Free, no signup. Core Web Vitals reports are usually a wall of numbers before they tell you anything useful. This leads with one sentence: whether the page passes, and the single thing to fix first —
real Chrome user data when it exists, a Lighthouse lab audit when it doesn't.
field data first (CrUX) · lab fallback (Lighthouse) · mobile + desktop
Checks run from our server; we fetch the URL you enter and don't keep the results. Anonymous aggregate stats count a domain once via a rotating hash for research posts; URLs are never stored. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Feedback
Report a bug
Found something broken in Cwv Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.
Sample report
Say you check a product page:
https://example.com/product/blue-widget
…and Chrome has field data showing a slow mobile load. The tool returns:
Illustrative example — real results need a live CrUX/PageSpeed Insights lookup this static page can't make; the good/needs-improvement/poor bands shown match this tool's actual LCP/INP/CLS thresholds (2.5s/4s, 200ms/500ms, 0.1/0.25)
Not passing
This page does not pass Core Web Vitals because of LCP (loading) on mobile.
https://example.com/product/blue-widget
Mobile — what Google ranks onfield · this URL
LCP4.3 s
INP158 ms
CLS0.06
Desktopfield · this URL
LCP1.9 s
INP120 ms
CLS0.03
What to fix, in order
Optimize the largest imageLCP
Your largest element is likely an unoptimized image. Serve it in a modern format
(AVIF/WebP), size it to the space it actually fills, and add fetchpriority="high" so the
browser loads it first.
Speed up server response (TTFB)LCP
Your server is slow to send the first byte, which caps how fast LCP can ever be. Add
full-page or edge caching, and check for slow database queries or origin round-trips.
Desktop passes on all three metrics, but mobile LCP sits at 4.3 s — past the 4 s
"poor" line — so the page does not pass overall. See what the color bands
mean ↓.
Google evaluates page experience on mobile, so the verdict names the
mobile LCP result specifically as the one thing to fix first, even though desktop is clean.
The fix list is ordered, not just listed — image optimization and server response
time both move LCP, so both appear ahead of any INP/CLS advice, which this page doesn't need here.
Paste a full page URL into the Single URL box (the scheme helps —
https://example.com/page).
Press Check vitals. The tool pulls field data for that exact URL first;
if Chrome has none, it falls back to whole-site (origin) field data, then to a simulated
Lighthouse lab audit — each card is labelled with the source it used.
Read the verdict banner first: one sentence naming whether the page passes
and, if not, the single worst metric holding it back.
Scan the mobile and desktop cards side by side, then work down the numbered
What to fix, in order list.
Need diagnostics on a page that already has field data? Click
Run a fresh lab audit instead for Lighthouse-driven fix detail. To compare
several sites at once, switch to Bulk domains (up to 5) for an origin
scorecard with CSV export.
Current target
Recent checks appear below. Use the star beside any saved site, page, or list to favorite it.
Saved targets, named lists, and recent check summaries remain only in this browser.
Lab vs. field comparison
Field data describes real Chrome visits over 28 days; lab data is one simulated run. Use the lab trace to investigate, then use field data to judge the real-user outcome.
What to fix, in order
Elements Lighthouse singled out
Runs Lighthouse on mobile + desktop — takes ~30 seconds, numbers are simulated and vary between runs.
Compare a later check
Download this result as a private JSON baseline, then import it after another check to compare the verdict, data source, and metric changes.
Rate this tool
whole-site field data (CrUX origin) · mobile · no lab runs in bulk
0 domains
Origin scorecard (mobile field data)
Origin
Verdict
Worst metric
LCP
INP
CLS
Field data is Google's Chrome UX Report — the same 28-day real-user dataset Search uses
for the page-experience signal; it updates daily, so repeat checks within 24 hours are
served from cache. Lab numbers come from Lighthouse with simulated throttling: expect them
to differ from field data and to vary between runs. Lab audits can't measure INP (it needs
real users).
This checker reads Google's real-user Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.
for a page and gives you a one-sentence verdict plus a prioritized fix list. For whole-site
field-data trends over time, use the Core Web Vitals History & Competitor Comparison;
to see what a bot renders versus what a user sees, use the
Render Gap Checker.
What the results mean
The verdict badge summarises the whole page in one word:
Passes (green) — every Core Web Vital is "good" on every device that had data.
Not passing (red) — at least one Core Web Vital is "needs improvement" or "poor".
The headline names the single worst-performing metric, on the worst device.
Partial data (amber) — the metrics that had data all passed, but at least one
Core Web Vital was missing, so the pass can't be certified outright.
No field data (amber) — Chrome has no field measurements for this page or
origin, so only simulated lab numbers are shown.
Each metric value is colour-coded against the official thresholds:
The source tag on each card is deliberately loud, because mistaking lab numbers for real-user
data is the most common CWV error:
field · this URL — real-user data for the exact page (best case).
field · whole site — origin-level real-user data, used when the specific URL
has no sample.
lab · simulated — a Lighthouse audit with simulated throttling; numbers vary
between runs and can't certify a pass.
How it works
Enter a URL and the tool calls a small server endpoint that queries the
Chrome UX Report for both mobile and desktop. CrUX is Google's
28-day rolling dataset of real Chrome users — the same field data behind the page-experience
signal. If the specific URL has no sample, the endpoint retries at origin level; if that is also
empty, it runs a Lighthouse lab audit for at least some
diagnostics.
The pass verdict logic, thresholds, and fix ranking live in shared, testable code. Ratings use the
exact official cut-offs; the verdict picks the binding constraint by scoring how far each
underperforming metric sits past its "good" line and breaking ties toward mobile. The fix engine
cross-references the worst-performing metric with the Lighthouse audits that actually fired on the
page (render-blocking resources, slow server response, unoptimized images, heavy third-party JS,
layout-shift elements, and more) so the advice is specific — with a per-metric fallback so every
underperforming metric always gets at least one concrete next step.
Features
Verdict-first: one plain-English sentence naming the single worst-performing metric on the worst
device, instead of a wall of numbers.
Real-user field data first (CrUX), with automatic fallback to origin field data, then to a
simulated Lighthouse lab audit — each source clearly labelled per card.
Mobile and desktop shown side by side, with mobile flagged as the device Google ranks on.
Prioritized, diagnostic fix list built from the Lighthouse audits that actually fired, not
generic tips.
Optional fresh lab audit on pages that already have field data, for extra diagnostics.
Bulk mode: an origin scorecard for up to 5 domains (mobile field data) with CSV export.
Nothing you check is stored; repeat checks within 24 hours are served from cache.
Limitations
Field data needs traffic: low-traffic or brand-new pages get no CrUX sample, so you'll see origin
data or lab numbers instead. Lab audits use simulated throttling — they vary between runs and
can't measure INP, which requires real user interactions, so a lab-only result never certifies a
pass. Field data lags reality by up to 28 days, so a fix you shipped yesterday won't show until
the rolling window catches up. The tool reports and prioritizes problems; it does not change your
site, and the fixes are starting points, not a guarantee of a passing score.
Frequently asked questions
What are the Core Web Vitals thresholds?
A page passes when its 75th-percentile score is "good" for all three metrics: Largest Contentful Paint (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) at 2.5 seconds or faster, Interaction to Next Paint (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) at 200 milliseconds or faster, and Cumulative Layout Shift (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) at 0.1 or lower. LCP over 4 seconds, INP over 500 milliseconds, or CLS over 0.25 is "poor"; anything between the two thresholds is "needs improvement". The tool uses these exact official cut-offs.
Why do my Core Web Vitals scores differ from PageSpeed Insights?
They should match when both are reading the same source. This tool shows Chrome UX Report (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) field data first — the same real-user dataset Search uses — and only falls back to a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab audit when a page has no field data. Lab numbers use simulated throttling and vary between runs, so a lab score will not line up with a field score. If your PageSpeed number is a lab score and ours is field data, or vice versa, that is the difference.
Why does the checker say "no field data" for my URL?
CrUX only reports a URL once it has enough Chrome traffic to form a statistically stable sample over the trailing 28 days. Low-traffic or brand-new pages never cross that bar. When that happens the tool falls back to origin-level field data (the whole site) or a simulated Lighthouse lab audit, and it labels which source each card is using so you never mistake lab numbers for real-user data.
Can this tool measure INP?
It can report INP from field data, because INP is measured from real user interactions. It cannot produce an INP number from a lab audit — Lighthouse has no real users to interact with the page, so a lab-only result shows "no lab INP" for that metric. If you need an INP figure and the page has no field data, you need real traffic (or the Chrome DevTools INP tooling on your own interactions).
Which device does Google use for ranking — mobile or desktop?
Google evaluates the page-experience signal on mobile, so the tool marks the mobile card "what Google ranks on" and, when a page does not pass on both devices, names the mobile metric as the binding constraint. Desktop scores are shown for context but do not decide the mobile ranking assessment.
Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Common issues & how to fix them
Page Speed Test & Core Web Vitals Checker · one finding
Render-blocking resources may delay LCP
Recommended action: Inline critical CSS and defer non-critical stylesheets or scripts that block the LCP resource from rendering.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Server response may delay LCP
Recommended action: Reduce initial server response time with caching, faster backend work, and a CDN near users before optimizing the LCP asset.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Image delivery may delay LCP
Recommended action: Resize and compress the LCP image, serve a modern format with srcset, and preload it when discovery is late.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Critical origin lacks preconnect
Recommended action: Add preconnect only for the critical third-party origin that serves the LCP resource, including crossorigin when required.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Third-party code contributes to INP
Recommended action: Defer or delay non-critical tag managers, chat, analytics, and testing scripts until after the first interaction, and remove unused vendors.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Main-thread work contributes to INP
Recommended action: Break long main-thread tasks into smaller chunks, move heavy computation to a worker, and minimize synchronous layout work.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Unused JavaScript contributes to INP
Recommended action: Code-split by route and component so the page downloads, parses, and executes only JavaScript needed for the current view.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Layout-shift elements contribute to CLS
Recommended action: Give the reported images, embeds, ads, and injected regions explicit dimensions or reserved placeholders before they load.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Font loading contributes to CLS
Recommended action: Preload critical fonts, use metric-compatible fallbacks, and choose font-display behavior that avoids a late layout-changing swap.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
Page Speed Test & Core Web Vitals Checker · one finding
Lab and field performance disagree
Recommended action: Use the Lighthouse trace to diagnose the simulated-run bottleneck, then monitor the matching CrUX metric before claiming or closing a real-user regression.
Fix principle: A poor LCP, INP, or CLS label names the user impact, not the implementation defect. Start with field data and segment evidence, reproduce the affected journey in the lab, identify the proximate resource, task, interaction, or shifting element, then change that owner and confirm the field distribution recovers.
Implementation for your setup
Confirm first: Representative field data at the 75th percentile shows a poor or needs-improvement experience for an important page group. The regression can be tied to a proximate cause such as slow server response, late LCP discovery, image delivery, render-blocking work, long interaction tasks, third-party JavaScript, layout-shifting elements, or font behavior. A deploy or template change aligns in time with the affected segment and the suspected cause reproduces in an appropriate lab or RUM trace.
Do not apply when: Only one synthetic run is slow while representative field data and repeated controlled traces do not show the regression. The apparent lab/field disagreement is explained by different URLs, devices, networks, user states, interactions, or LCP elements. The finding names only a metric band and provides no evidence identifying a controllable cause.
Likely control points: server · edge-cdn · cms-app · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Status: supported · Location: The server, template, resource pipeline, JavaScript owner, or third party responsible for the measured cause
Steps
Segment field data by page group, device, geography, and release window; identify the affected metric and whether the regression is page-level or origin-level.
Reproduce the affected page and journey with realistic lab settings, then inspect the metric subparts and responsible element or interaction.
For LCP, fix the measured subpart: server response, resource discovery/priority, resource load duration, or element render delay. Do not lazy-load the likely LCP image; expose it in initial HTML and use high fetch priority only when it is truly critical.
For INP, identify the slow interaction and reduce input delay, callback work, long tasks, layout work, and presentation delay; do not optimize unrelated startup code merely because it appears in a generic audit.
For CLS, reserve dimensions for images/embeds/ads, stabilize injected content, and correct the exact font or dynamic element causing unexpected shifts.
Deploy the smallest causal change behind a reversible release and preserve the prior metric/trace evidence.
Verify on this platform
Repeat controlled traces for the same page, device, network, and user journey and confirm the responsible subpart improves without regressing another vital.
Use RUM or wait for an equivalent field-data window to confirm the affected segment distribution recovers at the 75th percentile.
Compare release cohorts and confirm the improvement is not caused by a different URL mix or traffic population.
Rollback
Revert the causal release if it breaks functionality, visual stability, caching, or another vital.
Restore the prior resource priority or loading behavior if the new hint competes with a more important resource.
Caveats
Lab and field data measure different populations and conditions; neither should be relabeled as the other.
Core Web Vitals field data is a distribution and can take time to reflect a release.
Do not add `fetchpriority="high"` to many images; excessive priority removes the value of the hint.
Start with representative field data and preserve its page/device/time segmentation.
Identify the responsible LCP subpart, interaction, or shifting element in reproducible evidence.
Deploy one reversible causal change and repeat the same controlled trace.
Confirm recovery in an equivalent field-data cohort without hiding regressions in another vital.
Escalate when
Escalate when field and lab evidence cannot be reconciled, the responsible code belongs to an unconfigurable third party, or the proposed fix trades one vital or critical user function for another.
ErrorsLCP is poorFix: Cut LCP below 2.5 seconds by optimizing the measured LCP element and its critical delivery path, then verify with fresh field data.
WarningsLCP needs improvementFix: Bring LCP below 2.5 seconds by prioritizing the measured LCP element and removing delay from its delivery path.
ErrorsINP is poorFix: Cut INP below 200 ms by shortening the longest interaction tasks and reducing JavaScript work on the main thread.
WarningsINP needs improvementFix: Bring INP below 200 ms by breaking up long interaction handlers and yielding main-thread work.
ErrorsCLS is poorFix: Cut CLS below 0.1 by reserving space for shifting elements and preventing late font or content swaps.
WarningsCLS needs improvementFix: Bring CLS below 0.1 by adding stable dimensions and placeholders for elements that move after first paint.
