Page speed

Page speed is how quickly a page delivers usable content and responds to input, measured against published thresholds rather than a feeling. Google's Core Web Vitals guidance defines the three that matter: Largest Contentful Paint within 2.5 seconds of when the page first starts loading, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Each is assessed at the 75th percentile of page loads, segmented across mobile and desktop devices.

The percentile is the part most summaries drop, and it changes what the number means. A threshold at the 75th percentile is a statement about the distribution of real loads, not about a single run on a fast laptop. A median that clears 2.5 seconds while the tail sits at eight tells you the page fails, and a lab tool run once cannot tell you that at all.

The three metrics measure different things

• LCP — loading. When the largest content element in the viewport finished rendering. It answers "did something worth reading appear", not "did the page finish".
• INP — responsiveness. The latency from an interaction to the next paint, across interactions on the page. It replaced First Input Delay: web.dev records that INP was promoted in 2023 from experimental to pending status with the intent to eventually retire FID, and that it became a stable Core Web Vital in 2024. FID only measured the delay before the first input was handled, which flattered pages that were unresponsive later.
• CLS — visual stability. How much content moves without user input. Slow-loading images and late-injected banners are the usual cause.

They fail for different reasons and are fixed by different work, which is why "the page is slow" is not a diagnosis. Core Web Vitals covers each metric in detail.

What Google actually claims about ranking

Google's page experience documentation is unusually direct about the limits of the signal. It states that "Core Web Vitals are used by our ranking systems", and in the same document that "there is no single signal" — core ranking systems look at a variety of signals aligned with overall page experience — and that Search "always seeks to show the most relevant content, even if the page experience is sub-par".

Read together, that is a tiebreaker, not a lever. Fast pages do not outrank relevant ones. What speed reliably buys is that a relevant page is not held back by its delivery.

Why latency decides whether an agent reads you at all

For AI answers the mechanism is harsher than a ranking adjustment, because it is binary.

When an assistant answers a live question it performs a fetch against a request budget. Within that budget a page either returns usable content or it does not. If it does not, the page is not ranked lower — it is absent from the candidate set, and the answer is written from whichever competitor did return in time. Quality that never arrives is not weighed.

Three consequences follow.

Server-rendered content is the safe default. A page whose body only exists after client-side JavaScript executes is a bet that every agent fetching it runs a full browser. Some do not; a fetch that returns an empty shell has returned nothing. See crawling and indexing.

Time to first byte matters more than the pretty part. For a fetcher there is no perceived performance and no progressive reveal to hide behind. There is a response, or a timeout.

Speed compounds with crawl frequency. A cheap page is crawled more comfortably than an expensive one, which means the version of you in any index is more likely to be the current version.

Failure modes

• Optimising the lab score. A Lighthouse run is one synthetic load. The thresholds are defined on the 75th percentile of real loads; the two can disagree, and the field data is the one that describes reality.
• Averaging. A mean hides the tail that the 75th percentile exists to expose. Slow devices and poor networks are the population being measured.
• Fixing LCP and calling it done. Interactivity and layout stability are separate failures with separate causes.
• Client-rendering the substance. The fastest-feeling page in a browser can be an empty document to a fetcher that does not execute scripts.
• Treating speed as a content strategy. Speed removes a disqualifier. It does not make a passage worth quoting; that is a writing problem.

What to do, in order

1. Measure the field distribution, not one run, and look at the 75th percentile on mobile.
2. Render the substantive content server-side, so a fetch without JavaScript still returns the answer.
3. Cut the largest blocking asset first — usually a hero image or a render-blocking script — because LCP is dominated by one element.
4. Reserve space for anything that loads late to hold CLS down.
5. Then look at INP, which is normally main-thread work from third-party scripts rather than anything you wrote.