Core Web Vitals 2026: Qué Son, Por Qué Importan y Cómo Mejorarlos

¿Alguna vez has abandonado un sitio web porque tardaba demasiado en cargarse? ¿O porque, justo cuando ibas a hacer clic en un botón, la página se desplazó y acabaste haciendo clic en otra cosa? Esas experiencias tienen un nombre técnico — y desde hace varios años Google las mide como parte de sus señales de experiencia de página.

Se llaman Core Web Vitals: tres métricas que capturan la calidad de la experiencia que tiene un usuario cuando visita una página web. No miden si el sitio es atractivo visualmente ni si el contenido es valioso — miden si la página funciona bien en el momento en que una persona real la está usando.

Forman parte de las señales de experiencia de página de Google desde 2021. Las funciones de IA en los resultados no cambian los umbrales documentados ni demuestran un aumento automático de su peso: conviene optimizarlos sobre todo porque describen problemas reales para los usuarios.

Índice

1. Las tres métricas: LCP, INP y CLS
2. Cómo medir los Core Web Vitals
3. Por qué tu sitio probablemente no rinde bien
4. Cómo mejorar el LCP
5. Cómo mejorar el INP
6. Cómo mejorar el CLS
7. El papel de la infraestructura del servidor
8. Preguntas Frecuentes

1. Las Tres Métricas: LCP, INP y CLS

LCP — Largest Contentful Paint

En términos simples: cuánto tiempo tarda el contenido principal de la página en hacerse visible.

Esta métrica mide la velocidad percibida desde el punto de vista del usuario. No cuando la página empieza a cargarse, sino cuando la parte más importante — la imagen principal, el titular, el bloque central de texto — es realmente visible y legible.

Un LCP por debajo de 2,5 segundos se considera bueno para Google. Entre 2,5 y 4 segundos, necesita mejora. Más de 4 segundos es un problema grave.

INP — Interaction to Next Paint

En términos simples: con qué rapidez responde la página cuando el usuario hace algo — hace clic en un botón, abre un menú, rellena un campo.

Esta métrica sustituyó al FID (First Input Delay) en marzo de 2024, porque mide la capacidad de respuesta de forma más completa: no solo el primer clic, sino todas las interacciones durante la sesión de navegación. Un sitio que se carga rápido pero responde lentamente a los clics sigue siendo una mala experiencia.

Un INP por debajo de 200 milisegundos se considera bueno. Entre 200 y 500ms necesita mejora. Más de 500ms es problemático.

CLS — Cumulative Layout Shift

En términos simples: cuánto “salta” la página mientras se carga, desplazando elementos que el usuario estaba mirando o a punto de pulsar.

Esta es la métrica que captura esa experiencia frustrante en la que estás a punto de hacer clic en un enlace y de repente se carga un anuncio que empuja todo hacia abajo — y acabas haciendo clic en la cosa equivocada.

Un CLS por debajo de 0,1 se considera bueno. Entre 0,1 y 0,25 necesita mejora; por encima de 0,25 entra en el rango deficiente y requiere diagnóstico.

2. Cómo Medir los Core Web Vitals

Antes de actuar, hay que saber dónde está el problema. Las principales herramientas son de acceso gratuito:

Google Search Console — Si el sitio está verificado, el informe Core Web Vitals agrupa las URL según los datos de campo disponibles. Es un punto de partida útil para observar problemas reales; las URL con tráfico insuficiente también requieren mediciones coherentes de laboratorio o RUM.

PageSpeed Insights (pagespeed.web.dev) — Analiza una única URL y devuelve una puntuación de 0 a 100, separada para móvil y escritorio, con la indicación precisa de cada métrica y las principales causas de los problemas. Es la herramienta más inmediata para un diagnóstico rápido.

Chrome DevTools — El panel Rendimiento ofrece métricas en tiempo real y análisis detallados de la carga. Estas funciones han sustituido el papel de Web Vitals Extension, cuyo soporte terminó en 2025.

Una distinción importante: PageSpeed Insights muestra datos de laboratorio simulados y datos de campo agregados en Chrome UX Report. Los primeros ayudan a diagnosticar; los segundos describen la experiencia observada durante un periodo y pueden no estar disponibles para URL con poco tráfico.

3. Por Qué Tu Sitio Probablemente No Rinde Bien

En los análisis que realizamos regularmente sobre sitios web, los mismos problemas recurrentes aparecen siempre. No porque quien construyó el sitio fuera incompetente, sino porque ciertas decisiones se toman sin considerar su impacto en el rendimiento:

