How to Identify and Resolve JavaScript Performance Problems

This post was originally published on the Rigor Web Performance blog.

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 CDN’s can improve the delivery of these resources.

Service Outages Illustrate Need For 3rd Party SLAs

This post was originally published on the Rigor Web Performance blog.

It is still early in 2015, but there have already been numerous instances of web technology platforms experiencing service disruptions lasting over an hour in length. These disruptions often times have a ripple affect across the internet, impacting anyone that integrates with the service.

A couple of weeks ago, I wrote an article detailing one such outage related to New Relic’s RUM beacon. Earlier this year, a Facebook outage caused major service interruptions for its major partners Instagram, Vimeo and many others. A Facebook spokesperson told The Verge that the outage “occurred after we introduced a change that affected our configuration systems.”

facebook outage

Outages like this that have a wide-ranging impact bring to light the need for organizations to have service level agreements (SLAs) with all 3rd-party integrations and services that they host. These agreements are already commonplace for “mission critical” services such as cloud infrastructure, CDNs, and ISPs. However, seemingly harmless integrations with services such as social media networks, ad-serving networks, trackers, or marketing analytics plugins have been immune from this practice.

These “harmless” integrations can quickly become the source of serious performance problems for your website or web application. This is why I encourage sites to have clearly defined SLAs in place for all 3rd-parties that they host and to monitor these services with a neutral 3rd-party monitoring platform to report on the availability of the service.

fox guarding hen houseRight now, most 3rd-parties do not offer real-time monitoring of their scripts, and the few that do monitor their scripts internally. At Rigor, we often advise customers to be wary of reports on vendor performance that originate from the vendor themselves.  We operate under the simple mantra “trust, but verify”.

When working with 3rd-party providers that require hosted scripts on your site, here are some items to discuss when negotiating a clear SLA:

  • An annual percentage uptime guarantee
  • A process for reimbursing site owners if uptime drops below the guarantee
  • A neutral 3rd party monitoring platform to report on the availability of the service

Hopefully as site owners become more aware of the impact of “harmless” 3rd-party integrations and services, the demand for properly optimized scripts, improved monitoring and reporting, and greater organizational accountability will rise.

The Hidden Cost of Real User Monitoring (RUM)

This post was originally published on the Rigor Web Performance blog.

Every day Rigor robots make 1.5mm visits to over 350,000 web pages and load 23mm assets in browsers from around the world. Because of the large amount of data that we sift through each day, we are able to detect many outages that occur on the internet in real time. Yesterday we saw a sizable outage across many of our customer and research accounts.

When we dug down into specific runs we kept seeing the same issue pop up. A piece of javascript on each page was unable to connect back to its server and blocked other content from loading.  Below is a waterfall chart of one of our customers who experienced latency due to the beacon. (Not familiar with waterfall charts? Check out “How to Read a Waterfall Chart”).

waterfall picture rum latency

Websites such as TOMS, Citrix, AirBnB, and hundreds more experienced multi-second delays to their page loads due to issues loading a javascript beacon (also known as a tag). Ironically this beacon is used to track the end-users’ web performance experience.

After some digging we quickly discovered that the culprit was New Relic’s browser collection beacon. This piece of javascript is how New Relic creates their Real User Monitoring (RUM) data. Our suspicion was confirmed shortly thereafter via New Relic’s public status page as seen in the picture below:

New Relic Browser Collection

In all, the New Relic outage lasted nearly two full hours and caused significant UX problems for end users. This got me thinking about the two blogs I wrote in December describing the benefits and shortcomings of RUM and how it complements synthetic monitoring.

One of the key differentiators that I failed to mention in these blogs between RUM and Synthetics is the external nature of Synthetics. Despite all of the benefits of RUM, loading any external content on your site has risks. Unlike RUM, Synthetic monitoring is completely external and does not require any client-side installation or the insertion of a web tag. As the New Relic outage so clearly illustrated, RUM at its worst can be the source of serious performance problems and at its best is still yet another asset that needs to be loaded by your users at a time when web pages are already slowing and growing at an alarming rate.

Benefits of Using RUM with Synthetic Monitoring

This post was originally published on the Rigor Web Performance blog.

Last week I wrote a blog that defined and analyzed differences between the two predominant end-user monitoring techniques leveraged in the market today: Real User Monitoring (RUM) and Synthetic Monitoring.

I ended that post with a list of benefits provided by synthetic monitoring tools. This week I want to detail some of the shortcomings of using a “synthetic-only” approach and discuss how leveraging synthetic monitoring coupled with RUM is the most effective and holistic monitoring practice.

Rum heart Synthetic

Synthetic Deficiencies

Last week, I detailed many of the benefits offered by synthetic monitoring tools. When it comes to alerting on performance problems or major service disruptions,  testing pre-production environments, or baselining performance, synthetic monitoring is unrivaled. However, synthetic is not without its deficiencies. As its name would suggest, synthetic monitoring does not measure the experience of actual users. Instead, it creates synthetic traffic from data centers owned by the vendor and/or customer specifically for the purpose of measuring performance.

Consequently, visibility into performance is limited to the number of “synthetic tests” built and managed by the user. For example, if CNN creates a synthetic test for the homepage of their site they will have visibility into the performance of that specific page, but will be blind to performance problems elsewhere.

