PageSpeed.

Resumen de PageSpeed Insights

Hoy el rendimiento de un sitio es vital para el posicionamiento orgánico en las SERP de Google, una tendencia reforzada por las Core Web Vitals (LCP, INP y CLS), que pasaron a ser factores de posicionamiento en 2021.

La pestaña «PageSpeed» de SEO Spider te ayuda a recoger datos de dos fuentes:

• PageSpeed Insights, que usa Lighthouse para medir la velocidad de las páginas con «datos de laboratorio»;
• el Chrome User Experience Report (CrUX, o «datos de campo»), que te da datos reales de navegación.

Para rellenar la pestaña «PageSpeed» hay que conectar la API de PSI desde 1Configuration›2API Access›3PageSpeed Insights.

123

1Account InformationLa pestaña para conectar la API.2Secret KeyLa clave API creada en la Google Cloud Console.3ConnectConecta SEO Spider a la API.

Las métricas

La pestaña PageSpeed ofrece varias métricas generales:

• Total Size Savings.
• Total Time Savings.
• Total Requests.
• Total Page Size.
• HTML Size.
• HTML Count.
• Image Size.
• Image Count.
• CSS Size.
• CSS Count.
• JavaScript Size.
• JavaScript Count.
• Font Size.
• Font Count.
• Media Size.
• Media Count.
• Other Size.
• Other Count.
• Third Party Size.
• Third Party Count.

Otras métricas más concretas se dividen entre las «CrUX Metrics», datos de campo de Chrome, y las «Lighthouse Metrics», datos de laboratorio de PageSpeed Insights.

Métricas CrUX

Para cada métrica tienes el valor y la categoría (Good, Needs Improvement, Poor), tanto para la URL como para todo el origen:

• CrUX Performance.
• CrUX Largest Contentful Paint Time (sec).
• CrUX Interaction to Next Paint (ms).
• CrUX Cumulative Layout Shift.
• CrUX First Contentful Paint Time (sec).
• CrUX Time to First Byte (ms).
• CrUX Origin Performance y las mismas métricas para el origen.

Desde el 12 de marzo de 2024 el INP ha sustituido al First Input Delay (FID) entre las Core Web Vitals.

Métricas Lighthouse

• Performance Score.
• Time to First Byte (ms).
• First Contentful Paint Time (sec) y Score.
• Speed Index Time (sec) y Score.
• Largest Contentful Paint Time (sec) y Score.
• Total Blocking Time (ms) y Score.
• Cumulative Layout Shift y Score.

El Total Blocking Time es la referencia de laboratorio del INP, que no se puede medir sin interacciones reales. Métricas como Time to Interactive, First Meaningful Paint, First CPU Idle y Estimated Input Latency se han eliminado de Lighthouse.

Filtros de PageSpeed

Además de las métricas, la pestaña incluye estos filtros:

• Eliminate Render-Blocking Resources: muestra todas las páginas con recursos que bloquean el «First Paint», junto con el ahorro potencial.
• Properly Size Images: señala todas las páginas con imágenes de tamaño incorrecto y el ahorro de datos posible si se corrigieran.

123

1Ahorro de tiempo9,77 segundos estimados.2ImágenesLos recursos que redimensionar.3Potential SavingsLos KB ahorrados en cada imagen.

Lo ideal es que tu página no sirva imágenes más grandes que la versión que se muestra en la pantalla del usuario. La mejor estrategia es servir «imágenes responsive», generando varias versiones e indicando cuál usar en el HTML o el CSS mediante media queries, tamaño del viewport, etc.

Otras soluciones son usar un CDN de imágenes o formatos vectoriales SVG que escalan a cualquier tamaño, por ejemplo para los iconos.

• Defer Offscreen Images: identifica todas las páginas con imágenes ocultas o fuera de pantalla, junto con el ahorro potencial. Para solucionarlo, plantéate el «lazy-loading» de esas imágenes tras los recursos críticos para reducir el «Time to Interactive».
• Minify CSS: todas las páginas con archivos CSS sin minificar, junto con el ahorro potencial si se minificaran.

12

1Archivo CSSLa hoja de estilo sin minificar.2Potential SavingsLos KB ahorrados con la minificación.

Minificar el CSS mejora el tiempo de carga, porque normalmente el CSS que se usa es más pesado de lo necesario. Los archivos CSS pueden contener caracteres innecesarios como comentarios, espacios en blanco e indentación.

Al publicar, estos caracteres se pueden quitar sin problema para reducir el tamaño del archivo sin cambiar cómo procesa los estilos el navegador. Esta técnica se llama minificación.

/* Header background should match brand colors. */
h1 {
  background-color: #000000;
}
h2 {
  background-color: #000000;
}

Este código se puede minificar en una sola línea:

