Core Web Vitals (Page Experience)

What this parameter measures

Page experience measures the real-user performance of your pages across three Core Web Vitals: Largest Contentful Paint (LCP, loading speed), Cumulative Layout Shift (CLS, visual stability), and Interaction to Next Paint (INP, responsiveness). friendly4AI queries the Chrome User Experience Report (CrUX) API for field data — measurements collected from real Chrome users visiting your site — using the 75th-percentile (p75) values for each vital. When CrUX holds no field data for the URL (for example because the site is too new or has insufficient traffic), this parameter degrades to an advisory UNKNOWN outcome: it is excluded from the score denominator entirely and contributes neither a pass nor a penalty to your composite score.

Why it matters for AI-readiness

Google explicitly uses page experience as a ranking signal in its Search Generative Experience and AI Overviews, with Core Web Vitals forming the primary page-experience criteria. Pages that load slowly, shift content unexpectedly, or respond sluggishly to interaction are deprioritised in AI-generated answer surfaces compared with fast, stable alternatives covering the same topic. The CrUX field data used here is the same data Google's ranking systems consume, so the score directly reflects how Google's AI indexing layer sees your page's performance.

How we score it

Under the v4.5 methodology, this Technical SEO parameter is scored against CrUX p75 field data with three tiers. It passes (100) when all three vitals are Good: LCP at or below 2500 ms, CLS at or below 0.1, and INP at or below 200 ms. It scores partial (50) when at least one vital is in the Needs Improvement band (LCP 2500–4000 ms, CLS 0.1–0.25, INP 200–500 ms) and none are Poor. It fails (0) when any vital is Poor: LCP above 4000 ms, CLS above 0.25, or INP above 500 ms. If CrUX returns no field data for the URL, the result is UNKNOWN (advisory) — the parameter is excluded from the score denominator, so your total score is computed over the remaining parameters only and you are not penalised for insufficient CrUX coverage.

How to fix common issues

• LCP above 4 s (Poor): Identify the largest above-the-fold element (usually a hero image or heading block), preload it with <link rel="preload">, serve images in WebP/AVIF from a CDN, and remove render-blocking scripts that delay the first meaningful paint.
• CLS above 0.25 (Poor): Reserve explicit width and height attributes on all images and video embeds; avoid inserting content above existing elements (ads, banners, cookie notices) after load; use font-display: swap with proper size fallbacks to prevent layout shifts from web fonts.
• INP above 500 ms (Poor): Break up long JavaScript tasks using scheduler.yield() or setTimeout chunking; defer non-critical third-party scripts; use useTransition in React to keep interactions responsive during heavy renders.
• Use PageSpeed Insights and the CrUX dashboard to identify which vital is lagging and which pages drive the p75 values.
• Re-scan after deploying fixes; CrUX data refreshes monthly, so improvements appear in the next data window.