Table of Contents

What Are Core Web Vitals?

Core Web Vitals are a set of standardized metrics introduced by Google to quantify the real-world user experience of a web page. They focus on three fundamental aspects of UX: loading performance, interactivity, and visual stability.

First announced in May 2020 and integrated as ranking signals in June 2021, Core Web Vitals have become one of the most important technical SEO factors. According to a 2023 HTTP Archive analysis, only 33% of websites pass all three Core Web Vitals thresholds on mobile — meaning there is a massive opportunity for sites that optimize properly.

“Speed has always been a ranking factor for Google, but Core Web Vitals turned it into a specific, measurable, and actionable framework.” — Martin Splitt, Google Developer Advocate

At Lueur Externe, we’ve been optimizing web performance since our founding in 2003. As a certified Prestashop Expert and AWS Solutions Architect based in the Alpes-Maritimes (06), we’ve helped hundreds of businesses transform their Core Web Vitals from red to green — and seen the tangible ranking and conversion benefits that follow.

📌 Key Takeaway: Core Web Vitals are Google-defined metrics (LCP, INP, CLS) that measure real user experience and directly influence search rankings.

The Three Core Web Vitals Metrics Explained

Largest Contentful Paint (LCP)

Largest Contentful Paint measures how long it takes for the largest visible content element to render within the viewport. This is typically a hero image, a large text block, a video poster, or a background image.

LCP is the most intuitive of the three metrics — it answers the user’s fundamental question: “Has this page loaded enough for me to see the main content?”

What counts as the LCP element:

  • <img> elements (including those inside <picture>)
  • <image> elements inside SVG
  • <video> elements (the poster image or first frame)
  • Elements with a background image loaded via url() in CSS
  • Block-level elements containing text nodes

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. While FID only measured the delay before the browser started processing the first interaction, INP measures the full latency of all interactions (clicks, taps, keyboard inputs) and reports the worst observed latency (with outliers excluded).

This makes INP a far more comprehensive responsiveness metric. A page might have great FID but terrible INP if later interactions (like clicking “Add to Cart” or opening a filter menu) are slow due to heavy JavaScript execution.

INP measures three phases:

  1. Input delay — time from user interaction to event handler start
  2. Processing time — time to execute event handlers
  3. Presentation delay — time from handler completion to next frame paint

Cumulative Layout Shift (CLS)

CLS quantifies how much page content unexpectedly shifts during the user’s session. It’s calculated by multiplying the impact fraction (how much of the viewport shifted) by the distance fraction (how far elements moved).

We’ve all experienced the frustration of trying to click a button, only for an ad or image to load and push the content down — making you click the wrong thing. CLS puts a number on that frustration.

CLS uses a session window approach: it groups layout shifts that occur within 1 second of each other (with a maximum 5-second window) and reports the largest session window total.

📌 Key Takeaway: LCP = loading speed, INP = responsiveness to all interactions, CLS = visual stability. Master all three to pass Core Web Vitals.

Core Web Vitals Thresholds: What Scores Do You Need?

Google defines three rating levels for each metric: Good, Needs Improvement, and Poor.

MetricGoodNeeds ImprovementPoor
LCP≤ 2.5 seconds2.5s – 4.0s> 4.0 seconds
INP≤ 200 ms200ms – 500ms> 500 ms
CLS≤ 0.10.1 – 0.25> 0.25

To “pass” Core Web Vitals assessment, at least 75% of your page visits must meet the “Good” threshold for all three metrics. This is based on the 75th percentile of field data — meaning if 3 out of 4 visitors experience good performance, you pass.

Here’s the important detail many overlook: these thresholds are evaluated per page URL (or per URL group), not site-wide. A single slow page won’t necessarily drag down your entire domain.

How to Measure Core Web Vitals

Lab Tools vs. Field Data

Understanding the difference between lab and field data is critical for effective page speed optimization.

