What this tool shows you
- Nine months, week by week
- 40 weekly data points per site from Google's CrUX History API, not just today's number.
- You against three competitors
- Put up to four sites or pages on the same charts, with a pass or fail for each.
- The week it changed
- Finds every 20% move and works back through the 28-day window to the week it shipped.
- All five metrics
- LCP, INP and CLS for the assessment, plus FCP and TTFB to diagnose why LCP is slow.
- Phone, desktop or both
- Field data split by device, so mobile problems don't hide behind fast desktop visits.
- The spread, not only p75
- The share of good, needs-improvement and poor visits for every week.
- Site or single page
- Type a domain for the whole site, or paste a full URL for one page.
- Why it's slow, on the page
- A Google lab test on any page: the LCP element outlined on a screenshot, its four phases, and layout shift culprits.
- Fixes ranked by time saved
- Render-blocking files, third-party cost, server response and Google's estimated savings, biggest first.
- CSV export and share links
- Download every number, or send a link that reruns the same comparison and lab test.
Google's Core Web Vitals thresholds
Google assesses each metric at the 75th percentile of real visits over 28 days. A site or page passes Core Web Vitals when LCP, INP and CLS are all in the good range.
| Metric | Good | Poor |
|---|---|---|
| LCP · Largest Contentful Paint | ≤ 2.5 s | > 4 s |
| INP · Interaction to Next Paint | ≤ 200 ms | > 500 ms |
| CLS · Cumulative Layout Shift | ≤ 0.1 | > 0.25 |
| FCP · First Contentful Paint (diagnostic) | ≤ 1.8 s | > 3 s |
| TTFB · Time to First Byte (diagnostic) | ≤ 800 ms | > 1.8 s |
Anything between good and poor counts as needs improvement.
How to find the week something changed
CrUX publishes a new data point every week, but each one covers the 28 days before it. So when a deploy makes your pages slower, the line doesn't jump. It slopes for about four weeks, until the old, faster visits have rolled out of the window.
The tool looks for the four-week span with the biggest move, at least 20%, and reports the week that span started. That's when the change went live. Check your release notes, theme or plugin updates, tag manager changes and ad setup for that week.
Why compare against competitors
Core Web Vitals work as a tiebreaker between pages that are otherwise equally relevant, so the useful question isn't only whether you pass, but whether you're faster than the pages you compete with. Seeing them on one chart also separates your own regressions from changes that hit everyone, like a Chrome release that changes how a metric is measured.
Want to know whether a slow page is a rendering problem? The SSR vs CSR Inspector shows what the crawler receives versus what the browser paints.
Frequently asked questions
Where does this data come from?
From Google's Chrome UX Report (CrUX), through its official History API. CrUX is collected from real Chrome users who have opted in, and it's the same field data Search Console's Core Web Vitals report and PageSpeed Insights use. Nothing here is a lab test or a simulation.
Why does my site show no data?
CrUX only publishes sites and pages with enough real Chrome visitors to keep the data anonymous. Small sites often have no page-level data and sometimes no site-level data either. Try the hostname with or without www, switch to All devices, or check the whole site instead of a single page.
What does p75 mean?
The 75th percentile: three quarters of visits were at least this good. Google assesses each metric at p75, so a page passes LCP when 75% of visits load the main content within 2.5 seconds.
Why do changes take weeks to show?
Each data point is a rolling 28-day window, published weekly. If you ship a fix today, next week's point contains only a week of the faster visits. It takes about four weeks for the new level to show in full. This tool finds the start of each move, which is when the change shipped.
Is a whole-site score the same as a page score?
No. The site-level (origin) score blends every page on the hostname, weighted by traffic. A slow template can pass at site level if most visits land on fast pages. Paste a full URL to check one page, if it has enough traffic.
What's the difference between the lab test and the field data?
Field data (the charts) is what real Chrome users experienced over 28 days, and it's what Google assesses. The lab test is one simulated load of one page on a mid-range phone and slow 4G, using Lighthouse through PageSpeed Insights. It can't match field numbers exactly, but it shows why a page is slow and works on pages with too little traffic for field data.
What are the four LCP phases?
Server response (time to first byte), load delay (how long before the browser starts fetching the LCP image), load time (how long the image takes to download) and render delay (time between the content being ready and it appearing). Whichever phase is biggest tells you what to fix: the server, how the image is discovered, the file itself, or what's blocking rendering.
Do Core Web Vitals affect rankings?
They're part of Google's page experience signals. Google calls them a tiebreaker rather than a big ranking factor, so great content on a slow page can still rank. Speed has a clearer effect on bounce and conversion rates, which is why tracking it over time matters.
Why are FCP and TTFB here if they don't count?
They explain LCP. A slow Time to First Byte means the server or CDN is the problem; a fast TTFB with a slow First Contentful Paint points at render-blocking CSS or scripts. Neither counts toward passing Core Web Vitals.
How it works: comparisons go through a small server endpoint that calls Google's Chrome UX Report History API, and lab tests through Google's PageSpeed Insights API. It stores nothing; comparisons are cached for up to 12 hours and lab tests for an hour. Your recent comparisons stay in your browser.