I've been evaluating Netskope ZTNA for a private web application used by our development team. The application itself is a straightforward React frontend with a Go API backend, both containerized and running in our Kubernetes cluster. Without ZTNA, average page load times hover around 800ms. After enforcing ZTNA access policies through the Netskope client, our load times have consistently jumped to 1.8-2 seconds, essentially a 2x slowdown. This is for users within the same geographic region as the cloud.
My configuration is, I believe, the standard "app-centric" setup. I've defined the application in the Netskope UI, created the access policy, and our users connect via the latest version of the Netskope client. The traffic is being steered through the nearest Netskope POP, as expected.
Before I engage support, I want to rule out a fundamental misconfiguration on my end. The slowdown appears to be in the initial connection establishment and the first few data packets. Here's what I've already validated:
* **The App & Backend:** No increase in CPU/memory usage, and no added latency when accessed directly via its internal ClusterIP service. The problem is only present for the ZTNA-routed path.
* **Client Settings:** We are using the recommended "best performance" steering configuration. Split tunneling is correctly configured for the application's public FQDN.
* **POP Selection:** Confirmed users are connecting to the optimal POP via the client diagnostics.
My primary hypothesis is that the TLS inspection or the additional proxy hop for every single API call (of which there are many on a page load) is adding a non-trivial overhead that the architecture of a single-page application amplifies. I am not seeing this level of degradation with simpler, document-style web apps.
Has anyone else pushed Netskope ZTNA for a modern, chatty SPA and done detailed performance benchmarking? I'm particularly interested in:
* Any service-specific tuning parameters in the Netskope UI that are not immediately obvious.
* Whether using a dedicated Private Access connector (on-prem or in-cloud) instead of the public POPs has measurably improved latency for you.
* If there are known limitations with HTTP/2 or WebSocket performance over the ZTNA tunnel that could cause this.
* How you structured your application or access policies to minimize round trips. For example, would bundling the API under a wildcard subdomain to reuse a single tunnel connection help?
I can provide anonymized traceroutes and client diagnostic outputs if it's useful, but I'm first looking for configuration review or architectural insights. A 1-second penalty for security is a tough sell to a team that uses this app all day.
Show me the benchmarks.
That initial connection hit sounds about right. I'm looking at a different vendor and their docs warn about exactly that, especially for apps making many small requests. Have you checked if your app is trying to establish new connections for each API call instead of reusing one? That would make the handshake penalty add up fast.
Connection pooling is a good point, but it's often only part of the story. The extra latency is usually a combination of factors.
Even with persistent connections, every packet is now taking a longer path: from user -> client -> Netskope POP -> your K8s cluster. That's an extra two network hops for each request/response cycle, not just the initial handshake. For an app making dozens of API calls to render a page, that RTT adds up fast.
You should instrument your app to see exactly where the time is going. Is it purely in the connection setup, or is there added latency on each data packet? That will tell you if it's a pooling issue or an inherent routing overhead problem.
Show me the query.
You're absolutely right to focus on connection reuse. That initial TLS handshake through the ZTNA tunnel can be costly, and if the app is spinning up a new connection for every single API call, the overhead multiplies.
I'd add that some client libraries have different defaults for connection persistence, and the behavior can even change between HTTP/1.1 and HTTP/2. It's a good first check for the OP.
But even with perfect pooling, there's still the baseline latency of that extra routing path for every single packet, which user318's point addresses. The combination is usually what bites you.
—daniel