VELOCIDAD DE PÁGINAS

Análisis del rendimiento y de las constantes vitales de la Web para mejorar el posicionamiento en los motores de búsqueda.

ÍNDICE:

Visión general
Conocimiento de la velocidad de las páginas

Hoy en día, el rendimiento de un sitio web es vital para el posicionamiento orgánico en el Serp de Google, y esta tendencia se ve aún más corroborada por los nuevos Core Web Vitals, que se han convertido en un factor de clasificación a partir de mayo de 2021.

La pestaña “PageSpeed” del Seo Spider te ayuda a recopilar datos de dos fuentes:

  • PageSpeed Insights, que utiliza Lighthouse para comprobar la velocidad de las páginas web mediante “datos de laboratorio”;
  • Informe de experiencia de usuario de Chrome (CrUX, o “datos de campo”) que te permite obtener datos reales de navegación.

Para rellenar los datos de la pestaña “PageSpeed”, la API PSI debe estar conectada.

> > Configuración API PageSpeed Insights

Las métricas

Desde la pestaña Pagespeed, tienes varias métricas genéricas a tu disposición:

  • Ahorro total de tamaño.
  • Ahorro total de tiempo.
  • Total de solicitudes.
  • Tamaño total de la página.
  • Tamaño HTML.
  • Recuento HTML.
  • Tamaño de la imagen.
  • Recuento de imágenes.
  • Tamaño CSS.
  • Recuento de CSS.
  • Tamaño de JavaScript.
  • Recuento de JavaScript.
  • Tamaño de letra.
  • Recuento de fuentes.
  • Tamaño del soporte.
  • Recuento de medios.
  • Otro tamaño.
  • Otro recuento.
  • Tamaño de la tercera parte.
  • Recuento de terceros.

Las métricas más específicas disponibles se dividen entre “CrUX Metrics”, que corresponde a los datos de campo de Chrome, y “Lighthouse Metrix”, con datos de laboratorio publicados por PageSpeed Insight.

Métricas CrUX

  • Rendimiento CrUX.
  • CrUX Tiempo de pintura del primer contenido (seg).
  • CrUX Primera Pintura de Contenido Categoría.
  • CrUX Tiempo de retardo de la primera entrada (seg).
  • CrUX Primera Categoría de Retardo de Entrada.
  • CrUX Origen Rendimiento.
  • CrUX Origen Primer Contenido Tiempo de Pintura (seg).
  • CrUX Origen Primer Contenido Pintura Categoría.
  • CrUX Origen Tiempo de retardo de la primera entrada (seg).
  • CrUX Origen Categoría Retraso Primera Entrada.

Métricas del Faro

  • Puntuación de rendimiento.
  • Tiempo hasta el primer byte (ms).
  • Tiempo de pintura del primer contenido (seg.)
  • Índice de velocidad Tiempo (seg).
  • Tiempo hasta Interactivo (seg).
  • Primera Puntuación de Pintura Contenta.
  • Primer Tiempo de Pintura Significativo (seg).
  • Primera puntuación significativa en pintura.
  • Puntuación del Índice de Velocidad.
  • Latencia de entrada estimada (ms).
  • Puntuación estimada de la latencia de entrada.
  • Primer tiempo de inactividad de la CPU (seg).
  • Primera puntuación de CPU inactiva.
  • Tiempo para la puntuación interactiva.

Filtros Pagespeed

Además de las métricas, la Ficha incluye los siguientes filtros:

  • Eliminar recursos que bloquean la renderización: se muestran todas las páginas con recursos que bloquean la “Primera pintura” de la página, junto con los posibles ahorros.
  • Tamaño correcto de las imágenes: el filtro resalta todas las páginas que contienen imágenes de tamaño incorrecto y destaca el ahorro potencial si se corrigieran.
Web Vitals - gestione delle dimensioni delle immagini

Lo ideal es que tu página web no muestre imágenes más grandes que la versión mostrada en la pantalla del usuario. La estrategia más adecuada es servir “imágenes responsive” generando múltiples versiones y especificando cuáles utilizar en tu Html o CSS mediante consultas de medios, tamaños de ventana gráfica, etc.

Otras soluciones pueden ser el uso de CDN de imágenes o el uso de formatos de imagen vectorial SVG para escalar a cualquier tamaño, por ejemplo, iconos.

  • Aplazar imágenes fuera de pantalla: identifica todas las páginas que contienen imágenes ocultas o fuera de pantalla junto con el ahorro potencial. Para evitar este problema, puedes considerar la posibilidad de “cargar perezosamente” estas imágenes después de los recursos críticos para reducir el índice de “Tiempo para interactuar”.
  • Minificar CSS: todas las páginas con archivos CSS sin minificar, junto con el ahorro potencial si se minificaran correctamente.
Core Web Vitals - gestione della minificazione dei Css

Minificar el CSS mejora el tiempo de carga de la página porque normalmente el CSS utilizado es mayor de lo necesario. Los archivos CSS pueden contener caracteres innecesarios, como comentarios, espacios en blanco y sangrías.