AspectLab DataField Data (RUM)
SourceSimulated in controlled environmentReal users on real devices
ToolsLighthouse, WebPageTest, Chrome DevToolsCrUX, PageSpeed Insights (field section), RUM providers
ProsReproducible, detailed, immediateReflects actual user experience
ConsDoesn’t reflect real conditions28-day rolling average, slower to update
INP available?Simulated via TBT (Total Blocking Time)Yes, directly measured
Used by Google for ranking?NoYes (CrUX field data)

⚠️ Critical Insight: Google uses field data from the Chrome User Experience Report (CrUX) for ranking purposes, NOT Lighthouse lab scores. A perfect Lighthouse 100 doesn’t guarantee passing Core Web Vitals in the field.

Essential Measurement Tools

  • Google PageSpeed Insights — the single best starting point; shows both lab (Lighthouse) and field (CrUX) data
  • Google Search Console — Core Web Vitals report showing site-wide URL status (Good / Needs Improvement / Poor)
  • Chrome DevTools Performance Panel — deep-dive lab analysis with flame charts and per-frame detail
  • Web Vitals Chrome Extension — real-time overlay showing LCP, INP, and CLS as you browse
  • CrUX Dashboard (Data Studio) — historical trends of your field CWV data over time
  • WebPageTest.org — advanced lab testing with filmstrip view, waterfall analysis, and multi-location testing
  • Lighthouse CI — automated Lighthouse testing in your CI/CD pipeline

📌 Key Takeaway: Always check field data (CrUX) alongside lab tools. Lab tools help you diagnose; field data determines your actual Google assessment.

LCP Optimization: Step-by-Step

LCP is often the metric with the most room for improvement. According to HTTP Archive data from early 2025, approximately 60% of mobile origins meet the LCP “Good” threshold — meaning 40% still fail.

Diagnosing LCP Issues

Before fixing anything, identify your LCP element and its bottleneck:

  1. Open Chrome DevTools → Performance tab
  2. Record a page load
  3. Look for the “LCP” marker in the timeline
  4. Click it to identify the exact LCP element
  5. Analyze the waterfall to see what delayed it

LCP delays typically fall into four sub-parts (as defined by Google’s LCP breakdown):

  • Time to First Byte (TTFB) — server response time
  • Resource Load Delay — time between TTFB and when the LCP resource starts loading
  • Resource Load Duration — time to download the LCP resource (image, font, etc.)
  • Element Render Delay — time from resource loaded to element rendered on screen

Server-Side Optimizations

If TTFB is high (over 600ms), focus here first:

  • Use a CDN — serve content from edge locations close to your users. At Lueur Externe, as AWS Solutions Architect certified professionals, we deploy CloudFront distributions that reduce TTFB by 40-70% for geographically distributed audiences.
  • Enable server-side caching — use Redis, Varnish, or opcode caching to avoid regenerating pages on every request
  • Optimize database queries — slow SQL queries are one of the top TTFB killers, especially on e-commerce platforms
  • Upgrade hosting — shared hosting rarely delivers sub-200ms TTFB; consider dedicated or cloud-based infrastructure
  • Use HTTP/2 or HTTP/3 — multiplexing reduces connection overhead
# Nginx server-side caching example for improved TTFB
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=STATIC:10m inactive=7d use_temp_path=off;

server {
    location / {
        proxy_cache STATIC;
        proxy_cache_valid 200 1d;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        add_header X-Cache-Status $upstream_cache_status;
        proxy_pass http://backend;
    }
}

Image and Font Optimization

Since the LCP element is usually an image, this is the highest-impact area:

  • Use modern formats — WebP offers 25-35% smaller file sizes than JPEG; AVIF offers 50% savings
  • Serve responsive images with srcset and sizes attributes
  • Preload the LCP image — this is the single most impactful LCP optimization for image-based LCP elements
  • Avoid lazy-loading the LCP image — loading="lazy" on the LCP element delays it
  • Use fetchpriority="high" on the LCP image to signal its importance
