When the Wrong Code Executes: A Third Party Cautionary Tale

Almost every website these days relies on various third party providers to deliver content, better user experience, analytics, and more. To use these third parties, developers simply reference the tags provided by third party, often a single JavaScript tag which “magically” delivers the benefits of the provider. We all expect the providers to ensure their systems are up and running 24/7, and that they are not slow or impacting the end user experience. But there are other ways for a third party to affect a site’s performance beyond just speed and availability; we tend to just assume that they won’t deliver anything malicious or break our sites.

Sadly, today a major provider for web page optimization solution, used by over 20,000 sites, managed to deliver the wrong code on their webpage via JavaScript. The bad JavaScript file contained location.reload(); instead of the expected optimization file. As such, end users on the West Coast that accessed the sites containing the third party provider had their browsers constantly reload due to the code delivered. Many of our customers that use our browser synthetic monitoring solution immediately noticed their pages were not loading properly on the West Coast, and contacted us for assistance in explaining the failures.

The top two graphs here are taken from one of our clients, a major online retailer, that was experiencing the failures (indicated by the scary-looking red diamonds). And the bottom graph shows the total bytes being delivered by the third party Javascript, with failures from West Coast locations starting just before the retailer’s site is impacted.

In situations like these, it’s important to realize that referencing a third party means you are allowing an outside source to deliver and run code to your end users on your site. When doing so, you have to make sure that you have SLAs in place, not just for speed and availability, but also to ensure that they are not delivering any code or other content that would impact the end user experience on your site. Additionally, you might want to think about requiring third parties to not implement things like location.reload or changing the location.href (and other JavaScript) as an extra precaution. This is where synthetic monitoring via browser comes into play, as it will help you discover the problem before the user experience is harmed.

When deciding to run third party code on your site, be aware of how much control of your site you could possibly be giving over. Monitor your site to ensure that both your code and the third party code which you allow are working as expected. Be sure you know what to do if you discover that third party content is causing issues and how to hold them accountable.

Also, if you do deliver JavaScript to other sites, don’t deliver location.reload(); It’s not your location!