What Is TTFB and How to Reduce Server Response Time
Practice4 minInnovialabs editorial team
In short
TTFB is the time from a request to the first byte of the response; it delays everything else, including LCP, and slows crawling. Reduce it with caching, a CDN, static generation, database query optimisation and hosting close to your users.
What TTFB is
TTFB (Time to First Byte) is the time from the start of a request until the first byte of the response arrives. It includes:
- redirects, if any;
- DNS lookup, TCP connection and TLS handshake;
- server-side processing: code, database queries, HTML rendering;
- the first byte's trip back to the browser.
Until the HTML arrives, the browser cannot start loading CSS, fonts or images. That makes TTFB the foundation of page speed. The web.dev guidance is to aim for a TTFB of 0.8 seconds or less for most visits.
How TTFB affects LCP and crawling
- LCP (rendering of the largest element) cannot happen before the HTML arrives. If the server is slow, a good LCP is very hard to achieve no matter how well you optimise images.
- Crawling. Search bots limit how hard they load a site. When the server responds slowly, the bot gets through fewer pages. On large sites this means new pages take longer to reach the index.
How to measure TTFB from different regions
TTFB depends heavily on distance to the server, so one check from the office is not enough.
| Tool | What it shows |
|---|---|
| Chrome DevTools → Network → Timing | "Waiting for server response" for a specific request |
| PageSpeed Insights | Field data from real Chrome users when there is enough traffic |
| WebPageTest | A test from a chosen city and browser, broken down by phase |
| Search Console → Crawl stats | Average server response time for Googlebot |
| curl | A quick check from any machine with a terminal |
curl -o /dev/null -s -w "dns %{time_namelookup} tls %{time_appconnect} ttfb %{time_starttransfer}\n" https://example.com/
Test from where your users are: Tashkent, Almaty, Moscow — and separately from Europe or the US if your server or part of your audience is there. Compare a cold request (empty cache) with a warm one.
How to reduce server response time
1. Caching
- Full-page caching on the server or in a reverse proxy (Nginx, Varnish) — the strongest lever for pages that are the same for everyone.
- Object caching (Redis, Memcached) for heavy computations and frequent queries.
Cache-Controlheaders withs-maxageandstale-while-revalidate, so the CDN serves cache and refreshes it in the background.
2. CDN
A CDN serves the response from the node closest to the user. Cache not only static assets but also HTML wherever possible. Check that your CDN has points of presence near your audience.
3. Database optimisation
- Turn on the slow query log and read execution plans (
EXPLAIN). - Add indexes for frequent
WHEREandJOINconditions. - Remove N+1 queries, where a list triggers a separate query per item.
- Use connection pooling instead of opening a connection per request.
4. Static generation
Pages that rarely change (blog, services, product pages) are better generated in advance — SSG or incremental regeneration. The server then returns ready HTML instead of rendering on every request.
5. Hosting close to users
Physical distance adds latency to every step of the connection. If your audience is in Uzbekistan and the CIS, a server in Tashkent or a neighbouring region usually responds faster than one in North America. Also consider personal data localisation requirements if the site stores such data.
6. Small but noticeable things
- Remove extra redirects (http → https → www → trailing slash).
- Enable HTTP/2 or HTTP/3 and modern TLS.
- Avoid blocking calls to external APIs during rendering.
Common mistakes
- Measuring only from a local machine next to the server.
- Optimising images when the main delay is on the server.
- Adding a CDN but not caching HTML.
- Purging the entire cache on every change in the admin panel.