Core Web Vitals (Page Experience)

The Core Web Vitals (Page Experience) parameter checks whether your pages meet Google's three field-data performance thresholds — LCP ≤ 2.5s, CLS ≤ 0.1, and INP ≤ 200ms — measured from real Chrome users via the CrUX API. This is a Google-only signal, scored from 75th-percentile (p75) field data. It passes only when all three vitals sit in the "Good" range.

What does the Core Web Vitals parameter measure?

It measures real-user (field) performance across three Core Web Vitals:

• Largest Contentful Paint (LCP) — loading speed.
• Cumulative Layout Shift (CLS) — visual stability.
• Interaction to Next Paint (INP) — responsiveness.

friendly4AI pulls field data from the Chrome User Experience Report (CrUX) API — measurements from actual Chrome users visiting your site — and reads the 75th-percentile (p75) value of each vital. Sometimes CrUX has no field data for a URL, usually because the site is new or its traffic is too thin to report. In that case the parameter returns an advisory UNKNOWN: it drops out of the score denominator and counts as neither a pass nor a penalty against your composite score.

Why does page experience matter for AI-readiness?

Google treats page experience as a ranking signal in AI Overviews and Search Generative Experience, and Core Web Vitals are the primary page-experience criteria. When two pages cover the same topic, the one that loads slowly, shifts content under the reader, or lags on input gets pushed down in AI-generated answers. The CrUX field data scored here is exactly what Google's ranking systems read, so your result mirrors how Google's AI indexing layer sees the page. Back fast pages with a reachable origin (HTTP reachability) and clean transport (security headers baseline) to round out the technical foundation.

How is the Core Web Vitals parameter scored?

Under the v4.5 methodology, this Technical SEO parameter scores against CrUX p75 field data in three tiers:

• Pass (100): all three vitals are Good — LCP ≤ 2500 ms, CLS ≤ 0.1, and INP ≤ 200 ms.
• Partial (50): at least one vital sits in the Needs Improvement band (LCP 2500–4000 ms, CLS 0.1–0.25, INP 200–500 ms) and none are Poor.
• Fail (0): any vital is Poor — LCP above 4000 ms, CLS above 0.25, or INP above 500 ms.

When CrUX has no field data for the URL, the result is UNKNOWN (advisory): the parameter drops from the score denominator, your total is computed over the remaining parameters only, and thin CrUX coverage costs you nothing.

How do I fix Core Web Vitals failures?

• LCP above 4 s (Poor): Find the largest above-the-fold element — usually a hero image or heading block — and preload it with <link rel="preload">. Serve images in WebP/AVIF from a CDN, and strip out render-blocking scripts that delay the first meaningful paint.
• CLS above 0.25 (Poor): Set explicit width and height attributes on every image and video embed. Don't inject content above existing elements (ads, banners, cookie notices) after load. Use font-display: swap with matching size fallbacks so web fonts don't push the layout around.
• INP above 500 ms (Poor): Break long JavaScript tasks into chunks with scheduler.yield() or setTimeout. Defer non-critical third-party scripts. Reach for useTransition in React to keep interactions responsive while a heavy render runs.
• Use PageSpeed Insights and the CrUX dashboard to see which vital is lagging and which pages drive the p75 values.
• Re-scan once your fixes ship. CrUX data refreshes monthly, so improvements show up in the next data window.