Latency vs. User Experience: Why Milliseconds Decide Whether Visitors Stay

Introduction

Latency is the silent tax on every website. It is the time that passes between a visitor asking for something and actually receiving it, and unlike a slow feature or an ugly layout, most people never consciously notice it — they simply feel that a site is "sluggish" and leave. In this article we look at what latency really is, how it translates into user experience, where the milliseconds are spent, and what you can practically do to claw them back.

What we mean by "latency"

When engineers say latency they usually mean the round-trip time for a single request. But the number your users actually feel is the sum of many smaller latencies stacked on top of each other. A single page load is rarely one request — it is the HTML document, then the stylesheets, the fonts, the JavaScript bundles, the images, and often a handful of API calls after that. Each of those has to travel across the network, be processed by a server, and travel back.

The most common components of that budget are:

• DNS resolution — turning example.com into an IP address (can be tens of milliseconds on a cold lookup).
• TCP connection — the three-way handshake before any data flows.
• TLS handshake — negotiating encryption keys, one or two additional round trips depending on TLS version.
• Time to first byte (TTFB) — how long the server takes to start sending the response after receiving the request.
• Content download — the actual transfer of bytes, bounded by bandwidth and payload size.

Crucially, several of these are dominated by the distance between the user and the server, not by how fast your code is. Light in fibre travels at roughly two-thirds the speed of light in a vacuum, which means a round trip between, say, London and Sydney has a hard physical floor of well over 200 milliseconds no matter how good your hardware is. You cannot optimise your way past physics — you can only move the content closer.

How latency turns into lost users

The relationship between latency and behaviour is not linear, and it is far less forgiving than most teams assume. Study after study across e-commerce, search, and media has found the same pattern: as pages get slower, engagement falls and abandonment rises, and the effect compounds. A widely cited rule of thumb from large-scale experiments is that every additional 100 ms of latency measurably reduces conversion, and that once a page crosses a few seconds to become interactive, a large share of visitors have already given up.

The human perception thresholds are well established in interface research:

Response time	How it feels to a user
Under ~100 ms	Instant. The result feels like a direct consequence of the action.
~100 ms – 300 ms	Fast, but a subtle delay is perceptible on interaction.
~300 ms – 1 s	Noticeable lag; the user stays focused but starts to feel the machine working.
Over ~1 s	Flow is broken; attention drifts and the user may start doing something else.
Over ~3 s	A large fraction of visitors abandon the load entirely.

This is why latency is a user-experience problem before it is an engineering one. A 400 ms API call in isolation looks fine on a dashboard, but if it sits on the critical path of the first paint, it is the difference between a page that feels alive and one that feels dead.

Latency is not the same as bandwidth

A common and expensive misunderstanding is to treat "make it faster" as "buy more bandwidth". Bandwidth is how much data you can move per second; latency is how long it takes for the first bit to arrive. Upgrading a connection from 100 Mbps to 1 Gbps does almost nothing for a page made of many small requests, because each request is still waiting out its own round trips. Past a fairly modest point, adding bandwidth stops improving load times at all, while reducing latency keeps paying off. For most modern sites, latency — not throughput — is the binding constraint.

Where the milliseconds hide

Distance to the origin

If every request has to reach a single origin server in one region, then every user outside that region pays a distance penalty on every asset. This is the single biggest lever for most sites, and it is why edge caching and geographically distributed points of presence exist: serving a cached response from a node 20 ms away instead of an origin 200 ms away is a 10x improvement that no amount of backend optimisation can match.

Connection setup overhead

Every new HTTPS connection pays for a TCP handshake and a TLS handshake before the first byte of real data. Reusing connections (HTTP keep-alive), enabling HTTP/2 or HTTP/3, and using modern TLS (which cuts handshake round trips) all shave real time off the front of every interaction. A reverse proxy that pools upstream connections and terminates TLS efficiently removes a surprising amount of this cost.

Server processing time (TTFB)

This is the part fully within your control: how long your application takes to produce a response. Slow database queries, synchronous calls to third-party services, unbatched work, and cold caches all inflate TTFB. The best fix is often to not do the work at all on the hot path — cache the result, precompute it, or serve it from the edge.

Payload size

Large, uncompressed responses take longer to transfer and longer to parse. Compression (gzip, brotli), right-sizing images, and trimming unused JavaScript reduce both the download time and the CPU spent decoding on the client — which matters most on the low-powered mobile devices that make up much of real-world traffic.

What actually moves the needle

In rough order of impact for a typical site:

• Serve cacheable content from the edge. Put a caching reverse proxy or CDN in front of your origin so repeat and shared responses are answered close to the user. This attacks the distance penalty directly.
• Cache aggressively and invalidate deliberately. A high cache-hit ratio means most requests never touch your slow origin at all. Design your cache keys and purge strategy so you can cache confidently.
• Cut round trips. Enable HTTP/2 or HTTP/3, keep connections alive, use modern TLS, and avoid redirect chains — each redirect is a full extra round trip before anything useful happens.
• Shrink the critical path. Compress responses, defer non-essential scripts, and make sure the first paint does not depend on your slowest API call.
• Route to the fastest healthy origin. When you do have to reach the origin, performance-based routing and health checks keep you off slow or degraded backends.

Measuring what your users actually feel

Averages lie. A mean latency of 120 ms can hide a tail where 5% of your users wait two seconds — and those users churn first. Always look at percentiles (p75, p95, p99) rather than averages, and prefer real user monitoring (data from actual visitors) over synthetic tests from a single fast data centre. The Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — are a good, user-centred starting point because they measure perceived experience, not raw server numbers.

Conclusion

Latency is not a vanity metric. It is one of the most direct levers you have on engagement, conversion, and retention, because it maps onto something visceral: the feeling that a site respects the visitor's time. The good news is that the largest gains usually come from the same handful of moves — cache close to the user, cut round trips, and keep the critical path short. A well-configured caching reverse proxy sitting between your users and your origin does most of this heavy lifting at once, which is exactly the problem ARC2 Proxy is built to solve.