Page Speed
Page speed is how quickly a web page's content loads so users can actually see and interact with it. It directly affects user experience and conversion, and is measured through Core Web Vitals, one of Google's Page Experience signals.
- Page speed is how fast a page's content loads and becomes usable, a core metric that shapes user experience, conversion, and SEO.
- Google measures speed and usability through Core Web Vitals (LCP, INP, CLS), which feed into the Page Experience signal that informs search ranking.
- The recommended thresholds are LCP under 2.5 seconds, INP at or below 200ms, and CLS at or below 0.1, assessed at the 75th percentile of real-user (field) data.
- You measure it with tools like PageSpeed Insights, Search Console, Lighthouse, and CrUX, and improve it through server response, render-blocking resources, and image optimization.
Overview
Page speed refers to the time it takes from the moment a user requests a page until its content appears on screen and becomes genuinely usable. The concept has grown beyond simply "how fast it shows up" to encompass loading, responsiveness, and visual stability together. When a page is slow, users tend to abandon it before the content even renders, which translates directly into lower conversion.
Google quantifies user experience, including page speed, through a set of metrics called Core Web Vitals. Core Web Vitals are part of the Page Experience signal, and Google's documentation states that they align with what its core ranking systems aim to reward. In other words, speed alone does not determine ranking, but it acts as a meaningful differentiator between pages of comparable content quality.
The Three Core Web Vitals
Page speed and usability are measured by three key metrics.
- LCP (Largest Contentful Paint) — loading performance. It measures when the largest content element in the viewport renders, with a good threshold of 2.5 seconds or less.
- INP (Interaction to Next Paint) — responsiveness. It measures the delay before the screen responds to user interaction, with a good threshold of 200 milliseconds or less.
- CLS (Cumulative Layout Shift) — visual stability. It measures the cumulative amount of unexpected layout movement during loading, with a good threshold of 0.1 or less.
| Metric | Measures | Good Threshold |
|---|---|---|
| LCP | Loading performance | 2.5s or less |
| INP | Responsiveness | 200ms or less |
| CLS | Visual stability | 0.1 or less |
Assessment is based on the 75th percentile of real-user data, evaluated separately for mobile and desktop. In practice, 75% of users must receive a good experience for a metric to be considered passing.
Measurement Tools
Page speed measurement splits into field data collected from real users and lab data measured in a controlled environment. Google states explicitly that lab measurement cannot replace field measurement. Lab data is useful for catching regressions during development, but it cannot reflect actual devices, networks, and interactions.
- PageSpeed Insights — the flagship diagnostic tool that provides both field data (CrUX) and lab data (Lighthouse) together.
- Search Console Core Web Vitals report — shows the performance status of pages across the entire site, grouped by status, based on real-user data.
- CrUX (Chrome User Experience Report) — the source of field data collected from real Chrome users.
- Lighthouse / Chrome DevTools — lab-environment diagnostic tools used for performance checks and regression detection during development. Because lab runs have no interaction, they use TBT (Total Blocking Time) as a proxy in place of INP.
Key Optimization Areas
The core improvements drawn from web.dev's LCP optimization guide are as follows.
- Reduce server response time (TTFB) — cut unnecessary redirects and deliver the initial HTML as quickly as possible.
- Remove render-blocking resources — eliminate unused CSS, defer non-critical styles, and avoid synchronous scripts in the
<head>. - Optimize images — use modern formats like WebP and AVIF along with responsive images, and compress them. Apply
fetchpriority="high"to the LCP image and do not useloading="lazy"on it. - Preload resources — apply
<link rel="preload">to critical resources and ensure the LCP element is discoverable in the initial HTML. - CDN and caching — serve resources from locations close to the user and reduce network requests on repeat visits with a
cache-controlpolicy.
<!-- Prioritizing the LCP image -->
<img src="hero.avif" fetchpriority="high" alt="Hero image">
<!-- Preloading a critical resource -->
<link rel="preload" href="hero.avif" as="image" fetchpriority="high">
Rationale
Google Search Central documentation recommends achieving good Core Web Vitals for search success, since they align with what core ranking systems aim to reward. It also specifies the good thresholds of LCP 2.5 seconds, INP 200ms, and CLS 0.1, along with the 75th-percentile assessment method (sources: Google Search Central, web.dev). The specific techniques for LCP optimization are grounded in web.dev's LCP optimization guide.
Action Checklist
- Check the current field data for LCP, INP, and CLS using PageSpeed Insights and the Search Console report.
- Evaluate mobile and desktop separately to confirm whether each passes at the 75th percentile.
- Reduce server response time (TTFB) and remove unnecessary redirects.
- Eliminate unused CSS and JS and defer non-critical scripts.
- Apply modern formats, compression, and
fetchpriority="high"to the LCP image, and disable lazy loading on it. - Preload critical resources and configure CDN and browser caching.
- Specify dimensions for images, ads, and embeds to reduce CLS.
- After deployment, check for regressions with Lighthouse and reconfirm real improvement with field data.