Delta Air Lines · Performance Architecture
Making a 22MB application work at 35,000 feet.
The problem
An airline Wi-Fi portal doesn't operate like a typical web application. Passengers connect through satellite networks where latency is high, bandwidth is limited and network conditions can change quickly. The portal's initial frontend bundle had grown to roughly 22MB, with load times approaching 6 seconds. For a passenger waiting to connect to Wi-Fi, that was simply too slow.
What I changed
I approached the problem at the architecture level rather than trying to optimise individual files. The first step was breaking the monolithic bundle into route-specific content so that passengers only downloaded what they needed. The second was introducing a Service Worker caching strategy that could eliminate repeat network requests altogether.
The trade-off
Aggressive caching cuts load time, but it also risks serving passengers a stale version of the portal after a release. I designed deterministic cache invalidation tied to the release pipeline, so the performance gains didn't come at the cost of freshness.
Architecture
- User
- Route-specific content
- Optimised bundle
- Service Worker cache
- Satellite network
Result
22MB → 5MB
6s → 3s
−18% bandwidth
−20% regression test time
The biggest lesson was that web performance isn't always a frontend problem. Sometimes the network itself is part of your architecture.