Imágenes sin optimizar — Archivos de varios megabytes subidos con sus dimensiones originales en lugar de versiones redimensionadas y comprimidas para su contexto. Pueden consumir gran parte del presupuesto de carga de la página.

Demasiados plugins y scripts de terceros — Cada herramienta añadida al sitio agrega solicitudes de red y JavaScript que el navegador debe ejecutar. Herramientas de análisis, widgets de chat, píxeles de seguimiento, fuentes externas: se acumulan rápidamente y ralentizan todo.

Hosting de baja calidad — El tiempo de respuesta del servidor (TTFB, Time To First Byte) es la base sobre la que se construye cualquier otra optimización. Con un hosting lento, incluso un sitio perfectamente optimizado tendrá un LCP deficiente.

Ningún sistema de caché — Cada página se genera desde cero en cada solicitud en lugar de servirse desde una copia ya construida.

Fuentes web cargadas incorrectamente — Las fuentes personalizadas son una de las causas más comunes del CLS: la página muestra primero una fuente del sistema y luego la fuente personalizada se carga y desplaza el diseño.

4. Cómo Mejorar el LCP

El LCP debe descomponerse en toda la ruta de carga: respuesta inicial, descubrimiento y carga del recurso principal y retraso de renderizado del elemento. El cuello de botella cambia según la página.

Optimiza el recurso LCP cuando la medición indique que es el cuello de botella

WebP y AVIF pueden reducir el peso frente a formatos tradicionales, pero el resultado depende de cada imagen y de la compresión. El formato, las dimensiones y las alternativas deben elegirse y medirse en el contexto real del sitio.

Usa lazy loading — pero con criterio

El lazy loading pospone la carga de las imágenes que no son visibles en la ventana inicial. Es útil para todo lo que está más abajo en la página — pero nunca debe aplicarse a la imagen principal, la que contribuye al LCP. Un error común es activar el lazy loading global en todas las imágenes y empeorar involuntariamente la puntuación del LCP.

Implementa caché en el lado del servidor

Un sistema de caché puede servir una respuesta preparada en lugar de regenerarla en cada solicitud. El beneficio depende de aplicación, contenido y estrategia de invalidación y debe medirse en vez de darse por supuesto.

5. Cómo Mejorar el INP

El INP mide la capacidad de respuesta a las interacciones. JavaScript y las tareas largas en el hilo principal son causas frecuentes, pero también deben medirse el retraso de entrada, el procesamiento y la presentación del siguiente frame.

Identifica los scripts pesados

Cada fragmento de JavaScript que se ejecuta en el hilo principal puede obstaculizar la capacidad de respuesta. Los scripts de analítica, los widgets de terceros y las bibliotecas pesadas importadas para usar solo una parte de sus funciones son causas frecuentes de un INP alto.

El panel de Rendimiento de Chrome DevTools muestra qué tareas ocupan el hilo principal. Las prioridades deben seguir los cuellos de botella medidos, distinguiendo código propio, bibliotecas y servicios de terceros.

Carga los scripts de terceros de forma diferida

Los píxeles de seguimiento, widgets de chat y herramientas de análisis a menudo pueden usar defer o async, o activarse más tarde. La elección depende del consentimiento, las dependencias y la función, y debe medirse y probarse para evitar regresiones o pérdida de datos necesarios.

6. Cómo Mejorar el CLS

El CLS surge de desplazamientos inesperados del layout: imágenes sin espacio reservado, contenido insertado dinámicamente, fuentes y otros cambios pueden contribuir de forma distinta.

Especifica siempre las dimensiones de imágenes y vídeos

Si el navegador no conoce de antemano las dimensiones de una imagen, muestra primero el espacio vacío y luego la inserta una vez descargada — causando el desplazamiento de otros elementos. Añadir los atributos width y height al elemento <img> (o usar la propiedad CSS aspect-ratio) resuelve la mayoría de los casos de CLS causados por imágenes.

Reserva espacio para las fuentes personalizadas

Cuando una fuente web se carga después de que el navegador ya ha mostrado el texto con una fuente del sistema, el cambio tipográfico puede desplazar el diseño si las dos fuentes tienen métricas diferentes. font-display: optional puede reducir el riesgo al evitar un cambio tardío y size-adjust ayuda a calibrar el fallback. El resultado debe comprobarse con las fuentes y navegadores reales.

Atención a los banners y elementos insertados dinámicamente

