Your site might have great content, good backlinks, and solid on-page SEO — and still rank lower than a technically mediocre competitor because it loads slowly, jumps around while rendering, or feels sluggish when users click.

That's what Core Web Vitals measure. And since Google incorporated them as a ranking signal in 2021 — and has been strengthening that signal ever since — poor scores are a real competitive disadvantage.

This guide explains what each metric measures, what scores to aim for, what causes failures, and the specific fixes that actually move the numbers. No vague advice — just what works.

How to measure your current scores: Go to PageSpeed Insights, enter your URL, and run the test. The results show both field data (real user experience) and lab data (simulated). Google Search Console also has a Core Web Vitals report under Experience — this shows real-world data for your entire site.

LCP — Largest Contentful Paint

What it measures: How long it takes for the largest visible element on the page to load. This is usually your hero image, a large heading, or a video poster.

Target: Under 2.5 seconds (green). 2.5–4s is needs improvement. Over 4s is poor.

LCP is the metric most sites struggle with most. A slow LCP feels like a slow page — it's what users experience as "this site is taking forever to load."

Common LCP causes and fixes

Slow server response time (TTFB)

If the server takes more than 600ms to respond to the initial request, your LCP will almost certainly be poor regardless of anything else you do. Check your Time to First Byte in PageSpeed Insights.

Fix: Upgrade to a faster host (shared hosting on budget providers is often the culprit), enable server-side caching, or use a CDN. For WordPress, a caching plugin (WP Rocket, LiteSpeed Cache) dramatically improves TTFB.

Unoptimised hero image

The hero image is the LCP element on most websites. If it's a large JPEG uploaded at 4000px wide and 3MB — your LCP is that image's download time.

Fix:

  • Convert to WebP format (typically 30–50% smaller than JPEG at same quality). Use Squoosh.app (free, browser-based) or ImageOptim to convert.
  • Resize to the display size — don't serve a 4000px image in a 1200px container. A 1400px wide WebP at 85% quality is the sweet spot for most hero images.
  • Add fetchpriority="high" to the LCP image tag. This tells the browser to load this image before anything else.
  • Add loading="eager" (or remove loading="lazy") from the LCP image — lazy loading defers it, which directly harms LCP.
  • Preload the LCP image: add <link rel="preload" as="image" href="hero.webp"> to your <head>.

Render-blocking resources

CSS and JavaScript files that load in the <head> block the browser from rendering anything until they finish downloading. If you have 5 CSS files and 8 JS scripts loading before your content, your LCP is delayed by all of them.

Fix:

  • Add defer or async to non-critical JavaScript tags.
  • Inline critical CSS (the styles needed to render above-the-fold content) directly in the <head>, and defer the rest.
  • Remove unused CSS and JS — on WordPress, deactivate plugins you don't use.

No CDN for static assets

If all your images, CSS, and JS serve from a single origin server, users far from that server experience higher latency. A CDN (Content Delivery Network) caches assets on servers close to the user.

Fix: Cloudflare (free tier is excellent for most sites) or a host-level CDN. For static sites on Vercel or Netlify, CDN delivery is built in.

CLS — Cumulative Layout Shift

What it measures: How much visible page content shifts unexpectedly after it starts rendering. Every time something moves — a button that jumps, text that reflows, content that gets pushed down — it adds to the CLS score.

Target: Under 0.1 (green). 0.1–0.25 is needs improvement. Over 0.25 is poor.

CLS is the metric that makes users click the wrong button because the page shifted at the last moment. It's both a ranking signal and a direct UX and conversion problem.

Common CLS causes and fixes

Images without width and height attributes

When an image has no explicit dimensions, the browser doesn't know how much space to reserve before it loads. The image loads, the browser measures it, and everything below it shifts down.

Fix: Add width and height attributes to every <img> tag, matching the image's intrinsic dimensions. The browser uses the aspect ratio to reserve the correct space before the image loads.

<!-- Before: causes layout shift -->
<img src="hero.webp" alt="Hero">

<!-- After: reserves correct space -->
<img src="hero.webp" alt="Hero" width="1400" height="600">

Web fonts causing FOUT / FOIT

When a web font loads, the browser may switch from a fallback font to the loaded font — and if the metrics differ (line height, letter spacing, character width), the layout reflows and shifts.

Fix:

  • Add font-display: swap to your @font-face declarations (or use Google Fonts with &display=swap in the URL).
  • Preload your primary font: <link rel="preload" as="font" type="font/woff2" href="font.woff2" crossorigin>.
  • Use size-adjust, ascent-override, and descent-override to match your fallback font's metrics to the loaded font — this minimises reflow when the font swaps in.

