Free · Fast · Privacy-first

Core Web Vitals Checker

Core Web Vitals are Google's official page experience metrics, comprising LCP for loading, CLS for visual stability, and FID/INP for interactivity, which together form the three-pillar evaluation that feeds directly into the Page Experience ranking signal in Google search.

⚡

LCP, CLS, and FID/INP measurement

🔒

Pass/fail threshold indicators

✨

Mobile and desktop results

⚡

No sign-up required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Website Speed Test to your website

Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Core Web Vitals Explained: LCP, CLS, and INP and Why They Determine Your Rankings

Core Web Vitals are Google's standardised set of user experience metrics that measure the three most important aspects of the web page experience: loading performance, visual stability, and interactivity. Largest Contentful Paint (LCP) measures loading by capturing how quickly the largest visible content element (image, text block, or video) finishes rendering in the viewport. Google's threshold is 2.5 seconds for Good, between 2.5 and 4 seconds for Needs Improvement, and above 4 seconds for Poor. Cumulative Layout Shift (CLS) measures visual stability by quantifying how much elements move around during page load due to late-loading content, ads, or fonts. The Good threshold is a CLS score of 0.1 or lower. Interaction to Next Paint (INP), which replaced FID (First Input Delay) as a Core Web Vital in March 2024, measures responsiveness by tracking how quickly the page responds to user interactions across the entire visit. Good INP is under 200ms.

Google has confirmed that Core Web Vitals are explicit ranking signals in its search algorithm as part of the Page Experience update rolled out for mobile in 2021 and extended to desktop in 2022. Pages failing Core Web Vitals, particularly on mobile, are at a measurable disadvantage against pages that pass all three thresholds. The Google Search Console Core Web Vitals report under the Enhancements section shows which pages on your site are passing, need improvement, or are failing each metric using real field data collected from actual users visiting your site with the Chrome browser over a 28-day rolling window. This report is the most direct indicator of how Google perceives your site's performance and the data source that ultimately feeds into ranking decisions.

Core Web Vitals have different primary causes and fixes that map to the underlying mechanism of each metric. Poor LCP is most often caused by slow server response time, render-blocking resources that delay image loading, or large uncompressed images that take too long to download. Poor CLS is most often caused by images without explicit width and height attributes that cause reflow when they load, late-injected banner ads or cookie banners pushing content down, or web fonts that cause text to shift when the custom font swaps in after the fallback. Poor INP is most often caused by heavy JavaScript execution on the main thread, long tasks over 50ms that delay the browser's ability to respond to user input, or inefficient event handler code that does too much synchronous work in response to clicks.

Passing all three Core Web Vitals is a higher bar than passing any one of them, because all three must clear their respective Good thresholds for the page to qualify for the full Page Experience boost in search rankings. A page passing two thresholds but failing the third sees no benefit beyond what the third metric allows. This all-or-nothing structure means that diagnostic and optimisation work must be balanced across all three metrics rather than focused exclusively on the most familiar one. Many teams correctly identify LCP as the most weighted metric in the Lighthouse score and pour effort into image optimisation, only to discover that an unaddressed CLS issue from a cookie banner or an unaddressed INP issue from a tag manager prevents the page from passing as Good in Search Console regardless of how fast the LCP eventually becomes.

web.dev: Core Web Vitals, The Three Metrics Google Search Central: Core Web Vitals and Search

How to use this tool

💡

Enter your URL to check all three Core Web Vitals against Google's Pass/Needs Improvement/Fail thresholds.

How It Works

Step-by-step guide to core web vitals checker:

1
Enter your URL
Paste the page URL you want to check, prioritising your highest-traffic and most commercially important pages rather than spending the audit on URLs that drive little business value. The audit takes the same amount of time regardless of which page you test, so the cost of testing the right page versus the wrong page is the same while the benefit is dramatically different. Build a short prioritised list before starting the audit session.
2
Review the three Core Web Vitals
Check LCP against the Good threshold of 2.5 seconds, CLS against the threshold of 0.1, and INP against the threshold of 200ms. Note carefully which metrics fall in the Poor range and which sit in the Needs Improvement band, because the optimisation approach differs between the two. A metric in Needs Improvement often responds to incremental fixes, while a metric in Poor typically requires structural intervention.
3
Identify the root cause of failing metrics
Use the detailed report to identify which specific resources or elements are causing each failing metric, because the right fix depends entirely on the underlying cause. LCP failures usually point to a specific element such as a hero image; CLS failures usually point to a specific shifting element such as an ad slot; INP failures usually point to a specific JavaScript task. Capture the attribution data carefully so the subsequent fix work targets the correct cause rather than a generic prescription.
4
Implement fixes and re-test
Make targeted improvements to each failing metric in isolation, then re-test after each individual change so you know which intervention produced which improvement. Batching multiple changes into a single deployment makes it impossible to attribute the resulting score change to any specific fix, which complicates future decisions about where to invest engineering time. Sequence the work so the biggest expected gains happen first and the audit cycle stays tight enough to maintain momentum.

