Page Speed July 2026 · 9 min read

What Are Core Web Vitals?

Core Web Vitals are a set of real-world, user-centered metrics that Google uses to measure the quality of a user's experience on a web page. Introduced in 2020 and officially adopted as a ranking signal in 2021, these metrics focus on三个方面: loading performance, interactivity, and visual stability. The three Core Web Vitals metrics are Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP), which replaced First Input Delay (FID) in March 2024.

LCP measures how quickly the main content of a page loads. CLS quantifies how much the page layout shifts unexpectedly during loading. INP assesses how responsive a page is to user interactions like clicks and taps. Together, these three metrics provide a comprehensive picture of what real users actually experience when visiting a website. Google's goal was simple: create a measurable, field-based standard that pushes the web toward better performance for everyone.

Before Core Web Vitals, performance metrics like Load Time or DOM Content Loaded were commonly used, but they measured technical milestones rather than user experience. A page could technically finish loading while still showing a blank area to the user. Core Web Vitals shifted the focus to what matters most what the user sees and interacts with.

Why Core Web Vitals Matter for SEO

Since the Page Experience update in June 2021, Core Web Vitals have been a direct ranking factor in Google's search algorithm. Pages that meet the "good" thresholds for all three metrics are eligible for a ranking boost, especially in mobile search results. Google has repeatedly stated that page experience signals help prioritize pages that offer the best overall user experience.

The SEO impact goes beyond the direct ranking signal. Core Web Vitals correlate strongly with business metrics. Studies from Google and third-party researchers show that pages with poor LCP scores above 4 seconds see bounce rates increase by over 90%. Similarly, pages with high CLS scores can reduce conversion rates because users accidentally tap the wrong button when the layout shifts at the wrong moment.

For competitive keywords where dozens of pages offer similar content, Core Web Vitals can be the deciding factor that pushes one page ahead of another. Google has also confirmed that good Core Web Vitals do not guarantee a top ranking, but poor Core Web Vitals can hold back an otherwise well-optimized page. In other words, they are a necessary but not sufficient condition for strong search performance. With the rollout of INP replacing FID, the bar for interactivity is now higher than ever, and sites that fail to optimize risk losing ground in search results through 2026 and beyond.

LCP (Largest Contentful Paint)

Largest Contentful Paint measures the time from when the user first requests a page until the largest visible element (usually a hero image, heading, or video poster) is fully rendered in the viewport. A good LCP score is 2.5 seconds or faster. Scores between 2.5 and 4.0 seconds need improvement, and anything above 4.0 seconds is considered poor.

The most common causes of slow LCP include large unoptimized images, slow server response times, render-blocking JavaScript and CSS, and resource discovery issues. Here are the most effective ways to fix LCP:

Optimize images. Compress images with modern formats like WebP or AVIF, serve responsive images using srcset and sizes attributes, and lazy load below-the-fold assets. Large hero images should never exceed 200 KB when possible.

Reduce server response time. Aim for a Time to First Byte (TTFB) under 800 milliseconds. Use a fast hosting provider, enable server-side caching, implement a CDN, and optimize database queries if you use a CMS.

Eliminate render-blocking resources. Defer non-critical CSS and JavaScript, inline critical CSS in the document head, and use the async or defer attributes on script tags so the browser can render content while scripts are still loading.

Preload key assets. Use the preload link tag to hint the browser to fetch your hero image and critical fonts early in the loading process. For example, <link rel="preload" href="hero.webp" as="image">.

Use a CDN. Content Delivery Networks serve your assets from edge locations close to the user, reducing network latency. This is especially impactful for global audiences and can shave hundreds of milliseconds off LCP.

CLS (Cumulative Layout Shift)

Cumulative Layout Shift measures the sum total of all unexpected layout shifts that occur during the entire lifespan of a page. A layout shift happens when a visible element changes its position from one frame to the next, often because an image or ad loads after the surrounding content has already been rendered. A good CLS score is less than 0.1. Scores between 0.1 and 0.25 need improvement, and anything above 0.25 is poor.

Layout shifts are incredibly frustrating for users. Imagine reading an article when an ad loads above the text and pushes everything down by 500 pixels, causing you to lose your place. Google considers this a poor user experience because it often leads to accidental clicks on the wrong links or buttons. Here is how to fix CLS:

Set explicit dimensions on images and videos. Always include width and height attributes on your image and video elements, even if you plan to use CSS to make them responsive. Modern CSS can still respect aspect ratios when dimensions are provided: img { width: 100%; height: auto; aspect-ratio: 16 / 9; }.

Reserve space for embeds and ads. When loading third-party embeds like YouTube videos, Google Maps, or advertisements, reserve the exact space they will occupy before they load. Use placeholder containers with fixed dimensions or known aspect ratios so the rest of the page does not jump when they appear.

