The argument changed because the browser changed
Frontend debates used to revolve around which framework was fastest in isolation. That was always an incomplete question, but it became even less useful as frameworks converged on similar capabilities. Modern browsers are fast, build tools are sophisticated, and every major ecosystem offers some form of server rendering, code splitting, caching, and progressive loading.
The larger performance differences now come from architecture and discipline. A lightweight site can be slow when it ships oversized images and third-party scripts. A complex application can feel fast when it renders useful content early, prefetches intelligently, and keeps interaction work under control.
Measure what the user experiences
Time to first byte, Largest Contentful Paint, Interaction to Next Paint, layout stability, and resource waterfalls provide more actionable information than framework reputation. They answer different questions: how quickly the server responds, how soon the main content appears, whether interactions stall, and whether the page moves unexpectedly while loading.
The most useful performance work starts with real-user monitoring. Laboratory tests are excellent for repeatable comparisons, but field data reveals slow devices, distant networks, ad blockers, corporate proxies, and other conditions developers do not reproduce locally.
JavaScript is a budget, not a moral issue
It is easy to turn web performance into a philosophical argument about whether JavaScript is good or bad. A better approach is to treat client-side code as a budget. Every script has download cost, parse cost, execution cost, memory cost, and maintenance cost. If a feature earns those costs, ship it. If a static HTML interaction can do the same job, use the simpler option.
This framing also helps teams make product decisions. A conversion widget that adds meaningful revenue may justify additional code. A decorative animation library used for one transition probably does not. Performance improves when the tradeoff is visible instead of ideological.
Images are still the easiest win
High-resolution photography can dominate page weight even on technically elegant sites. Responsive image sizes, modern formats, lazy loading, explicit dimensions, and sensible compression remain some of the highest-return optimizations available. They require little architectural upheaval and improve both speed and bandwidth usage.
Teams should also question the image itself. A full-bleed hero can look great, but it may not need a 5000-pixel source file. Product screenshots can often be cropped tightly. Decorative imagery below the fold can load later. The cheapest byte is still the one never sent.
Server rendering is a tool, not an automatic win
Server rendering can improve initial content delivery and search visibility, but it can also introduce complexity, duplicated work, and expensive hydration. Static generation can be excellent for content that changes infrequently. Client rendering can be perfectly appropriate for authenticated tools where the shell loads once and the user spends hours interacting.
The best architecture follows the page. Marketing pages, documentation, dashboards, editors, and streaming interfaces have different performance needs. A single framework may support all of them, but the rendering strategy does not have to be identical.
Performance is a product habit
Fast sites rarely stay fast because of a one-time optimization sprint. They stay fast because teams watch budgets, review regressions, compress media, challenge new third-party tags, and include performance in release criteria. The important cultural shift is making speed part of product quality instead of a cleanup task.
The framework wars were useful because they pushed ecosystems to improve. The next phase is more practical: ship the experience, measure it, and optimize the bottleneck the user actually feels.