PageSpeed Insights: cómo leer el informe y qué arreglar primero

PageSpeed Insights es la herramienta gratuita de Google que mide la velocidad de una página con dos fuentes: datos de usuarios reales de Chrome de los últimos 28 días y una prueba de laboratorio con Lighthouse. Los datos reales dicen si apruebas las Core Web Vitals; el laboratorio, con su nota de 0 a 100, sirve para encontrar qué arreglar.

Para comprobarlo en tu web: Auditoría SEO

La velocidad es una parte del posicionamiento web, y PageSpeed Insights es la forma más directa de medirla. El problema es que su informe mezcla en una sola pantalla datos de origen, periodo y propósito distintos. Esta guía lo recorre de arriba abajo, en el orden en que conviene leerlo.

¿Qué mide PageSpeed Insights?

PageSpeed Insights (PSI) es un servicio de Google que informa sobre la experiencia de usuario de una página en móvil y en ordenador, y da sugerencias para mejorarla1. Al introducir una URL, devuelve dos bloques:

Debajo, Lighthouse añade otras tres categorías: accesibilidad, buenas prácticas y SEO. Son útiles, pero no tienen nada que ver con la velocidad ni con las Core Web Vitals.

Cómo leer los datos de usuarios reales

Es el bloque de arriba y el que importa para decidir. Muestra las tres Core Web Vitals (LCP, INP y CLS) y dos métricas de apoyo: FCP (First Contentful Paint, cuándo se pinta lo primero) y TTFB (Time to First Byte, cuándo empieza a responder el servidor)1. Cada métrica lleva su valor en el percentil 75 y una barra con el reparto de visitas en bueno, necesita mejorar y malo.

Encima aparece el veredicto: la evaluación de Core Web Vitals se aprueba si el percentil 75 de LCP, INP y CLS es «bueno». Si no hay datos suficientes de INP, basta con LCP y CLS1. Los umbrales de cada métrica y cómo se diagnostican están en la guía de Core Web Vitals.

Fíjate en las dos pestañas, una para la URL y otra para el origen:

• La URL son los datos de esa página exacta. Solo aparecen si tiene visitas suficientes.
• El origen es el agregado de todas las páginas del dominio. Si la URL no tiene datos propios, PSI recurre a él; si tampoco hay datos del origen, el bloque sale vacío1.

Esto explica una confusión frecuente: dos páginas distintas con datos de campo idénticos. No es un error, es que ambas muestran el origen. Y si el bloque sale vacío, CrUX no tiene visitas suficientes para tu web, porque solo incluye páginas públicas con un mínimo de visitantes que Google no publica2.

Cómo leer el diagnóstico de laboratorio

El bloque de abajo es una carga simulada. En móvil, Lighthouse emula un dispositivo de gama media con una red móvil ralentizada; en ordenador, un equipo con conexión por cable. La prueba se lanza desde centros de datos de Google en Norteamérica, Europa o Asia1.

Muestra cinco métricas de laboratorio: FCP, LCP, TBT (Total Blocking Time, cuánto tiempo estuvo el hilo principal bloqueado), CLS y Speed Index (lo rápido que se rellena visualmente la pantalla). Falta INP, porque en una carga simulada nadie hace clic; TBT es la aproximación que usa Lighthouse3.

Que el LCP del laboratorio y el de campo no coincidan es normal. Web.dev lo atribuye a la caché, a los dispositivos y redes reales de cada usuario, al contenido personalizado y a las páginas que el navegador recupera al instante al volver atrás. Su consejo: priorizar con los datos de campo y usar el laboratorio para encontrar la causa4.

¿Qué significa la nota de rendimiento?

La nota de rendimiento es una media ponderada de cinco métricas de laboratorio, convertida a una escala de 0 a 1005. Cada métrica se puntúa según dónde cae frente a las webs reales del HTTP Archive, y después se pondera:

Son los pesos que publica Lighthouse desde su versión 105; Lighthouse 13 no cambió el cálculo de la nota6. Los colores son de 90 a 100 bueno, de 50 a 89 necesita mejorar y de 0 a 49 malo1.

Dos conclusiones prácticas. La primera: casi un tercio de la nota depende de TBT, que no es una Core Web Vital. La segunda: la nota y la evaluación de Core Web Vitals son cosas distintas. Puedes tener un 60 y aprobar en datos de campo, o un 95 y suspender. Google recuerda que un buen resultado en el informe de Search Console o en herramientas de terceros no garantiza salir arriba7.

¿Por qué la nota cambia en cada ejecución?

Porque cada prueba de laboratorio es una carga nueva, en condiciones que nunca son idénticas. PSI cita la disponibilidad de la red, del hardware del equipo que mide y la competencia por recursos1. Lighthouse añade causas que dependen de tu página: pruebas A/B, anuncios que cambian en cada carga o rutas de tráfico distintas5.

Una variación de unos pocos puntos entre dos pruebas no significa que algo haya cambiado. Para comparar el antes y el después de un arreglo, repite la prueba varias veces y quédate con la mediana: según la documentación de Lighthouse, la mediana de cinco ejecuciones es el doble de estable que una sola8.

Insights y diagnósticos: cómo se llaman hoy

