Guía práctica de auditoría PageSpeed: cómo medir, interpretar y priorizar

Una auditoría PageSpeed no es magia ni un número para presumir en LinkedIn: es el proceso de medir qué tan rápida y estable se siente tu web, interpretar el informe y decidir qué optimizar primero. Si solo miras el puntaje verde o rojo sin contexto, acabarás cambiando el hosting o instalando plugins al azar.

Esta guía es práctica — centrada en PageSpeed Insights, Lighthouse y los datos de campo de Google — y encaja como capítulo de rendimiento dentro de una auditoría SEO técnica más amplia. No sustituye revisar indexación ni enlaces; complementa el paso de Core Web Vitals.

Índice

• Qué es una auditoría PageSpeed
• PageSpeed vs auditoría SEO completa
• Herramientas que usarás
• Datos de laboratorio vs datos de campo
• Pasos de la auditoría (workflow)
• Cómo leer LCP, INP y CLS en el informe
• Qué arreglar primero
• Errores habituales
• Preguntas frecuentes

Qué es una auditoría PageSpeed

Es un diagnóstico enfocado en rendimiento percibido y métricas de experiencia: tiempo hasta que el contenido principal es visible (LCP), respuesta a interacciones (INP) y estabilidad del layout (CLS). Google expone gran parte de esto en PageSpeed Insights y en Search Console bajo Core Web Vitals.

El objetivo no es “llegar a 100” en Lighthouse, sino:

• Identificar plantillas problemáticas (home, categorías, fichas de producto, landings).
• Separar problemas de servidor, frontend, imágenes y terceros.
• Priorizar cambios con impacto en usuarios reales y, como efecto secundario, en SEO.

Si aún no dominas qué significan las siglas, repasa Core Web Vitals: qué son y qué medir antes de profundizar en la auditoría.

PageSpeed vs auditoría SEO completa

Auditoría PageSpeed	Auditoría SEO técnica completa
Velocidad, CWV, recursos bloqueantes, peso de página	Indexación, canonicals, sitemap, arquitectura, schema, enlaces
Horas a pocos días por plantilla clave	Días a semanas según tamaño del sitio
Ideal tras rediseño, pico de rebote o antes de campañas de pago	Ideal antes de migraciones y de escalar contenido o link building

Puedes hacer una auditoría PageSpeed solo cuando el tráfico cae en móvil o Search Console marca URLs en rojo en Experiencia. Si además hay páginas “Descubierta — sin indexar”, arregla rastreo primero.

Herramientas que usarás

• PageSpeed Insights (PSI): URL pública, mezcla datos de campo (CrUX, si hay volumen) y prueba de laboratorio (Lighthouse).
• Lighthouse en Chrome DevTools: repetible en local o staging; útil para comparar antes/después de un cambio.
• Google Search Console: informe Core Web Vitals por grupos de URLs — visión agregada de usuarios Chrome.
• WebPageTest o similar (opcional): waterfall detallado, múltiples ubicaciones y conexiones simuladas.

Para el día a día del desarrollador, combina PSI con la guía de DevTools para SEO: pestaña Network, Coverage y Performance complementan lo que PSI resume.

Datos de laboratorio vs datos de campo

Laboratorio: simulación controlada (dispositivo, red, ubicación del servidor de prueba). Reproducible. Perfecto para depurar tras un deploy.

Campo: mediciones anonimizadas de usuarios reales (Chrome User Experience Report). Refleja dispositivos, redes y caches reales. Es lo que Search Console usa para clasificar URLs en bueno / mejorable / malo.

Regla práctica: no celebres un 98 en Lighthouse si GSC sigue mostrando LCP malo en la misma plantilla. Repite la medición en móvil, en 4G simulado y en la URL exacta que rankea.

Pasos de la auditoría (workflow)

