Web lenta en móvil: cómo leer PageSpeed Insights y qué arreglar primero

Respuesta corta: En PageSpeed Insights, mira primero el bloque de datos de usuarios reales (si aparece) y comprueba si pasas las Core Web Vitals: LCP, INP y CLS. La nota de 0 a 100 es una prueba de laboratorio con un móvil simulado y conexión lenta: sirve para encontrar problemas, no como objetivo. Casi siempre conviene arreglar en este orden: el tiempo de respuesta del servidor, la imagen principal, el CSS y JavaScript que bloquean, los scripts de terceros y, por último, los saltos de diseño.

Qué mide PageSpeed Insights

PageSpeed Insights (en pagespeed.web.dev) junta dos cosas muy distintas en la misma pantalla, y confundirlas es el origen de la mayoría de malentendidos.

Datos de usuarios reales (campo)

El bloque de arriba, «Descubre lo que experimentan tus usuarios reales», sale del informe de experiencia de usuario de Chrome (CrUX): mediciones de visitantes reales que usan Chrome, de los últimos 28 días. Para cada métrica se toma el percentil 75, es decir, el valor que cumplen tres de cada cuatro visitas. Es lo que Google usa para valorar la experiencia de página.

Si tu web tiene poco tráfico, verás «No hay suficientes datos». No es un error: simplemente no hay bastantes visitas medidas. En ese caso solo tienes el laboratorio.

Prueba de laboratorio

El bloque de abajo, con la nota de 0 a 100, es una prueba de Lighthouse hecha en ese momento, una sola carga, simulando un móvil de gama media con una conexión lenta. Por eso la nota de móvil es casi siempre peor que la de ordenador, y por eso cambia unos puntos cada vez que repites la prueba.

La nota se calcula con cinco métricas de laboratorio, con estos pesos (Lighthouse 10 y posteriores):

La nota se colorea así: de 90 a 100, buena; de 50 a 89, mejorable; por debajo de 50, mala.

Las métricas que importan

Las Core Web Vitals son tres, y se miden en usuarios reales. Estos son los umbrales que publica Google en su documentación:

Dos métricas de apoyo que también conviene mirar: TTFB (tiempo hasta el primer byte, bueno hasta 0,8 s) y FCP (bueno hasta 1,8 s). Si el TTFB es malo, todo lo demás llega tarde por definición.

INP no tiene equivalente directo en el laboratorio, porque necesita que alguien toque la página. Su aproximación en Lighthouse es el TBT: si el TBT es alto, es muy probable que el INP real también lo sea.

Cómo leer el informe, en orden

1. Elige la pestaña Móvil. La mayoría de tus visitas vienen del móvil, y es donde se notan los problemas.
2. Mira si pasas las Core Web Vitals en datos reales. Si las tres están en verde, tu web va bien para tus usuarios aunque la nota de laboratorio sea un 70. Puedes mejorar, pero no es urgente.
3. Si alguna falla, quédate con cuál. No es lo mismo un LCP malo (carga) que un CLS malo (diseño que salta) o un INP malo (JavaScript). Cada uno tiene causas distintas.
4. Mira la URL o el origen. PageSpeed enseña los datos de la página concreta si hay suficientes, y si no, los de todo el dominio. Una portada rápida no compensa unas fichas de producto lentas.
5. Baja al laboratorio para encontrar las causas. Los apartados de diagnóstico te dicen cuál es el elemento LCP, qué recursos bloquean el renderizado, qué scripts tardan más y qué elementos se mueven.
6. Ignora variaciones pequeñas de la nota. Cinco o diez puntos arriba o abajo entre dos pruebas es normal.

Qué arreglar primero

Este es el orden que mejor resultado nos da en webs WordPress. No es casualidad: cada paso hace que el siguiente se note más.

1. El tiempo de respuesta del servidor (TTFB)

Si el servidor tarda un segundo en empezar a contestar, ningún ajuste de imágenes te salvará. Mídelo desde la terminal:

