Construye un inventario único a partir de lo que carga el navegador
Empieza con páginas representativas: inicio, landing, detalle, búsqueda, carrito, pago, cuenta y campañas. Registra visitas nuevas y de retorno en Chrome DevTools. Compara la evidencia del navegador con el gestor de etiquetas, los complementos del CMS y las dependencias del código; una única vista puede pasar por alto scripts inyectados.
Usa una fila por proveedor o integración, no solo por URL. Captura los dominios con los que se comunica y si puede añadir etiquetas. Asígnale un responsable de negocio que pueda defender el propósito y aprobar la retirada. Revisa después de campañas, cambios de proveedor, publicaciones de plantillas y rediseños.
Guarda la página, el recorrido, dominios del proveedor, peticiones, tamaño transferido, trabajo en el hilo principal y condiciones de prueba. Un trazo en laboratorio es evidencia diagnóstica, no una promesa para cada visitante.
Incluye propósito, responsable, categoría de consentimiento, disparador, datos expuestos, orden de dependencias, fallback y fecha de revisión.
Haz visibles las decisiones de conservar, eliminar y presupuestar
Pregunta a cada responsable qué sería peor si la integración desapareciera. Si la respuesta es vaga, desactívala o elimínala. web.dev recomienda presupuestos, evitar funciones duplicadas y limpiar scripts redundantes.
Un presupuesto es una guía de equipo, no un umbral universal. Define límites por proveedor y por página para bytes, peticiones, tiempo en el hilo principal y tiempos de carga. Compara la línea base con el cambio. Exige al responsable que se mantenga dentro del margen, retire otro coste o obtenga una excepción con fecha de caducidad. Usa recorridos comparables y métricas centradas en el usuario.
Conserva solo las dependencias con un propósito actual, coste y uso de datos aceptados por su responsable y una ruta de fallo aceptable.
Retira píxeles caducados, analíticas duplicadas, chat inactivo, experimentos sin uso y complementos abandonados mediante una publicación escalonada.
Registra la razón, el coste, el aprobador, la acción compensatoria y la fecha de revisión.
Carga tarde solo cuando retrasar sea seguro
Elige el comportamiento de carga deliberadamente. Un script externo clásico sin async, defer o comportamiento de módulo se descarga y ejecuta antes de que continúe el parseo de HTML. Con async, la descarga se hace en paralelo pero la ejecución comienza cuando está listo, por lo que el orden no está garantizado. Con defer, los scripts clásicos externos se ejecutan después del parseo y en orden de documento, antes de DOMContentLoaded. Defer encaja con scripts ordenados; no es universal.
Para interfaces opcionales de chat, social, mapas, vídeo o recomendaciones, renderiza un marcador ligero y carga al proveedor después de un clic o cuando sea relevante. Este patrón de fachada comienza bajo tu control en lugar del incrustado completo. Preserva la interacción por teclado y reserva espacio. No difieras código necesario para calcular precio, iniciar sesión, procesar pago, proporcionar accesibilidad esencial o cumplir una obligación confirmada sin una alternativa revisada.
Carga inmediatamente solo para la dependencia de la primera tarea; usa post-parseo para código ordenado y triggers de interacción o visibilidad para incrustaciones opcionales.
No marques scripts interdependientes como async esperando que el orden se mantenga. Documenta y prueba la cadena publicada.
No relaciones la UI crítica con window load; las incrustaciones de terceros pueden retrasarlo incluso cuando se usa async o defer.
Haz del consentimiento la puerta, no una ocurrencia tardía
Clasifica cada proveedor con stakeholders de privacidad y legal que entiendan jurisdicciones y flujos de datos. Para una integración sujeta a consentimiento, establece el estado de consentimiento antes de que la etiqueta envíe datos relevantes. Google indica que su comando de consentimiento por defecto debería ejecutarse antes de los comandos de medición, y las actualizaciones deben seguir a un cambio de elección. Esta guía de producto no es asesoría legal.
Prueba la primera visita sin elección, con aceptación, con rechazo y con retirada. Revisa la interfaz y la red: un widget oculto no demuestra que no se haya enviado una petición o identificador. Si la plataforma de consentimiento se carga de forma asíncrona, prueba los tiempos. Persiste las elecciones adecuadamente y aplica los cambios en la página actual y en visitas futuras.
No confíes en la etiqueta del proveedor. Registra por qué la etiqueta es esencial, opcional o prohibida para una región o recorrido y obtén aprobación.
Tras la retirada, confirma que las etiquetas no esenciales configuradas no se cargan ni envían datos y guarda la evidencia de prueba.
Reduce el radio de impacto del código que no controlas
OWASP identifica la pérdida de control sobre cambios en el cliente, la ejecución de código arbitrario en navegadores y la divulgación de datos sensibles como riesgos centrales. Limita el acceso a publicación de etiquetas, revisa HTML personalizado o funciones de código arbitrario y documenta los campos de data-layer permitidos. Los acuerdos con proveedores y una revisión de seguridad cualificada pueden ayudar para integraciones de alto riesgo; ninguno sustituye las pruebas.
Subresource Integrity, o SRI, permite que el navegador verifique un script frente a un hash criptográfico. Ayuda solo cuando un recurso puede fijarse y la entrega cross-origin soporta CORS; W3C dice que usar SRI sin CORS es un error lógico. Es poco adecuado para muchas URLs de proveedores que cambian. Un iframe sandbox puede reducir el acceso directo al DOM y a las cookies del host, pero requiere revisión especializada. Flujos de pago y sensibles en seguridad merecen una revisión cualificada.
Pasa solo los campos documentados y necesarios para el propósito. No expongas secretos, datos de pago ni atributos de clientes innecesarios.
SRI verifica bytes, no si el uso de datos o las solicitudes posteriores son apropiadas; el aislamiento no es una solución universal.
Ensaya la falla del proveedor antes de que la encuentren los clientes
Para cada proveedor retenido, bloquea sus dominios en un entorno de pruebas o con un bloqueador de peticiones del navegador y luego ejecuta el recorrido. También prueba respuestas lentas y una configuración del gestor de etiquetas sin la integración. Confirma que el contenido principal, la navegación, formularios, checkout y acceso a cuenta se comporten como se pretende. Esto expone suposiciones antes de la publicación.
Define la remediación antes de un incidente: quién puede deshabilitar la etiqueta, si se requiere una bandera o una publicación en el gestor de etiquetas, cómo hacer rollback y cómo verificar. SIU es optimización proactiva de disponibilidad y remediación: usa inventario, presupuestos, preflight y ensayos de rollback para reducir el riesgo de dependencias. SIU no puede controlar la infraestructura del proveedor, garantizar disponibilidad ni sustituir la revisión.
Declara qué sigue siendo usable sin el proveedor, qué puede degradarse, el fallback y el retraso máximo antes de desactivarlo.
Adjunta un trazo antes y después, resultado de consentimiento, resultado con proveedor bloqueado y propietario del rollback al registro del cambio.