Measuring TTFB from 5 European locations: free tools and how to read the numbers

TTFB (Time To First Byte) is the time that passes from the browser's HTTP request to receipt of the first response byte from the server. According to Wikipedia's technical entry, it measures the duration from when the client makes an HTTP request to the first byte of the page received by the browser, and includes socket connection time, transmission time and the time to obtain the first byte of the page. It's not an abstract figure: if it's high, every other optimisation (images, CSS, JavaScript) starts late.

Testing from a single point, your office, tells you little. You need to test from multiple locations to understand where the site is slow and whether the cause is the origin server or the network. Here are three verified free tools, what they actually measure and how to read them.

KeyCDN Performance Test

The tool, available at tools.keycdn.com/performance, is a performance test on a single asset executable from 10 different locations worldwide, allowing you to test and measure the performance of any URL, returning a breakdown of load times and HTTP response headers. It requires no registration. It returns four distinct timings: DNS (domain name lookup time), Connect (connection time to the server), TLS (TLS connection overhead on the single asset) and TTFB (time from HTTP request to first data byte received). Point it at a single file, the home page HTML or a static image, not the entire page: it's a single asset test, not a full page speed test.

SpeedVitals and PageVitals: 40 locations, better European coverage

For a broader picture, SpeedVitals (speedvitals.com/ttfb-test) and PageVitals (pagevitals.com/free-tools/ttfb-tester) both measure TTFB from 40 different locations, free and without needing an account for a single test. PageVitals explicitly states: free and without registration required.

Among PageVitals' European locations are London and Paris, as well as Milan and Turin, alongside Frankfurt, Amsterdam, Berlin, Zurich, Brussels, Madrid, Warsaw and Helsinki: useful coverage for those with audiences in multiple EU countries.

Both tools also indicate performance thresholds. SpeedVitals classifies TTFB below 200 ms as "excellent" and above 700 ms as "poor"; PageVitals is stricter, placing excellence below 100 ms, defining complete global coverage at 40 locations and a methodology designed for accurate results, with "poor" threshold above 500 ms. Absolute numbers vary from tool to tool: what matters is the comparison between locations on the same test, not comparing a number read on one tool against one read on another.

How to read the difference between nearby and distant locations

The practical reasoning: if the server is in Milan, a test from Milan or Frankfurt will give low TTFB; a test from a more distant location (for example in Asia or the United States) will give higher TTFB only because of physical distance and network latency, not a server problem. This is expected behaviour, not a fault.

The problem becomes real when TTFB remains high even from European locations close to the server. In that case the cause is almost always not the network but the origin server: slow database queries, missing cache, unoptimised PHP, undersized hosting. Conversely, if the site uses a CDN and TTFB remains high precisely from locations furthest from the origin server but close to the CDN's edge nodes, suspicion shifts to the CDN: it may be that resource is not cacheable, or that the edge node being queried is doing a "pull" on every request to the origin instead of serving from cache.

Minimum procedure to repeat

1. Choose a fixed asset to test every time: the home page HTML or a static file such as an image or CSS.
2. Run the test on KeyCDN (10 locations) or SpeedVitals/PageVitals (40 locations, better European coverage) and note the DNS, Connect, TLS and TTFB times for each location.
3. Repeat the test two or three times: if you use a CDN, the first pass might find the cache cold and give a falsely high TTFB. SpeedVitals itself recommends repeating the test a couple of times to get accurate results, ensuring the resource is cached and served from the CDN provider's nearest datacenter.
4. Compare locations close to the server with distant ones: if the gap is large even between nearby locations, the problem is the origin; if the gap disappears with CDN active but remains on non-cacheable assets, the problem is cache configuration.

None of these tools replaces continuous monitoring, but for a one-off check, before and after a hosting change or CDN activation, they're sufficient and free.