Measure a site from Dhaka or Miami, or all three at once: where the first byte goes, what the page weighs, and whether caching and compression are actually on.
A site hosted abroad looks fast from abroad. Measure from where your visitors are.
Free allowance today: 15 more checks across 5 more sites. Resets at midnight UTC. Every other tool here is unlimited and needs no account.
Most speed tools measure from wherever their own servers happen to be, and one number from one place is not enough. A site hosted in Singapore looks respectable from Frankfurt and costs a Dhaka visitor a round trip out of the country and back before a single byte arrives. So you choose: our BDIX-peered core network in Dhaka, our colocation site in Dhaka, or Miami. Every result says which one it came from, because a speed number without a place is not a measurement. Or choose All three and get every location in one run, side by side, for one charge against the daily allowance rather than three.
The difference is rarely small. Measuring www.xeonbd.com while building this, the first byte arrived in 86 ms from Dhaka and 1.21 seconds from Miami: fourteen times slower for an American visitor, and completely invisible to anyone testing from only one side. If you sell to both, test from both.
The first byte is where most of the fixable time hides, and it splits into four parts that have completely different remedies. DNS and connect time are distance and routing. TLS is handshake cost. What is left is the server thinking, and that last part is almost always the application rather than the network: an object cache that was never switched on, a scheduled job running on a visitor's request, a query nobody looked at. This check separates them so you know which of the four you are actually fighting.
One warning worth reading before you trust any speed result, including this one. A page served from cache is fast by definition. On a site measured while building this tool, the same page answered in 14 ms from cache and 2,362 ms without it. If the response says it came from a cache, this check tells you plainly that you are looking at the easy case, because the visitor who decides whether your site feels slow is the one who arrives when the cache is cold.
No, and deliberately. LCP, CLS and INP need a real browser rendering the page, and there is no browser behind this check. Estimating them from network timings produces a number that disagrees with Google's own and cannot be reconciled, so this reports the half it genuinely measures and names the half it does not.
Because it is measured from a different place. PageSpeed runs from Google's network; this runs from Dhaka. If the two disagree about your first byte, that gap is the cost of distance for your local visitors, and it is a real finding rather than a discrepancy.
It fetches the HTML and then the stylesheets, scripts and images the page references, up to a bounded number of files, so the weight is measured rather than estimated. It does not execute JavaScript, so anything a script loads afterwards is not counted.