Hace unos meses (en febrero) escribí y publiqué un post sobre ciertas métricas de Google que se mostraban en 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, yo mismo predije en ese post anterior que el FCP y FID no eran las métricas que deberían tener más peso (si utilizábamos la lógica), ya que existían otras que deberían resultar más importantes en la práctica, como el LCP.
Pues bien. En mayo de 2020, Google actualizó Google Search Console y Google PageSpeed/Google LightHouse con un cambio importante: Core Web Vitals.
Con Core Web Vitals no se añaden ni se eliminan métricas, sino que simplemente se cambia el peso asignado en las puntuaciones y, por lo tanto, se realizan ciertos cambios en Google Search Console (donde aparece una nueva pestaña) y en Google LightHouse.
Aunque era un cambio lógico, yo personalmente no me lo esperaba tan rápido, ya que en temas de WPO no podemos juntar en la misma frase Google y “lógica” porque no van de la mano para nada.
Si quieres una introducción a todo esto, te recomiendo este artículo: https://alvarofontela.com/fcp-fid-wpo-google-search-console/
Con la aparición de la pestaña “Core Web Vitals” o “Metricas web principales” en Google Search Console, muchos websmaters se han vuelto locos porque, de golpe 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 anterior post sobre FCP y FID mostrábamos esta tabla, ya que el FCP y el FID eran las métricas más importantes del momento:
Pero ahora, al cambiar las métricas más importantes o con mayor peso, también tenemos que cambiar la tabla:
Incluso si quieres verlo de una forma más gráfica, esta es la imagen oficial:
Todas estas tablas son oficiales, sacadas de la web de soporte de Google para webmasters, y sirven como referencia para que veas los valores que tienes que alcanzar en cada métrica si quieres conseguir una buena puntuación en Google PageSpeed Insights.
Ahora que nos centramos en solo 3 métricas (aunque las demás siguen estando, pero con menos protagonismo o integradas en otras), vamos a tratar de explicarlas y también lo que 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 este:
- LCP: 25% del total.
- TBT: 25% del total.
- FCP: 15% del total.
- SI (Speed Index): 15% del total.
- TTI: 15% del total.
- CLS: 5% del total.
Todas estas métricas las tendremos en Google PageSpeed, aunque la mayoría no se muestran en Core Web Vitals en Google Search Console.
Si quieres hacer experimentos con la importancia de las puntuaciones, puedes usar esta herramienta oficial de Google: https://googlechrome.github.io/lighthouse/scorecalc/
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
Optimizar y mejorar LCP
Vamos a empezar por la más compleja y veremos cómo podemos mejorar esta métrica.
El LCP (Largest Contentful Paint) es la métrica que yo mencioné en febrero de 2020 explicando que tenía mucho más sentido como métrica principal que el FCP. Como decía más arriba, curiosamente unos meses más tarde Core Web Vitals le dio protagonismo.
Lo que mide exactamente el LCP es el tiempo que tarda en renderizarse y dibujarse en pantalla el elemento (CSS o Imagen) mas grande, y en la métrica se mide también el tiempo de bloqueo, es decir, lo que tarda en cargar incluyendo el bloqueo que ocurre por todo lo que tiene que cargarse antes. Se trata de una métrica MUY lógica y que, con el abuso de Javascript y CSS actual por parte de los sitios web, es normal tenerla controlada.
Para que veas la importancia actual del LCP como métrica, es la que más peso tiene.
¿Qué es lo que puede provocar una mala puntuación en LCP?
- Respuesta lenta en firstbyte o TTFB: Esto ocurre porque el sitio web no tiene sistema de cache de página o porque el servidor web tiene problemas y provoca retrasos importantes. La solución es fácil: implementar cache y resolver problemas de servidor en caso de tenerlos.
- Bloqueos 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 el timeline de carga del sitio web mientras son interpretados. Normalmente, podemos solucionarlo con una carga asíncrona efectiva o eliminando scripts y CSS.
- Lentitud al servir recursos estáticos: Los recursos estáticos como imágenes, CSS, JS, PDF y todo lo que se necesite para ver la web, deben cargarse lo suficientemente rápido. Podemos optimizar la carga de recursos estáticos con un servicio CDN y reducir su peso con técnicas como la minificación, si es posible.
En resumen, algunas de las técnicas que pueden ayudarnos a tener un buen LCP son la implementación de un CDN, la minificación, el cache de página y la carga asíncrona tanto de Javascript como de CSS. También podemos agilizar algo la carga del LCP con resource hints o con carga condicional.
Opinión personal sobre LCP
Como he dicho, se trata de una métrica “buena” y que es aplicable en la práctica al WPO de la mayoría de sitios web.
El hecho de medir la velocidad de carga junto con la renderización hace que sea una métrica aplicable a la práctica.
El problema está en que, en muchos casos, es una métrica muy “nazi” y poco “personalizable”, tiene el listón demasiado alto para llevarlo a la práctica. Como consecuencia, en muchos casos, al implementar ciertos scripts externos de medición 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, aunque el elemento mas GRANDE no sea tan pesado.
Para mí, la métrica es buena y es acertada. Sin embargo, como a la mayoría de cosas que hace Google, le falta bastante transparencia. Yo soy consciente y he demostrado que el Javascript puede bloquear la CPU de un dispositivo móvil de gama baja actual e incluso causar problemas a smartphones de gama alta, que es precisamente lo que nos permite prevenir el LCP. No obstante, creo que debería tener el corte un poco más bajo para poder aplicar la teoría a la práctica.
Para resumir, mi opinión personal es que esta métrica está bien, el enfoque está muy bien, pero la escala está mal y no es transparente. Por esta razón, en muchos casos hay que dar prioridad a las decisiones de marketing o negocio en lugar de ganar unos puntos en PageSpeed a costa del LCP. Si tenemos scripts y partes de la web que debemos cargar antes que el elemento mas grande, tendremos un problema.
Optimizar y mejorar CLS
Ahora vamos con la segunda métrica “nueva”, una métrica que puede desconcertar por lo que mide y porque, en algunos casos, si aliviamos un poco el LCP podemos llegar a dañar el CLS (Cumulative Layout Shift). No es exactamente una métrica antagonista del LCP, pero algunas cosas pueden superponerse.
El CLS mide exactamente cuánto ha cambiado el diseño de la página mientras que se está cargando e interpretando elementos.
Para ponerte un ejemplo a efectos prácticos, cuando no especificamos un tamaño en las imágenes y estas van cargando según se van descargando al navegador del visitante, es normal que al no tener un tamaño asignado las imágenes se vayan moviendo por la pantalla al ser cargadas unas después de otras. Esto que acabo de explicar es penalizado por CLS.
Para que veas un ejemplo práctico directo con una imagen, he encontrado esto en el blog de SEO PowerSuite:
Lo ideal es que la métrica sea 0 (perfecto), pero al requerir ciertos elementos es posible que no podamos mantenerlo en 0.
¿Qué es lo que puede provocar una mala puntuación en CLS?
- Imágenes sin el tamaño especificado en el código: Si no especificamos en el HTML las dimensiones de las imágenes mediante las etiquetas y atributos correspondientes, veremos que el CLS ha sido penalizado. Esto ya lo hacen la mayoría de los Pagebuilders y themes actuales para WordPress.
- 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í se nos plantea una buena decisión de negocio: “ganar dinero” versus WPO.
- Contenido inyectado dinámicamente: Si inyectamos o modificamos contenido de forma dinámica mientras se carga el sitio web, también veremos penalizado el CLS. En webs complejas este es uno de los principales problemas que nos encontraremos, sobretodo en ecommerce donde hay bastante AJAX.
- Carga de fuentes sin estilos: Cuando se optimiza la carga de fuentes desde local o Google Fonts, en algunos casos pueden cargarse inicialmente sin estilos para posteriormente cargar los estilos y el formato. Esto da problemas en el CLS, aunque para el WPO es una buena técnica.
- Cualquier animación o carga dinámica sin recargar: La mayoría de animaciones o cargas dinámicas post-carga sin recargar página pueden penalizar el CLS, en mayor o menor medida, dependiendo del impacto que tengan sobre el total del contenido.
Como he dicho al principio de la sección, el CLS es una métrica complicada de entender por su naturaleza. No es una métrica de WPO, 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 WPO para mejorar el CLS y yo personalmente no recomiendo prescindir de ciertos elementos para tener 0 de CLS.
Opinión personal sobre CLS
Como he dicho antes, CLS es más una métrica de UX y experiencia de usuario que de WPO. CLS no tiene nada de WPO. Por lo tanto, no existen técnicas que podamos aplicar sino que, más bien, podemos combinar algún “sacrificio” con buenas practicas.
Personalmente, creo que no debemos estresarnos por esta métrica y, por supuesto, no recomiendo prescindir de funcionalidades en el sitio web a favor de una mejora de 0,10 en CLS.
Además, aunque Google dice que el CLS es para mejorar la estabilidad visual y el UX, yo creo que al eliminar ciertos elementos podemos ir directamente en contra del UX.
Optimizar y mejorar FID
De la métrica FID (First Input Delay) ya he hablado en este blog cuando traté las anteriores métricas. Se trata de otra métrica más centrada en el UX y la experiencia de usuario que en el WPO. Es una métrica que está incluida dentro de la métrica TBT.
Lo que mide 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 el sitio web y, si se abusa de Javascript, esta métrica puede resultar muy penalizada. Cuanto más sobrecargado este el sitio web de Javascript, más tardara en ser interactivo tras la carga y peor puntuación tendremos en FID.
¿Qué es lo que puede provocar una mala puntuación en FID?
Pues a nivel práctico y sin entrar en temas muy complejos, el puto Javascript del que ya he avisado en este post.
¿Qué podemos hacer para solucionarlo? Pues minificar 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 eliminar elementos y scripts (o implementar una buena carga condicional en el caso de WordPress).
Esta métrica no suele castigar mucho: si tenemos un buen LCP, normalmente no tendremos problemas con el FID.
Opinión personal sobre FID
Pues no tengo mucho que decir sobre el FID, salvo que es una métrica que cuenta la mitad para el WPO y la mitad para el UX. Está muy relacionada con el tema de la ejecución de Javascript y la sobrecarga de los dispositivos.
Actualmente, con la V6 de LightHouse no suele aparecer mucho en Search Console, salvo que la web esté muy mal a nivel WPO.
Otras métricas TBT, SI y TTI
Existen otras métricas que no aparecen en Google Search Console pero que sí las podemos ver en Google PageSpeed y en Google LightHouse.
Algunas métricas están “incluidas” dentro de otras o se encuentran en la misma parte del proceso. Si unimos eso a que algunas aparecen en Search Console y otras no, en muchos casos puede dar lugar a confusión.
TTI (Time To Interactive)
Se trata de una métrica bastante práctica. Es el tiempo de espera del usuario hasta poder utilizar el sitio web. Esta métrica está muy orientada al WPO 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 no ser que tengamos demasiados scripts JS en delay que se ejecuten al finalizar 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. Aun así, el 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 principal de proceso, algo muy técnico y muy específico.
Una de las cosas que más impacta en el TBT (al igual que en el FID) es el exceso de Javascript que procesamos durante la carga de un sitio web.
SI (Speed Index)
Es otra métrica relacionada directamente con el WPO. Mide exactamente el tiempo que tarda en verse el contenido en la pantalla desde que empieza a “pintarse”.
El Speed Index mide más como el usuario percibe la velocidad de carga de nuestro sitio web y es una métrica más visual que otras como el LCP o FCP.
¿Cómo se mejora? Pues otra vez hago hincapie en el tema del Javascript y de no pasarnos con demasiados elementos DOM (páginas muy largas o complejas).
Teoría vs Práctica en WPO
Para finalizar, quiero hacer alusión a un post que publiqué hace unos días y que te permitirá entender la relatividad de las ventajas obtenidas al mejorar las métricas en Google Search Console y Google PageSpeed Insights.
Para mí la práctica se resume en tiempos de carga y experiencia de usuario, mientras que las métricas y puntuaciones son simplemente teoría que puede ser aprovechable o no, dependiendo de la naturaleza de la métrica.
Como he dicho antes, Core Web Vitals ha cambiado cosas y las métricas tienen algo más de sentido, ya que Google PageSpeed hasta mitad de 2018 directamente carecía de sentido como herramienta y como sistema de medición.
Me interesa también recalcar el tema de WPO vs NEGOCIO, es decir, cuándo merece la pena sacrificar algunos elementos necesarios para marketing o negocio para así ganar puntos en PageSpeed y LightHouse.
Pero no voy a profundizar más en todo este tema porque lo he explicado junto con mi opinión transparente en este post: https://alvarofontela.com/wpo-teoria-vs-practica-metricas-puntuaciones-tiempos/
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
3 comentarios
Buenos días.
En cuanto al LCP tengo una duda.
Ya sea porque tengamos un plugin de carga diferida de imágenes, o el propio wordpress, aplican un “lazy load” a todas las imágenes. ¿Esto no perjudica al LCP si es una imagen lo primero que aparece en las páginas de tu web? En tal caso, como podemos hacer para que a estas determinadas imágenes no se les aplique la carga diferida.
He buscado información al respecto y lo único que he visto es una función php que justamente hace esto, si aplicas un id a estas imágenes. Sin embargo, no se como aplicarles el id, ya que wordpress solo permite ponerles una clase.
Muchas gracias de antemano
Hola Juan, si una imagen es LCP no es cargada de forma retardada (aunque se le aplique Lazy Load), ya que carga al principio, por lo que no habría problema.
No podemos hacer nada, ya que Google pilla lo que le sale de las narices como LCP, de hecho yo ya vi caso de que en una carga el LCP era uno y en otra carga el LCP era otro…
Sabes lo malo? Que si le pones para que una imagen no cargue por Lazy Load, Google se te va a quejar de eso, así que lo que arreglas por un lado, lo revientas por otro…
Como ya he dicho en varios videos aportando pruebas, Google Lighthouse y variantes me parecen una mierda porque medio algoritmo carece de sentido…
Muchas gracias Álvaro!