Three numbers describing what your page feels like

Why they exist

Traditional speed measurements described what the server did rather than what the visitor experienced. A page could score well and still feel slow and unusable.

These three try to describe the experience instead. Did the thing I came for appear, did it stop jumping around, and did it react when I touched it.

They are imperfect proxies for a real feeling, and they are considerably closer to it than a raw load time.

Traditional speed measurements described what the server did rather than what the visitor experienced. A page could score well and still feel broken.

• Did the thing I came for appear
• Did it stop moving so I could read it
• Did it react when I touched it

How fast the main content appears

The first measures how long until the largest visible element has rendered. Usually a hero image, a heading, or a block of text.

It is a proxy for the moment a visitor feels the page has arrived. Everything after that is detail; before it, the page looks broken.

The usual causes of a poor score are an oversized hero image, a slow server response, and fonts or scripts that block rendering.

How much the layout moves

The second measures unexpected movement while the page loads. Text that shifts down as an image arrives, a button that moves as an advert loads.

This is the one visitors hate most viscerally, because it causes mis-taps. Everybody has tapped the wrong thing because the page moved underneath them.

The fix is nearly always to reserve space: declare image dimensions, leave room for anything that loads late, and avoid inserting content above what is already visible.

How quickly it responds

The third measures the delay between somebody interacting and the page visibly responding. A tap, a click, a keypress.

Poor scores come from too much script running at once, usually third party code competing for attention while the visitor is trying to use the page.

A mostly static page with little script tends to do well here without anybody working at it.

Field data versus lab tests

The scores that count are gathered from real visitors on real devices, which means they reflect your actual audience rather than a simulation.

A lab test in a browser tool is useful for diagnosis because it is repeatable, and it is not what is being measured for ranking.

Small sites may have too few visitors to produce field data at all. That is not a problem to solve; it simply means the lab view is what you have.

Small sites may have too few visitors to produce field data at all. That is not a problem to solve; it means the lab view is what you have.

How much they matter

They are a ranking signal and a modest one. A page with poor scores and the best answer generally still wins.

They matter much more as a description of whether visitors can comfortably use your site, which affects everything else you measure.

The right posture is to fix the obvious faults, particularly layout movement, and then stop thinking about the numbers.

A page with poor scores and the best answer generally still wins, which is worth knowing before spending a fortnight on a decimal.

How ours are built

Pages here are static, served close to the visitor, with no third party script by default and images that declare their dimensions so nothing shifts.

That removes the common causes of poor scores by construction rather than by tuning afterwards.

Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards, and layouts are checked for overflow across a range of widths.

The structural causes are removed at build rather than tuned afterwards, which is covered for each measure in layout shift.

The published thresholds, as Google states them

• Largest Contentful Paint is rated good at 2.5 seconds or less, measured at the 75th percentile of page loads web.dev, Core Web Vitals
• Cumulative Layout Shift is rated good at 0.1 or less web.dev, Core Web Vitals
• Interaction to Next Paint is rated good at 200 milliseconds or less web.dev, Core Web Vitals

Figures are from the source named beside each one, as published there. None of them is a claim about this product.