What Is Page Speed? How Google Measures It

Aug 09, 2026 · SEO Glossary

Run the same URL through PageSpeed Insights twice and you'll often get two different scores. That confuses people into thinking the tool is broken. It isn't — it's telling you that "page speed" is not a single number. It's a family of measurements, taken under different conditions, and Google cares about some of them far more than others.

So what is page speed in the way that actually affects your rankings? It's how quickly real users perceive your page to load and respond, measured in the field across your actual visitors — not the synthetic score a lab test spits out.

Lab Data vs. Field Data: The Distinction That Explains Everything

Lab data comes from a controlled test — Lighthouse running on simulated hardware with throttled network. It's reproducible and great for debugging, but nobody browses your site on that exact simulated device.

Field data comes from the Chrome User Experience Report (CrUX): anonymized measurements from real Chrome users over the trailing 28 days. This is what feeds the page experience signals in ranking, and it's what Search Console's Core Web Vitals report shows you. A page can score 95 in the lab and still fail in the field because your real audience is on mid-range Android phones over 4G.

When the two disagree, believe the field data. The lab is your workshop; the field is your report card.

What Is Page Speed Measured By? The Metrics That Count

As of 2026, Google's Core Web Vitals are three metrics, each graded at the 75th percentile of visits:

INP replaced First Input Delay in March 2024, and it's meaningfully harder to pass — FID only measured the delay before your code started running; INP measures until the screen actually updates. Sites that coasted on FID found long JavaScript tasks suddenly exposed.

Two supporting numbers matter even though they aren't Core Web Vitals: TTFB (time to first byte — your server response time, ideally under 200ms) and total page weight. Neither is a direct signal, but a slow TTFB puts a hard floor under your LCP: if the first byte arrives at 1.8 seconds, a 2.5-second LCP is nearly impossible.

How Much Does Speed Move Rankings?

Honest answer: it's a lightweight signal, mostly a tiebreaker between pages of similar relevance. You will not outrank better content by shaving 300ms. But the indirect effects are larger than the direct one. Slow pages depress conversion measurably — retail studies keep landing on roughly a few percent conversion loss per extra second. And a sluggish server slows Googlebot too: Google adapts its crawl rate to how fast your server responds, so a slow site gets crawled more conservatively, which matters once you're past a few thousand URLs.

Where the Big Wins Usually Are

After enough audits, the same culprits keep appearing, in roughly this order of payoff:

1. Oversized images. Still the #1 offender. A 2 MB hero PNG that should be a 90 KB WebP will dominate your LCP all by itself.
2. Slow TTFB. Uncached CMS pages rebuilding on every request. Page caching or a CDN typically cuts TTFB from 800ms+ to under 200ms.
3. Render-blocking CSS and JavaScript in the head, delaying first paint — covered in depth in our render-blocking resources guide.
4. Third-party scripts. Tag managers accumulate trackers for years. Each one costs main-thread time, and INP pays the bill.
5. Layout shift from unsized media. Missing width/height attributes on images and late-loading ad slots.

Verifying It Yourself

Start with Search Console's Core Web Vitals report — it groups URLs by shared problem, so one template fix often clears hundreds of pages at once. Cross-check individual URLs in PageSpeed Insights, reading the field section first and the lab diagnostics second. For anything CrUX won't show (low-traffic pages don't get field data), lab testing is your only option — just apply the thresholds with skepticism.

Two habits make your testing honest. First, test on hardware that resembles your audience's: a page that feels instant on a developer's laptop can take three times as long to become interactive on a mid-range phone, because mobile CPUs execute your JavaScript far slower — this gap is exactly why INP failures cluster on mobile. Second, test the templates your visitors actually land on. Teams benchmark the homepage obsessively while 80% of organic sessions enter through article or product templates that nobody has profiled. Pull your top landing pages from analytics and test those.

Speed also regresses silently: one new marketing script or one unoptimized upload can undo a quarter's work. A scheduled site audit that flags slow pages and oversized images on every crawl catches the regression the week it ships, which beats discovering it in next month's CrUX data.