Una web lenta puede estar haciéndote perder clientes sin que resulte evidente. Ves que las visitas no se convierten en llamadas, en citas o en compras, pero no siempre relacionas esa pérdida de oportunidades con el rendimiento de la página.
Ese rendimiento tiene un nombre concreto: los Core Web Vitals, el conjunto de métricas con las que Google mide la experiencia real de quien usa tu web, más allá de si «se ve rápida» a simple vista.
Si has llegado hasta aquí porque has visto el término en Search Console, en un informe SEO, o porque alguien te lo ha mencionado, puede que no tengas claro qué es ni si te afecta. Este artículo cubre justo eso: qué son los Core Web Vitals, por qué importan más allá del SEO, cómo comprobar si tu web los cumple, y qué puedes hacer para mejorarlos.
¿Qué son los Core Web Vitals?
Core Web Vitals no es un sinónimo de «velocidad web», aunque suela usarse así. Es el conjunto de métricas con las que Google mide tres aspectos concretos de la experiencia de un usuario real en tu web: cuánto tarda en cargar el contenido principal, cuánto tarda la web en responder cuando alguien interactúa con ella, y si los elementos se mueven de forma inesperada mientras carga.
Esa distinción importa porque una web puede parecer rápida en una prueba puntual y aun así ofrecer una mala experiencia a usuarios reales. Y también al revés: puede sacar una puntuación alta en una herramienta de test y fallar en Core Web Vitals cuando se mide con datos reales de navegación. Son cosas relacionadas pero no idénticas, y confundirlas es uno de los errores más habituales que vemos al hablar de este tema.
Las tres métricas oficiales son:
- LCP (Largest Contentful Paint): cuánto tarda en mostrarse el contenido principal de la página, normalmente la imagen más grande o el bloque de texto principal visible al cargar.
- INP (Interaction to Next Paint): mide la capacidad de respuesta de la página ante interacciones como un clic, un toque en pantalla o una pulsación de teclado.
- CLS (Cumulative Layout Shift): cuánto se desplazan los elementos de la página de forma inesperada mientras carga, por ejemplo cuando un botón se mueve justo cuando ibas a pulsarlo.
Aquí conviene aclarar algo que todavía genera confusión: hasta marzo de 2024, la métrica de interactividad utilizada era FID (First Input Delay). Google la sustituyó por INP, que es la métrica vigente desde entonces. Si te encuentras contenido que sigue hablando de FID como Core Web Vital actual, es una guía desactualizada.
Estos son los umbrales que definen si tu web aprueba cada métrica, según la documentación oficial de Google:
Métrica | Qué mide | Umbral bueno |
LCP (Largest Contentful Paint) | Cuánto tarda en mostrarse el contenido principal | ≤ 2,5 segundos |
INP (Interaction to Next Paint) | Cuánto tarda la web en responder a una interacción | ≤ 200 milisegundos |
CLS (Cumulative Layout Shift) | Cuánto se desplazan inesperadamente los elementos | ≤ 0,1 |
Un matiz importante: estos umbrales no se miden con la media de todas las visitas, sino con el percentil 75. Además, se evalúan por separado entre móvil y escritorio. Eso explica por qué una web puede aprobar Core Web Vitals en escritorio y suspender en móvil: son, a efectos prácticos, dos mediciones distintas de la misma web.
Por qué los Core Web Vitals importan más allá del SEO
Aunque no te interese el posicionamiento en Google, los Core Web Vitals miden algo que sí debería importarte directamente: la experiencia de alguien que ya ha llegado a tu web y está decidiendo si se queda o se va.
Una web que tarda en cargar el contenido principal, que no responde con fluidez cuando alguien intenta rellenar un formulario, o donde los botones se mueven justo cuando el usuario va a pulsarlos, genera fricción en el momento exacto en que esa persona estaba a punto de contactar, comprar o reservar. En navegación móvil, donde las condiciones de conexión suelen ser peores que en escritorio, ese efecto se nota todavía más.
No hace falta una cifra concreta de abandono para entender la idea. Cuanto más le cuesta a alguien hacer lo que ha venido a hacer en tu web, más probable es que abandone antes de conseguirlo. Los Core Web Vitals no son solo una métrica para Google: son, en buena parte, un termómetro de cuánto le estás poniendo fácil a un cliente potencial que ya te ha encontrado.
Si además te preguntas en términos más generales si tu web necesita atención de SEO, no solo por los Core Web Vitals, puedes revisarlo en nuestra guía sobre cómo saber si tu web necesita SEO.
¿Los Core Web Vitals afectan al posicionamiento SEO?
Sí, pero con matices que conviene tener claros para no sacar conclusiones exageradas. Google explica que sus sistemas de posicionamiento buscan recompensar a las páginas que ofrecen una buena experiencia general, y recomienda de forma explícita conseguir buenos Core Web Vitals. Pero también insiste en algo igual de importante: no hay que centrarse en una o dos señales aisladas como si fueran la clave de todo.
Los Core Web Vitals importan, pero no actúan de forma aislada. Google utiliza muchos sistemas y señales para determinar qué resultado es más útil y relevante para una búsqueda: la calidad y relevancia del contenido, los enlaces, la intención de búsqueda y otras señales siguen formando parte de esa evaluación. De hecho, Google explica que puede mostrar el contenido más relevante aunque la experiencia de página sea mejorable, y que tener buenos resultados en el informe de Core Web Vitals no garantiza por sí solo estar en las primeras posiciones.
Dicho de otra forma: una web con Core Web Vitals perfectos pero contenido pobre o poco relevante no va a posicionar bien solo por ser rápida. Y una web con contenido excelente puede posicionar razonablemente bien incluso con Core Web Vitals mejorables, aunque dejará puntos sobre la mesa frente a competidores igual de buenos en contenido pero más rápidos. Los Core Web Vitals forman parte de una estrategia SEO más amplia, no un factor aislado — la misma que desarrollamos en nuestra guía de SEO para pymes y que en BESEOWEB trabajamos a través de nuestro servicio de posicionamiento web.
Cómo saber si tu web cumple los Core Web Vitals
Hay dos herramientas principales para comprobarlo, y conviene no confundirlas.
PageSpeed Insights y Core Web Vitals no son exactamente lo mismo
Es una confusión muy habitual: «tengo un 92 en PageSpeed, mis Core Web Vitals deberían estar bien». No necesariamente. PageSpeed Insights y el informe de Core Web Vitals de Search Console no miden lo mismo, y entender la diferencia evita sacar conclusiones equivocadas.
PageSpeed Insights puede mostrarte dos tipos de datos. Por un lado, datos de laboratorio: una simulación de carga de tu página en condiciones controladas, en el momento exacto en que ejecutas la prueba. Por otro, cuando hay volumen suficiente de tráfico real, también muestra datos de campo procedentes de CrUX (Chrome User Experience Report). Es la base de datos de Google con métricas reales de usuarios de Chrome que han visitado tu web.
Search Console, en cambio, usa solo datos de campo reales: métricas agregadas de los últimos 28 días, agrupadas por URLs con un patrón similar, no cada URL exacta por separado. Google señala expresamente que los datos de laboratorio y los de campo pueden dar resultados distintos entre sí. Por eso una puntuación puntual de 92 sobre 100 en PageSpeed no garantiza que tus Core Web Vitals reales, medidos con tráfico real durante semanas, estén dentro de los umbrales buenos.
En la práctica esto se traduce en dos herramientas con dos funciones distintas. PageSpeed Insights sirve para el detalle técnico: identificar qué elemento concreto está penalizando cada métrica en una URL puntual. El informe de Core Web Vitals de Search Console sirve para ver cómo se comporta tu web con usuarios reales, agrupada por tipo de página. Si quieres profundizar en cómo interpretar el resto de informes de Search Console, lo explicamos en nuestra guía sobre cómo saber si tu SEO está funcionando.
Si nunca has revisado ninguna de las dos herramientas, ese es el primer paso antes de intentar corregir nada. Sin saber qué falla y en qué proporción de tus visitas, cualquier optimización que hagas puede estar apuntando al problema equivocado. Es uno de los primeros puntos que revisamos en cualquier auditoría SEO.
Si al entrar en el informe de Core Web Vitals de Search Console solo ves un aviso de que no hay datos suficientes, no significa que haya un error en tu web: es un caso muy habitual en negocios con poco tráfico, y lo explicamos en las preguntas frecuentes al final del artículo.
Qué suele provocar malos Core Web Vitals
Al optimizar distintas webs, sobre todo en WordPress y Elementor, encontramos patrones que se repetían una y otra vez. No es una lista exhaustiva de causas técnicas: es lo que nos hemos encontrado trabajando con clientes reales, organizado por la métrica a la que afecta cada patrón.
Problemas de LCP: el contenido principal tarda demasiado en aparecer
El patrón más habitual con diferencia es una imagen hero demasiado pesada. La imagen grande de cabecera, sin comprimir ni redimensionar al tamaño real en el que se muestra, suele ser la causa más frecuente de un LCP alto.
Muy relacionado con esto, y algo que vemos constantemente en heroes montados con Elementor: cuando la imagen principal de la cabecera es candidata a LCP, cargarla como background-image mediante CSS puede hacer que el navegador la descubra más tarde que una imagen presente directamente en el HTML. Dependiendo de la implementación, puede ser preferible usar una etiqueta <img> o <picture>, o simplemente priorizar correctamente ese recurso. Es una de las causas de LCP alto más difíciles de detectar a simple vista, porque visualmente la página «se ve» normal.
A esto se suman otros patrones frecuentes: ausencia de priorización del elemento LCP, un servidor lento en responder a la primera petición, CSS que bloquea el renderizado antes de mostrar nada, y fuentes que tardan en cargar. También un exceso de recursos que se cargan nada más entrar en la página, compitiendo todos por el mismo ancho de banda.
Problemas de INP: la web tarda en responder
Aquí el patrón común es demasiado JavaScript ejecutándose en el hilo principal del navegador. Scripts de terceros (chat, analítica, píxeles publicitarios) y tareas largas bloquean la capacidad del navegador para responder a la siguiente interacción del usuario, aunque sea algo tan simple como pulsar un botón.
Lo que más se repite en la práctica son plugins cargados en páginas donde ni siquiera se usan: widgets, formularios, sliders, chats o trackers que se ejecutan en todo el sitio, quiera o no la página concreta que se está visitando. Es habitual encontrar varios plugins pesados cargando su JavaScript completo en una página que solo necesita uno de ellos, o ninguno.
Problemas de CLS: los elementos se mueven mientras carga la página
Los casos más frecuentes: imágenes sin dimensiones (ancho y alto) definidas en el código, que hacen que el resto del contenido se reorganice en cuanto la imagen termina de cargar. También banners o avisos que aparecen después de que la página ya se haya renderizado, empujando el resto del contenido hacia abajo, y avisos de cookies mal implementados que aparecen de golpe sin haber reservado su espacio.
También influyen las fuentes web (el texto cambia de tamaño al cargar la fuente definitiva) y el contenido insertado dinámicamente con JavaScript después de la carga inicial. Lo mismo pasa con los iframes o embeds —vídeos, mapas, formularios externos— sin un espacio reservado de antemano.
Herramientas como WP Rocket para caché o ShortPixel para compresión de imágenes pueden ayudar a corregir varios de estos patrones en WordPress. Pero no sustituyen el diagnóstico: instalar un plugin de caché sin identificar antes qué métrica está fallando suele mejorar poco, o nada.
¿Te has reconocido en varios de estos problemas?
Es un buen momento para parar antes de intentar arreglar nada a ciegas. Cada patrón afecta a una métrica distinta, y corregirlos sin saber cuál está fallando en tu caso concreto suele ser tiempo perdido. En nuestra auditoría SEO revisamos también estos puntos técnicos, no solo el contenido.
Cómo mejorar los Core Web Vitals de tu web
Mejorar los Core Web Vitals no es un tutorial técnico único que sirva igual para cualquier web: depende de qué métrica esté fallando y por qué. Pero sí hay una estrategia general por métrica que aplica en la mayoría de los casos.
Para mejorar el LCP, el objetivo es que el navegador pueda descargar y mostrar el contenido principal cuanto antes. Eso significa usar imágenes en el formato y tamaño adecuados, evitar cargar el elemento LCP únicamente como background-image por CSS, priorizar la carga del elemento principal, optimizar el tiempo de respuesta del servidor y la caché, y reducir los recursos que compiten por cargar antes que el contenido visible.
Para mejorar el INP, el objetivo es reducir el trabajo que tiene que hacer el navegador cuando alguien interactúa con la página. Eso pasa por eliminar JavaScript innecesario, revisar qué scripts de terceros son realmente imprescindibles en cada página (no en todo el sitio por defecto), y dividir las tareas largas para que no bloqueen la respuesta a la interacción del usuario.
Para mejorar el CLS, el objetivo es que nada se mueva sin que el navegador lo sepa de antemano. Eso implica reservar las dimensiones de imágenes, vídeos e iframes, cargar las fuentes de forma que no provoquen saltos de texto, y controlar dónde y cuándo aparece el contenido dinámico y los banners.
Con todo esto sobre la mesa, hay una idea que resume bien nuestro enfoque cuando trabajamos esto con clientes:
No optimices para conseguir un 100 en PageSpeed. Optimiza para que la web funcione mejor para personas reales.
Perseguir la puntuación perfecta en una herramienta puede llevarte a pasar por alto lo que de verdad importa: cómo se comporta tu web con usuarios reales, en sus condiciones reales de conexión y dispositivo.
Todo esto aplica cuando ya tienes una web y quieres optimizarla. Si en cambio estás valorando renovarla o encargar una nueva, el rendimiento no debería ser un apaño que se resuelve después de lanzarla. Es algo que hay que dejar acordado desde el briefing con quien la diseñe. Repasamos justo este punto, entre otros criterios técnicos a exigir, en nuestra guía sobre qué preguntar antes de contratar a un diseñador web.
Preguntas frecuentes sobre Core Web Vitals
¿Qué son los Core Web Vitals?
Son el conjunto de métricas con las que Google mide la experiencia real de un usuario en una web: LCP (velocidad de carga del contenido principal), INP (rapidez de respuesta a las interacciones) y CLS (estabilidad visual mientras carga la página).
¿Cuáles son los 3 Core Web Vitals actuales?
Actualmente son LCP (Largest Contentful Paint), INP (Interaction to Next Paint) y CLS (Cumulative Layout Shift). Los umbrales considerados buenos son ≤ 2,5 segundos para LCP, ≤ 200 milisegundos para INP y ≤ 0,1 para CLS, medidos en el percentil 75.
¿Qué pasó con FID?
FID (First Input Delay) fue la métrica de interactividad utilizada hasta marzo de 2024, cuando Google la sustituyó por INP. Si encuentras contenido que sigue hablando de FID como Core Web Vital vigente, está desactualizado.
¿Una puntuación de 100 en PageSpeed significa que mi web tiene buenos Core Web Vitals?
No necesariamente. PageSpeed Insights puede mostrar datos de laboratorio (una simulación puntual) y datos de campo (de usuarios reales, vía CrUX). Google señala que ambos pueden dar resultados distintos, así que una puntuación perfecta en la prueba puntual no garantiza buenos Core Web Vitals reales.
¿Por qué Search Console no muestra datos de Core Web Vitals de mi web?
Porque el informe necesita suficientes datos de usuarios reales procedentes de Chrome. Google explica que la pantalla de «no hay datos disponibles» aparece cuando la propiedad es nueva en Search Console o cuando no hay suficiente información en CrUX para el tipo de dispositivo elegido, móvil o escritorio. En ese caso puedes utilizar PageSpeed Insights y sus datos de laboratorio para diagnosticar problemas, sabiendo que no sustituyen a los datos reales de usuarios.
¿Por qué mi web pasa Core Web Vitals en escritorio pero no en móvil?
Porque Google mide y evalúa móvil y escritorio por separado, no como una media conjunta. Es habitual que una web con buen rendimiento en escritorio falle en móvil, sobre todo por peso de imágenes y JavaScript.
¿Los Core Web Vitals afectan al SEO?
Sí. Google confirma que sus sistemas de posicionamiento utilizan los Core Web Vitals, pero son solo una parte de la experiencia general de página y no garantizan mejores posiciones por sí solos. La relevancia y calidad del contenido, los enlaces y otras muchas señales también intervienen en el posicionamiento.
¿Cuánto tarda Google en detectar una mejora?
No hay un plazo exacto. El informe de Core Web Vitals de Search Console se basa en datos de campo de CrUX, agregados de los últimos 28 días. Una mejora tarda en reflejarse mientras se acumula suficiente tráfico real posterior al cambio dentro de esa ventana. Si lo que quieres saber es cuánto tarda el SEO en general en dar resultados, no solo los Core Web Vitals, lo explicamos con más detalle en nuestra guía sobre cuánto tarda el SEO en dar resultados.
¿Quieres saber si tu web está perdiendo clientes por esto?
Si tu web falla Core Web Vitals, el primer paso no debería ser instalar más plugins o empezar a modificar cosas al azar. Hay que identificar qué métrica falla y qué la está provocando. En BESEOWEB podemos analizar tus Core Web Vitals reales, localizar qué está condicionando el rendimiento y priorizar las mejoras que tienen sentido para tu web. Contacta con nuestro equipo y lo vemos juntos.
