Benchmark report
Is the Wikipedia API slow?
Response times from 5 cities
Mixed by location
Response times ranged from 12 ms in Amsterdam to 226 ms in Tokyo. Where you are matters.
- Fastest
- 12 ms
- Amsterdam
- Slowest
- 226 ms
- Tokyo
- Successful requests
- 100%
- 5 of 6 locations
Response time around the world
Amsterdam12 ms
Singapore14 ms
Montreal50 ms
San Francisco216 ms
Tokyo226 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 16 and 15 ms: 2 to 3 ms to connect, 11 ms for TLS, 2 ms waiting and a download too short to measure. Montreal took 51 ms. San Francisco and Tokyo took 216 and 224 ms, and again the connection gives it away: 70 and 73 ms to connect, 74 and 78 ms for TLS, 71 and 73 ms waiting. That is three round trips to a distant site. The Wikipedia portal, fetched from the same addresses, takes about twice as long in those two cities because it also pulls 120 KB back over that path; this 2.9 KB response does not.
Click the location to see each stage.
Tokyo224 ms
Tokyo- Finding the server
- 1 ms
- Reaching the server
- 73 ms
- Setting up security: most of the time
- 78 ms
- Waiting for the server
- 73 ms
- Receiving the response
- 0 ms
- Total
- 224 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.
Amsterdam16 ms
Amsterdam- Finding the server
- 1 ms
- Reaching the server
- 3 ms
- Setting up security: most of the time
- 11 ms
- Waiting for the server
- 2 ms
- Receiving the response
- 0 ms
- Total
- 16 ms
San Francisco216 ms
San Francisco- Finding the server
- 12 ms
- Reaching the server
- 70 ms
- Setting up security: most of the time
- 74 ms
- Waiting for the server
- 71 ms
- Receiving the response
- 1 ms
- Total
- 216 ms
Montreal51 ms
Montreal- Finding the server
- 45 ms
- Reaching the server
- 15 ms
- Setting up security: most of the time
- 19 ms
- Waiting for the server
- 17 ms
- Receiving the response
- 0 ms
- Total
- 51 ms
Singapore15 ms
Singapore- Finding the server
- 3 ms
- Reaching the server
- 2 ms
- Setting up security: most of the time
- 11 ms
- Waiting for the server
- 2 ms
- Receiving the response
- 0 ms
- Total
- 15 ms
Tokyo224 ms
Tokyo- Finding the server
- 1 ms
- Reaching the server
- 73 ms
- Setting up security: most of the time
- 78 ms
- Waiting for the server
- 73 ms
- Receiving the response
- 0 ms
- Total
- 224 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 the action API
- The MediaWiki action API, article HTML, search, edits and images are not measured here. Only the cached REST summary of one article is.
- Which Wikimedia site answers you depends on your network
- Three 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.
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 | 15 ms | 209 ms | 51 ms | 45 ms ▲ | 225 ms | — |
| 28 August 2026 | 13 ms | 220 ms | 49 ms | 15 ms | 225 ms | — |
| 29 August 2026 | 13 ms | 222 ms | 50 ms | 13 ms | 222 ms | — |
| 30 August 2026 | 14 ms | 219 ms | 50 ms | 16 ms | 225 ms | — |
| 31 August 2026 | 13 ms | 220 ms | 51 ms | 14 ms | 227 ms | — |
| 1 September 2026 | 12 ms | 211 ms | 50 ms | 14 ms | 228 ms | — |
| 2 September 2026 | 12 ms | 216 ms | 54 ms | 14 ms | 226 ms | — |
| 3 September 2026 | 12 ms | 216 ms | 50 ms | 14 ms | 225 ms | — |
| 4 September 2026 | 11 ms | 215 ms | 50 ms | 30 ms | 227 ms | — |
| 5 September 2026 | 11 ms | 214 ms | 51 ms | 32 ms | 225 ms | — |
| 6 September 2026 | 17 ms | 217 ms | 50 ms | 14 ms | 228 ms | — |
| 7 September 2026 | 13 ms | 216 ms | 50 ms | 12 ms | 224 ms | 176 ms |
| 8 September 2026 | 14 ms | 216 ms | 49 ms | 14 ms | 232 ms | 176 ms |
| 9 September 2026 | 13 ms | 214 ms | 50 ms | 16 ms | 237 ms | 182 ms |
| 10 September 2026 | 12 ms | 214 ms | 50 ms | 12 ms | 221 ms | 182 ms |
| 11 September 2026 | 11 ms | 212 ms | 49 ms | 12 ms | 225 ms | 182 ms |
| 12 September 2026 | 11 ms | 223 ms | 48 ms | 12 ms | 223 ms | 177 ms |
About this measurement
GET en.wikipedia.org/api/rest_v1/page/summary/Internet · 70 requests per location over 14 daily runs · 30 August 2026 to 12 September 2026
What we tested · API response. The REST summary of one article (page/summary/Internet), 2.9 KB of JSON, cached up to 14 days at Wikimedia's edge.
How LatencyRadar measures response time →Also measured: Wikipedia →
Technical details
Doesn’t measure: The MediaWiki action API, uncached articles, or edits.
This report covers one Wikipedia surface: the REST API's summary of the article on the Internet, 2.9 KB of JSON that Wikimedia's edge caches for up to 14 days. It is the call apps and bots make for a title, extract and thumbnail, and the number is close to the pure cost of reaching Wikimedia's nearest site, with almost no body to download. The www.wikipedia.org portal has its own report. This call does not stand for the MediaWiki action API, for uncached or rarely visited articles, or for edits.
Not measured: the MediaWiki action API, article HTML, search, edits, or images. From outside we cannot see how Wikimedia routes 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 12 ms in Amsterdam and 14 ms in Singapore, 50 ms in Montreal, and 216 ms in San Francisco and 226 ms in Tokyo. All five cities were steady: San Francisco's daily median stayed between 211 and 223 ms and Tokyo's between 221 and 237 ms on every run. San Francisco connected to the same address Montreal used and Tokyo to the same address Singapore used, each about 70 ms away, the pattern the portal page shows in more detail. Singapore's slower time of 64 ms is the median of two controlled runs that disagreed, 108 ms on 30 August and 20 ms on 7 September; its daily median was 12 to 32 ms.
| Test location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 12 ms | 22 ms | 20 |
| San Francisco | 216 ms | 224 ms | 20 |
| Montreal | 50 ms | 57 ms | 20 |
| Singapore | 14 ms | 64 ms | 20 |
| Tokyo | 226 ms | 234 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 en.wikipedia.org/api/rest_v1/page/summary/Internet
- 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 API
https://en.wikipedia.org/api/rest_v1/page/summary/Internet
Independent measurement by LatencyRadar. Not affiliated with Wikipedia. · How we measure (v1.1)
How fast is your API 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.
