Core Web Vitals Explained: LCP, CLS, and INP
Core Web Vitals are a set of real-world performance metrics that Google uses to measure user experience on web pages. Introduced in 2020 and incorporated as a ranking signal in 2021, they evaluate how fast a page loads its main content, how stable the visual layout is, and how quickly the page responds to user interactions. Scoring well on these metrics is not just an SEO checkbox — it directly reflects how usable your site is for real visitors.
⠀
Why Google Uses Core Web Vitals as a Ranking Factor
⠀
Google's stated goal is to surface not just relevant content, but content delivered through a good user experience. Slow, unstable, or unresponsive pages drive visitors away — and Google can measure this at scale through data from Chrome users in the real world. A page that loads in 4 seconds loses a significant percentage of users before they read a word.
The Core Web Vitals ranking signal is part of a broader set of Page Experience signals that also includes mobile-friendliness and HTTPS. For most competitive queries, content quality and relevance remain the dominant ranking factors. But at parity, Core Web Vitals performance can be a meaningful differentiator — and for sites at the margin, failing thresholds can suppress rankings noticeably.
⠀
LCP — Largest Contentful Paint
⠀
Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element on the page to render in the viewport. This is typically a hero image, a featured photo, or a large block of text. LCP is the closest proxy Google has for "when does the page actually look loaded to the user."
LCP Thresholds
⠀
Score | LCP Time
Score: Good | LCP Time: 2.5 seconds or less
Score: Needs Improvement | LCP Time: 2.5 to 4.0 seconds
Score: Poor | LCP Time: More than 4.0 seconds
⠀
Common LCP Causes and Fixes
⠀
The most frequent LCP failures come from slow server response times, render-blocking resources, and unoptimized images. Specific issues and their solutions include:
Large, uncompressed hero images — compress images with WebP or AVIF format, and use the srcset attribute to serve appropriately sized images per device
No priority hints on the LCP image — add fetchpriority="high" to the <img> tag of your LCP element so the browser downloads it immediately rather than treating it equally with other resources
Render-blocking JavaScript or CSS — move non-critical scripts to the bottom of the page or mark them defer; inline critical CSS to avoid a render-blocking stylesheet request
Slow server or TTFB (Time to First Byte) — a slow first byte delays everything. Use a CDN, optimize server-side processing, and enable caching at the server level
Lazy-loading applied to the LCP image — never apply loading="lazy" to your hero image. Lazy-loading defers the most important image on the page, which almost always destroys LCP scores
⠀
⠀
CLS — Cumulative Layout Shift
⠀
Cumulative Layout Shift (CLS) measures the visual stability of a page during loading. A high CLS score means elements are moving around as the page loads — banners pushing content down, images expanding, fonts causing text to reflow — which creates a disorienting and frustrating experience.
CLS Thresholds
⠀
Score | CLS Value
Score: Good | CLS Value: 0.1 or less
Score: Needs Improvement | CLS Value: 0.1 to 0.25
Score: Poor | CLS Value: More than 0.25
⠀
Common CLS Causes
⠀
Images without explicit width and height attributes — when a browser encounters an <img> tag without dimensions, it cannot reserve the right amount of space while the image loads, so the surrounding content shifts when the image appears. Always set explicit width and height on every image.
Dynamic content inserted above existing content — ads, cookie banners, and notification bars that load after the initial render and push page content downward are a leading CLS cause. Reserve space for these elements in the page layout before they load.
Web fonts causing FOUT or FOIT — when a custom font loads and replaces a fallback font, text can reflow if the two fonts have different dimensions. Use font-display: swap and preload your critical fonts to minimize this.
Animations and transitions that affect layout — avoid animations that modify width, height, top, left, or margin properties, as these trigger layout recalculations. Use transform and opacity instead, which are GPU-accelerated and do not cause layout shifts.
⠀
⠀
INP — Interaction to Next Paint
⠀
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID measured only the delay before the browser began processing a user's first interaction, INP measures the full visual response time for all interactions throughout the page session — clicks, taps, and keyboard inputs.
INP captures the worst-case interaction latency (excluding outliers), making it a much more comprehensive measure of interactivity. A page that responds slowly to a user clicking a menu, submitting a form, or expanding an accordion will have a poor INP even if it loads quickly.
INP Thresholds
⠀
Score | INP Time
Score: Good | INP Time: 200 milliseconds or less
Score: Needs Improvement | INP Time: 200 to 500 milliseconds
Score: Poor | INP Time: More than 500 milliseconds
⠀
How to Improve INP
⠀
Reduce JavaScript execution time — long JavaScript tasks block the main thread and delay the browser's ability to respond to user input. Break up long tasks using setTimeout or the Scheduler API, and audit third-party scripts that run on interaction.
Minimize DOM size — a very large DOM slows down all rendering operations. Keep your DOM lean; unnecessary elements add rendering cost to every interaction.
Defer non-critical third-party scripts — analytics, chat widgets, and advertising scripts are common INP culprits. Load them after the page's critical interactions are established.
Optimize event handlers — inefficient event listener code that runs on click or keypress contributes directly to INP. Profile your handlers with Chrome DevTools and refactor anything that takes more than a few milliseconds to execute.
⠀
⠀
Field Data vs. Lab Data
⠀
This distinction matters enormously when interpreting Core Web Vitals results.
Field data (also called real-user monitoring or RUM) comes from real Chrome users visiting your site. Google collects this through the Chrome User Experience Report (CrUX) and uses it as the basis for Core Web Vitals ranking signals. If your site does not have enough traffic to populate CrUX data (typically a minimum of several hundred visits per URL per month), it will not have Core Web Vitals scores in Search Console.
Lab data is collected by simulating a page load in a controlled environment using tools like Lighthouse. Lab data is deterministic and reproducible, making it excellent for debugging — but it does not represent how real users on real devices and networks experience your pages. Lab scores and field scores can differ significantly.
When optimizing for rankings, prioritize improving your field data scores. Use lab data to identify specific issues, but validate fixes against field data before concluding that a problem is resolved.
⠀
Tools to Measure Core Web Vitals
⠀
PageSpeed Insights
⠀
PageSpeed Insights shows both field data (from CrUX) and lab data (from Lighthouse) for a single URL. It is the fastest way to get a top-level view of your Core Web Vitals status and pinpoint specific elements failing each metric.
Google Search Console — Core Web Vitals Report
⠀
Search Console's Core Web Vitals report aggregates field data across all URLs on your site, grouping URLs by status (Good / Needs Improvement / Poor). It identifies which URLs have issues and groups similar URLs together to make bulk fixes more tractable. This is the authoritative view of your site's Core Web Vitals standing from Google's perspective.
Chrome DevTools
⠀
Chrome DevTools provides the most granular diagnostic environment for Core Web Vitals debugging. The Performance panel records a page load timeline with LCP and CLS markers. The Performance Insights panel provides guided analysis. DevTools is indispensable for identifying which specific resource, script, or element is responsible for a poor score.
Screaming Frog with PageSpeed Insights API
⠀
Screaming Frog can integrate with the PageSpeed Insights API to pull Core Web Vitals data for every URL during a site crawl. This is efficient for large sites where checking URLs individually would be impractical. At Blakfy, we use this approach to prioritize which pages on a client site need the most urgent performance work.
⠀
⠀
FAQ
⠀
Are Core Web Vitals a strong ranking factor?
They are a confirmed ranking factor, but their weight is moderate compared to relevance and content quality. Google has described them as a "tiebreaker" — meaning two pages of similar quality will have their experience signals compared. For most sites, improving content relevance yields larger ranking gains, but failing Core Web Vitals thresholds can suppress pages that would otherwise rank well.
My lab score is good but my field data is poor — why?
Lab tests simulate ideal conditions: a fast machine, a controlled network, no other tabs open. Real users visit on slower devices, variable network connections, and with browser extensions running. If your lab score looks good but CrUX data shows poor performance, the gap often comes from third-party scripts, ads, or layout behavior that only triggers under certain real-world conditions.
Does every URL need a passing Core Web Vitals score?
Google evaluates Core Web Vitals at the URL level but may apply signals at the page group level for URLs without individual CrUX data. Prioritize your highest-traffic and highest-value pages — product pages, landing pages, key blog posts. Improving these has the most impact on both rankings and user experience.
What replaced FID and why?
First Input Delay (FID) was replaced by Interaction to Next Paint (INP) in March 2024. FID only measured the delay before the browser started processing the very first user interaction — it ignored processing time and rendering time, and only captured one interaction. INP measures the complete response time across all interactions throughout the session, making it a far more representative measure of real interactivity.