<!-- Optimal LCP image implementation -->
<link rel="preload" as="image" href="/images/hero-banner.webp" 
      imagesrcset="/images/hero-banner-400.webp 400w,
                   /images/hero-banner-800.webp 800w,
                   /images/hero-banner-1200.webp 1200w"
      imagesizes="100vw">

<img src="/images/hero-banner.webp"
     srcset="/images/hero-banner-400.webp 400w,
            /images/hero-banner-800.webp 800w,
            /images/hero-banner-1200.webp 1200w"
     sizes="100vw"
     alt="Hero banner description"
     width="1200" height="600"
     fetchpriority="high"
     decoding="async">

For font optimization (when the LCP element is text):

  • Use font-display: swap or font-display: optional
  • Preload critical fonts: <link rel="preload" as="font" href="/fonts/main.woff2" crossorigin>
  • Subset fonts to include only necessary characters
  • Self-host fonts instead of relying on Google Fonts (eliminates a DNS lookup + connection)

Critical Rendering Path

  • Inline critical CSS — extract above-the-fold styles and inline them in the <head>
  • Defer non-critical CSS — load remaining stylesheets asynchronously
  • Eliminate render-blocking JavaScript — use defer or async attributes
  • Reduce DOM size — pages with over 1,500 DOM nodes see measurable LCP degradation

📌 Key Takeaway: For most sites, preloading the LCP image with fetchpriority="high", switching to WebP/AVIF, and reducing TTFB will deliver the biggest LCP improvements.

INP Optimization: Making Pages Responsive

Understanding Main Thread Blocking

The browser’s main thread handles layout, painting, JavaScript execution, and user input. When JavaScript monopolizes the main thread with long tasks (any task longer than 50ms), interactions are delayed.

Total Blocking Time (TBT) in Lighthouse is the best lab proxy for INP. A TBT under 200ms generally correlates with good field INP.

Common causes of poor INP:

  • Large JavaScript bundles executing on load
  • Third-party scripts (analytics, ads, chat widgets, tag managers)
  • Expensive DOM manipulations in event handlers
  • Synchronous layout thrashing (reading then writing layout properties repeatedly)
  • Heavy computation in response to user interactions

JavaScript Optimization Techniques

  • Code split aggressively — only load JavaScript needed for the current view
  • Tree-shake unused code — modern bundlers (webpack, Rollup, esbuild) eliminate dead code
  • Defer non-essential scripts — analytics, social media widgets, and chat tools don’t need to load at page start
  • Use requestIdleCallback for non-urgent work
  • Break up long tasks with scheduler.yield() (or fallback to setTimeout)
// Breaking up a long task using scheduler.yield()
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // Yield to the main thread every 5 items
    // to allow the browser to process user interactions
    if (i % 5 === 0) {
      if ('scheduler' in window && 'yield' in scheduler) {
        await scheduler.yield();
      } else {
        await new Promise(resolve => setTimeout(resolve, 0));
      }
    }
  }
}

Event Handler Best Practices

  • Keep event handlers under 50ms of processing time
  • Use CSS transitions/animations instead of JavaScript-driven animations
  • Debounce scroll and resize event handlers
  • Move heavy computation to Web Workers
  • Use content-visibility: auto on off-screen content to reduce rendering work
  • Avoid forced synchronous layouts inside event handlers

📌 Key Takeaway: INP is about keeping the main thread available for user interactions. Break up long tasks, defer non-essential JavaScript, and keep event handlers lean.

CLS Optimization: Achieving Visual Stability

Common CLS Culprits

Layout shifts are caused by content that changes size or position after initial render. The biggest offenders include:

  • Images and videos without dimensions — the browser doesn’t know how much space to reserve
  • Ads, embeds, and iframes without reserved space — these load asynchronously and push content around
  • Web fonts causing FOIT/FOUT — text re-renders with different metrics when custom fonts load
  • Dynamically injected content — banners, cookie notices, notification bars inserted above existing content
  • CSS animations that trigger layout changes (animating top, left, width, height instead of transform)

Layout Shift Prevention Techniques

  1. Always set width and height on images and videos — this allows the browser to calculate the aspect ratio before loading:
