How do you make a website faster? Understanding Core Web Vitals

Let's answer the most common question first: scoring 100 in PageSpeed Insights is not a goal. What Google looks at for ranking isn't that coloured number but field data collected from the browsers of real visitors. Two sites can get the same score and behave completely differently in the field.

So let's start with the metrics rather than the score.

Which three things do Core Web Vitals measure?

The three describe different complaints, and their remedies differ too.

LCP is usually a photograph. Whenever the big image on your home page appears, that is your LCP. If it's slow, the cause is either the size of the file or the server answering late.

INP measures whether the page freezes after you press a button. It replaced FID in March 2024 and is a harder measure, because it doesn't judge a single first interaction but every interaction across the visit. Bad INP is almost always caused by too much JavaScript.

CLS is the problem everyone experiences without knowing its name: the text you've started reading slides down because an advert or image above it loaded late, and you tap the wrong thing. The remedy is simple and skipped on most sites: give images and advert slots explicit dimensions.

Why can the PageSpeed score mislead?

Let's give a concrete example here, because this is where the confusion sits.

We took measurements while building our own site. With real network throttling — not a simulated slow 4G but throttling actually imposed on the browser — LCP came out between 1.57 and 1.65 seconds, CLS measured 0.000, and on desktop LCP dropped to 0.55 seconds. On the same site, Lighthouse's default method was showing 2.6 to 2.8 seconds.

Where does the gap come from? Lighthouse's default measurement estimates by simulating the network, and it treats every request completed before the observed paint as a precondition of that paint. Under real throttling, LCP happened at the same moment as the first paint; in other words, the render delay was zero.

The practical rule that follows: a lab test is a diagnostic tool, not a report card. The report card is the Core Web Vitals report in Search Console. If there isn't enough data there, you look at Chrome's user experience report (CrUX).

How do you find the source of the slowness?

Acting on guesswork wastes time. The order runs like this:

1. How fast does the server answer? In the Network tab of your browser's developer tools, look at the response time of the first document. If that exceeds half a second, the problem isn't on the page but on the server or in the database. Compressing images won't fix it.

2. Which is the largest item? Sort the Network tab by size. At the top of the list you'll usually find a photograph or a font file.

3. How many requests are being made? Every externally loaded script opens its own connection. Analytics, live chat, maps, a font provider, a social media embed, an advertising pixel. On most sites, the total of those outweighs the site's own code.

4. How much JavaScript is there? The main thread view in the Performance tab shows when the browser is busy. INP problems are diagnosed here.

Which fix is worth what?

We give the order according to the balance of impact and cost.

Sort out the images. On nearly every site the biggest gain comes from here. Reduce the image to the size it will be used at, convert it to WebP or AVIF, and lazy-load anything below the fold. One warning: do not lazy-load the main image that is your LCP element — it has the opposite effect.

Simplify the fonts. Load two weights instead of five, serve the files from your own server, and use the font-display setting so the text stays visible until the font arrives. Otherwise the text is invisible for a few hundred milliseconds.

Remove unnecessary plugins. On sites running a content management system, this is usually the quickest win. Every unused plugin carries on loading its own CSS and JS file on every page.

Caching and a CDN. Page caching lowers the load on the server noticeably. If your audience is spread out geographically, a content delivery network adds further benefit; if your visitors are concentrated in one country and your server is already close to them, the gain is limited.

Review the third-party scripts. The question for each one is this: how much revenue does it bring, and how many milliseconds does it add to the page? A heatmap tool nobody has looked at for years does not pass that test.

Give things dimensions. Writing width and height on images, videos and embedded areas solves CLS in one move on most sites.

What gets done on the server side?

The application side has to be counted in too, particularly where pages are fed from a database.

Slow queries are the most frequent cause. Code that runs a separate query for every row on a listing page goes unnoticed at ten records and stops the site at a thousand. The second most frequent cause is logging and debug mode left switched on in production.

The hosting you're on plays a part here too: a plan where hundreds of sites share one machine will hold your response time back however well the page itself is built. Our approach on the custom software side is on the web development page.

How much does speed affect rankings?

The honest answer: the direct effect is smaller than people think. Core Web Vitals is a ranking signal, but it doesn't carry the same weight as the quality of the content. A fast but empty page will not overtake a slow page that gives the right answer.

The real effect arrives indirectly. A page that doesn't open gets abandoned, the form doesn't get filled in, the advertising budget goes to waste. If you're running ads, that is money directly: you collect fewer enquiries for the same cost per click. The page opening is the precondition for getting your money's worth on the SEO and Google Ads side.

Where should you start?

Here's an order you can work through in a week: look at the field data in Search Console, pick the worst-performing group of pages, find the three largest files on that page, shrink the images and change their format, give the images dimensions, and look at the data again two weeks later.

On most corporate sites that much is enough to get under the threshold. If it isn't, the problem isn't on the page but on the server or in the application, and that needs looking at separately.

If you'd like us to go through your current measurements with you, write to us from the contact page.