Websites today are growing larger than ever before with the average page size and number of page requests getting larger every month. As websites become increasingly JavaScript-heavy, it is  important for site owners to understand the impact of JavaScript on their websites.

With this blog, I will provide an outline for identifying whether poorly performing JavaScript files are a problem for your website, and provide some best practices for reducing the resulting performance issues.

To determine whether JavaScript is slowing down your site, run a performance test.  Just plug in the URL for your home page and hit “Start Performance Test”. Within a few seconds, you will have a free report with data showing all of the sources of latency on your site.  You can also run tests for any other highly trafficked pages, such as a landing or product page on an eCommerce site. The results will tell you a lot about your website–including information on each of the JavaScript files on your page.

Website Speed Test - Coastal

In the above picture, I ran a test on Coastal Contact’s eCommerce homepage. At first glance, the thing that popped out to me was the number of resources on the page: over 300 assets were loaded. This number is exceedingly high, particularly for an eCommerce website, as nearly 75% of the top 1000 websites have less than 150 requests.

The second item that stuck out to me was the page size breakdown. Nearly 3/4 of the page’s total size was comprised of JavaScript. This is in stark contrast to the average breakdown of the top 1000 pages on the web:

Average Page Load Breakdown by Content Type

The above picture is from HTTP Archive and shows the content breakdown for the average website as of their last scan (2/15/2015). The average web page today is around 2 MB in size, and only about 300 KB of that (or 15%) is attributable to JavaScript, significantly less than the page load percentage for Coastal Contacts.

How many Javascript calls?

The next metric I checked was the number of JavaScript calls made during page load. By hovering over the JavaScript line of the graph key provided by I can see the number of JavaScript calls made for this specific page load. It turns out that there were over 92 pieces of JavaScript loaded on the page. This is significantly higher than the average website which loads 6-10 pieces of JavaScript.

We’ve established that there are entirely too many JavaScript files on this site and that, in aggregate, JavaScript accounts for an unusually large portion of the page load. These stats are inconsistent with modern performance optimization best practices. When optimizing your website for performance, there are three front-end techniques that you want to leverage:

  • Look to reduce the number of requests
  • Look to reduce the overall size of the content
  • Promote the simultaneous download of assets


Lets tackle the first technique for reducing the number of JavaScript requests by concatenating multiple JavaScript files into fewer files. I know you may be asking, “Why is it important to reduce the number of files if the overall file size remains unchanged?”

Concatenate this

The answer is that reducing the number of requests reduces that amount of time a browser spends fetching specific assets. As you can see in the above waterfall chart of the page load, every request a browser makes takes a minimum of 20 ms to fetch. While it may not seem like much, by enabling concatenation techniques on sites like with hundreds of assets, site owners could shave off seconds of load time.  There are many tools to help site builders with this. A great open-source tool to help with JavaScript concatenation is minify.

Size Reduction by Minifying Large JavaScript Files

The next step in the optimization process is to identify any JavaScript files that appear unoptimized or excessively large. Once again, taking a look at a page’s waterfall chart can help with this.

Candidate for Minification

When scanning down the waterfall chart, look for JavaScript files that take longer than 200ms to load. If you identify any slow JavaScript files that exceed 200 ms then they are likely a candidate for minification. Once again, there are many tools that can minify your JavaScript automatically, including the tool I recommended above (minify).

What to do with 3rd Party JavaScript?

When dealing with JavaScript files that are managed by a 3rd party provider, it is best to be conservative and judicious when making decisions around what files to host on your website. Last week I wrote a blog demonstrating the need for organizations to require SLAs for all 3rd party JavaScript tags hosted on their sites as these scripts are some of the worst performance offenders.

Dealing with 3rd party JavaScript can be a tricky task, but it is an important one. Scripts from 3rd party providers can be a serious source of performance problems, particularly when the provider in question experiences a service disruption or downtime. Here are some questions (and answers) you might want to ask yourself once you’ve made the decision to utilize 3rd party scripts:

Q: Where do I want to host the script(s)?

A: Overall there is not an appreciable benefit to hosting JavaScript files on someone else’s servers. However, there is data out there that suggests a small subset of  IP addresses do serve a large volume of JavaScript files very efficiently. The majority of these addresses were found to belong to Google and Akamai servers. (Note: some newer CDN’s offer services around file optimization that can noticeably improve the delivery of JavaScript files)

Q: Is(are) the script(s) fully optimized or concatenated?

A: Looking at the script in the context of a waterfall chart can help you identify the total weight and performance impact of the file. If there is an opportunity for optimization, then minification or concatenation techniques outlined above can be impactful. These techniques can be done manually before deploying the script, or you can leverage a CDN such as Instart Logic that can perform these and other techniques automatically.

Q: Is(are) the scripts loading asynchronously?

A: If the answer to this is no, find out if your vendor has an asynchronous version of the script that you can use instead. Many vendors have come out with widgets that now load asynchronously so make sure you are using the latest version. There are two major reasons to use asynchronous scripts. First, if the 3rd party goes down or is slow, your page won’t be held up trying to load that resource. Second, it can help make that resource more efficient and speed up page loads.

We’ve gone over a lot of information about improving your site’s performance by identifying and fixing JavaScript-related performance issues. To recap, try leveraging tools such as to identify the performance cost of each piece of JavaScript on your website. Once you identify key offenders leverage techniques to reduce the size of the JavaScript and the number of browser requests your website requires. Understanding the impact of  3rd party JavaScript is also important. Ensure that you are using the most recent versions of all 3rd party resources and look at how hosting providers or CDNs can improve the delivery of these resources.

Want to learn about how the Rigor platform can help your website get fast and stay fast? Reach out to a member of our team for a free trial.