A trading analyst in London once told me his morning ritual was waiting ninety seconds for Bloomberg to load after the company rolled out a new secure web gateway. The vendor’s deck promised “single-digit millisecond added latency.” His stopwatch said otherwise. The gap between slide and reality is where this post lives.
Independent benchmarks are the only way to know what a secure web gateway actually costs you in user-perceived performance. Vendor numbers are generated in controlled labs with ideal routing. Yours will not be.
This is a step-by-step guide to running a secure web gateway latency benchmark that your CFO, your network team, and your end users will trust.
Why Vendor Latency Numbers Lie
Every secure web gateway vendor publishes a latency figure. Most of them are technically true and operationally useless.
The test beds run from one data center to another, with the SWG POP picked for proximity. Your real users sit in Austin, Singapore, and a dozen places nobody chose on purpose. When a cloud SWG forces traffic through its nearest ingress, you pay for geography the benchmark deck never mentioned.
On top of that, vendors measure added latency under low load with small responses. Real traffic has TLS handshakes, streaming chunks, and the occasional 10 MB JSON payload. Throughput under stress is what matters, and it almost never appears in marketing PDFs.
Vendor latency is the latency the vendor wants you to see. Your users feel the one your architecture actually produces.
Benchmark Setup: Tools and Baselines
A serious benchmark has three layers: a clean baseline, the gateway under test, and enough sample size to average out noise. Skip any of the three and you are measuring luck.
Step 1: Lock Down a Baseline
Before any gateway is in the path, record the following from the exact machines your users will run on:
- curl -w timing for DNS, connect, TLS handshake, and total time against ten representative URLs.
- Sustained throughput with iperf3 against a known server in your primary region.
- TTFB (time to first byte) from a headless browser load of your three most-used SaaS apps.
Run these at three times of day for five business days. You now have a baseline distribution, not a single number.
Step 2: Pick Representative Endpoints
Do not benchmark against example.com. Use a mix of endpoints that mirror your actual egress:
- A heavy SaaS app (Salesforce, Google Workspace).
- A streaming-heavy page (internal video portal, YouTube for corporate learning).
- A small-object-heavy page (news site, dashboard with many XHR calls).
- A large file transfer (a 50 MB download from your CDN).
Step 3: Instrument the Gateway Path
Install the agent, enable the cloud POP, or route DNS as the vendor recommends. For a modern secure web gateway with on-device inspection, the agent is usually a Jamf or Intune deployment and under 100 MB of RAM. For a cloud SWG, confirm the POP your traffic is hitting from each test site.
Re-run the exact same tests from Step 1 with the gateway in the path. Change nothing else.
What to Measure (TTFB, Handshake, Sustained Throughput)
Latency is not one number. Your benchmark has to capture at least these four.
TLS Handshake Time
A legacy proxy that terminates TLS in the data center adds one to two extra round trips. An on-device architecture that does not route traffic through a vendor POP adds almost none. Measure handshake time with curl -w “%{time_appconnect}” and compare against baseline.
Time to First Byte
TTFB captures the full round trip for the first byte of a real page response. It is the closest single number to user-perceived latency. Track the p50, p95, and p99. The p99 is where angry Slack messages come from.
Sustained Throughput
Proxies that downgrade HTTP/2 to HTTP/1.1 crush throughput on asset-heavy pages. Measure with a large file download and with a browser-based synthetic that counts bytes over time. If throughput drops by more than 15 percent, the gateway is rewriting connections in a way the vendor probably did not disclose.
Connection Count Under Load
Open 100 concurrent connections to a test server and measure how many complete in under one second. A weak gateway bottlenecks here silently.
Sample Benchmark Table
Use this template for your report. Fill the rows from your runs.
| Metric | Baseline | Cloud SWG | On-Device SWG |
|---|---|---|---|
| TLS handshake p50 (ms) | |||
| TTFB p95 (ms) | |||
| Throughput (Mbps) | |||
| Concurrent connections /sec | |||
| User-perceived page load (s) |
Interpreting Results Across Architectures
Raw numbers only matter if you know what architecture produced them.
Cloud POP SWGs
Expect added latency proportional to the distance between the user and the POP. If your user is in Phoenix and the POP is in Dallas, you are paying a round trip on every request. Cloud SWG vendors can soften this with regional POPs, but you will still see variance tied to user location.
On-Device SWGs
On-device inspection removes the vendor POP hop. Traffic goes straight from endpoint to destination, with classification happening locally. Expect latency numbers that look almost identical to baseline. A good agent uses native HTTP/2 and Apple Silicon acceleration where available, so the added overhead is close to the noise floor.
Hybrid Architectures
Some vendors inspect on-device for HTTPS and backhaul policy decisions to the cloud. The latency math here depends entirely on how much of the decision happens locally. Ask the vendor to show which operations cross the wire and which do not. If the swg agent calls home on every request, you are back to a cloud-POP latency profile.
FAQ
What is a secure web gateway?
A secure web gateway is a security control that inspects outbound web traffic to enforce acceptable use, block malware, and stop data loss. Modern versions run on-device with local SSL inspection instead of forcing traffic through a cloud proxy.
What is the difference between a VPN and a SWG?
A VPN encrypts traffic between an endpoint and a network, usually to reach internal resources. An SWG inspects outbound web traffic for security policy regardless of where the user sits. VPNs focus on access, SWGs focus on egress control.
Is a secure web gateway the same as a proxy?
Every SWG uses proxy techniques, but not every proxy is an SWG. A modern SWG layers content comprehension, DLP, and category-based policy on top of the proxy. A plain proxy just forwards traffic. A platform like dope.security folds DLP, SSL inspection, and shadow AI blocking into a single endpoint agent.
How do I benchmark SWG performance fairly?
Record a baseline without the gateway, run identical tests with it in the path, and measure TLS handshake, TTFB, throughput, and concurrent connections. Use the user’s real location, not a lab machine next to the vendor’s POP.