Google uses Core Web Vitals as a ranking signal. But the real reason to care about them is simpler: slow, janky pages lose visitors. A page that takes four seconds to show content or shifts layout while someone is trying to tap a button creates a bad experience, and bad experiences cost conversions.
There are three metrics. Each measures a different aspect of how a page feels to use. Here is what they are, what causes poor scores, and how to fix them.
LCP: Largest Contentful Paint
What it measures: How long it takes for the largest visible element (usually a hero image, heading, or video thumbnail) to finish rendering in the viewport.
Thresholds:
Good: under 2.5 seconds
Needs improvement: 2.5 to 4.0 seconds
Poor: over 4.0 seconds
LCP is the most intuitive metric. It answers the question: "When did the page actually appear?" Not when the first pixel rendered, but when the main content the user came to see became visible.
Common causes of poor LCP
Unoptimized images. This is the number one cause. A 3MB hero image downloaded from a stock photo site, served without compression, without responsive sizing, and without a CDN, will tank your LCP every time. Convert to WebP or AVIF, serve responsive sizes with srcset, and use a CDN. Our image SEO guide covers format selection, compression, and sizing in detail.
Render-blocking CSS and JavaScript. The browser cannot render anything until it has downloaded and parsed all CSS in the <head>. Large CSS files or multiple CSS files that load sequentially push LCP later. The same applies to synchronous JavaScript in the <head>, which blocks HTML parsing entirely.
Fix: inline critical CSS (the styles needed for above-the-fold content), defer non-critical CSS, and add defer or async to script tags. If you are using a bundler, enable code splitting so the browser only downloads what it needs for the current page.
Slow server response time (TTFB). If your server takes 800ms to respond, LCP cannot possibly be under 2.5 seconds on a slow connection. Time to First Byte should be under 200ms for static content and under 600ms for dynamic pages. Redirect chains add latency to every request, so as a first step. Server-side caching, edge deployment, and database query optimization are the standard fixes.
A ChatGPT SEO audit is a manual site review where you feed page data, crawl output, or Google Search Console exports into ChatGPT and use targeted prompts to identify technical issues, content gaps, and ranking opportunities. It works best for analysis and pri
The "duplicate content penalty" is one of the most persistent myths in SEO. Site owners panic when they find identical text on two URLs, convinced that Google is about to punish their entire domain. That is not how it works.
Google does not have a penalty for
React applications have a reputation for being invisible to search engines. That reputation is outdated, but the underlying concern is valid: if your content is rendered entirely in the browser with JavaScript, Google has to execute that JavaScript to see it.
Web font loading delays. If the LCP element is a text heading using a custom web font, the browser may wait for the font to download before rendering the text. Use font-display: swap in your @font-face declaration so the browser shows a fallback font immediately and swaps when the custom font loads. Preload your primary font file with <link rel="preload" as="font">.
Lazy loading above-the-fold images. If you add loading="lazy" to your hero image, the browser deliberately delays loading it until it enters the viewport. For images that are already in the viewport on page load, this creates unnecessary delay. Only lazy load images below the fold. Use fetchpriority="high" on the LCP image to tell the browser to prioritize it.
INP: Interaction to Next Paint
What it measures: The delay between a user interaction (click, tap, keypress) and the next visual update on screen. INP replaced First Input Delay (FID) in March 2024 because FID only measured the first interaction, while INP tracks all interactions throughout the page lifecycle and reports the worst one (approximately the 98th percentile).
Thresholds:
Good: under 200 milliseconds
Needs improvement: 200 to 500 milliseconds
Poor: over 500 milliseconds
INP catches problems that FID missed entirely. A page could have great FID because the first click happened during an idle period, but terrible INP because subsequent interactions triggered heavy JavaScript.
Common causes of poor INP
Long tasks on the main thread. Any JavaScript task that runs for more than 50ms blocks the browser from responding to user input during that time. Common offenders: large framework re-renders, complex DOM manipulations, synchronous API calls, and analytics scripts that process data on every interaction.
Fix: break long tasks into smaller chunks using requestAnimationFrame, setTimeout(fn, 0), or the scheduler.yield() API. Move heavy computation to Web Workers where possible.
Heavy JavaScript bundles. A 500KB JavaScript bundle does not just slow down initial load. Parsing and compiling that JavaScript takes time, and during that time the main thread is blocked. Even after initial load, if your framework re-evaluates large amounts of code on each interaction, INP suffers.
Fix: code split aggressively. Load only the JavaScript needed for the current page. Defer non-critical scripts. Consider whether you need that animation library, carousel plugin, or analytics SDK on every page.
Expensive event handlers. If a click handler triggers a complex DOM update, a state recalculation, or a synchronous network request, the visual update gets delayed until all of that finishes.
Fix: debounce rapid interactions (like scroll or resize handlers), batch DOM updates, and use requestAnimationFrame to schedule visual updates at the right time in the browser's rendering pipeline.
Third-party scripts. Chat widgets, analytics trackers, A/B testing tools, and ad scripts all compete for main thread time. Each one adds a small delay, and together they can push INP well past 200ms.
Audit third-party scripts regularly. Remove anything you are not actively using. Load non-essential scripts with defer or after the page is interactive.
CLS: Cumulative Layout Shift
What it measures: How much the visible content shifts around unexpectedly during the page's lifetime. Every time an element moves after it has already rendered, that movement is scored based on how far it moved and how much of the viewport it affected. CLS is the sum of all unexpected shift scores.
Thresholds:
Good: under 0.1
Needs improvement: 0.1 to 0.25
Poor: over 0.25
CLS captures the "I was about to click that button and it moved" problem. It is the most frustrating metric for users because layout shifts feel broken in a way that slowness does not.
Common causes of poor CLS
Images and videos without explicit dimensions. If an image tag does not specify width and height attributes (or equivalent CSS), the browser does not know how much space to reserve. When the image loads, the content below it gets pushed down. Always set dimensions or use the CSS aspect-ratio property.
Dynamically injected content above existing content. Banners, cookie notices, newsletter popups, and "breaking news" bars that insert themselves at the top of the page push everything else down. If you must show dynamic content, reserve space for it in advance, or position it as a fixed/sticky element that overlays rather than displaces.
Web fonts causing FOIT or FOUT. If a custom font has different character widths than the fallback font, text reflows when the font swap happens. This causes layout shifts on every text element using that font. Use font-display: swap with a carefully chosen fallback font that has similar metrics. Tools like fontaine or @next/font can automatically adjust fallback font metrics to match your custom font.
Ads and embeds without reserved space. Third-party ads, social media embeds, and iframe content often load late and push content around when they appear. Always wrap embeds in a container with fixed dimensions matching the expected content size.
Late-loading CSS. If a stylesheet loads after the page has already rendered, the new styles can cause elements to resize and reposition. This is especially common with asynchronously loaded CSS or CSS injected by JavaScript. Load all critical CSS synchronously in the <head>.
How to measure Core Web Vitals
Field data (real users)
Chrome UX Report (CrUX): Aggregated performance data from real Chrome users who have opted into usage statistics. Available through PageSpeed Insights, Search Console, and the CrUX API. This is the data Google actually uses for ranking. It updates monthly, so changes take time to reflect.
Google Search Console: The Core Web Vitals report groups your URLs by status (good, needs improvement, poor) based on CrUX data. It shows which pages have problems but does not diagnose the cause.
Lab data (synthetic testing)
Lighthouse: Built into Chrome DevTools (Audits tab). Runs a simulated page load and measures all three metrics. Lab data does not affect rankings, but it is useful for diagnosing specific issues. Run it in an incognito window to avoid extension interference.
PageSpeed Insights: Combines CrUX field data (when available) with a Lighthouse lab test. The top section shows real-user data. The bottom section shows the lab analysis with specific recommendations. This is the fastest way to get both perspectives.
Web Vitals Chrome extension: Shows CWV metrics in real-time as you browse your site. Useful for catching CLS issues that only happen on specific interactions.
Run your pages through the Ooty SEO Analyzer for a quick technical health check that flags Core Web Vitals problems alongside other SEO issues.
Fix priority order
Not all metrics are equally easy to fix, and not all fixes have equal impact. Here is a practical order:
CLS first. Layout shift fixes are usually the simplest: add image dimensions, reserve space for ads, fix font loading. The fixes are mostly HTML/CSS changes, not infrastructure work. Results show up quickly.
LCP second. Image optimization and render-blocking resource fixes have the highest impact per effort. Server response time improvements require more infrastructure work but pay dividends across every page.
INP third. JavaScript performance optimization is the most complex and often requires code refactoring. Start with the easy wins (removing unused third-party scripts, deferring non-critical JS) before tackling framework-level optimizations.
The real ranking impact
Core Web Vitals are a confirmed Google ranking signal, but they are a tiebreaker, not a primary factor. A page with excellent content and strong backlinks will outrank a page with perfect Core Web Vitals scores but thin content. Every time.
Google has been explicit about this: content relevance remains the strongest ranking factor. Core Web Vitals matter at the margins, where two pages are roughly equal in content quality and authority. In that case, the faster, more stable page gets the edge.
That said, the indirect effects are significant. Faster pages have lower bounce rates, higher engagement, and better conversion rates. Those user behavior signals do affect rankings over time, and they directly affect revenue. A 100ms improvement in LCP correlates with measurable increases in conversion rate for e-commerce sites.
Fix Core Web Vitals because they make your site better to use, not because you expect a rankings boost. The rankings benefit is real but modest. The user experience benefit is substantial.
If you are dealing with crawl budget issues alongside poor Core Web Vitals, prioritize server response time: it improves both crawl efficiency and LCP simultaneously. And if your site relies heavily on JavaScript for rendering, read our guide on JavaScript SEO to make sure Googlebot can actually see the content you are optimizing.
