Server response time (TTFB)
Time to First Byte (TTFB) is how long it takes from requesting a page until the first byte of the HTML response arrives. It covers everything that happens before the browser can start building the page: connecting to the server, the server generating the HTML, and the response travelling back.
Nothing on the page can render before the HTML arrives, so TTFB sets a floor under First Contentful Paint and Largest Contentful Paint.
Why it matters
Every millisecond the server spends thinking is a millisecond the visitor stares at a blank tab. A slow TTFB usually means pages are generated from scratch on every request: database queries, templates, API calls. That also makes the site fragile under traffic spikes.
TTFB is not part of the Lighthouse performance score directly, but because it delays everything that follows, a slow server makes a good score hard to reach.
What we check
We use the server response time Lighthouse measures for the main HTML document in the PageSpeed Insights mobile run:
| Result | Server response time |
|---|---|
| Good | 800 ms or less |
| Needs attention | over 800 ms, up to 1,800 ms |
| Poor | over 1,800 ms |
Keep in mind:
- The measurement comes from the test location, not from your visitors. A site hosted far from the test server, without a CDN, will show a higher value.
- It is a single request. Shared hosting, cold caches and serverless cold starts can make one request much slower than average. Scan again before drawing conclusions from a single bad value.
- Different tools draw the start and end points slightly differently, so their TTFB numbers do not always match exactly.
How to fix
Cache the HTML. The biggest gain usually comes from not generating the same page over and over. Options, from simplest to most involved:
- A full-page cache in your CMS or framework (for WordPress, a page caching plugin).
- A reverse proxy cache such as Nginx
proxy_cacheor Varnish in front of the application. - Caching HTML at a CDN edge, so most visitors never reach your server.
For pages that are the same for every visitor, tell shared caches they may keep a copy:
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60
s-maxage applies to shared caches such as CDNs; stale-while-revalidate lets the cache serve a
slightly old copy while it fetches a fresh one in the background. Never cache personalized pages
(logged-in views, carts) this way.
Use a CDN. Even without HTML caching, a CDN terminates the connection close to the visitor, which cuts the round trips for the connection and TLS setup.
Find the slow part of the backend. Measure where request time goes: slow or missing-index
database queries, calls to external APIs during page generation, and heavy template rendering are
the usual suspects. Many frameworks and APM tools can show a per-request breakdown. The
Server-Timing response header is a standard way to expose those timings in browser DevTools:
Server-Timing: db;dur=120, render;dur=45
Avoid redirects on the entry URL. Each redirect adds a full request before the real page even starts. See the redirect chains guide.
Check your hosting. Overloaded shared hosting, too few application workers, or a server located on another continent from most of your visitors can all keep TTFB high no matter how well the code is written. Enable HTTP/2 or HTTP/3 and keep the TLS configuration modern.
Reduce cold starts. On serverless platforms, rarely used functions can take much longer on their first request. Keep frequently visited pages cached at the edge so a cold start does not sit on the critical path.