email telefono contacto

Core Web Vitals / Google PageSpeed

Voy a empezar aclarando que me va a costar explicar con palabras todo lo que quiero contar sobre Core Web Vitals o Google PageSpeed en este post. Core Web Vitals (o, lo que es lo mismo, Google PageSpeed o Google Lighthouse) es un tema de actualidad desde mediados de 2020, ya que Google le ha dado bastante bombo al asunto y cada persona dice algo diferente.

Como resultado, existe mucha información en Internet sobre este tema, pero hay mucho ruido y muchos hablan «de oídas”. Yo aquí voy a hablar con fundamento, ya que llevo 10 años en temas de WPO y durante todos este tiempo he vivido muchísimos cambios en PageSpeed y sus distintos algoritmos.

Page Speed y Core Web Vitals

Todo esto apareció en el año 2010. Yo lo conocí más o menos en 2011 y en 2012 ya estaba viendo casos de clientes que querían subir su puntuación en Google PageSpeed. Desde 2012 hasta 2021, las cosas han cambiado mucho y el algoritmo ha cambiado 500 veces (exageración), aunque no todas para bien. Empezó siendo un análisis web que mostraba buenas prácticas, pero muy pocas relacionadas con el WPO y la velocidad de carga (a pesar de su nombre).

Yo siempre he estado muy en contra de Google PageSpeed y de todas las herramientas que sacan una puntuación sin sentido, ya que en temas de velocidad de carga siempre son poco objetivas. Por el contrario, los tiempos de carga en segundos no mienten.

En este enlace de la página de desarrolladores de Google aún podemos ver algo de la documentación del año 2010 sobre la velocidad de carga: https://developers.google.com/search/blog/2010/04/using-site-speed-in-web-search-ranking

No me voy a liar más. Voy a intentar explicarte un poco la historia de Google PageSpeed y también cómo conseguir una buena puntuación desde el punto de vista de la lógica y de la verdad.

Índice del artículo

Core Web Vitals / Google PageSpeed 1
¡Suscríbete al boletín!

No te enviaremos spam, lo prometemos. Enviamos a nuestros suscriptores contenido sobre WordPress, hosting, marketing digital y programación.

+ Información básica sobre protección de datos

¿Qué es Google PageSpeed actualmente?

Voy a explicarte lo que es ahora mismo Google PageSpeed, sin hablar del pasado, ya que Google PageSpeed ha sido muchas cosas a lo largo del tiempo (y no exagero).

Actualmente, Google PageSpeed es la parte visible, la herramienta; concretamente, se llama Google PageSpeed Insights. Es la herramienta que te ofrece la puntuación y algunos consejos o buenas prácticas para mejorar la “velocidad de carga” y la experiencia de usuario.

Que es Google PageSpeed

Pero detrás de esto tenemos el algoritmo Google Lighthouse, que es el motor que mueve Google PageSpeed Insights. Actualmente, Google Lighthouse viene integrado en todos los Google Chrome. Además, muchas herramientas (como GTMetrix) utilizan esta implementación para realizar sus propios tests de Google PageSpeed:

Google Lighthouse

Por otro lado tenemos Core Web Vitals, que han cogido muchísima fama en 2020 y que utilizan el algoritmo Google Lighthouse, pero solo algunas métricas para hacer medias y dar puntuaciones.

Core Web Vitals es una “iniciativa” de Google que utiliza datos de Chrome UX Report para mostrar la media de las métricas sacadas directamente de usuarios reales cosa que, como vamos a ver en las siguientes secciones, puede llegar a ser contraproducente y dar bastantes problemas.

Entonces, sabiendo esto, vamos a responder a las siguientes preguntas.

¿Qué es Google PageSpeed Insights?

Inicialmente Google PageSpeed fue la herramienta, el algoritmo y todo, pero actualmente Google PageSpeed Insights simplemente es la interfaz y herramienta donde los usuarios “normales” sacan sus conclusiones (que suelen ser erróneas) y se vuelven paranoicos.

Google PageSpeed Insights

Google PageSpeed muestra datos mezclados de Google Lighthouse en vivo y datos de Core Web Vitals sacados directamente de Chrome UX Report.