Real-world examples

Common situations where this approach makes a real difference:

SEO ranking investigation

A site owner noticing a 12 per cent rankings drop in the weeks after a Google algorithm update checks Core Web Vitals across the affected URL groups and discovers that CLS has increased from a healthy 0.05 to a failing 0.35 ever since a third-party advertising script was added to the article template six weeks earlier. The team removes the offending script, replaces it with a lighter alternative that uses reserved CSS space for its slot, and watches CrUX field data recover over the next two updates. Rankings return to their previous positions within two months as the field data normalises.

New theme deployment

A WordPress site owner testing a new theme on staging before activation runs the Core Web Vitals checker and discovers that the new theme's hero image is producing an LCP of 5.2 seconds on mobile, well into the Poor range that would have damaged Page Experience signals from day one of the launch. They replace the hero with an optimised WebP variant, add a preload hint in the head, and rerun the check to confirm LCP drops to 1.8 seconds before authorising the theme switch on the live site. The launch proceeds without the SEO penalty that would have applied to a less-careful deployment.

Quarterly CWV reporting

An agency delivers a structured quarterly Core Web Vitals report to each client showing before-and-after changes across all three metrics, along with competitor benchmarks and a prioritised list of remaining issues to address in the next quarter. FixTools enables the team to check all 25 client sites rapidly within a single afternoon without running Lighthouse manually on each one, freeing capacity for the more valuable interpretation and recommendation work that the client actually pays for. The reports become a standard retention touchpoint that proves ongoing value beyond the initial optimisation project.

When to use this guide

Use this to diagnose Page Experience issues that may be holding back your search rankings, or to verify that recent optimisations have moved your Core Web Vitals into the "Good" range.

Pro tips

Get better results with these expert suggestions:

Check Search Console for field data, not just lab scores

Google uses field data from real Chrome user measurements collected via CrUX for ranking decisions, not the Lighthouse lab scores returned by ad hoc audit tools. Your Search Console Core Web Vitals report shows which pages have real-world CWV issues across URL groups. A high Lighthouse score combined with poor Search Console CWV data means your production environment differs from the lab simulation in ways worth investigating, such as third-party scripts loaded conditionally, CDN configuration that misses certain users, or caching layers that work in staging but not in production.

Fix LCP first, it has the most ranking impact

Of the three Core Web Vitals, LCP is the most impactful for user perception and carries the highest weight in the Lighthouse composite score, so prioritising LCP work usually delivers the most visible improvement per unit of effort invested. Ensure your server TTFB is under 800ms before attempting front-end LCP fixes. Preload your LCP image with a link rel="preload" hint in the head, compress and convert it to WebP for smaller file size, and avoid placing render-blocking resources in the critical path before the LCP element is parsed and discovered.

Always set image dimensions to prevent CLS

The most common cause of poor CLS is images without explicit width and height attributes in the HTML. When a browser downloads an image without knowing its intrinsic dimensions, it cannot reserve the correct layout space, which causes content below the image to jump downward when the image data finally arrives. Add width and height attributes to every img tag across the site, which is a mechanical change that takes minutes per template and immediately improves CLS in a measurable way that shows up in the next Lighthouse audit without further intervention.

Use the INP debugger in Chrome DevTools

Chrome DevTools' Performance Insights panel, accessible under More Tools, shows INP events and identifies which JavaScript tasks are causing interaction delays during real interaction recordings. The Long Tasks panel highlights tasks over 50ms that block the main thread and prevent the browser from responding to user input. Profiling your page's interaction performance in DevTools pinpoints exactly which code is responsible for INP failures, including the specific function calls and the stack traces that produced them, so the resulting fix targets the actual root cause.

LCP is the most impactful metric to fix

LCP (Largest Contentful Paint) measures when the main content of a page is visible. It has the highest weighting in the Lighthouse score and the most direct correlation with user perception of page speed. Fix LCP first.

CLS is often caused by images or ads without dimensions

Cumulative Layout Shift (CLS) measures unexpected page movement while loading. The most common cause is images, ad slots, or embedded content loading without specified width and height attributes, causing content below to jump.

INP replaced FID in March 2024

Interaction to Next Paint (INP) replaced First Input Delay as the interactivity Core Web Vital in March 2024. INP measures the full interactivity of the page across all interactions, not just the first one.

FAQ

Frequently asked questions

