Test de velocidad web: por qué tarda tu portada

Casi todas las herramientas de velocidad te dan un número. Lo difícil es saber qué hacer con él. Este test se fija en las causas técnicas que se pueden ver en tu página de inicio desde fuera y te dice, para cada una, qué significa y cómo se corrige. Si buscas una explicación más general, la guía por qué una web puede ser lenta repasa los motivos más habituales sin tecnicismos.

Lo que medimos, de la primera petición a la última imagen

El servidor tarda en responder

Antes de mostrar nada, el navegador espera la primera respuesta del servidor. web.dev, el sitio de Google sobre rendimiento, considera bueno un tiempo hasta el primer byte de 0,8 segundos o menos. Nosotros somos más exigentes y lo señalamos desde 0,6 segundos. Si sale este aviso:

1. Pregunta a tu empresa de alojamiento si tienes activada una caché de páginas.
2. Comprueba qué versión de PHP u otro lenguaje usa tu web y si está al día.
3. Si la web es un WordPress con muchos plugins, desactiva los que no uses, con copia de seguridad previa.
4. Si nada de eso basta, valora un plan con más recursos o un servidor más cerca de tu clientela.

El HTML pesa demasiado o llega sin comprimir

Hablamos solo del código de la página, sin imágenes. Una portada ágil suele quedarse por debajo de 80 KB. Cuando pesa mucho más, el motivo habitual son estilos, iconos o textos incrustados dentro del propio código. Además, todo lo que es texto (HTML, CSS y JavaScript) debería viajar comprimido. Si tu servidor no envía la cabecera Content-Encoding, pide que activen Brotli o gzip: es un cambio de configuración, no de diseño. La documentación de Chrome para desarrollo explica cómo verlo en la pestaña Red del navegador.

Scripts que bloquean y demasiados scripts

Un script sin los atributos defer o async obliga al navegador a pararse, descargarlo y ejecutarlo antes de seguir. Chrome los considera recursos que bloquean el renderizado cuando están en la cabecera de la página. Nosotros contamos todos los scripts externos sin esos atributos, estén donde estén, así que algunos pueden molestar menos de lo que parece. También avisamos si la portada carga más de diez scripts: suele ser señal de chats, píxeles o plugins acumulados con los años.

Qué hacer: haz inventario. Para cada script, pregunta quién lo usa y para qué. Quita lo que sobre y carga el resto con defer.

Hojas de estilo separadas

Cada archivo CSS es una petición que el navegador debe completar antes de pintar la página. Con más de tres lo señalamos; con más de ocho, con más prioridad. Muchos gestores y plugins de caché permiten unir y minimizar los estilos en un solo archivo.

Imágenes: formato, carga diferida y medidas

• Formato. WebP y AVIF ofrecen mejor compresión que JPG y PNG con la misma calidad. El SVG, para logotipos e iconos, también cuenta como formato moderno.
• Carga diferida. Las imágenes que quedan más abajo pueden esperar con loading="lazy". Las primeras, no: web.dev aconseja no diferir las que se ven al abrir la página. Por eso nuestro test no tiene en cuenta las tres primeras.
• Medidas. Una imagen sin width y height no tiene su hueco reservado y, al cargar, empuja el texto hacia abajo. Es la causa más común de saltos en la página, según web.dev.

Sin instrucciones de caché

La cabecera Cache-Control le dice al navegador cuánto tiempo puede guardar una respuesta sin volver a pedirla. Sin ella, cada visita puede repetir descargas innecesarias. web.dev lo explica en su guía sobre la caché HTTP. Es otra tarea para quien gestiona tu servidor.

Este test no es Core Web Vitals

Google mide la experiencia real con tres métricas, las Core Web Vitals:

• LCP (carga): el elemento principal debería verse en 2,5 segundos o menos.
• INP (respuesta): la página debería reaccionar a un toque o clic en 200 milisegundos o menos.
• CLS (estabilidad): los saltos de contenido deberían sumar 0,1 o menos.

Se evalúan sobre el percentil 75 de las visitas reales, separando móvil y ordenador. Nuestro test no las calcula: no abre la página en un navegador ni recoge datos de personas reales. Lo que hace es encontrar causas que suelen empeorarlas. El tiempo de respuesta del servidor, por ejemplo, no es una Core Web Vital, pero retrasa todo lo demás, incluido el LCP.

Para los datos de campo, usa PageSpeed Insights. Si tu web tiene suficientes visitas, muestra cómo la han vivido las personas que la visitan con Chrome en los últimos 28 días, junto a una prueba de laboratorio. Si ambos datos no coinciden, da más peso a los de campo.

Lo que un análisis automático no ve

• Una sola medición, desde nuestro servidor. No desde el móvil de tu clientela ni con su cobertura. El tiempo puede variar entre una prueba y otra: repítela antes de sacar conclusiones.
• Solo la portada. Una ficha de producto o un formulario pueden ir peor. Las páginas internas que tardan más de 2,5 segundos se señalan aparte, en calidad web.
• El peso real de cada imagen. Miramos el formato y los atributos, no los megas de cada archivo.
• Lo que pasa en el navegador. Animaciones pesadas, tipografías o scripts que se cargan después no aparecen en el código inicial.

Para una revisión con método, la guía sobre la auditoría técnica web explica qué incluye. Y para las comprobaciones que puedes hacer tú con el móvil, tienes cómo saber si tu web funciona correctamente.

Por dónde empezar

Activa la compresión y la caché, que suelen ser cambios rápidos en el servidor. Después, imágenes y scripts sobrantes. Mide antes y después de cada cambio, y anota la fecha. Si quieres ver también cómo está tu web en buscadores, prueba a analizar el SEO de tu web; y si necesitas ayuda para priorizar, cuéntanos tu caso. El resultado del diagnóstico gratuito llega por correo y es orientativo.