Site Speed Tester
See how a URL performs for real Chrome users and in a controlled lab run, side by side. The gap between the two is often where the diagnosis starts.
Paste a full URL and app.search.co returns two kinds of performance data for it. Field data comes from the Chrome User Experience Report (CrUX), which aggregates how real Chrome users experienced the page over a trailing 28-day window. Lab data comes from a Lighthouse run, a single simulated page load on a defined device and network profile. You can test one URL with no account; for further tests, a free search.co account is required.
Practitioners need both, because they answer different questions. Field data tells you whether users actually have a problem and is the dataset Google's Core Web Vitals assessment draws on. Lab data tells you why, with a reproducible trace and specific opportunities a developer can act on. Reading them as interchangeable is the most common speed-reporting mistake.
Two datasets for one URL.
The report places real-user metrics and a lab run together so you can compare them without switching tools.
- Field Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) from CrUX, reported at the 75th percentile, when enough data exists.
- Lab metrics: Lighthouse measurements from a simulated load, including LCP and CLS plus diagnostic timings such as Total Blocking Time that stand in for responsiveness in a lab.
- Performance score: Lighthouse's weighted 0 to 100 score for that single run, useful for tracking a template over time.
- Opportunities and diagnostics: the specific resources and patterns Lighthouse identifies as slowing the load, which become the developer's starting list.
Why field and lab numbers disagree.
Lab data is one load, on one emulated device, over one throttled connection, with an empty cache and no user interaction. Field data is thousands of loads on whatever phones, laptops and networks your audience actually uses, including repeat visits with warm caches and pages people scroll and tap through. They will rarely match, and they are not supposed to.
Common patterns: lab LCP looks worse than field because the lab profile is slower than your typical visitor, or field LCP looks worse because a large share of your audience is on low-end mobile devices. CLS often looks fine in the lab and poor in the field, because many layout shifts happen after the initial load, when ads, embeds or lazy content arrive as the user scrolls. INP cannot be measured in a standard Lighthouse load at all, since it requires real interactions, so the lab substitutes Total Blocking Time as a proxy for main-thread congestion.
When the two disagree, trust field data for whether there is a problem and lab data for where to look. A green Lighthouse score with failing field INP means the issue is in interaction handling the lab never exercised.
The 75th percentile and the thresholds.
Core Web Vitals are assessed at the 75th percentile of page loads. In plain terms, a page passes a metric when at least three out of four real visits meet the good threshold. This choice means a fast median is not enough; the slower quarter of your traffic has to be acceptable too, which is where low-end devices and poor connections show up.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP | When the largest visible element finishes rendering | 2.5 s or less | Over 4 s |
| INP | Delay from a user interaction to the next visual update | 200 ms or less | Over 500 ms |
| CLS | Unexpected layout movement over the page's life | 0.1 or less | Over 0.25 |
Values between good and poor are labeled needs improvement. Note that the Lighthouse performance score is not part of this assessment. A page can score 60 in the lab and pass all three field metrics, or score 95 and fail one.
When a page has no field data.
CrUX only publishes data for pages and origins with enough eligible Chrome traffic over the collection window. New pages, low-traffic URLs, pages behind a login, and sites whose audience mostly uses other browsers can fall below that bar. In that case the report may fall back to origin-level data for the whole site, or show no field data at all.
Missing field data is not a failure and does not mean the page is slow. It means you have to rely on lab data as a proxy and accept that it reflects a simulated visitor. For a new launch, test the key templates in the lab now and recheck field data once a few weeks of traffic have accumulated. If you are comparing your site with a competitor, check that both URLs have field data before drawing conclusions; comparing one site's field numbers against another's lab numbers is meaningless.
Turning results into fixes by metric.
Work metric by metric, starting with whichever field metric fails. For LCP, identify the LCP element in the lab trace, then shorten its path: faster server response, a preloaded hero image sized to its display, and no render-blocking scripts in front of it. For CLS, reserve space for anything that loads late, including images, ads, embeds and injected banners. For INP, reduce long main-thread tasks, usually by trimming or deferring third-party scripts and breaking up heavy event handlers.
Test templates, not just the homepage. A product page, a category page and an article page usually have very different bottlenecks. If the slowdown seems tied to a specific platform or plugin, the technology lookup shows what a site runs, which helps when the culprit is a widget rather than your own code.
Speed testing errors to avoid.
These come up repeatedly in audits and client reports.
- Reporting the Lighthouse score as Core Web Vitals: the score is a lab composite. The assessment that matters for search uses field metrics.
- Expecting instant field improvement: CrUX covers a trailing 28 days, so a fix shipped today takes weeks to show fully in field data.
- Single-run conclusions: lab results vary between runs. Rerun before treating a small change as real.
- Testing a redirecting URL: test the final URL. Redirect hops add latency that belongs in a separate fix.
- Ignoring mobile: field data often differs sharply by device type, and mobile is usually where problems appear first.
Diagnose a slow template.
Pick a representative URL
Choose a high-traffic page for the template you want to diagnose and use its final, non-redirecting URL.
Read field data first
Note which Core Web Vitals fail at the 75th percentile, or whether field data is missing.
Match it to the lab trace
Use the Lighthouse opportunities and diagnostics to find the element or script behind the failing metric.
Ship and wait
Deploy the fix, confirm it in a fresh lab run, then recheck field data after the collection window has rolled forward.
Get an expert read on your results
Tools give you the raw numbers. Tell us your site and an SEO.co strategist will email you what they'd prioritise and the next steps they'd recommend.
Site speed tester questions.
What is the difference between field data and lab data?
Why does my page show no field data?
Is the Lighthouse performance score a ranking factor?
Why is INP missing from the lab results?
How soon will a fix show up?
Can I test more than one URL?
Pair it with these checks.
Field data failing and the fix is not obvious?
SEO.co's technical SEO services trace Core Web Vitals problems to the template, script or server setting behind them and work with your developers until field data passes.