Because Performance Matters

Remembering the Cost of Evaluating and Executing Scripts

Script performance is about more than download speed

By Shawn MaustSeptember 06, 2017

When trying to optimize a page, we’ll often look at the weight of the page, and how long the browser takes to download the necessary assets. But in addition to how long it takes to download the asset, it’s also valuable to check how long it takes to evaluate and execute it, especially when it comes to our JavaScript files.

Each script we use is going to have a cost associated with it, including a download cost and an execution cost. And both of these can impact our page’s performance. The execution cost is especially important when it comes to mobile devices. Overall, they will have far less resources and power to handle parsing and executing scripts than non-mobile devices. Which means a small, minified, script that doesn’t take that long to download, could still make a significant impact on the page’s performance if it requires much work to parse and execute–especially on lower-end devices.

Checking Evaluation and Execution Costs

So how do we see what these evaluation and execution costs are?

In Chrome, if you open up DevTools, you can find some useful tools under the ‘Performance’ tab. Here, if you hit the ‘Start profiling and reload the page’ button, it will reload the page and keep track of important stats.

For instance, at the bottom, there is a ‘Summary’ tab that will give you an overview of the various aspects of loading the page.

Chrome DevTools Summary tab
Summary tab in DevTools

Especially helpful is the ‘Bottom-Up’ tab right beside it, which will give you a detailed look at all the elements that make up the summary. This can help identify, for instance, how long it takes to evaluate individual scripts, and how long each one takes to execute.

Chrome DevTools Bottom-Up tab
Bottom-Up tab in DevTools

For similar information in Safari, you can go to the Timelines tab within Inspector. If the red recording button is already selected, you can simply reload the page, and it will begin recording performance related stats, with a timeline at the top, and details below. This can allow you to see if certain scripts are taking longer than expected, and can help pinpoint potential performance issues.

Safari Inspector Timelines tab
Timelines tab in Safari

Comparing Mobile and Desktop

Looking at these performance tabs can be helpful to get an overall idea of how things are going, but how does this relates to what actually happens on a phone? Here is where doing some remote debugging can be helpful.

I was curious how much the difference actually was, especially when it came to evaluating and executing scripts, so I connected an iPhone to my laptop and used Safari to connect to it remotely. I then pulled up the same page on both devices to see what the differences were for evaluating and executing the various scripts on the site. And while I expected there to be some difference, I didn’t realize how big a difference I would see.

(Note: I was using an iPhone 5c for this test–definitely not new, but also more powerful than some devices out there).

Desktop execution times in Inspector
Desktop times
Mobile execution times in Inspector
Mobile times

I noticed that in some cases evalutating the same script could be well over 5x slower on a phone. I tried this on other sites, and the slowdown was usually somewhere in the 2-10x range, with over 5x not being uncommon.

Using the Throttle

Knowing this can be helpful when building a site. Some issues that may not be noticeable on our development machines, may become big issues on a mobile device.

One way to catch these potential problems early is by choosing to throttle the CPU on your desktop when testing a site. This will emulate the additional time it would take for a phone to process the page, giving you a better idea of how it would perform in that environment.

In DevTools, in the ‘Performance’, there is a ‘CPU’ option you can use to emulate a slower CPU.

Throttle options in DevTools

Based on my experience, 5-10x isn’t a bad place to start if want an idea of how things will execute on lower-end devices. (The same could be done for the ‘Network’ option if we wanted to simulate slower network speeds).

More than Download Times

Download times are important, but so is the evaluation/execution costs of any JavaScript on the page. Neglecting these can lead to performance issues, but being mindful of them can help us provide a better experience to all the visitors to the page—including those on less performant devices.