Dynamically injected content above existing content

Cookie banners, notification bars, newsletter pop-ins, and ad slots that load after the initial render and push existing content downwards are among the most common CLS culprits.

Fix: Reserve space for late-loading elements before they appear. A cookie banner that slides in from the bottom doesn't cause layout shift; one that appears at the top and pushes the page down does. Set a minimum height on ad containers so they don't expand from zero.

Animations using top, left, margin, or width

CSS animations that change properties like top, margin, width, or height trigger layout recalculations and can cause CLS.

Fix: Use transform and opacity for animations. These run on the GPU compositing layer and don't trigger layout. transform: translateY(-10px) instead of top: -10px.

INP — Interaction to Next Paint

What it measures: How quickly the browser responds to user interactions — clicks, taps, key presses. INP replaced FID (First Input Delay) in March 2024 as a Core Web Vital. It measures the full interaction latency, not just the initial delay.

Target: Under 200ms (green). 200–500ms is needs improvement. Over 500ms is poor.

Poor INP feels like an unresponsive interface. Click a button — nothing happens for half a second. Tap a menu — it hesitates. These delays erode trust and increase bounce rates.

Common INP causes and fixes

Long tasks blocking the main thread

JavaScript runs on the browser's main thread. When a long JavaScript task is running (anything over 50ms is a "long task"), the browser can't respond to user input until it finishes. The user clicks — the click event queues — and INP is the time from click to when the browser can finally process it.

Fix:

  • Identify long tasks in Chrome DevTools Performance panel — they appear as red blocks in the main thread.
  • Break long tasks into smaller ones using setTimeout(fn, 0) or the scheduler.yield() API to yield to the browser between chunks.
  • Defer non-critical JavaScript until after the page is interactive.
  • Remove unused JavaScript — every byte of JS that loads is JS that has to be parsed and compiled.

Excessive event listeners

Attaching event listeners to many elements individually (especially in frameworks that re-render frequently) can cause input delay.

Fix: Use event delegation — attach one listener to a parent element and check which child triggered the event — rather than attaching listeners to each child.

Heavy third-party scripts

Chat widgets, marketing automation scripts, A/B testing tools, and some analytics scripts can consume significant main thread time and directly harm INP.

Fix: Audit your third-party scripts. Load non-critical ones with defer or after a setTimeout delay. Consider removing tools you don't actively use — a chat widget that nobody uses is a pure performance tax.

Slow DOM

Rendering and updating a very large DOM (thousands of nodes) is expensive. Every time something changes in a large DOM, the browser has to recalculate styles and layout for more elements.

Fix: For content-heavy pages, virtualise long lists (only render what's in the viewport). Avoid deeply nested DOM structures. Use content-visibility: auto on off-screen sections to defer their rendering.

A Practical Improvement Priority Order

If your scores are red across the board, this is the order that typically delivers the most improvement per hour of effort:

  1. Fix your server response time — if TTFB is over 600ms, everything else is fighting uphill.
  2. Optimise your LCP image — convert to WebP, resize, add fetchpriority and preload.
  3. Add explicit dimensions to all images — this alone often fixes CLS on image-heavy sites.
  4. Defer non-critical JavaScript — add defer to scripts that don't need to run before render.
  5. Audit and remove heavy third-party scripts — check the Opportunities section in PageSpeed Insights for which third parties are adding load time.
  6. Fix cookie banner / notification bar CLS — if you have one that pushes content down.

Run PageSpeed Insights before and after each change. The "Opportunities" and "Diagnostics" sections tell you exactly which issues are on your site and how much improvement each fix is estimated to provide — work through them in order of estimated impact.

Core Web Vitals and SEO

Google confirmed Core Web Vitals as a ranking factor in its Page Experience update. In practice, their direct impact on rankings is moderate — content relevance and backlinks still matter more for most queries. But the indirect impact is substantial:

  • Faster sites have lower bounce rates, which keeps users on your content longer — a positive engagement signal
  • Better CLS reduces accidental clicks and frustration, improving time-on-page
  • Good INP scores make interactions feel responsive, increasing form completions and conversions
  • For highly competitive queries where other signals are equal, Core Web Vitals can be the deciding factor

For the full SEO picture — including how Core Web Vitals fit into the broader technical SEO checklist — read The SEO Checklist I Use on Every Client Website.