First Input Delay (FID)

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Philip Walton

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

En la Web, una buena primera impresión puede marcar la diferencia entre que un usuario se convierta en un usuario leal o que se vaya y nunca regrese. La pregunta es, ¿qué hace que una impresión sea buena y cómo mides qué tipo de impresión estás causando en tus usuarios?

En la Web, las primeras impresiones pueden adoptar muchas formas diferentes: tenemos primeras impresiones sobre el diseño y el atractivo visual de un sitio, así como sobre su velocidad y capacidad de respuesta.

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

La primera impresión que tienen los usuarios sobre la rapidez con la que se carga tu sitio se puede medir con el primer procesamiento de imagen con contenido (FCP). Sin embargo, la velocidad con la que tu sitio puede pintar píxeles en la pantalla es solo una parte de la historia. Igualmente 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 de los usuarios sobre la interactividad y la capacidad de respuesta de tu sitio.

¿Qué es el FID?

El 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 impulsado por JavaScript) hasta que el navegador puede comenzar a procesar los controladores de eventos en respuesta a esa interacción.

¿Cuál es una buena puntuación de FID?

Para proporcionar una buena experiencia del usuario, los sitios deben esforzarse por tener una demora de la 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 los dispositivos móviles y las computadoras de escritorio.

FID en detalle

Como desarrolladores que escriben código que responde a eventos, a menudo suponemos que nuestro código se ejecutará de inmediato, en cuanto ocurra el evento. Sin embargo, como usuarios, todos experimentamos con frecuencia lo contrario: cargamos una página web en nuestro teléfono, intentamos interactuar con ella y, luego, nos frustramos cuando no sucede nada.

En general, la demora de entrada (también conocida como latencia de entrada) ocurre porque el subproceso principal del navegador está ocupado haciendo otra tarea, por lo que aún no puede responder al usuario. Un motivo común por el que puede ocurrir esto es que el navegador está ocupado analizando y ejecutando un archivo JavaScript grande que cargó tu app. Mientras lo hace, no puede ejecutar ningún objeto de escucha de eventos porque el código JavaScript que carga puede indicarle que haga otra cosa.

Considera el siguiente cronograma de una carga típica de una página web:

En la visualización anterior, se muestra una página que realiza un par de solicitudes de red para recursos (lo más probable es que sean archivos CSS y JS) y, después de que se terminan de descargar esos recursos, se procesan en el subproceso principal.

Esto genera períodos en los que el subproceso principal está ocupado momentáneamente, lo que se indica con los bloques de tarea de color beige.

