What Is Time to First Byte (TTFB) and How to Improve It

Before a browser can show a single pixel of your page, it has to ask your server for it and wait for a reply. Time to First Byte (TTFB) measures that wait — the gap between the request leaving the browser and the first byte of the response arriving. It is the quiet foundation beneath every loading metric: if the first byte is slow, everything after it is slow too. In short: TTFB is the time from request to first response byte, a good target is 800 milliseconds or less per web.dev, and you improve it with caching, a CDN, a faster backend and fewer redirects. This guide explains exactly what TTFB includes, what counts as good, how it feeds Largest Contentful Paint, how to measure it, and how to bring it down.

It is a deep-dive behind the server-response lever in how to make your website load faster.

What TTFB actually measures

TTFB sounds like a single number, but it is the sum of several sequential steps that all happen before your server's response begins to stream back. Understanding the parts is what makes the metric fixable, because each part has a different remedy.

When the browser requests a resource — usually the main HTML document — the following happens in order:

• Redirects. If the URL redirects (HTTP to HTTPS, a trailing-slash fix, a www-to-bare-domain rule), each hop is a full extra round trip before the real request even starts.
• DNS lookup. The browser translates your domain name into an IP address, which can require a network round trip if the answer is not already cached.
• Connection (TCP). The browser opens a connection to the server, a handshake that costs a round trip.
• TLS handshake. For HTTPS, the browser and server negotiate encryption, adding one or more further round trips.
• Server processing. The server runs your application code, queries databases, renders the page, and produces the response. On dynamic sites this is frequently the largest slice.

Only when that last step yields its first byte does the TTFB clock stop. Everything else the user experiences — first paint, the main content rendering, interactivity — is queued up behind it.

The components of TTFB at a glance

Component	What it is	Typical fix
Redirects	Extra round trips before the real request	Eliminate redirect chains; link to final URLs
DNS lookup	Resolving the domain to an IP	Fast DNS provider; reasonable TTLs; preconnect
Connection (TCP)	Opening the socket	CDN edge nearby; connection reuse; HTTP/2 and HTTP/3
TLS handshake	Negotiating HTTPS encryption	Modern TLS, session resumption, edge termination
Server processing	Generating the response	Caching, faster queries, better hosting

On a well-built static or cached site, the network phases (DNS, connect, TLS) dominate and server processing is near-instant. On a heavy dynamic site — an unoptimised content management system, a slow database, a cold serverless function — server processing can dwarf everything else. Measuring the breakdown tells you which world you are in.

What counts as a good TTFB

Google's web.dev guidance suggests that most sites should aim for a TTFB of 800 milliseconds or less. As a practical rating:

TTFB	Rating
≤ 800ms	Good
800ms - 1.8s	Needs improvement
> 1.8s	Poor

A couple of caveats matter. First, TTFB is highly sensitive to distance and connection — a visitor far from your origin will see a higher TTFB than one nearby, which is precisely why a CDN helps. Second, like the Core Web Vitals, it is best judged at the 75th percentile of real visits rather than from a single test on a fast connection, so that slower-network and slower-device users are represented. A great TTFB on your office fibre connection tells you little about a mobile user three time zones away.

How TTFB feeds Largest Contentful Paint

This is the reason TTFB matters even though it is not a Core Web Vital. Largest Contentful Paint (LCP) measures when the main content renders, and web.dev breaks LCP into four sub-parts — the first of which is Time to First Byte. In other words, the LCP clock effectively cannot stop until the first byte has arrived and the browser has begun building the page. If TTFB is 1.5 seconds, your LCP cannot possibly be under 2.5 seconds no matter how small and well-optimised your hero image is, because 1.5 of those seconds are already gone before the browser receives anything to render.

That makes TTFB a hard ceiling on loading performance. You can compress images, preload the hero, and inline critical CSS perfectly, but a sluggish backend will cap the result. This is why diagnosing a poor LCP often leads straight back to the server — see what is Largest Contentful Paint and how to improve it for how the sub-parts fit together. Fix TTFB first when it is the dominant slice, and the downstream metrics improve almost for free.

How to measure TTFB

A handful of free tools expose TTFB clearly, and using more than one is wise because lab and field values can differ.

1. Chrome DevTools - Network panel. Open DevTools, go to Network, reload, and click the main document request. The Timing tab breaks the wait into Queueing, DNS Lookup, Initial connection, SSL, and Waiting for server response — that last figure is your TTFB, and the phases above it show where the time went.
2. WebPageTest. Its waterfall colours each connection phase (DNS, connect, SSL) and shows TTFB explicitly on the first request, with the ability to test from many locations and connection speeds — invaluable for seeing the distance penalty a CDN would remove.
3. PageSpeed Insights. Reports TTFB in its field data (from the Chrome UX Report) so you see what real users experience, alongside the lab audit.
4. Lighthouse. The "Reduce initial server response time" audit flags a slow server response and estimates the potential saving, pointing you at TTFB directly.

