Third-Party Scripts: Surviving the Wild West of the Web

Hi, everyone. Thanks for tuning in. I'm Anton Zaldinov, a senior software engineer at the firm. Today, I'm excited to take you for the journey into the third-party scripts, surviving the wild west of the web. We'll explore the unique challenges and rewards of building code that runs on the website with an own.

So a bit about me. I work at the firm, and my primary focus is Affirm.js, which is our main third-party script library. My day-to-day involves writing and maintaining the script, ensuring it performs reliably and securely across thousands of the websites, environments that are completely outside of our control. When I talk about rich, Affirm.js operates at significant scale across many different websites.

This graph, for instance, shows event tracking specifically from Affirm.js. We're looking at around 93 million daily events. This volume underscores why robust development and understanding third-party landscapes are so crucial. The lifecycle of a third-party script starts with the local development, where we simulate varied web developments it will encounter. Then we craft the HTML snippet for the website owners.

Deployment involves minifications, CDNs, and versioning. The integrator embeds it, and our job continues with monitoring and maintenance. This monitor-and-maintain phase is highly iterative, often involving feedback loops from integrators and performance data to drive further improvements and ensure long-term stability. Let's look closer at development. Deployment locally means replicating the cross-domain reality. A key technique I use extensively is Chrome DevTools local overrides. This allows me to go to an actual integrated website that's already using our script and tell my browser to replace the live, deployed version of the third-party scripts with the version running from my local machine.

This is useful for testing new features and bug fixes in a complex e-commerce environment before they go live. Crucially, this live testing catches tricky issues, like CSS or script conflicts, on the integrator live page that mock setups often overlook. This script snippet is a handshake between the third-party script provider and the integrator. Here's our example. You will notice this script is loaded with Async. While this specific script handles it, it's vital for developers and integrators to understand Async and defer when dealing with a third-party script. Async downloads without blocking HTML parsing, and executes when ready, potentially interrupting parsing. Defer also downloads without blocking, but waits to execute until HTML parsing. In order, both are key for performance.

If there is one core takeaway, it's this. Any third-party script executes in an environment its developers fundamentally do not control on many different websites. This fact is the source of most unique challenges. We face as third-party script developers. It means we can make any assumptions about existing JavaScript, CSS, or even the HTML structure of the pages where our code will run. This uncertainty dictates our entire approach to design, develop, and testing. Every integration is a potential new set of variables, making robust, acceptable code not just a goal, but necessity for survival in this complex ecosystem.

Here's a concrete example from my experience. This code shows window fetch, a standard browser API, being completely overridden by another script on a host page. Our script, expecting normal workspace behavior, suddenly encounters the years or fails silently. This highlights why third-party script developers must code defensively and anticipate that global environment might not be in its default state. Beyond modified natives, third-party developers constantly navigate the global namespace, a complex web of potential variable clutches. Page loading is another common challenge. UI elements from a script must look right and function correctly despite the diverse host page CSS. Performance is paramount. Third-party scripts must be highly efficient to minimize the impact on page load times. Consider that median JavaScript payload in 2024 is over 550 kilobytes on a mobile, and a good chunk of that often comes from third-party sources, so every byte counts. And then there's debugging, when an issue only appears on a specific integrator's site out of the thousands. Reproducing and diagnosing that can be a real detective story for a script developer. Security is a top priority for any third-party script. Security is crucial to protect against vulnerabilities.

Developers also consider fourth-party scripts from dependencies. On top of that, the privacy landscape is always evolving. The phase-out of third-party cookies, driven by growing user privacy concerns and regulatory pressures, significantly impacts traditional methods for tracking and personalization. This shift requires all web developers, especially those working with embedded content, to master new browser APIs like Chips or Storage Access API to build user-centric solutions that respect privacy.

How do third-party script developers survive and thrive? First, efficient script loading is crucial, using async and defer appropriately to minimize script size. Techniques like tree shaking or code splitting are vital to ensure only necessary JavaScript is sent to the client, reducing load times. Second, strong walls for encapsulation are essential. Shadow DOM allows developers to create isolated DOM trees for their UI scripts, reducing system conflicts and JavaScript interference from the host page.

Defensive coding is non-negotiable, as developers must check global objects and use feature detection. Bundling all dependencies using tools like Webpack helps isolate the content of the script, while designing for security from the start is key. Testing is critical, going beyond standard tuning and integration tests to simulate diverse web conditions. Developing third-party scripts is a unique adventure with challenges but also rewarding, powering crucial functionalities across the web. The job of the third-party script developer is to ensure their script works well on every website.