Los retrasos largos de la primera entrada suelen ocurrir entre el primer procesamiento de imagen con contenido (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 el FCP y el TTI al cronograma:

Es posible que hayas notado que hay una cantidad considerable de tiempo (incluidas tres tareas largas) entre el FCP y el TTI. Si un usuario intenta interactuar con la página durante ese tiempo (por ejemplo, haciendo 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 lo que sucedería si un usuario intentara interactuar con la página cerca del comienzo de la tarea más larga:

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

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

El FID mide la diferencia entre el momento en que se recibe un evento de entrada y el momento en que el subproceso principal está inactivo. Esto significa que el FID se mide incluso en los casos en que no se registró un objeto de escucha de eventos. El motivo es que muchas interacciones del usuario no requieren un objeto de escucha de eventos, pero sí 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>)
• Menús desplegables seleccionados (<select>)
• vínculos (<a>)

¿Por qué solo se considera la primera entrada?

Si bien una demora en cualquier entrada puede generar una mala experiencia del usuario, te recomendamos medir principalmente la primera demora de entrada por los siguientes motivos:

• La primera demora de entrada será la primera impresión del usuario sobre la capacidad de respuesta de tu sitio, y las primeras impresiones son fundamentales para definir nuestra impresión general sobre la calidad y la confiabilidad de un sitio.
• Los mayores problemas de interactividad que vemos en la Web hoy en día ocurren durante la carga de la página. Por lo tanto, creemos que enfocarse inicialmente en mejorar la primera interacción del usuario con el sitio tendrá el mayor impacto en la mejora de la interactividad general de la Web.
• Las soluciones recomendadas para que los sitios corrijan las demoras de entrada iniciales altas (división de código, carga de menos JavaScript por adelantado, etc.) no son necesariamente las mismas soluciones para corregir las demoras de entrada lentas después de la carga de la página. Si separamos estas métricas, podremos proporcionar lineamientos de rendimiento más específicos a los desarrolladores web.

¿Qué se considera una primera entrada?

El 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, toques y presiones de teclas.

Otras interacciones, como el desplazamiento y el zoom, son acciones continuas y tienen restricciones de rendimiento completamente diferentes (además, los navegadores suelen poder ocultar su latencia ejecutándolos en un subproceso independiente).

En otras palabras, el FID se enfoca en la R (responsividad) del modelo de rendimiento RAIL, mientras que el desplazamiento y el zoom están más relacionados con la A (animación), y sus cualidades 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 serán en momentos inoportunos (cuando el subproceso principal esté ocupado durante un período prolongado) y las primeras interacciones de otros usuarios serán en momentos oportunos (cuando el subproceso principal esté completamente inactivo).

Esto significa que algunos usuarios no tendrán valores de FID, algunos tendrán valores de FID bajos y es probable que algunos tengan valores de FID altos.

La forma en que realices el seguimiento, generes informes y analices la FID probablemente sea bastante diferente de otras métricas que ya conozcas. En la siguiente sección, se explica cómo hacerlo.

¿Por qué solo se considera la demora de entrada?

Como se mencionó anteriormente, el FID solo mide la "demora" en el procesamiento de eventos. No mide la duración total del procesamiento de eventos ni el tiempo que tarda el navegador en actualizar la IU después de ejecutar controladores de eventos.

Aunque este tiempo es importante para el usuario y afecta la experiencia, no se incluye en esta métrica porque hacerlo podría incentivar a los desarrolladores a agregar soluciones alternativas que, en realidad, empeoran la experiencia, es decir, podrían unir la lógica de su 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 lo perciba el usuario.

Sin embargo, mientras que el FID solo mide la parte de "demora" de la latencia del evento, los desarrolladores que quieran hacer un seguimiento de más del ciclo de vida del evento 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 tu página. Puedes medir el FID con las siguientes herramientas.

Herramientas de campo

• Informe de experiencia del usuario de Chrome
• PageSpeed Insights
• Search Console (informe de métricas web esenciales)
• Biblioteca de JavaScript de web-vitals

Mide el FID en JavaScript

Para medir el FID en JavaScript, puedes usar la API de Event Timing. En el siguiente ejemplo, se muestra cómo crear un PerformanceObserver que escuche entradas de 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 tomando la diferencia entre las marcas de tiempo startTime y processingStart de la entrada. En la mayoría de los casos, este será el valor de FID. Sin embargo, no todas las entradas de 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 se deben ignorar cuando se calcula el FID.
• La API también enviará entradas first-input si la página se puso en segundo plano antes de que se produjera la primera entrada, pero esas páginas también se deben ignorar 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 de first-input cuando la página se restablece desde la caché de atrás/adelante, pero se debe medir el FID en estos casos, ya que los usuarios lo experimentan como visitas a páginas distintas.
• La API no informa las entradas que se producen dentro de los iframes, pero la métrica sí, ya que forman parte de la experiencia del usuario en la página. Esto puede mostrarse como una diferencia entre CrUX y RUM. Para medir correctamente el FID, debes considerarlos. Los submarcos pueden usar la API para informar sus entradas first-input al marco superior para la agregación.

Analiza y genera informes sobre los datos de FID

Debido a la varianza esperada en los valores de FID, es fundamental que, cuando informes sobre el 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 el caso de la FID, en particular, te recomendamos que mires los percentiles del 95% al 99%, ya que corresponden a las primeras experiencias particularmente malas que los usuarios tienen con tu sitio. Además, te mostrará las áreas que más necesitan mejoras.

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

Cómo mejorar el FID

Hay disponible una guía completa sobre la optimización de la FID para guiarte en las técnicas que te permitirán mejorar esta métrica.

Registro de cambios

En ocasiones, se descubren errores en las APIs que se usan para medir las métricas y, a veces, en las definiciones de las métricas. Como resultado, a veces se deben realizar cambios, y estos 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 se mostrarán en este registro de cambios.

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