Cómo leer una prueba de velocidad sin engañarte con el puntaje
En pocas palabras
En PageSpeed Insights, lo que dice si tu sitio anda bien no es el puntaje de 0 a 100 sino la sección de datos de campo: cómo cargó para visitantes reales en los últimos 28 días. Ahí se aprueba con un LCP de hasta 2,5 segundos, un INP de hasta 200 milisegundos y un CLS de hasta 0,1, medidos en tres de cada cuatro visitas. El puntaje sale de una sola carga simulada en un teléfono lento: sirve para encontrar problemas y comparar cambios, no para juzgar el sitio.
Las dos mitades del informe
Arriba, PageSpeed Insights muestra datos de campo del informe de experiencia de usuarios de Chrome (CrUX): mediciones de visitas reales, con sus teléfonos, sus redes y sus horarios, acumuladas durante 28 días. Abajo está el análisis de laboratorio: Lighthouse carga la página una vez en un teléfono emulado de gama media, con 4G lento (150 ms de latencia y 1,6 Mbps de bajada) y el procesador frenado a propósito.
Si tu sitio tiene pocas visitas, la parte de campo dice que no hay datos suficientes y solo queda el laboratorio. Cuando hay datos del sitio en general pero no de esa URL, se muestra el promedio del origen.
Qué mide cada métrica y dónde está el límite
| Métrica | Qué mide | Bueno | Malo |
|---|---|---|---|
| LCP | Cuándo aparece el elemento más grande de la pantalla, casi siempre la imagen o el título principal | Hasta 2,5 s | Más de 4 s |
| INP | Cuánto tarda la página en reaccionar a un toque o un clic, cerca de la peor interacción de la visita | Hasta 200 ms | Más de 500 ms |
| CLS | Cuánto se mueve el contenido mientras carga | Hasta 0,1 | Más de 0,25 |
| FCP | Cuándo aparece lo primero en pantalla | Hasta 1,8 s | Más de 3 s |
| TTFB | Cuánto tarda en llegar el primer byte desde el servidor | Hasta 0,8 s | Más de 1,8 s |
Los umbrales se evalúan en el percentil 75: para aprobar, tres de cada cuatro visitas tienen que estar en verde. LCP, INP y CLS son las Core Web Vitals, las que Google usa como señal.
De dónde sale el número de colores
El puntaje es un promedio ponderado de cinco métricas de laboratorio. Desde Lighthouse 10 pesan así: Total Blocking Time 30 %, LCP 25 %, CLS 25 %, FCP 10 % y Speed Index 10 %. El INP no entra, porque en una carga simulada nadie toca nada; el TBT, que mide cuánto tiempo el procesador estuvo trabado con JavaScript, hace de reemplazo aproximado.
Por eso el puntaje puede bajar diez puntos sin que el sitio cambie: una corrida con el servidor de prueba más cargado, un script de un tercero que respondió tarde. Y por eso un 100 no garantiza nada en el campo si tus visitantes usan teléfonos más lentos que el emulado.
Dónde se nota el servidor y dónde no
De todo el informe, lo que depende del hosting es casi solo el TTFB: lo que tarda el servidor en empezar a responder, más el viaje por la red. El resto —cuánto pesan las imágenes, cuánto JavaScript hay, cómo se cargan las fuentes— es trabajo del sitio.
Un detalle que confunde: muchas herramientas corren la prueba desde Estados Unidos o Europa si no elegís otra ubicación. Si tu sitio está en Buenos Aires, cada ida y vuelta suma más de 100 ms, y antes del primer byte hay varias (DNS, conexión, cifrado). Para tus visitantes en Argentina el TTFB real es menor. Para medirlo desde tu propia conexión:
curl -s -o /dev/null -w "DNS: %{time_namelookup} s\nConexión: %{time_connect} s\nCifrado: %{time_appconnect} s\nPrimer byte: %{time_starttransfer} s\nTotal: %{time_total} s\n" https://tudominio.com.ar/- Correlo tres o cuatro veces: la primera incluye la consulta DNS sin caché.
- Si el primer byte menos el cifrado da más de medio segundo, el servidor tarda en armar la página: falta caché o hay algo lento en la aplicación.
- Si el primer byte es bajo y el sitio igual se siente lento, el problema está en lo que el navegador tiene que descargar y ejecutar.
Avisos de Lighthouse: cuándo hacerles caso
| Aviso | Podés dejarlo si | Hacele caso si |
|---|---|---|
| Reducir el JavaScript sin usar | Señala el chat, la analítica o la publicidad, y ya cargan diferidos | Es un plugin o una librería que esa página no usa |
| Evitar redireccionamientos múltiples | La única es de http a https | Hay dos o más saltos, por ejemplo http, luego sin www, luego con barra final |
| Servir imágenes en formatos modernos | La imagen es de un tercero, como un mapa incrustado | Son tus fotos de producto o la imagen principal |
| Reducir el tiempo de respuesta del servidor | El primer byte medido desde Argentina queda por debajo de 0,8 s | También supera ese valor desde tu conexión |
Una sugerencia que según la propia herramienta ahorra menos de una décima de segundo casi nunca vale el trabajo.
Un método que da resultados comparables
- Elegí tres páginas representativas: la de inicio, una de contenido o de producto y una con formulario o buscador.
- Probalas en modo móvil, que es el que usa Google y donde más se nota.
- Hacé tres corridas por página y anotá la del medio, no la mejor.
- Guardá los resultados con la fecha. La comparación que vale es tu sitio contra tu sitio, antes y después de un cambio.
- A las cuatro semanas del cambio, mirá los datos de campo: recién ahí el promedio de 28 días refleja la versión nueva.
Qué hacer con lo que encontraste
Si falla el LCP, casi siempre es la imagen principal: su peso, su formato o que se carga tarde. El peso de las imágenes tiene el detalle. Si falla el CLS, faltan medidas en imágenes, anuncios o fuentes. Si falla el INP, sobra JavaScript. Para entender cada una a fondo está Core Web Vitals.
Si lo que falla es el TTFB, mirá la caché antes que el plan: cachés del navegador, del servidor y CDN explica cuál corresponde en cada caso. En los planes de hosting de InHosting el sitio se sirve desde Buenos Aires, con discos SSD, Nginx y HTTP/2, así que a un TTFB alto medido desde Argentina casi siempre le falta caché en la aplicación.
Preguntas frecuentes
¿Por qué el informe dice que no hay datos de campo?
Porque Chrome no juntó suficientes visitas de usuarios que comparten estadísticas en los últimos 28 días. Es normal en sitios nuevos o con poco tráfico. Mientras tanto, guiate por el laboratorio y medí el primer byte desde tu conexión.
¿Por qué en celular da mucho peor que en computadora?
Porque la prueba móvil emula un teléfono de gama media con 4G lento y un procesador cuatro veces más lento que el de la máquina de prueba. Es exigente a propósito: se parece a lo que vive buena parte de tus visitantes.
¿Conviene más GTmetrix, WebPageTest o PageSpeed Insights?
PageSpeed Insights es el único que muestra los datos de campo de Chrome, que son los que cuentan para Google. WebPageTest es el mejor para ver en detalle la cascada de descargas y elegir desde dónde probar. GTmetrix usa Lighthouse por dentro; si lo usás, fijate desde qué ciudad corre la prueba.
¿Sacar 100 en el laboratorio mejora el posicionamiento?
No directamente. Lo que Google usa son las Core Web Vitals de campo, y como una señal más entre muchas. Pasar de 90 a 100 en el laboratorio casi nunca cambia algo que un visitante note.
Seguí leyendo
Core Web Vitals: qué son LCP, INP y CLS y cómo mejorarlos
Qué mide cada Core Web Vital, cuáles son los umbrales de Google, dónde ver los datos reales de tu sitio y qué arreglar primero en LCP, INP y CLS.
6 min de lectura
Imágenes livianas: cuánto pesa una foto mal exportada y cómo arreglarla
Tamaño, formato y calidad: cómo bajar el peso de las imágenes de tu sitio sin que se note la diferencia, con WebP y AVIF, srcset y carga diferida.
5 min de lectura
Caché del navegador, del servidor y CDN: cómo hacer que se ayuden
Qué guarda cada capa de caché, cuánto tiempo conviene guardar cada archivo, qué no se cachea nunca y en qué orden se limpian para no ver contenido viejo.
6 min de lectura