Es una herramienta bastante completa, excepto porque tiene poca documentación (la mayoría de la documentación es de Lighthouse y Core Web Vitals) y la mayoría de la gente no sabe interpretar correctamente la información ofrecida.

Índice del artículo

Core Web Vitals / Google PageSpeed 1
¡Suscríbete al boletín!

No te enviaremos spam, lo prometemos. Enviamos a nuestros suscriptores contenido sobre WordPress, hosting, marketing digital y programación.

+ Información básica sobre protección de datos

¿Qué es Google Lighthouse?

Podemos decir que Google Lighthouse, actualmente, es el algoritmo que hay detrás de Google PageSpeed Insights.

Google Lighthouse no solo saca métricas relacionadas con la velocidad de carga, sino que la mayoría de métricas de este algoritmo son para UX y buenas prácticas en desarrollo web.

Google Lighthouse

Cualquier Google Chrome o navegadores basados en Chromium puede medir Google Lighthouse, ya que llevan la implementación en el núcleo.

Los datos almacenados en la base de datos de Chrome UX Report se sacan con Google Lighthouse, seleccionando algunas de sus métricas. Los datos que podemos ver en Google Search Console en Core Web Vitals están basados en los datos de Lighthouse almacenados.

¿Qué es Core Web Vitals?

Según Google, Core Web Vitals va a ser un factor de posicionamiento en 2021. Se trata de una media conseguida a través de Chrome UX Report con algunas métricas seleccionadas de Google Lighthouse.

Las métricas utilizadas para conseguir los resultados de Core Web Vitals han cambiado varias veces a lo largo del tiempo, pero en el momento de escribir este artículo son el LCP, FID y CLS.

Existen algunas métricas adicionales. Por ejemplo, el FCP engloba el LCP, el Speed Index es un resumen conjunto de los resultados de todas las métricas y hay algunas más que vamos a explicar en breves.

También vamos a explicar los problemas que tiene sacar las Core Web Vitals del Chrome UX Report y los problemas que existen para medir el rendimiento de usuarios reales.

Medir PageSpeed/LightHouse

Uno de los problemas de objetividad que tienen Google PageSpeed/Google Lighthouse/Core Web Vitals es que, dependiendo de cómo lo midas y desde dónde, te va a dar un resultado u otro. No solo depende de la implementación (que puede hacerla cualquiera), sino de la potencia disponible para hacer el test y de la conexión.

Existen 4 formas de medir esto (con diferentes nombres) y puedes verlas en el siguiente vídeo:

Como puedes comprobar, con cada método obtenemos una puntuación y unas métricas completamente diferentes, por lo que es imposible aislar el resultado y ser completamente objetivos.

¿Qué relación existe entre PageSpeed y el SEO?

Pues, realmente, ninguna. Aunque muchos han atribuido propiedades milagrosas a la puntuación de Google PageSpeed, la verdad es que no las tiene. Normalmente, lo que marca la diferencia en SEO en cuanto a velocidad de carga es la indexación y el crawling.

Hasta el momento solo he visto una web con mal PageSpeed que perdiera posiciones en las SERP y tenía problemas de indexación muy gordos relacionados con la saturación de JS durante el crawl. Evidentemente, al solucionar estos problemas mejora la puntuación y, al mismo tiempo, el bot de Google puede crawlear correctamente el sitio web.

PageSpeed y SEO

Esto de la captura anterior es la herramienta que nos ha dado Google en Google Search Console para controlar la indexación y el crawling. Para mí es una herramienta fundamental para ver si existen problemas: es bastante más útil que toda la información ofrecida en Google PageSpeed Insights. La mayoría de gente que se queja de mala puntuación en PageSpeed nunca ha revisado los datos ofrecidos por la herramienta “Estadísticas de rastreo” de Google Search Console.

¿Es posible que en el futuro la puntuación de Google PageSpeed o Core Web Vitals influya en el SEO? Pues pasamos a la siguiente sección.

¿Core Web Vitals influye en el SEO?

La respuesta es exactamente la misma que arriba, pero con algunos matices.

