Core Web Vitals (LCP, INP, and CLS) are real-world performance metrics that Google uses as ranking signals. Pages that pass all three thresholds load fast, respond instantly to interactions, and stay visually stable. This complete guide covers measuring, diagnosing, and fixing all three metrics — with actionable techniques for every platform.
2026 Update: INP (Interaction to Next Paint) replaced FID as an official Core Web Vitals metric in March 2024. If your performance monitoring still tracks FID, update to INP. PageGuard's free scan reports all three current Core Web Vitals metrics in one scan.
Check your Core Web Vitals right now
Free lab-based LCP, INP, and CLS measurement — no account required, results in 30 seconds.
Core Web Vitals are a subset of Google's Web Vitals — metrics that measure real-world page experience. Since May 2021, they have been an official Google search ranking signal (part of the "Page Experience" update).
The three current Core Web Vitals metrics (2024–present) are:
LCP
Largest Contentful Paint
Loading performance — how fast the main content appears
Good: ≤ 2.5s
INP
Interaction to Next Paint
Interactivity — how fast the page responds to clicks & input
Good: ≤ 200ms
CLS
Cumulative Layout Shift
Visual stability — how much content moves during loading
Good: ≤ 0.1
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
CWV metrics can be measured as lab data (simulated) or field data (real users). Google uses field data for rankings, but lab data is essential for debugging.
web-vitals npm package for measuring and reporting CWV from your actual users to your analyticsNote: If your site doesn't have enough Chrome user traffic, CrUX field data may not be available. In this case, use lab data as your primary benchmark and monitor Google Search Console as your traffic grows.
LCP is the time until the largest visible content element (usually a hero image or large heading) has fully rendered. Four main phases affect LCP: TTFB, resource load delay, resource load time, and element render delay.
Open Chrome DevTools → Performance → record a page load → look for the "LCP" marker. Or use the Web Vitals extension to see the LCP element highlighted. Common LCP elements: above-the-fold hero images, large product images, video poster frames, or large text blocks.
1. Preload the LCP image
Add <link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> in your <head>. This is often the single highest-impact LCP improvement. The browser starts fetching the image before it parses the body HTML.
2. Never lazy-load the LCP element
Remove loading="lazy" from any image that could be the LCP element. Lazy loading delays the LCP image and directly increases LCP time. Only lazy-load below-the-fold images.
3. Use next-gen image formats (WebP/AVIF)
WebP is 25–35% smaller than JPEG at equivalent quality. AVIF is 40–50% smaller. Use <picture> with source elements for AVIF/WebP with JPEG fallback. Tools: Squoosh, Sharp (Node.js), ImageMagick, Cloudinary.
4. Serve images from a CDN
A CDN reduces the distance between the user and the server — often cutting image load time by 50–80%. Cloudflare Images, Cloudinary, imgix, and Vercel's Image Optimization serve images from edge locations globally.
5. Reduce TTFB (Time to First Byte)
A slow TTFB delays everything, including LCP. Good TTFB is under 800ms. Improvements: use server-side caching (Redis, Varnish), upgrade to faster hosting, use edge computing (Cloudflare Workers), or implement HTML streaming.
6. Eliminate render-blocking resources
Scripts and stylesheets in <head> block rendering. Add defer to non-critical scripts, load CSS asynchronously when possible, and inline critical CSS for above-the-fold content.
INP replaced FID in March 2024. It measures the time from a user interaction (click, tap, keyboard input) until the browser has painted the visual response. Unlike FID, INP considers all interactions throughout the page visit — not just the first one.
Each interaction has three phases: Input delay (time waiting for main thread to be free) + Processing time (time to run event handlers) + Presentation delay (time to paint the result). INP = max of these three combined across all interactions.
1. Break up long JavaScript tasks
Tasks longer than 50ms block the main thread and cause input delay. Use scheduler.yield() (or setTimeout(0) as fallback) to yield control back to the browser between chunks of work. Chrome DevTools' Performance panel shows long tasks as red markers.
2. Audit and reduce third-party scripts
Analytics, chat widgets, ad scripts, and heatmap tools often add significant JavaScript execution time. Load third-party scripts with defer or dynamically after user interaction. Use Chrome DevTools to identify which scripts consume the most main thread time.
3. Minimize DOM size
Large DOMs (>1,400 nodes) slow style recalculation and layout, increasing presentation delay. Virtualize long lists (react-window, virtual scroll), use pagination instead of infinite scroll for very large datasets, and remove hidden elements that are no longer needed.
4. Optimize event handlers
Avoid synchronous DOM reads immediately followed by DOM writes in click handlers (causes forced layout/reflow). Debounce scroll and resize handlers. Move expensive computations off the main thread using Web Workers for CPU-intensive operations like search indexing or data processing.
5. Code-split and lazy-load JavaScript
Load only the JavaScript needed for the current page view. Use dynamic import() for routes and heavy components. Tree-shake unused dependencies. Next.js, Nuxt, and SvelteKit do automatic route-based code splitting when used correctly.
6. Avoid CSS animations that trigger layout
Only animate transform and opacity — these run on the compositor thread and don't block the main thread. Animating width, height, top, or margin triggers layout recalculation on every frame.
CLS measures the total unexpected layout shift of visible content. Each layout shift has an impact fraction (how much of the viewport moves) × distance fraction (how far it moves). CLS is the sum of all unexpected shift scores.
Use Chrome DevTools → Performance tab → record page load → look for Layout Shift entries in the Experience row. Or use the Layout Instability API in the browser console to log shifts with their contributing elements.
1. Always set explicit image dimensions
The #1 CLS cause. Add width and height attributes to every <img> tag — the browser uses these to reserve space before the image loads. Combine with aspect-ratio CSS for responsive images: img { height: auto; } maintains aspect ratio while using the declared width/height for space reservation.
2. Reserve space for ads and embeds
Ad slots, YouTube embeds, and iframes often load content after the page renders, pushing other content down. Set min-height on ad containers to reserve space. Use responsive embed containers with aspect-ratio: 16/9 for videos.
3. Handle font loading properly
Web fonts cause CLS when text is displayed in a fallback font then reflows when the web font loads (FOIT/FOUT). Solutions: use font-display: optional to skip the fallback entirely (best CLS, may show fallback on slow connections), preload critical fonts, or use the CSS size-adjust descriptor to match fallback font metrics to your web font.
4. Avoid injecting content above existing content
Don't inject cookie banners, chat widgets, notification bars, or promotional banners above the fold after initial render. If you must show late-injected content, add it below the fold or use a fixed/sticky position so it overlays rather than pushes other content.
5. Use CSS transform for animations
Animations that change an element's position using top, left, margin, or padding cause layout shifts. Rewrite these using transform: translate() which moves elements without affecting layout of surrounding elements.
6. Avoid unsized skeleton screens
Skeleton loaders improve perceived performance but can cause CLS if the actual content dimensions differ from the skeleton. Make skeleton dimensions match the final content exactly, or use min-height on content containers to reserve space before data loads.
WordPress is the most common CWV underperformer due to plugin bloat. Key fixes: (1) Switch to a lightweight theme (GeneratePress, Kadence, Astra); (2) Use WP Rocket or LiteSpeed Cache for full-page caching + CSS/JS optimization; (3) Enable Cloudflare's free CDN; (4) Use WebP conversion via Imagify, ShortPixel, or EWWW; (5) Audit and remove unused plugins — each plugin adds JavaScript to every page load.
Shopify's theme marketplace and app ecosystem are the main sources of CWV issues. Key fixes: (1) Choose a performance-focused theme (Dawn is Shopify's official performant theme); (2) Remove unused apps — every installed app may inject scripts; (3) Lazy load below-the-fold product images; (4) Use Shopify's built-in image CDN and serve images at appropriate sizes using {{ image | image_url: width: 1200 }}.
Next.js has strong built-in CWV optimizations. Key practices: (1) Use next/image for all images — it adds responsive sizes, lazy loading, WebP conversion, and explicit dimensions automatically; (2) Use next/font for Google Fonts (eliminates font CLS entirely); (3) Enable automatic code splitting via the App Router or dynamic() imports; (4) Enable priority prop on the LCP image to preload it.
These platforms handle some optimizations automatically (image CDN, basic compression) but have limited control for advanced optimization. Focus on: (1) Reducing hero image file sizes before upload; (2) Limiting embedded third-party widgets; (3) Disabling auto-playing videos in hero sections; (4) Using clean themes with minimal CSS/JS overhead. Wix and Squarespace have made significant CWV improvements in recent years.
Navigate to Core Web Vitals Report
In Google Search Console, click Experience → Core Web Vitals in the left sidebar. You'll see separate Mobile and Desktop reports showing URL counts by status: Good, Needs Improvement, and Poor.
Investigate Failing URL Groups
GSC groups similar URLs together (e.g., all blog post pages). Click on a failing group to see example URLs and which specific metric (LCP, INP, or CLS) is failing. Use PageSpeed Insights on those specific URLs to see both field and lab data.
Fix and Validate
After implementing fixes, use PageSpeed Insights lab data to verify improvement. For field data improvements: they lag by 28 days (CrUX data is updated monthly). After fixing, wait 4–8 weeks and then click "Validate Fix" in GSC to re-trigger the status check.
Set Up Email Alerts
Enable email notifications in GSC Settings → Email preferences → Core Web Vitals. You'll be alerted when URLs drop below the "Good" threshold — useful for catching regressions after code deployments.
Unoptimized images are the leading cause of poor LCP. Follow this image optimization checklist for every page:
✓ Image Optimization Checklist
Recommended Image Tools
Custom web fonts affect both LCP (delayed text rendering) and CLS (layout shift when font loads). Here's the complete font optimization strategy:
<link rel="preload" as="font" href="/fonts/main.woff2" crossorigin> for your primary body font. Only preload fonts used above the fold.
size-adjust descriptor adjusts fallback font metrics to match the web font dimensions, eliminating text reflow when the web font loads.
JavaScript is the primary driver of poor INP. The goal is to keep the main thread free to respond to user interactions within 200ms.
Audit Your JavaScript Bundle Size
Use webpack-bundle-analyzer or Vite's rollup-plugin-visualizer to identify large dependencies. Common culprits: moment.js (use date-fns instead), lodash (use lodash-es with tree shaking), or large UI component libraries loaded in full.
Defer Non-Critical Third-Party Scripts
Load analytics, chat widgets, and other third-party scripts after user interaction or with a small delay. Instead of loading on DOMContentLoaded, load them in a setTimeout(fn, 3000) or on first user interaction. Use type="module" which is automatically deferred.
Use Web Workers for Heavy Computation
Move data processing, search indexing, file parsing, or cryptographic operations to a Web Worker — these run on a separate thread and don't block the main thread. Comlink makes Web Worker communication much simpler.
Implement requestIdleCallback for Low-Priority Work
Defer non-urgent tasks (analytics processing, prefetching, cache warming) until the browser is idle using requestIdleCallback(). This keeps the main thread free for user interactions.
Understanding the real ranking impact of Core Web Vitals helps you prioritize your optimization effort:
Tracking Core Web Vitals is an ongoing process — deployments, content changes, and new third-party scripts can all cause regressions. Regular monitoring catches issues before they affect rankings.
PageGuard provides free on-demand Core Web Vitals measurement alongside SEO, accessibility, and best practices scores — giving you a complete picture of your page health in one scan.
Measure your Core Web Vitals now
Free LCP, INP, and CLS measurement alongside SEO and accessibility audit — no account required, results in 30 seconds.
Core Web Vitals are three user experience metrics: LCP (largest content load time ≤ 2.5s), INP (interaction response time ≤ 200ms), and CLS (layout shift score ≤ 0.1). Google uses them as part of its Page Experience ranking signal since May 2021. Pages passing all three get a rankings boost, especially for competitive queries. Beyond rankings, improving CWV reduces bounce rates and increases conversions.
LCP measures when the largest content element in the viewport finishes rendering. Good LCP is ≤ 2.5 seconds. The highest-impact improvements: preload your LCP image, never lazy-load it, convert images to WebP/AVIF, serve from a CDN, reduce TTFB with server-side caching, and eliminate render-blocking scripts/stylesheets in the document head.
FID (First Input Delay) was replaced by INP (Interaction to Next Paint) in March 2024. INP measures the latency of all interactions throughout a page visit (not just the first). Good INP is ≤ 200ms. Fix INP by breaking up long JavaScript tasks over 50ms, reducing third-party script load, minimizing DOM size, and only animating transform/opacity properties.
CLS measures visual instability as content jumps around during loading. Good CLS is ≤ 0.1. The main fixes: always set explicit width/height on images, reserve space for ads and embeds with min-height, use font-display: optional for web fonts, avoid injecting content above the fold after render, and only animate transform/opacity (not layout-affecting properties).
Lab tools (synthetic): Chrome DevTools Performance panel, Lighthouse, WebPageTest, PageGuard. Field tools (real user data): Google Search Console Core Web Vitals report, PageSpeed Insights (shows both lab and CrUX field data), Chrome UX Report dataset. Use lab data for debugging; use field data to measure real-world improvements and verify Google recognizes your fixes.
Website Speed Optimization 2026
Comprehensive guide to making your website faster with caching, compression, and CDN
Website Speed Test Guide 2026
How to use PageSpeed Insights, WebPageTest, and Lighthouse to measure performance
Technical SEO Checklist 2026
Complete technical SEO audit covering crawlability, indexing, and Core Web Vitals
Structured Data Guide 2026
Implement Schema.org JSON-LD markup to get rich results in Google search