NextJS Core Web Vitals - soluciona scripts de terceros

Soluciona scripts de terceros en NextJS

Los scripts de terceros son scripts que añaden funcionalidad de terceros a tus sitios web. A menudo estos scripts están alojados por un tercero aunque esto generalmente no es estrictamente necesario (puedes, por ejemplo, alojar tú mismo el archivo JavaScript de analytics). Los scripts de terceros proporcionan una amplia gama de funcionalidades útiles, haciendo que la web sea más dinámica, interactiva e interconectada. Estos scripts pueden ser cruciales para la funcionalidad o la fuente de ingresos de tu sitio web. Pero los scripts de terceros también conllevan muchos riesgos que deben tenerse en cuenta para minimizar su impacto mientras siguen aportando valor.

Imagina: Eres el orgulloso propietario de un sitio Next.js optimizado. Has optimizado todo tu código, implementado alguna forma de generación estática, optimizado todas tus imágenes, implementado Critical CSS pero tu sitio aún no pasa los Core Web Vitals. ¿Qué está pasando?

Puede ser por culpa de scripts de terceros como anuncios, analytics, botones de redes sociales, widgets, scripts de A/B testing, reproductores de vídeo y demás.

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

Los scripts de terceros pueden arruinar tus Core Web Vitals de más formas de las que probablemente imaginas. Estos son algunos de los problemas que he encontrado en sitios web en producción.

• Ralentizan la red. Los scripts de terceros pueden enviar múltiples peticiones a múltiples servidores, descargar archivos grandes no optimizados como imágenes y vídeos, 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 velocidad de renderizado de las páginas y usando demasiado tiempo de CPU, lo que puede retrasar la interacción del usuario y causar consumo excesivo de batería.
• Los scripts de terceros con bloqueo de renderizado cargados pueden ser un punto único de fallo (SPOF)
• Los scripts de terceros pueden causar problemas de red debido a una configuración deficiente del caché HTTP, falta de suficiente compresión del servidor y protocolos HTTP lentos/antiguos
• Perjudicar la user experience de muchas otras formas como ocultar contenido, bloquear eventos del navegador (como el evento window load) o usar APIs obsoletas como document.write

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

Idealmente, querrás asegurarte de que los scripts de terceros no impacten la ruta de renderizado crítica. Tu solución predeterminada sería usar el atributo defer o async. Desafortunadamente, en cuanto a tiempos, esta no es una buena opción para la mayoría de los sitios Next.js. Un sitio 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 consume tiempo y recursos. Este proceso se ralentizará cuando el navegador esté demasiado ocupado compilando y ejecutando JavaScripts de terceros.

Presentamos el componente Script de Next.js

El componente Script de Next.js, next/script, es una extensión del elemento HTML <script>. Permite a los desarrolladores establecer la prioridad de carga de scripts de terceros en cualquier parte de su aplicación, fuera de next/head, ahorrando tiempo al desarrollador mientras mejora el rendimiento de carga.

Para añadir un script de terceros a tu aplicación, importa el componente next/script:

import Script from 'next/script'

Strategy

Con next/script, decides cuándo cargar tu script de terceros usando la propiedad strategy:

Hay tres estrategias de carga diferentes que se pueden usar:

• beforeInteractive: Carga un script antes de que la página sea interactiva
• afterInteractive: Carga un script inmediatamente después de que la página sea interactiva
• lazyOnload: Carga un script durante el tiempo de inactividad
• worker: Carga un script en un web worker

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 del propio bundle.

Desde la perspectiva de Core Web Vitals, este es exactamente el tipo de comportamiento que nos gustaría evitar. La estrategia beforeInteractive solo debe usarse en scripts que sean absolutamente críticos para la página. ¡Los scripts de terceros nunca deberían 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 descargará y ejecutará la biblioteca de bootstrap antes del 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 el First Input Delay 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 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 descargarse 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');
  `,
  }}
/>

Estrategia lazyOnload

Con la estrategia lazyOnload las cosas finalmente se ponen interesantes. Mi forma de pensar sobre los scripts de terceros es simple: 'no deberían ser críticos para una página'. Si no puedes vivir sin un determinado 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 se hayan descargado 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 First Input Delay (FID)

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

Estrategia worker