How fast is IBM Cloud from your place?

Most "cloud ping" sites and every provider looking glass send the test from their servers, sitting in data centers on premium transit. That tells you how one data center reaches another. It says nothing about the part you actually feel: your home or mobile line, your ISP's backbone, its border links and how crowded they are tonight.

Me2Cloud sends every request from your browser, so the result includes all of it: Wi-Fi, router, ISP, the route your ISP picks, and the evening rush.

1. A warm-up request opens DNS, TCP and TLS. Its time is shown but never counted.
2. Then the browser sends 5, 10 or 20 more requests to the same host over the same connection. Each one costs a single round trip plus the provider's processing time.
3. Each provider uses the request type we verified keeps the connection open: GET for AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean and Scaleway; HEAD for Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr and OVHcloud (their GET closes the connection, which would triple every sample); <img> only for Hetzner.
4. We report median (the typical value), average, P90 (9 out of 10 samples are at or below it), jitter (average change between consecutive samples) and loss (samples with no answer within the timeout).
5. The tier comes from the median: T0 ≤ 30 ms, T1 ≤ 80 ms, T2 ≤ 150 ms, T3 ≤ 250 ms, T4 above that. The overall score used for picks is median + 2 × jitter + loss penalty, so a steady 60 ms beats a jumpy 45 ms.

• Same road as your traffic. Websites, APIs, SSH tunnels over 443, game logins and downloads all ride TCP. Many ISPs queue, shape or route ICMP separately, so ping can look fine while pages crawl, or the other way round.
• Not throttled away. Routers and clouds often rate-limit or drop ICMP. HTTPS to a public endpoint always gets an answer.
• Includes your real setup. DNS, IPv4 vs IPv6 choice, proxies and accelerators all apply to browser traffic, so you test what you would actually get.
• The catch: each sample also includes a small, steady server processing time. We measured 0–5 ms for AWS, about 8 ms for Alibaba Cloud and about 20 ms for Huawei Cloud OBS. For anything over 100 ms it does not matter; for very nearby regions the number reads a bit higher than ping.

• Residential networks are most crowded from about 20:00 to 23:00, and cross-border links even more. A region that is T1 at noon can drop to NPC at night.
• Run once during the day and once at peak. Saved runs are tagged “peak hour”, and you can switch between them in Results.
• Pause big downloads, streaming and cloud sync while testing. Wired beats Wi-Fi; if you must use Wi-Fi, stay near the router.
• On mobile data, results move with signal strength. Test where you will actually use the service.

• Shortlisting regions before you buy a server, a game host or a CDN origin.
• Comparing regions of one provider, or the same city across providers.
• Checking stability (jitter, loss) for gaming, video calls, remote desktop and SSH.
• Seeing how your proxy, accelerator or new ISP plan really performs, by testing with and without it.
• Testing your own server or CDN next to the big names with a custom endpoint.

• One location only. It is your line, not your users'. Ask a few users to run it, or export and compare.
• Endpoints, not your future VM. We test each provider's public API or storage endpoint in the region. Servers in the same region usually share the network, but premium routes (for example CN2, BGP vs single-carrier lines, Lightsail vs EC2) can differ.
• No bandwidth, no UDP, no route trace. It measures round trips, not download speed, UDP game traffic or the hops in between.
• Browser effects. Extensions, proxies, VPNs and a busy tab add noise. Close heavy tabs and keep the page in front.
• Hetzner cannot keep a connection open from a browser, so its numbers include a handshake every time. Some endpoints can also be unreachable from a few countries.

• The page is static files on Cloudflare. There is no backend, no account, no analytics, and results are never uploaded.
• All test requests go directly from your browser to the provider. Open the Request log above or your browser's developer tools (Network tab) to see each one.
• Network info comes from Cloudflare (speed.cloudflare.com/meta and /cdn-cgi/trace), and the optional WebRTC check asks stun.cloudflare.com for your UDP exit address. Turn it off in Settings if you prefer.
• Settings, custom endpoints and the last runs stay in this browser's local storage. “Reset all data” wipes them.

Hitting public endpoints too hard could trip a provider's rate limiting or WAF and spoil the result. The test is built to stay far below that:

• One request at a time per host, with a 250–370 ms pause between samples (about 2–3 requests per second per host at most).
• At most 2 hosts per provider at once, and at most 8 hosts overall (4 by default).
• At most 21 requests per host per run (warm-up + 20). No continuous mode.
• A host is dropped after 3 failures in a row instead of being retried.
• Anonymous, cookie-less, referrer-less "simple" requests: no preflight, tiny responses (a few hundred bytes), HEAD where possible, and nothing is downloaded in bulk.

That is less traffic than opening one ordinary web page. Every endpoint was checked to answer anonymous requests normally (status 200, 403 or 404 is all fine for timing).

If your traffic goes through a proxy, the browser measures your route to the proxy plus the proxy's route to the provider, not your own line. The network panel looks for the usual signs: an exit network that belongs to a data center, a time zone that does not match the exit country, WARP, or a WebRTC exit that differs from the HTTPS one.

Use Get bypass rules to send just the test hosts direct (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega or a plain list), then check again. If you want to measure the proxy itself, leave it on: the numbers are then the proxy's real performance.

• Each row's strip uses one shared scale (log, 2 ms to 3 s). Dots are samples, the shaded box covers the middle half of the samples, and the bar is the median.
• A narrow box means steady; a wide box or scattered dots means jitter. A red × counts lost samples.
• Click a row to see each sample in order, plus all stats and the endpoint used. ✓ marks a row that fits your needs.