Cuando se ponen en línea, estas fuentes pueden eliminarse de forma segura para reducir el tamaño del archivo sin afectar a la forma en que el navegador procesa los estilos. Esta técnica se llama minificación.

Esempio del codice Css da minificare

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

  • Minificar 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 de la carga útil y el tiempo de análisis del script.
    La minificación es el proceso de eliminar los espacios en blanco y cualquier código que no sea necesario para crear un archivo de código más pequeño pero perfectamente válido. Por ejemplo, Terser es una popular herramienta de compresión de JavaScript. webpack v4 incluye por defecto un plugin para esta biblioteca para crear archivos de compilación minificados.
  • Eliminar CSS no utilizado: identifica las páginas con CSS no utilizado, junto con el ahorro potencial en bytes. Normalmente los desarrolladores lo utilizan para añadir hojas de estilo a una página:
file css esterno

El archivo main.css que descarga el navegador se denomina hoja de estilo externa y se almacena separado del HTML que lo incluye en el código. Así, cuando un navegador se encuentra con esta condición, debe descargar, analizar y procesar todas las hojas de estilo externas que encuentre antes de poder servir cualquier contenido en la pantalla del usuario.

  • Codificar eficazmente las imágenes: el filtro muestra las páginas con imágenes no optimizadas, junto con los ahorros potenciales. Lighthouse recopila todas las imágenes JPEG o BMP de la página, establece el nivel de compresión de cada imagen en 85 y, a continuación, 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.
  • Servir imágenes en formatos Next-Gen: destaca las páginas con imágenes servidas en formatos antiguos como jpeg y png. El consejo es utilizar formatos como AVIF y WebP, que tienen características de compresión y calidad superiores.
  • Activar compresión de texto: todas las páginas con recursos basados en texto que no se han comprimido, junto con el ahorro potencial.
  • Preconectar al origen requerido: el filtro identifica todas las páginas que tienen conexiones a dominios distintos del tuyo, pero que todavía no están priorizando las peticiones fetch con enlaces rel=preconnect, junto con posibles ahorros. Antes de solicitar un recurso a un servidor, el navegador necesita establecer una conexión con el servidor para buscar el nombre de dominio y definirlo en una dirección IP, establecer una conexión con el servidor y cifrar la conexión. En todos estos pasos, el navegador envía datos y recibe respuestas del servidor, este proceso se denomina “ida y vuelta” y, dependiendo de las condiciones de la red, tarda un tiempo que afecta inexorablemente al rendimiento.

Para optimizarlo, puedes utilizar la “preconexión” de los recursos externos (conexiones a otros dominios), que indica al navegador a qué recursos debe conectarse en primer lugar por considerarlos prioritarios.

preconnect della risorsa per i web vitals

Un ejemplo de aplicación de “preconectar” podría ser para Google Tag Manager o Google Analytics

preconnect di GA e GTM per migliorare le performance dei Core Web Vitals

Las “peticiones de cadena crítica” corresponden a una serie de peticiones de red dependientes e importantes para la correcta renderización del documento html.

  • Reducir los tiempos de respuesta del servidor (TTFB): la velocidad de carga es esencial para una experiencia de usuario adecuada, y los usuarios son muy sensibles a este aspecto. Un sitio que tarda muchos segundos en cargarse tiene tasas de abandono directamente proporcionales. Una de las causas más comunes está relacionada con la lentitud de las respuestas del servidor a la hora de devolver el contenido de la página al navegador. Este filtro identifica todas las páginas en las que el navegador tuvo que esperar más de 600 ms a la respuesta del servidor en la petición del documento principal.
  • Evitar Redirecciones Múltiples: muestra las páginas que tienen recursos de redirección, y el ahorro potencial utilizando la URL directa. Los redireccionamientos ralentizan la velocidad de carga de la página. Cuando un navegador solicita un recurso que ha sido redirigido, el servidor suele devolver una respuesta HTTP como ésta:
codice per la gestione degli reindirizzamenti

y el navegador se ve obligado a realizar otra petición HTTP para recuperar el recurso en la nueva ubicación. Esta consideración no pretende prohibir el uso de 3xx, sino al crear cadenas de redirecciones o redirecciones múltiples en la misma página.
Deben evitarse siempre los redireccionamientos a recursos necesarios para la “ruta de renderizado crítica”.

  • Peticiones clave de precarga: identifica las páginas html con elementos que podrían manejarse con “precarga”.
    Cuando se solicita una página, el navegador solicita la página html al servidor analizando el contenido y enviando peticiones separadas para cada recurso de referencia incluido en el documento. Para mejorar el rendimiento, se recomienda acelerar este proceso solicitando los recursos críticos con antelación.
    Un ejemplo de aplicación podría ser la solicitud de una fuente en un archivo CSS, ya que el navegador sólo la descubriría tras leer la hoja de estilo. Al utilizar la función “Precargar”, vas a precargar y recuperar un recurso que el navegador sólo tendría en cuenta en una fase posterior, por ejemplo, en peticiones de cadena crítica.
    Recuerda que el navegador almacena en caché el recurso en “precarga” sin ejecutar los scripts, pero que, al haberlos considerado ya, los servirá inmediatamente una vez solicitados.
    Esta funcionalidad es muy adecuada para dependencias como JS, fuentes y CSS.

