LightHouse (PageSpeed Insights) o Search Console, ¿Cuál sería el mejor?

Parece ser que hay discusión sobre que métricas son mejores y, sobre todo, más fiables (que es lo que nos interesa) en el tema de la velocidad de carga de una web.

Por un lado tenemos las métricas de PageSpeed Insights (en adelante LightHouse) y Search Console, pasemos a analizar que datos usa cada herramienta y lo más importante como los usan.

Por un lado tenemos a Search Console:

-Search Console, mide las métricas de interacción en tu página de los usuarios que entran y entran con Google Chrome, no mide desde la primera interacción porque lo que mide es más la media de todas las interacciones (por eso tardan tanto en mostrarse) que cada visita en particular. No tienes datos detallados de visita a visita, ni de página a página.

Por otro lado presentamos a LightHouse:

-LightHouse mide un snapshot o una foto del estado de tu página en el momento que entra, esa foto la toma desde cero sin cookies o cache o cualquier otra cosa que no tengas en tus servidores en el momento que la foto se toma. Puedes elegir de que página y en que momento se toma esa foto pero no puedes obtener métricas por valor medio. Pero los puedes guardar y manejar más adelante para conseguir medias por tramos de tiempo o cualquier otra consulta, ya que, permite exportar datos en json para poderlos incorporar a tu base de datos.

Ahora, ¿Cuál de las dos es más válida?

Pues depende de lo que quieras medir y cuando lo midas, para mi las medias no son buenas ni para las piernas. Me gusta tomar snapshots en momentos de alto tráfico y de bajo para poder trabajar sobre ellos y sacar unas conclusiones válidas.

*Ejemplos de webs en Fastalia

¡Espera!, me dirás "Todo esto me parece muy bien, ¿pero que son esas métricas y cuál sería las más importante?"

Pues analicemos las métricas que nos dá LightHouse:

• FSP (First Contentful Paint): En cristiano "Renderizado de la página", cuanto tarda el navegador en entender lo que le estás enviando. Este valor es más alto cuanto más pese el HTML o más complejo sea el javascript.
• TBT (Total blocking Time): El Tiempo de bloqueo es lo que más tenemos en cuenta desde el desarrollo de una web, dado que es el tiempo que tarda el backend en procesar el HTML que va a enviar al navegador.Gran parte de la culpa de este tiempo la tiene la conexión con base de datos y la forma en la que es capaz de manejar esos datos el backend. Ahora me permitireis sacar pecho y decir que en Fastalia hemos hecho un trabajo excepcional, eso si, nos ha tocado desarrollar nuestra propía base de datos y hemos desarrollado nuestros frontales para conseguir la máxima velocidad para cualquier tipo de web y en cualquier situación.
• LCP (Largest Contentful Paint): Sería el tiempo que tarda el elemento más pesado de la página, cuanto tarda en cargar lo que más pesa de toda la página. No es una métrica muy decisiva si lo que más pesa no está en la primera parte visible de página, además si usamos un lazy load puede alterar mucho esta métrica. Por lo tanto, si lo que nos dice que pesa mucho no está en la parte visible por el usuario en la carga podemos descartar este parametro, pero nos fastidia el SI (Speed Index)
• CLS (Cumulative Layout Shift): Ahora viene el momento de agarrar al maquetador por las orejas y pillarle fuerte, este parametro nos mide como se mueven los elementos de nuestra web al cargar. Lo ideal es que cuando maquetamos una web se haga en modo de cajas estaticas asignando el espacio suficiente a imagenes (que tardan más en cargar) dentro de nuestro grid, pues bien, si el maquetador no ha puesto esos espacios nos tira abajo el CLS, pero tampoco es el fin del mundo esta métrica por ahora no tiene mucho peso en global pero si si quieres ver cohetes en LightHouse.
• SI (Speed Index):Y este es el momento héroico de toda la métrica, la valoración final de la velocidad de tu página. El problema en desarrollo es que necesitamos que el CLS esté en condiciones, si no, nos tira toda la métrica al suelo

En Fastalia trabajamos sin descanso para que la parte que podemos hacer nosotros, la de Performance, sea lo más alta posible. Estamos muy por encima de WP o Shopify tanto en respuesta de servidor como en capacidad de optimización, todo ello sin plugins ni costes añadidos. Nuestro ADN es la velocidad y la opmización y queda patente en cada web que está con nosotros.

Que partes son importantes para el SEO

Pues, en mi opinión (me lloverán criticas), una de las partes más importantes de estas métricas es el TBT ¿por qué? porque es el tiempo que el usuario espera hasta que responde tu web, el resto de parámetros se basan en la cantidad de javascript de terceros, las imagenes o como esté maquetada la web. Pero el TBT depende exclusivamente de tu servidor y como procese la información (y porque es el mejor parametro que tenemos )

Aparte de bromas, hay dos parámetros que deberían marcar un Internet mejor y más sostenible. Por un lado el TBT que nos marca la cantidad de energía y tiempo que consume un servidor y por otro el LCP que nos marca la tasa de transmisión de datos de la web. Ambos son importantes y contra menores sean menos trabajan los servidores, mejor será la experiencia de usuario, más tiempo estará en nuestra web y menor será la huella de carbono de nuestro sitio web.

Poco se habla de la huella de carbono de los sitios online, desde Fastalia estamos totalmente inmersos en mitigar esta debacle de gasto energético. Y es que Internet gasta más que muchos paises anualmente, como desarrolladores y diseñadores está en nuestra mano mitigar este gasto, a veces, innecesario. Es fácil, sustituir algún video por una imagen, cambiar la cantidad de HTML necesario para mostar una web,..... usar Fastalia como CMS.

Me dirás que el peso del HTML no supone un coste como tal pero ten en cuenta los millones de interacciones que recibe una web y multiplicalo por el exceso de código que se envía. Eso te dará una aproximación al problema.

Además las webs más optimizadas permiten más interacciones de usuario y por tanto mayor tiempo en la web (mejor para SEO), si el usuario además está feliz porque su iteración con tu sitio ha gastado menos de la mitad de recursos que si hubiera estado en otro pues más agusto estará el usuario en tu web.

Menor TBT y LCP menor consumo.

¿Sabes que puedes gestionar más visitas con un servidor menor? O usar más usuarios en tus servidores.

Si, cuanto menor sea tu TBT mayor será tu tasa de usuarios que admite tu servidor, o dicho de otro modo, mayor será la cantidad de peticiones por segundo que son admitidas en tu servidor.

Modificar esto con los CMS normales (WP, Shopify, Magento, ...) es difícil dado que están más interesados en recopilar datos que en proporcionarte velocidad, ¿no lo sabías?

Para Fastalia prima la velocidad y la experiencia de usuario, lo demás es secundario. Por eso somos los más rápidos en todos los aspectos.

Para despedirme una frase "Cuida tu TBT y LCP, asi también cuidarás el medio ambiente" (Piensa en verde ;)