Languages

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. Research counters record run totals only; they store no URL, domain, IP, user agent, hash, or pseudonymous identifier. 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. 
  
 
  
 
 
  
 
 
   
   
  
  
 
 
 
 
Long-term SEO tool history
 
The one-year view uses 12 monthly points. Lifetime defaults to yearly aggregation and can switch to monthly detail.
 
 
      
 
 
   
Source: Chrome UX Report BigQuery monthly origin dataset. Monthly origin-level BigQuery observations remain separate from the recent weekly History API series. Annual values average available monthly p75 observations and do not bridge missing months.
 
  

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.

People also explore
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.
 
     
  
  
 
 
 
 
     
 
Where this tool helps
Common use cases
Track field performance over time
Chart up to forty weeks of p75 Core Web Vitals from the Chrome UX Report for an origin or URL.
Compare competitors
Place up to five comparable origins or URLs on one chart to understand relative field performance.
Investigate a release or regression
Look for sustained changes in LCP, INP, CLS, FCP, or TTFB around a known deployment date.
Share a performance baseline
Export the observed series or send a shareable view while noting when CrUX lacks enough eligible traffic.
Watch the full workflow
Core Web Vitals History & Competitor Comparison walkthrough
Read the transcript

      
      

        
Core Web Vitals History & Competitor Comparison

        

        
A lab test shows one simulated visit. CrUX shows what real Chrome users experienced. I’ll explain when this tracker helps, how to build a comparison, how to read the sample result and thresholds, its charts, leaderboard, exports, limitations, and the next diagnostic step.

      

      

        
Step 1

        

        
This tracker charts Chrome U-X Report field data: anonymized measurements from eligible real Chrome visits. It can compare as many as five origins or U-R-Ls over forty weekly periods. Use it to monitor user experience and competitors, not to debug a single simulated page load.

      

      

        
Step 2

        

        
Use the tool after a performance release, during a regression investigation, for monthly reporting, to compare mobile and desktop, or to benchmark a competitor set. History helps answer whether a change persisted and roughly when it began. A bare origin usually has more coverage than a deep page.

      

      

        
Step 3

        

        
Enter a bare domain or full U-R-L and select Add. Repeat for up to five targets. Choose mobile or desktop and either p-seventy-five values or visit distributions, then select Compare. Origins are the safest starting point because individual pages need enough traffic to qualify separately.

      

      

        
Step 4

        

        
The clearly labeled illustrative card shows L-C-P at two-point-three seconds and C-L-S at zero-point-zero-six, both good, while I-N-P at two-hundred-forty milliseconds needs improvement. Because all three core metrics must be good together, the origin is not passing Core Web Vitals.

      

      

        
Step 5

        

        
The arrows compare the long trend, not just this week. In the example, loading and layout shift improve while interaction latency worsens. That points the next investigation toward interaction-heavy pages. Treat the dates, direction, and metric band together instead of reducing the report to one pass label.

      

      

        
Step 6

        

        
Good p-seventy-five thresholds are L-C-P at most two-point-five seconds, I-N-P at most two hundred milliseconds, and C-L-S at most zero-point-one. Values between good and poor need improvement. Poor begins above four seconds, five hundred milliseconds, and zero-point-two-five respectively.

      

      

        
Step 7

        

        
Each weekly point represents a rolling twenty-eight-day collection window, refreshed on Monday. The charts shade good, needs-improvement, and poor bands and can include L-C-P, I-N-P, C-L-S, F-C-P, and T-T-F-B. Expect gradual movement after a fix because old visits age out over time.

      

      

        
Step 8

        

        
Switch to Leaderboard to rank a curated group, or paste up to twenty-five origins of your own. Select one metric, overall Core Web Vitals pass, and a device. This is useful for directional benchmarking, but different audiences, page mixes, devices, and traffic volumes limit one-to-one conclusions.

      

      

        
Step 9

        

        
Main features include five-target comparisons, forty weeks of history, p-seventy-five and distribution views, mobile and desktop data, threshold-colored scorecards and charts, leaderboard mode, share links, C-S-V export, and private baseline export and import. Supporting F-C-P and T-T-F-B do not affect the Core Web Vitals verdict.

      

      

        
Step 10

        

        
No CrUX data is not a failing score. It means the selected origin or page and device lacks a stable eligible sample for one or more metrics. Try the origin, confirm the form factor, or use your own analytics and lab measurements. The tool does not invent values when coverage is missing.

      

      

        
Step 11

        

        
CrUX tells you what eligible Chrome users experienced, not which element, request, or script caused it. Data is Chrome-only, coverage favors higher-traffic targets, and the rolling window delays visible changes. Competitor differences may reflect audiences and page mix, so use rankings as context rather than proof of implementation quality.

      

      

        
Step 12

        

        
Export or baseline the exact targets, form factor, dates, p-seventy-five values, and coverage notes. Choose the weakest metric, locate the change window, and test representative page templates with PageSpeed Insights, Lighthouse, the Core Web Vitals Checker, and your own telemetry. After fixing the cause, monitor several weekly windows before declaring success.

      

      

        
Find the trend, then diagnose the cause.

        

        
Use the scorecard to identify the weak metric and the history to find when it changed. Then test representative pages with lab and field tools, investigate the responsible templates or scripts, ship a focused fix, and watch later rolling windows for a durable improvement.

      

    
 
         
 
Common issues & how to fix them
 
     
  •  Error 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. 
  •  Warning 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. 
  •  Error 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. 
  •  Warning INP needs improvement Fix: Profile slow interactions, split long main-thread tasks, and confirm the p75 INP trend in later field-data periods. 
  •  Error 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. 
  •  Warning CLS needs improvement Fix: Reserve layout space for media and injected UI, then confirm the p75 CLS trend in later field-data periods. 
  •  Warning 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. 
    •