Las métricas de PageSpeed Insights – en la nueva versión impuesta por Google desde hace algún tiempo – son, en cierto modo, bastante difíciles de entender: es un hecho que esas métricas tienden a masacrar “virtualmente” cualquier sitio, asignando puntuaciones que pueden ser embarazosas para los consultores de todo el mundo.

Es muy común, por ejemplo, que los sitios incluso de la más alta calidad y completamente libres de problemas técnicos, a menudo en la primera página de Google, terminen obteniendo una puntuación muy baja, y esto ocurre sobre todo en el lado móvil. No es necesariamente el fin del mundo, seamos claros: el lado SEO también depende de sus competidores, que no siempre lo consideran. Si estos últimos tienden a cuidar y optimizar la velocidad de la página, podrías pensar que tú también – de lo contrario será un factor como muchos otros. Y cada sitio, como siempre, hace la historia por sí mismo.

Después de todo, si instalas cualquier tema en WordPress, incluso el más esencial gráficamente, será difícil encontrar uno que pueda dar 100/100 como puntuación. Lo que es aún más extraño, muchos sitios que para GTMetrix o PingDom están objetivamente bien situados, son sin embargo maltratados por PageSpeed Insights, que requiere un profundo y crítico análisis de su sitio para ser mejorado.

¿Cómo hacerlo, en este momento?

Entender mejor el PSI (PageSpeed Insights)
Si bien es cierto que mucha gente habla de la importancia de PageSpeed, creo que pocos han logrado captar su esencia. Todo comienza con el análisis de la llamada cascada, un gráfico que muchas herramientas para la medición de la velocidad permiten visualizar y que muestra, para cada llamada HTTPS (así HTML, CSS, video, JS) el tiempo necesario para renderizar ese contenido. Esto obviamente afecta el tiempo de carga, pero también crea cadenas potenciales que pueden hacer que la visualización del sitio sea muy lenta, y este es el caso cuando, por ejemplo, los gráficos del sitio todavía se cargan mientras vemos el marcado HTML, o – incluso un caso más común – vemos un formulario de búsqueda o un filtro y no podemos interactuar con él de inmediato.

Todo esto forma parte de un discurso de optimización tanto del DOM general (es decir, el tamaño del HTML generado para cada página, que en temas antiguos tiende a “explotar” y a estar fuera de control) como de la forma en que se organiza y ordena el código CSS y JS dentro de la página, siguiendo en primer lugar las buenas prácticas que casi todo el mundo ignora (por una cuestión de tiempo, la mayoría de las veces), es decir:

  • El CSS debe ser cargado en el encabezado, es decir, en la parte superior de la página;
  • JS debería, a su vez, ser cargado al final de la página;
  • el marcado HTML no debe contener código superfluo o inútil;
  • las llamadas HTTPS para cada uno de los componentes deben ser mínimas, lo que es posible gracias a la minificación y la compresión (que, sin embargo, puede dar lugar a incompatibilidades y problemas de codificación).
  • Análisis de la cascada

Si haces clic en las opciones de desarrollo de Google Chrome en la red, encontrarás una herramienta de cascada integrada. Así que, por todo lo dicho, cuanto más puedas hacer un gráfico tan compacto para cada página, mejor será para al menos una parte de tu PSI.

Los tiempos de carga más largos corresponden a líneas más largas en la parte superior izquierda, mientras que en la parte inferior se encuentra el detalle con todas las llamadas de la página. Reducirlos no es poca cosa, no hay un único método y tendrás que apelar a tus más avanzadas habilidades de desarrollo web.

Cómo mejorar su puntuación de PageSpeed Insights

