Según el Web Almanac 2025, el proyecto anual de análisis del estado de la web elaborado por HTTP Archive, solo el 48% de las páginas móviles y el 56% de las páginas de escritorio aprueban simultáneamente las tres Core Web Vitals. Dicho de otra forma: más de la mitad de las webs del mundo están perdiendo una ventaja de posicionamiento por un problema que tiene solución técnica conocida.
Los Core Web Vitals no son una teoría ni una recomendación informal de Google. Son un factor de ranking confirmado, documentado oficialmente en Google Search Central, y activo desde junio de 2021. No deciden por sí solos quién ocupa el primer puesto, pero sí actúan como criterio de desempate constante entre páginas de contenido similar — y en sectores competitivos, ese desempate ocurre todos los días.
Esta guía explica qué mide exactamente cada una de las tres métricas, cómo comprobar el estado real de tu web con datos fiables, y qué acciones técnicas tienen mayor impacto para corregir cada una, ordenadas por prioridad real de implementación.
Tabla de contenidos
Qué son los Core Web Vitals
Las tres métricas explicadas en profundidad
Datos de campo vs. datos de laboratorio
Cómo medir tus Core Web Vitals paso a paso
Por qué importan para el SEO (con datos reales)
Cómo mejorar el LCP
Cómo mejorar el INP
Cómo mejorar el CLS
El papel del servidor y el hosting
Checklist de auditoría priorizada
FAQ sobre Core Web Vitals
Qué son los Core Web Vitals
Los Core Web Vitals son un conjunto de tres métricas oficiales de Google que miden la experiencia real de un usuario al navegar por una página web, centradas en tres dimensiones concretas: velocidad de carga percibida, capacidad de respuesta ante interacciones y estabilidad visual durante la carga.
Forman parte de un conjunto más amplio de señales que Google denomina «Page Experience», pero son las tres únicas que Google ha confirmado explícitamente como factor de posicionamiento desde 2021. Su origen se remonta a 2020, cuando Google identificó la necesidad de sustituir métricas técnicas dispersas y poco estandarizadas por un conjunto reducido, medible y comparable de indicadores centrados en el usuario final, no en el servidor.
Las tres métricas actuales, vigentes desde marzo de 2024, son:
- LCP (Largest Contentful Paint) — mide la velocidad de carga percibida.
- INP (Interaction to Next Paint) — mide la capacidad de respuesta ante interacciones.
- CLS (Cumulative Layout Shift) — mide la estabilidad visual durante la carga.
Hasta marzo de 2024, la métrica de interactividad era FID (First Input Delay), que Google sustituyó por INP tras un periodo de prueba de casi dos años, porque FID solo medía la primera interacción del usuario, mientras que INP evalúa la capacidad de respuesta durante toda la sesión de navegación — un reflejo mucho más fiel de la experiencia real.
Las tres métricas explicadas en profundidad
LCP — Largest Contentful Paint
El LCP mide el tiempo que tarda en renderizarse por completo el elemento visual más grande visible en la ventana del navegador (viewport) sin necesidad de hacer scroll. Habitualmente ese elemento es una imagen destacada, un vídeo de portada o un bloque de texto principal de gran tamaño.
Es, en esencia, la métrica de «velocidad percibida»: el momento exacto en el que el usuario siente que la página ya ha cargado su contenido principal, aunque otros elementos secundarios sigan cargándose en segundo plano.
Umbrales oficiales:
- Bueno: 2,5 segundos o menos
- Necesita mejora: entre 2,5 y 4 segundos
- Deficiente: más de 4 segundos
INP — Interaction to Next Paint
El INP mide el tiempo que transcurre entre una interacción del usuario — un clic, un toque en pantalla táctil, una pulsación de tecla — y el momento en el que el navegador actualiza visualmente la pantalla en respuesta a esa interacción.
A diferencia de su predecesor FID, que solo registraba el retraso de la primera interacción del usuario en la página, el INP evalúa todas las interacciones que ocurren durante la visita y reporta el percentil 75 de esas mediciones. Esto lo convierte en un indicador mucho más representativo del comportamiento real: una web puede responder bien al primer clic y volverse lenta después, algo que FID nunca detectaba y que INP sí captura.
Umbrales oficiales:
- Bueno: 200 milisegundos o menos
- Necesita mejora: entre 200 y 500 milisegundos
- Deficiente: más de 500 milisegundos
CLS — Cumulative Layout Shift
El CLS mide la suma de todos los cambios de posición inesperados que sufren los elementos visibles de una página mientras esta se está cargando. Es la métrica de estabilidad visual: cuantifica ese efecto molesto de intentar pulsar un botón y que, justo en ese instante, un elemento que acaba de cargar (una imagen, un banner de cookies, un anuncio) desplace todo el contenido hacia abajo.
El cálculo del CLS no es un conteo simple: combina la fracción de pantalla afectada por el desplazamiento con la distancia que se ha movido, acumulando ese valor a lo largo de toda la sesión de carga de la página.
Umbrales oficiales:
- Bueno: 0,1 o menos
- Necesita mejora: entre 0,1 y 0,25
- Deficiente: más de 0,25
Según datos del Web Almanac 2025, el CLS es la métrica con mejor rendimiento global: el 81% de las páginas móviles del mundo consiguen una puntuación buena, muy por encima del cumplimiento de LCP e INP. Esto sugiere que, en términos relativos, es la más sencilla de corregir con cambios técnicos puntuales — y la que menos excusa tiene para seguir en rojo.
Datos de campo vs. datos de laboratorio: la diferencia que todos confunden
Este es, con diferencia, el malentendido más extendido entre quienes empiezan a trabajar con Core Web Vitals. Existen dos tipos de datos completamente distintos, y solo uno de ellos es el que Google usa realmente para el posicionamiento.
Datos de campo (Field Data): son mediciones reales, recogidas de usuarios reales que han visitado tu web con el navegador Chrome, agregadas de forma anónima en un conjunto de datos público llamado Chrome UX Report (CrUX). Estos son los datos que Google utiliza efectivamente como señal de ranking. Reflejan condiciones reales de red, dispositivo y comportamiento — no una simulación.
Datos de laboratorio (Lab Data): son mediciones generadas por una herramienta que simula la carga de tu página en condiciones controladas y predefinidas (un dispositivo virtual, una velocidad de red simulada). Herramientas como Lighthouse generan exclusivamente datos de laboratorio. Son extremadamente útiles para diagnosticar problemas técnicos concretos y ver el efecto inmediato de un cambio, pero no son los datos que Google pondera para el posicionamiento.
La consecuencia práctica de esta distinción es importante: puedes optimizar tu web, ver una mejora instantánea en Lighthouse o PageSpeed Insights, y aun así no ver ningún cambio inmediato en el informe de Core Web Vitals de Search Console. Esto no es un error ni una señal de que la optimización no ha funcionado — es que los datos de campo del CrUX se recalculan sobre una ventana móvil de 28 días de tráfico real, así que el efecto tarda semanas en reflejarse en los datos que Google realmente usa para posicionar.
Cómo medir tus Core Web Vitals paso a paso
Existen cuatro herramientas gratuitas oficiales de Google, cada una con un propósito distinto. Usarlas en el orden correcto evita interpretaciones erróneas.
1. PageSpeed Insights
Es la herramienta de referencia porque combina ambos mundos: muestra datos de campo reales (si tu web tiene suficiente tráfico registrado en el CrUX) junto con datos de laboratorio generados por Lighthouse en el momento del análisis. Introduces la URL en pagespeed.web.dev, seleccionas si quieres el informe de móvil o de escritorio —analiza siempre ambos, por separado, porque Google usa indexación mobile-first y la versión móvil es la que más peso tiene— y obtienes una puntuación de 0 a 100 junto con el estado de cada métrica.
2. Google Search Console — Informe de Core Web Vitals
Se encuentra en el menú «Experiencia» de Google Search Console y es la única herramienta que muestra datos de campo agregados de todas las páginas de tu sitio a la vez, agrupadas por plantilla o tipo de página y clasificadas en las tres categorías oficiales: Bueno, Necesita mejora y Deficiente. Su ventaja frente a PageSpeed Insights es precisamente esa: en lugar de analizar una URL cada vez, permite detectar problemas sistemáticos que afectan a secciones enteras del sitio (por ejemplo, todas las fichas de producto de un e-commerce).
3. Lighthouse (integrado en Chrome DevTools)
Accesible presionando F12 en Chrome y seleccionando la pestaña Lighthouse, permite generar un informe de laboratorio bajo demanda, con recomendaciones técnicas específicas y priorizadas por impacto estimado. Es la herramienta más adecuada para depurar un problema concreto durante el desarrollo, antes de publicar cambios.
4. web.dev/measure
Ejecuta Lighthouse de forma remota desde el navegador de Google y ofrece guías paso a paso vinculadas a cada problema detectado, con enlaces directos a la documentación oficial de cada corrección. Puedes probarlo en web.dev/measure.
Proceso recomendado: usa Search Console para detectar qué páginas o plantillas tienen problemas a nivel de sitio completo con datos reales, y PageSpeed Insights o Lighthouse para diagnosticar el problema técnico específico de cada una de esas páginas antes de aplicar la corrección.
Por qué importan para el SEO (con datos reales)
Los Core Web Vitals no son el factor de posicionamiento más determinante — el contenido relevante y la autoridad del dominio siguen pesando más en el algoritmo de Google. Pero actúan como un desempate constante, y varios estudios cuantifican ese efecto con datos concretos:
- Un análisis de Searchmetrics encontró que las páginas situadas en el top 10 de Google tienen un LCP medio un 27% más rápido que las páginas en las posiciones 11 a 20 para las mismas búsquedas.
- Según datos citados por Google en su documentación de casos de estudio en web.dev, una mejora de 1 segundo en el LCP puede incrementar las conversiones hasta un 27% en determinados sectores.
- Un estudio de Vodafone mostró que una mejora del 31% en su LCP se tradujo en un incremento del 8% en las ventas.
- Amazon calculó, en un estudio ya clásico del sector, que cada 100 milisegundos adicionales de latencia le costaban aproximadamente un 1% en ventas.
- Un estudio de Deloitte encontró que una mejora de apenas 0,1 segundos en la velocidad de carga incrementó las conversiones un 8% en retail y un 10% en viajes.
El mecanismo por el que esto ocurre tiene dos vías. La primera es directa: Google usa los Core Web Vitals como señal de ranking documentada, así que dos páginas con contenido y autoridad comparables no compiten en igualdad de condiciones si una de ellas tiene una experiencia técnica sensiblemente peor. La segunda vía es indirecta pero igual de real: una web con mejores Core Web Vitals reduce su tasa de rebote, aumenta el tiempo en página y mejora las señales de comportamiento del usuario que Google también observa como indicio de calidad y relevancia.
Cómo mejorar el LCP
El LCP suele estar determinado por uno de estos cuatro factores, normalmente en este orden de impacto:
1. Tiempo de respuesta del servidor (TTFB). Si el servidor tarda mucho en entregar el primer byte de respuesta, todo lo demás se retrasa en cascada. Un TTFB por debajo de 200 milisegundos deja mucho margen para que el resto del proceso de carga sea bueno.
2. Recursos que bloquean el renderizado. CSS y JavaScript cargados de forma síncrona en el <head> del documento impiden que el navegador empiece a pintar el contenido hasta que termine de descargarlos y procesarlos. La solución pasa por diferir el JavaScript no crítico (usando los atributos defer o async), y por dividir el CSS entre el imprescindible para la primera pantalla (crítico, insertado en línea) y el resto (cargado de forma diferida).
3. Optimización del elemento LCP en sí. Si el elemento que determina el LCP es una imagen, hay que servirla en formatos modernos y comprimidos (WebP o AVIF en lugar de JPEG o PNG sin optimizar), con el tamaño exacto que se va a mostrar —no una imagen de 3.000 píxeles de ancho redimensionada por CSS a 600— y sin aplicarle lazy loading, ya que retrasaría precisamente el elemento que se quiere priorizar. Es recomendable, en cambio, precargar ese recurso concreto con la etiqueta <link rel=»preload»>.
4. Uso de una CDN (red de distribución de contenido). Una CDN almacena copias en caché de tu contenido en múltiples ubicaciones geográficas, de modo que se sirve al usuario desde el nodo más cercano físicamente, reduciendo la latencia de red. Es una de las mejoras con mejor relación esfuerzo-resultado, especialmente si tu audiencia está geográficamente dispersa.
Cómo mejorar el INP
El INP suele degradarse por un motivo principal: JavaScript que satura el hilo principal del navegador (main thread), impidiendo que este procese con rapidez la respuesta a las interacciones del usuario.
1. Dividir tareas largas de JavaScript. Cualquier tarea que ocupe el hilo principal durante más de 50 milisegundos de forma continuada empieza a generar retrasos perceptibles en la interactividad. La técnica principal de corrección es dividir esas tareas largas en fragmentos más pequeños, cediendo el control al navegador entre fragmento y fragmento.
2. Auditar scripts de terceros. Widgets de chat en vivo, píxeles de analítica, gestores de consentimiento de cookies y plugins de redes sociales son, con mucha frecuencia, la causa oculta de un INP deficiente. Cada script de terceros debería justificar su coste en rendimiento con un valor de negocio medible — y conviene revisarlos periódicamente, porque es habitual acumular scripts que ya no se usan.
3. Reducir el trabajo del navegador en cada interacción. Evitar manipulaciones innecesarias y repetidas del DOM en respuesta a eventos de usuario, y usar técnicas de debounce o throttle en eventos que se disparan con mucha frecuencia (como el scroll o el redimensionado de ventana).
4. Cargar JavaScript de forma diferida cuando sea posible. No todo el código de la página necesita estar disponible desde el primer instante. Cargar de forma diferida el JavaScript que solo se necesita tras una interacción específica del usuario (por ejemplo, el código de un modal que no se ha abierto todavía) reduce la carga inicial del hilo principal.
Cómo mejorar el CLS
El CLS suele ser, de las tres métricas, la más sencilla y rápida de corregir, porque sus causas son muy identificables y las soluciones son puramente estructurales.
1. Reservar espacio explícito para imágenes y vídeos. Definir siempre los atributos width y height en las etiquetas de imagen y vídeo, o usar la propiedad CSS aspect-ratio, permite que el navegador reserve el espacio exacto que va a ocupar ese elemento antes de que termine de cargarse, evitando el salto de layout cuando finalmente aparece.
2. Reservar espacio para anuncios y contenido embebido de terceros. Los bloques publicitarios, widgets de redes sociales embebidos o iframes de terceros deben insertarse dentro de contenedores con un tamaño mínimo fijo predefinido, para que su carga no desplace el contenido circundante.
3. Gestionar correctamente la carga de fuentes web (webfonts). Cuando una fuente personalizada tarda en cargar, el navegador puede mostrar primero una fuente de sistema y sustituirla después, provocando un reflujo del texto. La propiedad CSS font-display: swap o font-display: optional controla ese comportamiento y minimiza el impacto visual del cambio de fuente.
4. Evitar insertar contenido dinámico por encima de contenido ya visible. Banners de consentimiento de cookies, notificaciones o promociones que aparecen de forma repentina y empujan el contenido existente hacia abajo son una de las causas más frecuentes y más evitables de CLS alto. La solución pasa por reservarles espacio fijo desde el primer render, o por posicionarlos de forma que no desplacen el contenido principal.
El papel del servidor y el hosting
Es posible optimizar exhaustivamente el frontend de una web —imágenes, CSS, JavaScript— y aun así encontrar un techo de rendimiento si la infraestructura de servidor no acompaña. El servidor influye de forma directa, sobre todo, en el LCP, a través de varios factores concretos:
Tiempo de respuesta del servidor (TTFB). Es la base sobre la que se construye todo lo demás: si el servidor tarda 800 milisegundos solo en empezar a responder, ya has perdido buena parte del margen disponible para cumplir el umbral de 2,5 segundos del LCP, antes incluso de que el navegador empiece a descargar el primer recurso.
Versión del lenguaje de backend. En el caso de WordPress y otros CMS basados en PHP, cada versión mayor del lenguaje ha traído mejoras de rendimiento sustanciales. Ejecutar una versión de PHP obsoleta (7.x o inferior) frente a una versión moderna (8.2 o superior) puede suponer una diferencia de rendimiento notable sin tocar una sola línea de código de la web.
Ubicación física del servidor. La distancia física entre el servidor y el usuario introduce una latencia base que ninguna optimización de software puede eliminar por completo. Para un negocio con audiencia mayoritariamente española, tener el servidor alojado en territorio nacional o en la Unión Europea reduce esa latencia estructural frente a servidores ubicados en otros continentes.
Sistema de caché a nivel de servidor. Un servidor sin sistema de caché regenera cada página desde cero en cada visita, multiplicando innecesariamente el tiempo de respuesta. Los sistemas de caché a nivel de servidor (no solo a nivel de plugin del CMS) ofrecen mejoras de rendimiento superiores a las soluciones puramente basadas en plugins.
Antes de invertir tiempo exclusivamente en optimización de frontend, comprueba el TTFB de tu web con PageSpeed Insights o con la pestaña «Red» de Chrome DevTools. Si el TTFB supera los 600-800 milisegundos de forma consistente, el problema de fondo puede estar en la infraestructura de hosting, y ninguna optimización de imágenes o JavaScript va a compensar completamente esa base lenta.
Checklist de auditoría priorizada
Antes de empezar a corregir, es importante saber por dónde empezar. Esta tabla ordena las acciones por relación esfuerzo-impacto, de mayor a menor prioridad para la mayoría de webs.
| Prioridad | Acción | Métrica que mejora | Esfuerzo típico |
|---|---|---|---|
| 🔴 Crítica | Comprimir y servir imágenes en WebP/AVIF con tamaño correcto | LCP | Bajo |
| 🔴 Crítica | Definir width/height o aspect-ratio en imágenes y vídeos | CLS | Bajo |
| 🔴 Crítica | Reservar espacio fijo para banners de cookies y anuncios | CLS | Bajo |
| 🟠 Alta | Implementar sistema de caché de página completa | LCP, TTFB | Medio |
| 🟠 Alta | Diferir JavaScript no crítico (defer/async) | LCP, INP | Medio |
| 🟠 Alta | Auditar y eliminar scripts de terceros innecesarios | INP | Medio |
| 🟡 Media | Precargar el recurso LCP con <link rel=»preload»> | LCP | Bajo |
| 🟡 Media | Implementar font-display: swap en fuentes web | CLS | Bajo |
| 🟡 Media | Configurar una CDN | LCP | Medio |
| ⚪ Avanzada | Dividir tareas largas de JavaScript (code splitting) | INP | Alto |
| ⚪ Avanzada | Actualizar la versión de PHP del servidor | LCP, TTFB | Medio (requiere desarrollador/hosting) |
| ⚪ Avanzada | Migrar a un hosting con mejor TTFB base | LCP, TTFB | Alto |
Cómo usar esta tabla: las tres primeras acciones (prioridad crítica) suelen resolver la mayoría de los problemas de CLS y una parte relevante del LCP en la mayoría de webs, con un esfuerzo de implementación bajo. Si después de aplicarlas los datos de campo en Search Console siguen mostrando problemas —recuerda que tardan hasta 28 días en reflejar cambios—, es el momento de avanzar hacia las acciones de prioridad alta y, si es necesario, hacia las intervenciones más profundas de servidor. Este tipo de priorización es exactamente lo que debería aparecer en cualquier auditoría SEO técnica seria.
FAQ sobre Core Web Vitals
¿Los Core Web Vitals son el factor de SEO más importante?
No. El contenido relevante, la autoridad del dominio y la intención de búsqueda satisfecha siguen siendo los factores de mayor peso en el algoritmo de Google. Los Core Web Vitals actúan como un factor de desempate: cuando dos páginas compiten por la misma búsqueda con niveles de contenido y autoridad similares, la que ofrece mejor experiencia técnica tiene ventaja.
¿Cuánto tardan en reflejarse las mejoras en Search Console?
Los datos de laboratorio (Lighthouse, PageSpeed Insights) reflejan las mejoras de forma inmediata. Los datos de campo reales del Chrome UX Report, que son los que Google usa para el posicionamiento, se calculan sobre una ventana móvil de 28 días de tráfico real, por lo que el efecto de una corrección puede tardar hasta cuatro semanas en verse reflejado en el informe de Core Web Vitals de Search Console.
¿Necesito aprobar las tres métricas para tener buen SEO?
No es un requisito binario de todo o nada para posicionar, pero sí es el estándar que Google usa para clasificar una página como «aprobada» en su informe de experiencia de página. Cuantas más métricas estén en verde, mayor es la ventaja competitiva potencial en búsquedas donde compites con páginas de calidad de contenido similar.
¿Por qué mi web tiene buena puntuación en PageSpeed Insights pero Search Console muestra problemas?
Es una situación habitual y no indica un error. PageSpeed Insights puede mostrar datos de laboratorio (una simulación puntual y controlada) mientras que Search Console muestra datos de campo agregados de tráfico real de los últimos 28 días, que reflejan una variedad mucho mayor de dispositivos, condiciones de red y patrones de uso reales que no siempre coinciden con la simulación de laboratorio.
¿Los Core Web Vitals afectan igual a móvil que a escritorio?
Google evalúa ambas versiones por separado y genera informes independientes, pero dado que Google utiliza indexación mobile-first, la versión móvil de tu web tiene mayor peso relativo en la evaluación general de tu sitio. Es recomendable priorizar la corrección de problemas en la versión móvil cuando los recursos de optimización son limitados.
¿Qué plugin de WordPress mejora los Core Web Vitals?
No existe un plugin único que resuelva todos los problemas, porque cada métrica responde a causas técnicas distintas. Los plugins de caché (como WP Rocket o W3 Total Cache) ayudan principalmente al LCP y al TTFB; los plugins de optimización de imágenes (como ShortPixel o Imagify) ayudan al LCP; y ningún plugin corrige de forma automática los problemas de CLS derivados de un mal diseño de plantilla, que requieren intervención directa en el CSS y la estructura HTML del tema.
¿Cómo sé qué elemento concreto está causando un LCP lento en mi página?
PageSpeed Insights identifica explícitamente cuál es el elemento LCP de cada página analizada dentro de su informe, junto con un desglose del tiempo invertido en cada fase (retraso de carga, tiempo de carga del recurso, retraso de renderizado y tiempo de renderizado), lo que permite dirigir la corrección hacia la fase concreta que más está penalizando la métrica.
En resumen
Los Core Web Vitals no son una casilla técnica que marcar una sola vez. Son un conjunto de métricas vivas que reflejan la experiencia real de tus usuarios, y que deben integrarse en el proceso continuo de mantenimiento de cualquier web que dependa del tráfico orgánico para generar negocio.
La buena noticia es que, a diferencia de otros factores de SEO técnico que dependen de variables externas —backlinks, autoridad de dominio, competencia—, los Core Web Vitals están completamente bajo tu control técnico. La checklist priorizada de esta guía ofrece un punto de partida claro: empieza por las correcciones de bajo esfuerzo y alto impacto, mide con datos reales, y avanza hacia las intervenciones más profundas solo cuando sea necesario.
Si quieres saber en qué estado se encuentran realmente los Core Web Vitals de tu web y qué acciones concretas tienen más impacto en tu caso (y cuánto costaría corregirlas, dentro de lo que cuesta el SEO en España), en SEO Web Solutions realizamos auditorías técnicas de rendimiento para empresas en toda España. Cuéntanos tu caso →
También te puede interesar
SEO técnico en 2026: guía para no técnicos que quieren resultados →Sin código ni tecnicismos: qué es el SEO técnico, por qué afecta a tu tráfico y qué debe incluir cualquier auditoría profesional.
Escrito por
Xavier SerraFundador y Consultor SEO en Seo Web Solutions
Xavier Serra es fundador y consultor SEO en Seo Web Solutions, agencia especializada en posicionamiento web y visibilidad en IA en Barcelona, con más de 4 años de experiencia ayudando a empresas a crecer en internet.
