CrUX Vis to narzędzie do analizy Core Web Vitals z danych rzeczywistych użytkowników Chrome.
Technology · V2 version after source audit
How to read CrUX Vis, the 28-day data windows, the 75th percentile, LCP, INP, and CLS, and how to distinguish field data from laboratory measurements.
First publication:
14 January 2025
Verification:
18 July 2026
Length:
1183 words
Reading time:
approx. 6 min
checked sources
Evidence level:
High for tool operation; interpreting changes requires diagnostic data beyond CrUX
Author’s schematic illustration prepared for this article. It does not replace a documentary photograph or measurement.
What we know
- CrUX Vis shows the weekly history from the CrUX History API for up to about 40 weeks.
- Each point covers the previous 28 days, so adjacent points overlap heavily.
- Origin and URL data, form factor, and the 75th percentile view and distributions are available.
What remains uncertain
- CrUX does not itself explain which script, element, or deployment caused a change.
- Missing data for an address may result from insufficient traffic or privacy criteria.
- Simultaneous changes in multiple factors make it hard to assign a cause from a historical chart.
1. 1. What CrUX is and what CrUX Vis shows
2. 2. Field and laboratory data answer different questions
3. 3. Why the chart reacts slowly
4. 4. How to read LCP, INP, and CLS
5. 5. Why the 75th percentile matters
6. 6. Practical analysis process
7. 7. What missing data means
8. 8. Most common interpretation mistakes
9. 9. Questions and answers
10. Bibliography and sources
11. How to read overlapping 28-day windows
12. From a CrUX signal to a technical diagnosis
1. What CrUX is and what CrUX Vis shows
Chrome UX Report, abbreviated CrUX, is a public dataset of aggregated user experience data from Chrome on pages that meet qualification criteria. Google provides it through several tools: PageSpeed Insights, API, History API, BigQuery, and CrUX Vis.[[1]](#ref-1)
CrUX Vis is primarily for viewing trends. The user provides an origin or a specific URL, and the tool shows available metrics and their distribution over time. Origin means protocol, host, and port, for example `https://example.com`. URL data concerns a specific page but is only available with a sufficient number of observations.
2. Field and laboratory data answer different questions
A good laboratory result does not guarantee good field data. Users may have slower devices, unstable networks, extensions, different cache states, and different behaviours. The reverse is also possible: a synthetic test may look poor, but most real visits benefit from cache and fast devices.
3. Why the chart reacts slowly
The History API and CrUX visualisations use rolling periods of 28 days. A point does not describe one day. It combines data from four weeks, and the next point largely draws on the same days.[[2]](#ref-2)
If a faster LCP image was deployed on 1 July, then on 2 July most observations in the window still come from before the change. The share of new visits grows daily. The full effect may only become visible after the entire window has been replaced, and with variable traffic even later.
Therefore, to evaluate a deployment it is worth marking the change date and observing the direction for at least several weeks. A sudden one-day jump is usually not visible the way it would be in daily analytics.
4. How to read LCP, INP, and CLS
LCP: speed of showing the main content
Largest Contentful Paint measures the render time of the largest visible content element in the initial view. The good threshold is up to 2.5 seconds at the 75th percentile. Common causes of problems are slow server response, a large hero image, render-blocking CSS, late resource discovery, and client-side rendering.[[3]](#ref-3)
INP: responsiveness during the entire visit
Interaction to Next Paint evaluates interaction latency throughout the page lifetime. A good value is no more than 200 ms. Sources of problems include long JavaScript tasks, complex components, work performed on click, and an overloaded main thread.
CLS: visual stability
Cumulative Layout Shift measures unexpected layout shifts. A good result is no more than 0.1. Typical causes are images without reserved dimensions, late-inserted ads, banners, and fonts causing text geometry changes.
5. Why the 75th percentile matters
Core Web Vitals are assessed at the 75th percentile of visits. This means at least 75 percent of experiences should fall within the good threshold. The average would be too sensitive to the distribution and could hide poor experiences for a significant user group.
Dimensions should also be checked. Mobile and desktop results can differ, as can origin and a specific URL. Origin aggregation may look good when the problem affects a small but commercially important section.
6. Practical analysis process
1. Check the origin and key URL templates.
2. Record the dates of deployments, migrations, campaigns, and script provider changes.
3. Assess LCP, INP, and CLS separately, and the share of „good”, „needs improvement”, and „poor” categories.
4. Compare devices and templates.
5. Confirm the cause in PageSpeed Insights, DevTools, and RUM data.
6. After deployment, observe the trend for a full 28 days, but do not wait with laboratory diagnosis.
Interpretation example
After changing the consent system, INP starts worsening while LCP remains stable. In this case it makes no sense to optimise images. You need to check the JavaScript triggered on interaction, the number of listeners, CMP work, and tasks on the main thread.
7. What missing data means
CrUX applies qualification thresholds and privacy protections. For an unpopular URL, it may show no data even though the origin has enough. Missing data is not a „poor” rating. It means the public dataset cannot reliably return a metric for that level of aggregation.
In this case it is worth deploying your own Real User Monitoring, using the web-vitals library, and analysing laboratory data. RUM gives greater detail but requires correct implementation, consents, and data quality control.
8. Most common interpretation mistakes
- Comparing a CrUX point with a Lighthouse test run today.
- Expecting the full effect one day after deployment.
- Analysing only the origin result.
- Treating a good LCP as proof of good responsiveness.
- Ignoring changes in traffic structure, devices, and campaigns.
- Treating missing data as a bad result.
- Optimising for the tool result rather than the cause of the user experience.
9. Questions and answers
Is CrUX Vis a Google tool?
Yes. It is part of the Chrome UX Report toolset described in the Chrome for Developers documentation.
Why does PageSpeed show a different result from CrUX Vis?
PageSpeed combines field data, if available, with the Lighthouse laboratory test. CrUX Vis shows the field data trend, so the compared periods and conditions are different.
After how many days is a deployment effect visible?
The direction may be visible earlier, but full replacement of the rolling window takes 28 days. On small samples the change may be less stable.
Are Core Web Vitals the only performance indicators?
No. They are a common set of experience metrics, but diagnosis also requires server, technical, and business data.
Bibliography and sources
1. Chrome for Developers, [Overview of CrUX tools](https://developer.chrome.com/docs/crux/methodology/tools).
2. Chrome for Developers, [CrUX History API](https://developer.chrome.com/docs/crux/history-api).
3. web.dev, [Web Vitals](https://web.dev/articles/vitals).
4. Chrome for Developers, [CrUX Vis](https://developer.chrome.com/docs/crux/guides/crux-vis).
5. W3C Web Performance Working Group, [Web Performance](https://www.w3.org/webperf/).
SN
Redakcja Spraw Nauki
Popular-science material prepared on the basis of the sources indicated in the bibliography. In health-related topics, the text does not replace medical advice, and in organism identification it does not replace consultation with a specialist.
How to read overlapping 28-day windows
A point from a given Monday is not a measurement of one week. It is an aggregate of the previous 28 days. The next point retains about three-quarters of the previous period and replaces only the oldest week with the newest. For this reason the chart reacts more slowly than laboratory monitoring, and a single bad day does not need to be immediately visible.
When a deployment took place on 1 July, the full picture of its impact may be revealed gradually over several weeks. It is worth marking deployment, campaign, template change, consent mode, CDN, and major update dates on the axis. Without such a log, the chart easily becomes a correlation without a cause.
From a CrUX signal to a technical diagnosis
1. Check whether the regression affects the URL or the entire origin.
2. Separate phone, desktop, and tablet; mixing form factors can hide a problem.
3. Compare the 75th percentile with the „good / needs improvement / poor” distribution.
4. Verify the date of the first visible deviation and account for 28-day smoothing.
5. Move to laboratory data, RUM, and deployment logs to find the element causing the change.
CrUX answers the question „how did qualifying Chrome users experience the page.” Lighthouse answers a different question: „how did a controlled test behave under specific conditions.” Divergence between them is normal and diagnostically useful.
2026 update:
Google maintains CrUX Vis as a weekly historical view; the former CrUX dashboard and its connector were being phased out, so old instructions about Looker Studio may be outdated.