TTFB Checker: What Time to First Byte Tells You About Speed

Visitors judge a page's speed from the moment they click, and the first thing that happens after the click is a wait: the browser asks for the page, and nothing visible happens until the first byte of the response arrives. That wait is time to first byte, or TTFB, and it sets the floor for every other speed measurement. A page cannot paint content, load images, or become interactive before its first byte arrives, so a slow TTFB delays everything that follows, no matter how well the rest of the page is optimised. Understanding TTFB is therefore the first step in understanding page speed, not an advanced detail.

The TTFB Checker reviews a pasted timing summary, such as values from a browser's developer tools or a performance report, and interprets the TTFB figure: whether it is fast, acceptable or slow, and which component — server processing, network round trips, or redirects — most likely dominates it. It works from timing values you paste in; it does not fetch pages or require credentials, and you should never paste secrets or private data into it. Timing figures are performance data, not sensitive data, and that is all the tool needs.

TTFB is composed of several parts, and naming them helps diagnosis. First, the browser resolves the domain name, which takes time if DNS is slow. Then it connects to the server, which takes at least one network round trip, more if the connection uses TLS, as secure connections do. Then the server processes the request: running code, querying a database, rendering a page. Finally, the first byte travels back across the network. A slow TTFB can come from any of these stages, and the fix depends entirely on which one dominates, which is why a single TTFB number without its breakdown is a symptom, not a diagnosis.

What counts as fast, acceptable or slow

As a rough guide, a TTFB under 200 milliseconds is fast, 200 to 600 milliseconds is acceptable for most pages, and above 600 milliseconds deserves investigation, with values over a second usually indicating a real problem. These bands are guides, not guarantees: a page served to visitors on the other side of the world will naturally show higher network time than the same page served locally, and a page that personalises heavily or queries a database will naturally take longer to generate than a static page. Compare a page with itself over time, and with similar pages on the same infrastructure, before comparing it with unrelated sites.

Also distinguish TTFB from full load time. A page can have a fast TTFB and still feel slow if it then loads many large images or scripts, and a page can have a slow TTFB but feel acceptable if the first content paints quickly afterwards. TTFB matters because it delays the start of everything, but it is one metric among several. Judge speed by the visitor's experience — when content appears and becomes usable — and use TTFB to locate the server-side and network-side share of that experience. A fixation on TTFB alone can lead to optimising the wrong thing, such as shaving milliseconds from a server that is already fast while ignoring megabytes of images.

Measurement conditions matter enormously. TTFB measured from a server next door to your hosting will look far better than TTFB experienced by a visitor across an ocean. Measure from locations close to your real visitors, on connection types they actually use, and repeat measurements rather than trusting a single reading, because network conditions vary minute to minute. A single slow reading is a hint; a pattern of slow readings at the same time of day, or from the same region, is evidence. Record the measurement location, connection type and time alongside the figure, or the figure is hard to interpret later.

Worked example: a blog page with an 800-millisecond TTFB

Suppose a blog page shows a TTFB of 800 milliseconds, measured from a location near its main audience. The timing breakdown shows: DNS 20 milliseconds, connection and TLS 120 milliseconds, and server waiting time 640 milliseconds, with the remainder in transfer. The breakdown points clearly at the server: the network stages are healthy, but the server takes over six-tenths of a second to generate the page. The blog's owner investigates and finds that the page runs several database queries per article listing, including one unindexed query that scans a large table, and that no page caching is enabled for anonymous visitors.

The fixes follow the diagnosis. The unindexed query gains an index, the listing is simplified to avoid a redundant query, and page caching is enabled for anonymous visitors, so repeat visits are served from cache without regenerating the page. A repeat measurement shows TTFB at 180 milliseconds for cached visits and 350 milliseconds for uncached ones: both far better than before, and the remaining uncached time reflects genuine page generation rather than a fixable bottleneck. The owner also notes that the fix helped the slowest visitors most, because server time affects every visitor while network optimisations help only distant ones. That ordering — server first when server time dominates — is the general rule: fix the largest component first.

If the breakdown had instead shown connection time dominating, the fixes would have differed entirely: a content delivery network to serve visitors from nearer locations, faster DNS, or fewer redirects. If DNS had dominated, the fix would have been a faster DNS provider. The same 800-millisecond headline would have led to three different projects, which is why the breakdown, not the headline, drives the work.

Common causes and fixes, by component

Slow server processing is the most common cause of slow TTFB on dynamic sites. Causes include unindexed database queries, excessive queries per page, slow external API calls during page generation, uncached pages, and underpowered hosting. Fixes include indexing, query reduction, caching, moving slow calls out of the page-generation path, and upgrading hosting where the server itself is the bottleneck. Profile before optimising: a guess about which query is slow is often wrong, while a profile shows the truth in minutes.

Network causes include distant hosting, slow DNS, many redirects, and TLS overhead on new connections. A content delivery network helps distant visitors by serving cached content from nearby locations, but it helps dynamic, uncacheable pages less, because those still reach the origin server. Redirects deserve a specific check: each redirect adds a full round trip before the real page even starts generating, so a chain of two or three redirects can add hundreds of milliseconds that no server tuning can remove. Shorten redirect chains so the first redirect points directly at the final destination.

Also watch for TTFB that varies wildly between measurements. Variable TTFB often points at a shared hosting neighbour consuming resources, a cache that is sometimes warm and sometimes cold, or a server that scales slowly under load. If TTFB is fast on repeat visits but slow on first visits, cold caches are the likely story, and warming the cache or extending its lifetime may help. If TTFB degrades at peak times, capacity is the story, and the fix is resources or efficiency, not configuration tweaks. The LCP Element Analyzer identifies which element dominates the largest paint after the first byte arrives, and the INP Interaction Profiler covers responsiveness once the page is interactive. For image-related slowness after a fast TTFB, see Slow Blog Post Images Page Speed Fix.

FAQs

Is a low TTFB enough for a fast page? No. TTFB measures only the wait before the first byte. Images, scripts, stylesheets and rendering all add time afterwards, so a fast TTFB with heavy assets still feels slow. Treat TTFB as the foundation, not the whole building.

Does a content delivery network always fix slow TTFB? It helps cached and static content served near visitors, but dynamic pages that must reach the origin server still depend on origin speed. A network helps most when network distance dominates; it helps least when server processing dominates.

How often should TTFB be checked? After hosting changes, after major code or database changes, and periodically — monthly is reasonable for most sites — so that gradual slowdowns are caught before visitors notice. Track the trend, not single readings.