Website Speed Test: inicio inmediato y todos los términos explicados.

Website Speed Test significa: Largest Contentful Paint (LCP) por debajo de 2,5 segundos, Interaction to Next Paint (INP) por debajo de 200 milisegundos, Cumulative Layout Shift (CLS) por debajo de 0,1, cada uno en el percentil 75 de visitas reales. Eso lo dice así Google, no un blog. Quien solo mide desde su portátil en Berlín no conoce la página en Lagos.

Suelo empezar con el Chrome Inspector y miro en la pestaña Network si una imagen o un vídeo se come mucha capacidad. Luego PageSpeed Insights. Y luego un test desde otra ciudad, desde otro país, en otro continente.

Lab es una máquina. Feld son personas.

Lab (Lighthouse, un clic en PageSpeed Insights bajo „Diagnose"): un dispositivo fijo, una red fija, ningún humano que teclee. Bien para encontrar un JPEG pesado. Mal como veredicto sobre Japón.

Feld (Chrome User Experience Report, corto CrUX): usuarios reales de Chrome, 28 días, percentil 75. Esa es la cifra con la que Google valora la página. Un origin aprueba Core Web Vitals si LCP, INP y CLS allí son todos „good".

INP sustituyó a First Input Delay (FID) en marzo de 2024. Si en un texto todavía aparece FID como Core Web Vital, el texto es viejo.

Los umbrales que cuentan

Métrica	Qué mide	Bien	Regular	Mal
LCP	Cuándo el trozo visible más grande está ahí	≤ 2,5 s	2,5 s a 4 s	> 4 s
INP	Cuánto tarda un clic, tap o pulsación de tecla hasta el siguiente paint	≤ 200 ms	200 ms a 500 ms	> 500 ms
CLS	Cuánto se desplaza el layout sin que tú hagas nada	≤ 0,1	0,1 a 0,25	> 0,25
TTFB	Primer byte de la respuesta. No es un Core Web Vital, pero es el límite inferior para LCP	≤ 0,8 s	0,8 s a 1,8 s	> 1,8 s
FCP	Primer contenido visible. Diagnóstico, no vital de ranking	≤ 1,8 s	1,8 s a 3 s	> 3 s

Fuente de los tres vitals: web.dev/articles/vitals, última actualización el 31 de octubre de 2024, umbrales 2026 sin cambios. TTFB: web.dev/articles/ttfb, a fecha del 18 de noviembre de 2025. FCP: la misma familia de vitals, Lighthouse usa 1,8 s como "good".

Móvil y desktop tienen los mismos números. Está calibrado con una red móvil mediocre. Por eso casi cada origin falla primero en el teléfono.

La ruta de 20 minutos

1. Pestaña Network. Chrome, F12, Network, Reload. Ordena por Size. Lo que supera los 300 KB y es una imagen es la primera sospecha.
2. PageSpeed Insights. Campo (CrUX) y lab (Lighthouse) en una página. URL arriba en el starter.
3. Lighthouse local. DevTools, pestaña Lighthouse, categoría Performance, Device Mobile. El mismo motor que el Lab en PSI, solo en tu equipo.
4. Una segunda ciudad. WebPageTest, Location Mumbai o São Paulo, no solo "default". Si el TTFB explota allí, el servidor está en la región equivocada o sin CDN-Edge.
5. Un segundo navegador. Safari en un iPhone real miente de forma distinta que Chrome en un Pixel. Más abajo.

Tarjeta de herramientas: para qué sirve cada cosa

Herramienta	Mide	Lugares	Sensación de precio
PageSpeed Insights	Campo CrUX más Lab de Lighthouse, LCP/INP/CLS	Lab: una ubicación de Google. Campo: usuarios reales en todo el mundo, agregados	gratis
Chrome DevTools, Network + Performance + Lighthouse	Bytes, Waterfall, elemento LCP, Layout Shifts	tu escritorio	gratis
WebPageTest	Filmstrip, TTFB, LCP, Request-Waterfall, Script-Blocking	eliges la ciudad, el dispositivo, la conexión	gratis en el nivel básico, API de pago
GTmetrix	Lighthouse más vista Waterfall propia	pocas regiones fijas, más en Paid	gratis limitado, el resto suscripción
CrUX / CrUX Vis	Campo de 28 días, Origin o URL, si hay suficiente tráfico	usuarios reales, sin selección de ciudad	gratis
Search Console, informe Core Web Vitals	URLs de tu Property, campo, 28 días	tus visitantes reales	gratis, Property debe estar verificada
DebugBear, SpeedCurve, Calibre	Monitoreo, presupuestos, Lab en línea de tiempo	varias regiones	suscripción
Catchpoint	Sintético plus RUM, Enterprise	cien Plus ubicaciones	caro, serio
UptimeRobot	si la máquina responde, Response Time	pocos puntos de prueba	gratis basta para vivir
Pingdom	Uptime plus transacciones, Speed en Paid	varias regiones	suscripción
BrowserStack, LambdaTest	si la página en Safari, Firefox, Edge, iPhones antiguos siquiera funciona	nube de dispositivos, sin ranking de Speed	suscripción

Uptime no es Speed. UptimeRobot te dice si después de 30 segundos todavía llega un HTTP 200. El Response Time allí es a grandes rasgos TTFB, no LCP. Tengo allí una cuenta porque la pregunta "vive la página" es otra que "puede alguien en Jakarta ver el Hero".

Por qué los speedtests simples dejan fuera el mundo

PageSpeed Insights en el Lab arranca desde un ordenador de Google. CrUX debajo promedia usuarios reales, sin mostrarte Tokio contra Nairobi. Para una página de shop con clientes en DE y US el promedio es una mentira con fórmula correcta.

Quien quiera alcance global necesita tests sintéticos con ubicación seleccionable. WebPageTest es la entrada gratuita: Location, Browser, 4G. Catchpoint y DebugBear son lo mismo como pedido permanente. Un ping de un servicio de uptime desde EE. UU. mide el handshake, no la imagen más grande.

DNS, TLS, primer byte, luego HTML, luego CSS, luego la imagen hero. Un origin en Nürnberg es rápido en Frankfurt y en Sydney primero 250 ms en el cable, antes de que alguien pinte píxeles. Por eso: una medición aquí, una medición allá, solo entonces un juicio.

Navegadores que no son Chrome

Lighthouse es Chromium. Safari en iOS tiene otro JavaScript-JIT, otras reglas de caché, otra carga de fuentes. Firefox mete los trackers en el Strict-Mode. Un pase de Core Web Vitals en Chrome no dice nada sobre un checkout en Safari 17.

En la práctica:

• Un iPhone real, Safari, haz clic una vez por todo el checkout. No solo el simulador.
• Firefox, Tracking Protection activada, pestaña Network. Scripts de terceros que Chrome aún deja pasar a menudo se quedan atascados aquí.
• BrowserStack o LambdaTest, si no tienes un tablero de dispositivos: iPhone-Safari, un Samsung viejo, iPad. Eso es test de función. La speed allí es aproximada, porque la farm no es tu 4G.
• WebPageTest puede Chrome, Firefox, Edge en cajas reales en la ciudad elegida. Safari-iOS sigue siendo el dispositivo físico o la farm.

Qué retocas en la página cuando el número está rojo

• LCP: Hero como formato moderno (AVIF o WebP), ancho fijo, fetchpriority="high", no detrás de un slider. TTFB bajo 0,8 s, si no LCP no puede lograr los 2,5 s.
• INP: tareas largas en el main thread. Widgets de chat, cementerios de tag managers, hydration que bloquea 400 ms. Total Blocking Time en el lab es el proxy, porque Lighthouse no hace clic.
• CLS: Ancho y alto en imágenes y embeds. Ningún banner que caiga desde arriba a los 2 s. Fuentes con font-display: swap y un fallback adecuado que tenga un ancho similar.

Un iframe de YouTube en el artículo es un clásico culpable de CLS y LCP. Facades, o sea primero imagen previa, player tras el clic, son aquí la regla, no el extra.

Medir tú mismo con un agente de IA en 12 minutos

Necesitas Node, nada más. El agente escribe el script, tú lo lanzas contra tu URL.

npx --yes lighthouse https://example.com --only-categories=performance --form-factor=mobile --chrome-flags="--headless" --output=json --output-path=./lh.json

Luego TTFB sin teatro:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Playwright, si quieres hacer clic (INP en el lab no existe de otro modo):

npx --yes playwright install chromium
# ein 40-Zeilen-Skript: page.goto, page.click, performance.getEntries

Prompt al agente, con esto basta: "Escribe un script de Node que ejecute Lighthouse móvil contra esta URL, extraiga LCP/TBT/CLS del JSON y ponga curl-TTFB al lado. Sin dependencies excepto lighthouse. Exit 1 si LCP supera 2,5 s."

Eso no reemplaza CrUX. Reemplaza la tarde en la que persigues 40 URLs a mano por PSI.

Quien quiera varias ciudades y no tenga un contrato Enterprise: WebPageTest tiene una API. Un agente puede lanzar tres Locations una tras otra y volcar los JSON-Summaries en una tabla. Ese es el camino barato a "global", sin caja propia en Mumbai.

Una herramienta propia de speedtest para sitios web: lo que vale la pena

Iframear Google en la página no funciona limpio. PageSpeed Insights manda X-Frame-Options. Incluso si, el embed arruinaría exactamente las métricas que el artículo explica.

Tres niveles, de menor a mayor:

1. Starter, como arriba. Un campo, tres botones, los tests corren en Google y WebPageTest. Tiempo de construcción: menos de una hora. Está en este artículo.
2. Prueba de la propia flota. Un pequeño servicio en la Mothership: URL dentro, desde Núremberg (nbg1) y Falkenstein (fsn1) cada uno un HEAD más TTFB, DNS, TLS. Dos ubicaciones alemanas, etiquetadas como DE. Nada de "global". Tiempo de construcción: una tarde, si el agente escribe el servicio y tú ya tienes las cajas.
3. El mundo a través de ojos ajenos. La misma interfaz, detrás WebPageTest-API o un Catchpoint-Lite. Mumbai, Virginia, São Paulo como checkbox. Ese es el producto que los speedtests simples no son. Tiempo de construcción: dos días para una v1, más costos de API.

Los datos de campo (CrUX) los puedes añadir vía la CrUX API en cuanto el Origin tenga suficiente tráfico de Chrome. Bajo el umbral la baldosa se queda vacía, y eso lo tiene que decir la UI, no un número inventado.

Lo que no deberíamos construir: un clon de Lighthouse en la pestaña del navegador del lector, que finge ser el mundo. Miente en la misma dirección que el un clic en PSI.

Tabla de hechos

Afirmación	Cesta	Fuente
Core Web Vitals 2026: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, cada uno percentil 75, umbrales iguales en móvil y desktop	Hecho	web.dev/articles/vitals, estado 31.10.2024. Textos del sector 2026 confirman umbrales buenos sin cambios.
INP reemplazó a FID en marzo de 2024 como Core Web Vital	Hecho	La misma página, Lifecycle Stable para LCP, CLS, INP.
TTFB bueno ≤ 0,8 s, malo > 1,8 s, percentil 75. No es Core Web Vital	Hecho	web.dev/articles/ttfb, estado 18.11.2025.
FCP bueno ≤ 1,8 s en la definición de CrUX de HTTP Archive / web.dev	Hecho	httparchive.org/reports/chrome-ux-report, „Good First Contentful Paint".
El lab de PSI viene de una ubicación, CrUX promedia usuarios reales sin filtro de ciudad	Hecho	Producto PageSpeed Insights, docu de CrUX.
Un iframe de PSI en este artículo empeoraría el LCP y el CLS de la propia página	Tesis	MDN sobre costes de iframe, más la X-Frame-Policy de las herramientas de Google.
Dos ubicaciones de Hetzner (nbg1, fsn1) bastan para el TTFB desde Alemania, no para "global"	Tesis	Física de la distancia más nuestra flota. Mumbai sigue siendo otra medición.

Fuentes

1. https://web.dev/articles/vitals: Core Web Vitals, umbrales, lab frente a campo.
2. https://web.dev/articles/ttfb: Definición de TTFB y 0,8 / 1,8 s.
3. https://web.dev/articles/lcp · https://web.dev/articles/inp · https://web.dev/articles/cls
4. https://pagespeed.web.dev/: PageSpeed Insights.
5. https://developer.chrome.com/docs/crux: Chrome User Experience Report.
6. https://www.webpagetest.org/: Elige la ubicación.
7. https://httparchive.org/reports/chrome-ux-report: Distribución de campo sobre origins.
8. https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/HTML: Costes de iframe.
9. https://github.com/GoogleChrome/lighthouse: CLI para la ejecución del agente.

Corte de los umbrales: 16 de septiembre de 2026, frente a web.dev. Las cifras de bien no se han movido desde el cambio a INP de 2024.