Google ha comentado que, a lo largo de 2021, se van a implementar algunos cambios en el algoritmo del buscador para que esas puntuaciones afecten a las SERP como un factor de posicionamiento más. Sinceramente, yo no creo que eso sea posible si no se relaja un poco el impacto de ciertos aspectos técnicos en la puntuación. Y eso es precisamente lo que te explico en este vídeo:

Por un lado, es muy difícil asumir y llevar a cabo ciertas adaptaciones sin que afecten a decisiones de negocio. Por otro, como comento en el vídeo, penalizar en base a puntuaciones de carga de usuarios reales puede llegar a ser incluso “clasista” dependiendo del mercado y del país al que orientemos nuestros sitios web.

No todo es blanco o negro, hay puntos intermedios en la balanza, y eso es precisamente lo que creo que falta ahora mismo. Esto ha hecho que haya muchos administradores de sitios web que se han obsesionado con los resultados de Core Web Vitals en Google Search Console.

¿PageSpeed y Core Web Vitals = WPO?

NO. Ni Google PageSpeed ni Core Web Vitals ni Google Lighthouse son sinónimos de “velocidad de carga” o WPO.

WPO es un concepto creado en el año 2004 en EE. UU. y que engloba buenas prácticas orientadas a mejorar la velocidad de carga de un sitio web, pero cualquiera de los servicios de Google mencionados anteriormente son buenas prácticas para UX en un 80% y velocidad de carga en el 20% restante.

Google PageSpeed y Core Web Vitals han ido por el camino del UX, con métricas como el LCP y el CLS, que realmente están orientadas al usuario y no al rendimiento de la web, aunque pueden abarcar otros aspectos técnicos.

Desde hace más o menos dos años, Google PageSpeed (y todo el stack) busca que los usuarios prioricen la carga de los elementos de la parte superior de la página. Esto no es velocidad de carga real, sino postureo visual.

El WPO va mucho más allá: se trata de optimizar una web para que su carga sea impecable y como un reloj suizo, consumiendo los menos recursos posibles y siendo eficiente. Me he esforzado mucho en repartir este mensaje en diversas conferencias desde 2016 y parece que mucha gente aún no lo ha entendido del todo.

¿Merece la pena buscar el 100/100 de Google PageSpeed?

Ya dejando de lado Core Web Vitals, vamos a hablar del 100 de 100 en Google PageSpeed.

Mucha gente quiere conseguir el 100 de 100 en Google PageSpeed, pero no saben lo que implica, lo que necesitan ni que, en muchos casos, es inviable sin replantear el proyecto web y empezar de cero. Lo malo es que, además de no saberlo, tampoco quieren saberlo y, en muchas ocasiones, a los consultores WPO como yo nos piden cosas imposibles.

Hay que tener en cuenta que, en el 99,9% de los casos, para conseguir el 100 de 100 es necesario desarrollar la web desde cero y haciendo una inversión en desarrollo MUY ALTA. Por otro lado, también habrá que sacrificar herramientas de marketing que, a nivel negocio, suelen resultar vitales para una empresa. Olvídate de Google Analytics, de herramientas de automatización de marketing, del píxel de Facebook y Google Ads, etc.

Es más, como puedes ver en el siguiente vídeo, si tienes una web de contenido y quieres un buen PageSpeed tampoco puedes poner Google Adsense:

https://www.youtube.com/watch?v=TScKmn7y3wQ&ab_channel=AlvaroFontela

Si has visto el vídeo, estarás pensando: ¡Ostras! Si hasta los propios servicios de Google bajan MUCHO la puntuación de Google PageSpeed.

El 100 de 100 en PageSpeed es algo difícil, por no decir imposible, de alcanzar en la práctica. Si una web no es simplemente un prototipo y la queremos para vender o monetizar correctamente, es muy difícil alcanzar esa puntuación sin perder ventas o la posibilidad de optimizarlas.

Mejorar la puntuación de Google PageSpeed

No existe un método exacto para mejorar la puntuación de Google PageSpeed. Simplemente tenemos que mejorar los resultados en algunas métricas.

La mayoría de las métricas están basadas en tiempos, mientras que otras (como el CLS) están basadas en algoritmo.

