AI-readiness guide

Full page speed (Lighthouse + Core Web Vitals)

Passing the full Lighthouse run, LCP, CLS, and blocking time, a documented Search quality and crawl-efficiency signal.

The basic check estimates first paint. This one is the full lab run: an actual Lighthouse measurement of how your page loads, responds, and holds still. It is the difference between a glance and a proper diagnostic.

What it is

Lighthouse is Google’s open-source page-quality tool. It loads your page in a controlled environment and scores it, including the three Core Web Vitals, the metrics Google uses to judge real-world page experience.

From web.dev, the three vitals and their “good” thresholds:

  • LCP (Largest Contentful Paint): 2.5 seconds or less. How fast the main content appears.
  • INP (Interaction to Next Paint): 200 milliseconds or less. How quickly the page responds when someone interacts. INP replaced the older FID metric as a Core Web Vital in March 2024.
  • CLS (Cumulative Layout Shift): 0.1 or less. How much the layout jumps around as it loads.

Why it matters

Same framing as the basic check: no AI engine publicly names page speed as a citation factor, so this is a general quality signal, not a documented AI lever. What makes it worth passing is that Core Web Vitals are part of Google’s documented Search ranking systems, many AI answers draw on those indexes, and a fast, stable page is easier for any system to crawl and render. Passing the full run means you are strong across all three dimensions, not just first paint.

How to run it and read it

You can run Lighthouse from Chrome DevTools (the “Lighthouse” tab), from PageSpeed Insights, or from the command line:

npx lighthouse https://yourdomain.com --view

One distinction that trips people up: lab data versus field data.

  • Lab data (what Lighthouse gives you) is a single synthetic load in a controlled setting. Great for diagnosing and debugging.
  • Field data (from real visitors, via Google’s CrUX dataset) is what Google actually uses for the Core Web Vitals assessment.

This matters most for INP, which depends on real user interactions and cannot be fully captured in one lab load. In the lab, watch Total Blocking Time (TBT) instead, web.dev calls it a reasonable proxy for INP, though not a substitute.

How to improve it

The three vitals have three different fixes:

  • LCP: speed up your server response and your largest content element. The full set of levers is in the basic page speed guide.
  • INP / TBT: reduce heavy JavaScript work on the main thread. Break up long tasks, defer or remove unused scripts, and avoid doing expensive work in response to clicks and taps.
  • CLS: stop the layout from jumping. Set explicit width and height (or aspect-ratio) on images and embeds, reserve space for ads and late-loading content, and avoid inserting content above what the reader is already looking at.

Do not chase a perfect score

Do not chase a perfect Lighthouse score for its own sake. The goal is to clear the “good” thresholds on the three vitals for your real visitors, on the devices and networks they actually use. A flawless lab score on a page that still feels slow on a mid-range phone has missed the point. Fix what your field data, and your own phone, tell you is slow.

Sources

All guides →