Your website could have the best content in your industry – and still lose rankings to a competitor with a faster, more stable page. That is what Core Web Vitals measure: not your content quality or your backlink profile, but the raw user experience of visiting your site. And since 2021, Google has used these metrics as direct ranking signals.
In March 2024, Google updated its Core Web Vitals framework by replacing First Input Delay (FID) with a stricter new metric, Interaction to Next Paint (INP). Many websites that previously passed their CWV assessment are now failing. Only 53% of websites currently pass all three Core Web Vital thresholds. That means nearly half of all websites are leaving ranking points on the table due to fixable performance issues.
This guide explains exactly what Core Web Vitals are, how they affect your Google rankings, and – most importantly – the step-by-step fixes you can apply to pass each threshold. Whether you run a WordPress blog, a business website, or an e-commerce store, every fix in this guide is actionable without needing deep developer expertise.
What Are Core Web Vitals?
Core Web Vitals are a set of three specific, measurable metrics that Google uses to evaluate the real-world user experience of loading a web page. They were introduced by Google in 2020 and became an official Google ranking factor as part of the Page Experience Update in May 2021.
According to Google’s Search Central documentation: “Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page. We highly recommend site owners achieve good Core Web Vitals for success with Search.”
What makes Core Web Vitals different from older speed metrics is that they measure user perception – how fast the page feels, how quickly it responds to interactions, and how stable the layout is as it loads. These are the things that determine whether a real visitor stays or leaves.
Why Core Web Vitals Matter for SEO and Rankings
Core Web Vitals are a confirmed Google ranking factor – but understanding how much they matter requires context. They are not the dominant ranking signal (content relevance and backlinks still matter far more), but they are a meaningful tiebreaker for competitive keywords.
The Real-World Impact of Core Web Vitals on Business Metrics
Core Web Vitals matter beyond just rankings. Slow, unstable pages directly hurt conversions, bounce rates, and revenue – regardless of their impact on Google rankings:
How Google Measures Core Web Vitals: Field Data vs Lab Data
This is a critical distinction that many website owners miss. Google uses two types of data for Core Web Vitals:
- Field Data (Real User Metrics / CrUX): Anonymised performance data collected from actual Chrome browser users visiting your site, aggregated in the Chrome User Experience Report (CrUX). This is what Google uses for ranking. Your site needs at least 75% of page visits to meet each "Good" threshold. This data appears in Google Search Console and is 28-day rolling data.
- Lab Data: Simulated performance tests run in a controlled environment using tools like Lighthouse or PageSpeed Insights. Useful for diagnosis and development, but NOT what Google uses for ranking. Lab scores can differ significantly from field scores.
Implication: Always check your Core Web Vitals in Google Search Console (field data) – not just PageSpeed Insights (lab data). A perfect PageSpeed score does not guarantee passing CWV if your real users experience slow interactions due to third-party scripts, user behaviour patterns, or device diversity.
LCP (Largest Contentful Paint): What It Is and How to Fix It
LCP is the metric Google uses to measure how fast the most visible content on your page – typically your hero image or largest heading – actually renders for a real user. It is the Core Web Vital that most sites fail first, and it is also the one with the most direct, fixable causes.
What Google Counts as the LCP Element
The LCP element is not always what you expect. Google’s algorithm identifies the largest element visible in the viewport at the time of page load, which could be:
- A hero image (most common on websites with image-heavy headers)
- A featured image at the top of a blog post
- A large text block (H1 heading) if no image is present above the fold
- A video poster/thumbnail image
- A background image loaded via CSS (in some cases)
Find your LCP element: Open PageSpeed Insights (pagespeed.web.dev), run a test on your URL, and scroll to the “Opportunities” section. Click “Largest Contentful Paint element” to see exactly which element Google identified on your page.
The Most Common LCP Problems and Their Fixes
Most LCP failures trace back to one of four root causes – and identifying which one affects your specific page is faster than applying generic speed fixes that may not address the actual bottleneck. Check your PageSpeed Insights report and match the flagged issue to the corresponding fix below before making any changes.
Expected improvement: 800ms–1.5s faster LCP. WebP images are typically 25–35% smaller than equivalent JPEG or PNG files. AVIF is 20% smaller still. Smaller files download faster – directly improving LCP.
- 1. Identify your LCP image: Run PageSpeed Insights on your page and note the LCP element image URL.
- 2. Convert to WebP: Use Squoosh.app (free, browser-based), Cloudinary (free tier), or a WordPress plugin like Imagify, ShortPixel, or Smush to convert images automatically.
- 3. Set image dimensions: Always add width and height attributes to your hero image in HTML. This reserves space in the page layout before the image loads - also fixing CLS.
- 4. WordPress shortcut: Install the "Imagify" or "ShortPixel" plugin - it converts all existing and future image uploads to WebP automatically with no manual work required.
Expected improvement: 200–600ms faster LCP. A preload hint tells the browser to start downloading your LCP image immediately – before it finishes parsing the rest of the HTML. This eliminates the “late discovery” delay that is common for hero images.
Add this to your <head> section:
TTFB (Time To First Byte) is the root cause of slow LCP for many sites. If your server takes over 600ms to respond, everything downstream is delayed – and no amount of image optimisation will compensate.
- Upgrade hosting: Shared hosting with response times over 600ms is the most common TTFB culprit. Move to managed WordPress hosting (Kinsta, WP Engine, Cloudways) or a VPS.
- Implement server-side caching: WordPress: Install WP Rocket or LiteSpeed Cache. These cache fully-rendered HTML pages so the server does not rebuild the page from scratch on every request.
- Use a CDN: Cloudflare (free tier available) caches your static assets and HTML at edge servers worldwide - reducing the physical distance between your server and each visitor.
- Optimise your database: On WordPress, plugins like WP-Optimize clean up post revisions, spam comments, and transients that slow database queries.
INP (Interaction to Next Paint): What It Is and How to Fix It
INP replaced FID in March 2024 and is significantly stricter – where FID only measured the first click, INP measures every interaction across the entire page session and reports the slowest one. Sites that passed their CWV assessment before March 2024 need to re-audit specifically for INP, because previous FID compliance does not guarantee an INP pass.
Understanding the Three Components of INP
A slow INP score is almost never caused by the interaction itself – it is caused by what the browser has to do before and after registering the interaction. Understanding which of the three components is responsible for your INP failure determines whether the fix sits in your JavaScript, your rendering pipeline, or your event handler code.
The Most Common INP Problems and Their Fixes
INP failures are almost always JavaScript-related – heavy third-party scripts, unoptimised event handlers, and long tasks blocking the main thread are responsible for the majority of poor INP scores across all site types. The fixes below address each cause in order of frequency, starting with the changes that produce the largest INP improvement for the least development effort.
Third-party scripts are the #1 cause of poor INP scores. Every chat widget, ad network script, social media embed, A/B testing tool, and marketing analytics pixel adds JavaScript that competes with your site’s own code for the browser’s main thread.
- 5. Identify your third-party scripts: In Chrome DevTools, open the Network tab and filter by "Third-party." Note every external domain loading scripts on your page.
- 6. Measure their impact: Run PageSpeed Insights and scroll to "Third-Party Code" in the diagnostics. It lists each script with its blocking time.
- 7. Remove what you do not use: Be ruthless. If you have not used a tool in 30 days, remove its script from your site. Unused scripts still load and block your page.
-
8. Defer what you must keep: Add the defer attribute to non-essential scripts. Example:
<script src="analytics.js" defer></script>. This loads the script after the HTML is parsed, preventing render-blocking. - 9. Load chat widgets on interaction: Most live chat scripts load immediately. Instead, load them only when a user clicks a "Chat" button (interaction-based loading). This eliminates the INP impact for 95% of visitors who never use the chat.
Any JavaScript task that runs for more than 50ms on the main thread blocks the browser from responding to user interactions during that time. These “Long Tasks” are the structural cause of high INP scores.
- Find Long Tasks: Chrome DevTools > Performance tab > Record while interacting with your page > Look for red-topped tasks in the flame chart. Tasks over 50ms are flagged as Long Tasks.
- Use the scheduler API: Break up long tasks by yielding to the main thread. Use scheduler.yield() or setTimeout(0) to pause execution and allow the browser to process user interactions between chunks of work.
- WordPress fix: Install WP Rocket or LiteSpeed Cache and enable "Delay JavaScript" - this defers non-critical JS until after user interaction, dramatically improving INP for most WordPress sites without requiring developer intervention.
Code splitting breaks your JavaScript into smaller chunks that load only when needed – rather than loading a massive single bundle on page load. This reduces the amount of JavaScript the browser needs to parse and execute before the page becomes interactive.
- React / Next.js: Use dynamic imports: import('./Component') to load components only when they are needed. Next.js does code splitting automatically.
- WordPress: Use WP Rocket's "Remove Unused CSS" and "Delay JavaScript Execution" features. These defer or remove JavaScript that is not needed on the initial page load.
- Audit JavaScript coverage: Chrome DevTools > Coverage tab (Cmd/Ctrl + Shift + P > "Show Coverage") shows how much of your JavaScript is unused. Anything over 50% unused is a strong candidate for code splitting or removal.
CLS (Cumulative Layout Shift): What It Is and How to Fix It
CLS measures how much the visible content of your page moves unexpectedly during loading – every time an image loads without reserved dimensions, a font swaps in and pushes text down, or an ad injects above existing content, your CLS score increases. A CLS above 0.1 is one of the most user-visible performance problems on any site, because the visitor experiences it as content physically jumping away from where they were reading or clicking.
How CLS Is Calculated
CLS is calculated as the sum of all individual layout shift scores, where each score is the fraction of the viewport area affected by the shift multiplied by the distance the shifting element moves. A 0.1 CLS means an element shifted in a way that affected 10% of the screen area or moved 10% of the screen height.
Only unexpected shifts count. If a user clicks a button that expands an accordion, that shift does not count toward CLS because it was triggered by user interaction. CLS only measures shifts that happen without user initiation – like an image loading in and pushing text down, or a font swap causing reflowed text.
The Most Common CLS Problems and Their Fixes
The majority of CLS failures are caused by elements that load after the initial page render and push existing content out of position. Each fix below eliminates a specific shift source – apply them in order of impact, starting with images and embeds, which account for the largest share of CLS failures across all website types.
This is the single highest-impact CLS fix for most websites. Without dimensions, the browser cannot reserve space for an image before it loads – so when the image loads, it pushes all content below it down, causing a layout shift.
Font flashing occurs when a browser renders a page with a fallback font (causing text to appear), then swaps to the custom web font when it loads (causing text to reflow). This swap causes a layout shift that contributes to CLS.
Every ad slot, social media embed, cookie banner, or notification bar that appears after the page loads can cause massive layout shifts if space is not pre-reserved. The fix is simple: tell the browser how much space the element will occupy before it loads.
The Best Tools to Measure Core Web Vitals in 2026
Use a combination of field data tools (for Google ranking accuracy) and lab data tools (for diagnosis and development). Always validate fixes using field data tools before considering the work done.
Core Web Vitals Fixes for WordPress (Without a Developer)
WordPress powers 43% of all websites – and it has specific challenges and solutions for Core Web Vitals. The good news: most WordPress CWV issues can be fixed with the right plugins, without writing any code.
30-Day Core Web Vitals Improvement Plan
This plan is structured so the highest-impact fixes come first – LCP improvements in week one produce ranking-visible results faster than CLS or INP fixes, and they are typically achievable without developer involvement. Work through each week in sequence rather than tackling all three metrics simultaneously, which makes it harder to attribute score changes to specific actions.
Core Web Vitals 20-Point Checklist (2026)
Run this checklist against your PageSpeed Insights field data report – not lab data – before considering your CWV work complete on any page. Field data reflects real user experience across all devices and connection speeds, which is exactly what Google’s ranking algorithm uses. Lab scores can pass while field scores fail, and it is the field data that determines your ranking outcome.
Frequently Asked Questions About Core Web Vitals
(Structured for FAQPage schema – add via Rank Math or AIOSEO in WordPress)
