Cuáles son los umbrales de Core Web Vitals
Los umbrales de "buena" experiencia de las tres Core Web Vitals son LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos, y CLS de 0,1 o menos. Cada métrica tiene además dos rangos peores —"necesita mejora" y "pobre"—, y los tres valores se evalúan en el percentil 75 de las visitas reales de usuarios de Chrome. Esta es la tabla completa:
| Métrica | Qué mide | Bueno | Necesita mejora | Pobre |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Velocidad de carga | ≤ 2,5 s | 2,5 s – 4,0 s | > 4,0 s |
| INP (Interaction to Next Paint) | Capacidad de respuesta | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Una regla que conviene tener presente desde el principio: para aprobar la evaluación completa, las tres métricas deben estar en verde a la vez. No hay medias tintas ni promedios entre ellas. Un sitio con LCP e INP perfectos pero un CLS de 0,3 no aprueba las Core Web Vitals, y punto.
Cómo definió Google estos umbrales
Google definió cada umbral buscando un equilibrio entre dos criterios que a menudo tiran en direcciones opuestas: que el valor represente una experiencia de calidad para el usuario y que sea técnicamente alcanzable por sitios bien optimizados. Un umbral ideal desde la experiencia (por ejemplo, "todo debe cargar en 1 segundo") sería inútil si casi ningún sitio real pudiera cumplirlo; y uno demasiado laxo no distinguiría a los sitios buenos de los malos (web.dev, cómo se definieron los umbrales).
El caso del LCP ilustra bien el método. Google analizó los datos de rendimiento de sitios de todo el espectro y comprobó que umbrales de 1,5 o 2 segundos no se alcanzan de forma consistente ni siquiera en páginas bien construidas, mientras que 2,5 segundos sí es alcanzable sin dejar de sentirse rápido. Así, 2,5 segundos es la frontera donde una meta ambiciosa se cruza con una meta realista.
Hay un criterio adicional que Google aplica: el umbral debe poder medirse con calidad y fiabilidad. Una métrica que variara muchísimo entre una carga y otra por ruido, o que fuera difícil de medir con precisión, no serviría como línea de aprobado. Por eso los umbrales se apoyan en métricas estables y en un volumen de datos suficiente para que el número sea representativo y no producto del azar de unas pocas visitas.
Qué significa el percentil 75
El percentil 75 significa que el 75 % de las visitas a una página debe alcanzar el umbral "bueno" o mejorarlo para que esa página apruebe la métrica. Dicho al revés: basta con que una de cada cuatro cargas sea peor que el umbral para no aprobar. Si ordenaras todas las visitas de tu página de la más rápida a la más lenta y te pararas en la que ocupa la posición 75 de cada 100, ese es el valor que Google evalúa.
Un ejemplo con LCP lo aterriza. Supón que tu página tuvo 100 cargas: 80 con LCP de 2 segundos y 20 con LCP de 5 segundos. El percentil 75 cae dentro del grupo bueno, así que tu LCP evaluado sería de 2 segundos (aprueba), aunque un 20 % de tus usuarios haya tenido una experiencia mala. El percentil 75 tolera una minoría de visitas lentas, pero no una minoría grande.
¿Por qué el 75 y no la media o el 90? Google lo eligió como equilibrio deliberado: es lo bastante alto para representar la experiencia de la mayoría de los usuarios, pero no tan estricto como para que unas pocas visitas atípicas —alguien en una red 2G en medio del campo— hagan fallar a todo el sitio. La media, en cambio, se distorsiona con valores extremos y ocultaría a los usuarios peor servidos.
La ventana de 28 días
Los datos de campo que Google usa para evaluar las Core Web Vitals se calculan sobre una ventana móvil de 28 días del informe CrUX. Esto significa que el valor que ves en cualquier momento resume las visitas de los 28 días anteriores, y se actualiza a diario incorporando el día nuevo y descartando el más viejo. No es una foto instantánea, sino un promedio deslizante de casi un mes.
La consecuencia práctica sorprende a mucha gente: una mejora de rendimiento no se ve de inmediato. Si hoy optimizas tus imágenes y tu LCP real baja a la mitad, las visitas lentas de los días anteriores siguen contando en el promedio hasta que salen de la ventana. Puede pasar de dos a cuatro semanas hasta que la mejora se refleje por completo en PageSpeed Insights y en Search Console.
Esto lleva a una recomendación concreta: para verificar un arreglo al instante usa los datos de laboratorio de Lighthouse, que miden la página en ese momento; para confirmar el impacto real en el ranking, espera a que la ventana de 28 días se renueve. Cambiar algo y revisar los datos de campo al día siguiente esperando ver la mejora solo lleva a la frustración de creer que "no funcionó".
Datos de campo vs laboratorio en los umbrales
Los umbrales de Core Web Vitals se evalúan siempre con datos de campo, no de laboratorio, y esta distinción decide qué números importan para el posicionamiento. Los datos de campo provienen de usuarios reales de Chrome recogidos en CrUX; los de laboratorio provienen de una prueba simulada con un dispositivo y una red fijos, como Lighthouse. Google usa los primeros para rankear.
| Aspecto | Datos de campo (CrUX) | Datos de laboratorio (Lighthouse) |
|---|---|---|
| Origen | Usuarios reales de Chrome | Prueba simulada en un entorno fijo |
| Ventana | 28 días móviles | Instantánea, en el momento |
| ¿Cuenta para el ranking? | Sí | No |
| ¿Mide INP? | Sí | No (no hay usuario interactuando) |
| Para qué sirve | Evaluar el estado real del sitio | Diagnosticar y verificar arreglos al instante |
De aquí sale la situación que más confunde: tu página saca 98 en Lighthouse pero aparece en "necesita mejora" en campo. No es un error. Significa que tus usuarios reales navegan en condiciones peores que las del laboratorio, y como los umbrales se evalúan sobre ellos en el percentil 75, son ellos quienes definen si apruebas. Cuando campo y laboratorio discrepan, para el ranking gana el campo.
Por qué esto cambia cómo optimizas
Entender los umbrales cambia el orden en que trabajas: primero mides en campo, identificas cuál de las tres métricas cae por debajo de su umbral en el percentil 75, y solo entonces optimizas su causa concreta. Optimizar a ciegas, sin saber cuál métrica falla, suele arreglar lo que ya estaba bien y dejar intacto el problema real.
El percentil 75 también reordena prioridades hacia el usuario peor servido. Como la métrica la marca la visita en la posición 75, mejorar la experiencia de tus usuarios con móviles modestos y redes lentas mueve la aguja mucho más que optimizar para quien ya carga rápido. Y ahí es donde factores como el TTFB del servidor pesan: un hosting con discos NVMe, caché a nivel de servidor y baja latencia baja el suelo de carga para todos, incluidos los usuarios lentos que definen tu percentil 75. Para ver cómo estos umbrales se traducen en acciones concretas por métrica, la guía completa de Core Web Vitals recorre qué hacer con cada una.
Los umbrales de Core Web Vitals —2,5 s para LCP, 200 ms para INP y 0,1 para CLS— no son arbitrarios: Google los fijó equilibrando una experiencia de calidad para el usuario con una meta alcanzable por sitios bien optimizados, y los evalúa en el percentil 75 de las visitas reales sobre una ventana de 28 días. Entender esto tiene dos consecuencias prácticas: que debes optimizar pensando en tus usuarios más lentos, no en tu propia conexión, y que los cambios tardan semanas en verse en campo. Mide tu web en PageSpeed Insights, mira cuál de las tres métricas queda por debajo de su umbral en datos de campo y ataca esa; el resto es paciencia mientras la ventana de 28 días se renueva.
Hosting con LiteSpeed, NVMe y soporte 24/7 desde $3/mes.