5G Will Definitely Make the Web Slower, Maybe

5G is here. Its little icon is starting to appear in the top corners of phone screens throughout the world. If you’ve connected to 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. Carriers are predicting download speeds in 2019 for anywhere from 100Mb to 1 Gbit per second on average. At that speed, you could download the entire discography of Friends AND ceremoniously drag-and-drop it in your trash bin in around the same time it would normally take to load a webpage today. I mean, probably—I’m not a math person. The future is amazing!

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

So network performance stands to get much faster very soon. That should alleviate the web’s performance problems right?

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

Worse? How?!

Permalink to 'Worse? How?!'

Faster networks should fix our performance problems, but so far, they have had an interesting if unintentional impact on the web. This is because historically, faster network speed has enabled developers to deliver more code to users—in particular, more JavaScript code.

During the years 2011 through 2019, 4g coverage spread from 5% to 79% of the world. During that same time period, the median average JavaScript transfer size to mobile devices increased by 611%, from 52kb to 372.9 KB. Now, of course, that’s a correlation; many factors have contributed to this increase. Yes, sites also became a lot more interactive during that time, which can lead to increased JavaScript usage. Also, Responsive Design gained adoption, meaning many sites started sending a single JavaScript payload to all devices. But to be clear, “desktop” sites in 2011 were only sending about 50kb more JavaScript on average than their mobile counterparts. Generally, UI patterns haven’t changed that much on the web since then either. For example, the highly cross-device Boston Globe website that we were fortunate to help build launched in 2010, and news sites tend to retain a pretty similar feel today. And lastly, a very recent snapshot shows the trend continuing: even in just the past couple of years the average JavaScript transfer size has increased by more than 50%.

Now, before we go and blame the JavaScript frameworks, it does appear that these increases aren’t entirely tied to the user interface features of our sites. Indeed, most of the increase comes from a 706% increase in third party scripts. To be sure, these third party requests could be JavaScript frameworks, but most often, they’re the trackers, the A/B libraries, the personalization scripts, the ads, and the chat bots, all of which often kick off their own fourth and fifth party requests.

…after the party it’s the after party.

So JavaScript size has ballooned as networks have improved. Still, you might assume that if all this code downloads fast enough, it’s relatively harmless, right? Well, unfortunately not. Compared to the other kinds of code we are delivering, JavaScript is uniquely costly for its weight.

“Looks good on my phone”

Permalink to '“Looks good on my phone”'

Developer Convenience can easily lead us astray.

On the average devices still in use today, 200kb of JavaScript (compressed for transfer) 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, remember that on average, we are delivering almost twice that much. And during the time that JavaScript is parsing, a web page might be visible but not yet interactive, or it could be entirely blank (if the scripts are referenced in typical ways that block page rendering). Both scenarios are bad, and the worrisome part is, many of us who work on the web may not even notice this problem ourselves.

The average device is not the brand new thousand-dollar iPhone with 3 lenses for taking photographs. The average device even in the US is the sort of device that you see on the Amazon Best Sellers, which can run about $130. It might be an iPhone, but it’s probably 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 right now, where at the time of writing, the third best seller costs $59.

Even if folks are on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential speed improvements of 5G moot.

And what about folks without 5G?

Permalink to 'And what about folks without 5G?'

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

What to do?

Permalink to '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 script inventory, and scrutinize our 3rd party integrations regularly, as many of these packages are abandoned or meant to be short-lived. Perhaps we can even take a cue from the The Telegraph, and delete old third party scripts and see if anyone complains. We can test our reliance on tracking and personalization, and maybe like the NYTimes we’ll find that serving regular, un-targeted ads could actually increase revenue (and if so, please delete the scripts no longer in play)! We can run services like Calibre and SpeedCurve to keep tabs on our performance budgets, and get everyone on our team involved in the performance process. We should do whatever we can to keep our team members aware of their own impact, across all roles.

Most of all, we need to get our managers, product owners, developers, and everyone else an average Android device and test our sites on it regularly. Better yet, get that device tethered to a prepaid or metered data plan and see how long it takes to run out of data in a 5G world. Keeping our teams aware of our real-world performance will help all users–the folks with nice devices too!

As networks improve, we have a huge opportunity to improve the web we build, but it’s on us to take that opportunity, or squander it.

All blog posts