Los umbrales de Core Web Vitals 2026 establecen los estándares para la velocidad de página y la capacidad de respuesta a las interacciones en dispositivos de escritorio y móviles. Google evalúa estas métricas en el percentil 75 de las cargas de página: Largest Contentful Paint (LCP) se considera bueno en 2,5 segundos o menos y deficiente por encima de 4,0 segundos; Interaction to Next Paint (INP) se considera bueno en 200 milisegundos o menos y deficiente por encima de 500 milisegundos; y Cumulative Layout Shift (CLS) se considera bueno en 0,1 o menos y deficiente por encima de 0,25.
¿Cuáles son los umbrales de Core Web Vitals 2026?
Google evalúa la experiencia del usuario en sitios web a través de tres métricas principales, respaldadas por métricas a nivel de servidor como el Time to First Byte (TTFB). Cada métrica contiene tres clasificaciones de rendimiento: Bueno, Necesita mejorar y Deficiente. Google calcula estas métricas de forma independiente para visitas móviles y de escritorio utilizando datos de campo de usuarios reales recopilados por el Chrome User Experience Report.
- Largest Contentful Paint (LCP): Bueno es 2,5 segundos o menos; Deficiente es más de 4,0 segundos.
- Interaction to Next Paint (INP): Bueno es 200 milisegundos o menos; Deficiente es más de 500 milisegundos.
- Cumulative Layout Shift (CLS): Bueno es 0,1 o menos; Deficiente es más de 0,25.
- Time to First Byte (TTFB): El objetivo bueno es 0,8 segundos o menos para respaldar la entrega de respuesta inicial.
Para obtener una calificación de aprobación en los informes de Search Console, el 75 por ciento de las visitas a la página registradas durante un período de 28 días deben alcanzar el umbral de Bueno para cada métrica. Si incluso una métrica cae en la categoría de Necesita mejorar o Deficiente en el percentil 75, la URL no supera la evaluación general.
¿Por qué Google evalúa el percentil 75 por separado para móviles y escritorio?
Las capacidades de los dispositivos y las velocidades de red varían sustancialmente entre computadoras de escritorio y dispositivos móviles. Las CPU de los teléfonos inteligentes son generalmente menos potentes que los procesadores de escritorio, y la latencia de la red móvil cambia según la intensidad de la señal. Medir el rendimiento por separado evita que las métricas sólidas de escritorio oculten las experiencias deficientes de los usuarios móviles.
El umbral del percentil 75 garantiza que la mayoría de los visitantes reciban una experiencia web de alto rendimiento. Si el 74 por ciento de las sesiones móviles se cargan en menos de 2,5 segundos pero el 26 por ciento experimenta tiempos de espera más largos, la página cae en la categoría de Necesita mejorar. Este enfoque alienta a los equipos técnicos a crear sitios resistentes que funcionen de manera consistente en dispositivos de gama baja y conexiones más lentas.
¿Cómo solucionar las puntuaciones altas de Largest Contentful Paint (LCP)?
Largest Contentful Paint rastrea el tiempo necesario para renderizar el elemento de contenido principal en el viewport del usuario, como una imagen de banner principal, una miniatura de video o un bloque de texto grande. Los valores altos de LCP generalmente provienen de tiempos de respuesta del servidor lentos, CSS o JavaScript que bloquean el renderizado y la descarga retrasada de activos. Apunte a un Time to First Byte (TTFB) de 0,8 segundos o menos para darle al navegador suficiente tiempo para cargar los activos críticos.
En una tienda de comercio electrónico típica con imágenes de alta resolución, la imagen principal en las páginas de productos a menudo sirve como el elemento LCP. Cuando las páginas web aplican carga diferida (lazy loading) a los medios en la parte superior de la página, los navegadores retrasan la descarga de esos activos hasta que se completa la ejecución de JavaScript. Para acelerar la carga, elimine la carga diferida de las imágenes principales del encabezado y aplique el atributo fetchpriority=”high” directamente a la etiqueta HTML.
Optimizar la entrega de CSS también mejora los tiempos de LCP. Las reglas CSS extrañas bloquean el renderizado del hilo principal antes de que el navegador pueda dibujar el bloque visual principal. Extraiga el CSS crítico necesario para el renderizado inicial del viewport en etiquetas de estilo en línea, mientras difiere las hojas de estilo externas no críticas.
¿Cómo puede reducir el retraso de Interaction to Next Paint (INP)?
Interaction to Next Paint evalúa la capacidad de respuesta general de la página midiendo el tiempo entre las acciones del usuario (como tocar un botón o ingresar texto) y la actualización visual del marco posterior. Los valores altos de INP ocurren cuando se ejecutan tareas largas en el hilo principal del navegador, lo que impide el renderizado inmediato de la interfaz de usuario.
Para mantener el INP por debajo de 200 milisegundos, el código front-end debe evitar ejecutar tareas largas que superen los 50 milisegundos. Los desarrolladores pueden dividir las funciones monolíticas en bloques de ejecución asíncronos más pequeños utilizando opciones de API nativas como setTimeout o scheduler.yield(). Esto permite que el hilo principal del navegador procese los eventos del usuario rápidamente entre los pasos de ejecución.
Los scripts de terceros como widgets de chat en vivo, rastreadores de análisis y píxeles de marketing a menudo provocan retrasos inesperados en el hilo principal. En una auditoría de sitio típica, ejecutar múltiples etiquetas de terceros simultáneamente bloquea la ejecución del hilo durante los clics en los botones. Audite los scripts externos regularmente, cargue etiquetas no esenciales de forma asíncrona o envíe los cálculos en segundo plano a web workers.
¿Qué causa el Cumulative Layout Shift (CLS) y cómo prevenirlo?
Cumulative Layout Shift cuantifica la estabilidad visual midiendo con qué frecuencia los elementos de diseño se desplazan inesperadamente durante el renderizado de la página. Los cambios de diseño ocurren cuando los elementos se cargan de forma asíncrona sin espacio pre-reservado, lo que hace que el contenido existente se mueva repentinamente.
La causa principal de las puntuaciones altas de CLS es la falta de dimensiones de diseño en imágenes, contenedores incrustados y anuncios cargados dinámicamente. Cuando al navegador le faltan dimensiones predefinidas, no puede calcular la geometría de la página hasta que finaliza la descarga de los activos, lo que resulta en reflujos.
- Especifique atributos explícitos de ancho y alto en todos los elementos HTML de imagen y video, o defina relaciones de aspecto explícitas usando CSS.
- Reserve contenedores de diseño dedicados para contenido dinámico como banners publicitarios y barras de notificación para evitar que los elementos circundantes salten.
- Utilice font-display: swap o font-display: optional junto con la precarga de fuentes para eliminar los cambios de reflujo de texto causados por retrasos en la carga de fuentes web.
- Evite inyectar nuevo contenido HTML sobre elementos visibles existentes después del renderizado de la página, a menos que sea iniciado explícitamente por la entrada directa del usuario.
Cómo auditar Core Web Vitals en DevTools y Google Search Console
La optimización efectiva se basa en combinar el monitoreo de campo con diagnósticos de laboratorio detallados. Google Search Console destaca los datos de rendimiento de campo recopilados de visitas de usuarios reales, agrupando URL con perfiles de rendimiento similares para exponer problemas sistémicos del sitio.
Para la depuración local, utilice el panel de rendimiento de Chrome DevTools para registrar rastros de interacción e identificar tareas largas de JavaScript. La vista de línea de tiempo marca las tareas de más de 50 milisegundos con banderas rojas y localiza los elementos DOM precisos que causan cambios de diseño. En Alien Road, los equipos de desarrollo utilizan estos rastros de diagnóstico locales junto con comprobaciones automatizadas de integración continua para mantener los presupuestos de rendimiento antes de publicar actualizaciones.
Plan de acción: Por dónde empezar esta semana
Comience abriendo Google Search Console para examinar los informes de Core Web Vitals móviles e identificar las plantillas de URL fallidas. Priorice las correcciones en las páginas de destino de alto tráfico donde el LCP supere los 2,5 segundos, el INP aumente más de 200 milisegundos o el CLS supere 0,1.
Concéntrese en correcciones estructurales rápidas durante el primer sprint: establezca dimensiones de imagen explícitas, optimice las prioridades de la imagen principal con fetchpriority=”high” y asegúrese de que el TTFB se mantenga en o por debajo de 0,8 segundos mediante el almacenamiento en caché perimetral. Verifique las mejoras en los entornos de ensayo utilizando la limitación de red móvil simulada antes de implementar cambios de código en la producción.
Siga leyendo: Diseño y desarrollo web · Diseño web