Solucionar scripts de terceros en Next.js para mejorar los Core Web Vitals

Solucionar scripts de terceros en Next.js

Los scripts de terceros son la causa más común de fallos en los Core Web Vitals en sitios de Next.js que, por lo demás, están optimizados. Has hecho todo bien: optimizado imágenes, implementado generación estática, integrado el CSS crítico. Pero tu Interaction to Next Paint sigue fallando. La causa casi siempre es el JavaScript de terceros. Según el 2025 Web Almanac, el 92% de las páginas cargan al menos un recurso de terceros. Los scripts representan el 24.8% de todas las solicitudes de terceros, más que cualquier otro tipo de recurso.

Última revisión por Arjen Karel en marzo de 2026

Podría deberse a scripts de terceros como anuncios, analíticas, botones de redes sociales, widgets, scripts de pruebas A/B, reproductores de video, etc.

Cómo impactan los scripts de terceros en los Core Web Vitals

Los scripts de terceros pueden arruinar tus Core Web Vitals de más formas de las que probablemente puedas imaginar. Estos son algunos de los problemas que encuentro en sitios web en vivo.

• Ralentizan la red. Los scripts de terceros pueden enviar múltiples solicitudes a múltiples servidores, descargar archivos grandes no optimizados como imágenes y videos, y descargar frameworks y bibliotecas varias veces.
• El JavaScript de terceros puede bloquear el DOM en cualquier momento (o incluso varias veces durante una visita a la página), retrasando la rapidez con la que las páginas pueden renderizarse y usar demasiado tiempo de CPU, lo que puede retrasar la interacción del usuario y causar que se agote la batería.
• Los scripts de terceros que bloquean el renderizado pueden ser un único punto de fallo (SPOF).
• Los scripts de terceros pueden causar problemas de red debido a un almacenamiento en caché HTTP mal configurado, falta de compresión suficiente en el servidor y protocolos HTTP lentos o desactualizados.
• Perjudican la user experience de muchas otras formas, como ocultando contenido, bloqueando eventos del navegador (como el evento window load) o utilizando APIs obsoletas como document.write.

Los números son aleccionadores. El equipo de Chrome Aurora descubrió que un contenedor de Google Tag Manager con 18 etiquetas aumenta el Total Blocking Time en casi 20 veces. El 2025 Web Almanac reporta un TBT móvil mediano de 1,916 ms, casi 10 veces la mejor práctica de 200 ms. Los scripts de terceros son un contribuyente principal a ese número.

Solucionar scripts de terceros y Core Web Vitals en Next.js

Idealmente, deseas asegurar que ningún script de terceros impacte la ruta de renderizado crítica. Tu primer instinto sería utilizar el atributo defer o async. Desafortunadamente, desde una perspectiva de tiempo, esta no es una buena opción para la mayoría de los sitios en Next.js. Un sitio de Next.js depende en gran medida de JavaScript para hidratar la página.

Esto significa que tan pronto como los bundles de Next.js se hayan descargado, el navegador ejecutará ese JavaScript. Esto requiere tiempo y recursos. Este proceso se ralentizará cuando el navegador esté demasiado ocupado compilando y ejecutando JavaScript de terceros.

El componente Script de Next.js

El componente Script de Next.js (next/script) te da control sobre cuándo se cargan los scripts de terceros en relación con el código de tu aplicación. En lugar de luchar contra el comportamiento de carga predeterminado del navegador, eliges una estrategia que coincida con la importancia del script.

Importarlo en cualquier componente:

import Script from 'next/script'

Estrategia

Con next/script, tú decides cuándo cargar tu script de terceros usando la propiedad de estrategia. Hay cuatro estrategias de carga:

• beforeInteractive: Carga un script antes de que la página sea interactiva
• afterInteractive: Carga un script inmediatamente después de que la página se vuelve interactiva
• lazyOnload: Carga un script durante el tiempo de inactividad
• worker: Carga un script en un web worker (experimental, solo Pages Router)

Estrategia beforeInteractive

Los scripts que se cargan con la estrategia beforeInteractive se inyectan en el HTML inicial desde el servidor con el atributo defer habilitado y se ejecutan antes de que se ejecute el JavaScript empaquetado por sí mismo.

¡Desde la perspectiva de los Core Web Vitals, este es exactamente el tipo de comportamiento que nos gustaría evitar! La estrategia beforeInteractive solo debe usarse en scripts que son absolutamente críticos para la página. ¡Se supone que los scripts de terceros nunca deben ser críticos!

<Script
  id="bootstrap-cdn"
  src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"
  strategy="beforeInteractive"
 />

En este caso, la biblioteca JavaScript de bootstrap se añade al HTML generado con el atributo defer justo antes de los bundles de Next.js. Esto significa que el navegador probablemente obtendrá y ejecutará la biblioteca bootstrap antes que el bundle de Next.js. Esto retrasará la hidratación de Next.js y probablemente bloqueará el hilo principal cuando el navegador debería estar descargando y ejecutando los chunks de Next.js. Para los Core Web Vitals, esto significa que Interaction to Next Paint probablemente se verá afectado.

