TL;DR. Core Web Vitals — LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 — are a Google ranking factor. Field data (CrUX, 28-day rolling real-user) beats lab data for this reason.
The CrUX Field Data Probe is the audit you reach for when you already suspect a problem in this dimension and need a fast, copy-paste-able fix list. It reuses the same chrome as every other jwatte.com tool — deep-links from the mega analyzers, AI-prompt export, CSV/PDF/HTML download — but the checks it runs are narrow and specific to the dimension described above.
Fetches real-user Chrome UX Report p75 field data via the PageSpeed Insights API (no API key needed for low volume). Shows actual user experience metrics Google ranks on, not lab simulation.
What it actually checks
Extract of the audit's real findings — the same strings the tool prints when a check trips. Use this as a sanity check before you run the audit live:
Info-only (context for the fix plan — not a failure):
- Metrics passing
Why this dimension matters
Core Web Vitals (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1) are a Google ranking factor. They also gate how often a page can appear in AI Overviews — slow pages get deprioritized in the answer-generation step after the retrieval step. Field data (CrUX, 28-day rolling real-user) beats lab data (Lighthouse) for this reason: Google indexes field metrics, not synthetic ones.
Common failure patterns
- LCP hero image with
loading="lazy"— lazy-loading the LCP element defers it beyond the above-the-fold paint. The rule is: LCP image = no lazy, addfetchpriority="high", preload it in<link rel="preload" as="image">with the rightimagesrcsetfor responsive variants. - CLS from late-loading web fonts —
font-display: swapwithoutsize-adjust/ascent-overridefallback produces a layout shift at font load. Usefont-display: optionalon non-critical fonts, or match metrics precisely with a fallback stack. - INP from long tasks on interaction — a single
main-threadtask over 50ms blocks next-paint. The fix is breaking up handlers withrequestIdleCallback,scheduler.yield(), or post-message loops. Third-party analytics scripts are the most common culprit;defer+Partytown/ WebWorker offload helps. - TTFB regressions from cold serverless — scheduled functions with per-region cold starts add 300–1500ms to every geographically-distant visitor. Edge functions (Cloudflare Workers, Vercel Edge, Netlify Edge Functions) cut this to ~50ms.
How to fix it at the source
Treat CrUX field data as the authoritative measure; Lighthouse lab data is a proxy. Instrument your own RUM (the web-vitals library emits LCP/CLS/INP/TTFB/FCP to any endpoint) for percentile breakdowns beyond CrUX's 28-day window. For images: preload the LCP, lazy-load everything below the fold, always provide intrinsic width/height. For scripts: defer or async or Web Worker — never sync at the top of <head>.
Thresholds that matter
| Signal | Target |
|---|---|
| LCP (Largest Contentful Paint) | Good ≤ 2500ms · Needs Improvement 2500–4000ms · Poor > 4000ms (p75 at origin) |
| INP (Interaction to Next Paint) | Good ≤ 200ms · Needs Improvement 200–500ms · Poor > 500ms (p75) |
| CLS (Cumulative Layout Shift) | Good ≤ 0.1 · Needs Improvement 0.1–0.25 · Poor > 0.25 |
| TTFB (Time to First Byte) | Good ≤ 800ms · Needs Improvement 800–1800ms · Poor > 1800ms |
| FCP (First Contentful Paint) | Good ≤ 1800ms · Needs Improvement 1800–3000ms · Poor > 3000ms |
Example fix
LCP hero image — minimal fix:
<!-- Fail: lazy on LCP, no priority hint, no preload -->
<img src="/images/hero.webp" loading="lazy" alt="Hero">
<!-- Pass: eager, prioritized, preloaded, with srcset for responsive variants -->
<link rel="preload" as="image"
href="/images/hero-1200.webp"
imagesrcset="/images/hero-800.webp 800w, /images/hero-1200.webp 1200w, /images/hero-1600.webp 1600w"
imagesizes="100vw">
<img src="/images/hero-1200.webp"
srcset="/images/hero-800.webp 800w, /images/hero-1200.webp 1200w, /images/hero-1600.webp 1600w"
sizes="100vw"
width="1600" height="900"
fetchpriority="high"
decoding="async"
alt="Hero image of the product in use">
When to run the audit
- After a major site change — redesign, CMS migration, DNS change, hosting platform swap.
- Quarterly as part of routine technical hygiene; the checks are cheap to run repeatedly.
- Before an investor / client review, a PCI scan, a SOC 2 audit, or an accessibility-compliance review.
- When a downstream metric drops (rankings, conversion, AI citations) and you need to rule out this dimension as the cause.
Reading the output
Every finding is severity-classified. The playbook is the same across tools:
- Critical / red — same-week fixes. These block the primary signal and cascade into downstream dimensions.
- Warning / amber — same-month fixes. Drag the score, usually don't block.
- Info / blue — context only. Often what a PR reviewer would flag but that doesn't block merge.
- Pass / green — confirmation. Keep the control in place.
Every audit also emits an "AI fix prompt" — paste into ChatGPT / Claude / Gemini for exact copy-paste code patches tied to your specific stack.
Related tools in this family
- Mega Analyzer — kitchen-sink audit — use when you want CWV alongside SEO/schema/security.
- Image LCP Candidate Audit — identifies which image is the LCP element and whether it's properly prioritized.
- Font Loading Strategy Audit — detects CLS-causing font-load patterns (the #2 CLS source after ads).
- Critical CSS Inlining Audit — sibling performance audit — focuses on render-blocking CSS.
- Preconnect + DNS-Prefetch Hygiene — verifies preconnect/dns-prefetch hints are useful and not over-used.
Fact-check notes and sources
- Web.dev: Core Web Vitals
- Chrome UX Report: https://developer.chrome.com/docs/crux
- Addy Osmani: Image optimization recipes
- W3C: Resource Hints spec — preconnect, preload, prefetch
- GoogleChromeLabs: web-vitals library — RUM instrumentation
This post is informational and not a substitute for professional consulting. Mentions of third-party platforms in the tool itself are nominative fair use. No affiliation is implied.
