Benchmark report
Is fastly.com slow?
Homepage load times from 5 cities
Fast globally
Fastly responds quickly from all 5 test locations. Amsterdam was fastest at 14 ms; San Francisco took 96 ms.
- Fastest
- 14 ms
- Amsterdam
- Slowest
- 96 ms
- San Francisco
- Successful requests
- 100%
- 5 of 6 locations
Response time around the world
Amsterdam14 ms
Montreal15 ms
Tokyo16 ms
Singapore19 ms
San Francisco96 ms
MumbaiCollecting since 7 Sept 2026
Why is San Francisco slower?
Four cities finished in 13 to 18 ms in the controlled run of 7 September, with every phase in single digits: 2 to 3 ms to connect, 3 to 4 ms for TLS, 2 to 3 ms waiting and 5 to 8 ms downloading. San Francisco took 96 ms, and every phase grew together: 14 ms to connect, 16 ms for TLS, 14 ms waiting, 52 ms downloading. When all four stages stretch by a similar factor, the likely cause is a longer path to the edge that answered, not a slow server.
Click the location to see each stage.
San Francisco96 ms
San Francisco- Finding the server
- 13 ms
- Reaching the server
- 14 ms
- Setting up security
- 16 ms
- Waiting for the server
- 14 ms
- Receiving the response: most of the time
- 52 ms
- Total
- 96 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.
Amsterdam13 ms
Amsterdam- Finding the server
- 18 ms
- Reaching the server
- 2 ms
- Setting up security
- 3 ms
- Waiting for the server
- 3 ms
- Receiving the response: most of the time
- 5 ms
- Total
- 13 ms
San Francisco96 ms
San Francisco- Finding the server
- 13 ms
- Reaching the server
- 14 ms
- Setting up security
- 16 ms
- Waiting for the server
- 14 ms
- Receiving the response: most of the time
- 52 ms
- Total
- 96 ms
Montreal18 ms
Montreal- Finding the server
- 60 ms
- Reaching the server
- 3 ms
- Setting up security
- 4 ms
- Waiting for the server
- 3 ms
- Receiving the response: most of the time
- 8 ms
- Total
- 18 ms
Singapore14 ms
Singapore- Finding the server
- 2 ms
- Reaching the server
- 3 ms
- Setting up security
- 4 ms
- Waiting for the server
- 2 ms
- Receiving the response: most of the time
- 5 ms
- Total
- 14 ms
Tokyo14 ms
Tokyo- Finding the server
- 131 ms
- Reaching the server
- 2 ms
- Setting up security
- 4 ms
- Waiting for the server
- 3 ms
- Receiving the response: most of the time
- 5 ms
- Total
- 14 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
Fastly still feels slow?
- Check Fastly’s status page
- Edge incidents are posted per location there before they show up in a benchmark.
- This is not a benchmark of your Fastly service
- Your origin, VCL, cache rules and shielding decide what your visitors see. Compute, image optimisation and the control panel are not measured here.
- Each city reaches its own edge
- Six different addresses across our six cities in the controlled run, 83 ms apart at most. The edge San Francisco reaches answers noticeably more slowly than the others. A slow result from the US West Coast matches what we see; elsewhere it would be unusual.
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 | 16 ms | 81 ms | 17 ms | 30 ms | 16 ms | — |
| 28 August 2026 | 18 ms | 88 ms | 21 ms | 25 ms | 16 ms | — |
| 29 August 2026 | 12 ms | 79 ms | 16 ms | 17 ms | 15 ms | — |
| 30 August 2026 | 15 ms | 75 ms | 15 ms | 22 ms | 17 ms | — |
| 31 August 2026 | 13 ms | 71 ms | 16 ms | 20 ms | 14 ms | — |
| 1 September 2026 | 13 ms | 184 ms ▲ | 108 ms ▲ | 16 ms | 16 ms | — |
| 2 September 2026 | 21 ms | 628 ms ▲ | 15 ms | 29 ms | 18 ms | — |
| 3 September 2026 | 12 ms | 182 ms | 112 ms ▲ | 19 ms | 17 ms | — |
| 4 September 2026 | 12 ms | 95 ms | 14 ms | 18 ms | 18 ms | — |
| 5 September 2026 | 14 ms | 219 ms ▲ | 15 ms | 20 ms | 15 ms | — |
| 6 September 2026 | 13 ms | 70 ms | 16 ms | 17 ms | 17 ms | — |
| 7 September 2026 | 16 ms | 72 ms | 16 ms | 29 ms | 16 ms | 13 ms |
| 8 September 2026 | 15 ms | 198 ms ▲ | 114 ms ▲ | 15 ms | 16 ms | 15 ms |
| 9 September 2026 | 13 ms | 89 ms | 15 ms | 16 ms | 16 ms | 12 ms |
| 10 September 2026 | 17 ms | 173 ms | 13 ms | 18 ms | 14 ms | 14 ms |
| 11 September 2026 | 16 ms | 187 ms ▲ | 15 ms | 20 ms | 16 ms | 11 ms |
| 12 September 2026 | 12 ms | 195 ms ▲ | 13 ms | 19 ms | 13 ms | 15 ms |
About this measurement
GET www.fastly.com · 70 requests per location over 14 daily runs · 30 August 2026 to 12 September 2026
What we tested · Marketing website. The www.fastly.com marketing homepage, about 665 KB of HTML served through Fastly's own cache.
How LatencyRadar measures response time →
Technical details
Doesn’t measure: The Fastly edge serving your service, Compute, or the control panel.
One Fastly surface: the www.fastly.com marketing homepage, about 665 KB of HTML served through Fastly's own cache. Fastly puts its own site on the CDN it sells, so the page shows how a cold request to that CDN is answered from each of our cities. It does not stand for your Fastly service: your origin, VCL, cache rules and shielding decide what your visitors see.
Not measured: a Fastly service you configure, Compute, image optimisation, the control panel, or anything a browser does after the HTML arrives. From outside we cannot tell a cache miss from a longer path to the edge, and we do not know which point of presence answered beyond the address it used.
Between 30 August and 12 September 2026 Amsterdam, Montreal, Singapore and Tokyo all had a typical time of 14 to 19 ms, and San Francisco 96 ms. San Francisco's daily median was 70 ms or more on every one of the 14 runs and reached 628 ms on 2 September, so it is not one bad day: whatever edge our San Francisco worker reaches, it is not as close as the other four cities' edges are to them. Montreal, otherwise 13 to 16 ms, had three days at 108 to 114 ms. The six different addresses across our cities in the controlled run fit an edge network. Netlify shows the same shape with Amsterdam as the outlier; Vercel is slower in four of the five cities.
| Test location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 14 ms | 18 ms | 20 |
| San Francisco | 96 ms | 162 ms | 20 |
| Montreal | 15 ms | 23 ms | 20 |
| Singapore | 19 ms | 34 ms | 20 |
| Tokyo | 16 ms | 21 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.fastly.com
- 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.
Fastly
https://www.fastly.com/
Independent measurement by LatencyRadar. Not affiliated with Fastly. · 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.
