First Input Delay (FID)

Nov 7, 2019 — Actualizado Jul 18, 2022

Available in: English, Português, Русский, 中文, 日本語 y 한국어

Appears in: Tiempos de carga rápidos | Core Web Vitals | Métricas

Todos sabemos lo importante que es causar una buena primera impresión. Es importante cuando se conoce a gente nueva, y también es importante cuando se desarrollan experiencias en la web.

En la web, una buena primera impresión puede marcar la diferencia entre que alguien se convierta en un usuario leal o que se vaya y nunca regrese. La pregunta es, ¿qué es lo que da una buena impresión y cómo se puede medir qué tipo de impresión está causando en los usuarios?

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

Si bien es difícil medir el gusto de los usuarios por el diseño de un sitio con API web, ¡no lo es medir su velocidad y capacidad de respuesta!

La primera impresión que tienen los usuarios de la rapidez con la que se carga su sitio se puede medir con First Contentful Paint (FCP). Pero la rapidez con la que su sitio puede pintar pixeles en la pantalla es solo una parte de la historia. ¡La capacidad de respuesta de su sitio es igualmente importante cuando los usuarios intentan interactuar con esos pixeles!

La métrica First Input Delay (FID) ayuda a medir la primera impresión de su usuario sobre la interactividad y capacidad de respuesta de su sitio.

¿Qué es FID? #

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

Los valores de fid correctos son 2,5 segundos, los valores deficientes son superiores a 4,0 segundos y cualquier valor intermedio debe mejorarse

¿Qué es una buena puntuación FID? #

Para proporcionar una buena experiencia de usuario, los sitios deben esforzarse por tener una First Input Delay de 100 milisegundos o menos. Para asegurarse de que está alcanzando este objetivo para la mayoría de sus usuarios, un buen umbral para medir es el percentil 75 de cargas de página, segmentado en dispositivos móviles y de escritorio.

FID en detalle #

Como desarrolladores que escriben código el cual responde a eventos, con frecuencia asumimos que nuestro código se ejecutará inmediatamente, tan pronto como suceda el evento. Pero como usuarios, a menudo todos hemos experimentado lo contrario: cargamos una página web en nuestro teléfono, intentamos interactuar con ella y luego nos sentimos frustrados cuando no sucedía nada.

En general, la demora de la entrada (también conocida como latencia de la entrada) ocurre porque el subproceso principal del navegador está ocupado haciendo otra cosa, por lo que no puede (todavía) responder al usuario. Una razón común por la que esto puede suceder es que el navegador está ocupado analizando y ejecutando un archivo JavaScript grande, que carga su aplicación. Mientras hace eso, no puede ejecutar ningún detector de eventos porque el JavaScript que está cargando podría indicarle que haga otra cosa.

Considere la siguiente línea de tiempo para cargar una página web normal:

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

Esto da como resultado periodos en los que el subproceso principal momentáneamente está ocupado, lo que se indica mediante los bloques de tareas de color beige.

Los retrasos prolongados en la primera entrada normalmente suceden entre el First Contentful Paint: Primer despliegue de contenido (FCP) y el Time to Interactive: Momento para interactuar (TTI) porque la página procesó 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 a la línea de tiempo:

Es posible que haya notado que hay una buena cantidad de tiempo (que incluye tres tareas largas ) entre FCP y TTI, si un usuario intenta interactuar con la página durante ese tiempo (por ejemplo, haga clic en un enlace), habrá una demora entre el momento en que el se recibe un clic y cuando el subproceso principal puede responder.

Considere lo que sucedería si un usuario intenta interactuar con la página cuando está cerca de que inicie de la tarea más larga:

Debido a que la entrada se produce mientras el navegador ejecuta una tarea, debe esperar hasta que la tarea se complete antes de que pueda 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 detector de eventos? #

FID mide la delta entre el momento en que se recibe un evento de entrada y el siguiente momento en que el subproceso principal está inactivo. Esto significa que FID se mide incluso en los casos en que no se registró un detector de eventos. La razón se debe a que muchas interacciones de los usuarios no requieren de un detector de eventos, pero se requiere que el subproceso principal esté inactivo para que se pueda ejecutar.

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 opción (<input>, <textarea>)
Seleccionar menús desplegables ( <select> )
Enlaces (<a>)

¿Por qué se debe considerar solo la primera entrada? #

Si bien un retraso de cualquier entrada puede provocar una mala experiencia del usuario, principalmente recomendamos que mida la demora de la primera entrada por algunas razones:

La primera demora en la entrada será la primera impresión del usuario sobre la capacidad de respuesta de su sitio, y las primeras impresiones son críticas para dar forma a nuestra impresión general de la calidad y confiabilidad de un sitio.
Los mayores problemas de interactividad que vemos en la web hoy en día ocurren cuando carga una página. Por lo tanto, creemos que centrarse inicialmente en mejorar la primera interacción del usuario del sitio tendrá el mayor impacto en la mejora de la interactividad general de la web.
Las soluciones recomendadas sobre cómo los sitios deben corregir las grandes demoras en la primera entrada (división de código, carga de menos JavaScript por adelantado, etc.) no son necesariamente las mismas soluciones para corregir retrasos lentos en la entrada después que se cargue la página. Al separar estas métricas, podremos proporcionar normas de rendimiento más específicas para los desarrolladores web.

¿Qué cuenta como primera entrada? #

