Quieres saber si tu web carga bien. Pegas la dirección en PageSpeed Insights, esperas unos segundos y aparecen círculos de colores, siglas y una lista de recomendaciones bastante más larga de lo que habías pedido. Ahora tienes más información. Saber qué hacer con ella es el siguiente paso.
El informe resulta útil cuando entiendes qué está midiendo cada parte. Puede ayudarte a localizar una imagen que llega tarde, un menú que tarda en responder o un aviso que mueve media página. También puede llevarte a gastar una mañana persiguiendo un punto mientras el formulario sigue sin funcionar.
Cuando revisamos una web, usamos PageSpeed para conectar una medición con un problema concreto. Vamos a leerlo en ese orden, con un ejemplo real de nuestra propia página y sin exigir que aprendas desarrollo web antes del segundo apartado.
Qué es PageSpeed Insights y cómo analizar tu web
PageSpeed Insights es una herramienta gratuita de Google para analizar el rendimiento de una página. Combina una prueba de carga con datos de visitas reales cuando están disponibles y ofrece comprobaciones de accesibilidad, implementación técnica y SEO básico.
Para empezar, introduce la URL completa de una página, pulsa «Analizar» y espera el resultado. Puedes cambiar entre móvil y ordenador. No hace falta instalar un plugin ni una extensión para utilizarla.
Aquí conviene parar un momento. Si analizas la portada, has probado la portada. No has comprobado la categoría con cincuenta productos, la ficha con un vídeo o la página donde se solicita presupuesto. Aunque compartan diseño, pueden cargar recursos y comportarse de formas distintas.
Elegiríamos unas pocas páginas representativas del negocio. En una web de servicios, la portada, un servicio importante y el contacto; en una tienda, también una categoría y un producto. Para las zonas privadas o el pago harán falta otras comprobaciones. Una carga pública tampoco reproduce una compra completa ni un pico de visitas.
Guarda el enlace del informe y anota qué página, dispositivo y fecha estás viendo. Es el mínimo contexto para que un «mi web saca 63» se convierta en algo que podamos investigar.
Datos de campo y laboratorio en PageSpeed Insights
El primer bloque intenta mostrar lo que experimentan tus usuarios reales. Sus datos proceden de CrUX, el informe de experiencia de usuarios de Chrome, y resumen una ventana móvil de los últimos 28 días. Después aparece el diagnóstico de Lighthouse, una prueba ejecutada para analizar la página en unas condiciones concretas.
Los datos de campo ayudan a saber qué está pasando en las visitas recogidas. Los de laboratorio permiten investigar posibles causas y probar cambios. Son dos puntos de vista complementarios, como explica la documentación de Google sobre campo y laboratorio.
«Esta URL», «Origen» y «No hay datos»
Si hay datos reales, mira a qué corresponden. «Esta URL» se refiere a la página analizada. «Origen» reúne experiencias de páginas del mismo origen, por ejemplo https://tudominio.com. Un buen resultado del origen no demuestra que una ficha de producto concreta vaya igual de bien.
Cuando no hay suficientes muestras para una URL, PageSpeed puede mostrar los datos del origen. Si tampoco dispone de ellos, aparece «No hay datos». Eso no es un suspenso, ni significa que nadie visite la web. Significa que no hay información de campo suficiente disponible para esa evaluación.
En ese caso, el laboratorio sigue siendo útil. Complétalo con pruebas en dispositivos reales y, si necesitas seguir la experiencia con más detalle, con medición propia de usuarios. No deduzcas un aprobado de una sección vacía. Google explica estos requisitos y el uso del origen.
Qué significan LCP, INP, CLS y las demás métricas
Las tres Core Web Vitals describen la aparición del contenido principal, la respuesta a las interacciones y la estabilidad visual. No hace falta memorizar sus nombres en inglés para saber qué problema representa cada una.
| Métrica | Qué te ayuda a entender | Umbral bueno |
|---|---|---|
| LCP | Cuándo aparece el contenido principal | 2,5 segundos o menos |
| INP | Cuánto tarda en verse la respuesta a una interacción | 200 milisegundos o menos |
| CLS | Cuánto se desplaza el contenido de forma inesperada | 0,1 o menos |
En los datos de campo estos umbrales se valoran en el percentil 75. Dicho sin estadística de sobremesa, al menos tres de cada cuatro experiencias recogidas deben quedar dentro del umbral bueno de esa métrica. Aprobar no significa que todas las visitas hayan ido igual de bien. Puedes consultar las métricas que define Google.
El LCP puede ser una imagen grande o un bloque de texto. Si tarda, no basta con concluir «las fotos pesan mucho». Hay que identificar qué elemento es y en qué parte de la carga se retrasa.
El INP necesita interacciones. La prueba de carga habitual de PageSpeed no navega por todos tus menús ni envía tus formularios, así que no mide un INP representativo como el de los datos reales. En laboratorio encontrarás TBT, que suma bloqueos prolongados del navegador durante la carga. Ayuda a investigar problemas de respuesta, pero un TBT bueno no certifica un INP bueno.
También aparecen FCP, el primer contenido que se muestra, y Speed Index, que resume cómo progresa la aparición visual. Son pistas de diagnóstico. No hay que convertir cada sigla en una tarea independiente: varias pueden estar señalando el mismo retraso.
Qué puntuación de PageSpeed se considera buena
La puntuación de rendimiento de Lighthouse va de 0 a 100. De 90 a 100 es buena; de 50 a 89 necesita mejoras; de 0 a 49 es deficiente. Es un resumen calculado a partir de métricas de esa ejecución, no un porcentaje de calidad de toda la web.
Buscar un buen resultado tiene sentido. Perseguir el 100 sin mirar qué mejora para el visitante puede dejar de tenerlo. Tampoco hay un 85 universal a partir del cual podamos decir «ya está perfecto». Habrá que ver qué está pasando y a quién afecta. La explicación de la puntuación de Lighthouse ayuda a entender ese matiz.
Rendimiento, accesibilidad, prácticas recomendadas y SEO
Cada categoría responde a una pregunta distinta. Rendimiento analiza cómo carga la página en la prueba. Accesibilidad detecta problemas que puede comprobar automáticamente, como ciertos fallos de contraste o nombres de botones. Prácticas recomendadas revisa aspectos de implementación técnica. SEO comprueba requisitos básicos para buscadores.
Un 100 en SEO no significa que posiciones bien en Google. No evalúa por completo tu contenido, la competencia, la arquitectura o la utilidad de tus páginas. Para eso hay que mirar el trabajo de posicionar una web en Google con bastante más amplitud.
Del mismo modo, la accesibilidad exige pruebas manuales, incluso con una nota alta. En el informe usado en esta guía también aparece un bloque experimental de Navegación agéntica. Es una comprobación adicional, que puede cambiar, y no una garantía de que tu web aparezca en respuestas de IA.
Por qué PageSpeed puntúa peor en móvil y cambia entre pruebas
El análisis móvil usa condiciones de dispositivo y red diferentes de las de ordenador. Una página puede rendir bien con más potencia y mostrar sus limitaciones en la prueba móvil. No están midiendo la misma situación.
Por eso conviene revisar ambas vistas y consultar las condiciones que indica cada informe, en lugar de asumir que representan exactamente el móvil de tu cliente. La prueba móvil tampoco es el peor caso posible: habrá personas con dispositivos o conexiones mejores y peores.
Además, una ejecución puede cambiar por la respuesta del servidor, el estado de las cachés, los recursos externos o la variación de la propia prueba. Repite unas pocas veces la misma URL y dispositivo para reconocer una tendencia. Actualizar hasta que salga la nota que te gusta solo sirve para elegir una captura bonita.
Si el ordenador va bien y el móvil no, investiga esa diferencia. No la des por normal ni la interpretes automáticamente como una penalización de Google.
Cómo interpretar los avisos de PageSpeed y qué mejorar primero
Debajo de las métricas encontrarás estadísticas, diagnósticos y auditorías superadas. Los nombres cambian con las versiones, pero la tarea sigue siendo la misma: abrir el aviso, ver qué recurso señala y relacionarlo con una métrica o una función de la página.
Los ahorros que aparecen son estimaciones. No los sumes como si varias advertencias fueran descuentos independientes: pueden referirse a trabajo que se solapa. Tampoco todos los avisos tienen la misma importancia para tu caso.
En nuestra experiencia, el encargo mejora mucho cuando pasamos de «subir PageSpeed» a algo comprobable. Por ejemplo, «la imagen principal aparece tarde en móvil; vamos a localizar el retraso y medirlo después». Ya sabemos qué revisar y cómo reconocer una mejora.
Si tarda en aparecer el contenido principal
Mira el elemento LCP y su desglose. Si es una imagen, comprueba su tamaño, formato y cuándo empieza a descargarse. Un archivo ligero también puede llegar tarde si depende de otro recurso o se ha configurado con carga diferida. La imagen principal visible al abrir la página no debería esperar al lazy load, como advierte la guía de optimización de LCP.
Si el retraso empieza antes, en la respuesta del documento, revisa caché de página, ejecución del sitio y alojamiento. No hace falta cambiar de hosting cada vez que aparece un LCP alto. Sería como cambiar la cocina porque tarda el repartidor.
Si JavaScript o terceros frenan la página
Los menús, formularios, chats, vídeos y etiquetas pueden añadir descarga y trabajo al navegador. Revisa qué función cumple cada recurso y si debe cargarse ahí y en ese momento. Diferir código puede ayudar; retrasarlo todo indiscriminadamente puede romper justo la interacción que querías mejorar.
Esto nos lleva a una comprobación que no saltamos: abrir el menú, aceptar o rechazar cookies y probar el formulario después de optimizar. Una página que obtiene más puntos y deja de recibir solicitudes ha ganado un concurso bastante equivocado.
Si el contenido se mueve mientras lees
Revisa dimensiones de imágenes y vídeos, espacios reservados, fuentes y bloques que aparecen después. El salto del aviso de cookies también merece atención si desplaza el contenido. Que podamos cerrarlo no hace desaparecer la mala experiencia de quien iba a pulsar un botón. La guía de CLS de Google explica cómo evitar estos desplazamientos.
Si aparecen avisos de caché, fuentes o imágenes
Conviene distinguir dos cosas. La caché de página puede evitar que el servidor reconstruya el HTML en cada visita. La caché del navegador permite reutilizar archivos ya descargados. Un aviso sobre la duración de una imagen no demuestra por sí solo que falle la caché de toda la web.
Revisa qué archivos se repiten, su tamaño y quién los sirve. No puedes cambiar las cabeceras de un tercero como si fueran propias. Con las fuentes, comprueba que el texto aparezca y que el cambio de tipografía no desplace el diseño. Y con las imágenes, sirve tamaños adecuados además de comprimirlas. Si utilizas una CDN, nuestra guía para configurar Cloudflare en WordPress desarrolla esa parte.
El orden sale del problema observado. Una imagen desproporcionada pide una intervención distinta de un servidor lento o un filtro que bloquea el navegador. Activar todas las opciones de un plugin a la vez hace muy difícil saber qué ha mejorado y qué acabamos de estropear.
Un informe real de PageSpeed explicado con nuestra web
Para preparar esta guía analizamos la portada de Nereida el 20 de octubre de 2026, en la prueba móvil de PageSpeed. Puedes consultar el informe de esa ejecución. Dio 97 en rendimiento, un LCP de laboratorio de 2,4 segundos, TBT de 0 milisegundos y CLS de 0. En el bloque de usuarios reales apareció «No hay datos».
La lectura correcta es bastante concreta: la portada rindió bien en esas condiciones de laboratorio, y el informe no permite evaluar sus Core Web Vitals reales. No sería correcto escribir «el 97 demuestra que todos nuestros visitantes navegan rápido». Tampoco que un TBT de cero demuestra que cualquier interacción de la web responde al instante.
El propio informe aún señalaba recomendaciones de caché y recursos que bloquean el renderizado. Tener una nota alta no borra esas observaciones; toca revisar si aportan una mejora relevante. La captura sirve para entender el informe, no para sustituir el seguimiento de las visitas.
Cómo comprobar si una mejora de velocidad ha funcionado
Antes de tocar nada, guarda una referencia. Después cambia una cosa o un conjunto acotado de cambios, limpia las cachés que correspondan y repite las pruebas sobre las mismas páginas y el mismo dispositivo.
Compara la métrica que pretendías mejorar y prueba la función afectada. Si optimizaste la imagen principal, comprueba su aparición. Si retrasaste JavaScript, prueba los controles. Si ajustaste fuentes, revisa la lectura y los saltos en distintos anchos. Conviene que exista una copia recuperable antes de hacer cambios delicados.
No esperes que los datos reales cambien al pulsar otra vez «Analizar». Su ventana incluye visitas anteriores al ajuste y se irá renovando. Mientras tanto, el laboratorio ayuda a comprobar el efecto inmediato bajo condiciones comparables. Si tienes medición propia de usuarios, podrás contrastar también lo que ocurre después del cambio.
Y mantén la perspectiva. Google utiliza Core Web Vitals en sus sistemas de posicionamiento, pero un buen resultado no garantiza primeras posiciones, como aclara en su documentación sobre experiencia de página. Mejorar la carga es una parte del trabajo, junto con ofrecer una web útil, comprensible y que funcione.
Cuándo pedir ayuda para mejorar tu PageSpeed
Si el informe identifica una imagen enorme y sabes sustituirla correctamente, puedes empezar por ahí. Si señala código, servidor o un comportamiento que no entiendes, lo útil es pedir un diagnóstico que concrete qué se va a cambiar y cómo se comprobará.
Envíanos el enlace del informe, las páginas donde notas el problema y qué hace la web cuando falla. Con eso podemos revisar la carga y las interacciones dentro de nuestro servicio de mantenimiento web, priorizar las correcciones y comprobar el resultado.
Ese es el trabajo que interesa: que la página aparezca antes, responda mejor y se deje usar. El círculo de colores ayuda a orientarnos. La comprobación termina en la web.
Escrito en Nereida Studio, estudio de diseño web y posicionamiento en Valencia. Así trabajamos.
