Your claims-adjuster suite creates hosted browser sessions instantly, yet every tunnelled navigation crawls. What explains the split?

## Two paths, and only one is tunnelled It is tempting to picture a tunnelled run as "everything goes through the tunnel". It does not. A hosted browser session has traffic moving on two distinct paths, and confusing them makes the timing profile look inexplicable. - **The control path.** Your harness talks to the provider's remote endpoint over the public internet: it creates the session, sends each command, and reads each result. The relay does not sit on that path, which is why session creation for an insurer's claims-adjuster suite can feel instant while the run that follows does not. - **The content path.** The rented browser, having been told to open an internal hostname, has to actually fetch it. Those requests are the ones carried to the relay inside your network, performed from there, and returned. Two different machines originate the traffic on these two paths — your harness on one, the provider's browser on the other — and they are billed, routed and slowed independently. Which of the browser's requests take the relay path and which do not is decided by the routing arrangement rather than by the relay itself; the point here is simply that the two paths exist and are not the same path. ## Why the cost multiplies per request A single page is rarely a single request. The document arrives, and then the browser discovers stylesheets, scripts, fonts, images, and then the application starts issuing its own calls for claim records, adjuster lookups and reference data. Every one of those that travels the content path pays the same added journey: provider network to relay, relay to internal service, and the whole way back. That produces a characteristic shape: 1. **The slowdown scales with request count, not payload size.** A page that pulls many small assets is hurt far more than one that pulls a single large file, because the added cost is per journey rather than per byte. 2. **Interaction feels worse than navigation.** A form in the claims-adjuster tool that validates a field against the server on every keystroke turns a single interaction into a burst of tunnelled journeys. 3. **The effect compounds with anything serialised.** Requests the application deliberately waits on — a token refresh before a data call, a redirect chain on login — stack their added journeys end to end instead of overlapping them. None of this is a defect in the relay. It is the arithmetic of putting an extra leg on a journey that was already being made many times. ## The relay is a funnel as well as a hop Latency is the part people predict. The part they do not is that a relay is a process, running on a machine, with finite capacity for concurrent work — and every tunnelled request from every live session converges on it. As a suite widens, that convergence, not the individual hop, often becomes the dominant effect. The signature differs from plain latency: - Plain latency is roughly constant per request and shows up even on a quiet run. - Funnel pressure appears only when sessions run in parallel, worsens as width increases, and shows as variance rather than a steady offset. The practical reading is that "we measured the tunnel overhead on a single run" does not predict what a wide run will experience, because the two effects have different causes. ## What this does to a suite's assumptions | assumption from a local run | what a tunnelled run does to it | |---|---| | a wait threshold tuned against the developer machine | now too tight, and fails on request-heavy pages first | | "the app is slow" as the reading of a timeout | ambiguous: the content path is on the timing, the control path is not | | timings comparable between runs | comparable only while the relay's host and load are comparable | Two adjustments follow, and they are cheap: - **Separate your budgets.** Time session creation apart from page interaction. A run where creation is flat and interaction has doubled is telling you which path changed. - **Prefer waits on application state over fixed durations.** A condition that waits for the claim record to appear survives a slower path; a fixed pause tuned against a direct run does not. ## The honest boundary of the claim Say what is observable and stop there. What a tenant can see is that requests taking the content path are slower and that the effect scales with their number. What a tenant cannot see, and should not assert, is how the provider's end of the connection is implemented, what it does with a request internally, or where the time is actually spent on the far side. The useful mental model is the path, not the internals: identify which leg a given piece of traffic travels, and the timing stops being mysterious.