Esta funcionalidad es una directiva para que el navegador no bloquee la carga del documento html. <> <> Para implementar la directiva “Precargar”, basta con añadir la etiqueta enlace en la sección head del html o utilizar la cabecera Enlace HTTP.

gestione del codice con il preload per migliorare le performance dei Core Web Vitals
  • Utilizar el formato de vídeo para las imágenes animadas: identifica las páginas con GIF animados, junto con el ahorro potencial si se convierten a vídeo.
  • Evitar tamaño DOM excesivo: identifica todas las páginas que tienen un tamaño DOM superior a los 1.500 nodos totales recomendados. Considerar el DOM es de vital importancia porque puede afectar negativamente al rendimiento y la eficacia de varias formas:
    • A menudo, el DOM incluye muchos nodos que no son visibles para el usuario cuando la página se carga por primera vez; esta condición aumenta innecesariamente el volumen de datos que hay que servir a los usuarios y ralentiza el tiempo de carga (rendimiento de la carga).
    • Durante la navegación, se producen numerosas interacciones con la página web por parte de usuarios y scripts que hacen que el navegador reorganice la posición y el estilo de los nodos en el DOM, creando ralentizaciones en la renderización (rendimiento en tiempo de ejecución).
    • Si JavaScript utiliza selectores de consulta generales como document.querySelectorAll(‘li’), puede almacenar, sin saberlo, referencias a un número muy elevado de nodos, lo que puede sobrecargar las capacidades de memoria de los dispositivos de los usuarios (rendimiento de la memoria).
  • Reducir el tiempo de ejecución de JavaScript: filtra las páginas de informes con un tiempo de ejecución de JavaScript medio o lento. Cuando una página html tarda mucho en ejecutar scripts JavaScript, ralentiza el rendimiento:
    • aumentar el coste de la red: utilizar más bytes aumenta el tiempo de descarga.
    • El Javascript se analiza y compila en el hilo principal, que no permanece disponible para la interacción del usuario.
    • Ocupar el hilo principal de Javascript también retrasa el TTI (Tiempo para Interactuar) penalizando la Ux de la página y las vitales web dedicadas.
    • Si el Javascript contiene muchas referencias, puede consumir inexorablemente mucha memoria, penalizando la consulta de la página por parte del usuario.

Para mejorar el rendimiento de la ejecución de Javascript, generalmente se recomienda “minificar” y comprimir el código, eliminar el código no utilizado y almacenarlo en caché.

  • Servir activos estáticos con una política de caché eficiente: devuelve todas las páginas con recursos que no están “en caché”, junto con el ahorro potencial. Cuando un navegador solicita un recurso, el servidor que lo proporciona puede indicar al navegador durante cuánto tiempo debe almacenarlo temporalmente o guardarlo en caché. Para cada solicitud posterior de ese recurso, el navegador utiliza su copia local en lugar de obtenerla de la red. Las evaluaciones de Lighthouse tienen en cuenta fuentes, medios, imágenes u hojas de estilo que respondan con el código de estado 2xx y no hayan declarado explícitamente una “política de no caché”.

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

codice per il controllo della cache di un elemento

La directiva ‘max-age’ indica al navegador cuánto tiempo permanecerá un recurso en la caché. Para los “activos estáticos”, se recomienda un tiempo no inferior a un año.

  • Minimizar el trabajo del hilo principal: identifica todas las páginas con tiempos de ejecución medios o lentos en el hilo principal que penalizan la renderización del documento html. El proceso de renderizado del navegador convierte tu código en una página web con la que los usuarios pueden interactuar. Por defecto, el hilo principal del proceso de renderizado se encarga de la mayor parte del código: analiza el HTML y construye el DOM, analiza el CSS y aplica los estilos especificados, y analiza, evalúa y ejecuta el JavaScript.

El hilo principal también procesa los eventos de usuario. Así, cuando el hilo principal está ocupado haciendo otra cosa, la página web puede no responder a las interacciones del usuario, lo que provoca una mala experiencia. Para mejorar este proceso, recomendamos optimizar el javascript de terceros, eliminar el código no utilizado, reducir las referencias CSS y simplificarlas (minificarlas), posponer el CSS no crítico, dividir las cargas útiles de javascript.

  • Garantizar que el texto permanezca visible durante la carga de fuentes web: todas las páginas con fuentes que puedan parpadear o volverse invisibles durante la carga de recursos.

Exportar datos de rendimiento

Todos los datos de rendimiento, las páginas de origen y las URL de los recursos que podrían optimizarse pueden exportarse en bloque a través del menú PageSpeed.

> Informes PageSpeed

Panoramica del report "Pagespeed" di Screaming Frog

ÍNDICE:

Ficha Seo Spider