Es el turno de la segunda métrica más importante de las Core Web Vitals: el FID o First Input Delay. Como ya te decíamos en el artículo sobre la primera métrica de la que hablamos, LCP o Largest Contentful Paint, si estás al tanto de las actulizaciones de Google, sabrás que las Core Web Vitals ya están aquí, ha llegado ya durante este mes de Mayo para quedarse. Estas Core Web Vitals son tres, pero en este caso queremos centrarnos sobre una de ellas, tal y como hicimos con la LCP, y tal y como haremos con la tercera más adelante, la CLS.
Para empezar, ¿qué significa FID? La métrica FID se podría traducir como «Latencia de la primera interacción». ¿Y esto qué quiere decir exactamente? Pues básicamente esto quiere decir que la métrica FID mide la interactividad que tiene un usuario con una página. Fácil, ¿no? Esta es la principal idea que nos da esta métrica, ahora vamos a ver cómo funciona más en profundidad.
La métrica FID mide el tiempo de retraso que transcurre desde que un usuario interactúa por primera vez con una página (por ejemplo, cuando hace clic en un enlace, toca un botón o usa un control personalizado impulsado por JavaScript) hasta que el navegador comienza a procesar controladores de eventos en respuesta a dicha interacción.
¡Ojo! Esta métrica FID solo mide el «retraso» en el procesamiento de eventos. No mide el tiempo de procesamiento de eventos como tal, ni tampoco mide el tiempo que tarda el navegador en actualizar la interfaz de usuario después de ejecutar los controladores de eventos.
Y, ¿qué es este retraso? ¿Por qué se produce? El retraso de entrada (también conocido como latencia de entrada) ocurre porque el hilo principal del navegador está ocupado haciendo otra cosa, como por ejemplo, analizando y ejecutando un archivo JavaScript grande cargado por su aplicación. Mientras hace eso no puede ejecutar ningún detector de eventos, por lo que no puede, todavía, responder al usuario.
Ahora que estamos entiendo mejor cómo funciona, es muy posible que te estén surgiendo algunas de estas preguntas:
¡Vamos a darles respuesta!
Ahora mismo ya tienes una idea general de qué trata esta métrica y cómo funciona, pero aún nos queda mucho por saber y te habrás dado cuenta porque te habrán surgido algunas dudas que tienes sin resolver. En lo que vas a leer a continuación esperamos resolvértelas ??
La métrica FID mide el tiempo entre el momento en que se recibe un evento de entrada y el momento en que el hilo principal está inactivo. Esto significa que este tiempo podrá ser medido incluso en los casos en los que no se ha registrado un detector de eventos.
Los elementos HTML que deben esperar a que se completen las tareas en curso en el hilo principal antes de responder a las interacciones del usuario son:
Es cierto que un retraso en cualquier entrada puede provocar una mala experiencia del usuario, no sólo la primera. Sin embargo, son algunas de estas razonas por las cuales se considera medir sólo la primera:
Hemos hablado varias veces de «primera entrada» pero, ¿a qué estamos haciendo referencia con esto exactamente? Como tal, hace referencia a eventos de entrada como clics y pulsaciones de teclas. Otras interacciones, como el desplazamiento y el zoom, son acciones continuas y tienen mediciones de rendimiento completamente diferentes.
Para entenderlo mejor, el FID se centra en la R (capacidad de respuesta) en el modelo de rendimiento de RAIL , mientras que el desplazamiento y el zoom están más relacionados con A (animación). Por tanto, sus cualidades de rendimiento deben evaluarse por separado.
No todos los usuarios interactuarán con el sitio cada vez que lo visitan, de la misma forma que las primeras interacciones de algunos usuarios pueden ser en momentos en los que el hilo principal esté ocupado durante un período prolongado de tiempo o en los que el hilo principal está completamente inactivo.
Esto básicamente significa que algunos usuarios no tendrán valores FID, que algunos otros tendrán valores FID bajos y que otros probablemente tendrán valores FID altos.
Es cierto que todo el tiempo de procesamiento de eventos, no sólo la latencia, afecta a la experiencia del usuario directamente, pero incluir lo primero como parte de FID incentivaría a los desarrolladores a responder a los eventos de forma asincrónica a través de setTimeout() o requestAnimationFrame(). ¿Mejoraría la métrica como tal? Sí, pero probablemente empeoraría la experiencia pues sigue siendo una respuesta más lenta para el usuario, que es justamente donde está el punto de mira.
Aunque el FID solo mide la parte de «retraso» de la latencia del evento, si quieres realizar un seguimiento mayor del ciclo de vida del evento, puedes hacerlo mediante la API de temporización de eventos.
Cuando un usuario rellena un formulario de contacto y hace clic en el siguiente paso, este paso puede tardar 1 segundo en aparecer. Si esto ocurre, se considera que el FID es demasiado lento y puede generar frustración para el usuario.
Cuando un usuario hace clic en un botón y la página responde a esta interacción en menos de 100ms, el FID se considera bueno.
En conclusión, para proporcionar una buena experiencia de usuario, los sitios deben tener como mucho un retraso en la primera entrada de 100 milisegundos o menos. ¿Cuáles son los valores adecuados a partir de esto?
Para realizar estas mediciones del FID, contamos con herramientas que realizan esta función, aunque también podríamos saberlo a través de código JavaScript de forma manual.