Publicidad, banners de cookies, notificaciones: si se insertan en la página tras la carga inicial y desplazan el contenido ya visible, contribuyen negativamente al CLS. La solución es reservar de antemano el espacio que ocuparán, para que el diseño no se desplace cuando aparezcan.

7. El Papel de la Infraestructura del Servidor

Hay un aspecto que con frecuencia se ignora en el debate sobre los Core Web Vitals: todas las optimizaciones de front-end tienen un techo máximo determinado por la velocidad del servidor subyacente.

El TTFB (Time To First Byte) — el tiempo que el navegador espera antes de recibir el primer byte de respuesta del servidor — es el suelo sobre el que se construye cualquier otra optimización. Con un TTFB alto, incluso un sitio perfectamente optimizado nunca alcanzará un LCP excelente.

El TTFB debe evaluarse por zona geográfica, tipo de página e infraestructura. Un valor alto exige separar las causas de red, caché, aplicación y base de datos antes de actuar:

• Un servidor geográficamente cercano a los usuarios — o el uso de una CDN que distribuya el contenido en nodos globales
• Una configuración del servidor optimizada — versiones de software actualizadas, caché de opcodes activa, configuración del servidor web ajustada para la carga específica del sitio
• Un plan de hosting adecuado — en los hostings compartidos económicos, el TTFB es estructuralmente alto porque los recursos se dividen entre decenas de sitios

Este es el punto en que el SEO y la infraestructura se encuentran. Una respuesta inicial lenta consume una parte importante del tiempo disponible para mostrar el contenido principal; su impacto debe medirse junto con la red, la caché, el renderizado y los recursos de la página.

Preguntas Frecuentes

¿Los Core Web Vitals afectan realmente al posicionamiento en Google?

Forman parte de las señales de experiencia de página y pueden contribuir a la evaluación global. No existe una penalización automática independiente del contenido ni garantía de subir posiciones al mejorar un solo valor.

¿Cuál es la puntuación mínima de PageSpeed para estar tranquilo?

PageSpeed Insights asigna una puntuación de laboratorio de 0 a 100, útil para comparar pruebas ejecutadas en condiciones coherentes. No existe una puntuación mínima que garantice posiciones o conversiones: hay que evaluar por separado LCP, INP y CLS, los datos de campo, los diagnósticos y el comportamiento real de los usuarios.

¿Importan igual las puntuaciones de móvil y escritorio?

Google usa el rastreo mobile-first, pero el rendimiento móvil y el de escritorio deben analizarse por separado. El móvil suele revelar más límites de red y dispositivo: por eso es una prioridad operativa, no una regla universal sobre el “peso” de una métrica.

¿Puedo mejorar los Core Web Vitals por mi cuenta o necesito un especialista?

Depende de la estructura del sitio. Algunas optimizaciones superficiales — comprimir imágenes, eliminar scripts innecesarios — son accesibles para cualquiera con las herramientas adecuadas. Las optimizaciones que producen los mejoras más significativas y duraderas — configuración del servidor, gestión del TTFB, arquitectura del código, optimización de consultas a la base de datos — requieren trabajo a nivel de infraestructura con competencias técnicas específicas. Una regla práctica: si PageSpeed Insights identifica problemas del lado del servidor o de ejecución de JavaScript, no es territorio para el bricolaje.

¿Con qué frecuencia debo verificar los Core Web Vitals de mi sitio?

Los datos CrUX usados para Core Web Vitals agregan una ventana móvil de 28 días; esto no significa que cada actualización tarde 28 días en aparecer. En sitios estables conviene revisar la tendencia periódicamente. Tras un cambio importante, hay que probar de inmediato en laboratorio y seguir después la evolución de los datos de campo.

Mi sitio tiene buena puntuación en escritorio pero pésima en móvil. ¿Por dónde empiezo?

La diferencia casi siempre está causada por imágenes no optimizadas para pantallas pequeñas, JavaScript excesivo que ralentiza los dispositivos menos potentes, o fuentes y recursos cargados sin la prioridad correcta. El informe de PageSpeed Insights para la versión móvil identifica exactamente qué elementos contribuyen más a los problemas — es el punto de partida más eficiente.

¿Los Core Web Vitals de tu sitio están en el rango bueno, necesita mejora o deficiente? Realizamos un análisis completo: SEO técnico, velocidad, infraestructura del servidor y optimización del rendimiento. Contáctanos para descubrir qué está frenando a tu sitio.