Optimizar el retraso de primera entrada

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

Addy Osmani
Addy Osmani
X GitHub
Houssein Djirdeh

Hice clic, pero no sucedió nada. ¿Por qué no puedo interactuar con esta página? 😢

First Contentful Paint (FCP) y Largest Contentful La pintura (LCP) es una métrica que mide el tiempo que tarda el contenido en representar visualmente (pintar) en una página. Aunque son importantes, los tiempos de pintura no capturan la carga. capacidad de respuesta: Es la rapidez con la que una página responde a la interacción del usuario.

El retraso de primera entrada (FID) es una métrica de Métricas web esenciales que capta la primera impresión de la interactividad y la capacidad de respuesta de un sitio. Mide el tiempo que transcurre desde que un usuario interactúa por primera vez con una página hasta el momento en que el navegador realmente puede responder a esa interacción. FID es una métrica de campo y no se puede simulados en un entorno de lab. Se requiere una interacción real del usuario para medir la de la demora en la respuesta.

Los buenos valores fid son de 2.5 segundos, los valores deficientes son mayores que 4.0 segundos y cualquier valor intermedio debe mejorarse.

Para ayudar a predecir el FID en el lab, recomienda Total Blocking Time (TBT). Miden cosas distintas, las mejoras en TBT suelen corresponder a mejoras en FID.

La causa principal de un FID deficiente es una ejecución pesada de JavaScript. optimizar el análisis de JavaScript, las compilaciones y las ejecuciones en tu página web reducirán directamente el FID.

Ejecución intensiva de JavaScript

El navegador no puede responder a la mayoría de las entradas del usuario mientras ejecuta JavaScript en el subproceso principal. En otras palabras, el El navegador no puede responder a las interacciones del usuario cuando el subproceso principal está ocupado. Para mejorarlo:

Tareas extensas de separación de tareas

Si ya intentaste reducir la cantidad de JavaScript que se carga en una sola página, puedes ser útil para desglosar el código de larga duración en tareas asíncronas más pequeñas.

Las tareas largas son períodos de ejecución de JavaScript en los que los usuarios pueden descubrirás que tu IU no responde. Cualquier fragmento de código que bloquee el subproceso principal durante 50 ms o más se puede y se caracteriza por ser una tarea larga. Las tareas largas son una señal de un posible sobredimensionamiento de JavaScript (cargar y ejecutar más de lo que un usuario puede necesitar en este momento) Dividir las tareas largas puede reducir la demora de las entradas de tu sitio.

Tareas largas en las Herramientas para desarrolladores de Chrome
Las Herramientas para desarrolladores de Chrome visualizan Tasks largas en el panel de rendimiento

El FID debería mejorar notablemente a medida que adoptas prácticas recomendadas, como dividir y dividir código. Tareas largas. Aunque la TBT no es una métrica de campo, es útil para verificar el progreso lo que mejora el tiempo de carga (TTI) y el FID.

Optimiza tu página para mejorar la preparación de las interacciones

Existen varias causas comunes de puntuaciones bajas de FID y TBT en aplicaciones web que dependen en gran medida de JavaScript:

La ejecución de la secuencia de comandos propia puede retrasar la preparación para la interacción.

  • El sobredimensionamiento de JavaScript, los tiempos de ejecución pesados y la fragmentación ineficiente pueden ralentizar con qué rapidez de la página puede responder a las entradas del usuario y afectar el FID, TBT y TTI. La carga progresiva de código y las funciones pueden ayudar a distribuir el trabajo y mejorar la preparación para la interacción.
  • Es posible que parezca que las apps renderizadas del servidor se pintan píxeles en la pantalla con rapidez, pero tenga cuidado con el hecho de que las ejecuciones de secuencias de comandos de gran tamaño bloqueen las interacciones de los usuarios (p.ej., rehidratación para conectar objetos de escucha de eventos). Esto puede tardar varios cientos de milisegundos, a veces incluso en segundos, si se usa la división de código basada en la ruta. Considera cambiar más lógica del servidor ni generar más contenido estáticamente durante el tiempo de compilación.

A continuación, se presentan las puntuaciones de TBT antes y después de optimizar la carga de la secuencia de comandos propia para un y mantener la integridad de su aplicación. Al mover la carga (y ejecución) costosa de la secuencia de comandos de un componente no esencial de la ruta crítica, los usuarios pudieron interactuar con la página mucho antes.

Mejoras en la puntuación TBT en Lighthouse después de optimizar la secuencia de comandos propia.

La recuperación de datos puede afectar muchos aspectos de la preparación para la interacción

  • Esperar una cascada de recuperaciones en cascada (p.ej., JavaScript y recuperaciones de datos para componentes) afectan la latencia de interacción. Intenta minimizar la dependencia de las recuperaciones de datos en cascada.
  • Los grandes almacenes de datos intercalados pueden enviar tiempo de análisis de HTML y afectar tanto la pintura como la interacción métricas. Apunta a minimizar la cantidad de datos que el cliente debe procesar con posterioridad.