<!-- Good: dimensions specified -->
<img src="product.webp" width="800" height="600" alt="Product photo">

<!-- Even better: use CSS aspect-ratio as a fallback -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 4 / 3;
  }
</style>
  1. Reserve space for ads and embeds — use min-height on ad containers
  2. Use font-display: optional for the most aggressive CLS prevention (falls back to system font if custom font isn’t cached)
  3. Avoid inserting content above the fold dynamically — if you must (e.g., cookie banners), use overlays or bottom-positioned banners instead
  4. Use CSS contain property — contain: layout prevents an element’s internal layout changes from affecting surrounding elements
  5. Animate with transform and opacity — these properties don’t trigger layout recalculations

📌 Key Takeaway: Most CLS issues are preventable by setting explicit dimensions on media, reserving space for dynamic content, and using CSS transform for animations.

Lighthouse Score Deep Dive

How Lighthouse Calculates Your Score

The Lighthouse performance score is a weighted average of six metrics (as of Lighthouse 12):

MetricWeightWhat It Measures
First Contentful Paint (FCP)10%Time until first content pixel renders
Speed Index (SI)10%How quickly content is visually displayed
Largest Contentful Paint (LCP)25%Time until main content renders
Total Blocking Time (TBT)30%Sum of blocking time of long tasks (INP proxy)
Cumulative Layout Shift (CLS)25%Visual stability score

Notice that TBT (30%) and LCP (25%) account for more than half the total score. This is why JavaScript optimization and LCP improvements have the biggest impact on your Lighthouse score.

Lighthouse Score vs. Field Data

It’s common to see significant discrepancies:

  • Lighthouse simulates a mid-tier phone on a slow 4G connection (Moto G Power on 150ms RTT, 1.6 Mbps throughput). Your real users may have faster or slower conditions.
  • Lighthouse tests a single page load in isolation. Field data captures repeat visits (with cached resources), interactions across the entire session, and the full diversity of devices and networks.
  • A Lighthouse score of 90+ with failing field CWV usually means your real users are on slower devices/connections than Lighthouse simulates.
  • A Lighthouse score of 60 with passing field CWV can happen when most of your visitors use fast devices and good connections.

Our recommendation at Lueur Externe: Use Lighthouse for diagnostics and development workflow, but always validate against field data in Google Search Console and PageSpeed Insights for your final assessment.

📌 Key Takeaway: Lighthouse is a diagnostic tool, not a ranking factor. Field data from CrUX determines your actual Core Web Vitals status. Aim for Lighthouse 90+ but prioritize field metric thresholds.

Advanced Performance Optimization Strategies

Resource Hints and Preloading

Resource hints tell the browser about resources it will need, allowing it to start fetching them earlier:

  • <link rel="preconnect"> — establishes early connection (DNS + TCP + TLS) to critical third-party origins
  • <link rel="dns-prefetch"> — resolves DNS for third-party origins (lighter than preconnect)
  • <link rel="preload"> — fetches critical resources needed for the current page
  • <link rel="prefetch"> — fetches resources likely needed for future navigations
  • <link rel="modulepreload"> — preloads ES modules
<!-- Strategic resource hints -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://analytics.example.com">
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin>
<link rel="preload" as="style" href="/css/critical.css">

Rules of thumb:

  • Preconnect to a maximum of 2-3 origins (too many can hurt performance)
  • Only preload resources used within the first 3 seconds of page load
  • Use fetchpriority to signal relative importance of resources

CDN and Edge Computing

A Content Delivery Network reduces latency by serving assets from edge locations geographically close to users. Beyond basic CDN file serving, modern approaches include:

  • Edge-side rendering (e.g., Cloudflare Workers, AWS Lambda@Edge) — generate HTML at the edge for near-instant TTFB
  • Stale-while-revalidate caching — serve cached content instantly while fetching updates in the background
  • Image CDN services (Cloudinary, Imgix, CloudFront + Lambda) — serve optimally resized, compressed, and formatted images based on the requesting device

