SWG Memory and Performance Footprint: What an Endpoint Agent Should Actually Cost Your Devices

TL;DR. A modern endpoint secure web gateway agent should run in under 100 MB of RAM, add negligible CPU overhead, and deliver no measurable latency on the user's request path. Legacy cloud-proxy SWGs route every byte through a data center, adding 40 to 200 ms per request and burning device resources on a tunnel client just to get the traffic out.

The fastest way to find out what kind of SWG you actually deployed is to ask your help desk what changed after rollout. If the answer is "everyone's laptop got slower, video calls stutter on Wi-Fi, and we get tickets about Zoom every Monday morning," you didn't deploy a modern endpoint SWG. You deployed a tunnel client wrapped in a marketing brochure.

Performance is the part of the SWG conversation that nobody wants to put in their RFP, because every vendor swears their agent is "lightweight." Lightweight is not a metric. RAM, CPU, request latency, and battery impact are metrics. Let's go through what those should actually look like in 2026.

What a "lightweight" agent really means

The marketing answer is whatever the vendor tested on a clean lab machine. The real answer involves four numbers: resident memory, sustained CPU during steady-state browsing, request path latency, and battery draw on a laptop running off the wall.

A well-designed endpoint SWG agent should sit in the 50 to 100 MB RAM range. That includes the policy engine, the TLS inspection module, the certificate trust handling, the DLP classifier, and any local cache. The dope.security agent runs at under 100 MB. We measure it because we expect to be asked.

CPU should be near zero in steady state. Browsing the web, watching a video, sending email: none of that should register on Activity Monitor or Task Manager. The agent only does work when traffic is moving and a policy needs to evaluate. If your "SWG" is sitting at 3 to 5% sustained CPU while the user is idle, it's either logging more than it should or running a process loop you don't want to debug.

Request path latency is where the architecture choice shows up the most. We'll come back to it in a second.

Battery draw matters more than people give it credit for. A laptop user who loses 20% of their battery life to a security agent is a user who is going to file a ticket, and possibly file the agent.

Why legacy proxy SWGs are slower (the architecture math)

Cloud-proxy SWGs (Zscaler, Netskope, Cisco Umbrella's SWG component, legacy Symantec WSS, Forcepoint, Skyhigh) work by forcing every user request through one of the vendor's data centers. Your browser sends the request, the agent or PAC file routes it to a nearby POP, the POP decrypts it, applies policy, encrypts it again, and forwards it to the actual destination. Then it reverses the whole thing on the way back.

That's two extra network hops on every request, two TLS handshakes the original protocol didn't ask for, and a hard dependency on the vendor's POP geography. The math is unforgiving.

The standard added latency for a healthy cloud-proxy SWG is somewhere in the 40 to 80 ms range when the user is near a POP. It climbs fast when they're not. Users in regions with sparse POP coverage, like Southeast Asia, the Indian subcontinent, or anywhere inside China's Great Firewall, routinely see 150 to 400 ms added per request. Multiply that by every asset on a modern web page (call it 60 to 100 requests for a SaaS app load) and you get the user experience your help desk is hearing about.

Backhauling also burns endpoint resources before the latency even starts. The vendor agent has to maintain a tunnel client, manage cert trust, handle session state, and keep heartbeats alive with the POP. That work is what eats your RAM and CPU. The whole engine exists to get traffic somewhere else to be inspected, when you could just inspect it where it is.

Why agent-based SWGs are faster

Fly Direct, the architecture we built dope.security on, moves the policy engine onto the device. TLS inspection happens locally. URL filtering happens locally. Anti-malware checks happen locally. DLP classification happens locally. The agent applies policy, then the request flies direct to the destination. No POP. No backhaul. No tunnel.

The performance numbers fall out of the architecture, not from optimization heroics. About 4x faster than legacy proxy SWGs in head-to-head testing. Under 100 MB of RAM. No measurable latency added to the user request path, because there is no detour to add latency to. The user request goes straight to the internet the same way it would if no SWG were installed at all, except the policy and inspection happened a few milliseconds before it left the device.

That's also why dope.security works in China and other restricted regions where legacy SWGs struggle. There's no dependency on a vendor POP outside the country. The agent runs locally; the traffic goes where it was going anyway.

What this looks like in deployment

Performance isn't a benchmark you check on day one and forget. It's what your users feel for the next three years. Two customer reference points:

Outreach Health, a healthcare org with 5,000-10,000 employees across 34 offices, replaced a legacy SWG with dope.security and hit 99% of devices in a week. The follow-on metric was a 70% reduction in web access-related IT tickets in the first 90 days. That number is not about features. That number is about an agent that doesn't break user experience. (Read the case study.)

Greylock Partners, a Silicon Valley VC firm, replaced Cisco Umbrella in part because the SWG component still backhauled through Cisco data centers, adding latency for a distributed team. Time from first proposal to signed contract: 27 days. The decision turned on architecture, not on a sales discount.

The questions to ask your current SWG vendor

This week, open a terminal on a user's machine and check what the SWG agent is actually using. Look at memory resident size. Look at CPU at idle. Look at network throughput while a simple page loads. Run a couple of curl tests with timing to a few common destinations and compare with the agent enabled versus disabled (on an isolated, controlled host). Look at the gap.

If you have to ask your account team for those numbers, they'll send you a "lab condition" deck that bears no resemblance to a real user's M2 MacBook running Slack, Chrome, Zoom, Outlook, and a couple of Electron apps at once. Measure it yourself.

If the gap is uncomfortable, the path forward is straightforward. Switch to an endpoint SWG that runs on the device, not on the vendor's data center. Start a free trial of dope.security on a handful of test devices, watch the resource graphs, and run the same latency tests. The architecture math will do the rest.