La ejecución de secuencias de comandos de terceros también puede retrasar la latencia de interacción.

  • Muchos sitios incluyen etiquetas y análisis de terceros que pueden mantener la red ocupada Hacer que el subproceso principal no responda periódicamente, lo que afecta la latencia de interacción. Explorar carga de código de terceros bajo demanda (p.ej., es posible que no cargues los anuncios en la mitad inferior de la página hasta que se desplazan más cerca del viewport).
  • En algunos casos, las secuencias de comandos de terceros pueden anular las propias en términos de prioridad y ancho de banda en el subproceso principal, lo que también retrasa la rapidez con la que una página está lista para la interacción. Intenta prioriza la carga de lo que crees que ofrece el mayor valor a los usuarios primero.

Usar un trabajador web

Un subproceso principal bloqueado es una de las principales causas del retraso de entrada. Web trabajadores permiten ejecutar JavaScript en un subproceso en segundo plano. Mover las operaciones que no son de IU a un subproceso de trabajador separado puede reducir el el tiempo de bloqueo del subproceso y, en consecuencia, mejorar el FID.

Te recomendamos usar las siguientes bibliotecas para facilitar el uso de los trabajadores web en tu sitio:

  • Comlink: Es una biblioteca auxiliar que abstrae. postMessage y facilita el uso
  • Workway: Un exportador de trabajadores web de uso general
  • Workerize: Permite mover un módulo a un trabajador web.

Reduce el tiempo de ejecución de JavaScript

Limitar la cantidad de código JavaScript en tu página reduce el tiempo que el navegador necesita que gastas en ejecutar código JavaScript. Esto acelera la velocidad con la que el navegador puede comenzar a responder a cualquier interacciones del usuario.

Para reducir la cantidad de código JavaScript que se ejecuta en tu página, haz lo siguiente:

  • Difiere el código JavaScript sin usar
  • Minimiza los polyfills que no se usan

Difiere el código JavaScript sin usar

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

La pestaña Cobertura en Chrome Las Herramientas para desarrolladores pueden indicarte cuánto JavaScript no se está usando en tu página web.

La pestaña Cobertura.

Para reducir el uso de JavaScript sin usar, sigue estos pasos:

  • Divide el paquete en varios fragmentos con código
  • Aplaza cualquier JavaScript que no sea crítico, incluidas las secuencias de comandos de terceros, con async o defer.

La división de código consiste en dividir un solo paquete grande de JavaScript en fragmentos más pequeños que pueden cargarse de forma condicional (lo que también se conoce como carga diferida). La mayoría de los navegadores más nuevos admiten la sintaxis de importación dinámica, que permite recuperar el módulo a pedido:

import('module.js').then((module) => {
  // Do something with the module.
});

Importar JavaScript de forma dinámica en ciertas interacciones del usuario (como cambiar una ruta o mostrar una ventana modal) garantizará que el código no utilizado en la carga inicial de la página solo se recupere cuando según sea necesario.

Además de la compatibilidad general con los navegadores, la sintaxis de importación dinámica se puede usar en muchas compilaciones de la seguridad de la información.

  • Si usas webpack, Resumen, o Parcel como agrupador de módulos, aprovecha su compatibilidad con la importación dinámica.
  • Frameworks del cliente, como Reaccionar, Angular y Vue provee para facilitar la carga diferida a nivel de componente.

Además de la división de código, siempre usa async or aplazar para las secuencias de comandos que no son necesarias la ruta de acceso crítica o el contenido en la mitad superior de la página.

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

A menos que haya un motivo específico para no hacerlo, todas las secuencias de comandos de terceros deben cargarse con defer. o async de forma predeterminada.

Minimiza los polyfills que no se usan

Si creas tu código con la sintaxis moderna de JavaScript y haces referencia a las APIs de los navegadores modernos, necesita transpilarla e incluir polyfills para que funcione en navegadores más antiguos.

Una de las principales preocupaciones de rendimiento de incluir polyfills y el código transpilado en tu sitio es que los navegadores más nuevos no deberían tener que descargarla si no la necesitan. Para reducir el código JavaScript de tu aplicación, minimiza los polyfills sin usar tanto como sea posible y restringe su uso a entornos en los que se necesitan.

Para optimizar el uso de polyfill en tu sitio, haz lo siguiente:

  • Si usas Babel como transpilador, usa @babel/preset-env para incluir solo los polyfills necesarios para los navegadores a los que pretende orientar sus anuncios. Para Babel 7.9, habilita el elemento bugfixes para reducir aún más en los polyfills innecesarios

  • Usa el patrón module/nomodule para entregar dos paquetes separados (@babel/preset-env también admite esta opción a través de target.esmodules)

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

    Muchas funciones nuevas de ECMAScript compiladas con Babel ya son compatibles con los entornos compatibles con módulos de JavaScript. De este modo, simplificas el proceso de asegurarte de que solo se usa código transpilado para los navegadores que realmente lo necesitan.

Herramientas para desarrolladores

Hay varias herramientas disponibles para medir y depurar el FID:

Agradecemos a Philip Walton, Kayce Basques, Ilya Grigorik y Annie Sullivan por sus opiniones.