Fixing Core Web Vitals Problems, Step by Step

You run a quick check on your website, and a tidy little report appears with a few coloured bars. Some are green, which feels reassuring, and one or two are an alarming red, which does not. The labels next to them read like a foreign language: largest contentful paint, interaction to next paint, cumulative layout shift. You have no idea what they mean, only that a red bar is probably bad and that fixing it apparently matters for showing up in search results. If that sounds familiar, you are in exactly the right place.

These measurements are called Core Web Vitals, and behind the intimidating names they describe three very human experiences: does the page show up quickly, does it respond when I tap, and does it stay still while I read. In this guide we will translate each one into plain language, then walk through how to find the cause of a failing score and fix it, step by step. You will not need to write code, just to understand what is happening and know which lever to pull.

What Core Web Vitals actually measure

Popular search engines want to send people to pages that feel good to use, not just pages with the right words on them. To judge that feeling at scale, they settled on three measurements that act as proxies for a smooth experience. Each one corresponds to a moment of potential frustration that we have all felt.

Once you see them this way, they stop being abstract. A poor largest contentful paint means people are waiting too long to see anything useful. A poor interaction score means the page feels unresponsive and laggy. A poor layout shift score means things are jumping around annoyingly. Fixing your vitals is really just fixing these three irritations, and that connects directly to the broader work in our guide on how to speed up a slow website.

Step one: measure before you touch anything

The cardinal rule of fixing performance is to measure first, because guessing wastes effort on the wrong problem. Free testing tools will show you which of the three vitals is failing and, crucially, point to the likely cause. Some tools report on real visitors over time, which reflects genuine experience, while others run a single lab test on demand, which is handy for experimenting. Use both: the real-visitor data tells you whether you truly have a problem, and the lab test helps you hunt down why.

It also pays to test the right pages. Your busiest pages and the ones people land on most matter far more than an obscure corner of your site nobody visits. And because most visitors arrive on phones, always check the mobile result, which is usually the harsher and more honest one. This is exactly the kind of structured checking we recommend in our website health audit guide.

Step two: fix a slow main content (LCP)

When the largest piece of content, usually a big image or a block of text, takes too long to appear, a few culprits are nearly always to blame. The most common is an oversized hero image that has not been properly compressed, so the browser is downloading far more data than it needs. Optimising that single image often produces the biggest improvement of any change you can make, and our guide on image optimisation for faster pages walks through exactly how.

The second culprit is a slow server or hosting plan that is sluggish to send the first response. If your testing tool reports a long wait before anything begins to load, the issue may be upstream of the page itself. Pairing solid caching with a content delivery network, which serves files from a location near each visitor, frequently resolves this. We explain the latter in our guide on what a CDN is and whether you need one.

A quick checklist for LCP

Compress and correctly size your main image, make sure that image loads eagerly rather than being deferred, enable caching, and consider a content delivery network if your audience is spread out. Those four moves resolve the large majority of slow-content problems without any custom development.

Step three: fix an unresponsive page (INP)

The interaction measurement catches the horrible moment when you tap a button or open a menu and the page freezes for a beat before responding. This almost always comes down to the browser being overloaded with too much behind-the-scenes work, usually code from add-ons and external services all clamouring for attention at once. When the browser is busy doing that work, it cannot respond to your tap promptly.

The fix is rarely glamorous: it is reducing the amount of code running on the page. The biggest wins come from removing add-ons you no longer use and trimming external scripts, the same housekeeping we cover in our guide on managing plugins and add-ons safely. Each unused tool you remove is work the browser no longer has to do, freeing it to respond to your visitors instantly.

Step four: fix a jumpy page (CLS)

Layout shift is the most visually obvious problem and often the easiest to fix once you know the cause. It happens when something loads later than the surrounding content and shoves everything else out of the way: an image that appears without its space reserved, an advert that drops in, a banner that pushes the page down, or a font that swaps and changes the text size. The cure is to reserve the space in advance, so the slow-arriving element slots neatly into a gap that was always waiting for it.

For images, this means telling the browser each image's dimensions up front. For adverts and embedded content, it means giving them a fixed reserved area. These are small, almost invisible changes that eliminate the maddening jump. It is worth noting that this is the one place where an over-eager lazy loading setup can backfire, by deferring images without reserving their space, so the two topics are closely linked.

A worked example: turning red bars green

Imagine an owner whose homepage shows two red bars: slow main content and a jumpy layout. Rather than panicking or rebuilding the site, they work the steps in order. They run a test, which flags an enormous, uncompressed banner photo as the cause of the slow content. They resize and compress that one image, and the slow-content bar improves dramatically on the very next test. One change, one big win.

Next they turn to the jumpiness. The test points to a promotional banner that drops in a moment after the page loads, shoving everything beneath it downward. They give that banner a fixed reserved height, so the space is held open from the start and nothing leaps when the banner arrives. The layout bar goes green. With two targeted fixes, neither requiring a developer, both red bars are resolved. The lesson is that failing vitals almost always trace back to a small number of specific, nameable causes, and once you stop guessing and start measuring, the path to fixing them is surprisingly short. Most owners are relieved to discover they did not need a costly rebuild, just a careful look at what the test was actually telling them.

Step five: re-measure and keep watch

After making changes, resist the urge to declare victory immediately. Because real-visitor data accumulates over time, the official scores search engines use can take a few weeks to reflect your improvements. Use lab tests to confirm a change worked in the short term, then keep an eye on the real-visitor data over the following weeks to see it bed in. Performance, like fitness, responds to consistency rather than a single burst of effort.

This is also why vitals are best treated as an ongoing health check rather than a one-off rescue. New content, fresh add-ons, and seasonal campaigns can all quietly nudge a green score back into the red, so periodic re-checking keeps you ahead of trouble. We make the case for that long-term habit in our guide on keeping your website fast over time, and connect speed to search visibility in our piece on website speed and Core Web Vitals.

The bottom line

Core Web Vitals sound technical, but they boil down to three honest questions: did the page show up quickly, did it respond when tapped, and did it hold still while being read. Each failing score points to a specific, fixable cause, an oversized image, an overloaded browser, an unreserved space, and you rarely need to write code to put it right. The discipline is simply to measure first, fix the actual problem rather than a guessed one, and then re-measure.

Work through the metrics in order: tame the largest content with image optimisation and caching, calm an unresponsive page by removing unused code, steady a jumpy layout by reserving space, then re-check and keep watching. Do that, and you turn those alarming red bars green, giving your visitors a smoother experience and your pages a better chance of being seen. If the diagnosis or the fixing feels like more than you want to take on, you are welcome to get in touch.

Frequently asked questions

References

1. Google. "Core Web Vitals." web.dev.
2. Mozilla. "Web performance." developer.mozilla.org.
3. HTTP Archive. "Web Almanac: Performance." almanac.httparchive.org.