h1,h2{background-color:#000000}

• Minify JavaScript: muestra todas las páginas con archivos JavaScript sin minificar, junto con el ahorro potencial. Minificar los archivos JavaScript puede reducir el tamaño del payload y el tiempo de análisis del script.
  La minificación consiste en eliminar los espacios en blanco y cualquier código innecesario para obtener un archivo más pequeño pero totalmente válido. Por ejemplo, Terser es una herramienta de compresión JavaScript muy popular. webpack v4 incluye por defecto un plugin de esta librería para crear archivos de build minificados.
• Remove Unused CSS: identifica las páginas con CSS sin usar, junto con el ahorro potencial en bytes. Normalmente los desarrolladores añaden las hojas de estilo de una página así:

<!doctype html>
<html>
<head>
  <link href="main.css" rel="stylesheet">

El archivo main.css que descarga el navegador es una hoja de estilo externa y se guarda por separado del HTML que la incluye. Así, cada vez que el navegador se encuentra con esto, tiene que descargar, analizar y procesar todas las hojas de estilo externas antes de mostrar cualquier contenido en pantalla.

• Efficiently Encode Images: muestra las páginas con imágenes sin optimizar, junto con el ahorro potencial. Lighthouse recoge todas las imágenes JPEG o BMP de la página, fija su nivel de compresión en 85 y compara la versión original con la comprimida. Si el ahorro potencial es de 4 KiB o más, Lighthouse marca la imagen como optimizable.
• Serve Images in Next-Gen Formats: señala las páginas con imágenes en formatos antiguos como JPEG y PNG. El consejo es usar formatos como AVIF y WebP, con mejor compresión y calidad.
• Enable Text Compression: todas las páginas con recursos de texto sin comprimir, junto con el ahorro potencial.
• Preconnect to Required Origin: identifica todas las páginas que se conectan a dominios distintos del tuyo pero aún no priorizan las peticiones con link rel=preconnect, junto con el ahorro potencial. Antes de pedir un recurso a un servidor, el navegador tiene que establecer una conexión: resolver el nombre de dominio a una IP, abrir la conexión con el servidor y cifrarla. En cada paso envía datos y recibe respuestas; esto se llama «round trip» (ida y vuelta) y, según la red, lleva un tiempo que inevitablemente afecta al rendimiento.

Para optimizarlo puedes usar el «preconnect» de los recursos externos (conexiones a otros dominios), que indica al navegador a qué recursos conectarse primero porque son prioritarios.

<head>
  <link rel="preconnect" href="https://dominio.com">
</head>

<!-- La misma indicación se puede enviar con la cabecera HTTP -->
Link: <https://dominio.com>; rel=preconnect

Un ejemplo de uso del «preconnect» podría ser para Google Tag Manager o Google Analytics:

Link: <https://www.google-analytics.com>; rel=preconnect; crossorigin
Link: <https://www.googletagmanager.com>; rel=preconnect; crossorigin

Las «critical request chains» son series de peticiones de red dependientes e importantes para renderizar bien el documento HTML.

• Reduce Server Response Times (TTFB): la velocidad de carga es esencial para una buena experiencia de usuario, y los usuarios son muy sensibles a ella. Un sitio que tarda muchos segundos en cargar tiene tasas de abandono proporcionales. Una de las causas más habituales son las respuestas lentas del servidor al devolver el contenido de la página. Este filtro identifica todas las páginas en las que el navegador tuvo que esperar más de 600 ms la respuesta del servidor al pedir el documento principal.
• Avoid Multiple Redirects: muestra las páginas con recursos que redirigen y el ahorro potencial usando la URL directa. Las redirecciones ralentizan la carga. Cuando un navegador pide un recurso redirigido, el servidor suele devolver una respuesta HTTP como esta:

HTTP/1.1 301 Moved Permanently
Location: /path/to/new/location

y el navegador tiene que hacer otra petición HTTP para obtener el recurso en su nueva ubicación. No se trata de prohibir los 3xx, sino de evitar las cadenas de redirecciones o las redirecciones múltiples en la misma página.
Evita siempre las redirecciones en los recursos necesarios para el «Critical Rendering Path».

• Preload Key Requests: identifica las páginas HTML con elementos que podrían gestionarse con «preload».
  Cuando se pide una página, el navegador solicita al servidor el HTML, analiza su contenido y envía peticiones separadas para cada recurso referenciado. Para mejorar el rendimiento conviene acelerar este proceso pidiendo antes los recursos críticos.
  Un ejemplo sería una fuente llamada desde un archivo CSS, que el navegador solo descubriría tras leer la hoja de estilo. Con el «preload» precargas un recurso que el navegador solo tendría en cuenta más tarde, por ejemplo en las critical request chains.
  Recuerda que el navegador guarda en caché el recurso precargado sin ejecutar scripts, pero al tenerlo ya, lo servirá de inmediato cuando se pida.
  Es muy adecuado para dependencias como JS, fuentes y CSS.

Esta función es una indicación para el navegador que no bloquea la carga del documento HTML. Para implementar el «preload» basta con añadir la etiqueta <link> en el <head> del HTML o usar la cabecera HTTP Link.

<!-- En la sección head -->
<link rel="stylesheet" href="styles/main.css">
<link rel="preload" href="main.js" as="script">

<!-- Con la cabecera HTTP -->
Link: </css/style.css>; rel="preload"; as="style"

• Use Video Format for Animated Images: identifica las páginas con GIF animados, junto con el ahorro potencial si se convirtieran a vídeo.
• Avoid Excessive DOM size: identifica todas las páginas cuyo DOM supera los 1.500 nodos recomendados. El DOM es muy importante porque puede perjudicar el rendimiento de varias formas:
  • el DOM suele incluir muchos nodos que el usuario no ve en la primera carga; esto aumenta sin necesidad el volumen de datos y ralentiza la carga (rendimiento de carga).
  • durante la navegación hay muchas interacciones de los usuarios y de los scripts que obligan al navegador a recalcular la posición y el estilo de los nodos, lo que ralentiza el renderizado (rendimiento en ejecución).
  • si el JavaScript usa selectores generales como document.querySelectorAll(‘li’), podría guardar sin saberlo referencias a muchísimos nodos y saturar la memoria de los dispositivos (rendimiento de memoria).
• Reduce JavaScript Execution Time: señala las páginas con un tiempo de ejecución de JavaScript medio o lento. Cuando una página tarda mucho en ejecutar JavaScript, el rendimiento se resiente:
  • aumenta el coste de red: más bytes, más tiempo de descarga.
  • el JavaScript se analiza y compila en el hilo principal, que deja de estar disponible para la interacción del usuario.
  • al ocupar el hilo principal, el JavaScript también retrasa el TTI (Time to Interactive), lo que penaliza la UX y la web vital correspondiente.
  • si el JavaScript tiene muchas referencias, puede consumir mucha memoria y dificultar el uso de la página.

Para mejorar la ejecución del JavaScript, en general se aconseja minificar y comprimir el código, eliminar el que no se usa y guardarlo en caché.

• Serve Static Assets With An Efficient Cache Policy: devuelve todas las páginas con recursos sin caché, junto con el ahorro potencial. Cuando un navegador pide un recurso, el servidor puede indicarle cuánto tiempo guardarlo en caché. En cada petición posterior, el navegador usa su copia local en lugar de pedirlo a la red. Lighthouse tiene en cuenta fuentes, medios, imágenes u hojas de estilo que responden con 2xx y no han declarado explícitamente una política «no-cache».

Aquí tienes un ejemplo de caché mediante cabecera HTTP:

Cache-Control: max-age=31536000

La directiva «max-age» indica al navegador cuánto tiempo se queda un recurso en caché. Para los recursos estáticos se recomienda al menos un año.

• Minimize Main-Thread Work: identifica todas las páginas con tiempos de ejecución medios o lentos en el hilo principal, que penalizan el renderizado del documento HTML. El proceso de renderizado del navegador convierte tu código en una página web con la que el usuario puede interactuar. Por defecto, el hilo principal gestiona la mayor parte del código: analiza el HTML y construye el DOM, analiza el CSS y aplica los estilos, y analiza, evalúa y ejecuta el JavaScript.

El hilo principal también procesa los eventos del usuario. Así que, cuando está ocupado con otra cosa, la página puede no responder a las interacciones, con una mala experiencia como resultado. Para mejorarlo conviene optimizar el JavaScript de terceros, eliminar el código sin usar, reducir y simplificar (minificar) el CSS, aplazar el CSS no crítico y dividir los payloads de JavaScript.

• Ensure Text Remains Visible During Webfont Load: todas las páginas con fuentes que pueden parpadear o volverse invisibles mientras se cargan.
• Reduce Unused JavaScript: las páginas con JavaScript cargado pero no usado, con el ahorro potencial.
• Avoid Serving Legacy JavaScript to Modern Browsers: las páginas que envían polyfills y transformaciones innecesarias a los navegadores modernos.
• Avoid Large Layout Shifts: las páginas con elementos que provocan desplazamientos del diseño, relacionados con el CLS.
• Image Elements Do Not Have Explicit Width & Height: las imágenes sin dimensiones explícitas, una causa habitual de CLS.

Exportar los datos de rendimiento

Todos los datos de rendimiento, las páginas de origen y las URL de los recursos que se pueden optimizar se exportan en bloque desde el menú 1Reports›2PageSpeed.

123

1ReportsEl menú de informes agregados.2PageSpeedEl submenú de informes de rendimiento.3Informes de oportunidadesOpportunities Summary, Coverage y un informe por oportunidad.