Third-Party Scripts And Your Website: 10 Tips for Web Performance

A typical web page today can contain upwards of 75 third-party scripts, such as ads and analytics beacons. If you care about web performance, these scripts can be the bane of your existence. But third parties aren’t going away. They add value to site owners by generating revenue (ads), increasing conversions (targeting beacons), and helping you understand your users in unprecedented ways (analytics tags).

The best thing you can do is take a strong pro-active approach t mitigating any potential performance damage your third parties may generate.

Last month, I was invited to speak at WebPerfDays Amsterdam. I stayed for the breakout sessions, and I’m glad I did. One of the sessions focused on managing third-party performance, where pros like Andy Davies and Perry Dyball shared some best practices that were too good not to pass along.

Before you deploy a new third-party script…

1. Calculate its ROI

Perform an A/B test of your pages, with and without the script. Use a synthetic measurement tool, such asWebPagetest, to generate waterfall charts for both versions, and identify how long the third-party scripts take to load. Note these benchmarks.

From the third-party vendor, get the number for the average conversion rate increase experienced by other sites that use the tool. 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).

Use this ROI calculation to determine if a specific script ultimately helps your business.

2. Check where third parties are being served from

If most of your visitors are in the UK, but your third-party script is hosted in the US, that could incur a hefty latency delay. Talk to your third-party provider about using a content delivery network (CDN) to cache third-party assets closer to your users.

3a. Design and implement with failure in mind

There’s no such thing as 100% uptime. Everyone has bad days, and third party scripts are no exception. What will happen to your pages if a given script goes down? (You can easily simulate this in WebPagetest under the “SPOF” tab in the advanced settings. ) You need to factor this into design and implementation. Will you serve third party scripts asynchronously? Or alternatively, serve them in a non-blocking fashion? If that’s not an option (as in the case of some analytics tags or ad scripts), then will you set timers on your scripts to allow for a set waiting time before the script times out and the rest of the page can resume loading?

3b. Enable cache timeouts

(Hat tip to Philip Tellis for suggesting this new tip.) Many third-party scripts disable script caching or have very short timeouts (less than an hour). These scripts should have timeouts that span multiple days. This way they can weather spot sales, marketing campaigns, and other traffic spikes.

After you’ve added the script…

4. Measure its impact on performance and your business

This is an evolutionary leap from tip #1 near the top of this post. Instead of using synthetic measurement tools, use your own user data (via real user monitoring tools) to measure the actual impact of third-party tools on your business. This lets you do several great things simultaneously, such as:

1. Determine if the third-party script is slowing down your pages.
2. If the script is slowing down your pages, determine if this slowdown is hurting metrics like bounce rate, time on site, and conversion rate.
3. Regardless of whether or not the third-party script is slowing down your pages, gauge the impact of the script on business metrics, as above.

5. Generate a request map that exposes fourth-party (and fifth-party, and so on) calls

Use a third-party analysis tool to generate a request map and expose extended calls. For example, this request map, generated using Ghostery, illustrates long redirect chains triggered by third-party calls on Monster.com. I looked at the waterfall that this map is based on, and I counted 40+ calls in just one chain — possibly the longest redirect chain I’ve ever seen. (If you’ve seen longer, let me know. I’d love to see it.)

Whether a third-party script triggers a fourth-party call or a fortieth-party call, that call doesn’t just introduce additional latency. It also has the potential to hurt your business — and your users — in other ways:

• Exposes you to data leakage
• Generates content security warnings that alarm your visitors and kill your conversions
• Hurts your Google search rankings (SEO)
• Makes your site vulnerable to man-in-the-middle security attacks

6. Detect when your third-party scripts change

A while back, I shared a dozen performance best practices from Nordstrom. This one really stood out:

Most third-party vendors will go into lockdown along with you during the holidays, but your vendors might not be aware of your special events. They might plan changes that could have an impact on your site.

To illustrate: One year, during Nordstrom’s anniversary sale, Gopal’s team realized that their order management system wasn’t processing orders any more. After much digging, they discovered that the vendor they used for fraud checks had implemented a change to the service just hours before the start of the sale — and this change was blocking all orders. Now Nordstrom lets all vendors know about its anniversary sale well in advance.

7. Give feedback to third-party providers

I’ve been a longtime advocate of this practice. Sometimes third-party vendors don’t know their script is suffering from performance problems. Letting them know is the right thing to do.

Cheats and workarounds

8. Cache social media metrics to simulate social numbers without sacrificing performance

This is a nifty little hack. If social metrics are a must-have on your pages, but you don’t like the performance penalty/risk they can incur, one person in the WebPerfDays breakout session offered this tip. You simply update your metrics periodically or during off-peak times instead of in real time.

9. Instead of using third-party analytics, do your own A/B testing server side

Not everyone has the means to take this on, but if you can, this is a great suggestion from Perry Dyball.

10. Disable the script during peak traffic times

One breakout participant shared that his team simply disabled problematic scripts during known busy times. This one was a bit controversial (no surprise). For example, if the purpose of your script is to give you insights into your customers, then disabling it when many of your customers are visiting your site is obviously not good. Ultimately, WebPerfDays attendees tended to agree that this tactic is okay in an emergency, but not great as standard practice.

What are your pro tips for third-party performance?

This handful of tips was generated by a group of web performance pros in about an hour. While it’s a good start, I’m sure there’s more hard-won wisdom out there. If you have a pro tip that should be added to this list, let me know in the comments.

This article first appeared on the SOASTA Blog.

About the Author

Tammy Everts has spent the past 18 years obsessed with the many factors that go into creating the best possible user experience. For the past several years, her obsession has focused on web/application speed. As a senior researcher and evangelist at SOASTA, Tammy researches the technical, business, and human aspects of web/application performance, and she has shared her findings via countless blog posts, presentations, case studies, articles, and reports. She blogs at The Performance Beacon.