Mejora la puntuacion en Google PageSpeed

A continuación, voy a intentar explicar todas las métricas que actualmente participan en Google PageSpeed, en Lighthouse y en Core Web Vitals, así como la relación entre ellas.

Debes tener en cuenta que, para mejorar las puntuaciones, debes cumplir ciertas cosas que puedes ver en la interfaz de Google PageSpeed Insights:

PageSpeed Insights

Esto puede parecer fácil, pero necesitarás conocimientos técnicos en el 90% de los casos. Y en el 10% restante no es que necesites conocimientos técnicos, es que necesitas o un milagro o directamente un sacrificio, que justo es lo que explicamos anteriormente.

El algoritmo de Google Lighthouse es público, junto con los porcentajes y el peso de cada métrica: https://googlechrome.github.io/lighthouse/scorecalc/

Algoritmo Google Lighthouse

El tema es que el algoritmo de Lighthouse se va actualizando y en las distintas versiones los porcentajes y pesos van cambiando. En el momento de escribir esto estamos en la V7, pero puede que en futuras versiones los porcentajes e incluso las métricas cambien.

Bueno, no me lio más. Te voy a explicar algunas métricas de Google PageSpeed/Google Lighthouse y Core Web Vitals, junto con cómo mejorarlas.

Google PageSpeed: FCP

Vamos a empezar con una de las métricas más importantes y de las más difíciles de mejorar.

El FCP (First Contentful Paint) tiene un peso del 15% en la puntuación total y suele ser de las que más bajan la puntuación, dado que el CSS y el JS complejo suele dañar bastante el FCP.

El FCP mide el tiempo que tarda en cargar la parte de arriba de la web, es decir, el “Above the fold” o la parte visible en el momento de la carga.

Para mejorar la puntuación del FCP en Google PageSpeed y Core Web Vitals podemos aplicar las siguientes técnicas WPO:

  • Mejorar los tiempos de respuesta y el TTFB, normalmente con un servidor web más eficiente (LiteSpeed o Nginx) o implementando un sistema de cache a nivel servidor.
  • Implementar browser cache o cache de navegador, aunque esto solo afecta a las mediciones sobre usuarios reales.
  • Implementar una carga ágil y bien estructurada utilizando resource hints o precarga de recursos: preload, prefetch DNS, preconnnect, etc.
  • Implementar un CDN, sobre todo para agilizar la carga de JS y CSS.
  • Implementar un servidor web o CDN con HTTP/2 y HTTP/3, ya que la multiplexación permite agilizar el envío de archivos al navegador del visitante.
  • Auditoría completa de las peticiones externas a hosts de terceros y ajustes mediante carga asíncrona y retardada.
  • Eliminación de excedente de JS y CSS, tanto mediante minificación como carga condicional o directamente eliminación de recursos. Aunque esto puede parecer fácil, es de las partes más difíciles debido a las tendencias actuales en temas de desarrollos de themes y de webs en general.

En muchos casos, los problemas de FCP vienen por un exceso de JS y CSS o por ciertas librerías con muchas dependencias que dan problemas en la carga.

Debemos ser conscientes de que, si necesitamos cierto Javascript o CSS en nuestro sitio web, no hay milagros: o eliminamos la funcionalidad, y con ello el código, o poco más podemos hacer.

Si tenemos un sitio web WordPress con un theme multipurpose complejo con mucho CSS y JS y queremos una buena puntuación en Google PageSpeed, podemos aplicar todas las técnicas WPO listadas anteriormente, pero va a llegar un momento en que no podremos conseguir más mejora sin rehacer la web por completo.

Google PageSpeed: LCP

El LCP (Largest Contentful Paint) engloba parte del FCP, la primera parte. El LCP tiene un peso del 25% en la puntuación total y lo que mide es el tiempo que tarda en cargarse el elemento más grande en dimensiones de la parte de arriba de la web.

El elemento más grande del “Above the fold” puede ser una imagen o un CSS. El problema es que, si Google detecta que el elemento con mayor dimensión es un CSS, este puede contener varias imágenes y ser muy pesado en tiempo.

