Imminent bloat warning: JavaScript size up 48% in one year

js-codeWebsites are getting more dynamic, and more heavily scripted. JavaScript is going through something of a renaissance. Perhaps, however, it is time to start reigning in the amount of JavaScript code that’s included on the average web page.

Stats from HTTP Archive show an alarming trend:


This chart shows an average based on thousands of tested websites from the end of 2010 until now (HTTP Archive performs tests every month).

As you can see, a year ago the average web page included 128 kB of JavaScript. Now that number has risen to 189 kB. It’s gone up 48% in just a year.

Another 50% increase over the coming 12 months would put us at 283 kB of JavaScript. Then add all the other stuff that’s also growing, such as image download size, and the picture for web performance enthusiasts start to get pretty bleak.

We’ve shown before how JavaScript is the fastest-growing contributor to web page size. Time to start paying more attention to this.

P.S. Yes, we’re aware this blog is an offender. One of the reasons we’re planning a revamp.

Top image via Shutterstock.


  1. So what? People demand more interactivity, thus more scripts. But at the same time, internet connections become faster, and parallel loading solutions and cdns are out there – so there’s no reason for crying “alarm”.

  2. This is a bit silly.  An extra 50kB of JS year-over-year is trivial.  On a 1 Mbps connection that means that the first time you load said script it takes a few hundred ms longer, and then sits in your cache.
    You should do a breakdown of what the major components of JS load are–if they are commonly hosted jQuery/google ads/google analytics growing, those will be cached aggressively and really not a factor in page load times / performance even if they grow to MB each.

    1.  @elliottback That JavaScript completely blocks the browser until it’s been loaded, parsed and executed. This isn’t negligible on any browser and it’s particularly of concern for mobile devices where memory is more of a premium.
      That said, you are right to request a breakdown: a much bigger concern would the number of scripts and source domains as those will multiply all of the overhead even if the scripts aren’t that big.

      1.  @acdha  It all depends what is being used to load the JS. There are a whole stack of JS loaders that do not block other stuff from loading.

        1.  @Matthew Schinckel This is only partially true: because JavaScript is inherently single-threaded the only delay you’re removing with an async loader is the portion of the delay caused by network latency. Any JS loading strategy still counts against the per-host network limit and will still cause some level of blocking while the JS is parsed and executed.
          This is of concern on desktop browsers and more so on mobile: even with a cache hit something as simple as the memory increase from parsing something like jQuery UI can be noticeable.

  3. The reason for the increase in JavaScript is simple. The line between applications and web sites has blurred. In order to interact and/or display data asynchronously, meaning without having a page reload, then you must have client side logic (aka: JavaScript). Otherwise you’ll have a very clunky static site. As far as the file weight, it’s trivial when you take into account the various aspects being mitigated for the single page application user experience (UX) which immediately translates to quicker site interaction. I’m a huge advocate of only loading onto the client (your browser) what ever libraries/images/etc are necessary (something called lazy-loading). If a developer knows what they are doing, say for instance if they were using a common library like AngularJS, then they should know how to lazy-load dependencies on the first instance of a directive’s usage. In non-developer terms, this means, load stuff only when it’s actually about to be used.

Leave a Reply

Comments are moderated and not published in real time. All comments that are not related to the post will be removed.required