Scripts de Terceros: Sobreviviendo al Salvaje Oeste de la Web

Hola a todos. Gracias por sintonizar. Soy Anton Zaldinov, un ingeniero de software senior en la empresa. Hoy, estoy emocionado de llevarlos en el viaje hacia los scripts de terceros, sobreviviendo al salvaje oeste de la web. Exploraremos los desafíos y recompensas únicos de construir código que se ejecuta en el sitio web con uno propio.

Así que un poco sobre mí. Trabajo en la empresa, y mi enfoque principal es Affirm.js, que es nuestra principal biblioteca de scripts de terceros. Mi día a día implica escribir y mantener el script, asegurando que funcione de manera confiable y segura en miles de sitios web, entornos que están completamente fuera de nuestro control. Y cuando hablo de riqueza, Affirm.js opera a gran escala en muchos sitios web diferentes.

Este gráfico, por ejemplo, muestra el seguimiento de eventos específicamente de Affirm.js. Estamos viendo alrededor de 93 millones de eventos diarios. Este volumen subraya por qué el desarrollo robusto y la comprensión de los paisajes de terceros son tan cruciales. El ciclo de vida de un script de terceros comienza con el desarrollo local, donde simulamos los diversos desarrollos web que encontrará. Luego creamos el fragmento HTML para los propietarios del sitio web.

El despliegue involucra minificaciones, CDNs y versionado. El integrador lo incrusta, y nuestro trabajo continúa con la monitorización y el mantenimiento. Esta fase de monitorización y mantenimiento es altamente iterativa, a menudo involucrando bucles de retroalimentación de los integradores y datos de rendimiento para impulsar más mejoras y asegurar la estabilidad a largo plazo. Veamos más de cerca el desarrollo. Desplegar localmente significa replicar la realidad de dominios cruzados. Una técnica clave que uso extensivamente es las anulaciones locales de Chrome DevTools. Esto me permite ir a un sitio web integrado real que ya está usando nuestro script y decirle a mi navegador que reemplace la versión en vivo, desplegada de los scripts de terceros con la versión que se ejecuta desde mi máquina local.

Esto es útil para probar nuevas características y correcciones de errores en un entorno de comercio electrónico complejo antes de que se publiquen. Crucialmente, esta prueba en vivo detecta problemas complicados, como conflictos de CSS o scripts, en la página en vivo del integrador que las configuraciones simuladas a menudo pasan por alto. Este fragmento de script es un apretón de manos entre el proveedor del script de terceros y el integrador. Aquí está nuestro ejemplo. Notarás que este script se carga con Async. Aunque este script específico lo maneja, es vital que los desarrolladores e integradores comprendan Async y defer al tratar con un script de terceros. Async se descarga sin bloquear el análisis de HTML y se ejecuta cuando está listo, potencialmente interrumpiendo el análisis. Defer también se descarga sin bloquear, pero espera para ejecutarse hasta el análisis de HTML. En orden, ambos son clave para el rendimiento.

Si hay una conclusión principal, es esta. Cualquier script de terceros se ejecuta en un entorno que sus desarrolladores fundamentalmente no controlan en muchos sitios web diferentes. Este hecho es la fuente de la mayoría de los desafíos únicos. Enfrentamos como desarrolladores de scripts de terceros. Significa que no podemos hacer ninguna suposición sobre el JavaScript existente, CSS, o incluso la estructura HTML de las páginas donde nuestro código se ejecutará. Esta incertidumbre dicta todo nuestro enfoque para diseñar, desarrollar y probar. Cada integración es un conjunto potencial de nuevas variables, haciendo que el código robusto y aceptable no sea solo un objetivo, sino una necesidad para sobrevivir en este ecosistema complejo.

Aquí hay un ejemplo concreto de mi experiencia. Este código muestra window fetch, una API estándar del navegador, siendo completamente sobrescrita por otro script en una página anfitriona. Nuestro script, esperando un comportamiento normal del espacio de trabajo, de repente encuentra los años o falla silenciosamente. Esto resalta por qué los desarrolladores de scripts de terceros deben codificar de manera defensiva y anticipar que el entorno global podría no estar en su estado predeterminado. Más allá de los nativos modificados, los desarrolladores de terceros navegan constantemente por el espacio de nombres global, una compleja red de posibles colisiones de variables. La carga de la página es otro desafío común. Los elementos de la interfaz de usuario de un script deben verse bien y funcionar correctamente a pesar del diverso CSS de la página anfitriona. El rendimiento es primordial. Los scripts de terceros deben ser altamente eficientes para minimizar el impacto en los tiempos de carga de la página. Considere que la carga útil media de JavaScript en 2024 es de más de 550 kilobytes en un móvil, y una buena parte de eso a menudo proviene de fuentes de terceros, por lo que cada byte cuenta. Y luego está la depuración, cuando un problema solo aparece en el sitio de un integrador específico de los miles. Reproducir y diagnosticar eso puede ser una verdadera historia de detectives para un desarrollador de scripts. La seguridad es una prioridad principal para cualquier script de terceros. La seguridad es crucial para proteger contra vulnerabilidades.

Los desarrolladores también consideran los scripts de cuarta parte de las dependencias. Además de eso, el panorama de privacidad está siempre en evolución. La eliminación gradual de cookies de terceros, impulsada por las crecientes preocupaciones de privacidad de los usuarios y las presiones regulatorias, impacta significativamente en los métodos tradicionales de seguimiento y personalización. Este cambio requiere que todos los desarrolladores web, especialmente aquellos que trabajan con contenido incrustado, dominen nuevas APIs de navegador como Chips o Storage Access API, para construir soluciones centradas en el usuario que respeten la privacidad.

Entonces, ¿cómo sobreviven y prosperan los desarrolladores de scripts de terceros? Primero, la carga eficiente de scripts. Usar async y defer de manera adecuada. También es crucial minimizar el tamaño del script. Técnicas como tree shaking o code splitting son vitales, ayudando a asegurar que solo el JavaScript necesario se envíe al cliente, reduciendo los tiempos de carga.

Segundo, fuertes muros para la encapsulación. Usar Shadow DOM, por ejemplo, permite a los desarrolladores crear árboles DOM aislados para sus scripts de UI. Esto significa que los estilos definidos dentro del Shadow DOM no se filtran en la página principal y el sistema de página global no rompe la inferencia del componente. Así que reduce drásticamente los conflictos del sistema y la interferencia de JavaScript de la página anfitriona. La codificación defensiva es innegociable para los scripts de terceros.