curl -o /dev/null -s -w 'dns: %{time_namelookup}  conexión: %{time_connect}  tls: %{time_appconnect}  primer byte: %{time_starttransfer}  total: %{time_total}\n' https://tudominio.com/

Repítelo varias veces. Si el primer byte pasa de forma habitual de 0,8 segundos:

1. Activa una caché de página. En WordPress, es la mejora más grande que existe: en lugar de ejecutar PHP y consultar la base de datos en cada visita, se sirve una copia en HTML. Puede ser un plugin de caché o la caché del propio hosting, pero solo una.
2. Actualiza PHP a una versión con soporte. Las versiones antiguas son bastante más lentas y, además, inseguras.
3. Revisa los plugins que hacen trabajo en cada carga: estadísticas internas, registros de actividad, constructores de menús complejos.
4. Si nada de lo anterior basta, el problema es el hosting. Un hosting compartido saturado no se arregla desde WordPress.

Si la caché está funcionando, verás alguna cabecera que lo indica (depende del plugin o del servidor):

curl -sI https://tudominio.com/ | grep -iE 'cache|age|x-litespeed|cf-cache-status'

2. La imagen principal (LCP)

En la mayoría de webs el elemento LCP es la imagen de cabecera, un slider o una foto de producto. PageSpeed te dice cuál es en el diagnóstico de «elemento de Largest Contentful Paint».

1. Dale el tamaño justo. Una foto de 4000 píxeles para un hueco de 400 es el error más común. WordPress genera versiones reducidas; asegúrate de que el tema las usa.
2. Usa WebP o AVIF y una compresión razonable.
3. No la cargues en diferido. El lazy loading es perfecto para las imágenes de abajo y nefasto para la de arriba. WordPress ya intenta no aplicarlo a la primera imagen y marca la imagen principal con prioridad alta, pero algunos temas, constructores y plugins de optimización lo deshacen.
4. Dale prioridad si tu tema no lo hace:

<img src="/wp-content/uploads/portada-1200.webp" width="1200" height="600" fetchpriority="high" alt="Descripción de la imagen">

1. Desconfía de los sliders. Suelen cargar varias imágenes grandes y un JavaScript pesado antes de enseñar la primera. Una imagen fija suele convertir igual y carga mucho mejor.

3. El CSS y el JavaScript que bloquean

En «Eliminar recursos que bloquean el renderizado» (o el diagnóstico equivalente) verás ficheros CSS y JS que el navegador tiene que descargar antes de pintar nada.

• Quita lo que no se usa. Muchos plugins cargan sus estilos y scripts en todas las páginas aunque solo se usen en una (formularios, sliders, galerías). Hay plugins que permiten desactivarlos página a página.
• Difiere el JavaScript que no hace falta para pintar la página (atributo defer). Con cuidado: algunos scripts dependen del orden de carga.
• Fuentes: menos familias y pesos, servidas desde tu propio dominio y con font-display: swap. Cada peso de una fuente es un fichero más. Servirlas desde tu servidor también te ahorra enviar la IP de tus visitantes a terceros.

4. Los scripts de terceros

Chat, píxeles de publicidad, mapas, vídeos incrustados, widgets de reseñas, herramientas de mapas de calor. Cada uno descarga su propio JavaScript, y en móvil se nota mucho en el TBT y el INP.

• Haz inventario de lo que hay en el gestor de etiquetas y quita lo que nadie usa.
• Carga los vídeos de YouTube con una imagen de vista previa que solo carga el reproductor al pulsar.
• Carga el chat después de la interacción o tras unos segundos, no al principio.
• Respeta el consentimiento de cookies: lo que no se puede cargar sin permiso, tampoco debe frenar a quien no lo da.

5. Los saltos de diseño (CLS)

• Pon width y height en todas las imágenes, vídeos e iframes, para que el navegador reserve el hueco.
• Reserva espacio para lo que aparece después: banners de cookies que empujan el contenido, avisos en la parte superior, anuncios.
• Evita que las fuentes cambien mucho de tamaño al cargarse (elige fuentes de reserva parecidas).

6. La respuesta a la interacción (INP)

