First Input Delay (FID)

Navegadores compatibles

  • 76
  • 79
  • 89
  • x

Origen

Todos sabemos lo importante que es causar una buena primera impresión. Es importante a la hora de conocer personas nuevas, y también lo es cuando creas experiencias en la Web.

En la Web, una buena primera impresión puede marcar la diferencia entre que alguien se convierte en un usuario leal o si se va y no vuelve. La pregunta es: ¿qué genera una buena impresión y cómo se mide qué tipo de impresión podrías generar en los usuarios?

En la Web, las primeras impresiones pueden adoptar muchas formas: tenemos las primeras impresiones del diseño y el atractivo visual de un sitio, además de las primeras impresiones de su velocidad y capacidad de respuesta.

Si bien es difícil medir cuánto les gusta el diseño de un sitio a los usuarios con las APIs web, medir su velocidad y capacidad de respuesta no lo es.

Con el First Contentful Paint (FCP), se puede medir la primera impresión que tienen los usuarios de la velocidad de carga de tu sitio. Pero la rapidez con la que tu sitio puede pintar píxeles en la pantalla es solo parte de la historia. Igual de importante es la capacidad de respuesta de tu sitio cuando los usuarios intentan interactuar con esos píxeles.

La métrica Retraso de primera entrada (FID) ayuda a medir la primera impresión que tiene el usuario sobre la interactividad y la capacidad de respuesta de tu sitio.

¿Qué es FID?

FID mide el tiempo que transcurre desde que un usuario interactúa por primera vez con una página (es decir, cuando hace clic en un vínculo, presiona un botón o usa un control personalizado con tecnología JavaScript) hasta el momento en que el navegador puede comenzar a procesar controladores de eventos en respuesta a esa interacción.

¿Qué es una buena puntuación FID?

Para brindar una buena experiencia del usuario, los sitios deben esforzarse por tener un retraso de primera entrada de 100 milisegundos o menos. Para asegurarte de alcanzar este objetivo para la mayoría de los usuarios, un buen umbral para medir es el percentil 75 de las cargas de páginas, segmentadas entre dispositivos móviles y computadoras de escritorio.

Los valores correctos de FID son de 2.5 segundos o menos, los valores malos son mayores a 4.0 segundos y cualquier valor intermedio debe mejorarse

FID en detalle

Como los desarrolladores que escriben código que responde a los eventos, a menudo damos por sentado que nuestro código se ejecutará de inmediato, en cuanto ocurra el evento. Sin embargo, como usuarios, todos hemos experimentado lo contrario con frecuencia: cargamos una página web en nuestro teléfono, intentamos interactuar con ella y, luego, nos sentíamos frustrados cuando no pasó nada.

En general, la demora de entrada (también conocida como latencia de entrada) ocurre porque el subproceso principal del navegador está ocupado realizando otra tarea, por lo que (aún) no puede responder al usuario. Esto puede ocurrir porque el navegador está ocupado analizando y ejecutando un archivo JavaScript grande cargado por tu app. Mientras lo hace, no puede ejecutar ningún objeto de escucha de eventos porque el JavaScript que se está cargando podría indicarle que haga otra cosa.

Ten en cuenta el siguiente cronograma de carga típica de una página web:

Ejemplo de seguimiento de carga de página

En la visualización anterior, se muestra una página que realiza un par de solicitudes de red de recursos (probablemente archivos CSS y JS) y, una vez que esos recursos terminan de descargarse, se procesan en el subproceso principal.

Esto genera períodos en los que el subproceso principal está temporalmente ocupado, lo que se indica mediante los bloques task de color beige.

Por lo general, las demoras de primera entrada prolongadas ocurren entre el First Contentful Paint (FCP) y el Tiempo de carga (TTI) porque la página renderizó parte de su contenido, pero aún no es interactiva de forma confiable. Para ilustrar cómo puede suceder esto, se agregaron FCP y TTI al cronograma:

Ejemplo de seguimiento de carga de página con FCP y TTI

Es posible que hayas notado que hay un tiempo considerable (incluidas tres tareas largas) entre FCP y TTI. Si un usuario intenta interactuar con la página durante ese tiempo (por ejemplo, si hace clic en un vínculo), habrá una demora entre el momento en que se recibe el clic y el momento en que el subproceso principal puede responder.

