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 y las usa para decidir dónde posicionar tu sitio en los resultados de búsqueda.

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.

Son factores de posicionamiento oficiales desde 2021. En 2026, con la IA cada vez más integrada en los resultados de búsqueda, el peso de la experiencia de usuario en la evaluación global de un sitio por parte de Google ha aumentado aún más. Sin embargo, la mayoría de los sitios web todavía no los ha optimizado correctamente — algo que vemos de forma consistente en nuestros análisis.

Índice

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 es un problema que Google penaliza.

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 tu sitio está verificado en Search Console, encontrarás el informe “Experiencia de página” con datos reales de los usuarios desglosados por URL. Es el punto de partida obligatorio: muestra problemas reales en tráfico real, no simulaciones.

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 — Para quienes están familiarizados con las herramientas de desarrollo del navegador, el panel de Rendimiento permite un análisis granular de cada milisegundo de carga de la página.

Web Vitals Extension — Una extensión de Chrome que muestra las métricas en tiempo real mientras navegas por el sitio, útil para identificar problemas en páginas específicas.

Una distinción importante: PageSpeed Insights muestra tanto datos de laboratorio (simulados) como datos de campo (reales). Los datos que Google utiliza para el posicionamiento son los reales, recopilados de los usuarios a través de Chrome. Si tu sitio tiene poco tráfico, es posible que los datos reales no estén disponibles.

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 — Imágenes subidas con la resolución original de la cámara (a menudo de 4 a 6 MB) en lugar de versiones redimensionadas y comprimidas. Por sí solas pueden eliminar cualquier otro esfuerzo de optimización.

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 depende principalmente de dos factores: la rapidez con que responde el servidor y el tamaño del elemento principal de la página.

Optimiza las imágenes — esta es la prioridad absoluta

El formato WebP ofrece una calidad visual equivalente al JPEG con archivos hasta un 30% más ligeros. El formato AVIF, compatible con todos los navegadores modernos en 2026, va aún más lejos. Redimensiona siempre las imágenes al tamaño máximo en que se muestran realmente — no tiene sentido cargar una imagen de 3.000 píxeles de ancho si el contenedor tiene solo 800 píxeles.

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é sirve la página ya construida en lugar de regenerarla en cada solicitud. La diferencia en términos de TTFB puede ser de un orden de magnitud. En servidores gestionados, esta configuración se realiza a nivel del servidor web (Nginx o Apache) o mediante soluciones dedicadas como Varnish.

5. Cómo Mejorar el INP

El INP mide la capacidad de respuesta a las interacciones, y casi siempre es un problema causado por JavaScript que bloquea el hilo principal del navegador.

Identifica los scripts pesados

El panel de Rendimiento de Chrome DevTools muestra exactamente qué scripts consumen más tiempo. A menudo se descubre que el 90% del tiempo de ejecución está ocupado por uno o dos scripts de terceros que podrían cargarse de forma diferida o eliminarse.

Carga los scripts de terceros de forma diferida

Píxeles de seguimiento, widgets de chat, herramientas de análisis: en la mayoría de los casos no necesitan estar disponibles en el instante en que se abre la página. Cargarlos con el atributo defer o async, o activarlos solo tras la primera interacción del usuario, mejora el INP sin sacrificar funcionalidad.

6. Cómo Mejorar el CLS

El CLS casi siempre es causado por elementos que la página no sabe dónde colocar hasta que termina de cargarse.

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. La propiedad CSS font-display: optional evita el problema usando la fuente personalizada solo si ya está en la caché, sin causar nunca un rediseño.

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.

Un TTFB por debajo de 200 milisegundos es el objetivo. Lograrlo requiere:

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 inevitablemente. Puedes optimizar cada imagen y cada línea de JavaScript, pero si el servidor responde en 800ms ya estás fuera de los parámetros de un buen LCP antes incluso de empezar.

Preguntas Frecuentes

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

Sí, son factores de posicionamiento oficiales desde 2021. No son el factor dominante — la relevancia del contenido y la autoridad del sitio importan más — pero en contextos competitivos donde dos sitios son equivalentes en calidad de contenido, los Core Web Vitals pueden marcar la diferencia. Además, un sitio con métricas muy deficientes puede ser penalizado directamente independientemente de la calidad del contenido.

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

PageSpeed Insights asigna una puntuación de 0 a 100, pero el número en sí no es lo que Google usa para el posicionamiento — Google usa las métricas individuales (LCP, INP, CLS) y sus umbrales. Dicho esto, una puntuación por debajo de 50 en móvil es casi siempre la señal de que hay problemas graves por resolver. Por encima de 70 en móvil es un buen punto de partida. Por encima de 90 es excelente.

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

Google ha estado usando el rastreo mobile-first desde 2019 — evalúa tu sitio principalmente como lo vería un usuario de smartphone. Los Core Web Vitals en móvil tienen por tanto más peso. Es habitual ver puntuaciones muy diferentes entre móvil y escritorio: el móvil generalmente sale peor parado porque las conexiones son más lentas y los teléfonos tienen menos potencia de procesamiento que los ordenadores.

¿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?

Google Search Console actualiza los datos con un retraso de aproximadamente 28 días y muestra la evolución en el tiempo. Verificar mensualmente es suficiente para sitios estables. Después de cualquier cambio significativo en el sitio — actualizaciones de tema, nuevas integraciones, migración de hosting — vale la pena hacer una verificación inmediata con PageSpeed Insights.

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.