Last week, I had the great privilege of presenting an O’Reilly webcast as part of the lead-up to Velocity Santa Clara. The catch was that I didn’t want to give away what I’ll be presenting at Velocity, so I needed to come up with a brand-new topic. I decided to talk about third-party scripts, for two reasons:

1. I don’t think they get talked about nearly enough. Here we have these itty-bitty snippets of code that can seriously slow down your pages, or even take them out completely, and we spend a correspondingly itty-bitty amount of time talking about them.
2. There’s a fairly easy way to check your pages for potential third-party failure, and I don’t think it gets discussed as widely as it should, either. We can’t fix what we can’t measure. Third-party scripts will continue to be a silent performance killer if we don’t push ourselves to monitor it.

Here are the slides from my talk. You can also watch the webcast recording here.

(Huge, huge, HUGE shout-out to Patrick Meenan for developing both WebPagetest and SPOF-O-Matic — invaluable tools that should be in everyone’s toolbox.)

During the Q&A session at the end of the webcast, I got some good questions, so I’m including the answers here.

What is the source for the 1s = 7% lower conversion = 11% less page views = 16% less satisfaction graphic?

The question refers to this graphic, created back in my Strangeloop days (Strangeloop was acquired by Radware in 2013), to illustrate some cool findings by Aberdeen Group.

The Aberdeen report — titled “The Performance of Web Applications: Customers are Won or Lost in One Second” — is no longer available online, but you can contact them to request it. This report is also the source of the much-quoted statement “In dollar terms, this means that if your site typically earns $100,000 a day, this year you could lose $2.5 million in sales.”

What is your opinion on adding an onload eventhandler to load non-critical third parties when everything is ready?

The person who asked this question referred to this post from Philip Walton. Philip makes a strong case for why you should hand-code your third-party scripts, and why it’s not that hard to do. He also walks through the process for implementing your own script loader. At the end of the day, he urges people to understand the pros and cons of the various ways of implementing third parties and make the best choice for their pages.

Are deferred/async scripts a new feature, i.e. what’s the support for older browser like IE 8?

Deferral has been around for a while. It’s not a feature so much as a best practice. More info on deferring JavaScript on the Google Dev site.

These are the browser versions that support the “async” attribute on a script tag:

• Internet Explorer 10+
• Chrome 11+
• Safari 5+
• Firefox 3.6+

Speaking of async scripts, here’s an interesting GitHub entry for Lazy Ads: “Deliver synchronous ads asynchronously without modifying the ad code. Conditionally load ads for responsive layouts using the ad container’s dimensions, or a media query.”

But as I mentioned in the webcast, async scripts aren’t a cure-all. Ilya Grigorik talks about some of the caveats of script-injected asynchronous scripts.

Takeaway

This webcast was intended to give a high-level introduction to third-party performance and to help people begin to get a bead on their own scripts. For a deeper dive, check out the links I cite in this post and in my slides. If you’re curious about how Radware FastView addresses third-party performance, let me know.