The idea
Before application data can flow, a browser may need to resolve a hostname, establish a transport connection, and negotiate encryption. A fresh connection also begins cautiously while the network learns how much traffic the path can handle. These steps are valuable, but repeating them unnecessarily turns setup into user-visible delay.
Connection reuse lets later requests benefit from work already done. That does not mean “put everything on one server” in every architecture. It means hostname boundaries and request patterns have performance consequences. Splitting a page across many origins can force the browser to build and warm several separate roads.
Make it concrete
A checkout page fetches its interface from one origin, icons from a second, a tiny configuration file from a third, and its API response from a fourth. The payloads are small, yet a first-time mobile visitor pays setup costs for every origin. Serving the configuration with the application—or fetching it earlier over an existing connection—can remove an entire setup sequence.
Count origins, not just requests
In a network trace, group critical requests by origin and check when each connection begins. Ask whether a new origin provides a real benefit such as independent security, ownership, or caching. If not, consolidation or earlier connection setup may reduce delay. Measure the result: modern protocols and browser behavior make intuition alone unreliable.
Try it
Count the origins contacted before your page becomes usable. Choose one and write down the architectural benefit it provides. If you cannot name one, test whether that request can use an existing path.