First Input Delay (FID)

Philip Walton

Todos sabemos lo importante que es causar una buena primera impresi�n. Es importante a la hora de conocer gente nueva. Tambi�n es importante la Web.

En la Web, una buena primera impresi�n puede marcar la diferencia entre alguien se convierte en un usuario leal o se va y nunca regresa. La pregunta es: qu� causa una buena impresi�n, y c�mo mides qu� tipo de impresi�n que probablemente generas con tus usuarios?

En la Web, las primeras impresiones pueden adoptar muchas formas diferentes: 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 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 de la velocidad de carga de tu sitio se puede medir con Primer procesamiento de imagen con contenido (FCP): Sin embargo, la velocidad con la que tu sitio puede pintar p�xeles a la pantalla es solo una parte de la historia. Igual de importante es la capacidad de respuesta su sitio es 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 tu usuario de la interactividad y la capacidad de respuesta de tu sitio.

�Qu� es el FID?

FID mide el tiempo que transcurre desde que un usuario interact�a con una p�gina por primera vez (es decir, hacen clic en un v�nculo, presionan un bot�n o usan un control personalizado con 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 del FID?

Para proporcionar una buena experiencia del usuario, los sitios deben esforzarse por tener una primera entrada Retraso de 100 milisegundos o menos Para asegurarte de alcanzar este objetivo por para la mayor�a de los usuarios, un buen umbral para medir es el percentil 75 de cargas de p�ginas, segmentadas en dispositivos m�viles y de escritorio.

FID en detalle

Como desarrolladores que escriben c�digo que responde a eventos, a menudo suponemos que nuestro c�digo se ejecutar� inmediatamente, tan pronto como ocurra el evento. Pero como usuarios, todos hemos experimentado con frecuencia lo contrario: cargamos una p�gina web en nuestro tel�fono, intent� interactuar con �l y, luego, se sinti� frustrado cuando nada de que ocurra.

En general, la demora en la entrada (tambi�n conocida como latencia de entrada) se produce porque el subproceso principal est� ocupado haciendo otra cosa, por lo que (todav�a) no puede 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 cargado por la app. Mientras hace eso, no se puede ejecutar los objetos de escucha de eventos, ya que el JavaScript que se esté cargando podría indicarle que haga o algo más.

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

La visualización anterior muestra una página que está haciendo un par de solicitudes de red para los recursos (probablemente archivos CSS y JS) y, después de esos recursos, se terminan de descargar y se procesan en el subproceso principal.

Esto genera períodos en los que el subproceso principal está temporalmente ocupado, que es se indica con el color beige tarea bloques.

Por lo general, se producen retrasos prolongados en la primera entrada entre el primer procesamiento de imagen con contenido (FCP) y el tiempo de carga (TTI) porque la página tiene renderizado parte de su contenido, pero aún no es confiable de forma interactiva. Para ilustrar cómo puede suceder esto, se agregaron FCP y TTI al cronograma:

Habrás notado que hay bastante tiempo (incluidos tres largos tareas) entre el FCP y el TTI, si un usuario intenta interactuar con la página durante ese tiempo (por ejemplo, si haces clic en un vínculo), se mostrará de retraso entre el momento en que se recibe el clic y el momento en que el subproceso principal puede responder.

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

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 el tiempo de espera 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 est� inactivo el siguiente subproceso. Esto significa que el FID se mide incluso en los casos en que No se registr� el objeto de escucha. Esto se debe a que muchas interacciones del usuario no requieren un objeto de escucha de eventos, pero s� requieren que el subproceso principal est� inactivo para que se ejecute.

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

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

�Por qu� considerar solo la primera entrada?

Si bien un retraso en cualquier entrada puede llevar a una mala experiencia del usuario, principalmente se recomienda medir el retraso de primera entrada por los siguientes motivos:

• La primera demora en la entrada ser� la primera impresi�n que tendr� el usuario de la p�gina la capacidad de respuesta y las primeras impresiones son fundamentales impresi�n de la calidad y confiabilidad de un sitio.
• Los mayores problemas de interactividad que vemos hoy en la Web ocurren durante de carga de trabajo. Por lo tanto, creemos que, al principio, nos centraremos en mejorar la experiencia del primer usuario interacci�n tendr� m�s impacto en la mejora del la interactividad de la Web.
• Las soluciones recomendadas sobre c�mo los sitios deben corregir las demoras altas en la primera entrada (divisi�n de c�digo, carga menos JavaScript por adelantado, etc.) no son necesariamente usan las mismas soluciones para corregir las demoras en las entradas despu�s de cargar la p�gina. Mediante la separaci�n estas m�tricas, podremos ofrecer informaci�n m�s espec�fica lineamientos para desarrolladores web.

¿Qué se considera como una primera entrada?

FID es una métrica que mide la capacidad de respuesta de una página durante la carga. Por ello, Solo se enfoca en eventos de entrada de acciones discretas, como clics, presiones y botones las imprentas.

Otras interacciones, como desplazarse y hacer zoom, son acciones continuas y tienen restricciones de rendimiento completamente diferentes (además, los navegadores a menudo pueden ocultarlos ejecutándolos en un subproceso separado).

En otras palabras, FID se centra en el R (capacidad de respuesta) de la RAIL rendimiento tradicional, mientras que el desplazamiento y el zoom están más relacionados con A (animación) y su rendimiento cualidades 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. Y no todas son relevantes para los FID (como se mencionó en la sección anterior). En además, las primeras interacciones de algunos usuarios serán en momentos malos (cuando el evento principal está ocupado durante un período prolongado), y el primer mensaje de las interacciones se realizarán en un buen momento (cuando el subproceso principal esté completamente inactivo).

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

La forma de hacer un seguimiento del FID, generar informes sobre él y analizarlo probablemente sea algo diferente de otras métricas que ya conoces. En la siguiente sección, se explica la mejor esto.

¿Por qué considerar solo el retraso de la entrada?

Como se mencionó antes, FID solo mide el “retraso” en el procesamiento de eventos. Sí no mide la duración total del procesamiento de eventos en sí ni el tiempo que tarda el navegador para actualizar la IU después de ejecutar los controladores de eventos.

Si bien este tiempo es importante para el usuario y sí afecta la experiencia, No se incluye en esta métrica porque podría incentivar a los desarrolladores para agregar soluciones que realmente empeoren la experiencia, es decir, podrían unir la lógica del controlador de eventos en una devolución de llamada asíncrona (mediante setTimeout() o requestAnimationFrame()) para separarlo de la tarea asociada con el evento. El resultado sería una mejora en la métrica de calificación, pero una respuesta más lenta según lo percibe el usuario.

Sin embargo, aunque los FID solo miden el “retraso” de la latencia de eventos, los desarrolladores que deseen hacer un seguimiento más detallado del ciclo de vida del evento, pueden hacerlo mediante la opci�n Event Timing de la API de Google Ads. Consulta la gu�a sobre campa�as M�tricas para obtener m�s detalles.

C�mo medir el FID

FID es una m�trica que solo se puede medir en el de la aplicaci�n, ya que requiere que el usuario interact�e con la p�gina. Puedes medir el FID con las siguientes herramientas.

Herramientas de campo

• Experiencia del usuario en Chrome Informe
• PageSpeed�Insights
• Search Console (M�tricas web esenciales
• Biblioteca JavaScript web-vitals

Mide el FID en JavaScript

Para medir el FID en JavaScript, puedes usar el par�metro Event Timing de la API de Google Ads. En el siguiente ejemplo, se muestra c�mo crear un PerformanceObserver que tiene en cuenta first-input de entrada y las registra 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 como Toma el delta entre el startTime y el processingStart de la entrada y marcas de tiempo. En la mayor�a de los casos, ser� el valor del FID. Sin embargo, no todos Las entradas first-input son v�lidas para medir el 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� entradas de first-input para las p�ginas cargadas en una pesta�a en segundo plano, pero esas p�ginas deben ignorarse cuando se calcula el FID.
• La API tambi�n enviar� entradas de first-input si la p�gina se puso en segundo plano antes de 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 estaba en el en primer plano todo el tiempo).
• La API no informa entradas de first-input cuando la p�gina se restablece desde la memoria cach� atr�s/adelante, pero el FID deber�a medirse en estos casos, ya que los usuarios los experimentan como p�ginas distintas las visitas a la tienda.
• 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 de la p�gina. Esto puede Se muestran como una diferencia entre CrUX y RUM. Para medir los FID de forma correcta, debes tenerlos en cuenta. Los submarcos pueden usar la API para informar sus entradas de first-input al marco superior para la agregaci�n.

En lugar de memorizar todas estas diferencias sutiles, los desarrolladores pueden usar el Biblioteca JavaScript web-vitals en mide el FID, que controla estas diferencias por ti (cuando es posible, ten en cuenta que no se aborda el problema del iframe):

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 ver un ejemplo completo de c�mo medir el FID en JavaScript.

Analizar los datos de FID y generar informes sobre ellos

Debido a la variaci�n esperada en los valores de los FID, es fundamental que, al informar sobre FID observas la distribuci�n de los valores y te enfocas en los percentiles m�s altos.

Si bien la elecci�n de percentil de todas Los umbrales de M�tricas web esenciales son los 75, para los FID en particular se recomienda mirar los percentiles 95-99, ya que corresponden especialmente malas primeras experiencias que los usuarios tienen con tu sitio. Y tambi�n mostrarte las �reas que necesitan m�s mejoras.

Esto ocurrir� incluso si segmenta sus informes por tipo o categor�a de dispositivo. Para Por ejemplo, si ejecuta informes independientes para computadoras de escritorio y dispositivos m�viles, el valor del FID que que m�s les importa en las computadoras de escritorio deber�a ser entre el 95 y el 99% de los usuarios, y el valor del FID que m�s te interese en los dispositivos m�viles debe estar entre 95 y 99. percentil de usuarios de dispositivos m�viles.

C�mo mejorar el FID

Hay una gu�a completa para optimizar el FID que te guiar� a trav�s de las t�cnicas para 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, es necesario realizar cambios a veces, y estos pueden aparecer como mejoras o regresiones en tus informes y paneles internos.

Para ayudarte a administrar esto, todos los cambios que realices 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.