A slow page is a page that gets read less. Crawlers have budgets, people have patience, and both run out. This check is a quick estimate of how fast your homepage shows its main content, and whether that is fast enough to stay in the running.
What it is
This is a lightweight estimate of your Largest Contentful Paint (LCP): roughly how long it takes for the biggest piece of content on your page, usually your hero image or headline, to appear. It is the single most useful “is this page fast?” number, and it is one of Google’s three Core Web Vitals.
The bar from web.dev: an LCP of 2.5 seconds or less is good; 2.5 to 4 seconds needs work; over 4 seconds is poor. This check is an estimate, not the full lab measurement. For that, see the full page speed guide.
Why it matters
The claim is often overstated, so be precise. No AI engine publicly lists page speed as a citation criterion. So treat speed as a strong general signal, not a documented AI ranking lever.
Two things make it matter anyway. First, page speed is a documented Google Search ranking signal (Core Web Vitals are part of Google’s ranking systems), and many AI answers lean on or correlate with traditional search indexes. Second, a fast, reliably served page is simply easier for any crawler or fetcher to retrieve, which protects your crawl coverage. Fast pages are not a trick; they are table stakes for being read well everywhere.
How to improve it
LCP is mostly about two things: how quickly your server responds, and how quickly the main content can paint after that.
- Cut your time to first byte. TTFB is the wait before any content arrives, and it feeds directly into LCP. web.dev’s good bar is 0.8 seconds or less. Edge-cache your HTML on a CDN so it serves from near the visitor, minimize redirect chains, and reduce slow server work on the critical path.
- Make the LCP element fast to load. This is usually the hero image. Make sure it is discoverable directly in the HTML, compress it and use a modern format (WebP or AVIF), size it correctly, and add
fetchpriority="high". Never putloading="lazy"on the image that is your LCP element, that delays the very thing being measured. - Remove render-blocking resources. Defer non-critical JavaScript, inline critical CSS, and control web-font loading with
font-displayso text is not stuck waiting on a font.
Even a single change here, putting your HTML behind a CDN, often moves the number noticeably.
This is an estimate, not the verdict
This estimate is a fast first read, not the verdict. Real LCP varies by device and network, and the number your actual visitors experience (field data) is what Google ultimately uses. If this check flags you, treat it as a prompt to run the full Lighthouse and Core Web Vitals measurement, which looks at the whole picture, not just first paint.