Skip to content

Velocidad del Sitio

En el navegador · consultas a APIs públicas
Última verificación junio 2026 — corre en tu navegador

Velocidad del Sitio — Core Web Vitals desde CrUX (LCP, INP, CLS)

Introduce una URL u origen para obtener sus Core Web Vitals del Chrome User Experience Report (CrUX, developer.chrome.com/docs/crux). Los resultados son el percentil 75 de usuarios reales de Chrome durante los últimos 28 días — el mismo dataset que Google usa para señales de ranking. Las Core Web Vitals en 2024+ son LCP (Largest Contentful Paint, umbral <2,5 s para 'bueno'), INP (Interaction to Next Paint, umbral <200 ms — reemplazó a FID el 12 de marzo de 2024 según Google Search Central) y CLS (Cumulative Layout Shift, umbral <0,1). Más FCP (First Contentful Paint) y TTFB (Time to First Byte) para contexto diagnóstico. Las pruebas de laboratorio (Lighthouse, WebPageTest) hacen una sonda sintética desde una máquina limpia — esta herramienta refleja lo que experimentan visitantes reales. Los transportes modernos afectan los números: HTTP/2 (RFC 7540 Belshe, Peon y Thomson, mayo 2015) y HTTP/3 (RFC 9114 Bishop Ed., junio 2022) sobre QUIC cambian la configuración de conexión y el comportamiento de head-of-line blocking; pasar de HTTP/1.1 a HTTP/2 mejora normalmente TTFB y paralelismo de recursos.

Relacionado:

Estado del Sitio Verifica uptime del sitio web, tiempo de respuesta y estado del servidor Comparar Resolvers Compara respuestas DNS y latencia entre Cloudflare, Google, AdGuard y NextDNS Cabeceras HTTP Inspecciona cabeceras HTTP de respuesta y análisis de seguridad ¿Está Caída? Comprueba si un sitio web está caído para todos o solo para ti Velocidad del Sitio Comprueba Core Web Vitals (LCP, INP, CLS, FCP, TTFB) desde datos reales de Chrome Cuál Es Mi IP Consulta tu dirección IP pública, ubicación, ISP y detalles de red

Cómo comprobar las Core Web Vitals

  1. Introduce una URL (página específica) u origen (hostname completo) para testear.
  2. La herramienta consulta la API del Chrome UX Report para los valores p75 de LCP, INP, CLS, FCP y TTFB durante los últimos 28 días de datos reales de Chrome.
  3. Si los datos a nivel URL son insuficientes (por debajo del umbral de cobertura CrUX), la herramienta cae a agregación de origen — agrupando todas las URLs del hostname.
  4. Usa los números como contexto de datos de campo — combínalos con tests de laboratorio Lighthouse para una imagen completa de optimización.

Casos de uso comunes

  • Auditar si los usuarios reales de Chrome alcanzan los umbrales 'bueno' CWV (LCP <2,5 s, INP <200 ms, CLS <0,1) para una página de aterrizaje clave.
  • Confirmar que un despliegue de CDN mejoró el TTFB en CrUX — espera 28 días para que la ventana móvil se actualice tras el despliegue.
  • Comparar CWV en móvil vs escritorio — móvil suele ir por detrás por CPUs y redes más lentas.
  • Detectar regresiones: si INP pasó de verde a rojo tras un despliegue, sospecha de scripts de terceros nuevos o handlers de interacción costosos.

Preguntas frecuentes

¿En qué se diferencia de Lighthouse o PageSpeed Insights?

Lighthouse hace una sonda sintética desde una máquina limpia. CrUX agrega usuarios reales de Chrome al p75 durante 28 días — ese es el dataset que Google usa para ranking. Ambos útiles: Lighthouse para diagnóstico de laboratorio, CrUX para lo que los usuarios realmente experimentan.

¿Qué significa 'datos insuficientes'?

CrUX requiere suficiente tráfico Chrome por origen/URL para publicar datos conservando el anonimato. Por debajo del umbral (Google no publica el número exacto), no aparecen métricas. Usa Lighthouse o WebPageTest como fallback.

