Dev

Optimizar el retardo de la primera entrada

Cómo responder más rápido a las interacciones de los usuarios.

¡Hice clic pero no pasó nada! ¿Por qué no puedo interactuar con esta página? 😢

First Contentful Paint (FCP) y Largest Contentful Paint (LCP) son métricas que miden el tiempo que tarda el contenido en renderizarse (pintar) visualmente en una página. Aunque importante, los tiempos de pintura no capturan capacidad de respuesta de carga: o qué tan rápido responde una página a la interacción del usuario.

First Input Delay (FID) es una métrica de Core Web Vitals que captura la primera impresión de un usuario sobre la interactividad y capacidad de respuesta de un sitio. Mide el tiempo desde que un usuario interactúa por primera vez con una página hasta que el navegador es capaz de responder a esa interacción. FID es una métrica de campo y no se puede simular en un entorno de laboratorio. Una interacción de usuario real es necesario para medir el retardo de respuesta.

Los buenos puntajes FID son 2.5 segundos, los malos puntajes son mayores de 4.0 segundos y cualquier cosa intermedia necesita mejora.

Para ayudar a predecir la FID en el laboratorio, recomendamos el Tiempo de bloqueo total (TBT). Miden cosas diferentes, pero las mejoras en TBT generalmente corresponden a mejoras en FID.

La principal causa de un FID deficiente es ejecución de JavaScript pesada. Optimizar la forma en que JavaScript analiza, compila y ejecuta en su página web reducirá directamente la FID.

Ejecución pesada de JavaScript

El navegador no puede responder a la mayoría de las entradas de los usuarios mientras ejecuta JavaScript en el hilo principal. En otras palabras, el navegador no puede responder a las interacciones del usuario mientras el hilo principal está ocupado. Para mejorar esto:

Divida las tareas largas

Si ya ha intentado reducir la cantidad de JavaScript que se carga en una sola página, puede resultar útil dividir el código de larga duración en tareas asincrónicas más pequeñas.

Tareas largas son períodos de ejecución de JavaScript en los que los usuarios pueden encontrar que su interfaz de usuario no responde. Cualquier fragmento de código que bloquee el hilo principal durante 50 ms o más se puede caracterizar como una tarea larga. Las tareas largas son una señal de un potencial exceso de JavaScript (cargar y ejecutar más de lo que un usuario puede necesitar en este momento).
La división de tareas largas puede reducir el retraso de entrada en su sitio.

long-task-6693785
DevTools de Chrome visualiza tareas largas en el panel de rendimiento

FID debería mejorar notablemente a medida que adopte las mejores prácticas, como la división de código y la división de tareas largas. Si bien TBT no es una métrica de campo, es útil para verificar el progreso hacia la mejora final tanto de Time To Interactive (TTI) como de FID.

Optimice su página para que esté lista para la interacción

Hay una serie de causas comunes de puntuaciones bajas en FID y TBT en aplicaciones web que dependen en gran medida de JavaScript:

La ejecución de un script de origen puede retrasar la preparación de la interacción

  • El exceso de tamaño de JavaScript, los tiempos de ejecución intensos y la fragmentación ineficiente pueden ralentizar la rapidez con la que una página puede responder a la entrada del usuario y afectar a FID, TBT y TTI. La carga progresiva de código y funciones puede ayudar a difundir este trabajo y mejorar la preparación para la interacción.
  • Las aplicaciones renderizadas del lado del servidor pueden parecer que están pintando píxeles en la pantalla rápidamente, pero tenga cuidado con las interacciones de los usuarios bloqueadas por ejecuciones de scripts grandes (por ejemplo, rehidratación para conectar a los oyentes de eventos). Esto puede tardar varios cientos de milisegundos, a veces incluso segundos, si se utiliza la división de código basada en rutas. Considere cambiar más lógica del lado del servidor o generar más contenido de forma estática durante el tiempo de compilación.

A continuación, se muestran los puntajes TBT antes y después de optimizar la carga de scripts propios para una aplicación. Al mover la costosa carga de scripts (y ejecución) para un componente no esencial fuera de la ruta crítica, los usuarios pudieron interactuar con la página mucho antes.

tbt-before-after-first-party-4830319

La búsqueda de datos puede afectar muchos aspectos de la preparación para la interacción

  • Esperar una cascada de recuperaciones en cascada (por ejemplo, JavaScript y recuperaciones de datos para componentes) puede afectar la latencia de interacción. Trate de minimizar la dependencia de las recuperaciones de datos en cascada.
  • Los grandes almacenes de datos en línea pueden aumentar el tiempo de análisis de HTML y afectar tanto a las métricas de pintura como de interacción. Intente minimizar la cantidad de datos que deben procesarse posteriormente en el lado del cliente.

