Measured results

We measured in October 2026 on a reference site built as this playbook describes. It has server-rendered pages, inline CSS, one module script, an AVIF hero, self-hosted fonts and Brotli. The lab served it from its Node server over plain HTTP/1.1, without nginx, HTTP/2 or TLS. The baseline still prefetched every link at once and used font-display: swap. Both changed after these results. The tool was Lighthouse 12.8 in Chrome 143, with simulated throttling. "Mobile" means a mid-range phone on slow 4G. "Desktop" means a fast connection. Each variant is a copy of the site with one change, built and served the same way. Figures are the median of 3 runs on two pages, a home page and a content page. The SEO and accessibility rows used one run on the home page. Where it mattered, we confirmed them with 7 runs. To repeat it, see Measuring it yourself.

The reference site

SEO is 92, not 100, only because of Content-Signal lines in robots.txt (see below).

Taking one feature away

Mobile, start page unless noted. "Data" is everything the page downloaded during the test.

Two defaults that measuring overturned

Prefetching every link at once costs more than it gives. Prefetching means loading the next pages before anyone clicks. Lighthouse counts every prefetched page against the first load. Removing the eagerness: immediate prefetch took home page LCP from 2.10 s to 1.50 s. Data went from 202 KB to 117 KB. On a page with about 50 links, we tried prefetch on hover (moderate). It took LCP from 3.45 s to 1.51 s, and data from 403 KB to 89 KB. Browsers clicked no faster with immediate prefetch, because a service worker cache already held the pages.

font-display: swap can move long pages. We used size-adjusted fallback fonts. A short home page did not shift. Long pages did, when the fonts arrived and the text re-wrapped. Layout shift went from 0 to 0.226 on desktop and from 0 to 0.123 on a phone. With font-display: optional, every page measured 0.

Lighthouse and browsers disagree on font preloads

Adding two font preloads moved Lighthouse's simulated first paint from 1.35 s to 0.90 s. LCP on the home page got later, from 2.10 s to 2.25 s. Chrome, with the same HTML, showed the opposite. There, phone first paint moved from 43 ms after the HTML to 123 ms. Lighthouse simulates the network. The browser lab measures it. Trust the browser lab. Don't preload fonts unless it shows a gain.

SEO and accessibility checks catch problems

Lighthouse's SEO score is a floor, not a goal. It does not reward having a robots.txt. It also marks down Content-Signal lines, which robots.txt allows as extra records.

Clicks and repeat visits

We used Chromium, driven by Playwright, with 100 ms of added round trip and a 20 Mbit/s limit. Figures are the median of 7 fresh browsers. First paint counts from the start of the connection. A click counts from the click to the next page's first paint. A repeat visit is the start page opened again in a new tab.

• Inline CSS saves a full round trip on first paint. Moving the stylesheet to a file took phone first paint from 251 ms to 451 ms.
• Font preloads took phone first paint from 251 ms to 331 ms in a browser. That is the opposite of Lighthouse's simulation.
• The view transition took a phone click from 63 ms to 96 ms, and a desktop click from 68 ms to 126 ms.
• Prefetch, service worker and caching each make no difference on their own in Chromium. The others cover the same ground. The prefetch, the service worker's warm cache and the HTTP cache all hold the next page. Browsers that ignore speculation rules still get the service worker's warm cache (see Performance).

The rules in this playbook already follow these results. They prefetch at moderate, set fonts to optional, inline the CSS, and use no preloads and no view transition.