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 mide la carga del elemento mas grande cargado en la parte visible de la web, pero también le afectan los bloqueos.
- 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.
Por si te interesa, aquí te dejo un post donde describo el servidor perfecto para un WordPress MUY rápido: https://alvaro.click/hosting-servidor-perfecto-wordpress/
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.
Estos dos artículos que he publicado en este blog posiblemente te puedan ayudar:
- Optimizacion de Javascript y CSS en WordPress: https://alvarofontela.com/optimizar-carga-javascript-css-wordpress/
- Optimizacion de la carga de Google Fonts: https://alvarofontela.com/optimizar-la-carga-de-google-fonts-wordpress/
¿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 (https://alvarofontela.com/precarga-recursos-resource-hints-wpo/), 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.
Por último, si quieres algo más simple, puedes ver mi post sobre cómo optimizar WordPress aquí: https://alvarofontela.com/wpo-optimizar-wordpress/
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
6 Responses
Hola Álvaro
Coincido con mucho de lo que comentas. Es muy difícil tener todo cuando se quiere un diseño específico, hay unas lógicas de negocio concretas, los de analítica tienen unas necesidades o los de publicidad necesitan cargar una serie de píxeles
Al final optimizar es hacer las cosas de la mejor manera posible, teniendo en cuenta que todo lo que quieras hacer conlleva una consecuencia. Por eso en el trabajo hablamos de “performance budgets”, para que todas las parte implicadas en el diseño y desarrollo de una web se responsabilicen de su parte.
Si un diseño es muy recargado, tiene muchos efectos, o planta un slider fullHD arriba del todo… hay que ser consecuente que esas cosas pesan y ralentizan… podremos optimizar las imágenes, los JS o los CSS, servirlos desde una CDN, prelodearlo, etc… pero no más allá
Efectivamente Pablo, el problema es que las circunstancias son las que son para cada proyecto y las necesidades también, entonces…en ciertos casos poco podemos hacer salvo buscar alternativas a ciertos pixeles o servicios (si los hay claro…).
Un saludo.
Me fiaría más de Gtmetrix o google speed. Los slides si se configuran correctamente no tienen por que afectar a las métricas y a la optimización de carga, siempre puedes añadirle un background de color y lazy a las imágenes para que se salte el LCF con esto mejoraría ,FCP, FID y el CLS, En cuanto al uso de wp rocket me parece un engaño publicitario para vender a usuarios inexpertos, si hace que te carge rápido pero no te mejora las métricas a no ser que seas un usuario avanzado, pero si es el caso hay muchas opciones gratuitas que hacen mejor trabajo que rocket. Si realmente quieres mejorar esos puntos, tienes que fiarte más del waterfall y mirar que es lo que está pasando, para precargar o exluirlos de la cadena de solicitud crítica recursos como los woff2, fuentes de iconos o ciertos scripts. Asincronar cualquier script externo y hacerle prefech y preconect (tagmanager, analytics, hotjar, facebook, ect…. incluso algún script o css que pueda funcionar solo ).
Pre party Browser hints plugin es una buena opción para hacer estas cosas exludidas junto a cualquier plugin de optimización de js/css, caché y assets condicionales.
https://es.wordpress.org/plugins/pre-party-browser-hints/
Hola Adrian, de todo lo que hablas yo dejo claro mi punto de vista en los siguientes post de este blog:
– Resource Hints: https://alvarofontela.com/precarga-recursos-resource-hints-wpo/
– Server Timing (Waterfall): https://alvarofontela.com/server-timing-analizar-peticiones-https-http-wpo/
– Tiempos VS Puntuaciones: https://alvarofontela.com/wpo-teoria-vs-practica-metricas-puntuaciones-tiempos/
De todas formas, este post es antiguo, el actualizado sobre el algoritmo actual de Google LightHouse es este: https://alvarofontela.com/core-web-vitals-google-search-console-lcp-cls-fid/
Yo creo que Google se ha flipado mucho con esto… ¿Cuántas web realmente cargan en menos de 1s en el móvil? Poquísimas. Y como dices, en cuanto quieres añadir imágenes, analíticas, pixel, o similares, y ya si decimos Ad Sense ni te cuento… Pero al final es lo que hace que la web se vea bien, y que la puedas gestionar, y monetizarla! Así que, mira, habrá que sacrificar velocidad por diseño y funcionalidad. Si se ponen más duros con esto pues… Seguiremos como ahora, haciendo lo que se pueda y pagando por conseguir visibilidad y tráfico.
Hola Taisa, precisamente esto lo comento (actualizado) en este video en mi canal de Youtube: https://www.youtube.com/watch?v=JQQDYZ5sSe0