Reduce Server Response Times (TTFB): How to Fix It

What TTFB is

Time to First Byte measures how long it takes from the moment a browser requests your page to the moment it receives the very first byte of the response. It is not a single step. TTFB bundles together the connection setup (DNS lookup, the TCP handshake, and TLS negotiation), any redirects, and the time your server spends building the response. So TTFB is always a little longer than raw server response time alone. Lighthouse measures the server-side slice as a separate "Reduce server response times" audit and fails it when the browser waits more than 600 ms for the main document, while the broader TTFB metric carries the well-known 0.8 second target.

Why it matters

TTFB happens before any pixel can be painted. The browser cannot start parsing HTML, fetching CSS, or loading images until that first byte arrives, so every millisecond of server delay is added directly on top of First Contentful Paint and Largest Contentful Paint. A slow server raises the floor for every downstream metric, which makes it one of the highest-leverage things to fix. TTFB is not itself a Core Web Vitals metric, but a slow server makes the metrics that do count much harder to pass. As a rough guide, aim for a TTFB of about 0.8 seconds or less; values much higher than that signal an origin that needs attention.

How it gets flagged

Lighthouse and PageSpeed Insights raise the lab-data audit "Reduce server response times" with your measured value. PageSpeed Insights also shows field TTFB from the Chrome User Experience Report (CrUX), which reflects what real visitors experienced over the trailing 28 days, and Sitebulb-style crawlers report the same server timing. The lab number is one synthetic run while the CrUX field number is the real-world picture, so the two can disagree. For more, see our guide to field versus lab data.

How to fix it

Cache the page

The fastest server response is one that skips work entirely. Full-page caching serves a pre-built copy instead of regenerating the page on every request. Set appropriate Cache-Control headers so HTML and static assets can be reused, and on dynamic stacks add object caching with Redis or Memcached plus a PHP opcode cache (OPcache).

Put a CDN in front of your origin

A content delivery network caches your content on edge servers physically closer to each visitor, cutting the network distance that inflates TTFB. With the right cache headers, the CDN can answer many requests without ever touching your origin.

Use faster hosting and server software

Cheap shared hosting is a common cause of slow first bytes. A better-provisioned plan, a modern PHP version, and a host near your audience often deliver the single biggest improvement. An overloaded server that is out of CPU or memory will respond slowly no matter what else you tune.

Optimize the backend and database

When pages are generated dynamically, slow database queries and heavy application code dominate response time. Profile slow queries, add indexes, trim plugins or modules that run on every request, and cache expensive query results.

Reduce redirects

Every redirect adds a full round trip before the real page can respond, and that time counts toward TTFB. Eliminate redirect chains, link directly to final URLs, and avoid bouncing visitors through http to https to www in separate hops. While checking, confirm the origin is not returning 5xx server errors under load, which point to a struggling backend.

Keep connections alive

Reusing an established connection avoids repeating the DNS, TCP, and TLS setup on every request. Enable HTTP keep-alive, serve over HTTP/2 or HTTP/3, and use preconnect hints for critical third-party origins.

False positives

A single slow lab run does not always mean a real problem. Lab TTFB is one synthetic measurement and can spike from a cold cache, a distant testing location, or a momentarily busy machine. If your CrUX field data shows real users getting fast first bytes, trust the field number over a one-off lab spike. The first request after a cache purge will also look slow while later ones are fast. Test a few times and judge by what real visitors experience.

FAQ