Core Web Vitals, explained for a business owner

Google defines the three in its Core Web Vitals documentation, each with a threshold that a page should meet for three-quarters of its visitors.

A page passes when all three are within their thresholds at the 75th percentile: three visits in four, measured on the phones and connections visitors really have.

Two sources give different numbers, and both are right about different things.

• Field data comes from real visitors using Chrome who have agreed to share measurements, collected over 28 days. It is what Google uses, and it appears in Search Console’s Core Web Vitals report and at the top of a PageSpeed Insights result once a page has enough visitors.
• Lab data comes from one simulated load on a slow phone over a throttled connection. It is what the lower half of a PageSpeed Insights result shows, and it is the only figure a new or small site has.

Judge the site by the field data where it exists, and use the lab data to find what to fix: it names the slow image, the heavy script or the font that shifts the text.

The largest thing on the first screen is nearly always an image or a block of text, and Google’s page on Largest Contentful Paint traces a slow one to a few causes.

• A hero image that is too large, or that waits for a script before it loads. Size it for the screen it fills, serve it in a modern format, and load it first.
• A slow server, which delays everything that follows. A cheap shared host, or a platform under load, shows here as a long wait before the first byte arrives.
• Stylesheets and scripts that must load before anything is drawn. Fewer, smaller, and the critical part inline.
• Web fonts that hold the text back until they arrive. Load the one the first screen needs early, and let the text show in a fallback meanwhile.

A page that is slow to respond is busy running scripts when the visitor taps. Google’s page on Interaction to Next Paint points at long tasks: chat widgets, analytics, advertising, animation libraries and the platform’s own code, all competing for a phone’s processor. Remove what the page does not need, delay what it needs later, and test on a mid-range phone rather than a desktop, where almost everything responds quickly.

Content jumps when something arrives late and pushes the rest down: an image with no reserved space, a banner injected at the top, a font that is a different size from the one shown first. The advice on Google’s page on optimising Cumulative Layout Shift is to reserve space for everything that loads late: give images their dimensions, keep cookie banners and notices from pushing content, and match the fallback font’s size to the web font’s.

Google says in its page experience documentation that the vitals are part of how it judges a page, and that content and relevance matter more. In practice two sites that answer a search equally well are told apart by how they load, and a page that fails badly loses visitors before any ranking comes into it. Pass the thresholds, then spend the effort on the content.

Start with Search Console’s report, if it has data: the group marked poor is the work list. Without field data, run the home page and the busiest service page through PageSpeed Insights on the mobile tab and read the diagnostics beneath the score, which name the files responsible. Our guide to checking your website speed explains how to read the result, and the platform guides, from why a Wix site is slow to speeding up a WordPress website, cover the fixes each platform allows.