As an AWS Solutions Architect certified agency, Lueur Externe designs and deploys cloud architectures that leverage CloudFront, S3, Lambda@Edge, and ElastiCache to achieve sub-100ms TTFB globally — a foundational requirement for excellent LCP.

Framework-Specific Optimizations

Modern JavaScript frameworks introduce specific performance challenges:

React / Next.js:

  • Use React Server Components to reduce client-side JavaScript
  • Implement next/image for automatic image optimization
  • Use next/font for zero-layout-shift font loading
  • Leverage ISR (Incremental Static Regeneration) for dynamic content with static performance

Prestashop (our specialty):

  • Implement full-page caching with Varnish or Redis
  • Optimize module loading order and remove unused modules
  • Use WebP image generation for product catalogs
  • Compress and concatenate CSS/JS assets
  • Implement lazy loading for product listing images below the fold

WordPress:

  • Use server-level caching (Redis object cache + page cache)
  • Minimize plugin count (each plugin adds JavaScript and CSS)
  • Implement Critical CSS with WP Rocket or similar
  • Use the native lazy loading and priority hints

📌 Key Takeaway: Combine resource hints, CDN deployment, and framework-specific best practices for the most impactful performance gains.

Core Web Vitals for E-Commerce

E-commerce sites face unique CWV challenges due to product images, dynamic content, third-party payment/analytics scripts, and complex interactive elements.

Real-world impact data:

  • Vodafone: 31% LCP improvement → 8% more sales
  • NDTV: 55% LCP reduction → 50% lower bounce rate
  • Akamai: 100ms delay in load time → 7% drop in conversions
  • Google: 53% of mobile users abandon sites that take over 3 seconds to load

E-commerce CWV checklist:

  • ✅ Preload hero/banner images on category and product pages
  • ✅ Lazy-load product listing images below the fold
  • ✅ Use fetchpriority="high" on the main product image
  • ✅ Reserve space for product image galleries (prevent CLS)
  • ✅ Defer third-party scripts (reviews, chat, analytics, retargeting pixels)
  • ✅ Implement skeleton screens for dynamically loaded content (filters, recommendations)
  • ✅ Use server-side rendering or full-page caching for category pages
  • ✅ Optimize the “Add to Cart” interaction for fast INP (keep event handlers < 50ms)
  • ✅ Compress and serve product images in WebP/AVIF format
  • ✅ Minimize redirect chains (especially on mobile URLs)

At Lueur Externe, as certified Prestashop Experts, we routinely optimize Prestashop stores to achieve green Core Web Vitals across all product and category pages — often improving Lighthouse scores from the 30-50 range to 85-95+ while simultaneously reducing page weight by 60-70%. You can explore our e-commerce expertise and technical capabilities in more detail.

📌 Key Takeaway: E-commerce performance directly impacts revenue. Every 100ms of improvement can drive measurable conversion increases.

Monitoring and Continuous Improvement

Performance optimization is not a one-time project — it requires ongoing monitoring. New features, third-party script updates, content changes, and CMS updates can regress your metrics overnight.

Build a monitoring stack:

  1. Google Search Console — check the Core Web Vitals report weekly
  2. CrUX Dashboard — track monthly trends in field data
  3. Lighthouse CI in your deployment pipeline — prevent performance regressions before they reach production
  4. Real User Monitoring (RUM) — tools like SpeedCurve, Sentry Performance, or the web-vitals JavaScript library for granular, real-time data
  5. Performance budgets — set maximum thresholds for JavaScript size, image weight, and total page weight
// Collecting Core Web Vitals with the web-vitals library
import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,  // 'good', 'needs-improvement', or 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  });
  
  // Use sendBeacon for reliable delivery
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/analytics/cwv', body);
  } else {
    fetch('/analytics/cwv', {body, method: 'POST', keepalive: true});
  }
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

