What Are Core Web Vitals — and Why Do They Matter in 2026?

Core Web Vitals are three performance metrics that Google uses as a direct search ranking signal. They measure real-world user experience: how fast your main content loads, how quickly your page responds to clicks and taps, and whether your layout jumps around after loading.

Google has been weighting these signals since 2021, and in 2024 it replaced the old FID (First Input Delay) metric with INP (Interaction to Next Paint) — a stricter measure of interactivity. If your site hasn't been audited since before that change, you may be failing a metric you don't know about.

Here's what each metric measures:

LCP (Largest Contentful Paint): How long it takes for the main content to appear. Target: under 2.5 seconds.
INP (Interaction to Next Paint): How quickly the page responds to user interactions. Target: under 200ms.
CLS (Cumulative Layout Shift): How much the layout shifts unexpectedly after loading. Target: under 0.1.

A "Good" rating on all three is what you're aiming for. "Needs Improvement" hurts you. "Poor" actively drags down your search visibility.

How to Check Your Current Scores

Before fixing anything, you need to know where you stand. There are two types of data:

Field data (real users): Google Search Console's Core Web Vitals report shows how actual visitors experience your site. This is what Google uses for ranking. Go to Search Console → Core Web Vitals to see which pages are failing and why. Lab data (simulated): PageSpeed Insights, Lighthouse, and tools like PageScore run a controlled test and give you scores instantly — without needing real traffic data. Lab data is useful for diagnosing issues and testing fixes before they go live.

The key distinction: a page might look fast in lab tests but fail in field data if it relies on JavaScript that behaves differently on slower devices. Use both.

Fixing LCP: Get Your Main Content Loading Faster

LCP measures when the largest visible element — usually a hero image, headline, or banner — finishes loading. Most sites fail LCP for one of four reasons.

The LCP element is a slow-loading image

This is the most common cause. If your hero image is a 2MB JPEG served from an unoptimised server, LCP will be high regardless of everything else.

Fixes:

Convert your hero image to WebP format (typically 25–35% smaller than JPEG)
Add fetchpriority="high" to signal the browser to load it immediately:

<img src="hero.webp" alt="Hero image" width="1200" height="600" fetchpriority="high">

Preload the image in your :

<link rel="preload" as="image" href="/images/hero.webp">

Serve it from a CDN close to your users

The server is too slow (high TTFB)

If your server takes 1.5 seconds to respond, your LCP can't be under 2.5 seconds no matter how well your front-end is optimised. Time to First Byte (TTFB) is often the hidden culprit.

Check TTFB in PageSpeed Insights. Anything above 800ms needs attention. Common causes: shared hosting without caching, no page cache for WordPress, database queries on every request.

Fixes: Add a full-page cache (LiteSpeed Cache, WP Rocket, or equivalent), move to a faster host, or add a CDN like Cloudflare in front of your origin server.

Render-blocking resources delay the LCP element

If you have CSS or synchronous JavaScript in the , the browser can't render anything — including your LCP element — until those files finish downloading.

Fix: Defer non-critical JavaScript and inline critical CSS. See our 10 quick wins for PageSpeed for the specifics.

The LCP element is lazy-loaded

This is a common mistake. Adding loading="lazy" to your hero image tells the browser to deprioritise it — which is the opposite of what you want.

Fix: Never add loading="lazy" to images above the fold. Only use it for images that appear further down the page.

Fixing INP: Make Your Page Respond Faster to Clicks

INP replaced FID in March 2024 and is harder to pass. While FID measured the delay before your page started responding to the first click, INP measures the total time taken to render a visual update in response to any interaction throughout the page's lifetime.

In plain English: if clicking a button takes 500ms to show any visual feedback, that's an INP problem — even if JavaScript eventually runs correctly.

Long JavaScript tasks blocking the main thread

The most common INP cause. If you have a JavaScript function that runs for 300ms+ without yielding, any click during that time will feel unresponsive.

How to diagnose: Open Chrome DevTools → Performance tab → record while clicking around your page. Look for red-flagged "Long Task" blocks on the main thread. Fixes:

Break up long tasks using setTimeout with a 0ms delay to yield between chunks
Move heavy computation to a Web Worker (runs off the main thread)
Remove unused JavaScript — libraries you're not using, polyfills for browsers you no longer support

Third-party scripts causing INP failures

Analytics, chat widgets, and ad scripts all run on your main thread and can cause significant INP delays — especially on mobile.

Fix: Load third-party scripts with the defer attribute and audit which ones are actually being used. An abandoned analytics tag from a platform you left two years ago is still running on every page load.

Fixing CLS: Stop Your Layout From Jumping

CLS measures visual instability. Every time an element shifts position after the page loads — because an image loaded without reserved space, an ad popped in above content, or a font swapped — it adds to your CLS score.

Images without dimensions

The single most common CLS cause. If the browser doesn't know an image's size before it loads, it can't reserve space — so other content shifts to make room when the image arrives.

Fix: Add explicit width and height attributes to every image:

<img src="blog-photo.jpg" alt="Blog photo" width="800" height="450" loading="lazy">

This lets the browser calculate the aspect ratio and hold space even before the image loads.

Late-loading ads and embeds

Ads that load after your content are a classic CLS offender. If the ad slot isn't sized in advance, everything below it shifts down when the ad appears.

Fix: Always reserve space for ad slots using a min-height on the container, even before the ad loads.

Web font swaps causing text reflow

When a font loads late, text re-renders in the new typeface — sometimes at a different size, causing layout shifts.

Fix: Add font-display: swap to your @font-face declarations and preload your primary font file:

<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

Tracking Progress After Changes

Core Web Vitals improvements aren't instant in Search Console. Field data is collected over a rolling 28-day window, so a fix you deploy today won't fully show up in GSC for 4 weeks.

For faster feedback, use lab-based tools to verify your changes are working in the direction you expect. Run PageSpeed Insights before and after each change. If lab scores are improving, field data will follow.

Be aware that lab scores measure a single page load on a simulated device. INP, in particular, often only shows up in field data because it requires real interaction patterns.

What to Do First

If you're not sure where to start, prioritise like this:

1. Check your field data in Search Console. Find out which pages are actually failing and for which metric. 2. Fix LCP first — it's usually the biggest ranking impact and most fixable with image optimisation alone. 3. Check for layout shift — add width/height attributes to all images (one afternoon of work for most sites). 4. Profile INP — this requires Chrome DevTools and is more involved, but if your pages feel sluggish to interact with, it's worth the investigation.

A good starting point is to run a free audit on your site and see which specific issues are flagged. PageScore checks Core Web Vitals alongside SEO, security, and accessibility in one scan — and flags the specific elements causing problems. No signup required.

How to Improve Your Core Web Vitals in 2026