La ejecución de un script de terceros también puede retrasar la latencia de la interacción

  • Muchos sitios incluyen etiquetas y análisis de terceros que pueden mantener la red ocupada y hacer que el hilo principal deje de responder periódicamente, lo que afecta la latencia de la interacción. Explore la carga bajo demanda de código de terceros (por ejemplo, tal vez no cargue esos anuncios de la mitad inferior de la página hasta que se acerquen más a la ventana gráfica).
  • En algunos casos, los scripts de terceros pueden adelantarse a los propios en términos de prioridad y ancho de banda en el hilo principal, lo que también retrasa la rapidez con la que una página está lista para la interacción. Intente priorizar la carga de lo que crea que ofrece el mayor valor a los usuarios primero.

Utilice un trabajador web

Un hilo principal bloqueado es una de las principales causas del retraso de entrada. Trabajadores web hacen posible ejecutar JavaScript en un hilo de fondo. Mover operaciones que no son de UI a un subproceso de trabajo separado puede reducir el tiempo de bloqueo del subproceso principal y, en consecuencia, mejorar el FID.

Considere usar las siguientes bibliotecas para facilitar el uso de trabajadores web en su sitio:

  • Comlink: Una biblioteca auxiliar que abstrae
    postMessage y facilita su uso
  • Workway: Un exportador de trabajadores web de propósito general
  • Trabajar: Mover un módulo a un trabajador web

Reducir el tiempo de ejecución de JavaScript

Limitar la cantidad de JavaScript en su página reduce la cantidad de tiempo que el navegador necesita para ejecutar código JavaScript. Esto acelera la rapidez con que el navegador puede comenzar a responder a las interacciones del usuario.

Para reducir la cantidad de JavaScript ejecutado en su página:

  • Aplazar JavaScript no utilizado
  • Minimice los polyfills no utilizados

Aplazar JavaScript no utilizado

De forma predeterminada, todo JavaScript bloquea el procesamiento. Cuando el navegador encuentra una etiqueta de secuencia de comandos que se vincula a un archivo JavaScript externo, debe pausar lo que está haciendo y descargar, analizar, compilar y ejecutar ese JavaScript. Por lo tanto, solo debe cargar el código que se necesita para la página o responder a la entrada del usuario.

los Cobertura La pestaña de Chrome DevTools puede decirle cuánto JavaScript no se está utilizando en su página web.

coverage-panel-js-6236715

Para reducir el JavaScript no utilizado:

  • Divida el código de su paquete en varios fragmentos
  • Aplazar cualquier JavaScript no crítico, incluidos los scripts de terceros, utilizando async o defer

División de código es el concepto de dividir un solo paquete grande de JavaScript en fragmentos más pequeños que se pueden cargar condicionalmente (también conocido como carga diferida).
La mayoría de los navegadores más nuevos admiten la sintaxis de importación dinámica, que permite la obtención de módulos a pedido:

import('module.js')	
.then((module) => {
});

La importación dinámica de JavaScript en determinadas interacciones del usuario (como cambiar una ruta o mostrar un modal) garantizará que el código que no se utiliza para la carga de la página inicial solo se recupere cuando sea necesario.

Aparte de la compatibilidad general con el navegador, la sintaxis de importación dinámica se puede utilizar en muchos sistemas de compilación diferentes.

Aparte de la división de código, utilice siempre async o diferir para scripts que no son necesarios para contenido de ruta crítica o de la mitad superior de la página.

<script defer src=""></script>	
<script async src=""></script>

A menos que haya una razón específica para no hacerlo, todos los scripts de terceros deben cargarse con defer
o async por defecto.

Minimice los polyfills no utilizados

Si crea su código utilizando la sintaxis JavaScript moderna y hace referencia a las API de los navegadores modernos, deberá transpilarlo e incluir polyfills para que funcione en navegadores más antiguos.

Una de las principales preocupaciones de rendimiento de incluir polyfills y código transpilado en su sitio es que los navegadores más nuevos no deberían tener que descargarlo si no lo necesitan. Para reducir el tamaño de JavaScript de su aplicación, minimice los polyfills no utilizados tanto como sea posible y restrinja su uso a los entornos donde se necesitan.

Para optimizar el uso de polyfill en su sitio:

  • Si utiliza Babel como transpilador, use
    @babel/preset-env para incluir solo los polyfills necesarios para los navegadores a los que planea segmentar. Para Babel 7.9, habilite el
    bugfixes opción para reducir aún más los polyfills innecesarios

  • Utilice el patrón módulo / nomódulo para entregar dos paquetes separados (@babel/preset-env también es compatible con esto a través de target.esmodules)

    <script type="module" src="modern.js"></script>	
    <script nomodule src="legacy.js" defer></script>

    Muchas de las funciones de ECMAScript más nuevas compiladas con Babel ya son compatibles con entornos que admiten módulos JavaScript. Entonces, al hacer esto, simplifica el proceso de asegurarse de que solo se use el código transpilado para los navegadores que realmente lo necesitan.

Hay varias herramientas disponibles para medir y depurar FID:

Agradecemos a Philip Walton, Kayce Basques, Ilya Grigorik y Annie Sullivan por sus reseñas.

error: Atención: Contenido protegido.