Diagnostics run on our own network · BDIX-peered · Dhaka & Miami Engine operational Docs
MyDCHub Workspace Check a domain
Home / Tools / SPEED

Website speed test

Measure a site from Dhaka: where the first byte goes, what the page weighs, and whether caching and compression are actually on.

Why where you measure from decides the answer

Most speed tools measure from wherever their own servers happen to be, which for a Bangladeshi audience is usually Europe or the United States. 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. The number that matters is the one taken from where your customers actually are, so this check runs on our own BDIX-peered network in Dhaka and says so on every result.

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.

Common questions

Does this give me a Core Web Vitals score?

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.

Why is my result different from PageSpeed Insights?

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.

Does it load the whole page like a browser?

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.