Para reducir el coste de los scripts de terceros, identifica qué servicios se cargan, mide su efecto sobre tareas reales y elimina o retrasa el trabajo que el visitante no necesita de inmediato. async y defer cambian la programación, pero no eliminan el coste de ejecución. Una auditoría útil continúa después de la carga inicial: incluye las decisiones de consentimiento, la selección de productos, las búsquedas y el soporte.
Un script puede aportar valor comercial y cargarse en el momento equivocado. La decisión práctica consiste en determinar qué páginas e interacciones lo necesitan, quién es responsable y cómo funciona el sitio cuando el servicio no está disponible.
Crea un inventario que incluya los scripts añadidos indirectamente
Empieza con plantillas representativas: una página de destino, un artículo, una ficha de producto y, cuando corresponda, el acceso al pago. Abre el panel Network de Chrome DevTools y registra una navegación nueva. Examina dominios, tipos de recursos e iniciadores. Un pequeño script inicial puede descargar muchas dependencias: registra el servicio y sus descendientes, no solo el primer archivo.
Repite la prueba después de aceptar el seguimiento opcional, abrir el chat y reproducir contenido integrado. Compara con el estado anterior al consentimiento. Incluye contenedores de gestión de etiquetas, etiquetas insertadas directamente, aplicaciones, marcos y código del gestor de contenidos. Una lista de dominios es un punto de partida, pero una URL propia también puede servir código de un proveedor.
Anota la finalidad, el responsable, las plantillas afectadas, el desencadenante de carga y el procedimiento de retirada de cada servicio. Registra por separado los datos transferidos, la actividad de CPU y el comportamiento visible. Una descarga pequeña puede ejecutar mucho trabajo; una transferencia multimedia grande puede consumir ancho de banda sin producir el mismo patrón de ejecución de JavaScript.
No recopiles identificadores de clientes. Para reproducir una prueba necesitas el escenario y la configuración, no información privada de una compra. Guarda trazas depuradas y documenta la versión del navegador, el tamaño de pantalla, la red y el estado del consentimiento.
Compara ejecuciones controladas antes de atribuir el problema
Registra una referencia y utiliza el bloqueo de solicitudes de DevTools para impedir que se cargue una URL o un dominio sospechoso. Recarga y realiza las mismas acciones. Restablece la solicitud y repite la comparación. Haz varias ejecuciones con las mismas condiciones: las respuestas externas, la caché y el trabajo en segundo plano varían.
Bloquear es un experimento de diagnóstico. Si desaparece un configurador de productos, el resultado más rápido no representa una alternativa aceptable. Documenta la funcionalidad perdida junto al cambio de rendimiento. Bloquear un gestor de etiquetas también puede eliminar varios proveedores a la vez; examina sus dependencias antes de atribuir toda la diferencia al contenedor.
Lee la grabación de Performance junto a la cascada de solicitudes. Localiza tareas largas y examina funciones, URLs e interacciones cercanas. Para problemas de respuesta, sigue el procedimiento de diagnóstico de INP. Una navegación estándar de Lighthouse ayuda a explicar carga y bloqueo, pero no reproduce todo el recorrido interactivo de un cliente.
Los informes antiguos incluyen la auditoría “Reduce the impact of third-party code”. La documentación de Chrome indica que dejó de ser una auditoría independiente en Lighthouse 13. Su antiguo umbral de 250 ms no es un presupuesto universal ni garantiza nombres idénticos en informes actuales. Comprueba la versión y combina sus diagnósticos con la traza del navegador.
Elige el primer momento en que la función sea necesaria
Adapta la política de carga a la función. Esta comparación describe scripts externos clásicos; los módulos tienen un comportamiento predeterminado diferente.
| Estrategia | Cuándo resulta útil | Coste o riesgo pendiente |
|---|---|---|
| Retirar la integración | Su finalidad ha caducado o está duplicada | Comprobar los procesos dependientes |
defer |
Necesita HTML analizado y ejecución ordenada | Sigue utilizando el hilo principal |
async |
No depende del orden del documento | Puede ejecutarse durante trabajo importante |
| Cargar cerca del área visible | El contenido se utiliza más abajo | Puede descargarse antes de ser necesario |
| Cargar tras una acción deliberada | El video, mapa o chat es opcional | Hay que esperar su inicialización |
| Cargar tras el consentimiento correspondiente | El servicio configurado necesita ese permiso | Aceptar puede iniciar mucho trabajo simultáneo |
Consulta la integración documentada por el proveedor antes de cambiar atributos. Un inicializador en línea que presupone la existencia de una biblioteca puede fallar si esta pasa a ser asíncrona. Ocultar el error no resuelve el problema: verifica que los eventos lleguen una sola vez, en el orden previsto y con el consentimiento correcto.
Evita una regla general de “cargar todo después de la primera interacción”. Puede trasladar el trabajo exactamente al clic que deseas acelerar. Un temporizador arbitrario también cambia el momento del coste sin demostrar que sea adecuado. Primero reduce etiquetas, limita las páginas y simplifica las funciones.
Sustituye las integraciones opcionales por una fachada accesible
Una fachada representa una función con un elemento ligero que solo carga la integración real cuando se solicita. Las buenas prácticas de contenido integrado de Google describen este patrón. Su utilidad consiste en evitar inicializaciones que muchos visitantes nunca necesitan.
Este HTML ilustrativo crea un botón accesible mediante teclado y reserva espacio para el marco. Sustituye la dirección de ejemplo por una URL autorizada que permita su integración y adapta las etiquetas visibles al idioma del sitio.
<div class="media-slot" id="media-slot">
<button type="button" id="load-media">Load product video</button>
</div>
<p id="media-status" role="status"></p>
<style>
.media-slot { aspect-ratio: 16 / 9; background: #edf2f7; }
.media-slot iframe { width: 100%; height: 100%; border: 0; }
</style>
<script type="module">
const button = document.querySelector('#load-media');
const slot = document.querySelector('#media-slot');
const status = document.querySelector('#media-status');
button.addEventListener('click', () => {
button.disabled = true;
status.textContent = 'Loading video';
const frame = document.createElement('iframe');
frame.title = 'Product video';
frame.src = 'https://example.com/embed/product-video';
frame.allowFullscreen = true;
frame.addEventListener('load', () => {
status.textContent = 'Video frame loaded';
});
slot.replaceChildren(frame);
frame.focus();
}, { once: true });
</script>Es un patrón de carga, no una integración completa de un reproductor. El evento load no demuestra que un reproductor de otro origen sea utilizable; emplea la API de disponibilidad del proveedor cuando exista. En producción, añade un enlace alternativo y una vía de recuperación. Revisa Content Security Policy, permisos y consentimiento antes de crear el marco.
La proporción reservada debe coincidir con la integración final. De lo contrario, la inserción diferida puede sustituir una carga lenta por un salto visible. Aplica el mismo criterio a anuncios y paneles de chat mediante la guía para evitar desplazamientos de diseño. Prueba el botón con teclado y comprueba el foco después del reemplazo.
Carga el chat una sola vez y permite recuperarse de errores
Para un widget basado en scripts, conserva una única promesa de carga: así varios clics no insertan scripts duplicados. El siguiente ejemplo solo muestra el cargador. Adapta la URL y la señal de disponibilidad del proveedor; descargar el script no implica necesariamente que el chat esté listo.
let chatScriptPromise;
export function loadChatScript() {
if (chatScriptPromise) return chatScriptPromise;
chatScriptPromise = new Promise((resolve, reject) => {
const script = document.createElement('script');
script.src = 'https://example.com/widgets/chat.js';
script.async = true;
script.onload = () => resolve();
script.onerror = () => {
script.remove();
chatScriptPromise = undefined;
reject(new Error('Chat script could not be loaded'));
};
document.head.append(script);
});
return chatScriptPromise;
}Llama a esta función desde el manejador del botón después de comprobar el permiso necesario. Muestra un estado de carga, captura el rechazo y ofrece otra vía de contacto. Impide activaciones repetidas mientras carga y abre el widget mediante su API documentada. No inventes un método global ni simules una inicialización correcta.
Mide tanto la primera activación como los mensajes posteriores. Un cargador pequeño no convierte el widget descargado en ligero. Si el proveedor realiza un arranque síncrono largo, consulta si dispone de una integración reducida o una inicialización por etapas. La guía para reducir el tiempo de ejecución de JavaScript distingue entre descargar menos código y programar mejor su ejecución.
Trata los cambios de consentimiento como escenarios de rendimiento
Prueba al menos tres recorridos: sin permiso opcional, con permiso y con un cambio posterior. Revisa las solicitudes además del aspecto del aviso. Un banner visualmente correcto puede coexistir con una integración que el tema ya había inicializado por otra vía.
El control del consentimiento y el de carga están relacionados, pero no son equivalentes. Configura la política aprobada del sitio y el modo compatible del proveedor; defer no impide por sí mismo la recogida de datos. Si una función exige permiso, aplica la condición antes de inicializarla. Abrir un video o chat no concede necesariamente todos los permisos que solicite el proveedor.
Al aceptar, actualiza la interfaz con rapidez y evita inicializar todas las funciones opcionales dentro del mismo manejador síncrono. Conserva el orden necesario y documenta las mediciones que se pierdan al retrasar la analítica. Un conjunto de datos menor puede ser una decisión consciente; afirmar sin pruebas que la recogida diferida es idéntica no lo es.
Prueba también el rechazo y la retirada. Eliminar la etiqueta de un script no deshace código ejecutado, temporizadores ni solicitudes. Utiliza las interfaces de limpieza y actualización del proveedor. Esta es una auditoría de implementación, no una afirmación de cumplimiento en todas las jurisdicciones.
Evita que el gestor de etiquetas se convierta en otra aplicación
Exporta o revisa la configuración del contenedor con el equipo responsable. Busca instalaciones analíticas duplicadas, campañas caducadas, reglas amplias de “todas las páginas”, HTML personalizado repetido y escuchadores que se activan más de lo necesario. Comprueba si una aplicación de la plataforma ya envía el mismo evento.
Define el contrato de eventos antes de reescribir las reglas. Para una compra, acuerda nombre, punto de envío e identificador de deduplicación sin incorporar pedidos reales a la documentación. Verifica el comportamiento en las herramientas del proveedor y en la red. Una página más rápida que cuenta dos veces una transacción no está resuelta.
El etiquetado en servidor puede trasladar parte del procesamiento fuera del navegador, pero no elimina automáticamente los recolectores del cliente. Trátalo como un cambio de arquitectura con requisitos propios de datos y operación. Mide el código restante en el navegador.
Decide de forma explícita sobre alojamiento propio y cambios de proveedor
Alojar un script en tu infraestructura puede modificar conexiones y caché, pero no reduce por sí solo sus cálculos. Revisa licencia, actualizaciones y requisitos del proveedor antes de copiarlo. Asigna la responsabilidad de seguridad y compatibilidad. Un archivo congelado no es una optimización sostenible si cambia la API remota.
No ocultes el contenido principal mientras esperas indefinidamente a un servicio de experimentación. Acuerda una alternativa aceptable y prueba fallos y respuestas lentas. Para pagos, identidad o prevención de abuso, coordina los cambios y verifica el proceso completo. El objetivo es conservar funciones resistentes a fallos, no eliminar dependencias hasta conseguir un indicador verde.
Asigna responsable y salida a cada integración nueva
Utiliza la lista de comprobación de rendimiento antes de activar la siguiente etiqueta. Registra finalidad, páginas, regla de activación, pruebas de utilidad, escenarios, reversión y fecha de revisión. Asigna una persona o equipo de tu organización: las entradas sin responsable son difíciles de retirar.
Establece presupuestos a partir de tu referencia y necesidades, incluyendo transferencia, trabajo del hilo principal e interacciones afectadas. No existe una cuota universal para terceros. Revisa resultados reales tras el despliegue e investiga por plantilla y consentimiento. Las guías de velocidad web ayudan cuando el retraso restante procede de imágenes, estilos o código propio.
Empieza por la integración más costosa cuya finalidad no esté clara. Reproduce su coste, pregunta si sigue siendo necesaria y retírala o limita su alcance mediante un cambio reversible. Después repite la tarea que el visitante quería completar.