La optimización de PageSpeed Insights depende de algunos parámetros, definidos por Google – y no siempre medibles directamente en el sitio – que resumiré a continuación.

  • Ver los primeros contenidos – El tiempo que tardas en empezar a ver algo en la página. En la práctica, debes asegurarte de que el contenido aparezca lo antes posible, utilizando como referencia la secuencia de carga del sitio que se muestra en las capturas de pantalla del PSI de Google.
  • Índice de velocidad – Debería coincidir con el tiempo que tarda la página en cargarse correctamente, completamente. Tener un buen hosting y saber configurarlo.
  • Tiempo para la interactividad – El tiempo necesario para que los menús y la parte interactiva se activen; el sitio debe ser probado pacientemente con varias conexiones y dispositivos, ajustándolo de la mejor manera y haciéndolo útil para los usuarios, antes de que se vea bien gráficamente.
  • Visualización del primer contenido útil – El tiempo necesario para que la página tenga un contenido que pueda ser visto por el usuario de manera significativa (más o menos, la existencia o no de un significativo por encima del pliegue).
  • Primera inactividad de la CPU – Esta es una de las métricas más difíciles, de hecho: dicho de manera sencilla, mide el tiempo que tarda el sitio en responder correctamente a los clics o a las búsquedas en el sitio. Es de alguna manera la medida de la respuesta, y para mejorarla la mayoría de las veces tienes que poner tu mano dentro del sitio y trabajar en JS, CSS, PHP, hook o código de acción.
  • Retardo antes del máximo potencial de interacción – De nuevo una métrica difícil de encuadrar, aunque bastante similar a la anterior: mide el tiempo máximo de retardo para que el navegador devuelva algo al usuario. Así que, para decirlo simplemente, si tienes un formulario de búsqueda para tus productos que es lento y responde mal, la puntuación será desastrosa (y, nota, aquí también es sólo JS y CSS optimizado, con algo de precaución en la escritura de código).
  • De hecho, los SEO tienden a no siempre mirar bien esta métrica: también porque es bastante insoportable que sea tan abstruso y complejo de optimizar. La optimización de la PSI, después de todo, es un objetivo importante (si es que alguna vez decidimos darle prioridad) pero nunca debe ser un fin en sí mismo, porque tiende a ser demasiado largo de alcanzar y porque, en general, nunca debemos perder de vista el objetivo de nuestro sitio, que es hacer negocios. Los SEO, después de todo, deberían amar esta métrica, en teoría, porque podría inaugurar una nueva forma de hacer SEO: no exclusiva, a veces difícil de medir, no obligatoria, pero ciertamente de interés en los próximos años de nuestra querida web. Muchos otros, para que conste, critican el enfoque de Google que impone limitaciones demasiado complicadas de respetar y, en cierto modo, realmente demasiado especializadas (el promedio de los webmasters más hábiles ni siquiera sabría cómo optimizar el DOM de una página, por ejemplo).

Cómo no mejorar PageSpeed Insights

Cualquiera que se acerque al tema tiende, al menos en mi experiencia, a operar con el número de plugins instalados: cuanto más hay en WordPress, más lento es el sitio. Este es un aspecto fundamental, y generalmente cuanto más plugins se instalan, más problemas se pueden tener en el lado del rendimiento. Pero esto es sólo un aspecto, en realidad: el número de plugins sólo afecta parcialmente a PageSpeed Insights, y en particular parece estar relacionado con el TTFB (Time To First Byte, una métrica que mide el tiempo entre la llamada para abrir la página web y el inicio de la comunicación – una especie de latencia inicial que se puede medir, para que conste, con la herramienta de cascada de Chrome). Sigue siendo cierto que el problema básico sigue sin resolverse: si un plugin proporcionara una funcionalidad de negocio básica para mi sitio, ¿cómo podría pensar en eliminarlo? ¿Sólo para “hacer feliz a Google”? Francamente, la pregunta se vuelve incomprensible y fuera de lugar, y recuerda los tiempos en que el HTTPS se consideraba un factor de clasificación brutal, incluso antes de que fuera un factor de seguridad para el sitio.