¿Cuál es la diferencia entre ámbito URL y origen?

URL afecta a una página específica (/precios); origen agrega todas las URLs del hostname. URL es más accionable pero necesita más tráfico. La herramienta intenta URL primero, cae a origen si no hay datos.

¿Qué métrica debo optimizar primero?

La que esté en Pobre. En 2024+, INP (reemplazó a FID el 12 de marzo de 2024) es donde más sitios fallan tras endurecerse. Luego LCP (precarga imagen hero, reduce CSS bloqueante de render). CLS es normalmente el arreglo más barato — reserva espacio para imágenes y anuncios.

¿Cuándo reemplazó INP a FID?

12 de marzo de 2024 (anuncio Google Search Central). FID medía retraso antes de la primera interacción; INP mide el camino completo interacción-a-paint, capturando handlers lentos y layout thrashing que FID se perdía. Umbral bueno INP <200 ms (vs FID <100 ms).

Por qué importan los datos de usuarios reales y cómo funciona la ventana 28 días rolling

Las herramientas de laboratorio lanzan una petición sintética desde una máquina limpia y conexión rápida. Los usuarios reales tienen redes lentas, dispositivos viejos, CPUs saturadas y cascadas de terceros. CrUX agrega métricas de campo reales al percentil 75, que es el número que Google usa para decidir si una página es rápida a efectos de ranking. Si tu puntuación Lighthouse es buena pero CrUX es pobre, arregla la experiencia de usuarios reales, no el benchmark — son datasets distintos respondiendo preguntas distintas. CrUX tiene un umbral de cobertura: un origen o URL necesita suficiente tráfico Chrome durante la ventana móvil de 28 días para que Google publique datos a nivel URL. Por debajo de ese umbral (Google no publica el número exacto), la herramienta cae a agregación de origen, que suele tener volumen suficiente porque agrupa todas las URLs del hostname. El dataset CrUX cubre decenas de millones de orígenes (el número exacto se publica mensualmente vía las release notes del dataset BigQuery). Optimizar en el orden correcto importa: empieza por la métrica calificada como Pobre. Desde el 12 de marzo de 2024, INP reemplazó a FID — sitios que pasaban FID pueden fallar INP porque INP mide la peor interacción del ciclo de vida de la página (handlers de clic lentos, recálculos de estilo costosos, layout thrashing). LCP suele mejorar precargando la imagen hero y reduciendo CSS bloqueante de render. CLS es a menudo el arreglo más barato — reserva dimensiones para imágenes y contenido dinámico.

  • LCP, INP, CLS, FCP, TTFB al percentil 75 (umbrales Google CWV 2024+)
  • INP reemplazó a FID el 12 de marzo de 2024 (anuncio Google Search Central)
  • Dispositivos móvil y escritorio según estándar CrUX
  • Ámbito URL y origen (ventana móvil de 28 días)
  • Datos reales de Chrome vía Chrome UX Report (developer.chrome.com/docs/crux)
  • Estado "datos insuficientes" claro para sitios bajo el umbral de cobertura CrUX

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (5)
  • Google (web.dev / Chrome team) (live). Core Web Vitals — LCP, INP, CLS thresholds. web.dev/articles/vitals (LCP <2.5s, INP <200ms, CLS <0.1).
  • Google Chrome team (live). Chrome User Experience Report (CrUX) Methodology. developer.chrome.com/docs/crux (28-day rolling window, p75).
  • Google Search Central (2024). Interaction to Next Paint (INP) becomes a Core Web Vital on March 12. developers.google.com/search/blog/2023/05/introducing-inp + web.dev/blog/inp-cwv-march-12.
  • Belshe, M., Peon, R., & Thomson, M. (Ed.) (2015). Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540, IETF.
  • Bishop, M. (Ed.) (2022). HTTP/3. RFC 9114, IETF (HTTP semantics over QUIC).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Guías relacionadas

Por ·