Core Web Vitals are Google’s way of measuring whether a page feels quick and stable to the people using it. A slow page loses visitors well before it loses rankings because nobody waits long for a site to make up its mind. Each of the three metrics fails for different reasons and needs different fixes. Treating them as one big speed problem is how teams spend months tweaking the wrong things.
Find out which metric is failing
Before trying to improve site speed across the board, find out which of the Core Web Vitals is failing and on which pages. The Core Web Vitals report in Google Search Console groups similar URLs together and uses data from people visiting your site. That’s the data Google uses, so it’s a better starting point than any single lab test.
Lab tools like PageSpeed Insights and the Performance panel in Chrome DevTools come next. They show you why a page is slow, once Search Console has told you which pages to look at. If you need a refresher on how site speed affects SEO, we’ve got you covered.
How to improve Largest Contentful Paint
Largest Contentful Paint measures how long the biggest image or block of text in view takes to appear, and Google wants it at 2.5 seconds or less. Google’s web.dev guidance splits LCP into four parts. Knowing which part is slow tells you where to look:
| Part of LCP | What it means | Usual fix |
|---|---|---|
| Time to First Byte | How long the server takes to start responding | Caching, a CDN or better hosting |
| Resource load delay | The wait before the browser starts downloading the main image | Put the image in the HTML and give it high priority |
| Resource load duration | How long the image takes to download | Smaller, compressed images |
| Element render delay | The gap between the image arriving and appearing on screen | Cut render-blocking CSS and JavaScript |
Speed up the server
If Time to First Byte is slow, nothing else on the page can start. Server-side caching and a content delivery network usually make the biggest difference. If neither helps, the hosting itself may be the bottleneck, a common discovery on cheap shared plans where your site shares a server with plenty of others.
Let the browser find the main image early.
Browsers can’t download an image they don’t know about yet. Any images added through CSS backgrounds or JavaScript are found late. Put the main image in the HTML, add fetchpriority=”high” to it and never lazy load it. Lazy loading tells the browser to wait, which is the opposite of what you want for the first thing people see.
Shrink the image itself.
Compress the main image and serve it as WebP or AVIF, with responsive images so phones download a smaller version than desktops. A 2,000-pixel photo squeezed into a 400-pixel space still downloads at full size. The browser then throws most of it away, which is about as efficient as it sounds.
How to improve Interaction to Next Paint
Interaction to Next Paint measures how long a page takes to respond visibly after someone clicks or taps, and Google wants it at 200 milliseconds or less. INP replaced First Input Delay in March 2024. It’s harder to pass because it looks at interactions throughout the visit. Every interaction has three phases:
- Input delay: the wait before the browser starts handling the interaction.
- Processing time: how long your code takes to run.
- Presentation delay: the wait for the screen to update.
Break up long tasks
The browser does most of its work on a single main thread, one job at a time. A long task, e.g. a big script running in one go, blocks every click and tap until it finishes. Splitting that work into smaller chunks lets the browser respond to people in between, which your developers will know as yielding to the main thread.
Load less JavaScript
The fastest JavaScript is the JavaScript you don’t load. Remove unused scripts and defer anything that isn’t needed straight away. Then question every third-party tag on the site. Each one was added for a good reason at the time, and most of those reasons have since left the company.
Keep the page structure lean.
Pages with thousands of HTML elements take longer to update after every interaction, and mega menus and long product grids are common culprits. Simplifying the structure, or adding sections as people scroll, keeps each update quick.
How to improve Cumulative Layout Shift
CLS measures how much content moves around unexpectedly while a page loads, and Google wants a score of 0.1 or less. Most shifts come from content arriving late and pushing everything else out of the way.
Reserve space for images and embeds
Set a width and height on every image and video or use the CSS aspect-ratio property. The browser can then hold the space open before the file arrives. Do the same for adverts and embeds, which tend to load last and land hardest.
Stop late content pushing things down.
Banners injected at the top of the page after it loads are frequent offenders. Reserve space for them in advance, or overlay them so the content underneath stays put. If something has to appear late, put it lower down the page where it won’t shove what people are reading.
Tame your web fonts
When a custom font loads late, text can reflow as it swaps in for the fallback font. Preload your main fonts and choose a fallback with similar proportions. The CSS size-adjust property can fine-tune the match, so the swap is barely noticeable.
How to speed up a WordPress website
WordPress sites tend to slow down one plugin at a time, as each plugin can add its own scripts and styles to every page whether it needs them or not. Audit your plugins, remove anything unused and add caching if your host doesn’t already provide it. If your content is on WordPress and you’re not considering WordPress SEO, you may as well not be posting.
Check your fixes are working
Lab tools show an improvement as soon as a fix goes live. Field data in Search Console takes longer, as it’s based on 28 days of visits. Once a fix is live, use the Validate fix button in the Core Web Vitals report so Google tracks whether the issue has cleared.
Keep monitoring after every major release too, since new features have a habit of arriving with new scripts attached. Site speed can slip for months without anyone noticing until the field data catches it. Use our checklist of common technical SEO issues as a good base to build around.
Fix the metric that’s failing
Improving Core Web Vitals starts with knowing which metric is failing and on which templates. LCP usually comes down to the server and the main image. INP comes down to JavaScript, while CLS comes down to content arriving without reserved space. Fix the templates that bring in revenue first, then give the field data a month to catch up.
If your developers need a clear brief, contact us for a technical SEO audit. We’ll show them which metric is failing, on which pages and why.