Pero hay más, y es que no solo se calcula el tiempo de ese elemento, sino que se mide el tiempo total del conjunto desde que empieza a cargar la web, todos los bloqueos de JS y CSS hasta que se carga el elemento más grande. Por esta razón, incluye la primera parte del FCP.

Google Pagespeed FCP

En la mayoría de casos, al mejorar el FCP también mejoraremos el LCP. Mucha gente suele intentar ajustar al máximo el elemento que detecta Google como el LCP sin tener en cuenta que todos los bloqueos que ocurren antes también cuentan.

Como he dicho, para mejorar el LCP tenemos que solucionar los bloqueos y también todo lo listado para el FCP, ya que el FCP en parte incluye el LCP.

Además de mejorando el FCP, el LCP también se mejora solucionando “Oportunidades” como “Elimina los recursos que bloqueen el renderizado”. Esto puede hacerse reduciendo el CSS y JS o intentando cambiar el esquema de carga de recursos para que no bloqueen la carga por dependencias o por tiempo en ningún momento. Podemos usar preconnect o preload para hacer una carga escalonada, haciendo uso también de la carga asíncrona y carga retrasada para el JS, pero los milagros no existen y, en algunos casos, en sitios muy sobrecargados puede no ser suficiente.

Si quieres más detalles, puedes bajar un poco más en este artículo y pasar a la parte de “Oportunidades” o “Diagnóstico”.

Google PageSpeed: CLS

El CLS (Cumulative Layout Shift) tiene un peso muy bajo, el 5%. No es una métrica de “velocidad de carga”, sino que se trata de una métrica de UX que mide estabilidad visual.

Es la única métrica basada en algoritmo y no en tiempo, lo que hace que no pueda ser muy objetiva. En la práctica la medición de CLS falla como una escopeta de feria.

El CLS mide cómo se mueven los elementos en la pantalla después de la carga inicial de la página.

PageSpeed colocacion CLS

Esto puede evitarse marcando en el HTML las dimensiones de todos los elementos, teniendo cuidado con el lazy load de los mismos y evitando la inyección dinámica de nuevos elementos mediante JS tras la carga inicial de la página. En WordPress, WP Rocket permite marcar fácilmente las dimensiones en el código si nuestro theme no lo hace.

El CLS no tiene muchos más secretos, solo con lo anterior ya podríamos cumplirlo. El problema es que en muchos casos, como he dicho, la medición no es exacta y puede darnos mala puntuación aunque realmente no tengamos ningún problema en la web.

Google PageSpeed: FID

El FID (First Input Delay) no suele ser una métrica muy nombrada porque es muy fácil de cumplir. Si por casualidad nuestra web cojea en este punto, con implementar una librería de clic instantáneo como instant.page ya estaría solucionado.

Lo que mide el FID es el tiempo que tarda la web en volver a estar interactiva para el usuario después de hacer clic en un enlace o botón.

Google PageSpeed FID

El FID se mide en Core Web Vitals con datos reales de usuarios recogidos dentro del Chrome UX Report, pero no está incluida en Lighthouse directamente.

Normalmente, si tenemos problemas con las otras métricas, también los vamos a tener con el FID, sobretodo con el TTI y TBT, las dos métricas de bloqueo que suelen estar muy influenciadas por el JS y el CSS complejo.

Google PageSpeed: Time To Interactive

El TTI (Time To Interactive) mide el tiempo que tarda la web en ser interactiva para el usuario después de cargar. Esta métrica solo se puede ver en Google PageSpeed Insights y Google Lighthouse, pero no en Core Web Vitals.

No existe una forma exacta de mejorar el TTI. Simplemente se trata de mejorar las métricas principales e intentar que la ejecución del Javascript asíncrono no se extienda mucho en el tiempo ni bloquee la interacción para el usuario.

Google PageSpeed: Total Blocking Time

El TBT (Total Blocking Time) es una métrica que suma el FCP y el TTI, pero sin llegar al Speed Index. El TBT mide el tiempo de bloqueo total. Los bloqueos suelen venir durante la carga de librerías JS y sus dependencias, así como de hojas de estilo complejas que requieren otros archivos CSS.

