Retardo de la primera entrada: una explicación simple

First Input Delay (FID) es una métrica de la experiencia del usuario que Google introdujo y que pronto utilizará como un pequeño factor de clasificación. Este artículo ofrece una descripción general fácil de entender de FID para ayudar a entender el tema.

El retraso de la primera entrada es más que intentar complacer a Google. Las mejoras en el rendimiento del sitio generalmente conducen a un aumento de las ventas, los ingresos publicitarios y los clientes potenciales.

Definición de retardo de la primera entrada

FID es la medida del tiempo que tarda un navegador en responder a la primera interacción de un visitante del sitio con el sitio mientras se carga el sitio. Esto a veces se denomina latencia de entrada.

Una interacción puede ser presionar un botón, un enlace o presionar una tecla y la respuesta dada como respuesta. Las áreas de entrada de texto, los menús desplegables y las casillas de verificación son otros tipos de puntos de interacción que medirá el FID.

El desplazamiento o el zoom no cuentan como interacciones porque no se espera una respuesta del sitio en sí.

El objetivo de FID es medir la capacidad de respuesta de un sitio mientras se carga.

La causa del retraso de la primera entrada

El retraso de la primera entrada generalmente es causado por imágenes y scripts que se descargan de manera no ordenada. Esta codificación desordenada hace que la descarga de la página web se pause excesivamente, luego se inicie y luego se pause. Esto provoca un comportamiento que no responde a los visitantes del sitio que intentan interactuar con la página web.

Es como un atasco provocado por un libre para todos donde no hay señales de tráfico, lo que provoca accidentes y ralentizaciones. Arreglarlo se trata de poner orden en el tráfico.

Google describe la causa de la latencia de entrada de esta manera:

“En general, el retraso de entrada (también conocido como latencia de entrada) ocurre porque el hilo principal del navegador 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 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 ".

Cómo corregir la latencia de entrada

Dado que la causa principal del retraso de la primera entrada es la descarga desorganizada de scripts e imágenes, la forma de solucionar el problema es poner orden cuidadosamente en cómo esos scripts e imágenes se presentan al navegador para su descarga.

Resolver el problema de FID generalmente consiste en usar atributos HTML para controlar cómo se descargan los scripts, optimizar las imágenes (el HTML y las imágenes) y omitir cuidadosamente los scripts innecesarios. El objetivo es optimizar lo que se descarga para eliminar la pausa típica y comenzar la descarga de páginas web desorganizadas.

Por qué los navegadores no responden

Los navegadores son software que completan tareas para mostrar una página web. Las tareas consisten en descargar código, imágenes, fuentes, información de estilo y scripts y luego ejecutar (ejecutar) los scripts y construir la página web de acuerdo con las instrucciones HTML.

Este proceso se llama renderizado. La palabra render significa hacer y eso es lo que hace un navegador al ensamblar el código y las imágenes para renderizar una página web.

Las tareas de renderización individuales se denominan subprocesos. La palabra hilo es la abreviatura de "hilo de ejecución", que significa una secuencia individual de acción (en este caso, las muchas tareas individuales que se realizan para representar una página web).

En un navegador hay un hilo que se llama hilo principal. El hilo principal es responsable de crear (representar) la página web que ve un visitante del sitio.

El hilo principal se puede visualizar como una autopista en la que los coches simbolizan las imágenes y los scripts que se descargan y ejecutan cuando una persona visita un sitio web.

Algunos códigos son largos y lentos. Esto hace que las otras tareas se detengan y esperen a que el código grande y lento se salga de la autopista (termine de descargarse y ejecutarse).

El objetivo es codificar la página web de una manera que optimice qué código se descarga primero, cuando se ejecuta el código, de manera ordenada para que la página web se descargue de la manera más rápida posible.

No pierda el sueño por el código de terceros

Cuando se trata de web vitals centrales y especialmente con First Input Delay, hay cierto código sobre el que es poco lo que se puede hacer. Sin embargo, es probable que este también sea el caso de sus competidores.

