You paste a client URL into PageSpeed Insights and the lab block looks fine: Largest Contentful Paint, Total Blocking Time, even a Cumulative Layout Shift score from Lighthouse. Scroll to the field section and Interaction to Next Paint (INP) or CLS is simply absent. Not red, not amber, just missing. The account manager asks whether the page fails Core Web Vitals. You are not looking at a broken test. You are looking at a Chrome User Experience Report (CrUX) eligibility gap, and it is one of the most common sources of confusion in agency reporting.
PageSpeed Insights merges two data sources on one screen. Lab numbers are synthetic: Lighthouse runs on demand with a fixed device profile. Field numbers come from CrUX, a 28-day rolling sample of real Chrome users. Google only publishes a field metric when enough opted-in sessions meet privacy and quality thresholds for that origin, URL, device class, and metric. When the sample is too thin, PSI shows no data for that metric even though lab CLS or INP is right there. That split is normal on low-traffic pages, new launches, long-tail templates, and some desktop-only views. The fix is not to rerun the test until a number appears. The fix is to know which layer you are reading, follow a short decision tree, and fall back to scheduled lab monitoring where field data cannot exist yet.
Why PageSpeed Insights sometimes shows no CLS or INP field data
CrUX is not a census of every visit. Google aggregates performance from a subset of Chrome users who have opted in to sharing statistics. Before a metric appears in PageSpeed Insights field data, the URL or origin needs enough recent sessions in that collection period. If the count falls below Google's threshold, the metric is withheld rather than shown with misleading precision.
Several situations trigger a missing field row:
- Insufficient sample size for the specific URL, especially on blog posts, campaign landers, and localised paths that get far fewer sessions than the homepage.
-
Origin-level data only, where CrUX has enough traffic for
example.combut not forexample.com/pricing/enterprise. - Metric-specific gaps, where LCP field data exists but CLS or INP does not, because each metric has its own eligibility within the same report.
- Form factor splits, where mobile field INP is published but desktop INP is not, or the reverse, because phone and desktop traffic are reported separately.
- New or recently changed URLs that have not yet accumulated four weeks of blended field history in the rolling window described in why your Core Web Vitals fix is not in CrUX yet.
None of these mean the page is fast or slow in the eyes of Google Search. They mean Google does not have enough field evidence to print a percentile for that slice. Search Console may still group the URL with origin-level status when URL-level field data is missing, which is another reason teams misread a single PageSpeed Insights screenshot as the full story.
Lab CLS and INP vs missing CrUX field data on the same URL
The most confusing PSI screen is lab green beside an empty field row. Lighthouse always calculates lab CLS from the layout shifts it observes during the synthetic load. Lab interactivity is proxied through Total Blocking Time and related audits; INP itself is a field metric, so PSI does not show a field INP value when CrUX has no sample, even if lab TBT looks acceptable.
| Lab (Lighthouse in PageSpeed Insights) | Field (CrUX in PageSpeed Insights) |
|---|---|
| Source | One controlled run you triggered |
| CLS | Always calculated for that run |
| INP | Not a lab Core Web Vital; use TBT as a lab signal |
| Best for | Template QA, deploy checks, before/after on priority URLs |
| Missing data meaning | N/A (rerun always produces lab output) |
Treat the two blocks as complementary. Lab answers whether today's build looks clean on a representative device profile. Field answers whether enough real users experienced that quality over the past month. A missing field CLS or INP row does not invalidate lab work; it limits what you can claim about population-level Core Web Vitals for that exact URL. For the wider lab versus field programme, see synthetic versus real user monitoring and PageSpeed Insights versus automated monitoring.
When CrUX shows origin-level data but not URL-level CLS or INP
CrUX publishes at two granularities when sample size allows: origin (scheme plus registrable domain, for example https://www.example.com) and URL (the exact page tested). High-traffic homepages and top category routes often qualify for URL-level field data. Long-tail URLs frequently inherit only origin-level aggregates in PageSpeed Insights, or show no URL row at all.
If origin field CLS looks healthy but the product detail URL you care about has no field INP, you are not necessarily looking at a product-page regression. You may be looking at a page that does not meet URL-level thresholds. Google's PageSpeed Insights and CrUX guide documents how origin and URL slices appear in the UI. Practical workflow for agencies:
- Run PageSpeed Insights on the origin (homepage or canonical host) and note which metrics appear at origin level.
- Run the specific client URL and compare which metrics disappear.
- If origin field data exists but URL data does not, report origin status for SEO conversations and use lab monitoring on the priority template until URL-level field history builds.
- Query the CrUX History API or CrUX Vis for origin trends when you need charts; see CrUX Dashboard retired: where to get TTFB, INP, and field history for the replacement stack.
URL-level CrUX is valuable when you have it. It is not guaranteed for every page in the sitemap, and missing URL-level CLS or INP is often a traffic maths problem rather than a measurement error.
Desktop vs mobile splits when only one form factor has field data
PageSpeed Insights field data is split by phone and desktop form factors. Each combination of origin or URL, metric, and form factor has its own eligibility. That is why community threads describe CLS on desktop in one tool and no CLS on mobile in PageSpeed Insights, or INP on mobile with no desktop INP row.
Mobile traffic usually dominates retail and publisher sites, so mobile field Core Web Vitals are what Search Console emphasises for many properties. B2B sites with heavy desktop usage during business hours can still lack desktop INP in CrUX while mobile INP passes. Always note which strategy you selected in PageSpeed Insights before screenshotting a report. Switching between mobile and desktop lab profiles does not change field eligibility, but it changes which field column you are looking at.
For portfolio programmes, monitor both form factors on priority templates even when only one has field data today. Mobile versus desktop Core Web Vitals monitoring covers schedules and budgets; the reporting rule here is simple: never merge mobile and desktop field percentiles into a single averaged number for client decks.
Decision tree: what to check when PageSpeed Insights has no data
Use this sequence before you tell a client their CLS or INP "does not exist."
1. Confirm the exact URL (scheme, host, trailing slash) matches the live page
|
v
2. Check ORIGIN field data in PageSpeed Insights (same host, homepage if needed)
|
+-- Origin also missing --> likely low traffic or new site; skip to step 5
|
v
3. Check URL-level field data for the same metric on MOBILE and DESKTOP
|
+-- One form factor missing --> report the eligible one; lab-monitor the other
|
v
4. Compare LCP vs CLS vs INP availability (metric-specific gaps are common)
|
+-- Only INP/CLS missing --> interactions or shifts rare vs LCP paint; still fix in lab
|
v
5. Run lab Lighthouse on the template; store scheduled lab trends for proof
|
v
6. Set performance budgets and alerts on lab CLS/TBT (and field when it appears)
Step 4 matters for triage. A URL with field LCP but no field CLS often still has layout shift risk; Lighthouse lab CLS on that template is your honest diagnostic until CrUX accumulates enough sessions. A URL with no field INP may still have interaction pain visible as lab TBT or as INP in Chrome DevTools performance recordings on a real device.
If origin and URL both lack all field metrics, read Google's public guidance on discovering what your real users experience and treat the property as field-ineligible for now. SEO impact is evaluated at the origin level where data exists; product impact on a thin URL still warrants lab budgets because your users feel the page even when CrUX does not publish a percentile.
How agencies should monitor low-traffic URLs without CrUX samples
When PageSpeed Insights returns no field CLS or INP, your operating model shifts from field percentiles to template-level lab cadence plus origin field context.
Pick representative URLs, not every long-tail path. Monitor checkout, pricing, primary landing templates, and top blog layouts on a schedule. One good template lab series beats fifty one-off PSI pastes that all show "no data."
Store lab CLS and TBT (INP proxy) over time. Field INP may appear later if traffic grows; until then, regression alerts on lab metrics catch script and font changes that would hurt real users. Tie thresholds to performance budget templates and explain in client reports that field slices are pending, not ignored.
Use origin field data for executive summaries. When URL-level INP is missing, origin mobile INP still informs whether the domain broadly passes interactivity expectations. Pair that with lab evidence on the specific template you shipped last Tuesday.
Document device splits in every report. Note "mobile field INP: 142 ms p75; desktop field INP: not available (insufficient CrUX sample)" so stakeholders do not assume desktop is fine because mobile is green.
Re-test after traffic events. Product launches, paid campaigns, and seasonal enrolment can push a URL over CrUX URL thresholds. Schedule a quarterly eligibility check on pages that matter commercially.
Apogee Watcher is built for that layered model: scheduled PageSpeed Insights and Lighthouse runs across many client sites, budgets on lab metrics, and alerts when a priority URL regresses, while you still read field slices where Google publishes them. It does not manufacture CrUX samples for pages Chrome users rarely visit. It keeps lab proof continuous until field data catches up.
When field CLS or INP returns, compare it to the lab trend you stored. If they diverge, you are usually looking at cache mix, device diversity, or third-party behaviour that lab did not emulate. That is when CLS deep-dive fixes and LCP, INP, and CLS explained move from reference reading to sprint work.
FAQ
Why does PageSpeed Insights show lab CLS but no field CLS?
Lab CLS comes from Lighthouse on every run. Field CLS requires enough real Chrome sessions on that origin or URL in CrUX. Low traffic, URL-level ineligibility, or a form factor with too few sessions are the usual causes.
Does missing INP in PageSpeed Insights mean the page passes interactivity?
No. It means CrUX does not have enough interaction data to publish field INP for that slice. Use lab TBT, manual device testing, and scheduled lab monitoring until field INP appears or you confirm the URL is intentionally low priority.
Can I force URL-level CrUX data to appear?
You cannot opt in a single URL. Eligibility follows Chrome traffic volume and Google's privacy thresholds. Growing organic and paid traffic to the URL, fixing canonical and redirect issues, and waiting through the 28-day rolling window are the levers you actually have.
Should I report origin data when the client asked about one URL?
Yes, with a clear label. Origin field Core Web Vitals describe the domain's eligible traffic pool. Pair origin field status with lab results on the specific template so the client sees both the SEO-wide picture and the page they shipped.
Is "no data" the same as a failing Core Web Vital?
No. Missing field data is not a pass or fail badge. Search Console may use origin-level grouping for URLs without their own field row. Treat missing data as "not enough field evidence," then use lab monitoring and origin context until URL-level metrics qualify.
When should I use the CrUX API instead of PageSpeed Insights?
Use PageSpeed Insights for a quick human-readable check. Use the CrUX API or History API when you need to store daily or weekly field percentiles in your own database across many origins. Eligibility rules are the same; the API does not bypass sample limits.
Missing CLS or INP in PageSpeed Insights is a data availability problem, not a mystery bug. Read origin before URL, mobile before you assume desktop, lab before you declare victory, and keep scheduled synthetic monitoring on the templates that drive revenue while CrUX catches up.
Start a free trial to schedule PageSpeed tests, set lab budgets on priority URLs, and track regressions across client portfolios when field data is thin or absent.
References
- How to view Chrome UX Report data on PageSpeed Insights (Chrome for Developers)
- Chrome User Experience Report documentation (Chrome for Developers)
- CrUX API (Chrome for Developers)
- What Are Core Web Vitals? A Practical Guide for 2026
- LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It
- CLS Deep-Dive: Common Causes and Fixes for Layout Shift
- PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough
- When to Use Synthetic vs Real User Monitoring for Performance
- CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History
- Why Your Core Web Vitals Fix Isn't in CrUX Yet (28-Day Window)
- Mobile vs Desktop Core Web Vitals: Why You Need to Monitor Both
- Performance Budget Thresholds Template
Top comments (0)