As the above example suggests, the primary problem with synthetic monitoring is scaling the scope of your application monitoring. For synthetic monitoring to be valuable you must understand and monitor all of your business critical web pages, services, and transactions. When using a synthetic-only approach, failure to create tests for any of your high trafficked or mission critical websites and services leaves you in the dark to performance issues present in other areas.

RUM Benefits

RUM is valuable because, unlike Synthetic monitoring, it captures the performance of actual users of your website or web application regardless of their devices, browsers, or geography. In this sense, it is great for the business’s understanding of performance.

Because there is no need to pre-define your important use cases (a la synthetic), RUM is great for generating reports and analyzing trends. As users goes through the application, all of the performance timings are captured, so no matter what pages they see, performance data will be available. This is particularly important for large sites or complex apps, where the functionality or content is constantly changing.

By leveraging RUM, a business can better understand its users and identify the areas on its site that require the most attention. Moreover, RUM can help to understand the geographic or channel distribution trends of your users. Knowing your user trends helps you better define your business plan and, from a monitoring perspective, allows you to identify key areas to target for optimization and performance improvements.

Geo-Location GA

Summary of RUM Benefits

  • Understand HOW your application is being used
  • Understand the real geographic distribution of your users and the impact of that distribution on the end user experience
  • Understand network or channel distribution and flow of your users
  • Ensure full visibility of application usage and performance

Synthetic and RUM: Better Together

If your organization has access to synthetic tools, RUM allows for you to create synthetic tests that are more representative of your end user’s experience. A best practice would be to use RUM to identify target areas for optimization and then create synthetic tests to monitor these pages from relevant geographic areas and channels moving forward. This will allow you to isolate and diagnose the root cause of latency or intermittent performance problems that are impossible to identify with RUM data. A good illustration of this process can be found on this blog published by the performance team at Gilt Groupe.

In short, leveraging RUM with synthetic monitoring allows for a more cost-effective, accurate, and comprehensive monitoring experience.

Synthetic Monitoring vs RUM

This post was originally published on the Rigor Web Performance blog.

Recently one of our customers, Gilt Groupe, posted a case study on their tech blog evaluating the value and merits of utilizing synthetic monitoring (Rigor) to understand client side performance trends and problems real-time.

At Rigor, we often find ourselves educating potential customers and business users on the differences between some of the different web performance monitoring methodologies available in the market and their various use cases. In particular, we have seen an uptick in interest for Real User Monitoring (RUM).

For those that are unfamiliar with either performance monitoring methodology, here is a brief definition of how each technique works:

  • Synthetic Monitoring – vendors provide remote (often global) infrastructure that visits a website periodically and records the performance data for each run. The measured traffic is not of your actual users, it it traffic synthetically generated to collect data on page performance.
  • Real User Monitoring (RUM) – vendors provide an agent (javascript) that is injected on each page and reports on the page load data for every request that is made for each page. As the name suggests, this technique monitors an application’s actual user interactions.

Synthetic vs RUM

So which technique is more useful? The reality is that these two technologies are incredibly complimentary. In Gilt’s case study, Eric Shepherd (Gilt’s principle frontend engineer) does an excellent job defining the benefits of using both technologies:

Both RUM and synthetic monitoring give different views of our performance, and are useful for different things. RUM helps us understand long-term trends, and synthetic monitoring helps us diagnose and solve shorter-term performance problems.

Eric gives us a great start when detailing the benefits of each solution. Below I dive into specific benefits synthetic monitoring tools provide that RUM does not.

Top Benefits of Using Synthetic Monitoring:

  1. Monitor in a Controlled Environment
  2. Synthetic monitoring allows for users to monitor the performance of their websites or applications with a set of controlled variables (geography, network, device, browser, cached vs. uncached) over time. This is valuable because it allows users to block out much of the noise that is reported with RUM. As a result, users can identify latency and downtime promptly and scientifically isolate and diagnose the root cause of performance issues.
  1. Understand the Performance of 3rd Parties
  2. Unlike RUM, synthetic monitoring tools provide waterfall charts for every website visit generated by the vendor. These charts provide full page asset load times allowing users to attribute every millisecond of load time to a piece of web content. For example, users can understand the impact of switching ad providers, content delivery networks, or using a new marketing analytics plugin.
  1. Benchmarking
  2. Synthetic monitoring doesn’t require any installation or code injection on your website to start. Subsequently, users can leverage synthetic tools to monitor the competition and effectively benchmark performance against key competitors over time.

Staples Benchmark

  1. Test at Every Stage of Development
  2. Synthetic monitoring can be used to test websites and web applications in pre-production. Pre-production test results can be used to baseline performance and set alert thresholds when applications are live.
  1. 24/7 Monitoring
  2. If an issue arises during off-hours or other low-traffic periods, synthetic monitoring provides the insight you need to quickly identify, isolate, and resolve problems before they affect users and negatively impact revenue and brand equity.
  1. Baseline and Analyze Performance Trends Across Geographies
  2. With synthetic monitoring, baseline tests can be set up to mirror the way your end users access your applications. These baseline tests can monitor key transactions and a geographic locations while testing from multiple browsers and devices.

After this quick overview you can see how synthetic provides value in many ways that RUM cannot, but synthetic monitoring alone may fall short in some areas. In my next post I look at the benefits of RUM and how its strengths effectively complement the holes found when utilizing a “synthetic-only” monitoring approach.