Core Web Vitals History & Competitor Comparison

Free, no signup. Lab tests tell you how a page performs on your machine; Chrome's real users tell you how it performs on theirs. Chart 40 weeks of that field data — the same numbers Google uses for ranking — for up to 5 sites side by side.

Built by Patrick Stox

device origins (bare domains) have the most data; deep URLs need enough Chrome traffic of their own chart

Checks run from our server; we fetch the URL you enter and don't keep the results. Results are cached at the edge until the next weekly refresh. Anonymous aggregate stats count a domain once via a rotating hash for research posts. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Crux Tracker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
   
  
  
 

Data: Chrome UX Report History API — weekly p75 values over 28-day rolling collection
        periods, updated every Monday. A site only appears when enough Chrome users visit it.

 
    
 
Sample report
 
Add one origin on mobile:
 
 
example.com          (origin — most CrUX data)
competitor.com       (add up to 5)
device: mobile
 
 
…and the scorecard returns:
 
Illustrative example — real CrUX field data requires a live API lookup this static page can't make; the pass verdict bucketing shown matches this tool's actual good/needs-improvement/poor thresholds
 
 
 
example.com
 
Core Web Vitals not passing
 
 
LCP2.30 sas of 2026-07-06▼ 8% / 39w
 
INP240 msas of 2026-06-29▲ 5% / 38w
 
CLS0.06as of 2026-07-06▼ 12% / 39w
 
 
 FCP 1.60 s TTFB 620 ms 
 
 
 
     
  • INP sits in needs-improvement, not poor — 240 ms is over the 200 ms good
            threshold but under the 500 ms poor threshold, so it gets the amber band, not red. See
the full threshold table ↓.
    •  
  • One non-good metric still keeps the whole origin from passing — Google's Core Web Vitals
            pass requires all three core metrics good simultaneously, so LCP and CLS being good doesn't offset
            an amber INP.
    •  
  • The arrows are 40-week trend, not this week's change — LCP and CLS trending down
            (better) while INP creeps up 5% tells you which metric to prioritize fixing first: slow
            interactions, not loading or layout shift. Cross-check the interaction-heavy pages with the
Core Web Vitals Checker for a per-URL diagnosis.
    •  
 
 
 
How to use it
 
     
  1. Type a site into the box and press Add. A bare origin like
example.com has the most CrUX data; you can also add a specific URL. Repeat to
            stack up to 5 targets for a side-by-side race.
    2.  
  2. Pick the device — mobile or desktop. CrUX keeps separate field data per form
            factor, and mobile is usually the harder board to pass.
    3.  
  3. Press Compare. You get a scorecard per site (current LCP, INP, CLS with a
            pass verdict) and a weekly trend chart per metric spanning up to 40 weeks.
    4.  
  4. Read the scorecard first for today's standing, then the charts to see the trajectory — whether
            a metric is drifting toward or away from the good band. Use Export CSV or
Copy share link to save or send the exact comparison.
    5.  
  5. Switch to the Leaderboard tab to rank a whole field of sites on one metric at
            a time, or on the overall Core Web Vitals pass.
    6.  
 
 

Checking a single page's field data right now? Use the
Core Web Vitals Checker. Want the numbers explained?
          Read the Core Web Vitals guide.

 
How to read the result
 
Each metric tile is coloured by its p75 value against the official Core Web Vitals thresholds:
 
     
  • Good (green) — LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.10.
    •  
  • Needs improvement (amber) — between the two thresholds: LCP 2.5–4 s,
            INP 200–500 ms, CLS 0.10–0.25.
    •  
  • Poor (red) — LCP > 4 s, INP > 500 ms, CLS > 0.25.
    •  
 
The card verdict rolls those three up:
 
     
  • passes Core Web Vitals — all three core metrics (LCP, INP, CLS) are good.
    •  
  • Not passing — at least one core metric is needs-improvement or poor.
    •  
  • incomplete data / no CrUX data — CrUX has no stable sample for one or more
            core metrics on this target and device, so no pass verdict is asserted.
    •  
 

FCP and TTFB show below the core three as supporting diagnostics (they are not part of the
          Core Web Vitals pass). Each core tile also carries a 40-week delta so you can see direction, and
          the trend charts shade the good, needs-improvement, and poor bands behind every line.

 
Data sources & freshness
 

The tool calls the Google Chrome UX Report History API through a cached edge
          proxy. That API returns up to 40 weekly data points per metric, each the p75 across a 28-day
          rolling collection window, refreshed every Monday. All the charting, bucketing, and pass verdict math
          runs client-side in your browser from that raw response; results are cached at the edge until the
          next weekly refresh, so re-running a popular comparison is instant and spends no API quota.

 

The number for each metric is the p75 — the value 75% of real Chrome visits were
          at or below — which is the exact figure Google evaluates. A site only appears when it has enough
          Chrome traffic to form a stable sample; targets below that bar are reported as
