The Latency Math: What a Cloud-Proxy SWG Really Costs Your Users
.jpeg)
The short answer
A cloud-proxy Secure Web Gateway adds latency to every request because your traffic makes a detour to a vendor point of presence before reaching its destination. Near a point of presence that detour is roughly 40 to 80 ms. Far from one, or through a congested or filtered path, it climbs to 150 to 400 ms. That tax lands on every single request, all day.
On-device inspection removes the detour, because inspection happens on the endpoint and traffic goes straight to its destination. There is no network hop to pay for. We cover the architecture behind this in the SSE architecture guide.
Where the milliseconds go
Follow a single request through a cloud proxy.
- The device sends the request to the vendor's nearest point of presence.
- The point of presence decrypts the TLS session and inspects the contents.
- It opens a fresh connection to the real destination and forwards the request.
- The response comes back to the point of presence.
- The point of presence re-encrypts and returns it to the device.
Every step after the first exists only because inspection lives somewhere other than the device. The round trip to and from the point of presence is the tax. It is small when the user is close and the node is healthy. It grows with distance, congestion, and any filtering in the path. See what is backhauling.
Now the on-device path:
- The device inspects the request locally.
- The request goes straight to its destination.
No detour, because there is no remote inspection point to visit.
The tax by user location
| User location | Cloud-proxy detour (typical) | On-device (Fly Direct) |
|---|---|---|
| Near a point of presence | ~40 to 80 ms added | No network detour |
| Far from a point of presence | ~150 to 400 ms added | No network detour |
| Behind a filtered / restricted network | Highly variable, can fail | No remote hop to fail |
Cloud-proxy latency figures are representative ranges from ThousandEyes and vendor documentation, not a single benchmark. The point is the shape: the detour is real and grows with distance.
Why a few hundred milliseconds matters
It sounds small until you multiply it. A modern web page makes dozens of requests. An app in active use makes thousands over a session. When each one carries an extra 100 to 300 ms, the compounded effect is an internet that feels slow, and it feels slowest for exactly the people you most need productive: remote and international staff. See SSE for remote and hybrid workforces.
This is also why "our internet feels slow" is so often an architecture symptom, not a bandwidth one. Bandwidth is about capacity. This is about a detour on every request that no amount of bandwidth removes.
The on-device number
dope.security inspects on the device, so it adds no network detour. The agent runs in under 100 MB of RAM and delivers up to 4x the performance of legacy proxy SWGs. The approved way to say it: on-device inspection removes the backhaul tax, and dope.security runs up to 4x faster than legacy proxy SWGs. See on-device SWG: how it works.
Measure it yourself
You do not have to take the math on faith. The fastest honest test is to measure your own round-trip latency and compare the detour against direct inspection. Run the Fly-Direct Speed Test, pick where your people work, and watch the difference by user location. Then run dope.security next to your current SWG for a week and check the numbers on real traffic.
Frequently asked questions
Does a Secure Web Gateway slow down the internet? A cloud-proxy SWG adds latency because traffic detours to a point of presence for inspection. An on-device SWG inspects locally and adds no network detour, so users do not feel it as lag.
How much latency does a cloud proxy add? Roughly 40 to 80 ms near a point of presence and 150 to 400 ms far from one, applied to every request. Through filtered or congested paths it is higher and less predictable.
Why does my SWG feel slow only for some users? Because cloud-proxy latency scales with distance from a point of presence. Users near a node feel little; remote and international users feel the most.
How does on-device inspection avoid latency? It inspects on the endpoint, so there is no remote inspection point to route to and no detour to pay for. dope.security runs up to 4x faster than legacy proxy SWGs.
See it in action
Want to measure the backhaul tax on your own traffic? Run the speed test, then start a free trial or book a 20-minute demo at dope.security.
.jpeg)
