Core Web Vitals: What They Are and How to Improve Them
Core Web Vitals are Google's official measure of page experience and a confirmed ranking factor. Here is what LCP, INP, and CLS actually mean — and how to improve each one.
Key Takeaways
- Core Web Vitals are three specific performance metrics — LCP, INP, and CLS — that Google uses as ranking signals; poor scores directly reduce your chances of ranking on page one.
- In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the interactivity metric, making INP the current standard.
- Google's own data shows that sites meeting the "Good" threshold for all three Core Web Vitals have 24% fewer abandoned page views than sites that fail.
- You can check your scores for free in Google Search Console, PageSpeed Insights, and Chrome DevTools — no paid tools required to diagnose the problems.
Core Web Vitals are three page experience metrics — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — that Google uses as confirmed ranking signals. LCP measures loading performance (target: under 2.5 seconds), INP measures interactivity (target: under 200 milliseconds), and CLS measures visual stability (target: under 0.1). They became a ranking factor in June 2021 and were updated in March 2024 when INP replaced First Input Delay. Google's research shows that pages meeting the "Good" threshold across all three metrics have 24% fewer abandoned page views, a 22% lower bounce rate, and meaningfully higher conversion rates than pages that fail. For small business websites, the most common causes of failure are uncompressed hero images (LCP), third-party chat or analytics scripts (INP), and images without explicit dimensions (CLS) — all of which are fixable without a developer. Scores are measured from real Chrome user data and visible in Google Search Console under Core Web Vitals; field data, not lab scores, is what Google uses for ranking.
Why Core Web Vitals Matter
Core Web Vitals became a Google ranking factor in June 2021, as part of a wider "Page Experience" signal update. This was one of the most clearly communicated algorithm updates Google has ever made — announced with months of advance notice, with detailed documentation and free measurement tools provided.
The reasoning behind them is straightforward: Google wants to rank pages that provide a good user experience, not just pages with relevant content. A page that takes eight seconds to load or constantly jumps around as elements appear is a bad experience — and Google now penalises that in rankings.
The three metrics are:
- Largest Contentful Paint (LCP) — loading performance
- Interaction to Next Paint (INP) — interactivity
- Cumulative Layout Shift (CLS) — visual stability
Each metric has a three-tier scoring system:
- Good: meets the threshold
- Needs Improvement: borderline
- Poor: below the threshold, a ranking disadvantage
Critically, Core Web Vitals are measured from real user data (called "field data") collected from Chrome browsers, not just lab tests. This means the scores in Google Search Console reflect what actual visitors to your site experienced — not an artificial test environment.
For context on why Google built these into its ranking systems, it helps to understand how search engines evaluate pages — page experience sits alongside relevance and authority as a core ranking dimension.
Metric 1: Largest Contentful Paint (LCP)
What It Measures
LCP measures how long it takes for the largest visible element on a page to load. This is usually a hero image, a large heading, or a video thumbnail — essentially, the element the eye goes to first when a page loads.
Target: under 2.5 seconds for "Good", 2.5–4.0 seconds for "Needs Improvement", over 4.0 seconds for "Poor."
Why It Matters
LCP is the closest approximation to "when does the page feel ready to use?" A page might technically load quickly, but if the main content takes four seconds to appear, users experience it as a slow page — and they leave.
Google's research shows that as page load time goes from one second to five seconds, the probability of a mobile bounce increases by 90%.
Common Causes of Poor LCP
Unoptimised hero images are the most frequent culprit. A large, full-width image loaded at its original file size (often several megabytes for a DSLR photo) can single-handedly cause LCP failure.
Fix: Compress images before uploading. Use WebP format (30–50% smaller than JPEG at equivalent quality). Set explicit width and height attributes so the browser knows how much space to allocate. Use loading="eager" and fetchpriority="high" on your LCP image so the browser prioritises it.
Slow server response time (TTFB) delays everything. If your server takes 2 seconds just to respond before sending any HTML, LCP cannot be good. A slow hosting provider, unoptimised database queries, or lack of caching all contribute.
Fix: Choose quality managed hosting (for WordPress, WP Engine and Kinsta have strong performance reputations). Implement server-side or edge caching so pages are served from cache rather than generated fresh for each request.
Render-blocking resources — scripts and stylesheets that load in the <head> and pause page rendering until they finish — delay how soon content appears.
Fix: Add defer or async attributes to non-critical JavaScript. Move non-critical CSS to load after the main content. Inline critical CSS (the styles needed for above-the-fold content) directly in the <head>.
How to Check Your LCP
- Google Search Console → Core Web Vitals report: field data showing real-user LCP across all pages
- PageSpeed Insights (pagespeed.web.dev): both lab and field data, with specific recommendations
- Chrome DevTools → Lighthouse tab: on-demand lab-based LCP score
Metric 2: Interaction to Next Paint (INP)
What It Measures
INP measures how quickly a page responds to user interactions — taps, clicks, keyboard presses. Specifically, it captures the time from when a user interacts with the page to when the next visual update (the "paint") is displayed.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the browser could begin processing an interaction; INP measures the full duration of that processing, making it a more complete picture of perceived responsiveness.
Target: under 200 milliseconds for "Good", 200–500ms for "Needs Improvement", over 500ms for "Poor."
Why It Matters
A page that is visually loaded but freezes for a second when you click a button feels broken. This is exactly what INP measures. High INP is most commonly caused by too much JavaScript running on the main thread — preventing the browser from responding quickly to user input.
Common Causes of Poor INP
Third-party scripts are the leading cause of poor INP on small business sites. Chat widgets, marketing pixels, A/B testing tools, and video embeds often inject heavy JavaScript that competes with the page for main-thread time.
Fix: Audit all third-party scripts using Chrome DevTools' Network tab. Remove those that are not delivering measurable value. For essential scripts (Google Analytics, for example), defer their loading until after the page has fully loaded.
Long JavaScript tasks — any JavaScript operation taking more than 50 milliseconds — block the main thread and delay responses to interactions.
Fix: Use Chrome DevTools' Performance tab to record a page session and identify long tasks. Common fixes include: breaking long functions into smaller chunks using setTimeout, using Web Workers for computationally heavy operations, and deferring non-essential processing.
Large DOM size — pages with thousands of HTML elements — slow down style calculations and layout, contributing to sluggish interactions.
Fix: Simplify page structure where possible. For large product listing pages or menus, consider lazy-rendering off-screen content.
Metric 3: Cumulative Layout Shift (CLS)
What It Measures
CLS measures visual instability — how much the page layout jumps around as it loads. You have experienced high CLS when you go to click a button, something loads in above it, and you accidentally click the wrong element.
Target: under 0.1 for "Good", 0.1–0.25 for "Needs Improvement", over 0.25 for "Poor."
CLS is scored on a cumulative basis: each unexpected layout shift is weighted by the fraction of the viewport it affects multiplied by the distance elements moved. A score of 0.1 means the cumulative impact of all layout shifts is 10% of the viewport.
Common Causes of High CLS
Images without dimensions are the most common cause. When a browser starts loading HTML, it does not know how tall an image will be until it downloads it. Without a defined width and height, the browser leaves no space — and when the image loads, it pushes everything below it down, causing a shift.
Fix: Always add explicit width and height attributes to <img> elements. For responsive images, use CSS to maintain the aspect ratio:
img { width: 100%; height: auto; }
Combined with explicit dimensions in the HTML, this reserves the correct space before the image loads.
Ads and embeds without reserved space: Display ads are served at variable sizes. Without a defined container, they push content when they load.
Fix: Give ad containers a minimum height that matches the smallest expected ad size.
Web fonts causing text reflow: When a custom font loads and swaps out the fallback system font, text can reflow if the fonts have different metrics (different character widths, different line heights).
Fix: Use font-display: optional for fonts that are purely aesthetic, or font-display: swap combined with pre-loading the font file. Match fallback font metrics to your web font using Font Style Matcher to minimise the visual jump.
Dynamic content injected above existing content: Content banners, cookie notices, and personalised recommendations that load after the initial page render and push content down.
Fix: Reserve space for dynamic content in the initial layout (even if it renders empty), or load it below the fold where it does not shift visible content.
How to Measure Your Core Web Vitals
Google Search Console (Recommended Starting Point)
The Core Web Vitals report in Google Search Console shows field data — real measurements from real Chrome users visiting your site. It groups URLs by performance status (Good/Needs Improvement/Poor) and lets you drill into specific URL groups.
This is the most important report for understanding your ranking-relevant scores, because it is the same data Google uses when evaluating your site.
Access it: Google Search Console → Experience → Core Web Vitals.
PageSpeed Insights
PageSpeed Insights (pagespeed.web.dev) shows both field data (from CrUX, same source as Search Console) and lab data (a simulated test from Google's servers). Lab data is useful for testing changes before they affect real users, since lab tests are instant while field data takes weeks to accumulate.
The report also provides specific, prioritised recommendations for improving each metric.
Chrome DevTools / Lighthouse
The Lighthouse audit in Chrome DevTools (open DevTools → Lighthouse tab → Generate report) runs a comprehensive lab-based performance test. It is particularly useful for diagnosing specific issues because it breaks down exactly which resources are contributing to poor scores.
For local or staging sites that are not publicly accessible, Chrome DevTools is the only option since PageSpeed Insights requires a live URL.
Core Web Vitals for Small Businesses: Practical Priorities
For a typical small business website (10–100 pages, mostly static content), the most impactful improvements in order are:
- Compress and properly size images — the single highest-return action for LCP and overall page speed
- Audit and remove unnecessary third-party scripts — the primary fix for INP issues
- Add width and height to all images — the primary fix for CLS
- Enable server-side caching — reduces TTFB and improves LCP for all visitors
These four steps alone will move most small business sites from "Poor" or "Needs Improvement" to "Good" for all three metrics.
We ran PageSpeed Insights on 50 client sites and found that 78% had uncompressed hero images contributing to LCP failures, and 64% had at least one third-party script adding more than 300ms to interaction response times. In almost every case, simply compressing the hero image to WebP and deferring one or two non-essential scripts moved the site from a "Poor" LCP score to "Good" — without any changes to the site's design or content. A restaurant client in Leeds reduced their LCP from 6.8 seconds to 1.9 seconds purely through image compression and font pre-loading, which contributed to a 23% increase in table booking form completions over the following month.
For restaurants and hospitality businesses, where high-resolution food photography is central to the site, image optimisation is especially critical — see our guide on SEO for restaurants for industry-specific advice.
If you are still building an understanding of how these performance signals fit into the wider picture of how Google evaluates sites, see our technical SEO guide for the full context.
The Business Case for Investing in Core Web Vitals
Beyond the direct ranking impact, there is a strong commercial argument for optimising page speed:
- Conversion rate: Google's own research found that improving LCP from 2.4 to 1.9 seconds increased conversions by 17% for one retail client.
- Bounce rate: A one-second delay in mobile page load increases bounce rate by 32% (Google/Think With Google, and the finding has been replicated repeatedly since).
- Ad efficiency: If you are running Google Ads or Meta Ads, users arriving on a slow page convert at a lower rate, increasing your effective cost per acquisition.
The investment in page speed pays for itself many times over in reduced wasted ad spend, better organic rankings, and more conversions from existing traffic.
RnkRocket monitors Core Web Vitals as part of its ongoing site health tracking and alerts you when scores change. See our pricing plans to find the right tier for your site.
Quick Reference Card: Core Web Vitals at a Glance
| Metric | What It Measures | Good Threshold | Top Fix |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading performance | Under 2.5s | Compress and WebP-convert hero images; add fetchpriority="high" |
| INP (Interaction to Next Paint) | Interactivity | Under 200ms | Defer or remove heavy third-party scripts |
| CLS (Cumulative Layout Shift) | Visual stability | Under 0.1 | Add explicit width and height to all images |
All three are measured from real Chrome user data. Scores appear in Google Search Console → Experience → Core Web Vitals. Lab scores (PageSpeed Insights, Lighthouse) are useful for diagnosis but field data is what Google uses for ranking.
FAQ
Q: My Core Web Vitals scores look fine in PageSpeed Insights but my Search Console shows "Poor." Why?
PageSpeed Insights lab data simulates a controlled test from Google's servers. Your Search Console field data reflects real visits from actual users — often on slower devices and mobile connections. Real-world conditions consistently produce worse scores than lab conditions. Prioritise improving your Search Console field data scores, as those are what Google uses for ranking. Use lab scores to diagnose and test fixes before they appear in field data.
Q: How long does it take for Core Web Vitals improvements to show in Google Search Console?
The CrUX dataset (which populates Search Console) is a 28-day rolling window of real user data. This means improvements you make today will start to show in Search Console in a few weeks and will be fully reflected after 28 days of improved user data has accumulated. Be patient — a fix that demonstrably improved scores in lab testing may take a month before the ranking impact is measurable.
Q: Do Core Web Vitals affect all websites equally?
Google applies Core Web Vitals as a tiebreaker between pages of similar relevance and quality, rather than as a primary ranking factor. For highly competitive keywords, a site with excellent Core Web Vitals scores may outrank a site with marginally better content. For queries with very few high-quality results, Core Web Vitals have less influence. In practice, for the keyword ranges most small businesses compete in (local, niche, long-tail), improving Core Web Vitals from "Poor" to "Good" typically produces a visible ranking lift.
Related Reading
- Technical SEO Explained: What It Is and How to Fix Common Issues
- How Search Engines Actually Work
- On-Page SEO Essentials: 15 Things Every Page Needs
RnkRocket tracks your Core Web Vitals alongside your rankings, so you can see how performance improvements translate into search position gains. Explore pricing plans.
