TTFB Explained: What Time to First Byte Actually Measures

TTFB stands for Time to First Byte, and if you are reading this, a speed report probably just flagged yours in red. That is usually the moment people start searching for a plain answer to what is TTFB, because every tool that is supposed to explain it throws another acronym at you instead.

Here is the short version. TTFB measures how long your browser waited, after asking for a page, before the very first byte of the response came back. Not the whole page load, just the wait for that first byte to arrive. Everything else, painting text, loading images, running scripts, happens after this number is already locked in.

That is the TTFB meaning in one sentence. The rest of this article covers what is actually inside that wait, why your own site can show two different TTFB numbers depending on which tool you run, what counts as a good TTFB time, and what you can actually do about it if you are on ordinary shared hosting with no developer on staff.

What Is TTFB? The Plain-English Definition

Technically, TTFB is the time between when your browser starts navigating to a page and when it receives the first byte of the response. Google's own performance documentation defines it using the Navigation Timing API: responseStart minus startTime, both properties the browser records automatically for every page load, as described in MDN's Time to First Byte glossary entry. That is a single, cumulative number by default. It bundles together every delay that happens before content starts arriving.

Think of ordering food at a counter. You place your order, then wait. TTFB is the entire wait, from the moment you finish speaking to the moment the server hands you the first plate.

It does not care whether the wait was spent finding the kitchen, cooking, or walking the plate over. It just measures the total gap.

The five things happening before that first byte arrives

That single number is actually made up of several smaller steps, stacked one after another. Knowing them matters, because the fix for a slow DNS lookup is nothing like the fix for slow server processing.

• DNS lookup. Your browser translates the domain name into an IP address, usually by asking a DNS resolver somewhere between you and the site.
• TCP connect. Your browser and the server open a connection, a short back-and-forth handshake before either side sends real data.
• TLS handshake. If the site runs on HTTPS, which nearly all do now, there is an additional round trip to agree on encryption before anything else can move.
• Request sent. The browser transmits the actual request: the URL, headers, cookies, whatever the page needs to identify what it wants.
• Server processing. The server does its work, runs the code, queries the database, builds the page, and starts sending the response back.

On a slow shared hosting plan, that last step is usually where the time disappears. But you cannot know that from a single TTFB number alone. You need to see the phases separately, which is exactly where the confusion in the next section starts.

Why your TTFB number looks different in every tool

This is the part almost nobody explains, and it is the reason a site owner can run the same page through two tools and get two different TTFB figures within the same minute.

Google's PageSpeed Insights, Chrome User Experience Report, and the raw Navigation Timing API all report TTFB as one cumulative figure: redirect time plus DNS plus connection plus TLS plus server wait, all rolled into a single number, confirmed directly in web.dev's Time to First Byte documentation. Command-line tools built on curl work similarly under the hood. curl's own documentation for CURLINFO_STARTTRANSFER_TIME, the timing value most curl-based checkers use, states plainly that it "includes CURLINFO_PRETRANSFER_TIME and also the time the server needs to calculate the result," per curl.se's documentation. So it, too, starts as a cumulative number.

The difference shows up when a tool wants to isolate just the server's own wait, separate from the network overhead of getting connected in the first place. To do that, a checker has to subtract the earlier checkpoints, DNS lookup time, connect time, TLS time, from that cumulative figure. What is left is the server's own response wait, the part actually within a site owner's control.

This is what httpcheck.tools' own timing report does. It reports DNS, connect, TLS, TTFB and total as separate figures for each hop in a redirect chain, rather than folding everything into one blended number. If a chain has extra hops piling up delay before the server even gets a chance to respond, that shows up here too; the site's guide to redirect loops covers what to do when hops keep multiplying instead of resolving, and the status code reference explains what each hop's 301 or 302 means.

If you see a smaller TTFB there than you saw in PageSpeed Insights for the same page, that is not a bug or a discrepancy between two broken tools. It is two different, both-legitimate ways of slicing the same wait: one cumulative, one isolated to the server itself.

TTFB benchmarks: good, needs improvement, poor

Google publishes specific thresholds for the cumulative TTFB figure, measured at the 75th percentile of page loads for real users, according to web.dev's Core Web Vitals guidance.

These thresholds apply to the full Navigation Timing figure, not the isolated server-only wait some tools show. If you want to run a quick TTFB test and see both the total figure and the phase breakdown side by side, pasting the URL into httpcheck.tools gives you DNS, connect, TLS and server wait as separate rows, along with the total, so you can see exactly where the time actually goes instead of guessing.

What slows TTFB down

A handful of causes show up again and again in real audits, and they are worth checking in roughly this order.

