TTFB and Compression Checker

To measure how fast a server starts answering, paste a URL into the free TTFB and Compression Checker above. It requests each page three times from our server and reports time to first byte (TTFB) with the DNS, connection and TLS times inside it, then checks whether the HTML is compressed with Brotli or gzip and how many bytes that saves. You can test up to 10 URLs at once and compare them side by side.

Last updated: 6 November 2026. Written by Saad Raza.

Key takeaways

• Time to first byte is how long a browser waits before the first byte of the page arrives. web.dev treats 800 ms or less as good and more than 1,800 ms as poor.
• A slow TTFB delays everything after it, including Largest Contentful Paint, so it is often the first thing to fix on a slow site.
• If most of the wait comes after the connection is ready, the server is slow to build the page and full-page caching helps most. If most of it is the connection, a CDN helps most.
• HTML should always be compressed. Brotli is usually a little smaller than gzip, and both typically cut HTML by 60 to 80 percent.

What TTFB measures

When a browser requests a page, several things happen before any content arrives. It looks up the domain (DNS), opens a connection (TCP), agrees encryption (TLS), sends the request, and waits while the server builds the response. Time to first byte covers all of that, up to the moment the first byte comes back. It is not one of the Core Web Vitals, but it sits underneath them: a page cannot paint until its HTML arrives.

The checker shows each step as a cumulative time from the start of the request, the way browser developer tools do. If DNS finishes at 0 ms, the connection at 29 ms, TLS at 61 ms and the first byte at 95 ms, then the server spent about 34 ms building and sending the start of the page. That split tells you where to look. My plain-English guide to website speed explains the same steps without the jargon.

How to use the TTFB and Compression Checker

1. Paste one URL, or up to 10 with one per line. Test your home page, a key service page and a blog post, because they are often cached differently.
2. Tick Test as a mobile browser if your site serves different HTML to phones.
3. Run the test. Each URL is requested three times: once accepting Brotli, once accepting only gzip, and once asking for no compression.
4. Read the median TTFB, the breakdown, the encoding and the bytes saved. The verdicts underneath explain each result.
5. Run it again a minute later. If the first TTFB was high and the second is low, the first request hit a cold cache.

What each number means

The checker also flags redirects in front of the page (their time is shown separately), a missing Vary: Accept-Encoding header on compressed responses, and servers that compress for Brotli but send uncompressed HTML to clients that only accept gzip.

A worked example with real sites

These results came from the tool on 6 November 2026.

• example.com: TTFB 95, 97 and 98 ms, so a median of 97 ms. The connection was open at 29 ms and TLS done at 61 ms, so the server itself took only about 34 ms to start answering. The 577-byte page was sent with Brotli as 334 bytes (42 percent smaller; gzip would send 400). Cloudflare reported a cache HIT. The one warning was a missing Vary: Accept-Encoding header.
• github.com: TTFB 269, 193 and 187 ms, a median of 193 ms. The page is 515.9 KB of HTML and was sent with gzip as 90.6 KB, 82 percent smaller. Brotli was offered but not used, so the checker notes that Brotli could shave a little more.

A slow site looks different. A page with a TTFB of 2,050 ms, where TLS finished at 260 ms, spent about 1,790 ms waiting for the server, and the checker says so: most of the wait is the server building the page, so full-page caching is the fix. If that page is also sent uncompressed, both problems are listed.

How to improve a slow TTFB

• Cache whole pages. On WordPress, a page cache such as LiteSpeed Cache or a host-level cache serves ready-made HTML instead of running PHP and database queries for every visit.
• Use a CDN. A content delivery network answers from a location near the visitor, which cuts DNS, connection and TLS time, and can cache HTML too. My guide to hosting, caching and CDNs compares the options.
• Remove redirects in front of pages. Each redirect is a full extra round trip. Link to final URLs and check them with the redirect checker.
• Look at the server. Slow database queries, heavy plugins and undersized hosting show up as a long wait after the connection is ready.

How to turn on compression

Most hosts and every major CDN can compress HTML, CSS and JavaScript with a single setting. On Apache and LiteSpeed, mod_deflate or the LiteSpeed cache plugin handles gzip, and Brotli is available on LiteSpeed and through Cloudflare. On Nginx, enable gzip on; and add the Brotli module if you can. My article on gzip and Brotli compression gives the exact settings and how to confirm them. While you are in the headers, check Cache-Control too, and look at the full response with the HTTP header checker.

Limits of a single-location test

This checker measures from our server, in one location, at one moment. Your visitors in other countries will see different numbers, and a busy hour will be slower than a quiet one. For what real users experience, use field data from the Chrome UX Report in the PageSpeed checker. The three requests may reuse a connection, which can show DNS and connect as 0 ms. Only the HTML document is measured, not images, scripts or fonts; the page size checker covers the page weight. Up to 10 URLs are tested per run, and each counts as three checks towards the fair-use limit.

Questions about the TTFB and Compression Checker

If your site is slow and you want it fixed properly, my website speed optimisation service covers hosting, caching and Core Web Vitals, and you can ask for a free audit. You can also browse the other free image and speed tools.