Scripts de terceros: tu peor problema de rendimiento

El código que ralentiza tu web no lo escribiste tú

Los scripts de terceros son, en la mayoría de las webs que auditamos, la mayor fuente de lentitud. No el framework, no las imágenes, no el servidor: el código que cargas desde otros dominios. La analítica, el chat de soporte, el píxel de publicidad, el banner de cookies, el mapa incrustado, el widget de reseñas. Cada uno parece inofensivo. Sumados, son el ancla que arrastra tu rendimiento.

Lo incómodo es que ese código no está bajo tu control. Vive en servidores ajenos, se actualiza sin avisarte y se ejecuta en el navegador de tu cliente con los mismos privilegios que el tuyo. Optimizas tu web durante semanas y un solo script externo deshace el trabajo. Vale la pena mirarlo de frente.

Por qué un script ajeno pesa tanto

Un script de terceros no es solo su tamaño de descarga. Su coste real tiene varias capas que rara vez se miden juntas:

• Conexión a otro dominio. Cada origen nuevo obliga al navegador a resolver DNS, negociar TLS y abrir conexión antes de descargar nada.
• Bloqueo del hilo principal. Mientras un script se ejecuta, el navegador no responde a clics ni pinta contenido. Es el principal enemigo del INP.
• Efecto cascada. Muchos scripts cargan, a su vez, más scripts. Un solo gestor de etiquetas puede inyectar una docena de peticiones que tú nunca aprobaste.
• Impredecibilidad. El proveedor cambia su código y tu web se ralentiza sin que tú hayas tocado una línea.

Ese peso golpea directamente a las métricas que Google mide. Si quieres el contexto completo de qué se mide y por qué, está en los fundamentos de Core Web Vitals; aquí nos centramos en la causa que más veces los rompe.

El inventario que casi nadie hace

Antes de optimizar, cuenta. Abre las herramientas de desarrollo de tu navegador, mira la pestaña de red y filtra por dominios que no sean el tuyo. La lista suele sorprender. Para cada script, hazte tres preguntas:

1. ¿Aporta valor que justifique su coste? Un chat que genera ventas, sí. Un widget que nadie usa, no.
2. ¿Tiene que cargarse al inicio? Casi nunca. La mayoría puede esperar a que la página sea usable.
3. ¿Existe una alternativa más ligera? A veces una imagen estática sustituye a un mapa interactivo; un enlace, a un widget completo.

Este ejercicio es la versión técnica de hacer menos, pero mejor: cada script que eliminas es rendimiento que recuperas sin escribir una sola línea.

Tácticas para domar lo que sí te quedas

No todo se puede eliminar. La analítica y algún píxel suelen ser innegociables. Para esos, la clave es controlar cuándo y cómo se cargan.

Carga diferida y asíncrona

Un script que no es crítico no debería bloquear el renderizado. Los atributos defer y async indican al navegador que no espere por él:

<!-- Bloquea el render hasta descargar y ejecutar -->
<script src="https://otro-dominio.com/widget.js"></script>

<!-- Se descarga en paralelo y se ejecuta sin frenar la página -->
<script src="https://otro-dominio.com/widget.js" defer></script>

El patrón de fachada

Para widgets pesados —chats, vídeos incrustados, mapas— carga primero una imagen ligera que imita el componente. El script real solo se descarga cuando el usuario interactúa. El visitante que nunca abre el chat nunca paga su coste. Es una de las optimizaciones de mayor retorno y menor riesgo.

Presupuesto de rendimiento

Pon un límite explícito: un número máximo de scripts de terceros y un peso total que no se puede superar sin una conversación. Sin un presupuesto, la lista solo crece, porque añadir un script siempre es la decisión fácil. Defenderlo es, sobre todo, una disciplina de equipo.

Autocontrol del proveedor

Cuando elegimos las herramientas de un proyecto lo hacemos con criterio de rendimiento desde el principio, no como parche final. Es parte de por qué elegimos un stack moderno como Next.js: nos da control sobre qué se carga, cuándo y desde dónde. La velocidad se diseña; no se añade al final.

El coste oculto en negocio

Esto no es una discusión técnica para desarrolladores. Cada décima de segundo de retraso erosiona conversión, y la suma de scripts ajenos es, muchas veces, la diferencia entre una web rápida y una que ahuyenta. Lo hemos contado en términos de negocio en cuánto cuestan los milisegundos: el rendimiento es un canal de ingresos, no un lujo de ingeniería.

Google documenta con detalle el impacto de estos recursos y cómo mitigarlo en su recurso de referencia web.dev. La conclusión es consistente con lo que vemos en cada auditoría: el tercero que no controlas suele ser tu mayor palanca de mejora.

Preguntas frecuentes

¿Cómo sé qué scripts de terceros carga mi web?

Abre las herramientas de desarrollo del navegador, ve a la pestaña de red y filtra por dominios distintos al tuyo. También puedes usar herramientas de análisis de rendimiento que desglosan el coste de cada recurso externo.

¿Es malo usar Google Tag Manager?

No es malo en sí, pero es un multiplicador: facilita añadir etiquetas, y por eso las webs acumulan más de las que necesitan. Audítalo con regularidad y elimina lo que no aporte; la comodidad de añadir no debe convertirse en deuda de rendimiento.

¿El patrón de fachada sirve para cualquier widget?

Funciona especialmente bien con elementos pesados que el usuario activa de forma voluntaria: chats, vídeos, mapas. Cargas una vista previa ligera y solo descargas el script real cuando hay interacción, ahorrando el coste a quien nunca lo usa.

¿Diferir los scripts afecta a la analítica?

Bien configurada, la analítica moderna admite carga diferida sin perder datos relevantes. Conviene verificar la medición tras el cambio, pero el impacto en exactitud suele ser mínimo frente a la ganancia en rendimiento.

Reflexión final

Puedes escribir el código más limpio del mundo y aun así servir una web lenta si dejas la puerta abierta a cada script que alguien quiere añadir. El rendimiento no se pierde de golpe; se erosiona widget a widget, con decisiones pequeñas que nadie revisa.

Trata cada script de terceros como lo que es: un invitado que consume recursos de tu cliente. Algunos merecen estar; muchos no. Poner orden en esa lista es, a menudo, la optimización más rentable que existe. Si quieres que revisemos qué carga de más tu web, así abordamos el desarrollo web orientado al rendimiento.