Skip to main content

Sigmato | Software & Mobile App Development Company

Website Design

Core Web Vitals: How to Make Your Website Pass

By Sigmato Editorial TeamUpdated 9 Nov 20266 min read

Website speed analytics dashboard showing Core Web Vitals results

Core Web Vitals are three metrics Google uses to measure real-world user experience on a web page: how fast the main content loads, how quickly the page responds to input, and how stable the layout is while loading. They are part of the page experience signals Google Search considers, and, more importantly, they track closely with what users feel. Slow, jumpy pages lose visitors and sales. The good news is that most sites can pass with a focused set of fixes.

This guide explains each metric, the thresholds you need to hit, how to measure correctly, and the specific fixes our developers apply most often.

The Three Core Web Vitals and Their Thresholds

The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). A page passes when at least 75% of real visits meet the “good” threshold for all three, measured separately for mobile and desktop.

MetricWhat it measuresGoodNeeds improvementPoor
Largest Contentful Paint (LCP)Loading: when the largest image or text block becomes visible≤ 2.5 s2.5 – 4.0 s> 4.0 s
Interaction to Next Paint (INP)Responsiveness: delay between a click, tap or key press and the next visual update≤ 200 ms200 – 500 ms> 500 ms
Cumulative Layout Shift (CLS)Visual stability: how much content unexpectedly moves≤ 0.10.1 – 0.25> 0.25
Thresholds as published by Google on web.dev, assessed at the 75th percentile of page loads.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP is stricter because it considers interactions throughout the visit, not just the first one. The official definitions are on web.dev, and Google explains how they relate to search in its Search Central documentation.

How to Measure Core Web Vitals Correctly

Use field data from real users to judge whether you pass, and lab data to diagnose why. Mixing them up is the most common reason teams “fix” a score that never changes in Search Console.

  • Field data comes from the Chrome User Experience Report (CrUX), which aggregates real Chrome visits over a rolling 28-day window. This is what Google uses.
  • Lab data comes from tools such as Lighthouse, which simulate a single load on a set device and network. It is great for debugging but does not determine whether you pass.

Practical tools:

  1. PageSpeed Insights shows both field data (when available) and a Lighthouse lab test for any URL.
  2. Google Search Console groups your URLs into good, needs improvement and poor in its Core Web Vitals report.
  3. Chrome DevTools Performance panel helps find the exact scripts, images or layout shifts behind a poor score.
  4. Real user monitoring with the open-source web-vitals JavaScript library sends metrics to your own analytics, so you see results by page, device and country without waiting 28 days.
Developer optimizing website performance on a laptop

How to Fix Largest Contentful Paint (LCP)

Poor LCP is usually caused by a slow server response, a large or late-loading hero image, or render-blocking CSS and JavaScript. Fix them in that order.

  • Cut server response time. Use page caching, a CDN and efficient database queries. Aim for a time to first byte well under one second.
  • Optimize the LCP image. Serve it in WebP or AVIF at the displayed size, preload it or mark it with fetchpriority=”high”, and never lazy-load the hero image.
  • Remove render-blocking resources. Inline critical CSS, defer non-essential JavaScript and limit web font files.
  • Render on the server. Client-side rendered pages must download and run JavaScript before showing content. Server or static rendering, as offered by Next.js, usually improves LCP. See our Next.js vs React comparison.

How to Fix Interaction to Next Paint (INP)

Poor INP almost always means too much JavaScript running on the main thread when users interact. The fix is to do less work, break it into smaller pieces, or move it elsewhere.

  • Audit third-party scripts. Chat widgets, tag managers, A/B testing tools and ad scripts are frequent culprits. Remove what you do not use and load the rest after interaction where possible.
  • Break up long tasks. Split work over 50 ms into smaller chunks and yield to the browser so it can respond to input.
  • Give immediate visual feedback on click, then do heavy processing afterwards.
  • Reduce unnecessary re-renders in React, Vue or Angular apps, and virtualize long lists.
  • Move heavy computation to web workers or the server.

How to Fix Cumulative Layout Shift (CLS)

Layout shift happens when content loads without reserved space and pushes other content around. Reserving space for everything that loads late solves most CLS problems.

  • Set width and height attributes (or CSS aspect-ratio) on all images and videos.
  • Reserve fixed slots for ads, embeds and cookie banners.
  • Avoid inserting banners or notices above existing content after load.
  • Use font-display settings and matched fallback fonts to limit shifts when web fonts swap in.
  • Animate with transform and opacity rather than properties that change layout.

Platform-Specific Quick Wins

Each platform has predictable weak spots. Start with these before deeper engineering work.

WordPress

Heavy page builders, too many plugins and cheap shared hosting are the usual problems. Use a lightweight theme, page caching, an image optimization plugin and a CDN. Our WordPress speed optimization guide lists 20 fixes.

Shopify

Installed apps that inject scripts into every page often hurt INP and LCP. Remove unused apps, check that uninstalled apps left no leftover code in the theme, and compress hero and collection images.

Single-page applications

Large JavaScript bundles delay everything. Use code splitting by route, server-side rendering for public pages and careful state management to keep interactions fast.

What Passing Core Web Vitals Costs

Most business websites can pass with an investment of roughly $2,000–$15,000, depending on the platform and how much technical debt has built up. These are indicative figures; the final quote depends on scope.

A WordPress or Shopify site with image and plugin issues sits at the lower end. A custom single-page application that needs server-side rendering, bundle restructuring or a hosting change sits at the upper end, and occasionally beyond it when a front-end rebuild is the more economical path.

A Prioritized Plan to Pass Core Web Vitals

Fix templates, not individual pages, and focus on your highest-traffic page types first. A typical remediation project for a business website takes two to six weeks.

  1. Check Search Console to see which URL groups fail and on which device type.
  2. Identify the template behind each group: home page, product page, article, category.
  3. Diagnose with PageSpeed Insights and DevTools on a mid-range Android phone profile.
  4. Fix the largest issue per template, deploy and monitor with real user data.
  5. Add performance budgets to your CI/CD pipeline so regressions are caught before release.

Remember that Core Web Vitals are one ranking factor among many; relevant, helpful content still matters most. But faster pages almost always improve conversion rates, which our e-commerce conversion rate optimization guide explores further.

Frequently Asked Questions

Do Core Web Vitals affect Google rankings?

Yes, as part of Google’s page experience signals, but their weight is modest compared with content relevance. They matter most when competing pages are otherwise similar.

Why does my PageSpeed score differ from Search Console?

The PageSpeed performance score is a lab test of a single load, while Search Console uses 28 days of real-user field data. Only the field data determines whether you pass.

How long until fixes show up in Search Console?

Because field data covers a rolling 28-day window, improvements usually take up to four weeks to fully appear after deployment.

Is FID still a Core Web Vital?

No. Interaction to Next Paint (INP) replaced First Input Delay in March 2024.

Get Your Website into the Green

Sigmato’s website development team audits and fixes performance on WordPress, Shopify and custom React or Next.js sites. Send us your URL and we will identify the biggest wins.

Sources and References

Sigmato Editorial Team

Written by

Sigmato Editorial Team

The Sigmato Editorial Team is made up of software engineers, UI/UX designers and AI specialists at Sigmato Solutions Pvt Ltd in Bengaluru, India and the UK. We write practical guides on web, mobile, cloud and AI development, drawing on the products we design and build for startups and enterprises worldwide.

Last updated 9 November 2026 · Talk to our team