El mencionado TTFB que, por cierto, no se menciona entre los factores anteriores – y ni siquiera es una medida única (¿entiendes lo complicado que es el problema?): puede cambiar dependiendo de la ubicación geográfica en la que te encuentres, por lo que el TTFB medido desde Madrid será casi seguro diferente, en el mismo sitio, del medido desde París. Así que, al final, ¿quién tiene razón? ¿Qué medición del PSI es fiable? Cómo optimizar algo tan difícil de definir (en las aulas de ingeniería se hablaría, en estos casos, de una medición probabilística: no le preste demasiada atención, es una forma de decir que la medición se ve afectada por errores aleatorios, por un “ruido de fondo” que no puede ser eliminado, y cuanto antes nos demos cuenta, mejor).

Cómo mejorar realmente la comprensión de la velocidad de la página

A pesar del nombre, y de acuerdo con la compleja documentación oficial adjunta, el PageSpeed Insights de hoy no depende sólo de la velocidad: también depende de la apariencia del sitio, UX y la “capacidad de respuesta”. ¿Sabes cuando miras un formulario de una página web y el sitio tiende a atascarse mientras se carga? ¿O los casos en los que los elementos funcionales no están correctamente dispuestos en el pliegue? Bueno, por lo que hemos podido entender analizando el problema en varios sitios, parece que estos factores también son relevantes.

De los experimentos que he hecho en las últimas semanas, después de todo, descubrí algunas cosas interesantes sobre PageSpeed, en un intento de mejorarlo, es decir:

  • depende mucho del tema que uses
  • depende sólo parcialmente del número de plugins instalados
  • Regla de oro: cuanto menos CSS y JS pongas en tu tema, mejor.
  • muchos sitios no son, de hecho, optimizables (es más rápido cambiar de tema o de CMS, o descuidar el problema)
  • también es una cuestión de UX, no sólo de rendimiento (Google puede “medir” UX: por ejemplo, conseguí una mejora en la puntuación al optimizar el aspecto del menú a través de CSS, o incluso reducir la altura de la ventana emergente de las cookies, y muchos sitios que no cumplen con la GDPR obtuvieron puntuaciones de estrellas – no es una mala paradoja, diría yo).
  • Una solución práctica puede ser la de minar, pero a veces no es suficiente: lo mejor es eliminar directamente los scripts inútiles y el CSS de cada una de las páginas, cuidando de organizar bien el código y evitar que se carguen cosas innecesarias para la propia página (muchos plugins de WP son un desastre, en esto: por ejemplo Contact Form 7, en su versión actual, añade su propio CSS y JS en cualquier página del sitio, cuando en realidad debería hacerlo sólo en las páginas donde hay un formulario). Comprende bien, en este punto, que para resolver el problema se necesitan habilidades bastante altas, y que a menudo el trabajo a realizar es francamente difícil de cuantificar. Después de todo, la web también es esto, y al menos en parte deberías aceptarlo.

Una crítica razonada de PSI

Muchos sitios, después de todo, no pueden privarse de los componentes JS y CSS como sería virtualmente necesario, y Google no puede pensar en imponer una mentalidad mínima a toda costa – especialmente porque, y aquí lanzo mi pequeña crítica (esperemos que constructiva) es absurdo que las puntuaciones a menudo terminen difiriendo considerablemente entre las mediciones (con Mueller confirmando esto cándidamente: ¡según él es normal!). Si requieres de ayuda puedes contactar con nosotros, además de seo en lepe, ofrecemos este tipo de servicios.

Google está de acuerdo, en cierto modo, con los sitios que son ligeros y gráficamente delgados, también porque son más fáciles de gestionar e indexar: en una prueba un poco extrema que hice hace días, por ejemplo, me di cuenta de cómo es posible obtener 100/100 con PageSpeed Insights.

Sí, hay una forma de hacerlo.

Sin instalar plugins.

Sin cambiar el tema.