While I was trying to assess HTTP latency around the world for a small project I’ve yet to talk about, I grew frustrated by the limits of the online tool I was using:
- It was slow because it collects results from all tested locations before starting to show them to the client (with a slow animation, on top of that)
- It didn’t work very well: a third of my tests were failing for no known reason
- It had quotas per 12h period, preventing me to do all the experiments I needed
That was enough to prompt me to start rebuilding the tool my way. As luck would have it, I was at the same time playing with Cloudflare Workers, which I only had been watching from afar until then. This little project would be a good way to explore Workers further.
A few hours, a bit of JS, and a drop of Bootstrap later, here’s TTFB Tester, free for all to use 🎉
Of course, when the CDN’s cache isn’t warm, it’s not particularly pretty. Another example:
Tech-wise, until I expand on the architecture, here are a few remedies to the problems I had with the other tool:
- Slowness: Rather than a lengthy HTTP call waiting for results from all locations, every test run opens a WebSocket connection to the orchestrator Cloudflare Worker. This Worker then launches tests concurrently from the 28 datacenter locations and gradually sends results to the client through the WebSocket, as soon as they arrive.
- Reliability issues: It’s hard to pinpoint why tests failed on the other tool. Mine seems to work more reliably in general, maybe because each location is independent: if one fails to run the test1, it doesn’t affect the others, its line just disappears from the results table.
- Quotas: Of course, when you’re the one in charge of limits, things get a lot easier on this part. They are less restrictive here, mainly because the serverless architecture I’m using entails a virtually null cost as long as usage stays at the level I’m predicting.
If a picture is worth a thousand words, a trial is probably ten times more… Why don’t you take the tester for a spin yourself? Or use it for real needs, for that matter: that’s what it’s here for!
-
It happens (very) often for a few locations because of the way the tests are run at this time. Those locations still stay in the pool because the nature of the tool means that their results are still good to take, even if they’re sporadic: here, I’m looking for comprehensiveness more than reliability of individual locations. It’s also a trade-off I’m willing to make for now, in exchange for the tool costing virtually nothing to run. This indeed happened between the two screenshots above, as Toronto left and Madrid appeared. ↩︎