Pingdom Home

US + international: +1-212-796-6890

SE + international: +46-21-480-0920

Business hours 3 am-11:30 am EST (Mon-Fri).

Do you know if your website is up right now? We do! LEARN MORE

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

Posted in Tech blog on May 17th, 2012 by Pingdom

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:

js-size-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.

Tags: , , , , , , , , , , , , , , ,



Related content:

  1. Web pages are getting more bloated, and here’s why
7 comments
  Livefyre
Newest | Oldest
elliottback
elliottback

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.

therockerstar
therockerstar

 @elliottback When my browser freezes and I cannot do anything with my browser for a couple minutes, thats when I kill it and hit the javascript block tool and then reload the page...not cool when you are halfway done with an article and you can't even scroll.

acdha
acdha

 @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.

Matthew Schinckel
Matthew Schinckel

 @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.

acdha
acdha

 @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.

Jo Quinn
Jo Quinn

Javacript is your friend!!

ArtViper Designstudio
ArtViper Designstudio

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".


Read more posts at the homepage