PageSpeed Insights explicado: qué significa cada puntuación y cómo mejorarla
PageSpeed Insights explicado
PageSpeed Insights explicado: puntuaciones, métricas y soluciones | We.Inc
Qué significa cada número de PageSpeed Insights, datos de campo frente a datos de laboratorio, umbrales de LCP, INP, CLS, FCP y TTFB, pesos de la puntuación y código que corrige los resultados en rojo.
PageSpeed Insights muestra dos informes. El de arriba son datos de campo de visitantes reales de Chrome en los últimos 28 días, evaluados en el percentil 75. El de abajo es una prueba de laboratorio de Lighthouse con una puntuación de 0 a 100: 90 o más es buena, de 50 a 89 necesita mejorar y menos de 50 es mala. Corrige primero las métricas de campo.
Umbrales de las métricas de campo que usa PageSpeed Insights
Métrica
Buena
Necesita mejorar
Mala
LCP (Largest Contentful Paint)
2.5 s o menos
de 2.5 a 4 s
más de 4 s
INP (Interaction to Next Paint)
200 ms o menos
de 200 a 500 ms
más de 500 ms
CLS (Cumulative Layout Shift)
0.1 o menos
de 0.1 a 0.25
más de 0.25
FCP (First Contentful Paint)
1.8 s o menos
de 1.8 a 3 s
más de 3 s
TTFB (experimental)
0.8 s o menos
de 0.8 a 1.8 s
más de 1.8 s
Casi todo el mundo se fija en la gran puntuación circular, pero ese número sale de una sola visita simulada en un teléfono con la conexión limitada. Esta guía separa las dos mitades del informe, te permite evaluar tus propios números frente a los umbrales oficiales y relaciona cada métrica en rojo con el cambio que normalmente la mejora.
Analiza tu URL en pagespeed.web.dev y mira primero el bloque de datos de campo. Si dice que no hay suficientes datos, solo está disponible la prueba de laboratorio.
Escribe tus valores de LCP, INP, CLS, FCP y TTFB en el evaluador de abajo para ver en qué franja cae cada uno.
Abre la sección de soluciones de la peor métrica y aplica el cambio de código correspondiente.
Espera a los nuevos datos de campo. El informe de usuarios reales abarca 28 días móviles, así que las mejoras aparecen poco a poco y no a la mañana siguiente.
La prueba de laboratorio móvil se ejecuta en un teléfono de gama media emulado con una red lenta, así que es normal que la puntuación móvil sea más baja que la de escritorio.
Las puntuaciones de laboratorio varían unos puntos entre ejecuciones. Lanza la prueba tres veces y fíjate en el resultado intermedio antes de concluir que algo cambió.
La prueba de laboratorio no puede medir INP porque nadie hace clic en nada. Total Blocking Time es su sustituto, así que un TBT alto suele anticipar un INP malo.
Las etiquetas de terceros, como widgets de chat, mapas de calor y scripts de anuncios, suelen costar más que tu propio código. Revisa la lista de solicitudes de terceros antes de reescribir tu aplicación.
Preguntas frecuentes
¿Por qué mis datos de campo y mi puntuación de laboratorio son tan distintos?
Miden cosas diferentes. Los datos de campo reflejan lo que vivieron usuarios reales de Chrome, con sus propios dispositivos y redes, durante 28 días. La puntuación de laboratorio es una sola carga simulada con una limitación fija. Una página puede sacar 60 en laboratorio y aun así superar las Core Web Vitals en campo, o al revés.
¿La puntuación de Lighthouse afecta al posicionamiento en Google?
Google describe las Core Web Vitals como medidas de la experiencia real de los usuarios alineadas con lo que premian sus sistemas principales de clasificación. Sus pautas de Search no mencionan la puntuación de laboratorio de 0 a 100 como factor de posicionamiento, así que trátala como un diagnóstico para encontrar problemas.
¿Qué es TTFB y cuál es un buen valor?
Time to First Byte es el tiempo que espera el navegador hasta que llega el primer byte del HTML, incluidas las redirecciones, el DNS, el establecimiento de la conexión y el trabajo del servidor. PageSpeed Insights considera bueno 800 ms o menos. Guardar en caché el HTML en el borde de una CDN es la solución más habitual.
¿Cómo se calcula la puntuación de rendimiento de Lighthouse?
Desde Lighthouse 10 es una combinación ponderada de cinco métricas de laboratorio: Total Blocking Time 30 por ciento, LCP 25 por ciento, CLS 25 por ciento, FCP 10 por ciento y Speed Index 10 por ciento. Cada métrica se convierte primero en una subpuntuación de 0 a 100 según una curva.
¿Por qué dice que no hay datos de campo para mi sitio?
El Chrome User Experience Report solo publica datos de páginas y orígenes con suficientes visitas válidas. Los sitios nuevos o con poco tráfico a menudo no tienen ninguno, así que apóyate en la prueba de laboratorio y en tu propia monitorización hasta que crezca el tráfico.
Lee el informe de arriba abajo
El primer bloque responde si los visitantes reales tuvieron una buena experiencia. Muestra el valor del percentil 75 de cada métrica, lo que significa que tres de cada cuatro visitas fueron al menos así de rápidas. El objetivo es superar las tres Core Web Vitals (LCP, INP y CLS).
El segundo bloque es una sola ejecución de Lighthouse. Sus diagnósticos y oportunidades son donde descubres por qué una métrica de campo es lenta, porque la traza de laboratorio enumera los archivos, imágenes y scripts concretos implicados.
Un ejemplo de antes y después
Imagina la página de inicio típica de una pequeña empresa con una foto principal a todo el ancho cargada en diferido, una fuente web sin estrategia de respaldo y tres etiquetas de marketing en el head. En este ejemplo, la imagen LCP solo empieza a descargarse cuando termina el script, así que el LCP cae en la franja mala.
Quitar loading=lazy de la imagen principal, añadir fetchpriority=high, servir la foto en AVIF o WebP al tamaño mostrado y hacer que las etiquetas carguen cuando la página ya es interactiva ataca cada subparte del LCP. Esos son los cambios que muestra el código de abajo; tus números dependerán de tu página.
Dónde suele fallar cada métrica
El LCP se divide en cuatro partes: tiempo hasta el primer byte, retraso de carga del recurso, duración de carga del recurso y retraso de renderizado del elemento. Localiza primero la parte más grande y corrige esa.
El INP depende de tareas largas de JavaScript que se ejecutan cuando alguien toca o escribe. El CLS viene de elementos que cambian de tamaño tras el primer pintado: imágenes sin dimensiones, banners que llegan tarde y fuentes que se cambian por otra de distinto ancho.
Cómo se pondera la puntuación de laboratorio
Desde Lighthouse 10 se combinan cinco métricas de laboratorio. Total Blocking Time es la que más pesa, así que el JavaScript pesado perjudica la puntuación más que cualquier otra cosa.
Pesos de la puntuación de rendimiento de Lighthouse
Métrica de laboratorio
Peso
Métrica de campo relacionada
Total Blocking Time
INP
Largest Contentful Paint
LCP
Cumulative Layout Shift
CLS
First Contentful Paint
FCP
Speed Index
Ninguna directamente
Auditorías habituales y la solución de cada una
Qué te dice una auditoría en rojo
Auditoría o síntoma
Por qué está en rojo
Solución habitual
La imagen del Largest Contentful Paint se cargó en diferido
El navegador espera al diseño antes de pedir la imagen principal
Quita loading=lazy de la imagen principal y añade fetchpriority=high
Elimina los recursos que bloquean el renderizado
El CSS o los scripts síncronos del head retrasan el primer pintado
Inserta en línea el CSS crítico y aplaza los scripts
Ajusta el tamaño de las imágenes
Las imágenes son más grandes que su tamaño mostrado
Usa srcset y sizes, exporta al ancho de visualización
Sirve imágenes en formatos modernos
JPEG o PNG donde AVIF o WebP ocuparían menos
Convierte y sirve con picture o una CDN de imágenes
Reduce el JavaScript sin usar
Código enviado para funciones que no están en esta página
Divide los paquetes por ruta y elimina librerías sin uso
Reduce el impacto del código de terceros
Las etiquetas bloquean el hilo principal
Carga las etiquetas tras la interacción o en reposo
Los elementos de imagen no tienen width y height explícitos
No se reserva espacio, así que el contenido salta
Define width y height o aspect-ratio
Asegúrate de que el texto siga visible mientras se carga la fuente web
El texto se oculta mientras se descarga la fuente
Usa font-display: swap y precarga la fuente principal
El tiempo de respuesta inicial del servidor fue largo
TTFB lento por HTML sin caché
Guarda el HTML en caché en el borde y elimina redirecciones
Fragmentos de solución
Imagen principal que se carga primero
Sin carga diferida en el probable elemento LCP, con prioridad de descarga alta, formatos modernos y dimensiones reales para que nada se desplace.
Fuente que no oculta el texto
Precarga el único archivo de fuente que se usa en la parte visible inicial y deja que el texto se muestre con una fuente de respaldo hasta que llegue.
Etiqueta de terceros cargada cuando la página ya está estable
Inserta un script de marketing cuando el navegador está en reposo, para que no compita con el primer renderizado ni con el primer toque.
Reserva espacio para el contenido que llega tarde
Un contenido incrustado o un espacio publicitario con una relación de aspecto fija evita que el contenido de debajo salte cuando se carga.
Lista de verificación de velocidad
Revísalas en este orden
Paso
Comprobación
Datos de campo: ¿cuál de LCP, INP y CLS falla en el percentil 75?
Elemento LCP: ¿es una imagen, y se carga en diferido o se descubre tarde?
TTFB: ¿el HTML está en caché, y hay redirecciones antes?
JavaScript: ¿cuál es el Total Blocking Time y qué scripts lo causan?
Diseño: ¿las imágenes, los contenidos incrustados y los banners tienen espacio reservado?
Fuentes: ¿está definido font-display y se precarga el archivo principal?
Buena
Necesita mejorar
Mala
Evalúa tus números
Introduce los valores de tu informe para ver si cada uno es bueno, necesita mejorar o es malo.