Scripts de terceros que cargan antes, después o nunca
Analítica, chat de soporte, mapas, publicidad. Código que no controlás, que se ejecuta en tu página y que puede no llegar. Qué se comenta en una review cuando una funcionalidad depende de algo que carga cuando quiere.
Una página de producto real carga varios scripts que no escribió nadie del equipo: medición, chat, mapas, pagos, publicidad. Cada uno se ejecuta con los mismos permisos que el código propio, y cada uno puede tardar, fallar o no cargar nunca porque una extensión lo bloqueó.
El comentario de review es siempre la misma pregunta: ¿qué pasa con esta funcionalidad si ese script no está?
Las cuatro formas en que un tercero falla
| Falla | Cómo se manifiesta | Qué se rompe si no está contemplada |
|---|---|---|
| No carga | Bloqueado por una extensión o por la red | El código que usa su objeto global lanza y corta el resto |
| Carga tarde | Llega después de que la página ya interactuó | Eventos perdidos: se mide menos de lo que pasó |
| Carga y falla adentro | Una excepción propia del tercero | Si comparte el manejador de errores, ensucia el monitoreo propio |
| Carga y bloquea | Ocupa el hilo principal | La página no responde al clic aunque se vea completa |
Un detalle que sorprende la primera vez: una porción significativa de los usuarios bloquea scripts de medición. Si una funcionalidad del producto depende de la analítica para funcionar, esa funcionalidad no existe para esa gente.
Las reglas que se piden en la review
Cinco cosas concretas
- Nunca asumir el objeto global. Chequear antes de usarlo, y que la ausencia sea un camino normal y no un error capturado por casualidad.
- Cargar sin bloquear. Los scripts de terceros van diferidos o asíncronos; la página se tiene que poder usar sin ellos.
- Encolar lo que pasa antes de que carguen. Los eventos ocurridos antes se guardan en una cola local y se envían cuando el script llegue —o se descartan si nunca llega—.
- Envolver el acceso en una capa propia. Que el resto de la aplicación no sepa qué proveedor es. Además de aislar la falla, permite cambiarlo sin tocar veinte archivos.
- No mezclar el monitoreo de errores. Los errores del tercero no tienen que aparecer como errores propios ni al revés.
El costado que no es de robustez
Un script de terceros corre con los mismos permisos que el propio: puede leer el documento, los campos de un formulario y lo que haya en el almacenamiento accesible.
Antes de seguir, predecí
De ahí sale una regla simple para pantallas sensibles: en la página donde se ingresan datos de pago o credenciales, cuantos menos terceros, mejor. Es un caso donde la decisión de producto y la de seguridad coinciden.
El costo que nadie atribuye
Los terceros son la causa más frecuente de una página lenta, y la más difícil de ver en las métricas propias, porque el tiempo se gasta en código ajeno.
Lo que ayuda es medir con y sin ellos, y tener un dueño por cada script: quién lo pidió, para qué y hasta cuándo. Sin eso se acumulan igual que las banderas de experimento: nadie sabe si el de hace tres años todavía lo usa alguien.
Más a fondo · nivel seniorEl inventario de terceros
En productos grandes conviene una lista explícita: qué scripts se cargan, quién es el dueño interno, qué datos ve cada uno y qué pasa si se cae. Sirve para tres cosas a la vez: rendimiento, privacidad —hay obligaciones legales sobre qué se comparte y con quién— y respuesta a incidentes, porque cuando un proveedor tiene un problema la pregunta urgente es qué páginas lo cargan.
Qué pasa si ese script no está
Los cinco scripts que carga una página de producto. Ninguno lo escribió el equipo.
Cómo se convive con lo que no se controla
Cierre
Autoevaluación
¿Lo entendiste?
Práctica