Page Speed: What It Is, How to Measure It, and What Slows It Down

Page speed and Core Web Vitals get used interchangeably, but they are not the same thing. Page speed is the broad, colloquial term: the general perception and measurement of how long a page takes to load and become usable. It is a term SEO has used long before the current metrics existed, and it still gets used to talk about a site's overall performance in a client call or a brief, without pinning down exact numbers. Writing down just "improve page speed" in a report, without specifying which metric or which tool is meant, leaves the dev team guessing where to even start looking.

Core Web Vitals is the concrete implementation Google chose starting in 2020 to measure that performance in a standardized way: three metrics with defined numeric thresholds, part of the "page experience" signals in the search algorithm. Core Web Vitals is, in practice, a subset within page speed, the part Google turned into a measurable ranking factor. Page speed also covers aspects those three metrics do not capture directly, such as server response time on interactions that fall outside the LCP, INP or CLS calculation, or the general sense of smoothness a user gets while browsing.

For the full breakdown of LCP, INP and CLS, thresholds and examples included, there is a dedicated article on Core Web Vitals. This one covers what that article does not: how page speed actually gets measured and what slows it down.

Three free Google tools cover most of what you need to measure page speed.

PageSpeed Insights analyzes one specific URL at the moment you request it and returns two different data blocks for that page: lab data, and field data whenever enough real visits exist to generate it. It is the most common tool for a quick first check.

Lighthouse is the engine that runs the lab audit, whether inside PageSpeed Insights, Chrome DevTools, the command line, or a Node module. It simulates a visit under fixed conditions, a reference device and a reference connection, which is why it returns the same result every time as long as nothing on the page changes.

Search Console's speed report or Core Web Vitals report shows aggregated field data for groups of URLs with similar structure, not a single isolated page, over a window of several weeks. It best reflects what real visitors are actually experiencing, though it updates more slowly than a one-off test.

The gap between lab data and field data is the point that trips up most people new to these tools. Lab data, the kind Lighthouse produces, comes from a controlled environment: the same simulated device, the same connection speed, none of the noise of thousands of different real connections. It is useful for debugging a specific issue before shipping a change, because it is reproducible. Field data, sourced from the Chrome User Experience Report (CrUX), comes from real Chrome users who loaded that page on their own phones, laptops and connections, with all the variety that brings.

The two numbers not matching is not a tool malfunction or a sign of misconfiguration. They measure different things by design: a lab test run on fiber with a mid-range phone can come back "good" on LCP, while the real field data shows that a large share of visitors arrive on a budget phone over a weak 4G connection, dragging the aggregated result down. When the two figures diverge sharply, field data should drive prioritization, because it describes what the audience actually experiences.

It also helps to know how that field data gets generated in the first place. PageSpeed Insights calculates it over a rolling 28-day window, so it reflects aggregated behavior from the last four weeks, not from that particular day. If a specific URL does not get enough real traffic, Chrome will not generate field data for it at all, only the lab result shows up. In that case it is worth checking the aggregated figure for the group of URLs sharing a similar template in Search Console, rather than assuming the page simply has no real performance data available.

Almost every page speed problem traces back to a handful of technical causes that repeat project after project.

Uncompressed or oversized images relative to the space they render in are the single most common cause, especially on sites with heavy product photography or editorial imagery. The fix is serving images in modern formats like WebP or AVIF, compressing them before upload, and using responsive sizes that deliver the right resolution per device instead of one large image resized in CSS. Lazy loading images that sit below the first screen also helps, so the browser does not spend bandwidth on content the user has not scrolled to yet.

Render-blocking JavaScript and CSS force the browser to download and execute that code before it can paint anything on screen, even when that code has nothing to do with what the user sees first. The usual fix is deferring or loading non-critical JavaScript asynchronously, and inlining only the minimal CSS needed for the initial content, leaving the rest to load afterward. Marking non-essential scripts with the defer or async attributes, and checking which part of the stylesheet is actually needed to paint the first screen, tends to be the change with the best payoff for the effort it takes.

Missing caching forces the browser to redownload resources that barely change, logos, stylesheets, libraries, on every single visit. The fix is setting proper cache headers at the server or CDN level so those resources stay stored in the browser for a reasonable period and only get requested again when they genuinely change. It is worth distinguishing between browser caching, which stores static files like images or scripts, and full-page caching at the server level, which avoids regenerating dynamic HTML on every visit when the content has not actually changed.

A slow server response time, known as a high TTFB, delays everything downstream because the browser cannot start building the page until it gets that first response. The fix here involves reviewing the hosting setup, enabling server-side caching for pages that do not change on every request, and, when traffic volume justifies it, using a CDN that serves content from a location closer to the visitor. On sites running a content management system, a high TTFB often traces back to poorly optimized database queries or plugins running heavy tasks on every request, so checking that layer usually pays off more than simply switching hosting plans.

These four bottlenecks rarely show up alone. A page with heavy images and no server-side caching stacks the effects on top of each other: each cause adds its own delay, and the user feels the combined total, not each cause individually. That is why a page speed audit rarely gets solved by touching one single thing; it is worth checking all four causes in the same pass before calling the problem fixed.

• Measure the same URL with both PageSpeed Insights and Search Console's Core Web Vitals report before drawing conclusions, to compare lab data against real field data.
• Compress images and serve them in modern formats (WebP, AVIF) at sizes matched to each device, rather than uploading the original file untouched.
• Defer non-critical JavaScript and inline only the CSS needed for the visible initial content.
• Set cache headers at the server or CDN level for static assets that rarely change.
• Check server response time (TTFB) on a regular basis, not only after users start complaining about slowness.

• Relying only on Lighthouse's lab data and ignoring Search Console's field report, which better reflects what real visitors experience.
• Installing a "speed optimization" plugin without checking what it actually changes on the site, or verifying the result afterward.
• Uploading full-resolution images and letting the browser resize them via CSS, instead of generating the right size ahead of time.
• Loading all third-party JavaScript, chat widgets, ad pixels, embeds, synchronously in the head, blocking the rest of the page from loading.
• Treating page speed as a one-off task before launch instead of checking it regularly as new content and features get added.