First Input Delay (FID) es una métrica de la experiencia del usuario que Google usa como un factor de clasificación pequeño.
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.
¿Qué es el retardo de la primera entrada?
FID es la medida del tiempo que tarda un navegador en responder a los visitantes del sitio. primera interacción 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.
Anuncio publicitario
Continuar leyendo a continuación
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 callejón sin salida en el que no hay señales de tráfico. 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 “.
Anuncio publicitario
Continuar leyendo a continuación
Cómo corregir la latencia de entrada
Dado que la causa raíz 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 se presentan esos scripts e imágenes 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 típica pausa e inicio de 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, abreviatura de “subproceso de ejecución”. Esto significa una secuencia de acción individual (en este caso, las muchas tareas individuales realizadas para renderizar una página web).
En un navegador, hay un hilo llamado Main Thread y 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 y cuándo 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 Core Web Vitals y especialmente con First Input Delay, encontrará que hay un código sobre el que no puede hacer mucho. Sin embargo, es probable que este también sea el caso de sus competidores.
Anuncio publicitario
Continuar leyendo a continuación
Por ejemplo, si su negocio depende de Google AdSense (un gran script de bloqueo de procesamiento), el problema será el mismo para su competidor. Soluciones como la carga diferida con Google Ad Manager pueden ayudar.
En algunos casos, puede ser suficiente hacer lo mejor que pueda, porque es posible que sus competidores tampoco lo hagan mejor.
En esos casos, es mejor llevar sus ganancias donde pueda encontrarlas. 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 JavaScript esté allí para asegurarse de que se ingrese tanto el nombre como el apellido.
Cuando se presiona un botón, JavaScript puede estar ahí 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.
Anuncio publicitario
Continuar leyendo a continuación
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 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.
Esto se debe a que 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!
Anuncio publicitario
Continuar leyendo a continuación
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 cuando aprendes una habilidad; esa habilidad se convierte en un atributo de quién eres.
En este caso, los atributos Defer y Async le dicen al navegador que no bloquee el análisis de HTML durante la descarga. Estos atributos le dicen al navegador que mantenga el hilo principal mientras se descarga JavaScript.
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 (o diferir).
Esto se llama descarga asincrónica, donde se descarga independientemente del hilo principal y en paralelo con él.
Anuncio publicitario
Continuar leyendo a continuación
El atributo async es útil para archivos JavaScript de terceros, como publicidad y uso compartido en redes sociales, archivos en los que el orden de ejecución no importa.
Atributo diferido
Archivos JavaScript con el “aplazar”También se descargará de forma asincrónica.
Pero el archivo JavaScript diferido no se ejecutará hasta que se descargue y 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 los 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.
Esta 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.
Anuncio publicitario
Continuar leyendo a continuación
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 malos momentos (cuando el hilo principal está ocupado durante un período prolongado de tiempo), y las primeras interacciones de algunos usuarios serán en buenos momentos (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.
Anuncio publicitario
Continuar leyendo a continuación
Pero eso 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.
Anuncio publicitario
Continuar leyendo a continuación
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 la forma estándar de empaquetar CSS.
Desde 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.
Anuncio publicitario
Continuar leyendo a continuación
Ha llegado el momento de corregir el retardo de la primera entrada
En el futuro, podemos esperar que cada vez más desarrolladores de software responsables del CMS, los temas y los complementos pasen a las 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 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
