How to Improve Your Core Web Vitals Score

Core Web Vitals are three specific metrics that Google uses to measure how your website performs for real users. If your site is failing one or more of them, it can affect your search rankings, your bounce rate, and your conversion rate.

This guide explains what each metric measures and gives you specific, prioritised fixes for each one. Not sure where you stand? Run our instant speed test to check your current Core Web Vitals scores, or read our Core Web Vitals explainer for background on what the metrics mean.

The three Core Web Vitals

Metric	What It Measures	Good Threshold	Common Failures
LCP (Largest Contentful Paint)	Loading speed	2.5 seconds or less	Slow server, large images, render-blocking resources
INP (Interaction to Next Paint)	Responsiveness	200 milliseconds or less	Heavy JavaScript, long tasks, third-party scripts
CLS (Cumulative Layout Shift)	Visual stability	0.1 or less	Images without dimensions, late-loading fonts, injected content

Google measures these using real user data from Chrome browsers (the Chrome User Experience Report). You can see your site’s field data in Google Search Console under the Core Web Vitals report.

How to improve LCP (Largest Contentful Paint)

LCP is the most commonly failed Core Web Vital. It measures how long it takes for the largest visible element on the page to finish loading. This is usually a hero image, a heading, or a large block of text.

Google considers LCP good at 2.5 seconds or less, needs improvement between 2.5 and 4 seconds, and poor above 4 seconds.

Fix 1: Optimise your largest image

If your LCP element is an image (which it is on most pages), the size and format of that image directly controls your LCP time.

Compress the image. A hero image should be under 200 KB after compression for most layouts.
Convert to WebP or AVIF format. WebP is typically 25 to 35 percent smaller than JPEG at the same visual quality.
Serve the correct dimensions. Do not serve a 2400-pixel-wide image if the display area is 1200 pixels wide.
Preload the LCP image using <link rel="preload"> so the browser starts downloading it immediately rather than waiting until it encounters the image in the HTML.

Fix 2: Reduce server response time

A slow server means a slow LCP regardless of how well-optimised your front end is. Your Time to First Byte (TTFB) should be under 200 milliseconds for cached pages.

Enable server-side caching. On WordPress, install a caching plugin (WP Rocket, LiteSpeed Cache) or use host-level caching.
Use a CDN to serve cached content from a server closer to your visitors.
Upgrade hosting if your TTFB is consistently over 600 milliseconds. No amount of front-end optimisation compensates for a slow server.

Fix 3: Remove render-blocking resources

CSS and JavaScript files in the document head block the browser from rendering anything until they are downloaded and processed. Each render-blocking resource adds to the delay before your LCP element can appear.

Inline critical CSS (the styles needed for above-the-fold content) and load the rest asynchronously.
Add defer or async attributes to non-essential JavaScript files.
Remove unused CSS and JavaScript entirely where possible.

How to improve INP (Interaction to Next Paint)

INP measures how quickly your site responds when a user interacts with it. It tracks the delay between a user action (click, tap, keypress) and the next visual update on screen.

Google considers INP good at 200 milliseconds or less, needs improvement between 200 and 500 milliseconds, and poor above 500 milliseconds.

INP replaced First Input Delay (FID) in March 2024. It is a stricter metric because it measures all interactions during the visit, not just the first one.

Fix 1: Break up long JavaScript tasks

The browser runs JavaScript on its main thread. While a long JavaScript task is running, the browser cannot respond to user interactions. Any task longer than 50 milliseconds is considered a “long task” that blocks responsiveness.

Use requestIdleCallback or setTimeout to break large operations into smaller chunks.
Move heavy computation off the main thread using Web Workers where practical.
Review your JavaScript for loops or operations that process large data sets synchronously.

Fix 2: Reduce third-party script impact

Third-party scripts (analytics, chat widgets, ad tags, social media embeds) are the most common source of long tasks that block the main thread.

Audit every third-party script loading on your pages. Remove any that are not essential.
Defer non-critical third-party scripts. Load analytics after page interaction rather than on page load. Delay chat widgets until the user scrolls or clicks.
Use loading="lazy" for embedded iframes (YouTube videos, maps) so they do not execute until the user scrolls near them.

Fix 3: Minimise DOM size

A very large DOM (the structure of HTML elements on your page) makes every interaction slower because the browser has to process more elements when updating the page. Google recommends keeping your DOM under 1,400 elements.

Remove unnecessary wrapper elements and nested containers.
Simplify page structures, especially on pages generated by page builders which tend to produce deeply nested HTML.
Use pagination or lazy loading for long lists of content rather than rendering hundreds of items at once.

