What Are Core Web Vitals and Why Do They Affect Your Google Rankings?
Core Web Vitals are Google's official page experience metrics that directly affect your search rankings. This guide explains what each metric measures, what good scores look like, and exactly how to improve them.
By Josh Ternyak
March 29, 2026
Google's Report Card for Your Website's User Experience
For years, web developers and SEOs understood that page speed mattered for rankings — Google had confirmed it as a ranking signal since 2010. But the signal was vague. "Page speed" could mean dozens of different things, measured in dozens of different ways, and the correlation between any specific speed metric and ranking was difficult to isolate.
In 2020, Google announced Core Web Vitals — a specific set of three metrics, with defined measurement methodology and clear thresholds for Good, Needs Improvement, and Poor. In May 2021, these metrics became official Google ranking factors as part of the Page Experience update. For the first time, there was a specific, public, measurable set of performance criteria that Google was using to assess page experience quality and factor it into rankings.
The announcement created urgency in the web performance community — and confusion in the broader web industry. What exactly do these metrics measure? How much do they actually affect rankings? And what do you actually do to improve them?
This guide answers all three questions completely.
What Core Web Vitals Are
Core Web Vitals are a subset of Web Vitals — Google's initiative to define and quantify the aspects of web experience that contribute to user satisfaction. The current Core Web Vitals are three metrics:
- LCP (Largest Contentful Paint): Loading performance
- CLS (Cumulative Layout Shift): Visual stability
- INP (Interaction to Next Paint): Interactivity responsiveness
Google chose these three because research showed they correlate most strongly with users' subjective experience of whether a page "feels fast" and "works well." They're measured from real user data (field data) rather than synthetic lab tests, captured through the Chrome User Experience Report (CrUX) which aggregates performance data from Chrome users who opt in to sharing this data.
The data source matters: field data reflects the actual experience of your real visitors on their actual devices and connections — not a test run from a standardized environment. A page that scores well in lab conditions but is accessed primarily by users on slow mobile connections will show different field data than lab data. Google ranks based on field data from CrUX.
LCP: Largest Contentful Paint
What It Measures
LCP measures the time from when a user first requests a page to when the largest visible content element in the viewport is rendered. The "largest contentful element" is typically:
- A hero image (most commonly)
- A large block of text visible above the fold
- A background image in a large container
- A video poster image
LCP captures the user's perception of "when is this page substantially loaded?" — the moment when the main content the user came for is visible and they can start consuming the page. It's not just the first byte or the first paint; it's the meaningful content paint.
The Thresholds
- Good: Under 2.5 seconds
- Needs Improvement: 2.5–4 seconds
- Poor: Over 4 seconds
What Causes Poor LCP
Slow server response time (TTFB): If the server takes a long time to respond with the initial HTML, everything downstream is delayed — including the LCP element. TTFB over 800ms meaningfully contributes to poor LCP.
Render-blocking resources: CSS and JavaScript files in the document <head> that must be downloaded and processed before the browser can render any content. Each render-blocking resource adds to LCP time.
Slow resource load time: If the LCP element is a large image, that image's download time contributes directly to LCP. An unoptimized hero image at 2MB produces much slower LCP than the same image at 200KB.
Client-side rendering: Content rendered entirely through JavaScript (single-page applications) often shows poor LCP because the browser must download, parse, and execute JavaScript before it can render any visible content.
How to Improve LCP
Optimize the LCP image: Compress it, serve it in modern formats (WebP or AVIF), and size it appropriately for the viewport. A 3000px wide image being displayed at 1400px wide is unnecessarily large. Use the <img> srcset attribute to serve appropriately-sized images at different viewport widths.
Preload the LCP image: Add a <link rel="preload" as="image"> hint in the <head> for the LCP image. This tells the browser to start downloading the LCP image immediately, before it discovers it through normal HTML parsing. This single change often produces 0.5–1.5 second LCP improvements on image-heavy pages.
Improve server response time: Use server-side caching (page cache for WordPress), upgrade to better hosting, implement a CDN to serve pages from edge nodes closer to visitors.
Eliminate render-blocking resources: Load non-critical CSS asynchronously or inline critical CSS. Add async or defer attributes to non-critical JavaScript. Remove unused CSS (which still blocks rendering even if unused).
Use a CDN: A CDN serves all static assets — including the LCP image — from edge nodes near the visitor, reducing download latency dramatically.
CLS: Cumulative Layout Shift
What It Measures
CLS measures the total amount of unexpected visual movement of visible page elements during the entire loading phase. A "layout shift" occurs when a visible element changes position from one frame to the next — the text you were reading suddenly jumps down because an image loaded and pushed it. The annoying experience of trying to click a button that moves at the last second because an ad loaded above it. That's layout shift.
CLS is calculated as the sum of all layout shift scores throughout the loading process. Each shift is scored based on the fraction of the viewport that moved and the distance elements moved. A page with no unexpected visual movement has a CLS of 0. A page where significant content jumps around has a high CLS.
The Thresholds
- Good: Under 0.1
- Needs Improvement: 0.1–0.25
- Poor: Over 0.25
What Causes Poor CLS
Images without declared dimensions: When images load without width and height attributes specified in HTML, the browser allocates no space for them before they load. When they do load, they push content below them down — a layout shift. This is the most common cause of CLS issues.
Ads and embeds without reserved space: Ad units that load after page content, without reserved placeholder space, push content when they appear. The same applies to embedded iframes (social media embeds, video embeds) that inject content dynamically.
Dynamically injected content: Content added to the page after initial load — notifications, banners, consent popups — that appears above existing content causes the existing content to shift down.
Web fonts causing FOUT/FOIT: Font swapping where the browser first renders text in a fallback font, then swaps to the web font when it loads, can cause layout shifts if the two fonts have different character metrics (different line heights, character widths).
How to Improve CLS
Always specify image dimensions: Add width and height attributes to every <img> element. The browser uses these to reserve the correct space before the image loads, preventing the content below from shifting when the image appears. This is the highest-impact, simplest fix for CLS in most cases.
Reserve space for ads and embeds: Use CSS to set fixed dimensions on ad containers and embed wrappers before the content loads. The space is reserved; the content fills it when it arrives. No shift.
Avoid inserting content above existing content: Any dynamically injected content (banners, notifications, consent overlays) should appear below or as overlays, not inserted above content the user is reading.
Use font-display: optional or careful font-display: swap: font-display: optional only uses the web font if it's already cached (avoids FOUT entirely). font-display: swap allows FOUT but the shift is smaller if fallback fonts are carefully matched to the web font's metrics using the size-adjust CSS property.
INP: Interaction to Next Paint
What It Measures
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. Where FID measured only the delay before the browser begins processing a user interaction, INP measures the full duration from when a user interaction occurs (click, tap, keyboard input) to when the browser paints the next frame in response.
INP captures the full interactivity experience: if you click a button and the page takes 800ms to visually respond, that 800ms is what INP measures — not just the delay before the browser starts working, but the complete time until the response is visible. This is a more accurate representation of the user's experience of page responsiveness.
The Thresholds
- Good: Under 200ms
- Needs Improvement: 200–500ms
- Poor: Over 500ms
What Causes Poor INP
INP is primarily a JavaScript problem. The browser's main thread handles both JavaScript execution and rendering. When JavaScript occupies the main thread with long tasks — tasks exceeding 50ms — user interactions must wait for those tasks to complete before the browser can process the interaction and paint the visual response.
Long JavaScript tasks: Any JavaScript execution that blocks the main thread for 50+ milliseconds. Common sources: heavy framework rendering cycles, complex event handlers, large synchronous API calls, and poorly optimized analytics or tracking code.
Excessive JavaScript: Loading and executing more JavaScript than necessary on any given page. Every JavaScript file loaded is JavaScript that must be parsed and potentially executed, consuming main thread time.
Blocking third-party scripts: Analytics, chat widgets, advertising scripts, heatmap tools, and other third-party JavaScript running on your pages can execute long tasks on the main thread, causing poor INP even when your own code is efficient.
How to Improve INP
Break up long tasks: Use setTimeout, requestIdleCallback, or scheduler.postTask to yield control back to the browser between sub-tasks of a long operation. This allows the browser to process user interactions between task chunks rather than blocking for the full task duration.
Reduce JavaScript execution: Audit your JavaScript bundles. Remove unused code. Defer loading of scripts not needed for initial interaction. Use code splitting to load JavaScript only when needed.
Audit third-party scripts: Each third-party script loaded on your page is a potential INP contributor. Use the Chrome Performance panel to identify which scripts are running long tasks. Consider whether every third-party script is justified by its business value versus its performance cost.
Optimize event handlers: Event handlers attached to frequent events (scroll, mousemove) or complex event handlers on frequently-clicked elements can cause poor INP if they do significant work synchronously. Move expensive work off the critical interaction path.
How to Check Your Core Web Vitals
Google Search Console Core Web Vitals Report
The most important data source: field data from real users of your site. Google Search Console's Core Web Vitals report (under Experience → Core Web Vitals) shows URLs grouped into Good, Needs Improvement, and Poor categories for both mobile and desktop.
This is the data Google uses for ranking signals. If this report shows "Poor" URLs, those pages are being penalized in search rankings. Fix the "Poor" pages first; "Needs Improvement" next.
Google PageSpeed Insights
PageSpeed Insights (pagespeed.web.dev) provides both field data (from CrUX, when available for a URL) and lab data (from a synthetic test run in Google's infrastructure). The lab data provides diagnostic information — which specific resources are slow, which resources are render-blocking, which layout shifts are occurring — that the field data alone doesn't reveal.
Run PageSpeed Insights on your key pages (homepage, highest-traffic pages) and work through the Priority Opportunities listed.
Chrome DevTools Performance Panel
For detailed debugging of LCP, CLS, and INP, Chrome's DevTools Performance panel is the authoritative tool. Record a page load and analyze the timeline: when does the LCP element paint? What JavaScript tasks are blocking the main thread? What layout shifts occur and when?
Core Web Vitals and Rankings: Realistic Expectations
How much do Core Web Vitals actually affect rankings? The honest answer: they're a real signal but not a dominant one. Google has confirmed that CWV are a tiebreaker among pages with similar content quality — a page with excellent content and poor CWV may still rank above a page with mediocre content and excellent CWV.
Where CWV become more impactful: highly competitive queries where many pages have similar content quality, where the differentiating factor shifts to technical and experience signals. For competitive commercial queries, the difference between "Good" and "Poor" CWV can be the difference between ranking #3 and ranking #8 — a meaningful traffic difference.
Additionally, CWV have direct conversion implications independent of rankings. Pages that load slowly, have unstable layouts, or respond sluggishly to interaction produce higher bounce rates and lower conversion rates — regardless of how they rank. The performance work that improves CWV improves rankings and business outcomes simultaneously.
The Bottom Line
Core Web Vitals — LCP (loading), CLS (visual stability), and INP (interactivity) — are Google's specific, measurable page experience signals that factor into search rankings. Pages that score "Good" on all three have a ranking advantage over equivalent-content pages scoring "Poor." More importantly, pages with good CWV scores produce better user experiences that convert at higher rates and generate less bounce-driven SEO damage.
Improve LCP through image optimization, preloading, server performance, and CDN. Improve CLS through image dimension declarations and reserved space for dynamic content. Improve INP through JavaScript optimization and third-party script auditing. Measure through Google Search Console's CWV report (field data) and PageSpeed Insights (lab diagnostics).
Every website built by Scalify is performance-optimized from launch — with particular attention to the Core Web Vitals signals that affect both your search rankings and your visitors' direct experience.
78 SW 7th St, Miami, FL 33130
