Scripts de terceros: cómo frenan tu web y cómo controlarlos

Un script de terceros es cualquier código que tu página carga desde un dominio que no controlas: el widget de chat, el píxel de una red publicitaria, el gestor de etiquetas, el mapa incrustado, la herramienta de mapas de calor. Frenan la web por tres vías a la vez: compiten por la red durante la carga, bloquean el hilo principal del navegador mientras se ejecutan y, peor aún, siguen trabajando cuando el usuario ya intenta pulsar o escribir. Por eso una página con un HTML ligero y las imágenes bien optimizadas puede seguir sintiéndose lenta.

La buena noticia es que casi nunca hace falta elegir entre medir y ser rápido. Lo que sí hace falta es tratar cada script como una deuda: saber qué cuesta, quién lo pidió, qué aporta y cuándo debe cargarse. Esta guía se centra en la causa del problema y en el método para controlarlo, no en una métrica concreta: cómo se ve el daño, cómo auditarlo y qué hacer con cada script, ya sea aplazarlo, cargarlo bajo demanda, sustituirlo o quitarlo.

Por qué un script ajeno pesa más que uno propio

Cuando escribes un fichero JavaScript, lo sirves desde tu dominio, sabes qué hace y puedes comprimirlo, cachearlo y reducirlo. Con un script de terceros pierdes todo eso. No controlas su tamaño, ni su política de caché, ni la velocidad del servidor que lo entrega, ni los cambios que su proveedor publique mañana. Tu página puede cambiar de comportamiento sin que tú hayas tocado una sola línea.

El coste real casi nunca está en la descarga. Un fichero pequeño puede hacer mucho trabajo al ejecutarse: leer el documento entero, registrar escuchadores de eventos, crear iframes, inyectar hojas de estilo y lanzar, a su vez, otras peticiones a terceros que tú ni siquiera has pedido. Esa cadena es la parte que más sorprende: añades un único fragmento de código y acabas conectándote a cinco o seis dominios distintos.

Además, cada dominio nuevo obliga al navegador a resolver el DNS, abrir una conexión y negociar el cifrado antes de recibir el primer byte. Son tiempos de espera que no dependen de tu hosting y que no se arreglan comprimiendo imágenes.

Las tres formas en que frenan la página

Conviene separar los mecanismos, porque cada uno se corrige de manera distinta. Un diagnóstico que lo mezcla todo termina en recetas genéricas que no resuelven nada.

El primero es la red. Los scripts compiten con tus recursos críticos (CSS, fuentes, imagen principal) por el ancho de banda y por las conexiones disponibles. Un script cargado de forma síncrona en la cabecera, además, detiene el análisis del HTML hasta que se descarga y se ejecuta. Si el servidor del tercero va lento o está caído, tu página espera con él; en rendimiento se conoce como punto único de fallo.

El segundo es el hilo principal. El navegador ejecuta en un único hilo el JavaScript, el cálculo de estilos, el diseño y buena parte del pintado. Mientras un script ocupa ese hilo con una tarea larga (se consideran largas las que superan los 50 milisegundos), el navegador no puede responder a nada más. Lo que el usuario haga en ese intervalo se procesa cuando la tarea termina.

El tercero es el más traicionero: el trabajo posterior a la carga. Muchos scripts esperan al evento de carga o a la primera interacción y entonces se inicializan, observan el desplazamiento, envían datos por lotes o reconstruyen partes del documento. Eso no aparece en una medición de carga inicial, pero sí en la experiencia de quien intenta abrir el menú o rellenar un formulario. Es la razón de que el INP, la métrica de respuesta a la interacción que sustituyó al FID, suela empeorar por culpa de código ajeno aunque la carga inicial parezca correcta.

Quién suele ser el culpable: etiquetas, chats y píxeles

No todos los scripts cuestan lo mismo, y conviene saber por qué. Las categorías más habituales tienen perfiles de daño distintos.

Los gestores de etiquetas no son el problema en sí, sino el multiplicador. El contenedor carga una vez, pero dentro puede vivir cualquier cosa que alguien haya publicado con el tiempo: píxeles, pruebas A/B, scripts de remarketing, código de campañas que terminaron hace un año. El contenedor se convierte en un cajón donde nadie revisa lo que entra.

