Skip to content

How to reduce Time to First Byte (TTFB)

Speed1 min readFixes 2 checks ttfb, crux-ttfb

TTFB is how long the server takes to start answering. Every other metric waits for it. Under 800 ms is fine; page caching and a CDN usually cut it in half.

Step by step, with screenshots: CDN basics: what a CDN fixes and what it does not →

Check your own site

Runs these 2 checks and the other 185, free, in about 45 seconds.

What a passing site looks like

  • Time to First Byte: passesfail · −5 ptseffort M
  • Real-user Time to First Byte: passesinfo onlyeffort M

1. Time to First Byte

Why it matters. TTFB is how long the server takes to start answering. Everything else waits for it, so a slow first byte makes every other metric worse. Google's 800 ms target is for real visitors, network included; Lighthouse flags the server's own share above 600 ms (see server response time).

How to fix it.
  1. Add page caching (WordPress: WP Rocket, LiteSpeed Cache, or your host's cache; Shopify does this for you).
  2. Put a CDN in front (Cloudflare, Bunny) so the first byte comes from a nearby edge.
  3. Check database-heavy plugins and slow hosting; a plan with more CPU often fixes this outright.

2. Real-user Time to First Byte

Why it matters. How long real visitors wait for the server's first byte, including their network. Google's threshold for "good" is 800 ms.

How to fix it.
  1. Cache pages and use a CDN close to your visitors; see the TTFB finding above.

Filed under Speed & Core Web Vitals. Copy is generated from the same catalogue that scores every report, so what you read here is what the report says.