Slow website? Core Web Vitals explained, and how to fix them

What are Core Web Vitals?

Core Web Vitals are three measurements Google uses to describe the experience of loading and using a page: how quickly the main content appears, how quickly the page responds when someone interacts with it, and how much the layout jumps around while it loads.

They matter for two reasons. Google uses them as part of its page experience signals in ranking, though relevance and content quality matter far more. And they measure real frustration: a slow, jumpy page loses visitors before they read a word.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

To pass, a page needs to be "Good" on all three, measured at the 75th percentile of real visits. In other words, three out of four visits must have a good experience. Mobile and desktop are assessed separately, and mobile is usually the harder one.

How to check your Core Web Vitals

There are two kinds of data, and the difference matters.

• Field data comes from real Chrome users visiting your site (the Chrome User Experience Report). This is what Google uses. It needs enough traffic to be reported, and reflects the last 28 days.
• Lab data comes from a simulated test, such as Lighthouse. It's useful for diagnosing problems and testing fixes, but it isn't what Google judges you on.

Start with Search Console. It groups pages that share a template, so you can see, for example, that every blog post has a poor LCP on mobile. Then test one example page from each failing group in PageSpeed Insights.

If your site doesn't get enough traffic for field data, use the lab results as your guide and aim for the same thresholds.

Why is my website slow?

Most slow business websites come down to the same handful of causes:

If your site loads quickly for you but slowly for others, it's often because your browser has cached it, or you're near the server. Test in a private window, on a phone, using mobile data.

How to improve LCP (loading)

LCP is usually the hero image or the main heading at the top of the page.

1. Compress and resize images. Serve images at the size they're displayed, in a modern format such as WebP or AVIF. A hero image rarely needs to be more than a few hundred kilobytes.
2. Don't lazy-load the main image. Lazy loading is good for images further down the page, but the LCP image should load straight away. You can also mark it as high priority (fetchpriority="high").
3. Speed up the server. Use page caching, a content delivery network (CDN) and decent hosting. A slow server delays everything else.
4. Reduce render-blocking CSS and JavaScript. Load non-essential scripts later (defer or async), and remove what isn't used.
5. Load fonts efficiently. Use fewer font files, host them yourself or preload the main one, and use font-display: swap.

How to improve INP (responsiveness)

Poor INP means the page is busy running JavaScript when someone taps or clicks.

1. Remove scripts you don't need. Audit your tag manager and plugins: old tracking pixels, unused chat tools and duplicate analytics all add work.
2. Delay third-party scripts such as chat widgets until the visitor interacts, or until after the page has loaded.
3. Lighten heavy components: sliders, animations and complex menus often run a lot of code.
4. Break up long tasks in custom JavaScript, so the browser can respond in between (a job for your developer).

How to improve CLS (stability)

1. Set width and height on images, videos and iframes, so the browser reserves the space before they load.
2. Reserve space for anything injected later, such as cookie banners, announcement bars and embeds. Banners that overlay the page don't cause shifts; ones that push content down do.
3. Avoid inserting content above existing content after the page has loaded.
4. Load fonts in a way that doesn't change text size dramatically when they swap in.

Fix by template, not page by page

Most sites have a few templates: homepage, service page, blog post, contact page. Core Web Vitals problems usually live in the template, not in individual pages, which is why Search Console groups URLs together. Fix the template once and every page using it improves.

A sensible order:

1. The template with the most traffic that's failing on mobile
2. The failing metric with the biggest gap from "Good"
3. The biggest single cause for that metric (often one image or one script)

After deploying a fix, retest in PageSpeed Insights straight away (lab data), then use Validate fix in Search Console's report. Field data takes up to 28 days to reflect the change.

On WordPress, see our guide to speeding up WordPress for platform-specific fixes.

How much do Core Web Vitals matter for SEO?

They matter, but less than relevance and content. Google's guidance is that page experience signals help it choose between pages of similar relevance and quality; a great experience won't make up for a page that doesn't answer the search. Treat good Core Web Vitals as part of a well-run site, and because faster pages keep more visitors, not as a ranking shortcut.