Page speed: metrics, testing, and optimization tips

What is page speed?

Page speed describes how quickly a web page's resources load and become usable for a visitor. It is observed in two testing contexts: lab (synthetic) tests that simulate a device and network, and field (real-user) measurements collected from real browsers. Page speed is expressed via metrics that capture different user-centric phases, such as loading, first paint, interactivity and visual stability.

Why page speed matters for SEO

Faster pages improve user experience: they reduce wait time, lower abandonment and help visitors interact with content sooner. Search engines use page speed signals as part of broader ranking systems—Core Web Vitals are one set of signals that contribute to the page experience signal—but ranking is multi-factor and not determined by speed alone. Also note that since July 2024 Google crawls sites with Googlebot Smartphone by default; measure mobile page speed because the mobile rendering and resource set are the primary basis for crawling and indexing.

How page speed works

Page speed arises from interactions between server/network, resource payloads and client-side rendering. Key stages are: DNS lookup and TCP/TLS handshake, initial HTML response, downloading and parsing CSS/JS/images, rendering the first meaningful content, and executing scripts that enable interactivity. Both lab tools (which control device and network) and field data (real-user metrics) are needed to understand performance across audiences and conditions.

Types of page speed

Distinguish these common categories:

- Lab testing — controlled, repeatable audits using tools like Lighthouse or WebPageTest. Pros: reproducible, isolates regressions. Cons: may not reflect all real-user conditions.
- Field (real-user) data — RUM collected from actual visitors (Chrome UX Report / PageSpeed Insights field data, and the Core Web Vitals report in Google Search Console for your property). Pros: shows actual experience. Cons: noisy and influenced by audience device/network mix.
- Perceived vs. technical speed — perceived speed focuses on when users feel the page is useful (First Contentful Paint, Largest Contentful Paint), while technical speed includes metrics like total download time or number of requests.

How to get started with page speed

Start by combining lab and field measurements. For your own site, check the Core Web Vitals report in Google Search Console and compare it to PageSpeed Insights and Lighthouse results for representative pages. Prioritise: reduce large render-blocking resources, optimise images and fonts, use efficient caching and server response headers, and audit third-party scripts. Measure before and after each change so you can confirm impact.

How to verify and troubleshoot page speed

Field data: PageSpeed Insights and Core Web Vitals

Use PageSpeed Insights (which surfaces CrUX field data when available) to see real-user LCP, FCP and INP distributions. For properties you own, use the Core Web Vitals and Page Experience reports in Google Search Console to get site-level and URL-level trends. Remember: field data reflects your actual audience mix and should guide prioritisation.

Lab testing: Lighthouse, Chrome DevTools, WebPageTest

Run Lighthouse (in Chrome DevTools or via the command line) and WebPageTest to reproduce conditions and inspect waterfall charts. In DevTools, use the Performance and Network panels to find render-blocking scripts and long tasks. Lab tests let you control device and throttling to compare changes consistently.

Server and network checks (curl and headers)

Use curl for quick surface checks. To inspect response headers only: curl -I https://example.com/page (returns headers, not body). To fetch the HTML that a given user-agent receives: curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page. Check Cache-Control, Content-Encoding, and server timing headers to verify caching and compression.

Practical checklist: page speed checks

**Field Core Web Vitals** — where to verify: PageSpeed Insights / Search Console Core Web Vitals — passes when field LCP, INP and CLS distributions are within acceptable ranges for your audience.

**Lab Lighthouse audit** — where to verify: Chrome DevTools Lighthouse or WebPageTest — passes when Lighthouse shows no critical render-blocking resources and reduced total blocking time.

**Server response time & caching** — where to verify: curl -I and server logs — passes when responses include appropriate Cache-Control and responses are consistently fast under normal load.

**Compression & payload size** — where to verify: Network panel in DevTools or curl with --compressed — passes when resources are compressed and total bytes transferred are minimized.

**Third-party scripts** — where to verify: DevTools Performance + Coverage — passes when non-essential third-party code is deferred or removed and long tasks are eliminated.

**Mobile rendering parity** — where to verify: Chrome DevTools device emulation + curl with a mobile UA — passes when mobile HTML/CSS/JS delivers equivalent content and performance characteristics as intended for mobile users.

Common page speed mistakes

- Relying only on lab scores: treating a single Lighthouse run as definitive without consulting field data.
- Large unoptimised images and fonts that block rendering.
- Excessive synchronous JavaScript or long tasks that delay interactivity.
- Missing or incorrect caching and compression headers.
- Heavy third-party scripts that inject work on the main thread.
- Measuring desktop performance when the site is crawled and indexed primarily by Googlebot Smartphone; mobile metrics must be prioritised.
- Serving different content to crawlers than to users (avoid cloaking); optimise the mobile/desktop experience per device class without hiding content from search engines.

Read the Technical SEO Guide

Frequently asked questions