Es una métrica relacionada con el FID, pero mucho más compleja y artificial. Se puede mejorar al mejorar el FCP y el TTI, pero podemos tener un FCP malo y un buen TBT.

Google PageSpeed: Speed Index

El Speed Index es una métrica secundaria y, aunque aparece en Google PageSpeed Insight, no forma parte de Core Web Vitals.

Con Speed Index se mide el tiempo que tarda la web en estar totalmente disponible para el usuario desde el momento de iniciar la carga, aunque también tengo que añadir que la medición del servicio de Google PageSpeed Insight no es objetivo por la ubicación desde la que se hace la medición.

No existe una forma directa de mejorar el Speed Index. Simplemente hay que mejorar las 3 métricas anteriores, sobretodo el FCP, e intentar no pasarnos con el JS asíncrono o retrasado que pueda afectar a la interacción.

Oportunidades de Google PageSpeed Insights

En Google PageSpeed Insights y en Google Lighthouse tenemos una sección donde nos explican “Oportunidades” detalladas que podemos utilizar para mejorar la puntuación y, en algunos casos, también para conseguir una mejor carga en dispositivos con poca potencia de proceso (JS).

Lo bueno es que en las oportunidades también nos enseñan los archivos específicos que podemos tocar para solucionar el problema:

PageSpeed oportunidades de Insights

Creo que me va a faltar alguna “Oportunidad” en el listado, pero voy a intentar hablar de la mayoría y de cómo solucionarlas.

Eliminar los recursos que bloqueen el renderizado

Es una de las cosas que más suelen aparecer en las oportunidades de Google PageSpeed y de Google Lighthouse. Se trata de eliminar los bloqueos en la carga provocados por dependencias o por unos archivos que llaman a otros, tanto para JS como CSS, aunque el problema suele estar en el JS complejo.

Con los Resource Hints y la carga asíncrona o retrasada podemos conseguir cosas interesantes para mejorar esto, pero los milagros no existen.

Con determinados themes o pagebuilders, como Elementor, resulta imposible solucionar esta oportunidad y conseguir el 100 de 100. El impacto depende completamente de la complejidad del sitio web en cuestión.

Reducir el tiempo de respuesta inicial del servidor

Esto suele aparecer cuando la web no tiene cache o el servidor web tiene algún problema de eficiencia. La primera vez que hacemos el test con Google PageSpeed Insights es normal que nos salga esta oportunidad; si tenemos cache, la segunda ya no.

Quita los recursos Javascript que no se usen

Como su nombre indica, esto se soluciona de forma aparentemente fácil. El algoritmo de Google Lighthouse, teóricamente, puede detectar cuándo un recurso JS o CSS no se utiliza.

Esto puede parecer fácil de solucionar, pero en muchos casos es un falso positivo y no tenemos forma de decirle a Google que realmente sí que lo utilizamos.

Si es un JS que se carga en unas partes de la web y en otras no, podemos utilizar carga condicional (en el caso de WP) para afinar la carga.

Elimina archivos CSS sin usar

Para el CSS aplica exactamente lo mismo que para el Javascript: el algoritmo de Google Lighthouse utilizado en Google PageSpeed Insights falla como una escopeta de feria en la mayoría de los casos y suele dar falsos positivos que no podemos “impugnar”.

Si ese CSS se utiliza solo en una o varias páginas del sitio web, podemos utilizar la carga condicional para afinar la carga.

Usa un tamaño adecuado para las imágenes

Google Lighthouse puede detectar si las imágenes tienen unas dimensiones (en píxeles) demasiado grandes para el hueco donde las estamos mostrando y tienen que ser redimensionadas por CSS.

Esto suele ser fácil de solucionar para la mayoría de las imágenes: hay que configurar un tamaño ancho máximo para el layout más grande donde se van a mostrar.

En WordPress podemos solucionarlo fácilmente con el plugin Imsanity, aunque también podemos hacerlo antes de subirlas al sitio web con una aplicación de escritorio.

Pospón la carga de imágenes que no aparecen en pantalla

Esta oportunidad aparece cuando no tenemos lazy load implementado en el sitio web o cuando el lazy load no está afectando a alguna imagen.