Considera qué pasaría si un usuario intentara interactuar con la página cerca del comienzo de la tarea más larga:

Ejemplo de seguimiento de carga de página con FCP, TTI y FID

Debido a que la entrada se produce mientras el navegador está ejecutando una tarea, debe esperar hasta que se complete la tarea para poder responder a la entrada. El tiempo que debe esperar es el valor de FID para este usuario en esta página.

¿Qué sucede si una interacción no tiene un objeto de escucha de eventos?

FID mide el delta entre el momento en que se recibe un evento de entrada y el momento en que el subproceso principal queda inactivo. Esto significa que el FID se mide incluso en los casos en los que no se registró un objeto de escucha de eventos. Esto se debe a que muchas interacciones del usuario no requieren un objeto de escucha de eventos, pero requieren que el subproceso principal esté inactivo para ejecutarse.

Por ejemplo, todos los siguientes elementos HTML deben esperar a que se completen las tareas en curso en el subproceso principal antes de responder a las interacciones del usuario:

  • Campos de texto, casillas de verificación y botones de selección (<input>, <textarea>)
  • Seleccionar menús desplegables (<select>)
  • vínculos (<a>)

¿Por qué considerar solo la primera entrada?

Si bien una demora de cualquier entrada puede generar una mala experiencia del usuario, recomendamos, principalmente, que midas el retraso de la primera entrada por varios motivos:

  • El retraso de primera entrada será la primera impresión que tenga el usuario de la capacidad de respuesta de tu sitio, y las primeras impresiones son fundamentales para dar forma a nuestra impresión general de la calidad y la confiabilidad de un sitio.
  • Los mayores problemas de interactividad que vemos en la Web actualmente ocurren durante la carga de la página. Por lo tanto, creemos que, inicialmente, enfocarte en mejorar la primera interacción del usuario del sitio tendrá el mayor impacto en mejorar la interactividad general de la Web.
  • Las soluciones recomendadas para el modo en que los sitios deben corregir los retrasos altos de la primera entrada (división del código, carga menos JavaScript por adelantado, etc.) no son necesariamente las mismas para corregir retrasos en las entradas lentas después de la carga de la página. Si separas estas métricas, podremos proporcionar lineamientos de rendimiento más específicos a los desarrolladores web.

¿Qué se considera una primera entrada?

FID es una métrica que mide la capacidad de respuesta de una página durante la carga. Por lo tanto, solo se enfoca en los eventos de entrada de acciones discretas, como clics, presiones y pulsaciones de teclas.

Otras interacciones, como el desplazamiento y el zoom, son acciones continuas y tienen restricciones de rendimiento completamente diferentes (también, los navegadores a menudo pueden ocultar su latencia ejecutándolas en un subproceso independiente).

Para decirlo de otra manera, FID se enfoca en R (capacidad de respuesta) en el modelo de rendimiento RAIL, mientras que el desplazamiento y el zoom están más relacionados con la A (animación), y sus calidades de rendimiento deben evaluarse por separado.

¿Qué sucede si un usuario nunca interactúa con tu sitio?

No todos los usuarios interactuarán con tu sitio cada vez que lo visiten. Además, no todas las interacciones son relevantes para el FID (como se mencionó en la sección anterior). Además, las primeras interacciones de algunos usuarios se producirán en mal momento (cuando el subproceso principal esté ocupado durante un período prolongado) y las primeras interacciones de algunos usuarios ocurrirán en buenos momentos (cuando el subproceso principal esté completamente inactivo).

Esto significa que algunos usuarios no tendrán valores de FID, otros tendrán valores de FID bajos y otros probablemente tendrán valores de FID altos.

Es probable que la forma de hacer un seguimiento de los FID, generar informes sobre ellos y analizarlos difiera bastante de otras métricas a las que podrías estar acostumbrado. En la siguiente sección, se explica la mejor manera de hacerlo.

¿Por qué solo considerar el retraso de entrada?

Como se mencionó anteriormente, FID solo mide el "retraso" en el procesamiento de eventos. No mide el tiempo de procesamiento del evento ni el tiempo que le toma al navegador actualizar la IU después de ejecutar los controladores de eventos.

