Aquí vuelvo a estar yo con otro artículo técnico sobre WPO y rendimiento web pero, al mismo tiempo, voy a intentar solventar las dudas de muchos SEOs que han visto aparecer nuevos términos en Google Search Console junto a una nueva herramienta de velocidad.
Los términos de los que voy a hablar en este post, sobre todo el FCP y FID, no son nuevos. No aparecieron por primera vez en Google Search Console (nuevo), sino que vienen de Google PageSpeed Insights y de Google LightHouse, las dos herramientas de test de WPO de Google.
Antes de nada, vamos a ilustrar un poco a qué me estoy refiriendo.
En Google Search Console, en la sección de velocidad, nos encontraremos con esta interfaz de herramienta:
Y en Google PageSpeed Insights, esta otra:
En ambos casos he rodeado con un cuadro verde la zona que me interesa que observes, ya que es el dato principal.
Los dos datos que puedes ver, el FCP y FID (que ahora veremos qué son), se miden por separado tanto para desktop como para dispositivos móviles. La principal razón de esto es la que comento siempre: el aumento de cuota de mercado de los dispositivos móviles puso mas alto el “listón” del WPO, haciendo que sea mucho más exigente y difícil.
Para que puedas ver algo más de información sobre esto, a continuación te dejo un enlace oficial de Google donde puedes ver la importancia del WPO desde el punto de vista de la experiencia de usuario: https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/
Antes de comenzar, te dejo los siguientes enlaces que pueden llegar a ser de interés:
Anuncio de Google sobre la nueva herramienta en el nuevo Google Search Console: https://support.google.com/webmasters/answer/9205520?hl=en
La herramienta Google LightHouse: https://developers.google.com/web/tools/lighthouse
La herramienta Google PageSpeed Insights: https://developers.google.com/speed/pagespeed/insights/?hl=es
También quiero aclarar que todo esto, Google lo orienta al UX (Experiencia de Usuario). Desde ese punto de vista lo tenemos que entender nosotros también para saber qué nos está pidiendo Google cuando nos marca el “error” en Google Search Console o en Google PageSpeed.
Vamos a empezar por definir el FCP y el FID:
FCP: Son las siglas de First Contentful Paint, es decir, el periodo de tiempo que existe entre que se solicita la página (HTML) hasta que se carga la primera parte del contenido real.
FID: Son las siglas de First Input Delay, es decir, el tiempo que tarda en reaccionar la web desde que el usuario pulsa un enlace o un botón hasta que existe una respuesta.
¿De dónde salen estos datos? Pues de Google Chrome. Son datos que recogen los navegadores Google Chrome de los usuarios de forma anónima y que contribuyen a hacer una media del tiempo que tarda en cargarse la interfaz web para la mayoría de los usuarios.
Puedes encontrar más información acerca del Chrome User Experience Report en esta URL oficial: https://developers.google.com/web/tools/chrome-user-experience-report/
También quiero añadir que el FCP y el FID no son los únicos datos que recoge Google y que forman parte del Google User Experience Report:
DOMContentLoaded: Se mide todo lo que carga cuando la web ha terminado de cargar, es decir, cosas como el LazyLoad o la carga asíncrona de Javascript.
Onload: Eventos que se activan cuando la web ha terminado de cargar.
Largest Contentful Paint (LCP): Se trata de una métrica que con el tiempo va a ser importante, ya que mide un punto aproximado en el timeline de carga donde la web aún no ha terminado de cargar, pero el visitante ya debería poder verla como si estuviera completamente cargada.
Cumulative Layout Shift (CLS): Teóricamente es una métrica que ayuda a mejorar la estabilidad visual, pero aún no he conseguido encontrarle utilidad.
Time to First Byte: Esto casi no necesita presentación. El TTFB es el tiempo que tarda el navegador del visitante en recibir el primer byte de contenido desde que realiza la petición.
En un futuro relativamente cercano, creo que las métricas LCP y el DOMContentLoaded van a cobrar especial importancia debido a que las webs son cada vez más complejas.
Pero en este post quiero hablar del FCP y FID (y cómo mejorarlos), siempre con la vista puesta en los datos ofrecidos por el nuevo Google Search Console.
Volvemos a la ventana de Google Search Console, a la sección de velocidad, con otra captura de ejemplo:
A continuación, te dejo una tabla oficial que está disponible en una de las URL expuestas antes y que te ayudará a ver qué “límites” tienes que alcanzar para conseguir mejorar el “color” y la puntuación del FCP y FID en Google Search Console y también en Google PageSpeed Insights.
¿Cómo conseguimos llegar a estos tiempos?
Pues aquí es donde viene el problema, ya que la mayoría de themes actuales no están preparados para esto. Pero hay algo más: en muchos casos, sobrecargamos los sitios web con demasiados códigos de tracking, herramientas con peticiones externas y píxeles de conversión, provocando un FCP lento.
Una de las cosas que nos afecta tanto al FID como al FCP es el firstbyte o TTFB, ya que para tener un tiempo de carga aceptable el tiempo de respuesta debe ser perfecto.
¿Qué se considera un tiempo de firstbyte perfecto? En mis ponencias, siempre que hablo de esto, suelo decir que tiempos inferiores a 0,1 segundo o 0,2 segundos.
Y siempre utilizo Pingdom Tools para medirlo, ya que es la herramienta de la que más me fío.
Las caches de página como WP Rocket en WordPress o Varnish a nivel servidor pueden ayudarte con el firstbyte. Si tienes la certeza de que funciona correctamente el cache de página, pero aun así tienes un tiempo de firstbyte lento, puede ser un problema de hosting o servidor.
Una vez que tenemos zanjado el tema del firstbyte o TTFB, tanto para el FCP como para el FID, debemos tener en cuenta lo que se carga y algunas cosas que el propio Google PageSpeed Insights lleva tiempo diciéndonos una y otra vez.
En los sitios web actuales se carga cada vez más CSS y JS. Eso hace que las webs sean cada vez más difíciles de interpretar para los navegadores de los visitantes, pero también para el bot de Google.
Hace unas semanas escribí y publiqué un post en el que trataba los problemas que ocurren al sobrecargar un sitio web con mucho Javascript, ya que eso puede llevar incluso a bloqueos en el navegador web del visitante en dispositivos con poca potencia.
Puedes encontrar el articulo aquí: https://alvarofontela.com/impacto-del-javascript-en-wpo-actual-benchmark/
Pues bien, para mejorar el FCP y el FID, en gran parte tenemos que solucionar esas pequeñas “cositas” que nos lleva recordando Google PageSpeed Insights desde hace años. Por ejemplo, “Eliminar el CSS que bloquea la visualización”, aunque ahora se llame de otra forma.
¿Cuál es el problema que nos vamos a encontrar?
Que los milagros no existen y que normalmente un sitio web creado con un theme multipurpose sobrecargado de los que podemos comprar en ThemeForest, NO vamos a poder optimizarlo sin destrozar la web.
Algo obvio es que, cuanto más pequeños sean los archivos HTML y recursos (CSS y JS), mejor le irá al WPO de la web. Esto puede ser algo lógico, ya que en la optimización de JS y CSS se aplica minificación para reducir el tamaño de los archivos. El tema es que el HTML también se puede minificar, pero si conseguimos rebajar el tamaño completo del HTML para hacer que pese menos o eliminamos elementos innecesarios de la página para que no se tengan que interpretar en el navegador web del visitante, conseguiremos mejores resultados en el FCP al bajar el tiempo de renderización DOM.
En cuanto a la minificacion, la optimización de HTML, CSS y JS en WP Rocket funciona muy bien, pero si queremos probar algo diferente, también la optimización de código de CloudFlare CDN funciona bastante bien.
Por otro lado, vamos a encontrarnos con una cosa que expliqué al principio del post: un sitio web que cargue rápido y que consiga buenas puntuaciones en Google PageSpeed Insights, normalmente lo “jodemos” al añadir un montón de peticiones externas como códigos de seguimiento (Google Analytics), píxeles de conversión (Facebook Ads y Google Ads), botones sociales, servicios de chat o CRM externos, etc. Todos estos JS no podemos cargarlos en asíncrono, ya que tendremos problemas y no funcionarán bien.
Personalmente, todavía no he visto una web que, en producción, con todos los códigos de seguimiento y píxeles activos, tenga una puntuación perfecta en la parte de FCP.
Un poco unido a la afirmación anterior, quiero aclarar que la carga asíncrona de JS y CSS al igual que la minificación, pueden ayudar. También la priorización en la carga de elementos JS y CSS mediante resource hints, pero vuelvo a recalcar que los milagros no existen.
Todo lo que cargue Javascript en la parte de arriba de la página y sin ser asíncrona daña el WPO y con esto te aparecerá rojo el FCP y el FID. Cosas como un slider (que de por sí ya están en desuso) o mega menús muy “bestias” pueden ser un lastre importante para una web que cargue rápido.
La finalidad de todo lo que te propongo es agilizar al máximo la carga de Javascript desde el punto de vista del usuario.
Hay otro tema que he dejado para el final porque, sinceramente, me parece una idea de bombero. En la documentación oficial de Google también se menciona que cargando los elementos inline también conseguimos un mejor FCP y FID. Sin embargo, como he comentado, para mí cargar inline el CSS, el JS e incluso algunas imágenes con base64 me parece de locos.
Como siempre en estos casos, algo que puede ser bueno para la experiencia de usuario desde el punto de vista de la herramienta de velocidad de Google Search Console y desde el punto de vista de Google PageSpeed Insights o Google LightHouse, puede ser una “putada” para otras cosas. La tecnología avanza muy rápidamente y cosas como el combinado de CSS y JS que antes se recomendaba, ahora con HTTP/2 ya no es recomendable por la forma de funcionar que tiene la actualización del protocolo HTTP.
¿La conclusión? Pues muy simple: webs más ligeras, con menos peticiones externas y todo simplificado.
Contenidos cortos y con pocos elementos, poco Javascript, todo cargado de forma asíncrona y de la forma más organizada posible.
¿Si no cumplimos esto al 100% vamos a dejar de posicionar? Pues la verdad es que no todo es blanco o negro, existen puntos intermedios. Google ya ha dicho en varias ocasiones (primero para móviles y después para desktop) que la velocidad de carga orientada a la experiencia de usuario era un factor de posicionamiento que podía llegar a penalizar y ser el factor decisivo en keywords muy competidas.
Y también quiero recordar la herramienta antigua, la del antiguo Google Search Console que, aunque daba menos datos, a mí me encantaban sus gráficas de tiempo de respuesta y me encantaba hacer WPO con ellas para mejorar el crawl budget.
En muchos casos, con una mejora en el TTFB o con una optimización de la carga de Javascript, se podían conseguir mejoras radicales como la que puedes ver en la imagen anterior.