• Chats y widgets de atención: cargan mucho código de interfaz, abren conexiones persistentes y suelen inicializarse en cada página aunque solo una minoría de las visitas los use. Son candidatos claros a carga bajo demanda.
• Píxeles de publicidad y redes sociales: añaden pocas líneas visibles, pero cada uno descarga su librería, lee cookies y dispara peticiones de seguimiento. Varios píxeles a la vez suman tareas en el hilo principal justo cuando la página se vuelve interactiva.
• Pruebas A/B y personalización: muchas ocultan la página hasta decidir qué variante mostrar, lo que retrasa el primer pintado de forma directa. Son las que más perjudican la percepción de velocidad.
• Mapas de calor y grabación de sesiones: observan el documento entero y serializan cambios continuamente. Su coste crece con la complejidad del DOM.
• Vídeos, mapas y redes sociales incrustadas: traen un iframe con su propio documento, sus fuentes y sus scripts. Un solo vídeo incrustado puede pesar más que el resto de la página.
• Fuentes y bibliotecas desde CDN ajenos: añaden una conexión extra y, en el caso de las fuentes, pueden retrasar el texto visible.

Cómo auditar lo que carga tu página

Antes de tocar nada, necesitas un inventario con tres columnas: qué script es, cuánto cuesta y quién responde de él. Sin la tercera columna, la limpieza se paraliza en la primera reunión.

Empieza por la pestaña de red de las herramientas de desarrollo del navegador, con la caché desactivada y la conexión limitada para simular un móvil medio. Ordena por dominio y agrupa todo lo que no sea tuyo. Fíjate en las cascadas: un script que solicita a otro, que solicita a otro, indica una cadena que merece ser revisada. Después, en la pestaña de rendimiento, graba una carga y busca las tareas largas marcadas en rojo; al desplegarlas verás a qué fichero pertenece el código que las provoca.

Lighthouse aporta una auditoría específica sobre el impacto del código de terceros, que agrupa por proveedor el tiempo de bloqueo del hilo principal y el tamaño transferido. Sirve como punto de partida, con una cautela: se mide en laboratorio, con un dispositivo simulado y sin interacciones reales. Complementa ese dato con uno de campo, como el informe de experiencia de usuario de Chrome o la propia medición de tus visitas, para confirmar que el problema afecta a personas reales.

El método más concluyente es el bloqueo selectivo. En las herramientas de desarrollo puedes bloquear la petición de un dominio concreto y recargar. Si la página mejora de forma clara, tienes la prueba. Repite con cada proveedor sospechoso y anota la diferencia. Es una medición casera, pero responde a la pregunta que importa en una conversación con marketing: cuánto nos cuesta este script.

Un último paso que casi nadie hace: abre el código de tu contenedor de etiquetas y lista todo lo que dispara en todas las páginas. Verás etiquetas de campañas caducadas, duplicados del mismo píxel instalado por dos equipos distintos y scripts de herramientas que la empresa ya no contrata.

Decidir el destino de cada script

Con el inventario delante, cada script recibe una de cuatro decisiones. No hace falta que todas sean drásticas; basta con que sean explícitas.

Eliminar es la opción más potente y la más olvidada. Si nadie consulta los datos de una herramienta, si el píxel corresponde a una campaña terminada o si dos analíticas miden lo mismo, quítalo. Un script que no existe no cuesta nada, no se rompe y no expone datos de tus usuarios. Pregunta por escrito a quien lo pidió y fija una fecha: si nadie lo reclama, se retira.

Aplazar es la opción intermedia. Un script que no necesita estar listo para pintar la página puede cargarse después. Los atributos async y defer son la herramienta básica: async descarga en paralelo y se ejecuta en cuanto termina, en un orden impredecible; defer descarga en paralelo, pero ejecuta después de analizar el documento y respeta el orden entre scripts. Para código de medición suele bastar defer o una carga tras el evento de carga de la página.