How to improve CLS (Cumulative Layout Shift)

CLS measures visual stability. It tracks how much the visible content moves around while the page is loading. Every time an element shifts position after it has been rendered, it adds to the CLS score.

Google considers CLS good at 0.1 or less, needs improvement between 0.1 and 0.25, and poor above 0.25.

Fix 1: Set explicit dimensions on images and videos

The most common cause of layout shift is images loading without width and height attributes. The browser does not know how much space to reserve until the image downloads, so content below the image jumps when it loads.

Always include width and height attributes on <img> tags. The browser uses these to calculate the aspect ratio and reserve space.
For responsive images, use CSS aspect-ratio or the HTML width/height attributes combined with max-width: 100%; height: auto;.
Apply the same approach to video embeds and iframes.

Fix 2: Avoid injecting content above existing content

Any content that loads after the initial render and pushes existing content down causes layout shift. Common offenders include cookie consent banners, late-loading ad slots, and dynamically injected promotional bars.

Place cookie banners at the bottom of the viewport or as an overlay that does not push content.
Reserve explicit space for ad slots using CSS min-height.
Avoid inserting elements above the fold after page load.

Fix 3: Handle web fonts properly

When a web font loads and replaces the fallback font, the text often changes size slightly, causing layout shift. This is called Flash of Unstyled Text (FOUT).

Use font-display: swap in your @font-face declarations so text is visible immediately with a fallback font.
Preload your most important font files using <link rel="preload" as="font">.
Choose fallback fonts that closely match the dimensions of your web font to minimise the shift when the swap occurs.
Better yet, use a system font stack. There is no font swap if you do not load custom fonts. Our site uses this approach for exactly this reason.

Measuring your progress

After making changes, you need to verify they worked. There are two types of Core Web Vitals data:

Lab data is generated by tools like PageSpeed Insights and Lighthouse in controlled conditions. It shows results immediately and is useful for diagnosing specific issues. Use this for testing individual fixes.

Field data comes from real Chrome users visiting your site over a 28-day period. This is what Google actually uses for ranking. It takes 4 to 6 weeks after implementing changes for field data to reflect your improvements.

Check both:

Run our instant speed test or use PageSpeed Insights for immediate lab results.
Check Google Search Console’s Core Web Vitals report for field data over time.
If you want a thorough analysis, request a free speed check from us.

Priority order for fixing Core Web Vitals

If all three metrics are failing, fix them in this order:

LCP first. It has the most direct impact on perceived load speed and is usually the easiest to improve with image optimisation and caching.
CLS second. Layout shift fixes are often straightforward (adding dimensions, reserving space) and produce immediate results.
INP last. JavaScript performance issues tend to be more complex to diagnose and fix, but INP improvements have the largest impact on user experience after the page has loaded.

For most sites, addressing LCP alone produces a noticeable improvement in PageSpeed scores and user experience. If your Core Web Vitals are failing and you need professional help, our Core Web Vitals optimisation service handles all three metrics as part of a single engagement.

Frequently asked questions

How long does it take for Core Web Vitals improvements to show in Google Search Console? Field data in Search Console uses a 28-day rolling average. After implementing fixes, you will typically see improvements in the data within 4 to 6 weeks. Ranking changes based on improved Core Web Vitals may take longer.

Can I pass Core Web Vitals on a WordPress site with a page builder? Yes, but it requires more effort. Page builders like Elementor and Divi add significant CSS and JavaScript overhead. Careful configuration, asset optimisation, and caching can bring most page builder sites into the green. Some heavily customised sites may need a theme-level rebuild. See our WordPress speed optimisation guide for detailed steps.

Do Core Web Vitals affect SEO rankings? Yes. Core Web Vitals are a confirmed Google ranking signal as part of the page experience update. The effect is modest compared to content relevance and backlinks, but it matters in competitive searches. For a detailed explanation, see our post on whether page speed affects SEO.

What is the difference between lab data and field data? Lab data is generated by tools under controlled conditions. Field data comes from real users over 28 days. Google uses field data for ranking. Your lab scores can differ significantly from field data because real users have different devices, connections, and browsing patterns.

My PageSpeed score is good but Core Web Vitals are failing. How is that possible? The PageSpeed Insights score is based on lab data (a simulated test). Core Web Vitals field data reflects real users on real devices. If your real visitors are predominantly on slower mobile connections or older phones, their experience may be worse than what the lab test simulates.