Page speed
How quickly a web page loads and becomes usable, measured by metrics like Largest Contentful Paint, Time to First Byte, and overall load time.
Also known as: page load speed, site speed, page performance
Page speed describes how quickly a web page loads and becomes usable for a visitor. It is influenced by many factors including server response time, file sizes, network conditions, the visitor’s device, and how the page is constructed. Page speed affects user experience, search rankings, and conversion rates.
There is no single “page speed” number; it is a set of related metrics measured at different points in the loading process.
Common page speed metrics
| Metric | What it measures |
|---|---|
| Time to First Byte (TTFB) | Time from request to the first byte of response from the server |
| First Contentful Paint (FCP) | Time until any text or image is visible |
| Largest Contentful Paint (LCP) | Time until the largest visible element renders |
| Speed Index | How quickly the visible page is filled in |
| Time to Interactive (TTI) | Time until the page reliably responds to input |
| Total Blocking Time (TBT) | Total time the main thread was blocked between FCP and TTI |
| Interaction to Next Paint (INP) | Time for the page to visually respond to user interaction |
| Cumulative Layout Shift (CLS) | How much the page shifts visually during load |
LCP, INP, and CLS together form Google’s Core Web Vitals.
Why page speed matters
- Search rankings. Google uses page speed signals (especially Core Web Vitals) as ranking factors
- Conversion. Slower pages lose more visitors before they take action; this effect is well-documented across industries
- Bounce rate. Visitors leave before pages finish loading, especially on mobile networks
- User satisfaction. Faster pages feel more responsive and trustworthy
- Cost and accessibility. Lighter pages are friendlier on metered or slower connections
Common factors that affect page speed
- Server response time. How quickly the host returns the initial HTML
- Distance to the user. Latency between server and visitor (mitigated by CDN)
- Page weight. Total bytes downloaded for the page (HTML, CSS, JS, images, fonts, video)
- Number of requests. Each separate file requires a network round-trip (mitigated by HTTP/2 and HTTP/3)
- Render-blocking resources. CSS and JavaScript in the page head can delay first paint
- Image optimization. Unoptimized or oversized images often dominate page weight
- Third-party scripts. Analytics, ads, embeds, chat widgets often add significant overhead
- JavaScript execution. Large bundles consume CPU on the visitor’s device
- Web fonts. Late-loading fonts cause layout shifts and visual instability
- Caching. Whether assets are cached at the browser, CDN, or proxy level
How to measure page speed
| Tool | What it does |
|---|---|
| PageSpeed Insights | Lab and field data for any URL |
| Chrome DevTools → Lighthouse | Local lab audit |
| Chrome DevTools → Performance | Detailed runtime profiling |
| WebPageTest | Detailed lab tests with location and device variation |
| GTmetrix | Lab tests with historical tracking |
| Google Search Console → Core Web Vitals | Real-user field data |
| Cloudflare Web Analytics, Vercel Speed Insights | Real-user monitoring (RUM) |
Lab tools provide diagnostics under controlled conditions; field data shows what real visitors actually experience.
Common optimization strategies
For most sites, page speed improvements come from a combination of:
- Compress and resize images. Use WebP or AVIF formats; serve responsive sizes
- Enable a CDN. Reduce latency for global visitors
- Defer non-critical JavaScript. Load scripts asynchronously where possible
- Inline critical CSS. Send the minimum CSS needed for first paint immediately
- Lazy-load below-the-fold content. Defer images and embeds until needed
- Preload key resources. Hint to the browser to fetch important assets early
- Reduce third-party scripts. Audit analytics, ads, chat widgets, and embeds
- Use efficient hosting. Server response time directly affects TTFB
- Reserve space for late-loading content. Specify image dimensions and reserve space for ads to prevent layout shift
- Cache aggressively. Use long cache lifetimes for static assets with versioned URLs
Page speed by site type
| Site type | Typical page speed characteristics |
|---|---|
| Static / code-based sites | Often fast by default; performance depends on developer choices |
| Self-hosted WordPress | Highly variable; depends on theme, plugins, hosting, and caching |
| Hosted CMS (Squarespace, Wix, Webflow) | Set largely by the platform; user has limited control over JavaScript and asset loading |
| Single-page applications | Variable; can be slow on first load, fast for in-app navigation |
Performance depends more on configuration and content than on category alone.
Common misconceptions
- “A high PageSpeed score means a fast site.” PageSpeed reports lab data; actual user experience depends on field data, which can differ.
- “Image compression alone will fix page speed.” Images are often the biggest single factor, but JavaScript, fonts, and third-party scripts also contribute substantially.
- “Faster servers always mean faster pages.” Server speed affects TTFB but cannot compensate for heavy front-end code.
- “Page speed only matters for mobile.” It affects all devices; mobile is more sensitive due to slower networks and CPUs.