Core Web Vitals: what they are and how to fix every issue

What are Core Web Vitals and why do they affect rankings?

Core Web Vitals are a set of three metrics that Google uses to measure the real-world page experience of your site's visitors. Unlike traditional performance tests that run in ideal lab conditions, Core Web Vitals are measured from real Chrome user data collected through the Chrome User Experience Report (CrUX). That means Google is measuring the actual experience your visitors have, not an estimate.

The three metrics are Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Each one targets a distinct aspect of how a page feels to use: how fast it loads, how stable the layout is during loading, and how quickly it responds when someone clicks or taps something.

Google incorporated Core Web Vitals into its ranking algorithm as part of the Page Experience update. They are not the most heavily weighted ranking signal, but they function as a tiebreaker in competitive search results. Two pages with equivalent content, authority, and on-page optimisation will see the one with better Core Web Vitals scores rank higher. For sites operating in competitive niches, that tiebreaker matters.

Before doing anything else, check your current scores. Google Search Console's Core Web Vitals report shows your field data grouped by mobile and desktop, and flags URLs with poor or needs improvement status. PageSpeed Insights (pagespeed.web.dev) shows both field data from CrUX and lab data from Lighthouse for any URL. Start with your highest-traffic pages rather than trying to fix everything at once.

For context on where Core Web Vitals fit within a broader technical review, the full technical SEO audit guide covers all eight areas of a site audit including speed as step three.

Largest Contentful Paint (LCP): what causes it and how to fix it

LCP measures how long it takes for the largest visible element on the page to finish loading. In practice, this is usually a hero image, a large heading, or a banner. Google's threshold for a good LCP is under 2.5 seconds. Between 2.5 and 4 seconds is classed as needs improvement. Above 4 seconds is poor.

To find your LCP element, open Chrome DevTools, go to the Performance panel, record a page load, and look for the LCP marker in the timeline. Alternatively, PageSpeed Insights identifies the LCP element directly in its diagnostics section.

The three most common causes of slow LCP, in order of frequency:

• Unoptimised images: Large image files that have not been compressed, resized to the display dimensions, or converted to a modern format. WebP offers roughly 30% smaller file sizes than JPEG at equivalent quality. AVIF is smaller still but has slightly lower browser support. Compress images before uploading, set explicit width and height attributes on the img element to allow the browser to reserve space, and add loading='eager' to the LCP image specifically so the browser prioritises it.
• Render-blocking resources: JavaScript and CSS files that the browser must download and process before it can paint anything on the page. Identify render-blocking resources in the PageSpeed Insights diagnostics section. Defer non-critical JavaScript with the defer or async attribute, and move critical CSS inline into the head rather than loading it from an external file.
• Slow server response time (TTFB): If Time to First Byte is above 600 milliseconds, the browser cannot start loading any page resource until that time has elapsed. No amount of image optimisation or script deferring can compensate for a fundamentally slow server. If TTFB is the issue, the fix is at the infrastructure level: a faster hosting tier, a CDN, or server-side caching.

A less common but impactful cause is the LCP image not being in the initial HTML response. If the image URL is injected by JavaScript after the page loads, the browser cannot start downloading it until the JavaScript has run. Use a static img tag in the HTML for your hero image, never a JavaScript-injected background image.

Cumulative Layout Shift (CLS): identifying and resolving shift issues

CLS measures visual instability, specifically how much the page layout shifts around while it is loading. A score of 0.1 or below is considered good. Above 0.25 is poor. High CLS is frustrating for users because elements they are about to click on move as new content loads in above them.

The most common sources of layout shift are:

• Images without explicit dimensions: When the browser downloads an image but has no width and height attributes to tell it how much space to reserve, it reflows the layout when the image arrives. Add width and height attributes to every img element. This tells the browser the aspect ratio upfront, and it can hold the correct space even before the image has downloaded.
• Web fonts causing FOUT or FOIT: Fonts that load after the page renders can cause text to reflash or shift when the font swaps in. Add font-display: swap to your @font-face declarations so the browser uses a fallback font immediately and transitions to the custom font without causing layout recalculation.
• Dynamically injected content: Ads, cookie banners, and other injected elements that appear above existing content push everything below them down. Reserve space for ads with placeholder elements set to the expected ad dimensions, and ensure cookie banners are positioned as overlays (fixed or sticky) rather than pushing content.
• Embeds without reserved dimensions: YouTube iframes, Twitter embeds, and similar content loaded from external sources often have no intrinsic size. Wrap them in a container with a set aspect ratio using the CSS padding-top trick or the newer aspect-ratio property.

