There are plenty of reasons why the presence of script (what it does, how it works, and how heavy it is) needs to be considered a little more thoughtfully.

Web traffic today is made up of more than 50% mobile devices, of these devices, many operate under extremely volatile network connections—loading scripts-alone in less than 10 seconds is nigh on impossible in many situations.

If you’re working on a single page app, with no reasonable content-only-fallbacks, this can be far more damaging than you may think—users will be watching a white screen, with partial content, for a long time.

Performance is important, there’s no doubting that, but what common negative impacts does JavaScript have on our sites? How are we currently evaluating performance?

Let’s have a brief (but constructive) look at the cost of JavaScript.

When commonly auditing the performance impacts of JavaScript, we look at:

The number of render-blocking scripts present on the page

How long scripts take to download, and the amount of data transferred

But what we’re often missing is what happens thereafter—

Once the device has downloaded the scripts, they must be parsed, converted to bytecode, compiled and then executed.

Parse and compile time are two reasons why the same site that works great on your $3000 MacBook, feels kind of janky on a 2-year-old smartphone.

The above graphic compares Chrome parse/compile times on a regular desktop browser, verses a low power mobile device. This graphic is taken from Addy Osmani’s excellent article titled “JavaScript Start-up Performance”.

Ouch.