How to improve website speed: a priority order for Core Web Vitals

“My site is slow” is not a diagnosis. There are three distinct kinds of slow, each fixed by different work. Optimising the wrong one means spending a week and changing nothing.

The thresholds first

There are three Core Web Vitals. To count as “good” you must be under the threshold on 75% of visits — your distribution is measured, not your average. Mobile and desktop are assessed separately.

Metric	What it measures	Good
LCP — Largest Contentful Paint	Time until the biggest content element appears	Under 2.5s
INP — Interaction to Next Paint	Delay between a tap and the screen responding	Under 200ms
CLS — Cumulative Layout Shift	The page jumping while you read it	Under 0.1

The most commonly failed metric today is INP: roughly 43% of sites miss the 200ms threshold. Very few teams spend as much time on INP as they do on LCP, and that is where most of the loss sits.

Field data, not lab data

The most common mistake is treating the Lighthouse score as the target.

Lighthouse is lab data — one device, one connection, one run. What Google uses for ranking is field data: CrUX records collected from real users on real devices.

Scoring 98 in Lighthouse while failing in the field is entirely possible. The lab measures on a fast machine; half your users are on a three-year-old Android on mobile data.

Use them like this: field data tells you what is broken, lab data tells you why. Start with the Core Web Vitals report in Search Console, find the failing template, then open that page in Lighthouse.

LCP: it is almost always one image

A single element decides your LCP, and it is usually the hero image. In order:

1. Identify the LCP element. Do not guess — Lighthouse names it.
2. Do not lazy-load it. Putting loading="lazy" on an above-the-fold image delays LCP with your own hands. Give it fetchpriority="high" instead.
3. Modern format, correct size. AVIF or WebP, several widths, an accurate sizes. Serving a 2000px image into a 400px slot spends your visitor’s data allowance.
4. Cut server response time. Compressing the image is pointless if the document takes 800ms. Static generation plus a CDN often solves this step on its own.
5. Stop fonts from blocking. font-display: swap, and preload for critical faces.

INP: where the real loss is

INP measures the time between a user touching something and the screen changing. Bad INP is almost always JavaScript occupying the main thread.

What to do:

• Delete unused JavaScript. The highest-impact fix and the least performed. Shipping 90KB for a date library is indefensible when three lines of Intl would do.
• Count your third-party scripts. Analytics, heatmaps, a chat widget, ad pixels, an A/B testing tool. Each queues on the main thread. On most sites this alone is what breaks INP.
• Break up long tasks. Any task over 50ms delays whatever the user taps during it.
• Separate the response from the work. Give visual feedback on tap first, defer the heavy computation. The user must see something within 200ms.

Removing the chat widget from your homepage can pay more than six hours of code optimisation. Measure first.

CLS: the easiest win

CLS usually breaks for three reasons, and all three are simple to fix:

• Images without dimensions. Set width and height so the browser reserves the space.
• Late-loading fonts. The metric gap between the fallback and the real font shifts every line. size-adjust and a metrically close fallback stack close it.
• Content injected after load. Cookie banners, announcement bars, ad slots. Reserve the space upfront.

Fixing CLS is usually a day’s work and the cheapest of the three metrics to win.

Being honest about the ranking effect

Core Web Vitals is a ranking signal, but a small one. A fast site with irrelevant content will not outrank a slow site with relevant content.

The real return on speed is not ranking, it is conversion. When a page is slow, the visitor leaves — and that shows up in revenue, not in a rank tracker. Treat speed as friction on the path to purchase rather than an SEO task, and which page to fix first becomes obvious.

The short roadmap

1. Search Console → Core Web Vitals → find the failing template.
2. Open that page in Lighthouse, identify the LCP element.
3. Make sure it is not lazy-loaded; fix its format and dimensions.
4. List your third-party scripts and delete the ones that earn nothing.
5. Give dimensions to images and to injected slots.
6. Wait four weeks — field data comes from real users, so it does not move instantly.