Speed up slow server responses and heavy pages
Reduce time to first byte with caching and better hosting, slim down oversized HTML, and measure real performance properly.
The problem
Some pages take a long time before the server sends the first byte, or the HTML document itself is very large.
How to spot it
- A blank screen before anything appears.
- The audit lists slow time-to-first-byte measurements or large HTML sizes.
Why it matters
Nothing can render until the server responds. A slow first byte delays every other step of loading, and large HTML is slow to download and process on mobile networks.
What happens if you leave it
More visitors leave before the page loads. Note that our measurement is a single request from our server; your visitors' experience varies by location and device.
How to fix it
- Enable page caching so most visitors get a pre-built page instead of the server rebuilding it each time (a caching plugin, server cache or CDN cache).
- Use a CDN to serve pages and assets from locations near your visitors.
- Find slow work on the server: slow database queries, external API calls during page load, and heavy plugins. Remove or optimise them.
- Upgrade hosting if the server is overloaded.
- Reduce HTML size: remove large inline JSON or scripts, inline SVG sprites repeated on every page, and markup that is hidden and never shown.
- Measure properly: use field data (real-user metrics such as Core Web Vitals in Search Console) and lab tools (PageSpeed Insights or Lighthouse) for LCP, CLS and INP, which our audit does not measure yet.
Common mistakes
- Optimising images while the server takes two seconds to respond.
- Caching pages that show personal data, such as carts or account pages.
How to check the fix worked
Measure TTFB from several locations, then run PageSpeed Insights on key pages before and after. Re-run the audit and compare response times.
References and further reading
Related tutorials
Serve everything over HTTPS and fix mixed content
Redirect all HTTP traffic to HTTPS with a permanent redirect, and make sure HTTPS pages do not load any http:/...
Add basic HTTP security headers
Strict-Transport-Security, X-Content-Type-Options and a frame policy protect visitors from common attacks with...