A slow, jumpy website loses visitors before they read a word. Core Web Vitals are Google’s three measurements of how a page feels to real users: how fast the main content loads, how quickly the page responds when you tap or click, and whether things jump around while it loads.
In this guide I’ll explain what each metric means, how to find your real scores, and the fixes that make the biggest difference, based on Google’s own web.dev guidance. I’ve also included WordPress-specific tips, since many small business sites run on WordPress.
What are Core Web Vitals?
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the biggest image or text block appears | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | Responsiveness: how quickly the page reacts to clicks, taps and typing | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability: how much content moves unexpectedly | 0.1 or less | Over 0.25 |
Google assesses each metric at the 75th percentile of real page visits. In other words, a page passes if at least 75% of visits meet the “good” threshold.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
Do Core Web Vitals affect SEO?
They’re part of Google’s page experience signals, and Google recommends a good page experience. But relevance and helpful content matter more: a fast page with weak content won’t outrank a strong, relevant page just because it’s quicker. Think of Core Web Vitals as a way to keep visitors happy and avoid losing them, with SEO benefits as a bonus.
Step 1: Measure your real scores
There are two kinds of data:
- Field data comes from real Chrome users (the Chrome User Experience Report). This is what Google uses.
- Lab data comes from a simulated test (Lighthouse). It’s useful for debugging, but it can differ from what real users experience.
Where to look:
- Google Search Console › Core Web Vitals shows groups of URLs on your site rated Poor, Need improvement or Good, for mobile and desktop. Start here. My Google Search Console tutorial shows how to find it.
- PageSpeed Insights shows field data (if your page has enough traffic) plus a lab test with specific suggestions.
- Chrome DevTools › Performance panel for detailed debugging.
Fix problems on templates first. On WordPress, one slow template (such as single posts) can affect hundreds of URLs.
How to improve LCP (loading)
Google’s web.dev breaks LCP into four parts: server response time (TTFB), the delay before the LCP image starts loading, the time to download it, and the delay before it renders. Work on all four.
1. Speed up your server response.
- Use page caching. On WordPress, a caching plugin such as Breeze, WP Rocket or LiteSpeed Cache (depending on your host) serves ready-made pages instead of building each one.
- Use a CDN for images and static files.
- Choose decent hosting, and keep your PHP version up to date.
2. Help the browser find the LCP image early.
- Put the main hero image in the HTML, not only in CSS or JavaScript.
- Add
fetchpriority="high"to the LCP image so the browser loads it first. - Never lazy-load the LCP image. Lazy-loading delays it on purpose. Lazy-load images further down the page instead.
3. Make the LCP image smaller.
- Resize images to the size they’re displayed at.
- Use modern formats such as WebP or AVIF.
- Compress images before or on upload.
4. Reduce render-blocking code.
- Remove unused CSS and JavaScript, and don’t load heavy scripts in the
<head>unless they’re needed. - Defer non-critical JavaScript.
- Limit the number of web fonts and font weights.
How to improve INP (responsiveness)
INP measures the delay from an interaction (a tap, click or key press) to the next frame the browser shows. Google splits it into input delay, processing time and presentation delay. Poor INP is usually caused by too much JavaScript keeping the browser busy.
- Remove plugins and scripts you don’t need. Every slider, popup, chat widget and tracking script adds work.
- Delay third-party scripts (chat widgets, social embeds, some ad and tracking tags) until they’re needed.
- Break up long tasks. Developers should split heavy JavaScript into smaller chunks and yield to the main thread so the page can respond in between.
- Do less work in event handlers. Show visual feedback first, and do the heavy work afterwards.
- Keep the page’s HTML (DOM) size reasonable. Very large pages, such as huge page-builder layouts, take longer to update.
How to improve CLS (layout shifts)
Layout shifts happen when something loads late and pushes content down. The common causes, and Google’s recommended fixes:
- Images and videos without dimensions: always include
widthandheightattributes (or CSSaspect-ratio) so the browser reserves space. WordPress adds these automatically for images inserted in the editor. - Ads, embeds and iframes: reserve space with a fixed
min-height, and keep the space even if no ad loads. - Banners and notices injected at the top (cookie bars, promos): overlay them, or reserve space for them, so they don’t push content down.
- Web fonts: use
font-displaysensibly, choose fallback fonts with similar sizing, and preload your most important font. - Animations: animate with CSS
transform, not properties such astop,leftorheightthat change the layout.
Quick wins for WordPress sites
- Turn on page caching (and a CDN if your host offers one).
- Use an image optimisation plugin or your host’s tools to serve WebP and resize images.
- Deactivate unused plugins, especially sliders, page builders on pages that don’t need them, and social feeds.
- Check your theme’s hero image: make sure it isn’t lazy-loaded.
- Use a lightweight theme, and limit fonts to one or two families.
- Re-test in PageSpeed Insights after each change, so you know what helped.
If something breaks after a performance plugin change, clear the cache, undo the last setting, and check the browser console for errors. Minify and combine options are a common cause of broken layouts.
How long until Search Console updates?
Search Console’s Core Web Vitals report uses real-user data collected over the previous 28 days, so improvements take a few weeks to show. After fixing a group of URLs, you can click Validate fix in the report to start Google’s validation.
Frequently asked questions
What is a good Core Web Vitals score? LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, for at least 75% of visits.
Why does PageSpeed Insights show different scores each time? The lab test runs a fresh simulation each time, so results vary slightly. Field data from real users is more stable and is what Google uses.
Do I need a developer to fix Core Web Vitals? Not always. Caching, image optimisation and removing unused plugins fix many problems on small WordPress sites. INP problems caused by custom JavaScript usually need a developer.
What replaced First Input Delay? Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. It measures responsiveness across all interactions on a page, not just the first one.
Related guides on WebTechHelp
- Technical SEO audit checklist
- HTML and CSS for beginners
- How to get started with responsive images in WordPress
