How to check any URL's Core Web Vitals from a free tool

You just spent three days optimizing images, minifying JavaScript, and stripping out unused CSS to finally hit that glorious 100/100 Lighthouse score. You feel invincible. Then, you open Google Search Console only to find a sea of red: "Poor" URLs across your entire domain. The problem isn't your code; it's your data source. You are looking at a simulated "lab" environment, while Google is judging you on the actual, messy experiences of your last 28 days of Chrome visitors.

Lab Data vs. Field Data: Why your Lighthouse score is lying

In the world of web performance, there is a massive divide between what happens on your machine and what happens in the real world. We call these "Lab Data" and "Field Data." Lighthouse, Chrome DevTools, and even most CI/CD performance checks provide Lab Data. They are synthetic tests run in a controlled environment. Field data, specifically from the Chrome User Experience Report (CrUX), is the aggregated data from real users browsing your site in the wild.

The "Clean Room" Fallacy: Why synthetic tests miss real-world latency

Synthetic testing is like testing a car on a perfectly flat, indoor track with a professional driver. It tells you the car's theoretical top speed, but it says nothing about how it handles a pothole in a rainstorm on a Tuesday morning. When you run a Lighthouse test, you are likely using a high-end machine (like a Mac Studio or a modern MacBook Pro) on a stable, high-speed office fiber connection. Even if you "throttle" the connection in DevTools, the CPU power of your machine still handles the JavaScript execution significantly faster than a mid-range Android device.

Real users don't live in your office. They are on 3-year-old Samsung phones with expiring data plans, browsing your site while sitting on a train that is moving between cell towers. They have 40 other tabs open, and their battery is at 12%. Lab tests cannot replicate the chaotic reality of device thermal throttling, background processes, and flaky 4G latencies. This is why a site can feel "fast" to a developer but be categorized as "Poor" by Google's ranking algorithms.

What is the Chrome User Experience Report (CrUX)?

Google doesn't guess how fast your site is; they know. If a user is logged into Chrome and has "Usage statistic reporting" enabled, Chrome sends performance metrics back to Google. This massive dataset is called the Chrome User Experience Report (CrUX). It is the official data source for the Core Web Vitals program. When Google determines your search ranking based on page experience, they aren't running a Lighthouse test on your homepage. They are looking at the CrUX data for your URLs from the last 28 days.

Why the 75th percentile (p75) is the only number that matters for SEO

Google doesn't look at your average (mean) or median (p50) load time. Averages are dangerous because a few very fast sessions can hide the fact that 40% of your users are having a terrible experience. Instead, Google uses the 75th percentile, or "p75."

The p75 means that 75% of your users are having an experience at or better than that number. If your p75 Largest Contentful Paint is 2.4 seconds, it means 3 out of 4 visitors saw the main content in under 2.5 seconds. If that number slips to 2.6 seconds, your entire URL is marked as "Needs Improvement" because more than 25% of your audience is seeing a slow load. For SEO purposes, p75 is the only metric that moves the needle.

The Core Web Vitals Trinity (plus the new INP)

Google focuses on three primary metrics that they believe represent the "health" of a web page's user experience. As of 2024, the set has evolved to include a more robust way of measuring interactivity.

LCP (Largest Contentful Paint) - Loading performance

LCP measures how long it takes for the largest image or text block in the viewport to become visible. This is usually your hero image, a heading, or a large descriptive paragraph. It's the best proxy we have for "when does the user think this page is loaded?"

• Good: < 2.5s
• Needs Improvement: 2.5s - 4.0s
• Poor: > 4.0s

CLS (Cumulative Layout Shift) - Visual stability

Have you ever been about to click a "Cancel" button when an ad suddenly loads at the top of the page, pushing the content down and making you click "Buy Now" instead? That is a layout shift. CLS measures the sum of all individual layout shift scores for every unexpected shift that occurs during the entire lifespan of the page.

• Good: < 0.1
• Needs Improvement: 0.1 - 0.25
• Poor: > 0.25

INP (Interaction to Next Paint) - The new responsiveness standard

In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP). FID was too easy to "cheat"—it only measured the delay of the first interaction. INP is much stricter; it observes the latency of all clicks, taps, and keyboard interactions throughout the user's entire visit. It reports the longest duration observed, ignoring outliers. It's a measure of how "snappy" your site feels while the user is actually using it.

• Good: < 200ms
• Needs Improvement: 200ms - 500ms
• Poor: > 500ms

The Google Toolset: PSI, Search Console, and BigQuery

Google provides several ways to access this field data, but each has a specific trade-off that often frustrates developers looking for quick answers.

PageSpeed Insights: Comprehensive but slow

PageSpeed Insights (PSI) is the most common way to check field data. You plug in a URL, and it gives you both the CrUX field data and a fresh Lighthouse lab report. The problem is the friction. PSI is heavy, takes 10-15 seconds to run, and buries the actual field data under a mountain of "opportunities" and "diagnostics" that may or may not actually improve your CrUX scores. It's a great tool for deep debugging, but it's painful for a quick "How are we doing?" check.

