My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts. No matter how solid I think my prototype is, it doesn’t absolve me from paying attention to what happens during implementation, specifically when it comes to the addition of these third-party scripts.
I recently had a conversation with a friend working on quite a high profile e-commerce site. They were hired to develop the site, but particularly with performance in mind. They were going the PWA route, but were immediately hamstrung by third-party scripts. One of them, apparently unavoidably, couldn’t be HTTPS, meaning the site was immediately disqualified from being a PWA. They could still do a good job in many other areas, but right and left their great performance work was slaughtered by third-party scripts. I don’t envy being in that position.
It’s often the fault of “tag managers.” There are a bunch of them out there. Here’s a marketing pitch for one of them:
Marketers want tag management that’s simple, reliable, and integrates easily with existing systems … You’ll launch programs faster, so you can make swifter decisions.
In other words, “Give your marketing team the ability to add whatever third-party JavaScript they want quickly without having to go through your normal deployment process.” I can understand why they are needed in some organizations, but it still sends chills up my spine.
Third-party scripts could conceivably be a part of a design style guide. Right alongside your buttons and modals could be a list of the third-party scripts in place on a site. Brad Frost:
The idea is that someone (or as Trent points out, some *thing*) could hypothetically crawl through all the included scripts on a site, and display them in the in style guide alongside all the color swatches, icons, UI components, etc. After all, they affect the end user experience just as much (if not more) than all those other design elements. You can visually weight them based on how gnarly they are and thus have thoughtful conversations with your team — especially those folks are carelessly chucking in all these performance-damning scripts — about the pros and cons of each script that gets included.
Third-party scripts are probably the #1 cause of poor performance and bad UX on the web. It’s no wonder things like AMP exist. The fact that it disallows third-party scripts is probably the largest contributor to it making sites fast. Controversial as hell, though, in its other choices.
As fate would have it, third-party JavaScript is even more dangerous than it ever has been, thanks to Spectre and Meltdown. Jorgé:
Q: Is JavaScript vulnerable in my browser?
A: Yes, browsing a web can give access to third parties to your machine’s memory beyond the browser.
😳
More on Third-Party JavaScript
If you, like Trent, are planning to bone up on your third-party JavaScript chops, here’s a bunch of stuff from other developers in the past few years digging into it all. Some of this is targeted at you being the deliverer of the third-party JavaScript.
Third Party JavaScript (In the Third Person) Slides by Alex Sexton
On Third-Party Javascript – The Principles by Gergely Nemeth
When serving third-party JavaScript applications the size of it and the cache policy are crucial, as both not just affect the time your users have to wait to see the application, but also your monthly bills.
See also: Writing third-party Javascript the integration part in a nutshell.
Third-Party Javascript by Ben Vinegar and Anton Kovalyov
Things to Know (and Potential Dangers) with Third-Party Scripts by Yaphi Berhanu
The web is full of third-party scripts. Sites use them for ads, analytics, retargeting, and more. But this isn’t always the whole story. Scripts can track your behavior, your preferences, and other information.
I’m harvesting credit card numbers and passwords from your site. Here’s how. by David Gilbertson
My goal is simply to point out that any site that includes third party code is alarmingly vulnerable, in a completely undetectable way.
Ain’t No Party Like A Third-Party JS Party by Rebecca Murphey
You thought you had the hang of this whole JavaScript thing, but now you’re in the world of third-party JavaScript, where all you control is a single script tag and where it’s all but impossible to dream up every hostile environment in which your code will be expected to work. “It works on my machine” has never rung quite so hollow. In this talk, we’ll take a look at some of the delightful bugs we’ve had to solve at Bazaarvoice while working on the third-party JavaScript app that collects and displays ratings and reviews for some of the world’s largest retailers.
(Subscription required)
3rd Party Javascript Management Cheat Sheet
The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
- The loss of control over changes to the client application,
- The execution of arbitrary code on client systems,
- The disclosure or leakage of sensitive information to 3rd parties.
I’m a third party script author and have written a bit about being a good 3rd party provider. This one is about allowing your clients to measure your performance: http://www.lognormal.com/blog/2017/07/25/a-study-of-timing-allow-origin/ while this one is about the most performant way to load your 3rd party script into the page (to be updated soon): http://www.lognormal.com/blog/2012/12/12/the-script-loader-pattern/
According to Google guidelines we have to avoid third party scripts as possible as.
There’s no choice at all. An e-commerce site must run over https, so either the 3rd party fixes their broken mess, or an alternative is found. If I saw an e-commerce site today not using https, I would not use it.