How SpeedVitals' TTFB Test Works and What It Measures

SpeedVitals' TTFB test measures Time to First Byte from 40 locations with a single click, and adds cache status and CDN detection to each result. Use it when you need to know how fast your server starts responding to visitors around the world, or when you want to confirm whether a CDN and caching layer are actually doing their job. It is a server-response diagnostic, not a full page speed test — pair it with a standard speed test if you also care about rendering and Core Web Vitals.

What TTFB actually measures

Time to First Byte is the gap between a browser requesting a URL and the first byte of the response arriving. In practice it bundles several stages:

• DNS lookup for the hostname
• TCP connection setup, plus TLS negotiation on HTTPS
• The request travelling to the server
• Server-side processing (database queries, application logic, cache lookups)
• The first byte travelling back to the client

Because network round trips are included, the same server can produce very different TTFB numbers depending on where the test runs from. That is the reason a single-location measurement is rarely enough to judge global performance.

How the SpeedVitals TTFB test works

1. Enter the URL you want to test.
2. Run the test. SpeedVitals queries the URL from 40 locations in one pass rather than making you repeat the test location by location.
3. Read the results. Each location returns its own TTFB figure, so you see a spread rather than one average.
4. Check the accompanying signals. The tool reports cache status and performs CDN detection alongside the timing data.

The expected output is a per-location view of server response time plus an indication of whether responses are being served from cache and which CDN is in front of the origin. If TTFB is fast in one region and slow in another, the pattern usually points at distance from the origin or at a CDN that is not covering that region.

Why cache status and CDN detection matter together

TTFB alone tells you that something is slow, not why. Cache status and CDN detection narrow it down:

A cache miss forces the request back to the origin, which raises TTFB. A missing or misconfigured CDN means every visitor pays the full distance to your server. Seeing both signals next to the timing data is what makes the test useful for diagnosis rather than just measurement.

When to use the TTFB test instead of a full speed test

Reach for the TTFB test when:

• You have just changed hosting, a CDN configuration, or a caching plugin and want to confirm the server side improved.
• Users in a specific country report slow loading and you want to see whether their region's TTFB stands out.
• You are comparing two hosts or two CDN setups and want a server-response comparison without rendering noise.

Use the standard website speed test when your question is about the user experience as a whole — Core Web Vitals such as LCP, CLS, and TBT, plus resource-level reports like waterfalls and unused resources. The two answer different questions: TTFB is about how quickly the server starts talking; a full speed test is about how quickly the page finishes.

Practical notes and common sticking points

• Test the exact URL your visitors hit. A homepage and a product page can have very different TTFB if one is cached and the other is not.
• Treat a single slow location as a lead, not a verdict. Re-run before concluding there is a regional problem.
• Remember that TTFB is only one input into metrics like LCP. A fast TTFB with a slow-rendering page still produces a poor LCP.
• SpeedVitals also offers batch analysis of up to 50 speed tests in one click and multi-location batch tests across up to 35 locations, which is useful if you want to track TTFB across many URLs rather than one at a time.
• Pricing and plan limits are not covered in the material available here; check the site's pricing page if you need to know what the paid tiers include.