Core Web Vitals

Each of the three describes a different way a page can feel broken, which is why there are three of them rather than one score. They are measured at the 75th percentile of page loads, so the question is not whether the page is usually fine but whether it is fine for three visits in four.

This is the distinction that causes most of the confusion in client reporting. Lighthouse and PageSpeed Insights lab mode simulate a page load on a synthetic device and network, and produce a score immediately. Core Web Vitals are assessed on the Chrome User Experience Report: real loads, by real visitors, on the devices and connections they actually have.

CrUX aggregates over a rolling 28-day window. So a fix deployed today does not move the number today. It enters the window immediately and only dominates it a month later, as the slow loads from before the fix age out.

The consequence for an agency is entirely predictable and still catches people out: the work ships, the client checks PageSpeed Insights the next morning, sees the field data unchanged, and concludes nothing happened. Explaining the window before the deployment costs one sentence. Explaining it afterwards sounds like an excuse.

It also means a site with low traffic may have no field data at all, in which case Google falls back to origin-level data or has nothing to assess. That is worth checking before promising a client a score will improve.

Google has been consistent, and unusually clear, that page experience is a modest signal: a tiebreaker among results of comparable relevance rather than something that lifts a weak page above a strong one. An agency selling Core Web Vitals work as a ranking strategy is overselling it.

The honest framing is that it stops being a handicap rather than becoming an advantage. If two pages answer the query equally well and one of them shifts under the reader thumb, the other has an edge. If one page answers the query and the other does not, speed is not what decides it.

Which is why the stronger argument is commercial. Slow pages lose visitors before they have read anything, and that loss is measurable in the client own analytics rather than inferred from a ranking chart. A page that loads a second faster converting better is a claim a client can verify.

This matters for how the work is sold. Pitched as ranking, it competes with content and links and usually loses. Pitched as conversion, it competes with landing page work and often wins, because it helps every page at once.

The default is to open the homepage in PageSpeed Insights, and the homepage is rarely where the money is. The pages worth fixing are the ones receiving traffic that converts: the landing pages behind paid campaigns, the product or service pages, the articles that bring in search visitors.

Fixing the homepage while those stay slow is the most common way this work produces a better score and no better business, and it happens because the homepage is the URL everybody tests.

Within a page, the three metrics have very different economics. CLS is usually the cheapest to fix and the most visible to a human: reserve space for images, adverts and embeds so nothing jumps. LCP is usually about one large image or a blocking font. INP is the hardest, because it is generally third-party scripts, and third-party scripts are generally a marketing decision rather than a technical one.

That last point is worth raising explicitly with clients. A tag manager carrying eleven scripts is an INP problem that no amount of developer time solves, and the conversation about which of the eleven are still needed belongs to the agency as much as to the developer.