To debug CLS, use the Layout Shift Regions option in Chrome DevTools (under Rendering in the More Tools panel). It highlights in blue every element that shifts during page load, showing exactly what is moving and by how much.

Interaction to Next Paint (INP): reducing interaction delays

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the delay on the first interaction, INP measures the responsiveness of all interactions throughout a page visit. A good INP score is under 200 milliseconds. Above 500 milliseconds is poor.

INP is triggered by clicks, taps, and keyboard inputs. The metric measures the time from when the user initiates the interaction to when the browser paints the visual response. If the browser's main thread is busy when the user interacts, the response is delayed.

The main causes of poor INP:

• Long tasks on the main thread: JavaScript that runs for more than 50 milliseconds without yielding blocks the main thread and delays interaction handling. Use Chrome DevTools Performance panel to identify long tasks. The goal is to break large tasks into smaller chunks using setTimeout or the Scheduler API so the browser can handle input between them.
• Third-party scripts: Analytics platforms, chat widgets, retargeting pixels, and social media embeds all run JavaScript that competes for the main thread. Audit which third-party scripts are genuinely necessary and load them with defer or async. Consider loading non-essential scripts only after the page has finished its initial load.
• Excessive DOM size: Pages with very large DOMs (over 1,400 nodes according to Google's guidance) take longer to style, lay out, and paint. Simplify page structure where possible and use virtual rendering for long lists rather than rendering all items at once.

Tools like Semrush and Ahrefs surface INP issues at a site level through their site audit features. For deep debugging of individual pages, the Chrome DevTools Performance panel is the most detailed free option available.

How hosting affects Core Web Vitals

Hosting is the factor most site owners overlook when trying to improve Core Web Vitals. Every page experience metric has a floor set by your server's response time. If your server takes 1.5 seconds to respond, your LCP cannot be better than 1.5 seconds plus the time needed to download and render the LCP element. No other optimisation can change that ceiling.

TTFB (Time to First Byte) is the measure of server response time. A good TTFB is under 200 milliseconds. Between 200 and 600 milliseconds is acceptable. Above 600 milliseconds is a problem that needs addressing at the infrastructure level before other optimisations will have full effect.

Several factors affect TTFB: the physical distance between the server and the user, the processing time required to generate the page response (relevant for dynamic sites), and the server hardware tier. A CDN (Content Delivery Network) addresses the distance problem by serving cached responses from edge nodes close to the user. Server-side caching addresses the processing time problem by storing pre-generated page responses.

For WordPress sites, a caching plugin is the fastest way to reduce TTFB. For hosted platforms, the hosting tier is the main lever. Hostinger, Bluehost, and IONOS all offer plans with performance specifications relevant to sites with SEO requirements. Managed WordPress hosting plans typically include server-side caching and CDN as standard, which explains why they consistently outperform basic shared hosting on Core Web Vitals measurements.

On platforms like Webflow, WIX, and Squarespace, the hosting infrastructure is managed by the platform. Performance differences between plans on these platforms are generally smaller, but the choice of assets you add to the page (image sizes, third-party scripts) still controls LCP and CLS outcomes.

What this means for your page experience scores

Core Web Vitals improvement is iterative, not a one-time fix. Start with your highest-traffic pages, fix the LCP element first (usually an image), then check CLS on mobile specifically (layout shifts are more common on smaller viewports), then audit your JavaScript load for INP issues. Measure after each change using PageSpeed Insights to confirm the fix moved the score before proceeding to the next issue.

The biggest gains for most sites come from three changes: compressing and resizing hero images, deferring non-critical JavaScript, and switching to a hosting tier with a lower TTFB. These three changes alone typically move a site from poor or needs improvement into the good range for LCP and bring meaningful CLS reductions if images lacked explicit dimensions.

Track your progress over time in Google Search Console's Core Web Vitals report. Field data updates approximately every 28 days based on real user measurements, so expect a lag between making changes and seeing scores update in the report. PageSpeed Insights lab data reflects changes immediately and is useful for confirming fixes before field data catches up.

Core Web Vitals sit within the broader technical health of your site. For a complete audit framework covering all eight technical areas including crawlability, indexation, and structured data, the technical SEO audit guide provides the full step-by-step process. Rank Math also surfaces Core Web Vitals data within its WordPress dashboard, making it easier to monitor scores without leaving your CMS.