Why is the internet so slow? (And how we can fix it).

JavaScript can be found all over the web. It is involved in almost every aspect of what we do online. When we use Facebook, YouTube, or Google, we rely on JavaScript code to give us the interactive feel we expect from the web today. JavaScript gives us everything from web basics like spinner loading, browser alerts, and page transitions, to advanced features like web games, 3D renders, and interactive maps.

Unfortunately, a rarely discussed but highly impactful downside of all this interaction threatens our browsing experience and the future of the web itself: JavaScript bloat. This term refers to a website that requires too much JavaScript to function at maximum speed and capacity. As a professional web developer or internet business owner, keeping your website running at maximum efficiency is essential, so understanding and resolving JS bloat is extremely important.

More from Alex Zito-WolfHeadless vs Integrated Architecture: What’s the Difference?

Why is this a problem?

Over the past 10 years, the use of JavaScript on websites has increased significantly by any measure. Since 2017, JavaScript file weight increased by 78 percent in total for desktop sites, while the number of JS requests increased by 17 percent. Part of this increase can be attributed to the fact that the average website has become more complex over the past five years. However, much of it is due to bad practices, broken integrations, or unnecessary code. Whatever the reason, all the bloat is slowing down the internet for everyone.

If you are not familiar with how your internet browser downloads JavaScript, this introductory article explains the basics well. Every time you use your browser (e.g. Chrome or Firefox) to visit a webpage, you usually need to download some instructions HTML† javascript and C.S.Sthat tell your browser how to put the website together and make it ready for use.

So, what does a bloat look like?

A bloated website is one that has too much JavaScript relative to its content. For example, a complex website with many features will of course have more JavaScript, and that’s okay. The problem occurs when a simple site has a large amount of JavaScript that the user needs to download. This calculator provides the standard, widely used algorithm for determining JavaScript bloat. Using a screenshot of the website in question as a proxy for the overall complexity, the calculator compares that complexity to the size of the JavaScript downloaded and the number of JS requests.

JavaScript bloat can occur for many reasons, but websites generally get blown up for one of the following four. Fortunately, you can implement solutions to solve these problems.

Poor Compression

Minifying and compressing your JS and CSS files is essential for a production website. You could write a 200KB script that can be scaled down to 100KB and then compressed to just 15KB, which is only 7.5 percent of the original script size. If you don’t configure your server to apply the correct compression rules to every JS and CSS file, you’re setting yourself up for failure.

Use proper compression and size reduction to resolve this issue. This article by Chris Coyier explains the differences between the two and gives you a few ways to make sure you apply both processes correctly. Basically, you should be able to configure your server to use a compression algorithm of your choice, usually with Brotli compression or Gzip.

Complex frame code

Libraries like Angular and React offer a huge advantage to today’s businesses and developers. However, when you choose to use a framework, you are accepting significant overhead when it comes to the total JS it will use, and even more so for full-feature or enterprise-level frameworks. Choosing to use a complex framework when you have a simplistic use case guarantees that you will have a bloated site.

The remedy, of course, is to only use frames when you have to. Frames offer many advantages † you can write code with the latest templates, advanced styling tools and a network of plugins to quickly achieve advanced results. But you should still aim to write basic JavaScript for most projects and only apply frameworks to more complex pages or applications.

jQuery default

jQuery is a DOM manipulation library that is a dependency of almost 90 percent of the world†s websites† If you are able to get rid of this dependence, you will be able to rid yourself of 80 KB Minified JS†

The solution to this problem is to rid yourself of jQuery addiction. jQuery is a great, time-saving convenience, but it’s overused. With today’s browsers, it is often not necessary to use it for simple tasks, because these types of tasks have robust, native implementations that perform jQuery-like functionalities themselves. So, again, try to stick with native JavaScript whenever possible.

Blown Third Party Scripts

Whenever you add a third party script to your website, you are responsible for tracking the size of that script and making sure the code is as lean as possible. Third-party scripts generally come in two flavors: dynamically loaded, such as Google Analytics, or compiled with your application code, such as NPM modules† Both packages can add unnecessary baggage to your website. Dynamically loaded scripts have the added disadvantage of sometimes slowing down your site by: render blockingessentially causing your website to wait for Google’s servers to respond before loading your own site.

To reduce this type of bloating, limit the use of monitoring scripts and keep a close eye on your NPM packets. Third-party tracking code is responsible for much of the increase in JS weight on the web. Web users are still often held hostage by websites that insist on loading mountains of cookie tracking ad code before the page is even usable. Beware of scripts that cause your website to make a lot of requests to ad trackers, as they can put the speed of your website in the hands of Google.

When it comes to NPM packages, keep track of your dependencies and their weight. Before adding a new dependency to your application, use a site like this one to test the size. You don’t have to obsessively track your dependencies this way, but as a rule of thumb, if you’re adding more than 100KB of minified JS to your site, you’ll have to dig a little deeper into why that script needs so many lines.

More in Software EngineeringYou can use artificial intelligence to fix your broken code

To leave‘s De-Bloat the Web!

JavaScript bloat is a widespread problem. As technical professionals and web developers, our job is to manage and control it. By following the simple steps above, you should have a blueprint for properly choosing the scripts needed for your website and optimizing the ones you do want to use.