HTTP Parallelism, Push, “Preload”, And Why Markup Bloat Is The Enemy

Back in 2020 I wrote about how I thought HTTP 2.0 Push and SPDY might be placebo, but it turned out the problem was that the client I was working for just had a garbage website. This is a common affliction as systems like HTTP 2 push, server side result caching, CDN’s, even simple minification and gzip compression are oft blanket applied without thought; in the blind hope that it will be a magical panacea. As opposed to what they really are, tools that require a degree of knowledge, thought, and planning to apply to their full potential.

Quite often in fact they make zero improvement whilst costing you money and time, all because what’s really going on is someone trying to sweep the real problems — massive code bloat, failure to leverage caching at the construction level, copypasta development with idiotic frameworks — under the rug.

There are a lot of just plain bad choices developers make from the start, and most of that stems from simply failing to understand how browsers even load pages in the first place! If you are doing web development professionally — front end or back end — understanding how pages load is a must-have!

Parallelism Delayed

One of the biggest strengths of HTTP and how servers and browsers talk to each-other is their ability to perform more than one file request at a time. Most browsers limit you to six to eight simultaneous connections — and if the server or client are hitting up…