Hace unos meses hablamos de ciertas Métricas de Google tque se muestran en la Search Console. El motivo de escribir otro post sobre este tema es que Google ha vuelto a cambiar esto, dando prioridad a otras métricas.
Curiosamente, en ese estudio anterior pensamos que el FCP y el FID no eran las métricas que debían tener más peso, ya que había otras que debían ser más importantes en la práctica, como el CLS.
Pues bien, en mayo de 2020, Google actualizó Google Search Console y Google PageSpeed/Google LightHousecon un cambio importante: Core Web Vitals.
Con Core Web Vitals no se añaden ni eliminan métricas, sino que simplemente se cambia el peso asignado en las puntuaciones y, por tanto, se realizan determinados cambios en Google Search Console (donde aparece una nueva pestaña) y Google LightHouse.
Aunque era un cambio lógico, personalmente no esperaba que se produjera tan rápido, ya que en cuestiones de Optimización de páginas web no podemos juntar Google y "lógica" en la misma frase porque no van para nada de la mano.
Con la aparición de la pestaña "Core Web Vitals" o "Main Web Metrics" en Google Search Console, muchos weberos se han vuelto locos porque, de repente y de un día para otro, sus puntuaciones han cambiado y esto es precisamente porque las diferentes métricas han variado de peso.
En el post anterior sobre FCP y FID mostramos esta tabla, ya que FCP y FID eran las métricas más importantes en ese momento:
Pero ahora, cuando cambiamos las métricas más importantes o más pesadas, también tenemos que cambiar la tabla:
Aunque si quieres verlo de forma más gráfica, esta es la imagen oficial:
Todas estas tablas son oficiales, extraídas del Google webmaster support website, y te servirán de referencia para ver los valores que tienes que alcanzar en cada métrica si quieres obtener una buena puntuación en Google PageSpeed Insights.
Ahora que nos centramos en sólo 3 métricas (aunque las demás siguen ahí, pero con menos protagonismo o integradas en otras), vamos a intentar explicarlas y también qué debemos hacer para mejorarlas.
El peso o importancia de las distintas métricas en la puntuación de Google PageSpeed o Google LightHouse en la versión 6 de LightHouse es el siguiente:
- LCP: 20% del total.
- TBT: 20% del total.
- FCP: 15% del total.
- SI (Speed Index): 15% del total.
- TTI: 15% del total.
- CLS: 15% del total.
Tendremos todas estas métricas en Google PageSpeed, aunque la mayoría de ellas no se muestran en Core Web Vitals en Google Search Console.
Si deseas experimentar con la importancia de las puntuaciones, puede utilizar esta herramienta oficial de Google
Optimizar y mejorar LCP
Empecemos por la más compleja y veamos cómo podemos mejorar esta métrica.
El LCP (Protocolo de control de enlace) es la métrica que mencioné en febrero de 2020 explicando que tenía mucho más sentido como métrica principal que el FCP. Como dije más arriba, curiosamente unos meses después Core Web Vitals le dio protagonismo.
Lo que mide exactamente el LCP es el tiempo que tarda en renderizar los elementos con contenido desde que el usuario hace la petición a la página. Es una métrica MUY lógica y, con el abuso actual de Javascript por parte de las webs, es normal tenerla controlada.
Para ver la importancia actual de la LCP como métrica, es la que tiene más peso.
¿Qué puede causar una mala puntuación en LCP?
- Time to firstbyte o TTFB:Esto ocurre porque el sitio web no tiene un sistema de caché de páginas o porque el servidor web tiene problemas y provoca retrasos importantes. La solución es fácil: implantar la caché y solucionar los problemas del servidor si los tiene.
- Bloqueo de JavaScript y CSS durante la carga: Esto es bastante común. Ocurre cuando se cargan scripts pesados sin carga asíncrona. Estos scripts bloquean la línea de tiempo de carga del sitio web mientras son interpretados. Normalmente, podemos solucionarlo con una carga asíncrona eficaz o eliminando scripts y CSS.
- Lentitud en el servicio de recursos estáticos: Los recursos estáticos como imágenes, CSS, JS, PDF y todo lo necesario para ver la web deben cargarse con la suficiente rapidez. Podemos optimizar la carga de los recursos estáticos con un servicio CDN y reducir su peso con técnicas como la miniaturización, si es posible.
En resumen, algunas de las técnicas que nos pueden ayudar a tener un buen LCP son la implementación de un CDN, la minimización, la caché de página y la carga asíncrona tanto de Javascript como de CSS.
Sobre LCP
Como he dicho, esta es una "buena" métrica aplicable en la práctica a la optimización de la mayoría de los sitios web.
El hecho de medir la velocidad de carga junto con el renderizado la convierte en una métrica aplicable a la práctica.
El problema es que, en muchos casos, es una métrica muy estricta y tiene un estándar demasiado alto como para aplicarlo en la práctica. Como consecuencia, en muchos casos, al implementar ciertos scripts de medición externos como Hotjar o alguna herramienta de marketing como Hubspot, automáticamente tendremos una mala puntuación en LCP y también la consecuente bajada de puntos en Google PageSpeed.
Para mí, las métricas son buenas y precisas. Sin embargo, como ocurre con la mayoría de las cosas que hace Google, le falta bastante transparencia. Soy consciente y he demostrado que Javascript puede bloquear la CPU de un dispositivo móvil actual de gama baja e incluso causar problemas a los smartphones de gama alta, que es precisamente lo que nos permite evitar la LCP. Sin embargo, creo que debería reducirse un poco para poder aplicar la teoría a la práctica.
En resumen, mi opinión personal es que esta métrica es buena, el enfoque es muy bueno, pero el baremo es erróneo y poco transparente. Por esta razón, en muchos casos hay que dar prioridad a las decisiones de marketing o de negocio en lugar de ganar unos puntos en PageSpeed a costa del LCP.
Optimizar y mejorar el CLS
Ahora pasamos a la segunda "nueva" métrica, una métrica que puede resultar confusa por lo que mide y porque, en algunos casos, si aliviamos un poco el LCP podemos acabar perjudicando al CLS (Cumulative Layout Shift). No es exactamente una métrica antagónica de la CLS, pero algunas cosas pueden solaparse.
El CLS mide exactamente cuánto ha cambiado el diseño de la página mientras se cargan e interpretan los elementos.
Por poner un ejemplo práctico, cuando no especificamos un tamaño en las imágenes y éstas se cargan a medida que se descargan en el navegador del visitante, es normal que, al no tener un tamaño asignado, las imágenes se desplacen por la pantalla a medida que se cargan una tras otra. Esto es penalizado por CLS.
Para que veas un ejemplo práctico directamente con una imagen, he encontrado esto:
Idealmente, la métrica debería ser 0 (perfecta), pero como requiere ciertos elementos es posible que no podamos mantenerla en 0.
¿Qué puede causar una mala puntuación en el CLS?
- Imágenes sin el tamaño especificado en el código: Si no especificamos en el HTML las dimensiones de las imágenes utilizando las etiquetas y atributos correspondientes, veremos que el CLS ha sido penalizado. Esto ya lo hacen la mayoría de los Pagebuilders y temas actuales.
- Anuncios e iframes sin el tamaño especificado: Esto puede ocurrir con muchas redes de anunciantes y muchos sistemas de publicidad, incluso con Google Adsense. Aquí nos enfrentamos a una buena decisión de negocios: "ganar dinero" frente a la optimización de la página web.
- Contenido inyectado dinámicamente: Si inyectamos o modificamos contenido de forma dinámica mientras se carga la web, también veremos penalizado el CLS. En webs complejas este es uno de los principales problemas que nos encontraremos, especialmente en ecommerce donde hay mucho AJAX.
- Carga de fuentes sin estilos: Al optimizar la carga de fuentes desde local o Google Fonts, en algunos casos se pueden cargar inicialmente sin estilos para posteriormente cargar los estilos y el formato. Esto da problemas en el CLS, aunque para la optimización de la página Web es una buena técnica.
- Cualquier animación o carga dinámica sin recarga: La mayoría de las animaciones o cargas dinámicas sin recarga de la página pueden penalizar el CLS, en mayor o menor medida, en función del impacto que tengan sobre el contenido total.
Como dije al principio de la sección, el CLS es una métrica complicada de entender por su naturaleza. No es una métrica de Optimización de Página Web, sino que encaja mejor dentro de una métrica puramente de UX o experiencia de usuario. Por esta razón, es difícil establecer técnicas de Optimización de Páginas Web para mejorar el CLS y personalmente no recomiendo prescindir de ciertos elementos para tener 0 CLS.
Sobre el CLS
Como he dicho antes, CLS es más una métrica de UX y experiencia de usuario que de optimización de páginas web. CLS no tiene nada que ver con la optimización de páginas web. Por lo tanto, no hay técnicas que podamos aplicar sino que podemos combinar algo de "sacrificio" con buenas prácticas.
Personalmente, creo que no debemos estresarnos con esta métrica y, por supuesto, no recomiendo prescindir de la funcionalidad de la web en favor de una mejora de 0,10 en CLS.
Además, aunque Google dice que CLS es para mejorar la estabilidad visual y la UX, creo que eliminando ciertos elementos podemos ir directamente en contra de la UX.
Optimizar y mejorar el FID
Ya he hablado de la métrica FID (First Input Delay) en este blog cuando hablé de las métricas anteriores. Esta es otra métrica más enfocada a la UX y a la experiencia de usuario que a la Optimización de la página web. Es una métrica que se incluye dentro de la métrica TBT.
Lo que mide el FID es el tiempo que pasa desde que el usuario hace clic en un botón o enlace de la web hasta que el navegador responde. A nivel práctico, esto es útil en webs donde el usuario tiene que interactuar mucho con la web y, si se abusa de Javascript, esta métrica puede verse muy penalizada. Cuanto más se sobrecargue la web con Javascript, más tardará en ser interactiva tras la carga y peor será la puntuación en FID.
¿Qué puede causar una mala puntuación en el FID?
Pues a nivel práctico y sin entrar en temas muy complejos, el puto Javascript del que ya he advertido en este post. Qué podemos hacer para solucionarlo? Minimizar Javascript, reducir elementos Javascript e incluso la carga asíncrona podría ayudarnos un poco en algunos casos.
Los milagros no existen y, si queremos que se cargue menos Javascript, lo único que podemos hacer es quitar elementos y scripts, esta métrica no suele castigar mucho: si tenemos un buen LCP, lo normal es que no tengamos problemas con el IDF.
Sobre el FID
Bueno, no tengo mucho que decir sobre el FID, excepto que es una métrica que cuenta mitad para la optimización de la página web y mitad para la UX. Está muy relacionado con el tema de la ejecución de Javascript y la sobrecarga del dispositivo.
Actualmente, con el LightHouse V6 no suele aparecer mucho en Search Console, a no ser que la web esté muy mal a nivel de Optimización de Página Web.
Otras métricas TBT, SI y TTI
Hay otras métricas que no aparecen en Google Search Console pero que podemos ver en Google PageSpeed y Google LightHouse.
Algunas métricas están "incluidas" dentro de otras o se encuentran en la misma parte del proceso. Si a eso le sumamos que algunas aparecen en Search Console y otras no, en muchos casos puede llevar a confusión.
TTI (Intervalo de Tiempo de Transmisión)
Se trata de una métrica bastante práctica. Es el tiempo de espera del usuario hasta que puede utilizar la página web. Esta métrica está muy orientada a la Optimización de la Página Web y, para mejorarla, debemos hacer exactamente lo mismo que para mejorar el LCP y el FCP.
Si mejoramos el LCP, también mejoraremos el TTI a menos que tengamos demasiados scripts JS retardados que se ejecuten al final de la carga visible mientras el usuario ya puede interactuar con el sitio web.
TBT (Total Blocking Time)
Otra métrica bastante importante que en muchos casos es sustituida por FID, ya que está relacionada. Aún así, TBT tiene un peso del 25% en la puntuación de Google PageSpeed.
El TBT es algo más complicado de explicar, ya que mide el bloqueo del hilo del proceso principal, lo cual es muy técnico y muy específico.
Una de las cosas que más impacta en la TBT (así como en la FID) es el exceso de Javascript que procesamos durante la carga de una web.
SI (Speed Index)
Esta es otra métrica directamente relacionada con la optimización de páginas web. Mide exactamente cuánto tiempo se tarda en ver el contenido en la pantalla desde que empieza a "doler".
El Índice de Velocidad mide más cómo percibe el usuario la velocidad de carga de nuestro sitio web y es una métrica más visual que otras como LCP o FCP.
¿Cómo se mejora? Una vez más, me gustaría hacer hincapié en la importancia de Javascript y no utilizar demasiados elementos DOM (páginas muy largas o complejas).
Teoría vs. Practica
Por último, la práctica se resume en tiempos de carga y experiencia de usuario, mientras que las métricas y puntuaciones son simple teoría que puede o no ser utilizable, según la naturaleza de la métrica.
Como decía antes, Core Web Vitals ha cambiado las cosas y las métricas tienen un poco más de sentido, ya que Google PageSpeed hasta mediados de 2018 directamente carecía de sentido como herramienta y como sistema de medición.
También me interesa saber cuándo merece la pena sacrificar algunos elementos necesarios para el marketing o el negocio para ganar puntos en PageSpeed y LightHouse.
