Key takeaways
- Core Web Vitals are three metrics: LCP (loading), INP (interactivity), and CLS (visual stability). All three must pass for a page to score "good."
- They are a confirmed Google ranking factor, but act as a tiebreaker between pages with similar content quality.
- INP replaced First Input Delay (FID) in March 2024. It measures all interactions, not just the first one.
- Fix LCP by optimizing your largest above-the-fold element (usually the hero image). Fix INP by reducing JavaScript execution. Fix CLS by setting explicit dimensions on images and ads.
- Use Google Search Console for site-wide field data and PageSpeed Insights for per-page diagnostics.
Core Web Vitals are three performance metrics that Google uses to measure how users experience your web pages. They track how fast the page loads, how quickly it responds when you interact with it, and how stable the layout stays while loading. Together, they form part of Google's page experience ranking signal.
If your Core Web Vitals are poor, your pages load slowly, feel sluggish when users click buttons, and content jumps around on screen. Beyond the SEO impact, that directly hurts bounce rate and conversions. This guide explains what each metric measures, what the passing thresholds are, how to diagnose problems, and how to fix them.
In this guide
What are Core Web Vitals?
Google introduced Core Web Vitals in 2020 as a standardized way to measure real-world user experience on web pages. Instead of tracking hundreds of performance metrics, Google narrowed it down to three that capture the aspects users care about most:
- Largest Contentful Paint (LCP) measures perceived loading speed. How quickly does the main content appear?
- Interaction to Next Paint (INP) measures responsiveness. When a user clicks, taps, or types, how quickly does the page react?
- Cumulative Layout Shift (CLS) measures visual stability. Does the content stay in place or jump around while loading?
Each metric has a threshold for "good," "needs improvement," and "poor." Google evaluates these metrics using real user data from the Chrome User Experience Report (CrUX), which collects anonymous performance data from Chrome users who have opted in. This means the scores reflect what actual visitors experience, not what a testing tool reports in ideal conditions.
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible content element to finish rendering. This is usually the hero image, a large text block, or a video poster image in the viewport when the page first loads.
Thresholds
- Good: 2.5 seconds or less
- Needs improvement: 2.5 to 4.0 seconds
- Poor: more than 4.0 seconds
Common causes of slow LCP
- Unoptimized images. A 2 MB hero image that is not compressed or served in a modern format is the most frequent LCP killer. Use WebP or AVIF, set explicit width and height, and add
fetchpriority="high"to the LCP image. Read the image optimization guide for the full process. - Slow server response time (TTFB). If the server takes more than 600ms to respond, everything downstream is delayed. Use a CDN, enable server-side caching, or upgrade your hosting. For sites on Cloudflare Workers like this one, TTFB is typically under 50ms globally.
- Render-blocking CSS and JavaScript. Large CSS files or synchronous JavaScript in the
<head>block rendering until they finish loading. Inline critical CSS, defer non-critical stylesheets, and adddeferorasyncto script tags. - Web fonts blocking text rendering. If the browser waits for a web font to load before showing text, LCP is delayed. Use
font-display: swapin your@font-facerules and preload critical fonts. - Client-side rendering. SPAs that render content entirely in JavaScript force the browser to download, parse, and execute JavaScript before any content appears. Server-side rendering or static generation solves this.
How to fix LCP
- Identify the LCP element using PageSpeed Insights or Chrome DevTools Performance panel.
- If it is an image: compress it, serve it in WebP, set dimensions, add
fetchpriority="high", and removeloading="lazy"from above-the-fold images. - If it is text: make sure the web font loads quickly (preload it) or use
font-display: swap. - Reduce TTFB by using a CDN and enabling caching.
- Remove or defer render-blocking resources.
INP: Interaction to Next Paint
INP measures how quickly the page responds to user interactions. It replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the delay before the browser started processing the first interaction, INP measures all interactions throughout the entire page lifecycle and reports the worst one (at the 75th percentile).
Thresholds
- Good: 200 milliseconds or less
- Needs improvement: 200 to 500 milliseconds
- Poor: more than 500 milliseconds
Common causes of poor INP
- Heavy JavaScript execution. When a user clicks a button and the main thread is busy executing JavaScript, the browser cannot process the interaction until that script finishes. Long tasks (over 50ms) are the primary cause of poor INP.
- Third-party scripts. Analytics, chat widgets, ad scripts, and social media embeds often run JavaScript on the main thread. Each one adds to the total blocking time.
- Large DOM size. Pages with thousands of DOM elements take longer for the browser to update after an interaction. Complex layouts with deep nesting make this worse.
- Expensive event handlers. Click handlers that trigger layout recalculations, reflows, or synchronous API calls block the main thread and delay the visual update.
How to fix INP
- Use Chrome DevTools Performance panel to record interactions and identify long tasks.
- Break up long JavaScript tasks using
requestIdleCallback,setTimeout, or thescheduler.yield()API. - Defer or lazy-load third-party scripts that are not needed for the initial page interaction.
- Reduce DOM size. Remove unnecessary wrapper elements, simplify nested structures, and virtualize long lists.
- Move expensive computations to Web Workers so they run off the main thread.
CLS: Cumulative Layout Shift
CLS measures how much the visible content shifts unexpectedly while the page is loading. If you have ever started reading a paragraph and then the text jumped down because an ad loaded above it, that is layout shift. CLS quantifies that frustration.
Thresholds
- Good: 0.1 or less
- Needs improvement: 0.1 to 0.25
- Poor: more than 0.25
CLS is calculated differently from the other two metrics. It uses a "session window" approach: layout shifts that happen within 1 second of each other, with a maximum 5-second window, are grouped together. The largest group's total shift score becomes the CLS value.
Common causes of high CLS
- Images without dimensions. When an
<img>tag has nowidthandheightattributes, the browser does not know how much space to reserve. When the image loads, the content below it shifts down. - Ads and embeds without reserved space. Ad containers that change size after the ad loads, or social embeds that expand unexpectedly, push surrounding content around.
- Web fonts causing text reflow. When a fallback font renders first and then the web font loads with different metrics (line height, letter spacing), the text reflows and shifts other elements.
- Dynamically injected content. Banners, cookie notices, or notification bars that push the page content down after initial render cause layout shift.
How to fix CLS
- Always set
widthandheightattributes on images and video elements. The browser uses the aspect ratio to reserve space before the media loads. - Reserve fixed dimensions for ad containers using CSS
min-height. - Use
font-display: swapcombined withsize-adjuston fallback fonts to match the metrics of your web font. Or preload your web font so it arrives before the first paint. - Add new content below the viewport or use CSS
transformanimations instead of changes that affect layout (liketop,margin, orheight). - Use the
containCSS property on elements that should not affect surrounding layout.
How to measure Core Web Vitals
You need both field data (real users) and lab data (testing tools) to understand your Core Web Vitals properly.
Field data tools
- Google Search Console — The Core Web Vitals report groups your URLs by status (good, needs improvement, poor) based on real user data. This is the data Google actually uses for ranking.
- PageSpeed Insights — Shows CrUX field data for individual URLs along with lab data from Lighthouse. The field data section at the top is what matters for SEO.
- CrUX Dashboard — A Google Data Studio dashboard that visualizes CrUX data trends over time for your entire origin.
- web-vitals JavaScript library — The web-vitals library lets you collect Core Web Vitals data from your own visitors and send it to your analytics platform.
Lab data tools
- Chrome DevTools — The Performance panel lets you record page loads and interactions. You can see exactly which elements trigger LCP, which scripts cause long tasks (INP), and which elements shift (CLS).
- Lighthouse — Built into Chrome DevTools and available as a CLI. Runs a simulated page load and reports performance metrics with specific optimization suggestions.
- WebPageTest — Lets you test from different locations and devices. The filmstrip view and waterfall chart help diagnose loading issues.
Start with Google Search Console to see which pages have problems in the real world. Then use lab tools to diagnose the specific cause on those pages.
Field data vs. lab data
Field data and lab data often show different results, and understanding why matters.
Field data comes from real users on real devices with real network connections. A user on a budget Android phone with a 3G connection in rural Nepal will have much worse Core Web Vitals than a developer testing on a MacBook Pro connected to office Wi-Fi. CrUX field data reports the 75th percentile, meaning the score reflects what 75% of your users experience or better.
Lab data comes from tools running under controlled conditions: a specific simulated device, network speed, and location. Lab data is reproducible and useful for debugging, but it does not capture the variety of real user experiences.
When your lab scores are good but field scores are poor, the gap usually comes from:
- Users on slower devices and connections than your test setup
- Third-party scripts that load differently in production than in testing
- Interactions that lab tools do not simulate (INP requires real user interactions)
- Geographic distance from the server (a CDN fixes this)
Always prioritize field data. That is what Google uses for ranking, and it reflects what your actual visitors experience.
Core Web Vitals and SEO
Core Web Vitals became a Google ranking factor in June 2021 as part of the page experience update. However, the SEO impact is often misunderstood.
Google has been clear: Core Web Vitals are a tiebreaker, not a primary ranking signal. Content relevance and other ranking factors like backlinks carry much more weight. A page with excellent content and mediocre vitals will outrank a page with perfect vitals and thin content every time.
That said, there are three scenarios where Core Web Vitals make a real difference:
- Competitive queries. When multiple pages have similar content quality and authority, the page with better vitals gets the edge.
- Top Stories and Discover. Google has indicated that page experience signals carry more weight for these features.
- Indirect impact through user behavior. Pages that load slowly and feel unresponsive have higher bounce rates. Users click back to search results, which sends negative engagement signals. This indirect effect can be larger than the direct ranking signal.
The complete speed optimization guide covers the full process of improving site performance beyond just Core Web Vitals.
What to fix first
If all three metrics are poor, start with LCP. Loading speed has the most direct impact on user experience and bounce rate. A page that takes 6 seconds to show its main content loses users before they even see the content. It is also typically the easiest to fix because the causes (large images, slow servers) are straightforward.
Next, fix CLS. Layout shifts frustrate users and the fixes are usually simple: add image dimensions, reserve ad space, handle font loading. Most CLS problems can be fixed in a single development session.
Fix INP last. Interactivity problems are harder to diagnose and fix because they involve JavaScript profiling and potentially refactoring how your page handles user interactions. The good news is that static content sites with minimal JavaScript rarely have INP issues.
The priority changes if one metric is far worse than the others. If your LCP is already good but CLS is terrible, fix CLS first. Always start with the metric that is furthest from the "good" threshold.
Frequently asked questions
What are the three Core Web Vitals?
The three Core Web Vitals are Largest Contentful Paint (LCP), which measures loading speed by timing how long it takes for the biggest visible element to appear; Interaction to Next Paint (INP), which measures responsiveness by recording how quickly the page reacts to user interactions like clicks, taps, and key presses; and Cumulative Layout Shift (CLS), which measures visual stability by tracking how much the page layout moves around unexpectedly while loading. All three must pass their thresholds for a page to have good Core Web Vitals.
Are Core Web Vitals a Google ranking factor?
Yes. Core Web Vitals are a confirmed Google ranking factor as part of the page experience signals. However, they act as a tiebreaker rather than a primary ranking signal. A page with excellent content and average Core Web Vitals will still outrank a page with perfect vitals but thin content. That said, poor Core Web Vitals hurt user experience directly: slow pages have higher bounce rates and lower conversion rates, which indirectly hurts your SEO performance.
What replaced First Input Delay (FID)?
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the browser started processing the first interaction. INP is a better metric because it measures the responsiveness of all interactions throughout the page lifecycle, not just the first one, and it includes the full duration from input to the next visual update.
How do I check my Core Web Vitals?
Use Google Search Console for field data across your entire site. It groups URLs by status and highlights specific issues. For individual page testing, use PageSpeed Insights, which shows both field data from CrUX and lab data from Lighthouse. Chrome DevTools has a Performance panel for debugging specific issues. For real user monitoring, the web-vitals JavaScript library lets you collect Core Web Vitals data from your actual visitors.
Need help fixing your Core Web Vitals? I offer website optimization services that include Core Web Vitals diagnostics, image optimization, script management, and performance tuning. Or start with a technical SEO audit to identify all performance issues. Get in touch to discuss your project.