Vitals

What the three Core Web Vitals actually measure

Largest contentful paint is the moment the biggest thing in the viewport finished rendering — usually the hero image or the headline. It is a proxy for "when did this page look ready". Google's threshold is 2.5 seconds.

Cumulative layout shift measures how much content jumped around after it first appeared. It is the metric behind the universal experience of tapping a link and hitting an advert because the page moved. The threshold is 0.1, and the usual causes are images without dimensions and fonts that swap late.

Total blocking time counts how long the main thread was too busy to respond to a tap. It is measured here as a lab stand-in for interaction latency, which can only be measured properly with real users.

Lab numbers are not field numbers

This is a single load from one server on a fast connection. Google ranks on field data — the twenty-eighth percentile of real visits on real devices and real networks — and that number will almost always be worse than what you see here.

So treat this as a diagnostic rather than a report card. It is good at telling you what is slow and roughly how much of the problem each thing is. It cannot tell you what your actual visitors are experiencing, and any tool claiming otherwise from a single synthetic load is overselling.

Run it twice. The first load populates caches at the CDN and the difference between the two is often larger than any change you were testing.

Weight is the lever you control

Most slow pages are not slow because of one bad decision. They are slow because a hundred small ones added up: a font family with six weights, three analytics scripts, a chat widget, an image at four times the size it displays.

The breakdown by type and the list of heaviest requests are there because they are usually more actionable than the headline metric. A 3 MB page has a specific 1.8 MB of JavaScript in it, and that is a conversation you can have with somebody.

Mobile is the number that counts

Mobile is the default here for the same reason Google indexes mobile-first: it is where most visits happen and where the constraints are real. A page that is comfortable on a laptop with a wired connection can be genuinely unusable on a mid-range phone.

The mobile measurement uses a phone-sized viewport, so the layout and the images the page chooses to serve are the mobile ones. It does not throttle the CPU or the network, which means the timings are optimistic compared with a real device — the weight and request counts, which are what you can act on, are accurate either way.

Measure what a page actually costs to load: largest contentful paint, cumulative layout shift, total blocking time, and the weight of everything it pulls in. Measured in a real browser rather than estimated, and reported with the specific thing to fix rather than a score out of a hundred.

It's one of the free tools in the util.quest collection — nothing to install, and no account needed. Found a bug or want a feature? Reach out at [email protected].