Is 340 ms slow?

What does the 340 ms number measure? It might be one server response, the wait for the first byte, a full page load, or the first token from an AI model. Those are different jobs, so they should not share one pass-or-fail line.

A 340 ms response from one URL does not mean the whole page loaded in 340 ms. The browser may still need to download images, fonts, CSS, and JavaScript, then draw the page. Treat 340 ms as one part of the experience unless your tool clearly says it measured the full load.

This table is a quick guide, not a web standard. It assumes one request to a server reasonably close to the person making it.

The Nielsen Norman Group's response-time guidance says about 100 ms feels instant, while a delay of about one second is noticeable but can still preserve a person's flow of thought. That research describes feedback in an interface. It is not a universal score for every HTTP request.

For a website's first response, Google gives a different rough guide. Its TTFB guidance says most sites should aim for 800 ms or less, while more than 1,800 ms is poor. TTFB means Time to First Byte: how long the browser waits before the server starts replying. It is not the same as the time needed to finish loading the page.

A request has to reach the server, and the reply has to come back. Cloudflare explains that data moves through internet fibre at almost 200,000 kilometres per second. That gives a simple best-case rule: about 1 ms of round-trip time for every 100 km of straight-line distance.

This is why one number from one city can mislead you. A 340 ms result across an ocean includes a large travel cost. You cannot safely subtract the physical floor and call everything left over server time, because the request also passed through networks and connection steps along the way.

The useful next step is to test the same endpoint from several regions. If nearby cities are fast and distant cities are slower, geography or routing is probably part of the answer.

• A website response: Usually fine. It is below Google's rough 800 ms TTFB target, but remember that one response is not the complete page load. In our current Google benchmark, the global typical response is about 82 ms. Google is a useful fast reference, not a target every site must match.
• A static file: Often slow, especially if the file should already be cached near the user. Our current Google Fonts CSS benchmark has a global typical response of about 60 ms. A 340 ms static-file request is a reason to check caching, file size, and delivery location.
• An API called once: Acceptable, but noticeable in a direct interaction. The current npm registry benchmark is about 30 ms globally, although a public registry and an API doing database work are not equal jobs.
• Several API calls in a row: Slow enough to matter. Four sequential calls at 340 ms each take at least 1.36 seconds. Calls made in parallel can overlap, so four calls do not always mean four times the wait.
• An AI or LLM API: Very fast. In our current OpenRouter provider benchmark, ranked typical time to first visible token ranges from 486 ms to 1,722 ms for the same open-weights model. At 340 ms, the first token would arrive faster than every ranked result in that test.

Typical means the middle result: half the measured requests were faster and half were slower. It is a useful headline, but people often notice the slow requests more than the typical one.

The legacy March 2026 Supabase benchmark used four regions. Its global typical response was about 47–48 ms. Amsterdam's typical result was 67 ms, but its slow tail reached 354 ms at p99. P99 means roughly 99 out of 100 measured requests were faster than that number.

A service that is usually fast but sometimes takes several seconds can feel worse than a slightly slower service that stays consistent. Look at both the middle result and the slow tail before deciding what to fix.

• One website response: Usually no. It is a reasonable result, though the rest of the page still matters.
• One interactive API call: It is acceptable, but the delay may be visible.
• Several API calls in sequence: Yes, because the waits add together.
• A cached image, font, or stylesheet: Usually yes. Check the cache and where the file is served from.
• The first token from an AI model: No. It is very fast.
• A request crossing an ocean: Maybe not. Compare regions before blaming the server.

1. Compare regions. Check whether 340 ms appears everywhere or only far from the server.
2. Open the timing breakdown. See how much time went to DNS, connecting, TLS, waiting for the first byte, and downloading.
3. Compare typical and slow-tail results. A large gap can point to cold starts, cache misses, busy connection pools, slow database work, or network changes.
4. Compare the first request with later requests. A slower first request can come from connection setup, an empty cache, or a sleeping service.
5. Measure the backend directly. If every region spends most of its time waiting for the first byte, inspect server and database timings instead of guessing from the outside.

The LatencyRadar examples above come from the benchmark snapshots published on each linked page. Current benchmarks use 20 requests from Amsterdam, San Francisco, Montreal, Singapore, and Tokyo. The older Supabase example is clearly labeled because it used four regions. Each benchmark page shows its measurement date and method.

The distance table is a physical lower bound calculated from straight-line distance and the speed of light in fibre. It is not a promise of the speed you will see on the public internet.