Field data vs lab data: reading CrUX, RUM and Lighthouse together
Lighthouse says 95, Search Console says failing. Why both can be right, and how we use each source to make decisions.
One of the most common messages we receive starts with a screenshot of a green Lighthouse score and ends with a question: why does Search Console say our Core Web Vitals are failing? Both tools are telling the truth. They are simply measuring different things. Lighthouse runs one test, on one simulated device, under controlled conditions. Field data summarizes what thousands of real visitors experienced over the last 28 days on their own phones and networks. Understanding how the two relate is the foundation of every performance project we run.
What each source actually measures
There are three sources we use on nearly every engagement, and each answers a different question.
- Lab data from Lighthouse, PageSpeed Insights lab section or WebPageTest. A controlled test of one page load with a set device profile and network throttling. It answers: under these conditions, what happens and why?
- CrUX field data from the Chrome User Experience Report, shown in Search Console and PageSpeed Insights. Aggregated real-user metrics from opted-in Chrome users, reported at the 75th percentile over a rolling 28 days. It answers: are real visitors having a good experience, in the terms search engines use?
- Real user monitoring from a script on your own site. Every visit's metrics, with whatever detail you choose to collect. It answers: which pages, devices, countries and interactions are slow, and what caused it?
Core Web Vitals assessments are based on field data. A perfect lab score does not pass the assessment, and a mediocre lab score does not fail it.
Lab data tells you what could happen. Field data tells you what did. You need the first to fix things and the second to know whether you did.
Why they disagree
When lab and field results differ, the reason is usually one of a handful of things.
- Devices. Lighthouse simulates a mid-range phone, but your audience may skew toward older Android devices that are much slower, or toward recent iPhones, which do not report to CrUX at all.
- Caching and state. Lab tests usually load a page cold, with no cookies, no consent choice and an empty cache. Real users arrive with consent banners, logged-in states, personalized content and warm caches.
- Interactions. Lighthouse does not interact with the page, so it cannot measure Interaction to Next Paint. Total Blocking Time is a proxy, and an imperfect one.
- Layout shifts over time. Cumulative Layout Shift in the field includes shifts that happen while scrolling and interacting, which a lab load never sees.
- Traffic mix. The page you test in the lab may not be the page most users land on. Field data reflects your actual landing pages, including slow campaign pages you forgot existed.
On a recent publishing client, lab LCP on the article template was a comfortable 1.8 seconds. Field LCP was 3.4 seconds. RUM showed why: most mobile visitors arrived from social links with tracking parameters that bypassed the CDN cache, so they received uncached HTML from a slow origin. No lab test had ever reproduced that path.
How we use them together
Our workflow uses each source for what it does best.
- Prioritize with field data. Start with CrUX in Search Console to see which page groups fail which metric. Use RUM to rank templates by the number of affected visits, so effort goes where most users are.
- Diagnose with RUM attribution. Collect the LCP element, the slowest interaction target and the largest layout shift source for each visit. This narrows the problem from "product pages are slow" to "the review widget shifts the add-to-cart button on mobile".
- Reproduce and fix in the lab. Recreate the conditions RUM reveals, including device class, cache state and consent state, and use traces to find the cause. Lab tools are where you iterate quickly.
- Verify in the field. Deploy, then watch RUM for immediate confirmation and CrUX over the following 28 days for the official result.
That last step requires patience. Because CrUX uses a rolling 28-day window, a fix shipped today moves the reported number gradually over four weeks. RUM lets you see the effect within a day or two, which is why we do not run performance projects without it.
Setting up RUM without slowing the site
Real user monitoring does not have to be expensive or heavy. The open-source web-vitals library is small, and its attribution build provides most of the diagnostic detail we need. We typically send the results to an analytics endpoint or a lightweight collector, sampled if traffic is high, and store them with the page template, device type, connection type and country. Commercial RUM products add dashboards, session context and alerting, which are worth it for larger sites.
Whatever tool you use, segment by template rather than by URL. Most sites have thousands of URLs but only a dozen templates, and performance problems almost always belong to a template.
Reporting that stakeholders trust
When we report progress to clients, we show field data first, broken down by template and device, with the lab data as supporting evidence of what changed. That avoids the trap of celebrating a Lighthouse score while real users still wait. It also sets honest expectations about the 28-day lag before Search Console reflects the improvement.
Setting up this measurement stack is the first phase of our Core Web Vitals optimization projects. The RUM data often lives alongside the client's analytics, which is where our GA4 and analytics setup work comes in, and it feeds into broader technical SEO audits when search visibility is the concern.
Not sure which numbers to believe?
If your lab scores and Search Console tell different stories, we can set up proper measurement and find out what real users experience. Reach out for a fixed-price quote within 24 hours.