La implementación de lazy load en WordPress es relativamente fácil, pero en algunos casos siempre puede quedar una imagen a la que no aplica (fondos sobretodo) y puede ser necesario meter lazy load manual o con otro método.

Es recomendable usar lazy load nativo en lugar de mediante JS, ya que es mucho más eficiente, aunque depende de la compatibilidad del navegador web.

Minifica los recursos Javascript

Como su nombre indica, simplemente nos pide minificar los recursos Javascript. La teoría es simple, pero en la práctica casi ningún plugin o servicio es capaz de llegar a los niveles de minificación que exige el algoritmo de Google Lighthouse.

Algunos recursos Javascript, al minificarlos demasiado, pueden dejar de funcionar.

Minifica los archivos CSS

Exactamente lo mismo que arriba: se trata de minificar el CSS, pero podemos encontrarnos con que no podemos llegar a los niveles exigidos por Google.

Además, si nos pasamos minificando podemos dañar la apariencia del sitio web.

Evita usar Javascript antiguo en navegadores modernos

Aún no he conseguido saber de dónde viene esto; tampoco he encontrado demasiada documentación. No he logrado aislar lo que provoca esto, pero me imagino que será algún código antiguo o alguna librería obsoleta.

Diagnósticos de Google PageSpeed Insights

Además de las oportunidades, en la interfaz de Google PageSpeed Insights también tenemos un listado de diagnósticos. Los diagnósticos son más técnicos y vienen directamente de Google Lighthouse.

Diagnosticos Lighthouse

En ocasiones, las tareas listadas en diagnósticos pueden darnos una idea más detallada para solucionar problemas y mejorar la puntuación.

Algo curioso del listado de diagnósticos es que no suelen tener punto intermedio: o son demasiado técnicos o son demasiado obvios.

Me voy a dejar alguno, pero voy a intentar explicar los más comunes.

Asegúrate de que el texto permanece visible mientras se carga la fuente web

Esto se soluciona fácilmente. Suele aparecer cuando optimizamos la carga de Google Fonts u otro tipo de fuentes cargadas desde servidores de terceros.

Simplemente tenemos que configurar el font-display en SWAP.

Minimiza el trabajo del hilo principal

Esto se suele mejorar al optimizar la carga del Javascript, ya que es principalmente lo que sobrecarga el navegador del visitante durante la carga del sitio web.

No existe algo específico para mejorar esto, sino que deberemos aplicar técnicas WPO según todo lo comentado anteriormente en este artículo para mejorar el FCP y el LCP.

Pasando la carga de algunos scripts a asíncrona o carga retrasada, podemos conseguir mitigar un poco este diagnóstico.

Publica recursos estáticos con una política de caché eficaz

Para mejorar esto solo tenemos que aplicar browser cache o cache de navegador, algo muy simple y que puede parecer una tontería, pero que ayuda bastante a la carga desde el punto de vista de los usuarios.

El problema es que, en la mayoría de los casos, esta regla aparece por los recursos de terceros cargados desde otros servidores sobre los que no tenemos control. Por lo tanto, no podremos hacer nada para solucionarlo.

Reduce el tiempo de ejecución de Javascript

Al igual que “Minimiza el trabajo del hilo principal”, depende totalmente de las técnicas WPO utilizadas para mejorar la carga del FCP y LCP.

Reduce el impacto del código de terceros

Esto lo solucionamos eliminando scripts cargados desde servidores de terceros. En la mayoría de los casos, eliminarlos es lo único que podremos hacer. En otros casos, podremos trucar scripts y cachearlos en local para poder hacer algunas acciones o aplicar algunas técnicas WPO sobre ellos, pero no siempre.

Los elementos de imagen no tienen width y height explícitos

Esto es exactamente lo explicado en el caso del CLS: debemos especificar las dimensiones de todas las imágenes en el código para evitar perder puntos por el CLS.

Si quieres saber lo que es el CLS, consulta este mismo post un poco más arriba.

Evita un tamaño excesivo de DOM

Google PageSpeed y Google Lighthouse establecen un máximo de elementos DOM anidados como recomendables. Cuando trabajamos con themes o pagebuilders con estructuras muy complejas, podemos alcanzar el máximo e incluso sobrepasarlo de largo.