Aunque este tiempo es importante para el usuario y afecta la experiencia, no se incluye en esta métrica porque podría incentivar a los desarrolladores a agregar soluciones alternativas que realmente empeoren la experiencia, es decir, pueden unir la lógica del controlador de eventos en una devolución de llamada asíncrona (a través de setTimeout() o requestAnimationFrame()) para separarla de la tarea asociada con el evento. El resultado sería una mejora en la puntuación de la métrica, pero una respuesta más lenta según la percepción del usuario.

Sin embargo, aunque el FID solo mide la porción "retraso" de la latencia de eventos, los desarrolladores que deseen realizar un seguimiento mayor del ciclo de vida de eventos pueden hacerlo con la API de Event Timing. Consulta la guía sobre métricas personalizadas para obtener más detalles.

Cómo medir el FID

El FID es una métrica que solo se puede medir en el campo, ya que requiere que un usuario real interactúe con la página. Puedes medir el FID con las siguientes herramientas.

Herramientas de campo

Mide FID en JavaScript

Para medir FID en JavaScript, puedes usar la API de Event Timing. En el siguiente ejemplo, se muestra cómo crear una PerformanceObserver que escuche las entradas first-input y las registre en la consola:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

En el ejemplo anterior, el valor de retraso de la entrada first-input se mide cuando se toma el delta entre las marcas de tiempo startTime y processingStart de la entrada. En la mayoría de los casos, este será el valor del FID. Sin embargo, no todas las entradas first-input son válidas para medir el FID.

En la siguiente sección, se enumeran las diferencias entre lo que informa la API y cómo se calcula la métrica.

Diferencias entre la métrica y la API

  • La API enviará entradas first-input para las páginas cargadas en una pestaña en segundo plano, pero esas páginas deberían ignorarse cuando se calcula el FID.
  • La API también enviará entradas first-input si la página pasó a segundo plano antes de que se produzca la primera entrada, pero esas páginas también deben ignorarse cuando se calcula el FID (las entradas solo se consideran si la página estuvo en primer plano todo el tiempo).
  • La API no informa entradas first-input cuando se restablece la página desde la memoria caché atrás/adelante, pero se debe medir el FID en estos casos, ya que los usuarios las experimentan como visitas distintas a la página.
  • La API no informa las entradas que ocurren dentro de los iframes, pero la métrica sí, ya que son parte de la experiencia del usuario de la página. Esto puede mostrarse como una diferencia entre CrUX y RUM. Para medir correctamente los FID, debes considerarlos. Los submarcos pueden usar la API para informar sus entradas first-input al marco superior para la agregación.

En lugar de memorizar todas estas diferencias sutiles, los desarrolladores pueden usar la biblioteca de JavaScript web-vitals para medir el FID, que se encarga de estas diferencias (siempre que sea posible, pero ten en cuenta que el problema de iframe no se aborda):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Puedes consultar el código fuente de onFID() para obtener un ejemplo completo de la medición de FID en JavaScript.

Análisis e informes sobre los datos FID

Debido a la variación esperada en los valores de FID, es fundamental que, cuando informes sobre FID, observes la distribución de los valores y te enfoques en los percentiles más altos.

Si bien la elección del percentil para todos los umbrales de las Métricas web esenciales es el 75, en particular para las FID, te recomendamos que observes los percentiles 95 al 99, ya que corresponderán a las primeras experiencias particularmente malas que tienen los usuarios con tu sitio. Y te mostrará las áreas que necesitan más mejoras.

Esto ocurrirá incluso si segmentas tus informes por categoría o tipo de dispositivo. Por ejemplo, si ejecutas informes separados para computadoras de escritorio y dispositivos móviles, el valor de FID que más te interesa en computadoras de escritorio debe ser el percentil 95-99 de los usuarios de computadoras, y el valor de FID que más te interesa en dispositivos móviles debe ser el percentil 95-99 de los usuarios de estos dispositivos.

Cómo mejorar FID

Hay una guía completa disponible para optimizar el FID con el fin de guiarte por las técnicas para mejorar esta métrica.

Registro de cambios

Ocasionalmente, se descubren errores en las APIs que se usan para medir métricas y, a veces, en las definiciones de las métricas en sí. Como resultado, a veces es necesario realizar cambios, que pueden aparecer como mejoras o regresiones en tus informes y paneles internos.

Para ayudarte a administrar esto, todos los cambios en la implementación o definición de estas métricas aparecerán en este Registro de cambios.

Si tienes comentarios sobre estas métricas, puedes enviarlos en el grupo de Google web-vitals-feedback.