Por Francisco Severiche · 15 de mayo de 2026 · 3 min de lecturaPageSpeed Insights es la herramienta gratuita de Google que combina datos de Lighthouse (lab) y CrUX (campo) para diagnosticar la performance de una URL. Es el primer reporte que casi todo SEO mira tras un cambio. Esta guía explica cómo interpretarlo correctamente, qué métricas priorizar y cómo traducir las recomendaciones en acciones reales.
Tabla de contenidos
Las dos secciones del reporte
- Datos de campo (CrUX): datos reales de usuarios Chrome durante los últimos 28 días. Es lo que Google usa para evaluar ranking. La sección que más importa.
- Datos de Lighthouse (lab): simulación sintética en un entorno controlado. Útil para diagnosticar, no para “aprobar”.
Si el lab marca 95 pero el campo marca rojo, gana el campo. Optimiza para campo, usa el lab para entender por qué.
Las métricas core
- LCP (Largest Contentful Paint): velocidad de pintar el elemento principal. Bueno ≤2.5 s.
- INP (Interaction to Next Paint): respuesta a interacciones. Bueno ≤200 ms.
- CLS (Cumulative Layout Shift): inestabilidad visual. Bueno ≤0.1.
- FCP (First Contentful Paint): primer contenido pintado. Bueno ≤1.8 s.
- TTFB (Time To First Byte): respuesta del servidor. Bueno ≤800 ms.
Las tres primeras (LCP, INP, CLS) son los Core Web Vitals oficiales y factor de ranking. Las otras dos son diagnósticas.
El “score” de Lighthouse
Es el número grande de 0-100 que ves arriba. Composición ponderada (2026):
- FCP — 10%
- LCP — 25%
- Speed Index — 10%
- TBT (Total Blocking Time, proxy de INP en lab) — 30%
- CLS — 25%
Un score de 90+ es “Bueno”, 50-89 “A mejorar”, <50 “Malo”. Pero recuerda: es score lab, no CrUX.
Cómo leer las “oportunidades”
Lighthouse lista oportunidades ordenadas por impacto. Las que más se ven:
- Eliminar recursos que bloquean el renderizado: CSS y JS síncronos en el head. Solución: critical CSS inline + defer en JS.
- Aplazar imágenes fuera de pantalla: lazy loading. Activado por defecto en WP desde 5.5.
- Servir imágenes en formatos modernos: WebP/AVIF en lugar de JPG/PNG.
- Tamaño correcto de imagen: no servir 2000px cuando se muestra a 800px.
- Habilitar compresión de texto: gzip o brotli para HTML/CSS/JS.
- Reducir JavaScript no utilizado: code splitting, eliminar bibliotecas innecesarias.
- Reducir CSS no utilizado: purge CSS con herramientas tipo PurgeCSS.
- Precargar peticiones clave: preload fonts, LCP image.
Diagnósticos vs oportunidades
- Oportunidades: cambios que reducirían tiempo de carga estimado.
- Diagnósticos: información sobre el estado actual (peso del DOM, tareas largas, scripts de terceros, etc.). Ayudan a entender el contexto.
No persigas todas las recomendaciones a la vez. Prioriza las que mueven LCP / INP / CLS reales.
Errores de interpretación frecuentes
- “Mi PageSpeed bajó de 95 a 75 — desastre”. Si el campo CrUX sigue verde, no hay desastre. El score lab fluctúa.
- “Tengo que llegar a 100”. Casi imposible en sitios reales con anuncios o ad-tech. 90+ está perfecto.
- “Cambié 5 cosas a la vez y mejoró”. No sabes cuál de las 5 funcionó. Cambia una variable a la vez.
- “No tengo datos de campo”. Ocurre si la URL tiene poco tráfico. Mejora basado en lab + recomendaciones genéricas mientras acumula datos.
Mobile vs Desktop
PageSpeed mide ambos por defecto. Mobile es el que Google usa para ranking (mobile-first indexing). Desktop suele tener mejor score por hardware más potente. Trabaja primero mobile.
Cómo mejorar paso a paso
- Identifica la métrica más roja (LCP/INP/CLS).
- Mira las oportunidades específicas para esa métrica.
- Implementa la oportunidad con mayor “estimated savings”.
- Espera 28 días para confirmar mejora en CrUX.
- Repite con la siguiente métrica.
Cuando PageSpeed Insights miente
- Si tu CDN o WAF detecta el test como bot y entrega versión simplificada: score artificialmente alto.
- Si tu A/B testing tiene variantes muy distintas: score depende de cuál sirvió.
- Si tu site requiere login: el test solo ve la home pública.
En estos casos, complementa con Chrome DevTools manual y RUM propio.
Herramientas complementarias
- web.dev/measure: similar a PSI, con consejos contextuales.
- GTmetrix: alternativa con waterfall detallado.
- WebPageTest: el más potente para testing avanzado (ubicación específica, condiciones de red).
- Chrome DevTools Performance: análisis frame-by-frame en tu propio navegador.
Lectura relacionada
Profundiza con Core Web Vitals, SEO técnico WordPress, auditoría SEO. Para diagnóstico personalizado, diagnóstico SEO gratis.
¿Por qué mi score varía entre tests?
Lighthouse simula con cierta variabilidad. Diferencias de ±5 puntos son normales. Si varía ±20 puntos hay problema real (third-party scripts variables, A/B testing, caché frío).
¿Score lab importa para ranking?
No directamente. Google usa CrUX para ranking. El score lab es indicador.
¿Cuál es un score “aprobado” en 2026?
Mobile lab: 70+ es decente, 90+ es excelente. Desktop: 90+ debería ser estándar. Pero lo que importa es campo (CrUX) en verde para LCP, INP, CLS.
¿Los scripts de terceros bajan mucho mi score?
Sí. Google Analytics, Tag Manager, ads, chat widgets, A/B tools. Audita y elimina lo que no aporta. Carga el resto con defer/async.
¿WordPress puede llegar a 100?
Sí pero raramente conviene. Llegar a 95+ es objetivo razonable; ir a 100 implica sacrificar features (sin ads, sin tracking, sin terceros).
¿Servir imágenes desde CDN es suficiente?
Ayuda con LCP de imágenes. No resuelve INP (JavaScript) ni CLS (layout). CDN es parte de la solución, no la solución entera.
Por Polemicus — agencia SEO en Colombia. Actualizado mayo 2026.