Search Console: Great for trends, delayed by days

Google Search Console (GSC) is the "source of truth" for how Google sees your site. It groups your URLs into clusters and shows you which ones are failing. However, GSC data is notoriously delayed. It usually reflects a window of data from 3-5 days ago. If you deploy a fix today, you won't see that line graph move in Search Console for nearly a week. It also doesn't let you easily check URLs that you don't own, making competitive benchmarking impossible.

Chrome DevTools: Excellent for debugging, but still strictly "lab"

The "Performance" tab in Chrome DevTools is where you go to fix the problems. It allows you to see exactly which task is blocking the main thread or which element is causing a layout shift. But remember: DevTools is still just showing you your experience on your computer. Even with the "Performance Insights" panel, you are looking at lab data. It cannot tell you what your users in Brazil or Japan are experiencing.

How to check p75 field data for any URL instantly

If you want to know how a URL is performing in the real world without waiting for a full PageSpeed Insights report or digging through BigQuery, you need a tool that queries the CrUX API directly and presents the p75 values cleanly. We built a free tool exactly for this purpose.

Using the Web Vitals Lookup tool

The GlitchReplay Web Vitals Lookup is a zero-config way to see the actual CrUX data for any domain or specific URL. Unlike PSI, it doesn't run a synthetic test. It simply fetches the latest rolling 28-day p75 data that Google has on file and displays it in a clear, color-coded dashboard.

Because it skips the Lighthouse simulation, it is near-instant. You can quickly check your homepage, your top-performing blog post, or your checkout page to see where you stand against Google's thresholds.

Interpreting the results: FCP and TTFB as diagnostic signals

When you use the lookup tool, you'll see metrics beyond the "Core" three. Specifically, pay attention to Time to First Byte (TTFB) and First Contentful Paint (FCP). These aren't ranking factors themselves, but they are the "canaries in the coal mine."

If your LCP is "Poor" and your TTFB is high (over 800ms), your problem is likely your server or your CDN. Your application is taking too long to respond before the browser can even begin to think about rendering. If your TTFB is fast but your LCP is slow, the bottleneck is on the client side—likely a massive hero image that isn't being lazy-loaded or a render-blocking JavaScript bundle.

Competitive Benchmarking: Checking your competitors

One of the most powerful uses of a public CrUX lookup tool is seeing how you stack up against your competitors. If you are competing for a high-value keyword and both you and your competitor have great content, the "tie-breaker" often becomes Page Experience. You can use the Web Vitals Lookup to see if your competitor's site is actually as fast as it looks, or if their p75 data reveals a "Poor" experience that you can exploit by being faster.

Beyond Lookup: Moving to Real-Time Monitoring

Checking a lookup tool once a week is a great start, but it's not a strategy for production-grade applications. CrUX data is a "lagging indicator." It tells you what happened over the last 28 days. If you ship a JavaScript change today that breaks INP for all mobile users, it will take weeks for that to significantly impact your CrUX p75 score—and by the time it shows up in Search Console, your rankings may have already started to slip.

The gap between CrUX updates and your latest deploy

CrUX is a rolling window. This means that today's "score" is actually an average that includes data from 27 days ago. If you make a massive improvement today, it will take 28 days for the "old, slow" data to fully cycle out of the report. This delay is why developers often feel like their optimization work isn't "doing anything." You are doing the work, but the report is still looking at the past.

Correlating performance spikes with specific user sessions

To fix Core Web Vitals, you need to know why they are failing. A lookup tool tells you that your INP is 450ms (Needs Improvement), but it doesn't tell you which button the user clicked that caused that delay. This is where Real User Monitoring (RUM) comes in.

By using a tool like GlitchReplay, you can capture these same Web Vitals metrics in real-time. Because our SDK is compatible with Sentry, you can drop it into your existing app and start seeing performance data immediately. More importantly, when a user has a "Poor" LCP or a "Poor" INP, you can watch a Session Replay of that exact visit. You can see the user struggle, identify the layout shift as it happens, and see exactly what JavaScript was executing when the interaction became laggy.

Setting up a "Scorecard" for your engineering team

Performance is a feature, and like any feature, it suffers from "regressions." You might optimize your site today, but three months from now, a marketing tag or a heavy third-party widget will be added that brings your scores back down. A healthy engineering culture treats Web Vitals as a continuous metric.

"What gets measured gets managed."

Don't wait for the monthly SEO report. Use the Web Vitals Lookup tool as a quick sanity check during your sprint reviews, and move toward a real-time monitoring solution to catch regressions the hour they are deployed, not the month they are reported by Google.

Ready to see the truth? Check your site's actual p75 field data right now with the GlitchReplay Free Web Vitals Lookup.