For years, a lot of front-end performance advice has been shaped by the cost of each request.
Combine files, use sprites, reduce round trips and avoid making the browser ask the server for too many separate things. That advice made sense because HTTP/1.1 made lots of requests expensive in ways developers had to work around. A website with many small assets could feel slower than it needed to be, so we learned to bundle, merge and squeeze files together.
HTTP/2 changes that conversation. It does not remove the need for performance work, but it does make me question some of the habits that became automatic. If the browser and server can communicate differently, then the best project structure may not be the same structure we used when every request felt like a penalty.
The Old Habits Still Made Sense
I would not criticise the old approach too quickly.
CSS sprites, combined JavaScript files and careful asset loading solved real problems. They helped older browsers and older connections. They made projects faster in a world where every extra request could slow the page noticeably. Many of those decisions were practical responses to the web we were actually building for.
The problem is that old performance rules can survive after the reason for them starts changing. A build process might combine every script into one large file because that was once the safest answer. A site might use sprites for icons even when individual assets would be easier to maintain. A developer might avoid splitting files because too many requests used to be a clear warning sign.
HTTP/2 makes me think those decisions need to be revisited rather than repeated automatically.
Smaller Pieces Can Be Easier To Maintain
One thing I like about modern front-end work is the move towards smaller, more understandable pieces.
A component has its own CSS. A module has its own JavaScript. A template loads what it needs rather than dragging every possible interaction onto the page. That kind of structure is easier to reason about during development, but older performance advice sometimes pushed in the opposite direction. Everything was combined because the network made separation expensive.
With HTTP/2, separation starts to look less wasteful in some cases. The browser can handle multiple requests more efficiently over the same connection, which means the maintenance value of smaller files deserves more attention. That does not mean splitting everything for the sake of it. It means the trade-off is no longer as simple as fewer files always being better.
Performance Is Still Not Automatic
The danger is assuming HTTP/2 solves poor front-end decisions by itself.
It does not make an oversized image smaller. It does not stop a tracking script from blocking the page. It does not make a badly written JavaScript file cheap to parse. If the site sends too much work to the browser, the browser still has to do that work. The protocol can improve how assets move across the network, but it cannot fix every decision inside those assets.
That distinction matters because performance work is often misunderstood. A faster transport layer helps, but the page still needs to be designed with restraint. The fastest request is still the one the browser does not need to make, and the easiest script to parse is still the one that was never added.
What I Would Change In Projects
The practical change for me is not to throw away existing build habits.
It is to question them. If files are being combined, is that still helping the project or just continuing an old rule? If icons are in a sprite, is that making maintenance easier or harder? If every page loads the same large JavaScript bundle, would a more targeted approach make more sense now?
Those questions are useful because they connect performance with maintainability. A project should be fast, but it also needs to be understandable when someone returns to it later. HTTP/2 gives developers more room to balance those concerns instead of making every asset decision revolve around request count alone.
What I Took From It
HTTP/2 feels like a reminder that performance advice has a shelf life.
Some principles remain stable. Send less unnecessary work, serve files efficiently and respect the visitor’s connection. Other habits need to be re-examined as the platform changes. The web we build for in 2015 is not the same web we built for five years ago.
That is why I find this shift useful. It does not give developers permission to stop caring about performance. It gives us a reason to care about it more precisely.