Internet speeds vary wildly across the world. In my cushy Oakland, California office, the Internet is zippy and every page loads within a couple seconds. On a recent trip to Indonesia, I got three, maybe four websites to load over my myXL E connection. Ultimately, websites I used to visit with frequency were completely unusable. I stopped going entirely. The culprit? HTTP/1.1 and all your goddamn JavaScript.
First, HTTP/1.1. It’s outdated, and everyone knows it. Google came up with the SPDY protocol which some webservers added support for and some sites used, but it didn’t catch on. Over time, it morphed into today’s specification for HTTP/2, a much needed iteration of the HTTP protocol every website uses today to serve you its content. It is much faster, for a variety of reasons. See Mark McDonnell’s excellent write-up of all the benfits of HTTP/2 for a holistic look at the best parts of HTTP/2.
If I had to pick a favourite part, it’d be that HTTP/2 uses a single, persistent connection to each host. All those other resources, like JavaScript, CSS, and images, served from the same host can be sent down one connection. This reduces overhead dramatically, especially for TLS connections which take a considerable amount of time to perform the handshake. In my view, this is the biggest win.
Run a website? Support HTTP/2 today! Most web browsers now support it out of the box, so do yourself and your visitors on slow connections a favour and upgrade!
Second, all your goddamn JavaScript. Holy crap, what is the web coming to? Visit wired.com and open the web inspector. You’ll see a disturbing 57 requests for JavaScript alone. FIFTY-SEVEN REQUESTS. As a user, I go to wired.com and I make ONE request and I have an expectation that it will be fast. Little do I know that my favourite websites ship with dozens of additional JavaScript resources which much be loaded individually, each using up its own connection, negotiating TLS, then receiving either a redirect (which has to run the entire process again) or, finally, some content. In total, wired.com requests 276 resources on load, JavaScript contributing a fifth of the load. Of the 10 megabytes for a single page, JavaScript contributed 3.5 MB, or 35% of the total bytesize of the page. Heavy.
Take a few different high-traffic websites and you’ll see a disturbing similarity: advertisements are the worst in this regard. You can rationalize to your Product Manager a few JavaScript files, maybe 1 or 2 megabytes. But then Finance calls and says you’re moving to an ad-supported platform. You diligently hook up the ad network code to every page, ensure it’s pixel-perfect and ship it. All of a sudden, your site bloats from 4 JavaScript files to 15 or 20. Every visitor’s browser and network connection becomes absurdly overloaded and many of your users on slow connections simply don’t return. You start making money on every request, but fewer people are reading the content because the site takes so long to load and render. Your Finance team will be happy, but it’s a loss for every other department.
Don’t get me started on JavaScript-only websites. Ember, Angular, etc. are all curses on all our houses.
If all you care about are folks in rich areas in first-world countries, then don’t do anything. You’re all set!
If you care about folks on slow connections, support HTTP/2 and reduce the resources which your pages load. Most of Asia, Africa, and South America, and many in Europe and North America, too, will thank you.