In many projects, performance is only raised before launch. By then the architecture is fixed and the only options are compressing images and merging requests. The effective approach is to set a performance budget at the start and write it into acceptance criteria.
Define what fast means
Opening quickly is not a standard. We define measurable metrics with the team: first contentful paint, largest contentful paint, interaction latency, and usability of key pages on slow networks.
- Critical first-screen content does not depend on third-party scripts;
- First-screen images have explicit dimensions and priority to avoid layout shift;
- Non-critical modules load lazily, leaving the main thread for interaction.
SSR is not a silver bullet
Server-side rendering improves first contentful paint, but chained data requests can slow the server response. We parallelize independent requests and add timeouts and fallbacks for external services.
The point of a performance budget is not to make every page perfect, but to give the team a shared ruler for trade-offs.
Measure continuously
Performance degrades naturally as features grow. Connect key metrics to daily monitoring and compare against a baseline after each iteration, so speed becomes a maintained state rather than the result of a one-off optimization project.