Avoid inserting content above existing content. Banners, cookie notices, newsletters signup forms, and promotional overlays should never be injected at the top of the page after the main content has already rendered. If you must use them, reserve the space ahead of time or use a fixed overlay approach that does not shift the document flow.

Use transform animations instead of layout-triggering properties. Animating properties like width, height, margin, or top triggers layout recalculations that can cause CLS. Whenever possible, use CSS transform and opacity for animations, because these properties do not trigger layout changes.

INP (Interaction to Next Paint)

Interaction to Next Paint replaced First Input Delay (FID) as a Core Web Vital in March 2024. While FID measured only the initial delay before the browser could handle the first interaction, INP evaluates the responsiveness of every single interaction a user makes with the page, including clicks, taps, and key presses. INP measures the time from when a user initiates an interaction to when the next frame is painted in response. A good INP score is 200 milliseconds or faster. Scores between 200 and 500 ms need improvement, and anything above 500 ms is poor.

INP is a more accurate and comprehensive metric than FID because it captures the full range of interactions across the page lifecycle, not just the first one. This is especially important for single-page applications, complex forms, and interactive dashboards where users perform many actions during a session. Here is how to fix INP:

Break up long tasks. The main thread in the browser can only handle one task at a time. If a task takes longer than 50 milliseconds, it is considered a "long task" and blocks user interactions. Use techniques like yielding to the main thread with setTimeout or scheduler.yield to break long JavaScript tasks into smaller chunks.

Reduce JavaScript execution time. Audit your JavaScript bundles and remove unused code. Use code splitting to load only the JavaScript needed for each page. Minimize and tree-shake your production bundles. Consider using frameworks that ship less client-side JavaScript.

Use Web Workers. Web Workers allow you to run JavaScript on background threads separate from the main thread. If your page performs heavy computations such as data processing, image manipulation, or encryption, move that work to a Web Worker so the main thread stays responsive to user input.

Lazy load third-party scripts. Third-party scripts for analytics, ads, social media widgets, and chatbots are among the biggest contributors to poor INP. Load them asynchronously, defer them until after the page is interactive, or use techniques like partytown to offload them to Web Workers. Audit every third-party script and remove any that are not essential.

How to Check Your Core Web Vitals Score

There are several free and paid tools available to measure your Core Web Vitals scores from both lab data (controlled tests) and field data (real users). Here are the most reliable options:

Google Search Console. The Core Web Vitals report in Search Console shows which pages on your site are poor, need improvement, or good based on real user data from the Chrome User Experience Report (CrUX). This is the best starting point for site-wide analysis.

PageSpeed Insights. Enter any URL and get both lab data from Lighthouse and field data from CrUX. It provides specific recommendations for improving each metric along with estimated savings.

Chrome DevTools. The Performance panel and Lighthouse tab in Chrome allow you to audit any page in real time. The Performance Insights panel is particularly useful for diagnosing INP issues because it highlights long tasks and interaction delays.

NexGenWebLab PageSpeed Tool. Our free tool provides instant Core Web Vitals analysis with actionable recommendations. Unlike some tools, it also tracks your scores over time so you can measure the impact of your optimizations.

CrUX API. For developers who want to automate performance monitoring, the Chrome UX Report API provides programmatic access to field data for any origin. You can query LCP, CLS, INP, and FCP at the 75th percentile.

Core Web Vitals Tools Comparison

Frequently Asked Questions

Do Core Web Vitals affect mobile and desktop rankings differently?

Yes. Google evaluates Core Web Vitals independently for mobile and desktop. A page may have good scores on desktop but poor scores on mobile due to slower network speeds, smaller viewports, and different rendering behavior. You should monitor both versions separately using Google Search Console's device-specific reports.

Can I have a good PageSpeed score but still have poor Core Web Vitals?

Absolutely. PageSpeed Insights and Lighthouse scores are lab-based measurements that run on a simulated device and network. They can show different results from field data collected by real users. It is possible to score 100 on Lighthouse while actual users experience poor LCP or CLS because field data accounts for real-world device diversity, network variability, and dynamic content. Always prioritize field data from CrUX for the most accurate picture.

How often should I check my Core Web Vitals?

Core Web Vitals should be monitored continuously, not as a one-time fix. Performance can regress with any code change, new third-party script, or content update. Set up monthly audits using PageSpeed Insights or NexGenWebLab's tracking tool. If you deploy frequently, consider integrating performance monitoring into your CI/CD pipeline to catch regressions before they impact users and rankings.

Core Web Vitals are not a one-time optimization checklist. They represent an ongoing commitment to user experience. By understanding each metric, monitoring your scores regularly, and applying the fixes outlined in this guide, you can improve your search rankings, reduce bounce rates, and deliver a faster, more pleasant experience for every visitor. Start with a free check of your site's Core Web Vitals today.