The workflow mirrors all performance work: establish a baseline, find the dominant component, fix it, and re-measure in the field. For the broader testing context, see Core Web Vitals explained.

How to improve TTFB

Because TTFB is a chain of steps, the fixes map onto those steps. Tackle the largest contributor first.

Cache so pages are not rebuilt every time

The single most effective TTFB improvement on dynamic sites is caching. If your server regenerates the same HTML from scratch on every request — querying the database, rendering templates, assembling the page — server processing time piles up. Full-page caching stores the finished HTML so repeat requests are served instantly without rebuilding. Object and query caching stores expensive intermediate results so even uncached pages assemble faster. For content that rarely changes, serving a cached copy turns a multi-hundred-millisecond render into a near-instant response. This is the highest-leverage change for most slow backends.

Put a CDN in front

A CDN serves cacheable responses from an edge server physically close to the visitor, which collapses the network phases — shorter distance means faster DNS, connection and TLS, and a cached response never has to travel to your origin at all. For a geographically spread audience this is transformative, because it removes the distance penalty that inflates TTFB for far-away users. Many CDNs also terminate TLS at the edge and support HTTP/2 and HTTP/3, further trimming handshake overhead. A CDN is one of the biggest single levers in how to make your website load faster.

Speed up the backend and database

When server processing dominates, the work is in your application. Optimise database queries — add indexes, eliminate N+1 query patterns, and replace many small queries with fewer efficient ones. Reduce wasted computation in request handling, and profile slow endpoints to find the hot spots. On serverless platforms, cold starts can add significant latency to the first request, so keeping functions warm or choosing a runtime with fast cold starts helps. A leaner backend lowers the floor of what caching has to cover.

Remove unnecessary redirects

Every redirect is a full extra round trip before the real request begins. A chain like http://example.com to https://example.com to https://www.example.com can add two complete round trips to TTFB. Audit your redirects, collapse chains so there is at most one hop, and update internal links and canonical tags to point at the final URL so users and crawlers skip the redirect entirely.

Choose adequate hosting

Underpowered or heavily oversubscribed shared hosting is a common, hidden cause of slow responses: when the server is starved of CPU or memory, every request waits. If you have optimised code and caching and TTFB is still high under load, the hosting tier itself may be the limit. Moving to a better-provisioned plan or a platform that scales with traffic can resolve a TTFB problem that no amount of code tuning would.

A worked example

Suppose PageSpeed Insights shows a field TTFB of 1.6 seconds and an LCP of 3.9 seconds — both poor. The DevTools Timing breakdown reveals a small DNS and connection time but a large "Waiting for server response" of around 1.3 seconds, and the waterfall shows a redirect hop before the main request. Two changes follow directly. First, you enable full-page caching so the page is served pre-rendered instead of being rebuilt from the database on every hit, cutting server processing to tens of milliseconds. Second, you remove the redirect chain so the browser reaches the final URL in one request. TTFB drops under 800ms, and because the LCP clock now starts far sooner, LCP falls below 2.5 seconds without touching a single image. This is the typical shape of TTFB work: the server is usually the culprit, and caching is usually the cure.

When TTFB is not your problem

It is worth knowing when to stop. If your TTFB is already comfortably under 800ms but the page still feels slow, the bottleneck has moved downstream — to render-blocking CSS and JavaScript, an oversized hero image, or heavy client-side rendering. Chasing TTFB from 400ms to 300ms yields almost nothing a user can feel, so once it is good, redirect your effort to the front-end levers: trimming JavaScript, optimising images, and unblocking the critical path. TTFB is a foundation, not the whole house; a fast first byte is necessary for a fast page but not sufficient on its own.

Common mistakes

• Blaming the front end for a slow LCP when the real culprit is a high TTFB on the server.
• Leaving redirect chains in place, each adding a full round trip to every affected request.
• Testing TTFB only from one nearby location, hiding the distance penalty your far-away users suffer.
• Caching nothing on a dynamic site, so the server rebuilds identical pages on every request.
• Over-optimising an already-good TTFB instead of moving on to the bigger downstream wins.

Go deeper

• The big picture, in priority order: how to make your website load faster.
• The metric TTFB feeds: what is Largest Contentful Paint and how to improve it.
• The first paint it precedes: what is First Contentful Paint (FCP).
• The full set of metrics: Core Web Vitals explained.

Want your server response time measured alongside Core Web Vitals, SEO and security? Analyse any URL with StackOptic — free, no sign-up.