8 min read
SEO Fundamentals
What Are Core Web Vitals? Google's Page Experience Metrics Explained (2026)
Core Web Vitals are three Google metrics that measure real-world page experience: LCP, CLS, and INP. Here's what each one means and how it affects rankings.
Team 7 Seers
What Are Core Web Vitals? Google's Page Experience Metrics Explained (2026)
What are Core Web Vitals?
Core Web Vitals are a subset of Web Vitals, an initiative Google launched in 2020 to give site owners a common, simplified set of performance metrics that map directly to user experience. The "Core" Web Vitals are the three metrics Google considers most important for every page on the web, and they are the ones used as ranking signals.
The current three Core Web Vitals are:
Largest Contentful Paint (LCP): how fast the main content loads
Cumulative Layout Shift (CLS): how stable the layout is during loading
Interaction to Next Paint (INP): how quickly the page responds to user input
Each one targets a specific dimension of user experience. LCP is about loading. CLS is about visual stability. INP is about interactivity. A page that does well on all three feels fast, stable, and responsive to real users, which is exactly what Google wants to surface in search results.
Why Core Web Vitals matter for SEO
Google rolled Core Web Vitals into its ranking algorithm as part of the Page Experience update in mid-2021. They have been a confirmed ranking signal ever since. In March 2024, Google replaced the original responsiveness metric (FID, First Input Delay) with the more comprehensive INP, which is the version that has applied throughout 2024, 2025, and into 2026.
Three things to understand about CWV as a ranking factor:
The impact is real but modest. Google has consistently described CWV as a tiebreaker, not a primary ranker. If two pages have similar relevance and content quality, the one with better CWV wins.
Field data is what counts, not lab data. Google measures CWV from real Chrome users via the Chrome User Experience Report (CrUX) dataset. A page only gets the boost when at least 75% of real visits pass the threshold.
The indirect effects are bigger than the direct ones. Faster pages get more conversions, lower bounce rates, more shares, and more backlinks. Those second-order effects often outweigh the direct ranking signal.
What "passing" means
A page passes Core Web Vitals when the 75th percentile of real user visits hits "Good" on all three metrics, measured separately for mobile and desktop over a rolling 28-day window.
The three metrics at a glance
Before going deep on each one, here is the cheat sheet you can refer back to.
Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
LCP | Loading speed of main content | ≤ 2.5s | 2.5s to 4.0s | > 4.0s |
CLS | Visual stability during load | ≤ 0.1 | 0.1 to 0.25 | > 0.25 |
INP | Responsiveness to user input | ≤ 200ms | 200ms to 500ms | > 500ms |
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest content element visible in the user's viewport to render. That element is usually a hero image, a featured product photo, a large block of headline text, or a video poster. The clock starts when the page begins loading and stops when that largest element is fully painted on screen.
LCP thresholds
Good: 2.5 seconds or less
Needs improvement: 2.5 to 4.0 seconds
Poor: over 4.0 seconds
What causes slow LCP
Slow server response time (TTFB). If your server takes 1.5 seconds to send the first byte, you have already burned over half your LCP budget before any rendering begins.
Render-blocking resources. Large CSS files or synchronous JavaScript in the <head> delay the browser from painting anything until they finish loading.
Large unoptimized images. A 4 MB hero image on a mobile connection is the single most common LCP killer.
Lazy-loading the LCP image. Loading="lazy" on the hero image is a frequent mistake. Lazy-loaded LCP images can take 1 to 2 extra seconds to start downloading.
Slow third-party scripts. Tag managers, chat widgets, and analytics that run on the main thread block paint events.
Slow CDN or no CDN at all. Geographic distance to your origin server adds latency to every request.
How to fix LCP
Optimize your hero image. Convert to WebP or AVIF, serve responsive sizes via srcset, and compress aggressively. Aim for under 200 KB on mobile.
Preload the LCP image. Add <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> in your <head> so the browser starts the download immediately.
Use fetchpriority="high" on the LCP <img> tag itself.
Never lazy-load above-the-fold images. Reserve loading="lazy" for images below the fold.
Defer non-critical JS using async or defer attributes, or load it after the main content paints.
Inline critical CSS for above-the-fold content, defer the rest.
Use a CDN to serve assets from a server geographically close to each visitor.
Improve TTFB. Use server-side caching, reduce database query times, and consider edge rendering.
The 70/30 rule of LCP
For most sites, around 70% of LCP issues come from the image itself (size, format, lazy-loading, late discovery) and 30% from server and render-blocking factors. Start with your hero image.
CLS: Cumulative Layout Shift
CLS measures how much the visible page content moves around unexpectedly during loading. Every time an element shifts position because something new loaded above or beside it, that counts as a layout shift. CLS scores the total impact of all unexpected shifts across the entire page lifecycle.
The score is unitless. A score of 0 means nothing shifted. A score of 0.5 means a substantial chunk of the viewport jumped around. CLS is the metric most directly tied to the frustrating experience of trying to tap a button and accidentally tapping an ad that just loaded into the same spot.
CLS thresholds
Good: 0.1 or less
Needs improvement: 0.1 to 0.25
Poor: over 0.25
What causes layout shifts
Images without width and height attributes. The browser does not know how much vertical space to reserve, so when the image arrives it pushes everything else down.
Ads, embeds, and iframes loading late. Ad slots that have no reserved height jolt the page when filled.
Web fonts swapping in. When a custom font loads after a fallback, character widths often change, causing text to reflow.
Dynamically injected content. Banners, cookie notices, or "subscribe" popups inserted at the top of the DOM push everything below them down.
Animations that affect layout. Animating width, height, top, or margin triggers reflow. Animating transform and opacity does not.
Async resources changing dimensions. A YouTube embed that sizes itself after loading.
How to fix CLS
Always set width and height on every <img> and <video>. The browser uses these to compute the aspect-ratio and reserve space before the asset loads.
Reserve space for ads and embeds. Use min-height or fixed-aspect-ratio containers so slots do not collapse when empty.
Preload web fonts with <link rel="preload" as="font" crossorigin> and use font-display: optional or swap with carefully matched fallback metrics.
Use the size-adjust, ascent-override, and descent-override font descriptors to make fallback fonts match the dimensions of your custom fonts.
Avoid inserting content above existing content unless triggered by a user interaction (interactions within 500ms are excluded from CLS).
Use CSS transforms for animations instead of top/left/width/height.
Test with throttled network conditions in DevTools to surface shifts that only appear on slow connections.
INP: Interaction to Next Paint
INP measures how quickly your page responds to user interactions, meaning clicks, taps, and key presses. Specifically, it measures the latency from the moment a user interacts with the page to the moment the next visual update appears on screen. INP looks at all interactions across a page session and reports a value representing the worst (or near-worst) interaction.
INP became a Core Web Vital on March 12, 2024, replacing the older First Input Delay (FID) metric. The reason for the swap: FID only measured the input delay of the very first interaction, ignoring everything that came after. INP measures the full interaction-to-paint latency of all interactions, which is much closer to how users actually perceive responsiveness.
INP thresholds
Good: 200 milliseconds or less
Needs improvement: 200 to 500 milliseconds
Poor: over 500 milliseconds
What causes high INP
Heavy JavaScript on the main thread. Long tasks (over 50ms) block the browser from responding to input.
Large event handlers. A click handler that runs 300ms of JavaScript before yielding will produce a 300ms INP score on every click.
Third-party scripts. Heavy tag managers, A/B testing tools, and analytics often run synchronous work during interactions.
Excessive DOM size. Pages with thousands of DOM nodes are slower to update because the browser has more layout and paint work to do.
Heavy framework hydration. Single-page-app frameworks doing hydration or re-rendering on interaction can produce long tasks.
Synchronous storage access. Reading large amounts of data from localStorage or IndexedDB on the main thread during input handling.
How to fix INP
Break up long tasks. Split work into chunks under 50ms, yielding to the main thread between chunks using setTimeout, scheduler.yield(), or requestIdleCallback.
Use the new scheduler.postTask API to prioritize input handling over background work.
Defer non-essential work to after the next paint using requestAnimationFrame followed by setTimeout, so the visual response happens before the heavy logic.
Move heavy computation to Web Workers. Workers run on a separate thread and never block input handling.
Audit third-party scripts. Replace or remove ones that contribute to INP. Use Chrome DevTools Performance panel to identify culprits.
Reduce DOM size. Aim for under 1,500 nodes per page. Use virtualization for long lists.
Debounce and throttle expensive event handlers like scroll, resize, and input.
Use CSS for visual feedback, not JavaScript, where possible. CSS-driven hover and active states do not add to INP.
INP is the hardest CWV to fix
Most sites that fail Core Web Vitals fail on INP, not LCP or CLS. Heavy JavaScript frameworks and accumulated third-party scripts make INP a persistent challenge. Plan for it deliberately.
Other Web Vitals you should know
Beyond the three Core Web Vitals, Google publishes additional Web Vitals that are useful for diagnosis even though they are not direct ranking factors. Two stand out.
TTFB (Time to First Byte)
TTFB measures the time between the browser requesting a page and receiving the first byte back from the server. It captures DNS lookup, TLS handshake, server processing time, and network latency. TTFB is the foundation of LCP: a slow TTFB makes a fast LCP almost impossible.
Good: 800ms or less
Needs improvement: 800ms to 1800ms
Poor: over 1800ms
How to improve TTFB: use a CDN, enable caching, optimize backend code and database queries, and choose hosting close to your audience.
FCP (First Contentful Paint)
FCP measures when the first piece of content (text, image, SVG, canvas) is painted to the screen. It marks the moment the user knows the page is loading, even if the main content is not ready yet. FCP is a useful diagnostic for LCP: if FCP is slow, LCP will almost always be slow too.
Good: 1.8 seconds or less
Needs improvement: 1.8 to 3.0 seconds
Poor: over 3.0 seconds
How to measure Core Web Vitals
You have several free tools, each with different strengths. Use a combination, do not rely on just one.
1. PageSpeed Insights
The fastest way to test a single URL. Visit pagespeed.web.dev, paste a URL, and get both lab data (Lighthouse) and field data (CrUX) in one report. Field data is shown at the top, broken into mobile and desktop. This is the closest you will get to seeing what Google sees.
2. Google Search Console: Core Web Vitals report
For site-wide field data, open Search Console and go to Experience > Core Web Vitals. The report groups your pages into Good, Needs Improvement, and Poor for both mobile and desktop, and lets you drill into specific URL groups. This is what Google uses for ranking purposes, so it is the most important report to monitor.
3. Lighthouse (Chrome DevTools)
For lab-based debugging, open Chrome DevTools (F12), go to the Lighthouse tab, choose Mobile and Performance, and run an audit. Lighthouse simulates a mid-range device on a slow 4G connection and gives you actionable optimization recommendations. Great for development, less useful for measuring actual user experience.
4. Chrome DevTools Performance panel
For deep diagnosis of INP and CLS, the Performance panel records every frame and layout shift in real time. You can see exactly which scripts are blocking the main thread and which elements are shifting. This is the tool engineers use to fix specific problems after Lighthouse identifies them.
5. CrUX (Chrome User Experience Report)
The raw, public dataset that powers PageSpeed Insights and Search Console. You can query it directly via the CrUX API, the CrUX BigQuery dataset, or the CrUX Dashboard in Looker Studio. Useful for tracking trends over time across multiple URLs at once.
6. web-vitals JavaScript library
For real user monitoring on your own site, the open-source web-vitals library from Google lets you collect LCP, CLS, and INP directly from your visitors and send the data to your analytics. Many analytics platforms (Google Analytics 4, Cloudflare, Vercel Analytics, SpeedCurve) integrate this automatically.
Field data vs lab data: why they disagree
One of the most confusing things about Core Web Vitals is when PageSpeed Insights shows green field data but red lab data, or the reverse. Understanding the difference is essential.
Lab data | Field data | |
|---|---|---|
Source | Lighthouse simulation | Real Chrome users (CrUX) |
Device | Single emulated mid-range phone | Every device that visits your site |
Network | Throttled simulated 4G | Whatever the user is actually on |
Sample size | One run per audit | Aggregated over 28 days |
Includes INP | No (lab cannot simulate user input well) | Yes |
Used for ranking | No | Yes |
The takeaway: field data is the truth. Lab data is a useful debugging tool, but it does not affect rankings. If your field data is green, you are passing CWV regardless of what Lighthouse says. If your field data is red, fixing it requires understanding what real users on real devices are experiencing, not just what Lighthouse simulates.
New site? You may not have field data yet
CrUX requires a minimum amount of traffic before it reports data for your URLs. New or low-traffic sites often see "Insufficient data" in PageSpeed Insights field data section. In that case, lab data is your only option until traffic grows.
If You Have a Framer Site
Framer was built with performance as a first-class concern, and many of the Core Web Vitals best practices are handled for you out of the box. Images uploaded to Framer are automatically converted to WebP, served from Framer's global CDN, and resized into responsive variants for each viewport. Below-the-fold images are lazy-loaded by default. Width and height attributes are set automatically, which protects your CLS score. Framer's runtime is also lightweight compared to most page builders, which helps INP.
That said, Framer alone does not guarantee green Core Web Vitals. The most common culprits on Framer sites are:
Heavy hero videos or 4K images placed above the fold, which inflate LCP and increase data usage.
Complex on-load animations that delay paint and visual stability.
Embedded third-party widgets (chat tools, calendars, marketing scripts) that block the main thread and damage INP.
Custom code components that ship more JavaScript than they need to.
Custom fonts loaded without preloading or proper font-display settings, causing layout shifts when they swap in.
This is exactly where RankFrame helps. RankFrame includes a Page Speed tab built into the Framer editor that pulls live Lighthouse data and Core Web Vitals metrics for every page on your site, so you can see LCP, CLS, and INP scores without leaving Framer. You get specific, actionable recommendations for the pages that are failing, and you can re-test after each publish to confirm your fixes worked. Combined with RankFrame's site audit (which catches issues like missing image dimensions, oversized images, and render-blocking scripts), it becomes much easier to keep your Framer site in the green on Core Web Vitals over time. Start your 14-day free trial to see your scores inside the Framer editor today.
Frequently asked questions
What are the three Core Web Vitals?
The three Core Web Vitals are Largest Contentful Paint (LCP), which measures loading performance; Cumulative Layout Shift (CLS), which measures visual stability; and Interaction to Next Paint (INP), which measures responsiveness to user input. Each has a defined threshold for Good, Needs Improvement, and Poor.
