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.
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.
A: Yes, browsing a web can give access to third parties to your machine’s memory beyond the browser.
amzn_assoc_tracking_id = “csstricks-20”;
amzn_assoc_ad_mode = “manual”;
amzn_assoc_ad_type = “smart”;
amzn_assoc_marketplace = “amazon”;
amzn_assoc_region = “US”;
amzn_assoc_design = “enhanced_links”;
amzn_assoc_asins = “1617290548”;
amzn_assoc_placement = “adunit”;
amzn_assoc_linkid = “5b25672b1eb04d67cf22c6b254ad7924”;
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
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.