Performance architecture for a high-traffic web app

Context

A content-heavy web application had performance work scattered across tickets: image compression, a few code-splits, occasional caching. The product still felt slow on the routes that mattered.

Problem

The timing was a symptom. Waterfalls, over-fetching, and client-side work on pages that did not need it were producing the delay. Optimizing components in isolation did not change the request shape.

Constraints

• Confidential engagement
• No invented metrics
• Changes had to land without a redesign
• The team needed to keep shipping while the investigation ran

Approach

We started with the network and the rendering path, not the component tree. Which work was required for first paint? Which data could wait? Which JavaScript existed because it was convenient, not necessary?

Architecture

Caching, rendering, and data ownership were treated as one system. Static where the page was static. Server-rendered where the data was personal but cacheable. Client code only where the browser actually had work to do.

Result

The work produced a clearer performance model for the team: budgets on key routes, fewer request chains, and a shared language for when a change was architectural rather than cosmetic.

What we learned

Performance problems that survive a round of "quick wins" are usually architecture. Treat the timing as evidence, then change the system that created it.