1. Elige 5–10 URLs: home, landing principal, artículo de blog con tráfico, plantilla de listado y una URL “problemática” que ya conozcas.
2. Define el dispositivo: empieza por móvil; desktop solo si tu negocio es B2B muy orientado a escritorio.
3. Ejecuta PSI para cada URL; captura pantalla o exporta oportunidades principales.
4. Anota las tres CWV (campo si hay datos; si no, laboratorio) y el elemento LCP que PSI destaca.
5. Agrupa por plantilla: si diez productos fallan igual, el fix es la plantilla — no diez tickets sueltos.
6. Lista oportunidades en tres buckets: imágenes, JavaScript/CSS, servidor/red (TTFB, caché, CDN).
7. Implementa 1–2 cambios de alto impacto; vuelve a medir la misma URL en las mismas condiciones.
8. Documenta URL, fecha, puntuación/métricas y cambio aplicado — imprescindible si trabajas con agencia o dev externo.

Cómo leer LCP, INP y CLS en el informe

LCP (carga)

PSI indica qué elemento fue el “contenido principal” (hero, imagen, bloque de texto). Pregunta: ¿es una imagen enorme? ¿Un slider? ¿El servidor tardó en responder? Las oportunidades “Mejorar entrega de imágenes” o “Reduce el tiempo de respuesta del servidor” suelen apuntar aquí.

INP (interactividad)

Relevante en menús, filtros, carritos y SPAs. Si INP falla con poco JavaScript visible, sospecha de scripts de terceros (chat, tags, A/B testing) que bloquean el hilo principal.

CLS (estabilidad)

Busca imágenes sin dimensiones, banners que se insertan tarde y fuentes que cambian el layout. PSI a veces lista “elementos que provocaron el mayor cambio de diseño”.

Lighthouse también muestra categorías (Performance, Accessibility, Best Practices, SEO). Para una auditoría PageSpeed orientada a negocio, Performance + CWV van primero; el resto ayuda pero no sustituye arreglar LCP en la landing que convierte.

Qué arreglar primero

Señal	Acciones típicas (sin entrar en stack concreto)
TTFB alto	Caché HTML, CDN, hosting más cercano al usuario, reducir trabajo en el origen
LCP = imagen hero	Compresión, tamaño responsive, preload prudente, evitar carruseles pesados above the fold
JS bloqueante	Retrasar scripts no críticos, dividir bundles, revisar plugins que inyectan scripts globales
CLS	Reservar espacio para media y anuncios; evitar insertar barras encima del contenido principal
INP	Reducir listeners pesados, optimizar handlers, limitar widgets de terceros en páginas clave

Orden sugerido en la mayoría de sitios corporativos y blogs: servidor/caché → imágenes LCP → scripts terceros → CLS → refinamiento INP. E-commerce y marketplaces a veces invierten INP y LCP por la complejidad del carrito.

Errores habituales

• Auditar solo la home mientras el tráfico orgánico entra por entradas de blog o categorías lentas.
• Optimizar desktop ignorando que Google evalúa mobile-first.
• Confundir puntaje Lighthouse con ranking — ayuda, pero no es un interruptor de posiciones.
• Instalar un plugin “PageSpeed” que minifica sin medir: a veces empeora INP o rompe funcionalidad.
• No repetir la medición tras el cambio, o hacerlo en condiciones distintas (otra red, otra extensión del navegador).
• Ignorar datos de campo cuando ya tienes volumen suficiente en GSC.

Preguntas frecuentes

¿Cuánto dura una auditoría PageSpeed básica?

Para 5–10 URLs y un informe priorizado, cuenta medio día de análisis y otra media jornada si incluyes reuniones con desarrollo. Implementar las mejoras depende del equipo — de horas a varias semanas.

¿PageSpeed Insights es gratis?

Sí. Lighthouse en Chrome también. Search Console es gratuita con verificación de dominio. Herramientas avanzadas de waterfall pueden ser de pago pero no son obligatorias para empezar.

¿Qué puntuación PageSpeed necesito para rankear?

No hay umbral público único. Google trabaja con rangos de Core Web Vitals y experiencia general. Apunta a “bueno” en campo en tus plantillas principales, no a un número redondo en laboratorio.

¿Auditoría PageSpeed en staging o solo producción?

Producción refleja CDN, caché real y terceros. Staging sirve para probar fixes antes de desplegar, pero compara siempre la URL pública final tras el release.

¿Con qué frecuencia repetirla?

Tras cada cambio grande de diseño, plugins o scripts. En operación normal, revisión mensual o trimestral de las mismas URLs “canario” más el informe CWV de Search Console.