Si el INP real es malo, el problema es JavaScript que tarda demasiado en ejecutarse cuando el usuario toca algo. Los sospechosos habituales en WordPress son los constructores visuales con muchos widgets, los menús y filtros hechos con JavaScript pesado, y la suma de scripts de terceros. En WooCommerce, revisa también los scripts del carrito que se cargan en páginas donde no hacen falta.

Cómo medir bien (y comparar antes y después)

Una sola prueba de PageSpeed no demuestra nada. Para saber si un cambio ha servido:

1. Haz tres pruebas antes y tres después y compara la mediana, no la mejor.
2. Mide varias páginas: la portada, una página de servicio, una entrada del blog y, si es una tienda, una categoría y una ficha de producto.
3. Recuerda que los datos reales tardan en moverse: son de los últimos 28 días, así que una mejora de hoy no se verá del todo hasta dentro de unas semanas.
4. Vacía la caché después de cada cambio, o medirás la versión antigua.

Si quieres automatizarlo, la API de PageSpeed Insights devuelve lo mismo que la web en JSON. Sin clave tiene un límite bajo de consultas; para uso habitual, crea una clave en Google Cloud.

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://tudominio.com/&strategy=mobile&category=performance" |
  jq '{nota: (.lighthouseResult.categories.performance.score * 100),
       lcp: .lighthouseResult.audits["largest-contentful-paint"].displayValue,
       tbt: .lighthouseResult.audits["total-blocking-time"].displayValue,
       cls: .lighthouseResult.audits["cumulative-layout-shift"].displayValue,
       campo: .loadingExperience.overall_category}'

Y si prefieres medir desde tu equipo con Lighthouse, que es el mismo motor del laboratorio:

npx lighthouse https://tudominio.com/ --only-categories=performance --view

Ten en cuenta que en tu equipo los resultados dependen de tu procesador y tu conexión, así que compara siempre en las mismas condiciones.

Errores habituales

• Perseguir el 100. Pasar de 85 a 100 cuesta mucho y rara vez cambia nada para el visitante. Lo que importa es pasar las Core Web Vitals en datos reales.
• Mirar solo escritorio. Escritorio casi siempre sale bien. El problema está en el móvil.
• Instalar tres plugins de optimización a la vez. Se pisan entre ellos, duplican la caché y rompen cosas. Uno bien configurado es mejor que tres.
• Aplicar todas las opciones del plugin de optimización sin probar. Combinar y diferir todo el JavaScript rompe menús, formularios y carritos. Ve activando opciones de una en una y prueba la web después de cada una.
• Cargar en diferido la imagen principal. Empeora el LCP justo en la imagen que más importa.
• Convertir a WebP sin redimensionar. Una imagen de 4000 píxeles en WebP sigue siendo una imagen de 4000 píxeles.
• Medir solo la portada. Tus visitas de Google entran sobre todo por páginas interiores.
• Ignorar el servidor. Si el primer byte tarda un segundo y medio, el resto de optimizaciones apenas se notarán.

Y antes de dedicarle horas a la velocidad, confirma lo básico: que la web va por HTTPS (los navegadores solo usan HTTP/2 y HTTP/3 con HTTPS; mira cómo pasar tu web a HTTPS) y que Google puede indexarla (si WordPress no indexa, la velocidad es lo de menos). Si además el certificado da problemas, empieza por los errores de certificado SSL.

Para agencias: la velocidad de toda la cartera, de un vistazo

Revisar PageSpeed web a web, a mano, no escala. Y sin datos, es difícil explicarle al cliente por qué su web necesita trabajo.

El Radar de Jeffrey incluye la velocidad: mide PageSpeed en móvil y lo valora con la misma escala que Google (de 90 en adelante, bien; de 50 a 89, aviso; por debajo de 50, mal). En el apartado de disponibilidad, además, avisa cuando la web tarda más de 3 segundos en responder, que suele ser la primera pista de un servidor o una caché que no están haciendo su trabajo. Te sirve para saber qué clientes tienen margen de mejora y para enseñárselo con datos.

Preguntas frecuentes