• Server processing time. Slow application code, unoptimized database queries, or a content management system rebuilding a page from scratch on every request.
• No caching layer. Without a page cache or object cache, the server redoes the same expensive work for every single visitor.
• Resource contention on shared hosting. Your site sits on hardware shared with dozens or hundreds of other accounts, so a noisy neighbor can slow your response even when your own code is fine.
• Physical distance to the server. A visitor in Sydney hitting a server in Frankfurt pays a network latency tax before the server even starts working.
• Slow or misconfigured DNS. A sluggish DNS provider adds a lookup delay before the connection process has even begun.

Fixing slow TTFB on shared hosting

Nobody on a budget hosting plan wants to hear "just switch hosts" as the only answer, so here is a realistic order of operations before you reach for that.

1. Confirm you actually have a caching layer, and that it is working. If you run WordPress, check whether a caching plugin is active and actually serving cached pages, not just installed and idle. For what the response headers should actually say once caching is on, the site's Cache-Control header guide covers the values worth sending.
2. Audit plugins or add-ons one at a time. Deactivate them individually and re-test. A single poorly-coded plugin running on every page load is a common, checkable cause of slow server response on shared hosting, and it is one of the few fixes that costs nothing.
3. Check your DNS provider's response time. If you are still on the DNS that came bundled with your domain registrar, moving to a dedicated, faster DNS provider is a low-effort change.
4. Add an edge cache in front of the origin, even on cheap hosting. A CDN's cache can serve a stored copy of your page from a location near the visitor, sidestepping your origin server's processing time entirely for cached requests. If you need to write the actual caching rules for your server, htaccess.tools covers the Apache-side configuration for that.
5. Upgrade hosting only after the above. If your TTFB is still poor with caching enabled, plugins trimmed, and an edge cache in place, that is a genuine signal your hosting plan's resources, not your configuration, are the bottleneck.

TTFB and Core Web Vitals: where it actually matters

TTFB is not itself a Core Web Vital. It matters because nothing on the page can start painting before the first byte arrives, which makes TTFB the floor underneath Largest Contentful Paint, the Core Web Vital Google does score directly, a relationship Google's own web.dev guidance on optimizing TTFB describes in detail. A slow TTFB does not guarantee a bad LCP score, but it puts a hard ceiling on how fast LCP can possibly be.

Worth one honest caveat here. Cloudflare has published research showing that a technical change, enabling gzip compression, can actually increase raw TTFB while cutting total download time dramatically, because the server spends a fraction more time compressing before it spends much less time transferring, detailed in Cloudflare's engineering blog. TTFB is a useful diagnostic. It is not the only number that matters, and chasing it in isolation can occasionally push you toward the wrong fix.

How to check your TTFB right now

The fastest way to actually see your own numbers, instead of guessing from someone else's benchmark article, is to run a TTFB test directly. Paste your URL into httpcheck.tools and you will get the DNS, connect, TLS and server-wait timing broken out hop by hop, alongside the full HTTP header report, so you can see whether a redirect chain is adding delay before the server even gets a chance to respond. For a deeper look at what those headers mean once you have the timing sorted, the site's HTTP headers guide covers the rest of what a full report shows you.

Frequently Asked Questions

What is a good TTFB?

Google considers a cumulative TTFB of 0.8 seconds or less good, 0.8 to 1.8 seconds as needing improvement, and anything above 1.8 seconds as poor, measured at the 75th percentile of real page loads, per web.dev's published thresholds. Keep in mind this benchmark applies to the full cumulative figure, not an isolated server-only wait some phase-by-phase tools report separately.

What is included in time to first byte?

The default, cumulative TTFB figure includes DNS lookup time, TCP connection setup, the TLS handshake on HTTPS sites, the time to send the request, and the server's own processing time before it starts sending a response back. It is everything from the moment your browser starts the navigation to the moment the first byte of the response arrives, as defined by the Navigation Timing API's responseStart measurement.

Does TTFB affect SEO?

Not directly. Google has said TTFB itself is not used as a direct search ranking signal, according to reporting on statements from Google's John Mueller in Search Engine Roundtable. Its influence is indirect: a slow TTFB sets a hard floor under Largest Contentful Paint, which Google does score as a Core Web Vital, and it can also slow down how efficiently search crawlers get through your pages. Treat TTFB as a diagnostic worth fixing for user experience and crawl efficiency, not as a ranking lever on its own.

How do I reduce TTFB on shared hosting?

Start with the cheapest, highest-leverage fixes before assuming you need a hosting upgrade. Confirm your caching layer is actually active and serving cached pages, deactivate plugins or add-ons one at a time to find any that are dragging on every page load, check whether your DNS provider is adding unnecessary lookup delay, and put a CDN's edge cache in front of your site so cached requests never have to touch your origin server at all. Only upgrade hosting once those steps are in place and TTFB is still poor, since that is the point where the bottleneck is genuinely your server's resources rather than its configuration.