Performance at 100
How EDS delivers a 100 Lighthouse score — the three-phase loading model explained.
Edge Delivery Services is built around one goal: a perfect, mobile Lighthouse score by default. It gets there mainly by controlling when work happens, not just how much of it there is.
The eager / lazy / delayed model
Every page's work is split into three phases so the browser only pays for what a given moment actually needs.
Eager
Decorate the DOM — classes for icons, buttons, blocks, sections — and build any auto-blocks. The body stays hidden with display:none until this is done, which avoids layout shift from images popping in unstyled. The first section loads in full, with priority given to whatever is the Largest Contentful Paint (LCP) candidate, usually a hero image; fonts load asynchronously only after that first section is visible.
The target budget is to keep everything delivered before LCP under 100kb, aiming for LCP around 1560ms. Connecting to a second origin before LCP fires is explicitly discouraged — the DNS and TLS handshake cost eats into that budget for no benefit yet.
Lazy
Everything else: remaining sections, block CSS/JS, below-the-fold images, and non-blocking scripts. None of this should affect Total Blocking Time or First Input Delay, since it all loads after the critical path to LCP.
Delayed
Third-party martech — analytics, consent banners, chat widgets — is deliberately held back until at least three seconds after LCP so it can never compete with the metrics that matter.
Rendering model
Canonical content is rendered server-side into real markup; CSS and DOM decoration only change how it's displayed, they don't replace that server-rendered content. Client-side rendering is reserved for genuinely non-canonical UI, like dynamically generated listings.
Headers, footers, and fonts
Headers and footers load asynchronously since they sit outside the critical path to LCP. Fonts load after LCP and rely on a font-fallback technique so swapping in the real web font doesn't cause a layout shift.
Things that hurt more than they help
- Early hints, HTTP/2 push, and preconnect — they consume the mobile 100kb budget without reliably improving LCP
- Multi-hop path redirects (e.g. domain → domain/en → domain/en/home)
- Pulling scripts from third-party CDNs before LCP — adds blocking time with no upside
- Minifying JS/CSS — measured to add no meaningful performance benefit at this stage
Measuring it
PageSpeed Insights is the lab tool of record; pull requests are automatically failed if a page scores below 100, tested primarily on mobile since it's the harder target to hit. Real User Monitoring (RUM) supplies the complementary field data.