The Web Is Too Damn Fat and Doomed, How You Can Fix It

Ronan Cremin recently posted an article relating the current size of the average web page to the size of DOOM, the game I wasted many late hours playing back in college. How did we get to this miserable state? Ronan does not go into the details, so I will. And I will offer hope to fix the situation.

The Web Is Too Damn Fat and Doomed, How You Can Fix It

Too Much JavaScript

HTTPArchive reports the average page loading 358kb of JavaScript, light in my experience. I routinely see 1-4MB of scripts being loaded. What are you people doing with all this script? The vast majority of the web is still read-only and needs no JavaScript. Seriously think about the purpose of a script before you add it to your payload.

JavaScript Transfer Size 4-15-16

Too Much CSS

HTTPArchive says the average site uses 76kb of CSS. Again a lot of rendering instructions. I bet if we audited those 100,000 sites we would find 95% of the CSS is never used and could be quickly eliminated with a node module at build time. Yes I bet the average page could use 5kb of CSS and render just as well, and faster. So clean up your CSS.

CSS Transfers Size 4-15-16

Oversized Images

Just under 1.47MB of images per page. I know this could be reduced by half if you would just optimize your images. Then layer responsive images in and you could reduce your image payload by 75% in most cases. Remember the majority of web pages are loaded on a mobile device today, this means smaller viewports rule.

Images Transfer Size 4-15-16

Too Many HTTP Requests

The average home page measured by HTTPArchive employs 99 HTTP requests to render. If you saw the pages I run through web page test you would think that is light. I often analyze pages with 3-500 HTTP requests. Each request requires overhead to initiate. Scripts are more problematic because they are blocking and require the browser to evaluate the script before doing anything else.

Total Transfer Size 4-15-16

Too Many 3rd Party Scripts

3rd party scripts are things like analytics packages, ad providers and even content providers. They are killing the web today. This is why customers use ad blockers and other 3rd party script blockers. I guarantee if you have a public web property someone has dropped in some of these horrible ‘solutions’ in your application. I doubt they are providing the added benefit they claim and definitely are costing you business because customers hate the latency they introduce to your user experience. Not to mention their code is often poorly written and causes your page to crash the browser.

What to Do?

Loosing online fat is easier, but similar, than loosing body fat. You need to watch what you eat and exercise. Like personal fitness 80% of the game is changing your diet. Eliminate fast food frameworks and excess code. Most of the JavaScript and CSS we load is never used.

Unused CSS is easy to eliminate because we have several node modules, like UNCSS, to help. JavaScript is a bit tougher because too many developers lean on heavy, fast food frameworks. I have never found the need to use any of the bloated frameworks and transpilers. You do not need them, learn a few dozen browser APIs and a couple of module patterns and you should be good to go.

Next optimize images. Today that is a two fold process, optimize images, but also create a responsive image array. Tools like Kraken can be used to do both. Kraken is great because it optimizes image file size. You can also use the API to create a responsive image array.

All modern browsers support responsive images. And old browsers ignore the responsive attribute (srcset and sizes) and load the traditional src image. Responsive images give you and advantage because now the browser loads the best image for the current viewport size. This means you can avoid loading a 2000 pixel wide image on a phone, over slow, expensive GPRS.

The next suggestion comes with a caveat. If your web server supports HTTP/2 and your site uses SSL then by all means use many small files. However, more often than not you will benefit from bundling and minifying your scripts and stylesheets. On top of that you should GZIP compress all text assets to further reduce their size. Also if possible use async and defer attributes on your scripts to defer evaluation until a page has fully loaded.

Finally, audit your third party script usage. Chances are you do not use many of the 3rd party scripts loaded in your pages. Eliminate those scripts and the money your company is paying to use them. Your pages will load faster, customers will buy more things from you and your bottom line is more profitable. Also look for 3rd parties that load 4th and 5th party scripts. You can use Simon Hearn’s Request Map Generator to see the third party script universe your pages generate upon each request.

Third Parties Tracker

Nutrition is the first step, next we need exercise. For the web that means testing and measuring. Use tools like your browser’s developer tools and WebPageTest to monitor your application’s health. I recommend the book Using WebPageTest to learn both fundamentals and advanced ways to use WebPageTest to monitor your applications performance health.


The average web page being the same size of an advanced 3D first person shooter game is embarrassing. We need to put the web on a diet and exercise plan today. I loved DOOM, but I love the web more. Please join me in putting the web on a diet and fitness program. Lets make the web strong and healthy again.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel