Core Web Vitals: What They Are and How to Improve Them
Learn what Core Web Vitals (LCP, CLS, INP) are, why Google uses them for rankings, and how to fix performance issues. Includes benchmarks and optimization techniques.
Google doesn’t just care whether your website exists — it cares how your website feels. Core Web Vitals are the metrics Google uses to measure that experience, and they directly influence your search rankings.
If your site is slow, visually unstable, or unresponsive to clicks, Google knows — and it adjusts your ranking accordingly. Understanding these metrics is the first step to fixing them.
What Are Core Web Vitals?
Core Web Vitals are a set of three specific metrics that Google uses to evaluate the real-world user experience of a web page. They measure loading performance, visual stability, and interactivity — the three dimensions of experience that users notice most.
These metrics are part of Google’s broader “page experience” ranking signals, which also include mobile-friendliness, HTTPS, and the absence of intrusive interstitials. But Core Web Vitals carry the most weight in that group.
The three current Core Web Vitals are LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and INP (Interaction to Next Paint).
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible element on the page to finish loading. This is usually a hero image, a large text block, or a video thumbnail — whatever dominates the viewport when the page first appears.
Benchmarks
- Good: 2.5 seconds or less
- Needs Improvement: 2.5 to 4.0 seconds
- Poor: More than 4.0 seconds
Why It Matters
LCP is the closest proxy to what users perceive as “the page has loaded.” Even if your server responds quickly and the HTML arrives fast, a slow-loading hero image or above-the-fold block makes the page feel sluggish.
Common Causes of Poor LCP
Slow server response time. If your server takes 2 seconds to respond, your LCP can’t be faster than 2 seconds regardless of everything else. Measure your Time to First Byte (TTFB) — it should be under 800ms.
Render-blocking resources. Large CSS and JavaScript files in the <head> prevent the browser from rendering anything until they’re downloaded and parsed. Critical CSS should be inlined, and non-essential scripts should be deferred.
Unoptimized images. The LCP element is often an image. If that image is a 3MB uncompressed PNG, it will dominate your loading time. Use modern formats (WebP or AVIF), serve responsive sizes, and implement proper caching.
Client-side rendering. Single-page applications that render content via JavaScript after the initial HTML loads often have poor LCP because the largest element doesn’t appear until the framework initializes. Consider server-side rendering (SSR) or static generation for critical pages.
How to Fix LCP
Optimize your server response time by using a CDN, enabling caching, and upgrading your hosting if TTFB is consistently high. Preload the LCP image using <link rel="preload"> so the browser starts downloading it immediately. Convert images to WebP format and serve them at the correct dimensions — don’t serve a 2400px image for a 600px container. Inline critical CSS and defer everything else.
CLS: Cumulative Layout Shift
CLS measures visual stability — how much the page layout shifts unexpectedly while it’s loading. If you’ve ever started reading an article and had the text jump down because an ad or image loaded above it, you’ve experienced a layout shift.
Benchmarks
- Good: 0.1 or less
- Needs Improvement: 0.1 to 0.25
- Poor: More than 0.25
Why It Matters
Layout shifts are one of the most frustrating user experiences on the web. They cause misclicks, lost reading position, and a general feeling that the page is unreliable. On mobile, where screens are smaller, even small shifts are disorienting.
Common Causes of Poor CLS
Images without dimensions. If you don’t specify width and height attributes on <img> tags, the browser doesn’t know how much space to reserve until the image loads. When it arrives, everything below it shifts down.
Dynamically injected content. Ads, cookie banners, newsletter popups, and other elements that load after the initial render push existing content around.
Web fonts causing FOIT/FOUT. When a custom font loads and replaces the fallback font, text can reflow because the fonts have different metrics. This causes layout shifts in text-heavy sections.
Embeds and iframes without reserved space. YouTube embeds, social media widgets, and other third-party embeds that don’t have predefined dimensions cause shifts when they load.
How to Fix CLS
Always include explicit width and height attributes on images and video elements. Use CSS aspect-ratio for responsive containers. Reserve space for ads and dynamic content using min-height or placeholder elements. Use font-display: swap with size-adjusted fallback fonts to minimize font-related shifts. Avoid inserting content above existing content unless triggered by user interaction.
INP: Interaction to Next Paint
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. While FID only measured the delay of the first interaction, INP measures the responsiveness of all interactions throughout the page’s lifecycle — clicks, taps, and keyboard inputs.
Benchmarks
- Good: 200 milliseconds or less
- Needs Improvement: 200 to 500 milliseconds
- Poor: More than 500 milliseconds
Why It Matters
INP captures whether the page feels responsive when users interact with it. A page might load quickly (good LCP) and stay stable (good CLS), but if clicking a button takes 400ms to produce a visual response, the page feels broken.
Common Causes of Poor INP
Long JavaScript tasks. Any JavaScript task that runs for more than 50ms blocks the main thread and delays the browser’s ability to process user interactions. Heavy frameworks, complex calculations, and poorly optimized event handlers are common culprits.
Excessive DOM size. Pages with thousands of DOM nodes take longer to update when interactions trigger re-renders. Large DOMs also slow down style calculations and layout operations.
Third-party scripts. Analytics, chat widgets, ad scripts, and social media embeds all compete for main thread time. Each one adds processing overhead that can delay interaction responses.
How to Fix INP
Break long JavaScript tasks into smaller chunks using requestIdleCallback or setTimeout to yield to the main thread. Lazy-load third-party scripts that aren’t needed for the initial interaction. Reduce DOM complexity — flatten nested structures and remove hidden elements. Use content-visibility: auto for off-screen content to skip rendering work. Debounce rapid user inputs to prevent redundant processing.
How to Measure Core Web Vitals
Lab Data vs. Field Data
Lab data comes from controlled testing environments — tools like Lighthouse, Chrome DevTools, and WebPageTest that simulate page loads under specific conditions. Lab data is useful for debugging because it’s reproducible.
Field data comes from real users visiting your site. Google collects this through the Chrome User Experience Report (CrUX), which aggregates anonymous performance data from Chrome users who have opted in to sharing usage statistics.
Google uses field data for ranking purposes. Your Lighthouse score might be 95, but if real users on slow connections in Southeast Asia experience 4-second LCP, that’s what Google sees.
Tools for Measurement
Google PageSpeed Insights shows both lab (Lighthouse) and field (CrUX) data for any URL. It’s the single best starting point for understanding your Core Web Vitals.
Google Search Console has a Core Web Vitals report that shows which URLs on your site pass or fail, grouped by status and metric.
Chrome DevTools Performance tab lets you profile individual page loads and interactions to identify specific bottlenecks.
Web Vitals JavaScript library can be added to your site to measure Core Web Vitals from your own real user monitoring (RUM) setup.
Monitoring tools with Lighthouse integration — platforms like OpsKitty run Lighthouse checks on a schedule, tracking your performance scores, accessibility, and Core Web Vitals over time so you can spot regressions before they impact rankings.
Core Web Vitals and SEO
Google confirmed that Core Web Vitals are a ranking factor, but they’re not the dominant one. Relevant, high-quality content still matters more than page speed. However, when two pages have similar content quality and relevance, Core Web Vitals can be the tiebreaker.
The real impact is often indirect. Poor Core Web Vitals lead to higher bounce rates, shorter session durations, and lower engagement — all behavioral signals that can further affect rankings.
For competitive keywords where many pages have similar content quality, Core Web Vitals become a meaningful competitive advantage. Improving from “poor” to “good” across all three metrics won’t transform your rankings overnight, but it removes a headwind that’s been holding you back.
A Practical Optimization Checklist
Start with the highest-impact fixes first. Use PageSpeed Insights to identify which metric is your weakest, then focus there.
For LCP: Check your TTFB, preload the LCP image, convert to WebP, inline critical CSS, and defer non-essential JavaScript.
For CLS: Add width/height to all images, reserve space for dynamic content, use font-display: swap, and avoid inserting content above the fold after load.
For INP: Profile your JavaScript for long tasks, lazy-load third-party scripts, reduce DOM size, and break heavy operations into smaller chunks.
Measure before and after each change. Core Web Vitals improvements compound — fixing LCP often improves INP because fewer resources compete for the main thread.
Continuous Monitoring Matters
Core Web Vitals aren’t a “fix once” problem. New content, updated plugins, additional scripts, and design changes can all cause regressions. A performance score that’s green today can turn red after a single deployment.
Set up continuous monitoring that tracks your Core Web Vitals over time. Automated Lighthouse checks on a daily or weekly schedule catch regressions within days instead of weeks. Pair this with real user monitoring for the most complete picture.
Track your Core Web Vitals over time with OpsKitty — automated Lighthouse monitoring tracks performance, accessibility, and SEO scores from 29 global regions. Catch regressions before they impact your rankings.