Esto suele dañar un poco el FCP, pero tampoco es algo que dañe mucho la velocidad de carga general. Lo que sí hace es aumentar el consumo del navegador del visitante al cargar el HTML y puede llegar a ser tan dañino como el exceso de Javascript durante la carga si hay poca potencia en el dispositivo del visitante.

Mejorar Core Web Vitals

Aunque el algoritmo Lighthouse saca muchas métricas con distintos fines y en Google PageSpeed se capturan y muestran todas las anteriores, la verdad es que Core Web Vitals es mucho más simple.

Los datos sacados de Core Web Vitals están basados en Chrome UX Report y las métricas “trabajadas” son el LCP, el FID y el CLS. Hay que tener en cuenta que el LCP incluye también el FCP (al menos, la primera parte), por lo que también medimos FCP.

Ahora vamos con lo que importa. ¿Cómo mejoramos Core Web Vitals?

Mejora core web vitals

Debemos aplicar todo lo anterior para mejorar estas tres métricas, pero también debemos entender cómo funciona Core Web Vitals.

Voy a repetir algo que he explicado ya antes.

Para recoger datos de estas 3 métricas de Core Web Vitals se utiliza la implementación de Google Lighthouse de cada uno de los navegadores de los visitantes. Estos datos se almacenan en el Chrome UX Report en los servidores de Google.

De ahí se saca la media y es precisamente lo que se muestra en Google Search Console:

Google Search Console para Core Web Vitals

Como lo oyes: los datos de tu Google Search Console son la media de los datos obtenidos por los navegadores de los visitantes.

Esto es lo que hace que esta medición no sea instantánea: como hace la media de los últimos 28 días, un cambio puede tardar varias semanas en registrarse. El problema es que esta puntuación media está condicionada por la potencia media y la conexión media de los visitantes de nuestra web.

Por si aún no has visto mi vídeo sobre el tema, mírate la parte final y entenderás por qué digo esto:

En cuanto a los colores, dependiendo de la puntuación puedes verlos en la imagen anterior y la escala de medición.

Todo esto quiere decir que, en algunos casos, aunque mejoremos la puntuación de PageSpeed mucho, las tres métricas de Core Web Vitals que salen en Google Search Console pueden no cambiar o incluso empeorar, ya que no dependen de nuestra web directamente, sino de nuestros visitantes.

Google ha comentado que, a lo largo de 2021, las Core Web Vitals serán un factor de posicionamiento. No obstante, es muy difícil que esto sea así tal y como se están planteando y con las escalas con las que se está trabajando.

Conclusiones sobre Core Web Vitals y Google PageSpeed

No sé lo que ocurrirá en el futuro, pero mi consejo como profesional de WordPress y del WPO con más de 10 años de experiencia es que no te obsesiones.

Cuando la gente pierde el norte es cuando empiezan los problemas, ya que dejan de mejorar otras partes de la web que podrían darles más beneficios para centrarse en algo que les va a reportar poca mejoría en su negocio.

Si habéis visto los vídeos que he incrustado en este post, ya conocéis mi opinión sobre el tema y habéis visto las pruebas expuestas, por lo que creo que no tengo mucho más que decir sobre mis conclusiones.

Por último, quiero añadir que PageSpeed NO es WPO y que si piensas esto estás muy equivocado. Aunque se llame PageSpeed, no es un servicio o iniciativa orientada a la velocidad de carga. Es como si monto un bar y lo llamo “La funeraria”: no se entierra gente, solo tiene el nombre.

Alvaro Fontela
Alvaro Fontela

Mi nombre es Alvaro Fontela, soy consultor Wordpress y blogger activo desde hace años. CEO y co-Fundador de Raiola Networks, escribiendo sobre WordPress, hosting y WPO en este blog desde 2014.

Artículos relacionados

Si te ha gustado este post, aquí tienes otros que pueden ser de tu interés. ¡No dejes de aprender!

Tenemos 0 comentarios en "Core Web Vitals / Google PageSpeed"
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

¿Vienes de otro proveedor?

¡Ningún problema! Te migramos gratis y sin cortes
cohete raiola