Lighthouse reorganizó sus recomendaciones de rendimiento en 2025. Las antiguas auditorías («oportunidades») se agruparon en insights, las mismas que muestra el panel Rendimiento de las herramientas para desarrolladores de Chrome9. Lighthouse 13, publicado el 10-10-2025, retiró del informe las auditorías antiguas, y Chrome lo anunció para PageSpeed Insights en la semana siguiente6. Si una guía te manda buscar «Serve images in next-gen formats» o «Eliminate render-blocking resources», está escrita para la versión anterior.

Las insights no suman ni restan puntos por sí mismas: Lighthouse 13 solo cambió auditorías que no puntúan6. Lo que hacen es explicar por qué una métrica sale mal. Estas son las que más se ven, con su nombre en inglés tal como lo documenta Chrome (PSI las traduce si lo usas en castellano)10:

Debajo de las insights quedan los diagnósticos, auditorías que no se convirtieron en insights, como el trabajo del hilo principal o el JavaScript sin usar. Usa el filtro de auditorías por métrica que hay sobre la lista y elige la que te falla: el informe se reduce a lo que la afecta.

Móvil frente a escritorio: ¿cuál miro?

Empieza por móvil. Google usa la versión móvil del contenido de una web, rastreada con su agente de smartphone, para indexarla y clasificarla11. Además, la prueba de laboratorio en móvil es más exigente por diseño, con un dispositivo y una red ralentizados1.

Pero no te saltes escritorio: los datos de campo son independientes por dispositivo, y Search Console puede marcar una URL como buena en móvil y mejorable en ordenador12. Lee cada pestaña por separado.

¿Qué arreglar primero?

Este es el orden que evita trabajar en lo que no mueve nada:

1. Mira el veredicto de campo en móvil. Si apruebas, la velocidad no es tu cuello de botella; no persigas el 100 de laboratorio.
2. Si suspendes, localiza la métrica que falla en el bloque de datos reales: LCP, INP o CLS.
3. Filtra las auditorías por esa métrica y empieza por la insight que más tiempo o más desplazamiento atribuye.
4. Prioriza los arreglos de plantilla. Quitar la carga diferida de la imagen principal o poner dimensiones a las imágenes se hace una vez y llega a todas las páginas que la usan. Lo de las imágenes está en cómo optimizar las imágenes de una web.
5. Comprueba en el laboratorio con la mediana de varias pruebas, y confirma en el campo al cabo de 28 días.

Las otras tres categorías de Lighthouse (accesibilidad, buenas prácticas, SEO) se revisan aparte, dentro de una auditoría SEO completa.

PageSpeed Insights y SmoothSeen

Declaración de interés: este blog es de SmoothSeen, una herramienta de auditoría web que mide el posicionamiento en buscadores y en asistentes de IA. SmoothSeen toma la velocidad de PageSpeed Insights, tanto los datos de usuarios reales como los de laboratorio. Lo que ves en su informe es, por tanto, lo mismo que verías en PageSpeed, con la única diferencia de la variación normal entre dos pruebas de laboratorio. Lo junta con el resto de comprobaciones de Posicionamiento web, lo compara con tus competidores y lo ordena en un plan de acción.

Preguntas frecuentes

¿Una nota baja en PageSpeed Insights me hace perder posiciones?

No directamente. La nota de 0 a 100 sale de una prueba de laboratorio; lo que Google dice usar en sus sistemas de clasificación son las Core Web Vitals, que se evalúan con datos de usuarios reales. Además, Google insiste en que siempre intenta mostrar el contenido más relevante aunque la experiencia sea mediocre. Una nota baja sí indica problemas que probablemente notan tus visitas.

¿Por qué PageSpeed Insights no muestra datos de usuarios reales de mi web?

Porque CrUX solo incluye páginas públicas e indexables con un mínimo de visitas, cifra que Google no publica, y solo recoge datos de Chrome en ordenador y en Android. Si la URL no llega, PSI muestra los datos del origen; si el dominio tampoco llega, solo verás el laboratorio. Es habitual en webs nuevas o con poco tráfico.

¿Qué es más importante, móvil o escritorio?

Móvil, en casi todos los casos. Google indexa y clasifica con la versión móvil de tu web, y la prueba de laboratorio en móvil simula un dispositivo y una red más lentos, así que destapa problemas que en escritorio no se ven. Revisa los dos, pero arregla primero lo que falla en móvil, salvo que tus estadísticas digan que casi todas tus visitas llegan desde ordenador.

¿Dónde están las «oportunidades» que veía antes en el informe?

Desde Lighthouse 13, publicado en octubre de 2025, las antiguas oportunidades y buena parte de los diagnósticos se agruparon en insights, como Improve image delivery o Render-blocking requests. Son las mismas que muestra el panel Rendimiento de Chrome. El cálculo de la nota no cambió: solo cambió cómo se presentan las recomendaciones.

Qué hacer ahora

Pasa tu página principal por PageSpeed Insights en móvil, anota si apruebas en datos reales y, si no, qué métrica falla. Filtra las auditorías por esa métrica y arregla primero lo que se resuelve en la plantilla. Para ver cómo encaja la velocidad con el resto, sigue con la guía de posicionamiento web.