Estrategia afterInteractive

Los scripts que usan la estrategia afterInteractive se inyectan del lado del cliente y se descargarán después de que Next.js hidrate la página.

Desde la perspectiva de los Core Web Vitals, este es un lugar mucho mejor (pero aún no perfecto) para inyectar scripts de terceros. Esta estrategia debe usarse para scripts que no necesitan cargarse lo antes posible y pueden obtenerse y ejecutarse inmediatamente después de que la página sea interactiva.

<Script
  strategy="afterInteractive"
  dangerouslySetInnerHTML={{
    __html: `
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer', 'GTM-XXXXXX');
  `,
  }}
/>

Para Google Tag Manager y Google Analytics, ahora hay una mejor opción. Consulta la sección @next/third-parties a continuación.

Estrategia lazyOnload

¡Con la estrategia lazyOnload las cosas finalmente se están volviendo interesantes! La forma en que pienso sobre los scripts de terceros es simple: 'no deberían ser críticos para una página'. Si no puedes vivir sin cierto script de terceros, probablemente no deberías depender de un tercero.

Los scripts que usan la estrategia lazyOnload se cargan tarde después de que todos los recursos han sido obtenidos y durante el tiempo de inactividad. Esto significa que el script de terceros no interferirá con los chunks de Next.js y minimizará el impacto que este script tiene en el Interaction to Next Paint (INP).

<Script
  id="some-chat-script"
  src="https://example.com/chatscript.js"
  strategy="lazyOnload"
 />

Estrategia worker

La estrategia worker es una función experimental que usa Partytown para ejecutar scripts en un web worker en lugar del hilo principal. El concepto es interesante: el equipo de Chrome Aurora midió una reducción del 92% en TBT al mover GTM a un web worker. Pero la estrategia worker solo funciona con el Pages Router. No soporta el App Router. Mi consejo: mantente alejado de esto hasta que el proyecto madure o el DOM esté disponible para los web workers.

@next/third-parties: el enfoque moderno

Next.js ahora proporciona el paquete @next/third-parties con componentes optimizados para los servicios de terceros más comunes. Estos componentes manejan la estrategia de carga internamente, por lo que no necesitas configurarla tú mismo.

Instálalo:

npm install @next/third-parties

Para Google Tag Manager, añade el componente a tu diseño raíz (root layout):

import { GoogleTagManager } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <GoogleTagManager gtmId="GTM-XXXXXX" />
      <body>{children}</body>
    </html>
  )
}

Para Google Analytics:

import { GoogleAnalytics } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <GoogleAnalytics gaId="G-XXXXXX" />
      </body>
    </html>
  )
}

El equipo de Chrome Aurora reporta que el 66% de los sitios en Next.js usan Google Tag Manager y el 52% usan Google Analytics. Si estás cargando cualquiera de estos, usa los componentes dedicados en lugar del componente genérico Script con dangerouslySetInnerHTML. Si usas el dataLayer de GTM, también consulta el dataLayer INP yield pattern para evitar que los eventos push bloqueen las interacciones.

¿Qué estrategia para qué script?

• GTM y GA: Usa componentes @next/third-parties. Ellos manejan el tiempo internamente.
• Widgets de chat (Intercom, HubSpot, Drift): Usa lazyOnload. Un widget de chat nunca es crítico para la primera interacción.
• Pruebas A/B (Optimizely, VWO): Usa beforeInteractive solo si la prueba afecta el contenido above-the-fold (visible en la parte superior). De lo contrario, usa afterInteractive.
• Incrustaciones sociales y reproductores de video: Usa lazyOnload.
• Scripts de anuncios: Usa afterInteractive. Los anuncios necesitan cargarse razonablemente rápido para los ingresos, pero no deberían bloquear la hidratación.

A lo largo de los sitios de Next.js monitoreados por CoreDash, aquellos que usan lazyOnload para scripts de analíticas muestran una mejora mediana en INP de 27ms en comparación con afterInteractive. Esa es la diferencia entre pasar y fallar el umbral de INP.

Cualquiera que sea la estrategia que elijas, verifica los resultados con el Real User Monitoring. Las puntuaciones de laboratorio te dicen lo que podría pasar. Los datos de campo te dicen lo que realmente sucedió. Y a veces la mejor optimización es eliminar los scripts que no necesitas.

Para más información sobre cómo medir el impacto, consulta la guía sobre cómo medir los Core Web Vitals en Next.js. Si también estás lidiando con CSS que bloquea el renderizado en Next.js, soluciona eso primero. Para una visión más amplia sobre cómo el navegador decide qué obtener y cuándo, consulta la guía de priorización de recursos.