Core Web Vitals are three user experience metrics defined by Google that measure loading via LCP (Largest Contentful Paint), visual stability via CLS (Cumulative Layout Shift), and interactivity via INP (Interaction to Next Paint). Google uses these three metrics as explicit ranking signals in its search algorithm as part of the Page Experience update that has been live since 2021. Pages that pass all three thresholds, defined as LCP under 2.5 seconds, CLS under 0.1, and INP under 200ms, qualify as Good in Search Console and receive the Page Experience boost in ranking calculations. The all-or-nothing structure means a page must pass every threshold rather than averaging across them.

Yes, directly and measurably. Google confirmed Core Web Vitals as explicit ranking signals in its Page Experience update, which rolled out for mobile in 2021 and for desktop in 2022. They function primarily as a tie-breaking factor: when two pages have similar content quality and backlink authority profiles, the one with better Core Web Vitals scores tends to rank higher in the results. Their influence is most visible in competitive SERPs where top-ranking pages have comparable content authority and the algorithm needs additional signals to differentiate them. In less competitive categories, content quality remains the dominant factor and Core Web Vitals matter less in practice.

Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024 after a multi-year transition during which both metrics were reported in parallel so teams could prepare. FID only measured the delay before the first interaction on a page, which made it easy to optimise for that specific moment while ignoring every subsequent interaction during the same visit. INP measures the responsiveness of all interactions throughout the entire page lifecycle and reports the worst-case latency excluding outliers, providing a more comprehensive picture of interactivity. INP under 200ms is Good, 200 to 500ms is Needs Improvement, and above 500ms is Poor.

Three main approaches cover different parts of the workflow. Google Search Console's Core Web Vitals report shows field data from real users segmented by URL group, which is the authoritative data source for ranking decisions. PageSpeed Insights shows both lab data from Lighthouse and field data from CrUX for a specific URL, providing the most complete single-URL view. Chrome DevTools' Performance panel provides detailed per-session profiling for diagnosis during active optimisation. The Search Console report is most authoritative for understanding ranking impact, while the other tools support faster iteration during the fix cycle.

Google's Core Web Vitals thresholds for CLS define Good as 0.1 or lower, Needs Improvement between 0.1 and 0.25, and Poor as anything above 0.25. CLS is a unitless ratio representing how much content shifts during the page load weighted by how far it moves and how much of the viewport is affected. A score of 0.1 means the cumulative unexpected movement represents approximately 10 per cent of the viewport area. Most CLS issues are fixable by adding explicit width and height attributes to images and videos, reserving space for ads and banners with min-height CSS, and avoiding inserting content above existing content during the load sequence.

INP measures how quickly a page responds to user interactions including clicks, taps, and keyboard input by capturing the latency from input to next visual update. It replaced FID in March 2024 because it measures all interactions during the visit rather than only the first one, which makes it more representative of actual user experience. To improve INP, break up long JavaScript tasks into smaller chunks using setTimeout, scheduler.yield, or Promise.then to create yield points where the browser can process input. Defer non-essential JavaScript, avoid complex layout recalculations in event handlers, and use Web Workers for CPU-intensive operations that do not need DOM access.

CrUX data is updated using a 28-day rolling window of real Chrome user measurements, which means your Search Console CWV data will only fully reflect a deployed improvement after the old measurements have completely aged out of the window. Expect Search Console CWV status to start updating within 28 days and to settle completely between 28 and 56 days after the deployment. Ranking changes from CWV improvements are gradual and incremental rather than abrupt, and they are most visible over a 2 to 3 month period following significant performance work as the cumulative effect compounds across the rolling field data.

Yes, and this is one of the most common patterns seen in production sites that have done partial optimisation work without auditing all three metrics. A page passing LCP and CLS but failing INP, for example, will not receive the full Page Experience boost despite the strong performance on two of the three metrics. The all-or-nothing structure of the Core Web Vitals signal means that engineering effort spent reaching Good on only one or two metrics is wasted from a ranking perspective if the third metric remains in Poor or Needs Improvement. Always audit all three metrics and plan the optimisation roadmap to clear all three thresholds rather than focusing narrowly on the most familiar one.

Core Web Vitals apply to every page on your site that is indexed by Google, and Search Console reports CWV status at the URL-group level by clustering similar URLs together based on template patterns. Different page types on the same site often have different CWV characteristics: homepages may pass comfortably while product pages fail due to heavier images, or article templates may pass while category templates fail due to ad-driven CLS. Always check the per-URL-group breakdown in Search Console rather than assuming the homepage result is representative, because the templates that drive the most traffic are often not the ones that pass most easily.

The field data Google uses for ranking is collected specifically from the Chrome browser via the Chrome User Experience Report, so technically yes, CrUX measurements depend on Chrome user visits. Other browsers may have different real-world performance characteristics but those measurements do not feed into the ranking signal. Lab measurements via Lighthouse or PageSpeed Insights also use Chrome under the hood. This Chrome-only dependency matters less than it might seem because Chrome's market share is dominant enough that the field data is broadly representative, and the optimisations that improve Chrome performance generally also improve performance for users on other browsers.