Qué son los Core Web Vitals y por qué Google los usa como señal de ranking
Los Core Web Vitals son un subconjunto de métricas de Web Vitals que Google ha seleccionado como indicadores de la experiencia de usuario en páginas web reales. A diferencia de las métricas de laboratorio (que se miden en condiciones controladas), los CWV se calculan a partir de datos reales del Chrome User Experience Report (CrUX), que agrega millones de visitas de usuarios reales de Chrome.
Esto es importante: Google rankea tu sitio basándose en los datos de CrUX, no en lo que diga Lighthouse en tu ordenador. Si tu target principal está en España con dispositivos de gama media y conexiones de 4G, esa es la distribución de datos que importa.
El peso real en ranking: Google confirmó en 2021 que los CWV son una señal de ranking dentro de la actualización Page Experience. En la práctica, su peso es menor que el de la relevancia del contenido y los backlinks: una página con contenido excelente y CWV mediocres rankea mejor que una con CWV perfectos y contenido pobre. Pero en nichos competitivos donde el contenido está igualado, los CWV pueden ser el diferenciador.
Las tres métricas actuales en 2026 son:
- LCP — Largest Contentful Paint: velocidad de carga percibida
- INP — Interaction to Next Paint: interactividad (reemplazó a FID en marzo 2024)
- CLS — Cumulative Layout Shift: estabilidad visual
LCP (Largest Contentful Paint): Qué Mide y Cómo Optimizarlo
LCP mide el tiempo que tarda en renderizarse el elemento más grande visible en el viewport desde que el usuario inicia la carga de la página. El elemento que se evalúa puede ser una imagen, un video, un bloque de texto o un elemento con imagen de fondo CSS.
Umbrales 2026:
- Bueno: < 2,5 segundos
- Necesita mejora: 2,5s - 4,0s
- Pobre: > 4,0 segundos
Google evalúa el percentil 75 de todas las visitas. Si el 75% de tus usuarios tienen LCP < 2,5s, pasas el umbral.
Causas más frecuentes de LCP lento
- TTFB alto: Si el servidor tarda en responder, todo lo demás se retrasa. Un TTFB > 800ms es una señal clara de problema de servidor o falta de caché.
- Imagen LCP no precargada: El elemento LCP más habitual es el hero image. Si el navegador no lo descubre hasta que parsea el DOM, llegará tarde.
- Formato de imagen ineficiente: JPEG o PNG en lugar de WebP/AVIF puede añadir 200-500ms en conexiones lentas.
- CSS render-blocking: Hojas de estilo grandes y síncronas retrasan el primer pintado.
Soluciones con código
Precargar el elemento LCP en el <head>:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">Añadir fetchpriority al elemento imagen:
<img src="hero.webp" alt="Hero" fetchpriority="high" loading="eager">Comprimir imágenes con formato moderno y srcset para responsive. Para WordPress: plugin Imagify o ShortPixel en modo AVIF.
INP (Interaction to Next Paint): La Métrica Nueva que Más Sitios Fallan
INP —Interaction to Next Paint— es la métrica que reemplazó a FID (First Input Delay) el 12 de marzo de 2024. Mide el tiempo entre cualquier interacción del usuario (clic, toque, pulsación de teclado) y el siguiente pintado visual que refleja el resultado de esa interacción.
La diferencia clave con FID: FID solo medía la primera interacción y solo la demora inicial (no el tiempo de procesamiento completo). INP mide el peor percentil de TODAS las interacciones durante toda la sesión. Es una métrica mucho más exigente.
Umbrales 2026:
- Bueno: < 200ms
- Necesita mejora: 200-500ms
Pobre: > 500ms
Por qué el 28% de sitios españoles fallan en INP
El culpable número uno es el JavaScript bloqueante en el main thread. Cada vez que el main thread está ocupado procesando JS (parseo, ejecución, garbage collection), las interacciones del usuario se encolan y esperan. Los síntomas típicos:
- Menús que tardan en abrirse con el primer clic
- Botones de formulario que no responden inmediatamente
- Tabs de acordeón con latencia perceptible
- Animaciones que se congelan durante scroll intenso
Soluciones para mejorar INP
1. Romper las tareas largas (Long Tasks > 50ms):
// En lugar de un bucle síncrono que bloquea:
function procesarDatos(items) {
items.forEach(item => procesarItem(item));
}
// Usar scheduler para ceder el main thread:
async function procesarDatosCediendo(items) {
for (const item of items) {
procesarItem(item);
await scheduler.yield(); // cede el main thread entre iteraciones
}
}2. Diferir JavaScript no crítico:
<script src="analytics.js" defer></script>
<script src="chatbot.js" async></script>3. Reducir el DOM size: Un DOM con >1.500 nodos aumenta el tiempo de rendering. Las páginas de ecommerce con muchos productos son especialmente vulnerables.
Herramienta para detectar Long Tasks: Chrome DevTools > Performance > Main thread. Las barras rojas son Long Tasks.
CLS (Cumulative Layout Shift): Cómo Eliminar los Saltos Visuales
CLS mide la inestabilidad visual acumulada durante la carga de una página. Cada vez que un elemento se desplaza de forma inesperada (sin que el usuario haya interactuado para provocarlo), se suma al CLS. El valor se calcula como un score, no en milisegundos.
Umbrales 2026:
- Bueno: < 0,1
- Necesita mejora: 0,1 - 0,25
- Pobre: > 0,25
Causas más comunes de CLS alto
- Imágenes sin dimensiones declaradas: Si el navegador no sabe el tamaño de la imagen antes de descargarla, reserva 0px y cuando la imagen carga, empuja el contenido hacia abajo.
Solución: siempre declarar width y height en el HTML o usar aspect-ratio en CSS:
O con CSS:<img src="foto.webp" width="800" height="450" alt="Descripción">img { aspect-ratio: 16/9; width: 100%; } - Anuncios y embeds sin espacio reservado: Los banners de publicidad o embeds de redes sociales que se cargan después del HTML empujan el contenido. Solución: reservar el espacio con un contenedor de tamaño fijo o
min-height. - Fuentes web sin font-display: swap: Cuando la fuente web carga después del texto de fallback, puede producir un FOIT (Flash of Invisible Text) o FOUT (Flash of Unstyled Text) que desplaza el layout.
Solución:@font-face { font-family: 'MiFuente'; src: url('/fonts/mifuente.woff2') format('woff2'); font-display: swap; } - Animaciones que afectan al layout: Animar propiedades como
height,top,marginopaddingcausa reflows y contribuye al CLS. En su lugar, anima solotransformyopacity, que se procesan en el compositor sin afectar al layout. - Banners de cookies y notificaciones tardías: Si aparecen después de que el contenido ya estaba visible, empujan todo hacia abajo.
FCP y TTFB: Las Métricas de Apoyo que Afectan a LCP
Aunque FCP (First Contentful Paint) y TTFB (Time to First Byte) no son Core Web Vitals oficiales, son métricas diagnóstico críticas que Google también monitoriza y que tienen impacto directo en LCP.
TTFB (Time to First Byte)
Tiempo desde que el navegador hace la petición HTTP hasta que recibe el primer byte de respuesta. Incluye el tiempo de DNS lookup, establecimiento de conexión TCP/TLS y el tiempo de procesamiento del servidor.
Umbral recomendado: < 800ms. Para alcanzarlo:
- CDN: Cloudflare gratis reduce el TTFB para usuarios geográficamente alejados del servidor. Para webs españolas con tráfico nacional, un servidor en Frankfurt o Madrid con Cloudflare puede llegar a <100ms de TTFB.
- Caché de página completa: En WordPress: WP Rocket, W3 Total Cache o LiteSpeed Cache. El TTFB baja de 500-800ms a 20-50ms en páginas cacheadas.
- PHP/Python optimizado: Evitar consultas N+1 a base de datos. Caché de objetos con Redis.
FCP (First Contentful Paint)
Tiempo hasta el primer elemento visible en pantalla (cualquier texto, imagen o SVG). Umbral recomendado: < 1,8s.
El bloqueo de render por CSS y JS síncronos es la causa principal. Herramienta diagnóstico: Chrome DevTools > Performance > waterfall de recursos. Los recursos que bloquean el render se marcan en rojo.
Herramientas para Medir Core Web Vitals con Datos Reales
El error más común al medir CWV es usar solo datos de laboratorio (Lighthouse local) cuando lo que Google usa para ranking son datos de campo reales (CrUX). Usa siempre ambos, pero prioriza los datos de campo.
- Google Search Console > Core Web Vitals: La fuente más importante. Datos reales de CrUX agrupados por página y tipo de dispositivo. Te muestra qué URLs específicas tienen problemas, con suficiente volumen de datos para ser estadísticamente relevantes.
- PageSpeed Insights: Combina datos de campo (CrUX si hay suficiente volumen) con datos de laboratorio (Lighthouse). Útil para páginas con poco tráfico donde CrUX no tiene datos suficientes.
- Chrome DevTools > Performance: Análisis de laboratorio detallado. Identifica Long Tasks, waterfall de recursos, main thread activity. Imprescindible para debugging de INP.
- Web Vitals Extension (Chrome): Muestra LCP, CLS e INP en tiempo real mientras navegas por cualquier web. Útil para comparar con la competencia.
- CrUX Dashboard (Data Studio): Historial de CWV para cualquier dominio con suficiente tráfico. Permite ver la evolución a lo largo del tiempo.
Core Web Vitals en WordPress: Soluciones Específicas
WordPress representa más del 40% de los sitios españoles y tiene patrones de problemas CWV muy específicos, principalmente por la acumulación de plugins y temas con JavaScript y CSS pesados.
LCP en WordPress
- Tema ligero como base: GeneratePress o Kadence Theme cargan en <30KB de CSS vs los 200-400KB de temas premium genéricos.
- Desactivar lazy loading en el LCP element: WordPress 5.9+ añade lazy loading por defecto a todas las imágenes. El hero image debe tener
loading="eager"yfetchpriority="high". - WP Rocket o LiteSpeed Cache: Caché de página completa, preconnect a fuentes externas, entrega diferida de JS no crítico.
INP en WordPress
- Auditar plugins activos: cada plugin puede añadir JS al main thread. Desactiva los que no sean imprescindibles en el frontend.
- Query Monitor plugin: identifica qué plugins hacen peticiones lentas a base de datos que bloquean el servidor.
- Eliminar jQuery si el tema y los plugins no lo necesitan. En 2026 es posible con la mayoría de temas modernos.
CLS en WordPress
- Instalar plugins de lazy loading que reserven espacio (como a3 Lazy Load con placeholder dimensions).
- Eliminar Google Fonts inline y usar font-display: swap en las declaraciones @font-face del tema hijo.
El Impacto Real de Core Web Vitals en Posicionamiento: Datos 2025-2026
El debate sobre el peso real de CWV en el ranking ha evolucionado con más datos disponibles. Lo que sabemos con certeza en 2026:
Lo que Google ha confirmado oficialmente: CWV es una señal de ranking dentro de la señal combinada Page Experience. En caso de empate de contenido y autoridad, CWV puede ser el desempate. El umbral es el percentil 75: si el 75% de tus visitas tiene buenas métricas, el sitio se considera bueno para ese CWV.
Datos de correlación (Semrush, 2025): Los sitios en posición 1-3 para keywords competitivas tienen un LCP mediano de 1.8s vs 2.7s para los que están en posición 4-10. La correlación no implica causalidad directa, pero la tendencia es clara.
Lo que la industria ha aprendido:
- Mejorar CWV de "pobre" a "necesita mejora" tiene impacto observable en algunos sectores.
- Pasar de "necesita mejora" a "bueno" tiene impacto menor, especialmente si el contenido es muy competido.
- El impacto es más claro en mobile que en desktop, porque Google usa mobile-first indexing.
- Nichos con alta competencia en contenido (finanzas, salud, legal) muestran mayor correlación CWV-ranking que nichos con menos competidores.
La conclusión práctica: mejorar CWV tiene sentido si estás en el umbral "pobre", y tiene un ROI claro en términos de experiencia de usuario y tasa de conversión incluso aunque el impacto SEO sea moderado.
Core Web Vitals en Ecommerce: El Impacto en Conversión más Allá del SEO
Para ecommerce, la relevancia de CWV va más allá del ranking. Amazon tiene datos internos que señalan que cada 100ms de mejora en tiempo de carga se traduce en un 1% de aumento en ventas. Walmart reportó un 2% de aumento en conversión por cada 1s de mejora. Los datos reales de clientes de WebsBarcelona con tiendas online muestran una correlación similar.
En ecommerce, los problemas CWV más frecuentes son:
- LCP en páginas de producto: Las imágenes del producto suelen ser el elemento LCP. Con 5-10 imágenes de alta resolución por producto, la optimización de formatos y lazy loading es crítica.
- INP en el carrito y checkout: Los scripts de pago (Stripe, PayPal, Bizum) y los validadores de formularios JavaScript son fuentes frecuentes de INP alto.
- CLS en páginas de categoría: Las grids de productos con imágenes de diferentes proporciones sin aspect-ratio definido producen CLS cuando las imágenes cargan asíncronamente.
Para WooCommerce: el plugin perfmatters + Imagify + WP Rocket es la combinación más probada. Para Shopify: las mejoras son más limitadas por la arquitectura cerrada de la plataforma, aunque los temas Dawn y Craft de Shopify tienen buenas bases de CWV.
Relacionado: Estrategia SEO completa para tu negocio.
Plan de Mejora de Core Web Vitals: Por Dónde Empezar
Si tu GSC muestra problemas de CWV, esta es la prioridad correcta de actuación:
- Identifica las URLs con más tráfico que fallan: GSC > Core Web Vitals te agrupa las URLs por problema. Prioriza las que tienen más impresiones y clics.
- Distingue datos de campo de laboratorio: Si tienes datos de campo en GSC/PSI, trabaja sobre esos. Si no (tráfico bajo), Lighthouse es tu referencia.
- Empieza por LCP: Es la métrica con más impacto percibido y generalmente la más fácil de mejorar con cambios de infraestructura (CDN, caché). Un CDN bien configurado puede mejorar el LCP mediano un 30-40%.
- Luego CLS: Declarar dimensiones de imágenes es un cambio de código simple con impacto inmediato.
- INP al final: Es el más complejo de optimizar porque requiere análisis del JavaScript específico de cada sitio. Reserva tiempo de developer senior para este punto.
- Mide el impacto 28 días después: CrUX agrega datos de los últimos 28 días. Los cambios de hoy no se verán en GSC hasta dentro de 28-56 días.
¿Necesitas ayuda con los CWV de tu web? Servicio SEO de WebsBarcelona o contacta directamente.
Preguntas frecuentes
Los Core Web Vitals en 2026 son tres métricas de experiencia de usuario que Google usa como señal de ranking: LCP (Largest Contentful Paint, velocidad de carga del elemento principal), INP (Interaction to Next Paint, interactividad) y CLS (Cumulative Layout Shift, estabilidad visual). INP reemplazó a FID en marzo de 2024. Se miden con datos reales de usuarios de Chrome (CrUX) y los umbrales buenos son LCP < 2.5s, INP < 200ms y CLS < 0.1.
Sí. Google sustituyó oficialmente FID por INP el 12 de marzo de 2024. INP es una métrica más completa: mide el tiempo desde cualquier interacción del usuario hasta el siguiente pintado visual durante toda la sesión, mientras que FID solo medía la demora inicial de la primera interacción. INP es más exigente y más representativo de la experiencia real de uso.
Los CWV son una señal de ranking dentro de la actualización Page Experience de Google. Su peso es menor que la relevancia del contenido y los backlinks, pero en nichos competitivos donde el contenido está igualado pueden ser el factor diferenciador. El impacto más claro es pasar de 'pobre' a 'bueno', especialmente en mobile. Mejorar CWV también aumenta la tasa de conversión independientemente del SEO.
INP es la más difícil porque requiere análisis y optimización del JavaScript específico de cada sitio. LCP y CLS tienen soluciones más estándar (CDN, caché, declarar dimensiones de imágenes, font-display:swap). INP requiere identificar Long Tasks en el main thread con Chrome DevTools y refactorizar el JavaScript para ceder el hilo principal entre tareas pesadas.
CrUX (Chrome User Experience Report) es el dataset de Google que agrega datos reales de rendimiento de millones de usuarios de Chrome. Es la base sobre la que Google calcula los Core Web Vitals para ranking. A diferencia de Lighthouse (datos de laboratorio, medición única en condiciones controladas), CrUX refleja la experiencia real de los usuarios del sitio con sus dispositivos y conexiones reales. Google evalúa el percentil 75 de los datos CrUX.
En Google Search Console, ve a 'Experiencia' > 'Core Web Vitals'. Verás dos informes: uno para móvil y otro para escritorio, con las URLs agrupadas por problema (LCP lento, INP lento, CLS alto). Para ver datos a nivel de URL individual, también puedes usar PageSpeed Insights introduciendo la URL de cada página.
CrUX agrega datos de los últimos 28 días de forma deslizante. Si implementas mejoras hoy, los datos de GSC empezarán a reflejar la mejora progresivamente y verás el impacto completo en 28-56 días. Los datos de laboratorio (Lighthouse, PageSpeed Insights) se actualizan inmediatamente, pero los datos de campo (que son los que usa Google para ranking) necesitan ese periodo de tiempo.
Las causas más frecuentes de CLS alto en WordPress son: imágenes sin dimensiones declaradas en el HTML (el problema más común), fuentes web sin font-display: swap que producen cambios de layout al cargar, widgets dinámicos (chat, banners de cookies, anuncios) que aparecen después del contenido inicial, y plugins de slider o galería que cambian el tamaño de su contenedor al inicializarse.
Sí, y el impacto en conversión es generalmente más directo y medible que el impacto en ranking. Estudios de Google muestran que sitios con buenas CWV tienen un 24% menos de abandono de página. Para ecommerce, cada segundo de mejora en tiempo de carga se correlaciona con un 1-2% de aumento en conversión. Mejorar CWV tiene ROI doble: más tráfico orgánico y mejor conversión del tráfico existente.
No existe un umbral de exclusión: un sitio con CWV pobres no desaparece del índice de Google. Los CWV son una señal de ranking positiva (tener buenos CWV ayuda) no una señal de exclusión (tener malos CWV no te elimina). La excepción sería si los problemas de rendimiento son tan graves que Google no puede rastrear e indexar el contenido, pero eso ya no sería un problema de CWV sino de crawlability.
En resumen
Los Core Web Vitals en 2026 son una realidad técnica que afecta tanto al posicionamiento como a la conversión. El reemplazo de FID por INP ha pillado desprevenidos a muchos sitios que habían optimizado para la métrica anterior. El plan de acción es claro: empieza por GSC para identificar qué URLs fallan y con qué métrica, prioriza LCP e INP en mobile (que es donde Google mide para ranking), y recuerda que los cambios tardan 28-56 días en reflejarse en los datos de campo.
Si tu web tiene problemas de CWV o quieres saber en qué posición está técnicamente, revisa nuestro servicio SEO o contacta para una auditoría inicial gratuita.
¿Necesitas una web profesional en Barcelona?
Presupuesto cerrado en 24h sin compromiso. Desde 99€.
Pedir presupuesto →Somos tu diseño web en Barcelona para pymes y autónomos · Ver portfolio