An 11-Step Program to Bulletproof Your Site Against Third-Party Failure

Everyone has bad days, and third-party content providers are no exception. If you host third-party scripts — such as ads, social widgets, analytics, and trackers — on your sites, then script failure is inevitable. Sometimes this failure is fleeting and passes almost without notice. Other times, a single line of JavaScript can cause your entire site to crash spectacularly. While you can’t control your third-party content, you can control its impact on your website’s performance. Here are eleven steps to protect your site.

Most performance issues with third-party scripts fall into one of two categories:

Problem #1: Slowness

Last year, performance monitoring company New Relic looked into the most popular third-party APIs used by the 200,000+ applications it monitors and calculated the average response times for some of the most popular scripts:

• Twitter – 832 milliseconds
• Facebook – 918 milliseconds
• PayPal – 1.788 seconds

We tend not to notice these delays because these third-party scripts have been optimized to load alongside primary page content, rather than blocking it. These scripts are the exception, however; most third-party scripts are unoptimized, putting the performance of your pages at their mercy.

Problem #2: Outages

Slowness doesn’t make headlines. Outages do. The recent Facebook button outage that took down a number of high-profile media sites, including CNN and Gawker, is a good example of this.

The average top ecommerce site contains seven third-party scripts, with some sites containing 25 or more. Cumulatively, these can have a massive impact on page performance. Here’s an eleven-step program for regaining control before, during, and after deployment of third-party scripts.

Before Deployment

Before you allow anyone to install new third-party code on your site — no matter how tiny and innocent-looking that snippet might be — follow these steps:

1. Research the third-party provider.

Who are they? What’s their performance track record? What is their average monthly downtime? What’s their response time and time to last byte when tested from key locations? Do they use a CDN, and if so, where are their caches located? The vendor should be able to give you clear answers to these questions.

2. Read the provider’s service level agreement.

Most third-party providers don’t offer real-time monitoring of their scripts, nor do they offer meaningful service level agreements (SLAs). This won’t change until site owners start demanding these tools.

In an ideal world, a third-party SLA would:

• Express annual uptime guarantee as a percentage (ideally, as close to 100% as possible).
• Describe the process for reimbursing site owners (if site owners are paying for the service provided by the script) if uptime drops below the SLA guarantee.

Whether or not the provider has an SLA may not be a deal breaker for you… yet. If the value of the script outweighs the nebulousness of not having an SLA, then you may opt to proceed and accept the fact that you’ll need to take care of your own real-time performance monitoring.

3. Perform a cost/benefit analysis.

1. Perform an A/B test of your site, with and without the tool, in a real-world environment. Generate waterfall charts for both tests, and identify how long the third-party objects take to load. Note these benchmarks.
2. From the tool vendor, get the number for the average conversion rate increase experienced by other sites that use the tool.
3. Using Aberdeen’s widely accepted performance stat that a 1-second page delay equals a 7% loss in conversions, calculate the potential net conversion gain or loss. For example, if a tool slows down page load by 2 seconds, that means a 14% conversion loss. But if that same tool promises a 20% conversion increase, then that’s a net gain of 6% (not including the cost of purchasing the tool).

 4. Be ready to say no.

Nobody likes to be the naysayer who turns down exciting new features, but if a feature has the potential to seriously hamper overall performance, someone has to put their foot down.

During Deployment

After you’ve made the decision to implement a new third-party script, make sure you’re doing so in a way that won’t hurt the performance of your pages.

5. Defer third-party scripts so they load last.

In simplest terms, deferral is a front-end optimization technique that delays the execution of non-critical scripts until the rest of the page has loaded and rendered on the browser. An advantage of deferral is that it’s a relatively easy fix; however, it won’t work for all third-party content. If your site hosts third-party ads, then your ad providers may not approve of this technique. Save deferral for third-party scripts like analytics beacons, tracking pixels, and social widgets.

6. Better yet, use scripts that load asynchronously.

With asynchronous loading, third-party scripts load in parallel with crucial page content. This lets you display ads and other business-critical third-party scripts without blocking your primary content. Async code can be tricky to program, which is all the more reason why it’s been gratifying to note its increasing rate of adoption among third-party providers.

Asynchronous scripts aren’t a perfect solution, however. Slow third-party scripts will prevent the onLoad event from firing. A page’s onLoad determines its load time as measured by performance measurement tools. Too many delayed onLoads will obfuscate your results. If you’re tracking thousands of pages over extended periods of time, these results will make it difficult to pinpoint other performance problems.

7. Implement third-party timing and script killing.

Also known as “tag management”, this technique involves establishing an allotted time for scripts to load. If a script fails to load within that time, it’s either killed or deferred. The down side of this technique is that it doesn’t lend itself to hand-coding, which leads to the next tip…

8. Consider the benefits of using a tag management service.

If you have a large, complex site with multiple third-party tags, you may choose to use the services of a tag management company, which offers an automated version of the services described above.

After Deployment

Don’t turn your back on your scripts. They need constant care and feeding.

9. Monitor constantly.

With real user monitoring (RUM), not only can you keep an eye on the real-time performance of your scripts, you can also glean actionable data for other initiatives. For example, one of our customers uses their RUM data to create new SLAs with their third-party vendors.

10. Give feedback to your third-party providers.

If you’ve identified a performance issue with a piece of third-party code, let the vendor know. They may not realize there’s an issue, because scripts can behave differently out in the world than they do in the lab. And as with any customer service situation, you can learn a lot about a vendor based on how they respond to your concerns.

11. Be ready to kill a persistently poorly performing script.

The occasional outage happens, but if outages and slowdowns are persistent and your third-party provider isn’t responding to your concerns, you need to consider the value in keeping the script. This takes you back to step 1. That’s not a bad thing.

Learn more: Find out how Radware FastView helps optimize the performance of third-party scripts.