Las Core Web Vitals se han convertido en un importante estándar promovido por Google para evaluar la experiencia de página bajo tres métricas: el CLS, el LCP y el FID. El First Input Delay, FID por sus siglas en inglés, es el tiempo que tarda el usuario en hacer la primera interacción con la página y el tiempo que tarda el navegador en poder procesarlo.
Google lleva años valorando la velocidad de carga de los sitios web y la experiencia de usuario que ofrecen. Si queremos que nuestro sitio web aparezca en los primeros resultados de Google, también debemos trabajar las Core Web Vitals como un pilar más del SEO.
Debido al incremento de navegación en dispositivos móviles, Google es muy exigente con los tiempos de carga. Si los usuarios interactúan rápidamente con la página, se traduce en que les interesa y están dispuestos a dedicar tiempo para visitarla.
¿Qué es el FID?
El FID (First Input Delay) es una métrica que mide el tiempo desde que un usuario interactúa con la página hasta que esta responde. Tenemos que recordar que se considera una interacción cuando un usuario hace clic en un elemento interactivo como un botón o un enlace. Hacer scroll o zoom no se considera un input del usuario.
Conseguir aprobar esta métrica no siempre es sencillo, debemos intentar mantenerla lo más baja posible o al menos que esté comprendida entre 100 y 300 milisegundos. Un buen FID debe tardar menos de 100 milisegundos:
- Bueno: FID inferior a 100ms
- Necesita mejoras: FID comprendido entre 100 y 300 ms
- Mala: FID superior a 300 ms
La medición que hace Google del FID está basada en la ponderación de las métricas de usuarios reales utilizando el navegador Google Chrome. Al ser una métrica que depende de la interacción de un usuario, los bots no pueden simular los clics o el comportamiento real de cara a una prueba de laboratorio que queramos hacer con alguna herramienta de medición.
¿Qué causa un alto FID?
Contar con un FID lento suele estar causado porque el efecto de elementos JavaScript y/o CSS del sitio web. En la mayoría de los casos, el contenido es visible, parece que todo se ha cargado, pero el sistema no es capaz de responder a la petición del usuario porque está terminando de descargar otros elementos del DOM.
En muchas ocasiones se debe a código JavaScript muy pesado o con muchas peticiones. Pensemos en la carga de Tag Manager o Analytics, vídeos embebidos, píxeles de redes sociales, herramientas de medición como un mapa de calor,... Son peticiones que se incluyen en el head de la web y que si se cargan al principio aumentarán el tiempo del FID.
El FID se considera una métrica de primera impresión. Si un usuario llega a nuestro sitio web, pulsa sobre un enlace y la página tarda en responder estaremos causando mala impresión y puede que abandone nuestra web.
En la navegación móvil la velocidad es muy importante, depende tanto de la red como de la potencia del dispositivo y, con la cantidad de información disponible, un usuario suele tener poca paciencia para que se cargue una web. Tener un producto o servicio muy bueno no es suficiente si la página no responde con rapidez a las demandas de los usuarios. Al igual que no nos gusta esperar en un establecimiento físico a ser atendidos, debemos evitar que nuestros usuarios web tengan que esperar a que se muestre la información que ya han demandado.
¿Cómo medir el FID de una URL?
Esta métrica se puede medir a través de distintas herramientas, siendo la más recomendable el inspector de Chrome para medir Core Web Vitals, que indica el tiempo que tarda en hacer su primera interacción y el valor de esta métrica.
Debemos resaltar que se trata de una métrica de campo. Cuando hablamos de datos de campo nos referimos a que necesitamos métricas de usuarios reales porque Google no puede simular la interacción del usuario.
El índice de interactividad solo se centra en la tardanza o demora en el procesamiento de eventos. Si observamos el siguiente gráfico veremos la diferencia de peticiones del hilo principal y cómo se procesan en segundo plano.
Podemos medir el FID de un sitio web con las siguientes herramientas:
- Google Page Speed Insights.
- Chrome User Experience Report.
- Semrush.
- Con JavaScript y la API para cronometrar eventos o con la biblioteca de JavaScript web-vitals.
¿Cómo puede ayudar Semrush a mejorar el FID de un sitio web?
Semrush es una herramienta de SEO profesional que facilita el trabajo tanto a los expertos como a los principiantes. Dentro de la sección de SEO On Page y Tech SEO, podemos realizar una auditoría de la web que nos clasifica las mejoras en distintos niveles:
- Errores: será la prioridad en nuestro trabajo SEO, aquí muestra tanto errores generales como puede ser un código 404 o una página con un HTML demasiado largo.
- Advertencias: para las mejoras, aquí encontraremos, por ejemplo, los avisos de JavaScript o CSS sin comprimir que afectan al FID de la página.
El informe permite hacer el seguimiento de todas las Core Web Vitals y calcular el TBT (tiempo total de bloqueo), que es la métrica que sí se puede medir en un testeo de laboratorio y con la que podemos estimar nuestro FID.
Este informe permite configurar las urls sobre las que queremos medir. Muchas veces se mide solo la home pero tenemos que pensar en la estrategia de negocio y que la estrategia SEO la acompañe. Si tenemos una URL preparada para la conversión, podemos medir el FID para comprobar que responde rápido a la interacción de un usuario. Nuestra recomendación es priorizar los cambios en las páginas que más tráfico atraigan o en las que queramos potenciar.
Consejos para mejorar el FID de tu página
El Total Blocking Time (TBT) es el tiempo en el que la página está bloqueada por los procesos largos de carga de la página. Por tanto, cualquier optimización del TBT (Total Blocking Time) va a repercutir en una mejora del FID ya que entienden que están correlacionadas.
Para optimizar el FID es necesario mejorar la velocidad de carga de la página y lo podemos hacer de la siguiente forma:
- Reduciendo el tiempo de ejecución de JavaScript y CSS.
- Reduciendo las peticiones de la página a código de terceros.
- Minimiza el trabajo del hilo principal.
- Menos peticiones y de menor peso posibles
Cuando necesitamos mejorar la velocidad web de un sitio web, optimizar JavaScript y CSS suele dar buenos resultados. Como medida general, recordamos que es necesario eliminar lo innecesario, minificar el código todo lo que podamos y comprimirlo. Así también mejoraremos el LCP (Largest Content Paintful), otra de las Core Web Vitals.
Si nuestra web está en un CMS como Wordpress, podemos hacer uso de alguno de los numerosos plugins de optimización, que bien configurados pueden hacer gran parte del trabajo de mejora de estas métricas.
Atributos JavaScript para mejorar la velocidad de carga de página
- El atributo “preload” (precarga) debe utilizarse para cargar con prioridad los recursos clave de la web. Así estarán disponibles cuando se lance el evento de llamada.
- El atributo “defer” (aplazar) se puede utilizar para cargar scripts externos (vídeos embebidos de Youtube, por ejemplo), ya que envía una señal al navegador para que no aplace la carga de dicho script. Así se cargará en segundo plano permitiendo que el DOM esté completo en menor tiempo.
- El atributo “async” comparte con “defer” la característica de convierten a los scripts en no bloqueantes. Se utiliza para scripts completamente independientes que se descargan en paralelo al resto de la página y se ejecutan una vez finalizada su descarga.
- Prefetch para cargar recursos de manera anticipada. Se puede usar para ciertas páginas o recursos que hemos estimado que el usuario necesitará después. Por ejemplo, en un listado de entradas de blog destacadas, si se han precargado, la navegación será muy rápida.
Cuando realicemos cambios, como el resultado no lo veremos de inmediato en las herramientas de Google (los datos se toman cada 28 días), podemos hacer pruebas en el navegador Google Chrome, mediante la opción de inspector del navegador y la pestaña “Network”.
Una vez ahí, recargaremos la página y tendremos un listado de todos los elementos que se han cargado. Podemos buscar y bloquear un recurso para probar qué impacto tendría ese cambio. Desde la pestaña Lighthouse podremos hacer la prueba antes y después de bloquear los recursos. Si conseguimos el resultado que esperábamos, podemos solicitar al equipo de desarrollo que bloquee ese elemento.
Esperamos que este artículo te haya ayudado a entender una de las Core Web Vitals de tu página web y que sigas nuestros consejos para conseguir una web más rápida que satisfaga mejor las necesidades de tus usuarios.
Recuerda que con la auditoría de Semrush puedes programar una revisión periódica para poder conocer con un simple vistazo cómo está tu web, qué ha mejorado desde los últimos cambios o si ha surgido algún problema nuevo para solucionar. El informe de Velocidad y Rendimiento que ofrece Semrush muestra detalladamente los archivos HTML grandes y sugiere mejoras de velocidad que serían muy difíciles de detectar manualmente.