Why is this a problem?
So, what does a bloat look like?
- Bad compression.
- Complex framework code.
- JQuery by default.
- Blown third-party scripts.
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.
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†
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.
To leave‘s De-Bloat the Web!