Benchmark report
Is Wikipedia slow?
Portal load times from 5 cities
Slow from some locations
Tokyo waited 436 ms, about 27× Amsterdam. The gap suggests some test locations reach a distant server.
- Fastest
- 16 ms
- Amsterdam
- Slowest
- 436 ms
- Tokyo
- Successful requests
- 100%
- 5 of 6 locations
Response time around the world
Amsterdam16 ms
Singapore19 ms
Montreal88 ms
San Francisco414 ms
Tokyo436 ms
MumbaiCollecting since 7 Sept 2026
Why are San Francisco and Tokyo slower?
In the controlled run of 7 September Amsterdam and Singapore finished in 20 and 18 ms, connecting in 2 to 3 ms. Montreal took 91 ms: 16 ms to connect, 18 ms for TLS, 20 ms waiting and 37 ms downloading. San Francisco and Tokyo took 408 and 426 ms, and their first phase gives the reason: 70 and 73 ms just to open the connection, then 77 and 78 ms for TLS, 88 and 93 ms waiting and 173 to 182 ms downloading the 120 KB over that long path. A 70 ms connection is a long way. San Francisco connected to the same address Montreal used (208.80.154.224), and Tokyo to the same address Singapore used (103.102.166.224). Wikimedia operates a caching site in San Francisco; our worker there does not appear to reach it.
Click the location to see each stage.
Tokyo426 ms
Tokyo- Finding the server
- 75 ms
- Reaching the server
- 73 ms
- Setting up security
- 78 ms
- Waiting for the server
- 93 ms
- Receiving the response: most of the time
- 182 ms
- Total
- 426 ms
Finding the server is measured once per location, so it sits outside these bars. Open a city to see it.
Bars show the typical request, so the parts add up to its total. Why
Compare all locationsHide the comparison
Click a city to see its stage-by-stage breakdown.
Amsterdam20 ms
Amsterdam- Finding the server
- 1 ms
- Reaching the server
- 2 ms
- Setting up security: most of the time
- 10 ms
- Waiting for the server
- 4 ms
- Receiving the response
- 4 ms
- Total
- 20 ms
San Francisco408 ms
San Francisco- Finding the server
- 10 ms
- Reaching the server
- 70 ms
- Setting up security
- 77 ms
- Waiting for the server
- 88 ms
- Receiving the response: most of the time
- 173 ms
- Total
- 408 ms
Montreal91 ms
Montreal- Finding the server
- 1 ms
- Reaching the server
- 16 ms
- Setting up security
- 18 ms
- Waiting for the server
- 20 ms
- Receiving the response: most of the time
- 37 ms
- Total
- 91 ms
Singapore18 ms
Singapore- Finding the server
- 3 ms
- Reaching the server
- 3 ms
- Setting up security: most of the time
- 6 ms
- Waiting for the server
- 5 ms
- Receiving the response
- 4 ms
- Total
- 18 ms
Tokyo426 ms
Tokyo- Finding the server
- 75 ms
- Reaching the server
- 73 ms
- Setting up security
- 78 ms
- Waiting for the server
- 93 ms
- Receiving the response: most of the time
- 182 ms
- Total
- 426 ms
The phases come from the controlled run of 7 September 2026. Typical times pool daily requests; slower times use controlled full runs. 5 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo.
Finding the server is measured once per location, so it sits outside these bars. Open a city to see it.
Bars show the typical request, so the parts add up to its total. Why
Wikipedia still feels slow?
- Check Wikimedia’s status page
- Site-wide incidents are posted there. The routing pattern on this page is not an incident; it held on every daily run.
- This is not an article benchmark
- Article pages, the mobile site, search, editing, images and the MediaWiki API are not measured here. The Wikipedia REST API has its own report.
- Which Wikimedia site answers you depends on your network
- Three different Wikimedia addresses across our five cities in the controlled run. Amsterdam and Singapore connected in 2 to 3 ms; San Francisco shared Montreal's address and Tokyo shared Singapore's, each about 70 ms away. A reader in San Francisco on another network may see a very different number.
Response time over the last 30 days
A dot marks a day well above that location’s usual level.
Show the numbers
| Day | Amsterdam | San Francisco | Montreal | Singapore | Tokyo | Mumbai |
|---|---|---|---|---|---|---|
| 27 August 2026 | 17 ms | 421 ms | 87 ms | 39 ms | 434 ms | — |
| 28 August 2026 | 16 ms | 406 ms | 88 ms | 21 ms | 431 ms | — |
| 29 August 2026 | 16 ms | 423 ms | 88 ms | 17 ms | 441 ms | — |
| 30 August 2026 | 17 ms | 583 ms | 88 ms | 24 ms | 434 ms | — |
| 31 August 2026 | 16 ms | 422 ms | 89 ms | 20 ms | 434 ms | — |
| 1 September 2026 | 16 ms | 420 ms | 89 ms | 16 ms | 443 ms | — |
| 2 September 2026 | 16 ms | 401 ms | 100 ms | 24 ms | 446 ms | — |
| 3 September 2026 | 16 ms | 420 ms | 86 ms | 22 ms | 436 ms | — |
| 4 September 2026 | 15 ms | 416 ms | 89 ms | 24 ms | 436 ms | — |
| 5 September 2026 | 16 ms | 435 ms | 88 ms | 19 ms | 439 ms | — |
| 6 September 2026 | 18 ms | 415 ms | 89 ms | 16 ms | 437 ms | — |
| 7 September 2026 | 16 ms | 408 ms | 87 ms | 24 ms | 436 ms | 343 ms |
| 8 September 2026 | 14 ms | 428 ms | 87 ms | 16 ms | 426 ms | 334 ms |
| 9 September 2026 | 15 ms | 413 ms | 88 ms | 70 ms ▲ | 429 ms | 343 ms |
| 10 September 2026 | 16 ms | 407 ms | 84 ms | 16 ms | 431 ms | 342 ms |
| 11 September 2026 | 16 ms | 406 ms | 85 ms | 18 ms | 421 ms | 343 ms |
| 12 September 2026 | 16 ms | 409 ms | 112 ms | 17 ms | 433 ms | 334 ms |
About this measurement
GET www.wikipedia.org · 70 requests per location over 14 daily runs · 30 August 2026 to 12 September 2026
What we tested · Website document. The www.wikipedia.org language portal, about 120 KB of HTML, served from Wikimedia's own cache layer (ATS).
How LatencyRadar measures response time →Also measured: Wikipedia API →
Technical details
Doesn’t measure: An article page on a language edition, editing, or search.
One Wikipedia surface: the www.wikipedia.org language portal, about 120 KB of HTML that Wikimedia serves from its own cache servers rather than from a commercial CDN. It is the front door a reader types before choosing a language, and it changes rarely, so nearly every request should be a cache hit; the number is close to the cost of reaching Wikimedia's nearest site and pulling 120 KB back. It does not stand for an article page, which is larger, sometimes uncached and served by a language edition, or for search or editing. The Wikipedia REST API has a separate report.
Not measured: article pages, the mobile site, search, editing, images from upload.wikimedia.org or the MediaWiki API. From outside we cannot see how Wikimedia steers each request to one of its sites. We see the address each city connected to and how long the connection took, which together suggest where that site is.
Between 30 August and 12 September 2026 the typical time was 16 ms in Amsterdam and 19 ms in Singapore, 88 ms in Montreal, and 414 ms in San Francisco and 436 ms in Tokyo. The two slow cities were slow on every daily run: San Francisco's median stayed between 401 and 435 ms apart from a 583 ms run on 30 August, and Tokyo's between 421 and 446 ms. Wikimedia operates a caching site in San Francisco, yet our San Francisco worker connected to the address Montreal used, with a 70 ms connection time that suggests the US East Coast, and Tokyo connected to the address Singapore used, 73 ms away. We cannot say from outside whether that routing is Wikimedia's choice, our workers' network provider or something in between; a reader in San Francisco on another network may see a very different number. The Google homepage is the other reference site in this set.
| Test location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 16 ms | 25 ms | 20 |
| San Francisco | 414 ms | 421 ms | 20 |
| Montreal | 88 ms | 95 ms | 20 |
| Singapore | 19 ms | 26 ms | 20 |
| Tokyo | 436 ms | 450 ms | 20 |
| Mumbai | Collecting since 7 Sept 2026 | ||
Typical: half of the requests finished within this time (technical: p50). Slower: 95% of requests finished within this time (technical: p95). Statistics
- Request
- GET www.wikipedia.org
- Measured from
- Amsterdam · San Francisco · Montreal · Singapore · Tokyo
- Requests
- Daily measurements from 30 August 2026 to 12 September 2026. 5 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo. · 30 August 2026 to 12 September 2026
- Timings taken
- DNS, connect, TLS, waiting for the server, download
- Report coverage
- 5 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo.
- Daily requests in each location
- Amsterdam: 70 · San Francisco: 70 · Montreal: 70 · Singapore: 70 · Tokyo: 70
- Typical response time
- Median of the eligible daily requests in each included location.
- Slower response time
- Median of recent controlled full-run p95 values in each included location.
Wikipedia
https://www.wikipedia.org/
Independent measurement by LatencyRadar. Not affiliated with Wikipedia. · How we measure (v1.1)
How fast does your site load around the world?
Run a free speed test from multiple cities and find out where your users are waiting. No setup, no account required.
No account required · Takes about 30 seconds.
