Glossary Term

TTFB

Time To First Byte: how long the browser waits between requesting a page and the first byte arriving.

Definition

TTFB (Time To First Byte) is the time between a browser sending a request and the first byte of the response arriving back. It is the headline server-side performance metric in web hosting, because it captures everything before any HTML even starts to download: DNS lookup, TLS handshake, network round-trip, server processing, database queries and any backend logic. A good TTFB is under 200ms for cached pages and under 500ms for dynamic ones; over 800ms is a warning sign that the server, the application or the network is too slow. TTFB feeds directly into Core Web Vitals (especially LCP) and is what Google measures when it talks about 'slow servers'. It is measured per request using the Navigation Timing API, and reported by Chrome DevTools, WebPageTest and the web-vitals JS library. It matters most for dynamic, uncached pages; static assets served from a CDN edge can show a low TTFB regardless of origin distance, so the metric mainly exposes origin and application slowness rather than network transport.

How it works

TTFB is measured per request, from the moment the browser sends the request packet to the moment the first response byte arrives. It is reported by Chrome DevTools, WebPageTest, and the Web Vitals JS library, and it is one of the most actionable metrics a host can move.

Why it matters

High TTFB feels like a slow site even when the page eventually loads quickly, because nothing visible can happen until the first byte arrives. Lowering it is one of the highest-impact performance wins: pick a host closer to your audience, add a CDN, cache database queries, or precompute the response.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Frequently Asked Questions

What is a good TTFB?

Under 200ms for cached pages and under 500ms for dynamic ones. Over 800ms means the server, app or network is too slow for the visitor.

How do I improve TTFB?

Host closer to your audience, add a CDN, cache database queries, precompute responses with ISR or static generation, and use HTTP/2 or HTTP/3.

How do I check my site's TTFB?

Open Chrome DevTools, go to the Network tab, reload the page and look at the Timing breakdown for the main document: TTFB is the 'Waiting for server response' figure. WebPageTest and the web-vitals JS library give the same figure across multiple runs, which matters because a single request can be misleading.

Does adding a CDN always fix high TTFB?

No. A CDN speeds up static or cached content served from its edge, but if the origin server is slow to generate dynamic responses, the first request (or any cache miss) still has to hit that origin, so TTFB stays high until the backend itself is fixed.

What commonly causes sudden TTFB spikes on otherwise fast hosting?

Unoptimised database queries, plugin bloat (common on WordPress), cold starts on serverless functions, DNS or SSL renegotiation issues, and shared hosting neighbours consuming CPU. Check server logs and APM tools first; a spike that appears only under load usually points to database or application code, not the network.