Site speed and Core Web Vitals

Site speed influences both the crawl budget bots devote to your site and the actual experience of your visitors: a slow site gets crawled less often and less deeply, and loses visitors before they even reach the content. Core Web Vitals are the standard way to measure that speed in a way that's comparable across sites.

Why speed affects crawl budget and experience

Crawl budget refers to the number of pages a bot is willing to explore on your site within a given time. That budget isn't unlimited: it depends partly on how quickly your server responds. It's generally observed that a slow or unstable site pushes bots to reduce how often they visit and how many pages they crawl per visit, which mechanically slows down the discovery of new content and its update in the index.

On the user side, the effect is more direct: a long loading time increases the abandonment rate before content even renders. For a GEO objective, this matters twice over: a slow page has less chance of being crawled by an AI crawler, and less chance of being read all the way through by a visitor who clicked through from a generated answer.

The three Core Web Vitals metrics explained

Google defined three metrics that together make up Core Web Vitals:

• LCP (Largest Contentful Paint): the time it takes to render the largest visible element on screen (often a hero image or a headline). Generally recommended target: under 2.5 seconds.
• INP (Interaction to Next Paint): the delay between a user interaction (click, keypress) and the corresponding visual update. This metric replaced FID (First Input Delay) in 2024. Generally recommended target: under 200 milliseconds.
• CLS (Cumulative Layout Shift): a measure of unexpected visual shifts during loading (a button that moves right before you click it, for instance). Generally recommended target: under 0.1.

These thresholds are indicative benchmarks published by Google, not absolute rules that apply everywhere: a site with a lot of complex interactive content may tolerate slightly different margins depending on its use case.

Measuring with PageSpeed Insights (and why not only that)

pagespeed.web.dev is the reference tool for testing a specific page. It provides two types of data, worth telling apart:

• Field Data, sourced from the Chrome User Experience Report, reflecting the real experience of your visitors over the last 28 days — only available if your site gets enough Chrome traffic.
• Lab Data, generated from a simulated test at the moment you run the analysis — useful for diagnosis, but can vary from one run to the next depending on the simulated network conditions.

The Core Web Vitals report in Google Search Console, covered in an earlier lesson, complements this tool by giving an aggregated site-wide view rather than a page-by-page one, which helps prioritize by template rather than by isolated URL.

Mobile and desktop: two separate realities

Core Web Vitals are evaluated separately for mobile and desktop, and the results often diverge quite a bit between the two. Since most web traffic today happens on mobile, and Google uses "mobile-first" indexing (your page's mobile version is the reference used for crawling and evaluation), it's advisable to treat mobile results as the priority whenever there's a trade-off to make. A site that scores well on desktop but poorly on mobile is still, from Google's standpoint, a site with a speed problem to fix.

The most common fixes, and their order of priority

In most audits, the fastest wins come from:

1. Image compression and resizing: serve images at the size they're actually displayed, in a modern format (WebP or AVIF), with lazy loading for off-screen images.
2. Reducing blocking JavaScript: defer loading of scripts that aren't essential to the initial render (live chat, third-party widgets, secondary ad pixels).
3. Reserving space for dynamic elements: define explicit dimensions for images, videos, and ads before they load, to avoid layout shifts (CLS).
4. Caching and CDN: use a content delivery network to bring static files closer to visitors, and configure appropriate browser caching.
5. Hosting choice: cheap shared hosting is often the hardest limiting factor to fix without switching technical solutions.

Tracking the impact over time

After each significant fix, re-test with PageSpeed Insights and watch Search Console's Core Web Vitals report over the following weeks rather than the following hour: field data is based on a rolling 28-day window, so it doesn't react instantly to a change.

Once speed is under control, the site's technical foundation is largely in place. It's time to move on to controlling bot access with the lesson on the robots.txt file and controlling AI crawlers, then to understand in detail how a search engine reads a page.