Cargar bajo demanda va un paso más allá. El widget de chat no necesita existir hasta que el usuario lo busque: puedes mostrar un botón ligero y descargar el código real solo al pulsarlo, al acercar el cursor o al cabo de unos segundos de inactividad. El mismo patrón, llamado fachada, vale para vídeos incrustados: una imagen con un botón de reproducción que se sustituye por el reproductor real cuando hay un clic. La primera interacción tarda un poco más, pero el resto de las visitas, que no interactúan, ya no pagan el coste.

Sustituir es la cuarta vía. Algunos servicios ofrecen alternativas más ligeras, o permiten medir lo mismo desde el servidor en lugar de hacerlo en el navegador. Otros, como las fuentes o las bibliotecas de uso común, pueden alojarse en tu propio dominio para evitar una conexión extra y controlar la caché. Sustituir exige más trabajo y una validación de que los datos siguen siendo comparables, así que deja esta opción para los casos donde el script es necesario y caro a la vez.

Técnicas para reducir el daño de los que se quedan

Los scripts que sobreviven a la auditoría también admiten mejoras. Ninguna es mágica, pero juntas recortan trabajo evitable.

Anticipa las conexiones críticas. Si un tercero es imprescindible y carga pronto, una indicación de preconexión hacia su dominio permite al navegador resolver el DNS y abrir la conexión mientras procesa el resto. Úsala con moderación: preconectar con muchos dominios acaba compitiendo por los mismos recursos que querías proteger.

Dale la prioridad que merece. Cada vez que un script no crítico se ejecuta antes que tu CSS o tu imagen principal, estás pagando un coste sin beneficio. Revisa el orden de las etiquetas en la cabecera y mueve lo secundario al final del cuerpo o a una carga diferida.

Reparte el trabajo largo. Si controlas el código que invoca al tercero, evita lanzar varias inicializaciones seguidas en el mismo instante. Escalonarlas permite al navegador atender entre medias las interacciones del usuario. Hay bibliotecas que trasladan scripts de terceros a un hilo secundario para liberar el principal; funcionan bien con ciertos píxeles de medición, pero pueden romper los que necesitan acceder al documento, así que pruébalo siempre con datos reales y compara que las conversiones se siguen registrando.

Reserva el espacio. Los banners, widgets y anuncios que aparecen tarde empujan el contenido hacia abajo. Fija las dimensiones del contenedor desde el principio para que su llegada no mueva el diseño.

Respeta el consentimiento. Muchos scripts de publicidad y analítica solo deben cargarse cuando el usuario acepta las cookies. Bien implementado, el banner de consentimiento retrasa esos scripts hasta la decisión y, de paso, evita que se carguen para quien los rechaza. Mal implementado, carga todo y luego lo pausa. Comprueba en la pestaña de red qué sucede antes de aceptar nada.

Cómo evitar que el problema vuelva

La limpieza sin gobierno dura un trimestre. El cajón de las etiquetas se vuelve a llenar porque instalar un script cuesta un minuto y nadie mide el coste de tenerlo encendido. Lo que funciona es convertirlo en un proceso ligero.

Define quién puede publicar cambios en el gestor de etiquetas y exige, para cada nueva, tres datos: para qué sirve, quién la pidió y cuándo caduca. Añade una revisión periódica, por ejemplo cada trimestre, en la que se repase la lista y se retire lo que ya no se usa. Guarda la medición de antes y después de cada cambio importante, de modo que el coste de un script deje de ser una opinión.

Por último, establece un presupuesto. No necesitas una cifra sofisticada: basta con acordar que una página no debería superar cierto tiempo de bloqueo del hilo principal en la auditoría de laboratorio, y que cualquier herramienta nueva debe entrar dentro de ese margen o sustituir a otra. Integrar la comprobación en el despliegue, con una auditoría automática, evita que alguien descubra el deterioro seis meses tarde.

El objetivo no es una web sin terceros. Un negocio necesita medir, atender y anunciarse. El objetivo es que cada script esté ahí por una razón que alguien pueda defender, cargue en el momento adecuado y cueste lo que se ha decidido pagar.