Definition
Page speed is how quickly a web page responds to a request, displays its main content and becomes usable. It is not a single number. It covers server response time (Time to First Byte), how fast the largest visible element appears (Largest Contentful Paint), and how quickly the page reacts to clicks and taps (Interaction to Next Paint), along with supporting metrics such as First Contentful Paint and Total Blocking Time.
Page speed overlaps with page experience but is narrower. Page experience is Google's broader idea of a usable page, including security, mobile display and ads. Page speed is the performance part, and it matters to three audiences: human visitors, Google's ranking systems and AI crawlers.
For Google, speed reaches rankings through Core Web Vitals. The thresholds, measured at the 75th percentile of real page loads, are LCP within 2.5 seconds and INP of 200 milliseconds or less, plus CLS of 0.1 or less for visual stability (web.dev). Google treats these as one input among many, and relevance still comes first.
There are two kinds of measurement, and they answer different questions:
- Field data comes from real users, mainly the Chrome User Experience Report, and powers Search Console's Core Web Vitals report and the top section of PageSpeed Insights. This is what Google uses.
- Lab data comes from a simulated load in Lighthouse or Chrome DevTools. It is reproducible and useful for debugging, but it cannot measure INP because there is no real user input; Total Blocking Time is the lab proxy.
For AI search, the most important speed metric is often the simplest one: how quickly and reliably the server returns complete HTML. AI systems fetch pages in two ways. Background crawlers such as OAI-SearchBot, PerplexityBot and ClaudeBot build indexes, and user-triggered fetchers such as ChatGPT-User or Perplexity-User retrieve a page while a person waits for an answer. A slow origin, frequent 5xx errors or rate limiting can mean fewer pages crawled and pages skipped during live retrieval. Most of these crawlers do not execute JavaScript: Vercel's December 2024 analysis found that OpenAI's, Anthropic's, Meta's and Perplexity's crawlers fetch script files but do not run them, while Google's Gemini uses Googlebot's rendering. A page that is fast for humans because it renders in the browser can still be effectively empty to an AI crawler.
The practical priorities follow from that. Serve main content in the initial HTML through server-side rendering or static generation, so it does not depend on JavaScript. Keep Time to First Byte low with caching and a CDN, and make sure bot-protection rules do not slow or challenge legitimate AI crawlers. Optimize the LCP element with compressed modern image formats and preloading, and never lazy-load it. Reduce long JavaScript tasks to improve INP by splitting bundles, deferring third-party scripts and removing unused code. Reserve space for images, ads and embeds to avoid layout shifts.
Then measure from both sides. Use field data for Google, and AI crawler logs for AI systems: response times, status codes and bytes returned per AI user agent show whether crawlers get fast, complete responses. Our study on how CDNs affect the way AI agents crawl and cite content looks at that layer in more detail. See also JavaScript rendering and crawl budget.
Examples of Page Speed
- An online retailer moves product pages from client-side rendering to static generation with hourly revalidation. LCP improves from 3.8 to 1.9 seconds, and AI crawler logs show full product descriptions in the HTML that OAI-SearchBot receives.
- A publisher's origin server responds in over two seconds during traffic peaks. After adding CDN caching for article pages, Time to First Byte drops below 200 milliseconds and 5xx errors to AI crawlers disappear from its logs.
- A SaaS site scores 95 in Lighthouse but fails INP in Search Console field data because a chat widget and three analytics tags block the main thread on real devices. Deferring them fixes the field metric.
- A documentation site finds PerplexityBot receiving 429 rate-limit responses during a crawl burst and raises the limit for verified Perplexity IP ranges instead of blocking.