Por ejemplo, si su negocio depende de Google AdSense (un gran script de bloqueo de renderizado), el problema será el mismo para su competidor.

En muchos casos, puede ser suficiente hacer lo mejor que pueda porque es posible que sus competidores tampoco puedan hacerlo mejor.

Entonces, en esos casos, es mejor llevar sus ganancias donde pueda encontrarlas y no se preocupe por las pérdidas donde no puede hacer un cambio.

Impacto de JavaScript en el retraso de la primera entrada

JavaScript es como un pequeño motor que hace que sucedan cosas. Cuando se ingresa un nombre en un formulario, es posible que haya un JavaScript para asegurarse de que se ingrese tanto el nombre como el apellido. Cuando se presiona un botón, un JavaScript puede estar allí para decirle al navegador que genere un mensaje de agradecimiento en una ventana emergente.

El problema con JavaScript es que no solo tiene que descargarse, sino que también tiene que ejecutarse (ejecutar). Entonces, esas son dos cosas que contribuyen a la latencia de entrada.

Si un archivo JavaScript grande se encuentra cerca de la parte superior de la página, ese archivo bloqueará el procesamiento del resto de la página debajo de él (se volverá visible e interactivo) hasta que el script termine de descargarse y ejecutarse.

A esto se le llama bloquear la página.

La solución obvia es reubicar este tipo de scripts desde la parte superior de la página y colocarlos en la parte inferior de la página para que no interfieran con todos los demás elementos de la página que están esperando ser renderizados.

Pero esto puede ser un problema si, por ejemplo, se coloca al final de una página web muy larga. La razón es porque una vez que se carga la página grande y el usuario está listo para interactuar con ella, el navegador aún indicará que se está descargando (porque el archivo JavaScript grande se está retrasando al final). La página puede descargarse más rápido, pero luego se detiene mientras espera que se ejecute JavaScript.

¡Hay una solución para eso!

Atributos diferidos y asíncronos

Los atributos Defer y Async HTML son como señales de tráfico que controlan el inicio y la detención de cómo se descarga y ejecuta JavaScript.

Un atributo HTML es algo que transforma un elemento HTML, algo así como extender el propósito o comportamiento del elemento.

Es como si aprendes una habilidad, esa habilidad se convierte en un atributo de quién eres.

En este caso, los atributos Defer y Async cambian la forma en que se comporta un archivo JavaScript.

Uno de los cambios importantes es que le dicen al navegador que no se detenga para JavaScript. Estos atributos le dicen al navegador que mantenga el hilo principal en funcionamiento.

Los archivos JavaScript se descargarán y procesarán independientemente del hilo principal, lo que permitirá que el navegador represente la página web más rápido.

Atributo asincrónico

Los archivos JavaScript con el atributo Async se descargarán y luego se ejecutarán tan pronto como se descarguen. Cuando comienza a ejecutarse es el punto en el que el archivo JavaScript bloquea el hilo principal.

Normalmente, el archivo bloquearía el hilo principal cuando comienza a descargarse. Pero no con el atributo async.

Esto se llama descarga asincrónica, donde se descarga independientemente del hilo principal y en paralelo con él.

El atributo async es útil para archivos JavaScript de terceros como publicidad y uso compartido en redes sociales, archivos en los que no importa en qué orden se ejecuten.

Atributo diferido

Archivos JavaScript con el "aplazar”El atributo también se descargará de forma asincrónica.

Pero el archivo JavaScript diferido no se ejecutará hasta que se descargue y se procese toda la página. Los scripts diferidos también se ejecutan en el orden en que se encuentran en una página web.

Los scripts con el atributo defer son útiles para archivos JavaScript que dependen de los elementos de la página que se cargan y cuándo importa el orden en que se ejecutan.

En general, utilice el atributo defer para scripts que no sean esenciales para la representación de la página en sí.

La latencia de entrada es diferente para todos los usuarios

Es importante tener en cuenta que las puntuaciones de retraso de la primera entrada son variables e inconsistentes. Las puntuaciones varían de un visitante a otro.

