5G is Making the Web Slower

Alright, I made you click. So hear me out…

5G is here. Its little icon is starting to appear in the top corners of phone screens throughout the US. If you’ve used it already, you may have observed that it doesn’t feel a whole lot faster than 4G, and I concur. Reportedly, these early days of 5G are hampered by transitioning infrastructure, but as it matures 5G is predicted to improve network speeds dramatically. Providers are predicting download speeds from 150-200Mbps on average, and I’ve even seen claims that we could theoretically soon see speeds of 5gigs per second. With speeds like that, you could download the entire discography of Friends AND ceremoniously drag and drop it in your trash bin in the time it would normally take to load a webpage today. The future is amazing!

Oh! And it’s not just bandwidth that’ll change. Latency will improve under 5G as well, and latency has been one of the web’s notorious performance bottlenecks for some time. That means that the time we spend connecting to a website in the first place could drop to essentially zero. Again, amazing!

Alright, so network performance stands to get way faster very soon. That should alleviate the web’s performance problems right?

Well, it should, but I don’t think it will. At least not soon. If recent trends continue, 5G will make web performance worse, not better, for the average person.

Worse? How could this be?

Faster networks really should fix our performance problems, but so far, they are actually making them worse. This is because historically, faster network speed enables developers to deliver more code to users… in particular, more JavaScript code.

During the years 2014-2018(TODO: check), 3g and 4g coverage spread to x% of the world. During that same time frame, the average JavaScript transfer size increased by 70% (TODO: check), from Xmb to Xmb(TODO: check). Sure, sites became a lot more interactive during that time too, and that tends to mean more JavaScript, but complexity can’t explain all of it: even in just the past couple of years JavaScript transfer size has increased by 50%. Also, the weight isn’t necessarily tied to the fancy, appy UI parts of our sites anyway, as it’s mostly invisible third party stuff. The average 3rd party JavaScript size increased by X%(TODO: check) in the past X years(TODO: check).

Okay, but if it downloads fast enough on these newer networks… what’s the problem? Well, compared to the other kinds of code we are delivering, JavaScript is uniquely costly for its weight.

On the average device, 200kb of transferred JavaScript can take 6 or more seconds to parse, and that’s after the time it takes to download the code over the network. Before you think that sounds like a lot of JavaScript, note that on average, we are delivering almost twice that much. And during the time that JavaScript is parsing, visible but not interactive, or entirely blank. Both scenarios are bad, and the worst part is, many of us who work on the web may not even notice this problem ourselves.

“Looks good on my phone”

Developer Convenience can easily lead us astray. The average device in the US is not the brand new iPhone with the notch at the top that many of us may have in our pockets. The average device even in the US costs about $130. It could be an iPhone, but it’s an older one. It’s most likely to be a mid-range Android, with a relatively underpowered processor. Here are the best-sellers on Amazon as of last friday:

[image]

Again, these are the phones we should be paying attention to. Even if they’re on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential improvements of 5G moot.

And what about folks without 5G?

5G coverage requires big infrastructure changes, so it’s going to arrive in affluent, developed areas first. Rural and developing regions of the world are less likely to see it as soon. That means folks in non-5G regions not only experience the web on their relatively-underpowered devices, but they’re also downloading our increasing amounts of code over an older 3G or 4G network. Doubly bad.

What to do?

This problem is on us. Yes, we need to better prioritize our asset delivery, but most importantly, we need to stop delivering so much JavaScript. We need to audit our scripts, and scrutinize our 3rd party integrations regularly, as many of these packages are short-lived anyway. Perhaps even take a cue from the The Telegraph, and delete old third party scripts see if anyone complains. Test your reliance on tracking and personalization, and maybe like the NYTimes you’ll find that serving un-targeted ads could increase revenue! Run Calibre or Speedcurve. Keep your team aware of their impact, across all roles.

Most of all, get your managers, product owners, developers, and everyone else an average Android device and test your site on it. It’ll help all of your users.

We have a huge opportunity to improve the web as networks improve, but it’s on us to take it or leave it.

All blog posts