Optimization workflow:

  1. Measure — identify the worst-performing pages and metrics using Search Console and CrUX
  2. Diagnose — use Lighthouse, DevTools, and WebPageTest to pinpoint specific bottlenecks
  3. Fix — implement changes, starting with highest-impact/lowest-effort wins
  4. Validate — test in lab tools immediately, then wait 28 days for field data to update
  5. Monitor — set up alerts for regressions and repeat the cycle

📌 Key Takeaway: Set up automated monitoring and performance budgets. Treat performance as a continuous process, not a one-off task.

Frequently Asked Questions

What are Core Web Vitals and why do they matter for SEO?

Core Web Vitals are three Google-defined metrics — LCP (loading), INP (interactivity), and CLS (visual stability) — that measure real user experience. They are confirmed Google ranking signals, and pages passing all three thresholds are 24% less likely to be abandoned by users.

How do I check my Core Web Vitals scores?

Use Google PageSpeed Insights for both lab and field data, Google Search Console for site-wide status, Chrome DevTools for deep analysis, and the Web Vitals Chrome extension for real-time monitoring. Always prioritize field data (CrUX) over lab scores.

What is a good Lighthouse score in 2025?

A score of 90+ (green) is considered good. However, Lighthouse is a lab tool — field data determines your actual Core Web Vitals status. Focus on meeting field thresholds: LCP < 2.5s, INP < 200ms, CLS < 0.1.

What replaced FID in Core Web Vitals?

Interaction to Next Paint (INP) replaced FID in March 2024. INP measures the latency of all interactions throughout a page visit, not just the first one, making it a more comprehensive responsiveness metric. A good INP score is 200ms or less.

How long does it take to see SEO results after fixing Core Web Vitals?

CrUX data updates on a 28-day rolling window. Ranking improvements typically appear 2-8 weeks after Google processes the improved field data. Sites going from “poor” to “good” on all metrics see the most noticeable improvements.

Can Core Web Vitals affect my e-commerce conversion rate?

Absolutely. Studies show a 100ms improvement in load time can increase conversions by up to 7% (Akamai). Vodafone saw an 8% sales increase from 31% better LCP. On Prestashop and other e-commerce platforms, performance optimization directly correlates with higher revenue per session.

Do Core Web Vitals apply to mobile and desktop separately?

Yes, Google evaluates and reports Core Web Vitals separately for mobile and desktop. Since Google uses mobile-first indexing, mobile scores are typically more important for rankings. Mobile scores are often worse due to slower devices and network conditions.

Conclusion

Optimizing Core Web Vitals is no longer optional — it’s a fundamental requirement for competitive search visibility and exceptional user experience. As this core web vitals optimization guide has demonstrated, the path to green metrics involves a combination of server-side improvements (TTFB, caching, CDN), asset optimization (images, fonts, CSS), JavaScript management (code splitting, deferring, breaking long tasks), and layout stability (explicit dimensions, reserved space, transform-based animations).

The good news: every improvement you make for Core Web Vitals also improves your user experience, conversion rate, and brand perception. It’s a rare SEO initiative where what’s good for Google is also genuinely good for your users and your bottom line.

Here’s your action plan:

  1. Run your key pages through PageSpeed Insights and note both lab and field data
  2. Check Google Search Console’s Core Web Vitals report for site-wide issues
  3. Prioritize fixes by impact: LCP image optimization and server caching first, then JavaScript for INP, then CLS fixes
  4. Implement changes, validate in lab tools, and monitor field data over the following 28 days
  5. Set up continuous monitoring with Lighthouse CI and RUM

Need expert help? At Lueur Externe, we’ve been building and optimizing high-performance websites since 2003. As certified Prestashop Experts and AWS Solutions Architects based in the Alpes-Maritimes, we combine deep technical expertise with proven SEO strategy to deliver measurable results. Whether you’re running an e-commerce store that needs sub-2-second LCP or a content site struggling with CLS, our team can diagnose, fix, and monitor your Core Web Vitals — so you can focus on growing your business.

Contact Lueur Externe → for a free Core Web Vitals audit of your site.

Explore more performance and SEO resources on the Lueur Externe blog, and discover our full range of web development and optimization services.