Website speed: Core Web Vitals for business leaders

One day a speed report lands on your desk, with a score in red and acronyms: LCP, INP, CLS. The temptation is to forward it to the agency and move on. That would be a shame: behind those acronyms are three sensations every one of your visitors experiences, and a few decisions that are not technical but yours. This article translates them. For the technical background (why a static site starts with a head start), see our guide to migrating to Astro.

Three measurements, three sensations

Each measurement describes what a visitor feels, and Google publishes a threshold for each:

Two details change how to read them. First, Google recommends judging at the 75th percentile: it is not enough for the average visit to be fast, three visits out of four must be, with mobile and desktop counted separately. Second, the response to clicks (INP) replaced in 2024 an older measurement that only looked at the first interaction: a site that was “green” three years ago may no longer be, without having changed.

What Google does with them

Google says in its Core Web Vitals documentation that good results align with what its core ranking systems seek to reward. But it adds a caveat:

Google adds that a good score in its reports does not guarantee a top position. In other words: a slow site that is the only one answering a question remains visible, and a fast site with no useful content does not climb. Speed separates comparable pages; it replaces neither content nor reputation.

What slowness really costs

The most direct effect of speed is not on rankings, it is on what visitors do once they arrive. The most quoted study on the subject, run by Deloitte for Google on the mobile sites of 37 European and American brands, measured what a gain of one tenth of a second changes:

These figures come from large brands and from a study commissioned by Google: they show a direction, not a promise for your site. The direction itself holds wherever people measure. Our article on landing pages shows what it costs when you pay for every click.

Where the sites we know stand

Here is the time to display the main content, measured by Lighthouse in mobile simulation, on three sites we know closely:

The plush toy store also showed a Lighthouse mobile score of 65 and a 4.2 MB page. On this site, the same measurement gives a score of 99 and 233 KiB transferred. The difference is not about the talent of the teams: it is about what the browser has to download and run before it can display anything.

Lab data, field data

Two families of figures circulate, and they do not say the same thing:

• The lab (Lighthouse, the “diagnose” part of PageSpeed Insights) simulates an average phone on an average network. It is the right measurement to compare before and after a change, under identical conditions.
• The field comes from real visits. The Core Web Vitals report in Search Console relies on this real-world usage data, taken from the Chrome User Experience Report, and labels your groups of pages “Good”, “Needs improvement” or “Poor”.

The field is what counts for Google, and for your customers. A site can feel fast on the office fibre and slow on a train: the field report will tell you, your own impression will not.

What slows a site down, and who decides

The technical causes often come down to decisions taken without linking them to speed:

• Images. A photo exported at full resolution weighs ten times what it should. On Palmora Property, the image pipeline converted 3,892 originals into 7,784 files in the right formats, and a thumbnail went from 353 KB to 17 KB.
• Scripts added one by one. Chat, customer reviews, ad tracking, maps: each is useful, and each loads. On the plush toy store, four to five review systems were loaded, for no review displayed.
• Pages built on every visit. A site that assembles its pages on a server waits for that server; a static site serves a file that is already built, from the point closest to the visitor (see our hosting comparison).
• Plugins. On a CMS, each plugin can add its scripts and styles to every page, and its updates to watch (see why WordPress sites get hacked).

Three decisions therefore belong to leadership. Require a dated measurement before any work, so you know what it changed. Write the thresholds into the brief for a redesign, alongside the pages and languages (see what a business website costs and sorting pages before a redesign). Arbitrate third-party scripts: every marketing tool added must be worth the time it costs on every visit.

Speed also meets accessibility: a page that does not move under the finger and responds quickly serves first those who navigate with a keyboard or assistive technology (see what the EU accessibility obligation changes). Sites whose content comes from a headless CMS keep these benefits on the visitor side, as our article on Astro and Sanity explains; so do forms and search, when they are plugged in page by page. And when copy is produced with AI to go faster, whether to disclose it is a separate question.

A business website we deliver is built to be fast on mobile from launch; a migration to a static site measures speed before and after, under the same conditions.

Frequently asked questions

Sources

1. Web.dev (Google), Core Web Vitals (new tab)web.dev
2. Google Search Central, Core Web Vitals (new tab)developers.google.com
3. Search Console Help, Core Web Vitals report (new tab)support.google.com