La variación en las puntuaciones es inevitable porque la puntuación depende de las interacciones que son particulares de la persona que visita un sitio.

Algunos visitantes pueden distraerse y no interactuar hasta un momento en el que todos los activos están cargados y listos para interactuar con ellos.

Así lo describe Google:

“No todos los usuarios interactuarán con su sitio cada vez que lo visiten. Y no todas las interacciones son relevantes para FID ...

Además, las primeras interacciones de algunos usuarios serán en momentos malos (cuando el hilo principal está ocupado durante un período de tiempo prolongado), y las primeras interacciones de algunos usuarios serán en momentos buenos (cuando el hilo principal está completamente inactivo).

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

Por qué la mayoría de los sitios fallan en FID

Desafortunadamente, muchos sistemas de administración de contenido, temas y complementos no se crearon para cumplir con esta métrica relativamente nueva.
Esta es la razón por la que tantos editores están consternados al descubrir que sus sitios no pasan la prueba de Demora de la primera entrada.

Pero eso es algo que está cambiando a medida que la comunidad de desarrollo de software web responde a las demandas de diferentes estándares de codificación de la comunidad editorial.

Y no es que los desarrolladores de software que crean sistemas de gestión de contenido tengan la culpa de producir productos que no se comparan con estas métricas.

Por ejemplo, WordPress abordó una deficiencia en el editor del sitio web de Gutenberg que estaba causando que obtuviera una puntuación peor de la que podría.

Gutenberg es una forma visual de construir sitios usando la interfaz o metáfora de bloques. Hay un bloque de widgets, un bloque de formulario de contacto y un bloque de pie de página, etc.

Entonces, el proceso de creación de una página web es más visual y se realiza a través de la metáfora de los bloques de construcción, literalmente construyendo una página con diferentes bloques.

Hay diferentes tipos de bloques que se ven y se comportan de diferentes maneras. Cada bloque individual tiene un código de estilo (CSS) correspondiente, y gran parte de él es específico y único para ese bloque individual.

La forma estándar de codificar estos estilos es crear una hoja de estilo que contenga los estilos que son únicos para cada bloque. Tiene sentido hacerlo de esta manera porque tiene una ubicación central donde existe todo el código específico de los bloques.

El resultado es que en una página que podría constar de (digamos) veinte bloques, WordPress cargaría los estilos para esos bloques más todos los demás bloques que no se están utilizando.

Antes de Core Web Vitals (CWV), se consideraba como la forma estándar de empaquetar CSS.

Después de la introducción de Core Web Vitals, esa práctica se considera un exceso de código.

Esto no pretende ser un desaire contra los desarrolladores de WordPress. Hicieron un trabajo fantástico.

Esto es solo un reflejo de la rapidez con que los estándares cambiantes pueden llegar a un cuello de botella en la etapa de desarrollo del software antes de integrarse en el ecosistema de codificación.

Pasamos por lo mismo con la transición al diseño web móvil primero.

Gutenberg 10.1 Rendimiento mejorado

WordPress Gutenberg 10.1 introdujo una forma mejorada de cargar los estilos cargando solo los estilos que se necesitaban y no cargando los estilos de bloque que no se iban a utilizar.

Esta es una gran victoria para WordPress, los editores que confían en WordPress y, por supuesto, los usuarios que visitan sitios creados con WordPress.

Ha llegado el momento de corregir el retardo de la primera entrada

Creo que, en el futuro, cada vez más desarrolladores de software responsables del CMS, los temas y los complementos pasarán a prácticas de codificación compatibles con First Input Delay.

Pero hasta que eso suceda, la responsabilidad recae en el editor para tomar las medidas necesarias para mejorar el retardo de la primera entrada. Entenderlo es el primer paso.

Citas

Informe de experiencia del usuario de Chrome

PageSpeed ​​Insights

Faro de herramientas de desarrollo de Chrome

Google Search Console (informe de Core Web Vitals)

Optimizar el retardo de la primera entrada

Retardo de la primera entrada

Métricas de rendimiento centradas en el usuario

Secuencia de comandos de GitHub para medir los valores fundamentales de la Web