FID es una métrica que mide la capacidad de respuesta de una página durante la carga. Como tal, solo se enfoca en eventos de entrada para acciones discretas como dar clics, pulsar y presionar teclas.

Otras interacciones, como el desplazamiento y el acercamiento, son acciones continuas y tienen restricciones de rendimiento completamente diferentes (además, los navegadores con frecuencia pueden ocultar su latencia cuando se ejecutan en un subproceso separado).

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

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

No todos los usuarios interactuarán con su sitio cada vez que lo visitan. Y no todas las interacciones son relevantes para FID (como se mencionó en la sección anterior). Además, las primeras interacciones de algunos usuarios serán en los malos momentos (cuando el subproceso principal está ocupado durante un periodo prolongado de tiempo), y las primeras interacciones de algunos usuarios serán en los buenos momentos (cuando el subproceso principal está completamente inactivo).

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

La forma en que sigue, reporta y analiza FID probablemente será bastante diferente de otras métricas a las que puede estar acostumbrado. En la siguiente sección se explica cuál es la mejor manera de hacer esto.

¿Por qué solo considerar la demora en la entrada? #

Como se mencionó anteriormente, FID solo mide la "demora" en el procesamiento de eventos. No mide el tiempo en que se procesan los eventos perse, ni el tiempo que tarda el navegador en actualizar la interfaz del usuario después de que se ejecuten los controladores de eventos.

A pesar de que este tiempo es importante para el usuario y afecta a la experiencia, que no se incluye en este indicador, ya que si se hace podría incentivar a los desarrolladores a que agreguen soluciones que realmente hagan que la experiencia empeore, es decir, que puede envolver su lógica para controlar eventos en una devolución de llamada asíncrona (a través de setTimeout() o requestAnimationFrame()) para que se separe 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 que percibe el usuario.

Sin embargo, aunque FID solo mide la parte de la "demora" de la latencia del evento, los desarrolladores que quieran realizar un seguimiento mayor del ciclo de vida del evento pueden hacerlo mediante la API para cronometrar eventos. Consulte la guía sobre métricas personalizadas para obtener más información.

Cómo medir FID #

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

Herramientas de campo #

Cómo medir FID en JavaScript #

Browser support

chrome 76, Supported 76
firefox 89, Supported 89
edge 79, Supported 79
safari, Not supported ×

Source

Para medir FID en JavaScript, puede utilizar la API para cronometrar eventos. En el siguiente ejemplo se muestra cómo crear un PerformanceObserver que capte 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 demora para la entrada first-input se mide al tomar la delta entre las marcas de tiempo startTime y processingStart. En la mayoría de los casos, este será el valor FID, sin embargo, no todas las first-input son válidas para medir FID.

La siguiente sección enumera 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á first-input para las páginas que se carguen en una pestaña de segundo plano, pero esas páginas deben ignorarse al calcular FID.
La API también enviará first-input si la página estaba en segundo plano antes de que ocurriera la primera entrada, pero esas páginas también deben ignorarse cuando se calcula FID (las entradas solo se consideran si la página estuvo en primer plano todo el tiempo).
La API no reporta las entradas first-input cuando la página se restaura desde la caché de retroceso/avance, pero FID debe medirse en estos casos, ya que los usuarios las perciben como distintas visitas de la página.
La API no reporta las entradas que suceden dentro de los iframes, pero para medir correctamente FID, se deben considerar. Los sub-marcos pueden usar la API para reportar sus entradas first-input al marco principal para su incorporación.

En vez de memorizar todas estas diferencias sutiles, los desarrolladores pueden usar la biblioteca de JavaScript web-vitals para medir FID, que maneja estas diferencias por usted (cuando sea posible):

import {onFID} from 'web-vitals';

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

Puede consultar el código fuente de onFID) para obtener un ejemplo completo de cómo medir FID en JavaScript.

Analizar y reportar los datos de FID #

Debido a la variación esperada en los valores de FID, es fundamental que al informar sobre FID observe la distribución de valores y se concentre en los percentiles más altos.

Si bien la elección del percentil para todos los umbrales de Core Web Vitals es el 75, para FID en particular recomendamos encarecidamente que consulte los percentiles 95 al 99, ya que corresponderán a las primeras experiencias particularmente malas que los usuarios tienen con su sitio. Y le mostrarán las áreas que necesitan más mejoras.

Esto es así incluso si segmenta sus reportes por categoría o tipo de dispositivo. Por ejemplo, si ejecuta informes separados para computadoras de escritorio y dispositivos móviles, el valor de FID que más le interesa en las computadoras de escritorio deben ser los percentiles 95 al 99 de los usuarios de computadoras de escritorio, y el valor de FID que más le interesa en los dispositivos móviles deben ser los percentiles 95 al 99 de los usuarios de dispositivos móviles.

Cómo mejorar FID #

Para aprender a mejorar FID para un sitio específico, puede ejecutar una auditoría de desempeño Lighthouse y prestar atención a cualquier oportunidad específica que sugiera la auditoría.

Si bien FID es una métrica de campo (y Lighthouse es una herramienta de métrica de laboratorio), la guía para mejorar FID es la misma que para mejorar la métrica de laboratorio Total Blocking Time (TBT) .

Para profundizar en cómo mejorar FID, consulte Optimizar FID. Para obtener orientación adicional sobre las técnicas de desempeño individual que también pueden mejorar FID, consulte:

CHANGELOG #

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.

Última actualización: Jul 18, 2022 — Mejorar el artículo

Return to all articles