Benchmark report
Is the Wikipedia API slow?
Response times from 6 cities
Mixed by location
Response times ranged from 12 ms in Amsterdam to 236 ms in Tokyo. Where you are matters.
- Fastest
- 12 ms
- Amsterdam
- Slowest
- 236 ms
- Tokyo
- Successful requests
- 100%
- 6 locations
Response time around the world
Amsterdam12 ms
Singapore13 ms
Montreal50 ms
Mumbai181 ms
San Francisco216 ms
Tokyo236 ms
Why are San Francisco, Tokyo and Mumbai slower?
In the controlled run of 4 October Amsterdam and Singapore finished in 20 and 21 ms: 3 ms to connect, 12 to 14 ms for TLS, 2 to 6 ms waiting and a download of 1 ms or less. Montreal took 49 ms. San Francisco, Tokyo and Mumbai took 216, 242 and 181 ms, and again the connection gives it away: 58 to 80 ms to connect, 65 to 83 ms for TLS, 57 to 79 ms waiting. That is three round trips to a distant site. The Wikipedia portal, fetched from the same addresses, takes nearly twice as long in those three 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.
Tokyo242 ms
Tokyo- Finding the server
- 2 ms
- Reaching the server
- 80 ms
- Setting up security: most of the time
- 83 ms
- Waiting for the server
- 79 ms
- Receiving the response
- 0 ms
- Total
- 242 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
- 2 ms
- Reaching the server
- 3 ms
- Setting up security: most of the time
- 14 ms
- Waiting for the server
- 2 ms
- Receiving the response
- 1 ms
- Total
- 20 ms
San Francisco216 ms
San Francisco- Finding the server
- 45 ms
- Reaching the server
- 71 ms
- Setting up security: most of the time
- 74 ms
- Waiting for the server
- 70 ms
- Receiving the response
- 1 ms
- Total
- 216 ms
Montreal49 ms
Montreal- Finding the server
- 1 ms
- Reaching the server
- 16 ms
- Setting up security: most of the time
- 18 ms
- Waiting for the server
- 15 ms
- Receiving the response
- 0 ms
- Total
- 49 ms
Singapore21 ms
Singapore- Finding the server
- 2 ms
- Reaching the server
- 3 ms
- Setting up security: most of the time
- 12 ms
- Waiting for the server
- 6 ms
- Receiving the response
- 0 ms
- Total
- 21 ms
Tokyo242 ms
Tokyo- Finding the server
- 2 ms
- Reaching the server
- 80 ms
- Setting up security: most of the time
- 83 ms
- Waiting for the server
- 79 ms
- Receiving the response
- 0 ms
- Total
- 242 ms
Mumbai181 ms
Mumbai- Finding the server
- 3 ms
- Reaching the server
- 58 ms
- Setting up security: most of the time
- 65 ms
- Waiting for the server
- 57 ms
- Receiving the response
- 1 ms
- Total
- 181 ms
The phases come from the controlled run of 4 October 2026. Typical and slower times pool the daily requests. 6 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo, Mumbai.
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 six cities in the controlled run. Amsterdam and Singapore connected in 3 ms; San Francisco shared Montreal's address, and Tokyo and Mumbai shared Singapore's, 58 to 80 ms away.
Response time over the last 29 days
A dot marks a day well above that location’s usual level.
Show the numbers
| Day | Amsterdam | San Francisco | Montreal | Singapore | Tokyo | Mumbai |
|---|---|---|---|---|---|---|
| 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 |
| 13 September 2026 | 13 ms | 216 ms | 49 ms | 13 ms | 229 ms | 182 ms |
| 14 September 2026 | 12 ms | 216 ms | 48 ms | 12 ms | 221 ms | 182 ms |
| 15 September 2026 | 13 ms | 216 ms | 50 ms | 13 ms | 215 ms | 177 ms |
| 16 September 2026 | 11 ms | 212 ms | 48 ms | 12 ms | 219 ms | 182 ms |
| 17 September 2026 | 16 ms | 216 ms | 49 ms | 13 ms | 212 ms | 183 ms |
| 18 September 2026 | 10 ms | 217 ms | 49 ms | 16 ms | 214 ms | 177 ms |
| 19 September 2026 | 11 ms | 217 ms | 49 ms | 12 ms | 218 ms | 176 ms |
| 20 September 2026 | 10 ms | 214 ms | 50 ms | 17 ms | 224 ms | 184 ms |
| 21 September 2026 | 12 ms | 216 ms | 48 ms | 20 ms | 243 ms | 177 ms |
| 22 September 2026 | 14 ms | 217 ms | 50 ms | 14 ms | 238 ms | 184 ms |
| 23 September 2026 | 13 ms | 138 ms | 131 ms ▲ | 14 ms | 234 ms | 178 ms |
| 24 September 2026 | 11 ms | 217 ms | 51 ms | 12 ms | 249 ms | 184 ms |
| 25 September 2026 | 11 ms | 216 ms | 51 ms | 14 ms | 248 ms | 182 ms |
| 26 September 2026 | 12 ms | 210 ms | 48 ms | 12 ms | 241 ms | 176 ms |
| 27 September 2026 | 11 ms | 218 ms | 50 ms | 12 ms | 219 ms | 179 ms |
| 28 September 2026 | 12 ms | 214 ms | 50 ms | 11 ms | 218 ms | 176 ms |
| 29 September 2026 | 15 ms | 216 ms | 50 ms | 14 ms | 237 ms | 183 ms |
| 30 September 2026 | 11 ms | 217 ms | 50 ms | 16 ms | 236 ms | 183 ms |
| 1 October 2026 | 11 ms | 231 ms | 50 ms | 14 ms | 236 ms | 186 ms |
| 2 October 2026 | 13 ms | 217 ms | 52 ms | 13 ms | 237 ms | 176 ms |
| 3 October 2026 | 13 ms | 218 ms | 51 ms | 14 ms | 224 ms | 175 ms |
| 4 October 2026 | 9 ms | 216 ms | 51 ms | 13 ms | 237 ms | 181 ms |
| 5 October 2026 | 11 ms | 215 ms | 49 ms | 12 ms | 243 ms | 182 ms |
| 6 October 2026 | 12 ms | 210 ms | 49 ms | 12 ms | 240 ms | 181 ms |
| 7 October 2026 | 11 ms | 210 ms | 52 ms | 12 ms | 249 ms | 182 ms |
| 9 October 2026 | 11 ms | 213 ms | 50 ms | 14 ms | 223 ms | 181 ms |
| 10 October 2026 | 11 ms | 218 ms | 52 ms | 28 ms | 225 ms | 182 ms |
About this measurement
GET en.wikipedia.org/api/rest_v1/page/summary/Internet · 65 requests per location over 13 daily runs · 27 September 2026 to 10 October 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.
Between 27 September and 10 October 2026 the typical time was 12 ms in Amsterdam and 13 ms in Singapore, 50 ms in Montreal, and 181 ms in Mumbai, 216 ms in San Francisco and 236 ms in Tokyo. The daily medians were steady: Mumbai's stayed between 175 and 186 ms, San Francisco's between 210 and 231 ms and Tokyo's between 218 and 249 ms on every run. From outside we cannot see how Wikimedia routes each request to one of its sites, but the address each city connected to and how long the connection took together suggest where that site is. San Francisco connected to the same address Montreal used, and Tokyo and Mumbai to the same address Singapore used, each 58 to 80 ms away, the pattern the portal page shows in more detail. The slower times are less even. Singapore's is 232 ms against a typical 13 ms, Amsterdam's 108 ms against 12 ms and Mumbai's 394 ms against 181 ms: a few of the 65 requests in each of those cities took far longer than the rest, while their daily medians barely moved.
| Test location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 12 ms | 108 ms | 65 |
| San Francisco | 216 ms | 231 ms | 65 |
| Montreal | 50 ms | 55 ms | 65 |
| Singapore | 13 ms | 232 ms | 65 |
| Tokyo | 236 ms | 271 ms | 65 |
| Mumbai | 181 ms | 394 ms | 65 |
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 · Mumbai
- Requests
- Daily measurements from 27 September 2026 to 10 October 2026. 6 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo, Mumbai. · 27 September 2026 to 10 October 2026
- Timings taken
- DNS, connect, TLS, waiting for the server, download
- Report coverage
- 6 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo, Mumbai.
- Coverage changes
- Mumbai (measured since 7 September 2026) joined this report on 21 September 2026. Earlier daily bands keep their previous location set.
- Daily requests in each location
- Amsterdam: 65 · San Francisco: 65 · Montreal: 65 · Singapore: 65 · Tokyo: 65 · Mumbai: 65
- Typical response time
- Median of the eligible daily requests in each included location.
- Slower response time
- The 95th percentile of the same eligible daily requests 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.3)
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.
