Why Is This a Problem?
So, What Does Bloat Look Like?
- Poor compression.
- Complex framework code.
- JQuery by default.
- Bloated third-party scripts.
Minifying and compressing your JS and CSS files is essential for a production website. You might write a script at 200KB that can be minified to 100KB and then compressed to only15KB, which is just 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, then you’re setting yourself up for failure.
To fix this issue, use proper compression and minification. This article by Chris Coyier explains the differences between the two, and gives you a few ways to ensure that you are applying both of these processes correctly. In short, you should be able to configure your server to use a compression algorithm of your choice, generally using either Brotli compression or Gzip.
Complex Framework Code
Libraries like Angular and React offer a huge benefit to today’s corporations and developers. When you choose to use a framework, however, you’re accepting some substantial overhead when it comes to the total JS that it will use, and even moreso for full-feature or enterprise-level frameworks. If you choose to use a complex framework when you have a simplistic use case, you’re guaranteeing that you’ll run a bloated site.
jQuery by Default
Bloated Third-Party Scripts
Whenever you add a third-party script to your website, you’re 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, like Google Analytics, or compiled with your application code, like NPM modules. Both of these packages can add unnecessary baggage to your website. Dynamically-loaded scripts have the added detriment of sometimes slowing down your site by render-blocking, essentially causing your website to wait for Google’s servers to respond before your own site can load.
To reduce this type of bloat, limit your use of surveillance scripts and monitor your NPM packages closely. Third-party tracking code is responsible for much of the increase in JS weight on the internet. Web users are still frequently held hostage by websites that insist on loading up mountains of cookie-tracking advertising code before the page is even usable. Look out for scripts that are causing your website to make many requests out to advertisement trackers because these can put the speed of your website into Google’s hands.
When it comes to NPM packages, track your dependencies and their weight. Before you add a new dependency to your application, use a site like this one to test the size. You don’t need to obsessively track your dependencies in this way, but as a rule of thumb if you are adding more than 100KB of minified JS to your site, then you should dig a bit deeper into why that script needs so many lines.
Let’s De-Bloat the Web!