no CrUX data rather than guessed.

 
Features
 
     
  • Up to 40 weeks of history per metric — LCP, INP, CLS, plus FCP and TTFB as diagnostics.
    •  
  • Compare up to 5 origins or URLs on one chart, colour-coded per target.
    •  
  • Per-site scorecard with a Core Web Vitals pass verdict and a 40-week trend delta per metric.
    •  
  • Trend charts with shaded good / needs-improvement / poor bands behind every line.
    •  
  • Mobile and desktop toggle — CrUX field data is kept separate per device.
    •  
  • Leaderboard mode: rank a curated group or your own list of origins on any single metric or on
            the overall Core Web Vitals pass.
    •  
  • Shareable link that restores the exact comparison, plus CSV export of every weekly value.
    •  
 
Limitations
 

This is field data, not a lab audit. It tells you what real users experienced, not
which element or script caused it — for that, run a lab tool on the page. Sites without
          enough Chrome traffic return no data and cannot be charted, and deep URLs often have less coverage
          than their origin. The values reflect a trailing 28-day window and refresh weekly, so a fix you
          shipped this morning will not show up for days. And because CrUX is Chrome-only, traffic from other
          browsers is not represented.

 
Frequently asked questions
 
What is CrUX field data and how is it different from a Lighthouse score?
CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. is the Chrome UX Report — real Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. measurements collected from actual Chrome users who opted in to sharing usage statistics. It is field data: what people really experienced on your pages. A LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or PageSpeed lab score is a single simulated load on one throttled device, useful for debugging but not what Google uses for ranking. Google ranks on the field (CrUX) data, which is exactly what this tool charts.
What are the Core Web Vitals thresholds?
A metric is "good" if its 75th-percentile value stays at or below the good threshold: LCP 2.5 seconds, INP 200 milliseconds, and CLS 0.10. It is "poor" above the poor threshold: LCP 4 seconds, INP 500 milliseconds, and CLS 0.25. Anything between the two is "needs improvement." A site passes Core Web Vitals only when all three of LCP, INP, and CLS are in the good range.
Why does my site show "no CrUX data"?
CrUX only reports a URL or origin once it has enough real Chrome traffic to form a stable sample. New pages, low-traffic sites, and specific deep URLs often fall below that bar. Bare origins (your root domain) collect far more visits than any single page, so if a deep URL returns nothing, try the origin instead — it usually has data even when individual pages do not.
What does the p75 value mean?
CrUX reports the 75th percentile of each metric — the value that 75% of visits were at or below. It is deliberately stricter than an average: it means three out of four of your real visits were at least this fast, so a fast median cannot hide a slow tail. Google uses this same p75 value to decide whether each metric is good, needs improvement, or poor.
How often does the CrUX History data update, and how far back does it go?
The History API returns weekly data points, each a 28-day rolling collection window, refreshed every Monday. This tool charts up to 40 of those weekly periods — roughly the trailing year — so you can see whether a fix actually moved the field data and when a regression began, rather than just today's snapshot.
 
 
     
 Local data 
Saved targets, named lists, and recent check summaries remain only in this browser.
 
   
 
    
 
   
Next stepPage Speed Test & Core Web Vitals Checker — verify it with a direct check.

Explore more
ToolHTTP Header CheckerToolDNS CheckerToolHosting CheckerArticleLargest Contentful Paint (LCP)ArticleFirst Contentful Paint (FCP)ArticleLazy Loading
 
 
 
Feature requests for Crux Tracker
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
         
 
Common issues & how to fix them
  
     
  •  Errors LCP is in the poor band Fix: Identify the recurring LCP element on affected templates, reduce its server/render/resource delay, and confirm improvement in a later CrUX period. 
  •  Warnings LCP needs improvement Fix: Identify the recurring LCP element on affected templates, reduce its server/render/resource delay, and confirm improvement in a later CrUX period. 
  •  Errors INP is in the poor band Fix: Profile slow interactions, split long main-thread tasks, and confirm the p75 INP trend in later field-data periods. 
  •  Warnings INP needs improvement Fix: Profile slow interactions, split long main-thread tasks, and confirm the p75 INP trend in later field-data periods. 
  •  Errors CLS is in the poor band Fix: Reserve layout space for media and injected UI, then confirm the p75 CLS trend in later field-data periods. 
  •  Warnings CLS needs improvement Fix: Reserve layout space for media and injected UI, then confirm the p75 CLS trend in later field-data periods. 
  •  Warnings Metric trend is worsening Fix: Address the component driving the decline and confirm improvement with a fresh period. 
  •  Information CrUX history is incomplete Fix: Try the bare origin for a larger sample and wait for enough real Chrome traffic; do not infer a pass from missing history. 
    •