Core Web Vitals: what to fix first when your scores are red
The four changes that fix most failing Core Web Vitals, ordered by impact per hour of work.
- LCP is almost always an image or a font. Fix the hero image first.
- CLS is almost always missing width and height attributes on images and ads.
- INP is usually a heavy third-party script you can defer or remove.
- Most sites can go from red to green in a day of focused work.
Do not optimise everything
Performance work has a long tail of diminishing returns. Four changes fix most failing sites, and they take a day. Everything after that takes a week and moves the number by two points.
Start with what Google actually measures on real users, not what your local Lighthouse run says. Open the Core Web Vitals report in Search Console and work from field data.
LCP: fix the hero image
Largest Contentful Paint is usually your hero image or your headline font. If it is the image, three things fix it.
Serve it as WebP or AVIF. Set explicit width and height. Add fetchpriority=’high’ and loading=’eager’ — and make sure it is not lazy-loaded, which is the single most common self-inflicted LCP problem.
If it is the font, preload the font file and use font-display: swap. A headline that renders in a fallback face and swaps is far better than one that renders three seconds late.
CLS: width and height on everything
Cumulative Layout Shift happens because the browser does not know how much space to reserve before an asset loads.
Every img tag needs width and height attributes, even when CSS overrides the actual size. The browser uses the ratio to reserve space.
Reserve space for ads, embeds and anything injected by JavaScript. A cookie banner that pushes content down after two seconds is a CLS disaster and users hate it independently of the metric.
INP: the third-party audit
Interaction to Next Paint replaced First Input Delay and it is harder to game. It measures how long the page takes to respond when someone actually clicks.
Open the coverage tab in Chrome DevTools and look at unused JavaScript. Most sites are loading a chat widget, three analytics tools, a heatmap recorder and a personalisation script, and using almost none of them.
Defer everything non-essential. Load the chat widget on interaction rather than on page load. Question whether you need the heatmap tool running on every session forever.
The measurement trap
Lighthouse on your laptop over office wifi is not what Google measures. It measures field data from real Chrome users, aggregated over 28 days.
That means two things. First, test on a throttled connection and a mid-range Android. Second, after you deploy a fix, expect to wait several weeks before the field data reflects it. Do not panic and change five more things in week two.
Want this done for you?
We do this work every day across 24 services. Free audit, findings yours either way.
Related questions
What is a good LCP?
Under 2.5 seconds for 75% of visits. Under 1.5 is comfortable. Above 4 seconds is failing and will be affecting rankings and conversion both.
Do Core Web Vitals actually affect rankings?
Yes, as a tiebreaker rather than a primary factor. Content and links decide who is in contention; page experience decides between similar candidates. It affects conversion more than rankings, which is the better reason to fix it.
Can I fix this on WordPress?
Mostly, yes. A caching plugin, an image optimisation plugin and removing three unused plugins fixes most WordPress performance problems. The hard cases are page builders that ship enormous CSS.
