Abres tu web desde el móvil. Tardas cuatro segundos en ver algo útil. Intentas hacer clic en el menú y el botón se mueve justo cuando vas a tocarlo. La página salta. Vuelves atrás.

Eso es exactamente lo que Google mide con los Core Web Vitals. Y si tu web lo hace, estás perdiendo posicionamiento y clientes al mismo tiempo.

Los Core Web Vitals llevan siendo un factor oficial de ranking desde 2021, pero su peso en el algoritmo ha ido creciendo progresivamente. En 2026, con Google priorizando más que nunca la experiencia del usuario, ignorarlos es una decisión cara.

La buena noticia es que entenderlos no requiere ser programador. Y mejorarlos tampoco, al menos en los casos más frecuentes.

Esto es lo que necesitas saber.

Qué son los Core Web Vitals y por qué le importan a Google

Los Core Web Vitals son un conjunto de métricas que Google usa para medir la experiencia real de los usuarios cuando cargan y usan una página web. No miden lo rápido que carga el HTML en un servidor: miden lo que el usuario percibe en su pantalla, en su dispositivo real, en sus condiciones reales de conexión.

Google lleva años dejando claro que su objetivo no es solo encontrar el contenido más relevante, sino también el que ofrece la mejor experiencia cuando alguien llega a él. Una página que tarda seis segundos en cargar, aunque tenga el mejor artículo del mundo, pierde frente a una que tarda dos y tiene contenido casi tan bueno.

En 2026 hay tres métricas principales que componen los Core Web Vitals. Las tres tienen nombre propio, umbral de referencia y formas concretas de mejorarlas.

LCP: Largest Contentful Paint

Qué mide

El LCP mide cuánto tarda en aparecer el elemento más grande visible en la pantalla inicial de la página. Ese elemento suele ser una imagen destacada, el titular principal o un bloque de contenido grande.

En términos simples: ¿cuánto tarda el usuario en ver algo con sustancia cuando abre tu página?

Los umbrales de referencia

  • Bueno: menos de 2,5 segundos.
  • Necesita mejora: entre 2,5 y 4 segundos.
  • Malo: más de 4 segundos.

Estos umbrales están medidos en el percentil 75 de tus usuarios, es decir, al menos el 75% de las visitas tienen que cumplirlos para que Google considere que tu página está en el rango correcto.

Por qué falla el LCP con más frecuencia

La causa más habitual de un LCP lento es una imagen demasiado pesada sin optimizar. Si la imagen principal de tu página pesa 3 megabytes y no está comprimida ni en formato moderno, eso solo puede hacer que el LCP se vaya fácilmente a 4 o 5 segundos en móvil con conexión normal.

Otras causas frecuentes: servidor lento sin caché configurada, recursos bloqueantes que retrasan la carga inicial (scripts de terceros que se cargan antes de lo que el usuario ve), o fuentes tipográficas que tardan en cargarse y bloquean el texto.

Cómo mejorarlo sin tocar código

Comprime tus imágenes: usa herramientas como Squoosh (gratuita, de Google) o TinyPNG para reducir el peso de las imágenes antes de subirlas a tu web. Una imagen de 3MB puede bajar a 200KB sin pérdida visible de calidad.

Convierte imágenes a WebP: el formato WebP pesa entre un 25% y un 35% menos que JPEG para la misma calidad visual. Si tu CMS es WordPress, plugins como ShortPixel o Imagify convierten automáticamente tus imágenes al subirlas.

Activa la caché del servidor: si tu hosting tiene opción de caché, actívala. Hace que las páginas se sirvan mucho más rápido para usuarios que ya las han visitado y también mejora el tiempo de respuesta general.

Usa un CDN: una red de distribución de contenido sirve tu web desde servidores más cercanos geográficamente al usuario. Para negocios españoles que tienen sus servidores en servidores europeos pero usuarios en otras zonas, mejora notablemente.

INP: Interaction to Next Paint

Qué mide

El INP es la métrica más reciente de los tres Core Web Vitals. Sustituyó al FID (First Input Delay) en marzo de 2024 y mide algo diferente y más completo: la respuesta de la página a las interacciones del usuario a lo largo de toda la visita, no solo al primer clic.

En términos simples: cuando el usuario hace clic en un botón, toca un menú o interactúa con cualquier elemento de la página, ¿cuánto tarda la página en responder visualmente? Ese retraso es lo que mide el INP.

Los umbrales de referencia

  • Bueno: menos de 200 milisegundos.
  • Necesita mejora: entre 200 y 500 milisegundos.
  • Malo: más de 500 milisegundos.

200 milisegundos es menos de un cuarto de segundo. Para el usuario, 200ms se percibe como respuesta casi instantánea. 500ms o más se percibe como que la página está atascada o va lenta.

Por qué falla el INP con más frecuencia

La causa más habitual de un INP alto es el exceso de JavaScript ejecutándose en el hilo principal del navegador. Cuando el navegador está ocupado ejecutando scripts, no puede responder a las interacciones del usuario, y el tiempo de respuesta sube.

Plugins y scripts de terceros son frecuentemente los culpables: herramientas de chat en vivo, píxeles de seguimiento, widgets de redes sociales, scripts de analítica mal configurados. Cada uno por separado puede parecer inocente, pero la suma de varios puede hacer que el hilo principal esté constantemente ocupado.

Cómo mejorarlo sin tocar código

Audita los scripts de terceros que tienes instalados: abre las herramientas de desarrollador de tu navegador (F12 en Chrome), ve a la pestaña Network y filtra por tipo «Script». Verás cuántos scripts se cargan y cuánto tardan. Si hay alguno que no usas activamente, elimínalo.

Carga los scripts de terceros de forma diferida: si tu CMS lo permite (WordPress tiene plugins para esto), configura que los scripts de terceros no esenciales se carguen después de que la página sea interactiva, no antes.

Reduce el número de plugins activos: en WordPress especialmente, cada plugin activo añade código que puede afectar al rendimiento. Desactiva los que no usas.

CLS: Cumulative Layout Shift

Qué mide

El CLS mide la estabilidad visual de la página: cuánto se mueven o saltan los elementos mientras la página termina de cargar. Ese fenómeno irritante de hacer clic en un botón y que en el último segundo aparezca un banner justo encima y hagas clic en algo que no querías, eso es CLS alto.

Los umbrales de referencia

  • Bueno: menos de 0,1.
  • Necesita mejora: entre 0,1 y 0,25.
  • Malo: más de 0,25.

El valor del CLS es adimensional, no tiene unidades. Un CLS de 0 sería una página perfectamente estable donde nada se mueve inesperadamente. Cuanto más alto, más saltos y desplazamientos experimenta el usuario.

Por qué falla el CLS con más frecuencia

Las causas más frecuentes son:

Imágenes sin dimensiones definidas: si tu código HTML no especifica el ancho y el alto de las imágenes, el navegador no reserva espacio para ellas mientras cargan. Cuando finalmente aparecen, empujan hacia abajo todo el contenido que ya estaba visible.

Anuncios, banners o embeds que aparecen tarde: los bloques de publicidad, los widgets de Instagram o Twitter embebidos y los banners de cookies que aparecen después de que la página ya se ha cargado generan desplazamiento de contenido.

Fuentes tipográficas que hacen swap: cuando usas fuentes de Google Fonts o similares, el navegador a veces muestra primero el texto en la fuente del sistema y luego lo reemplaza por la fuente correcta, haciendo que el texto se desplace.

Cómo mejorarlo sin tocar código

Añade dimensiones a tus imágenes: en la mayoría de CMS esto se puede configurar desde el panel de subida de imágenes. Asegúrate de que cada imagen tiene su ancho y alto definidos.

Configura el aviso de cookies para que aparezca sin desplazar el contenido: muchos plugins de cookies mal configurados hacen que el banner aparezca empujando el contenido hacia abajo. Configúralo para que se superponga al contenido en lugar de desplazarlo.

Usa font-display: swap con precaución: si tienes control sobre la configuración de fuentes, el atributo font-display: optional puede ser más efectivo que swap para reducir el CLS relacionado con tipografía.

Cómo medir tus Core Web Vitals

Antes de mejorar nada, necesitas saber en qué punto estás. Estas son las herramientas más útiles, todas gratuitas.

Google PageSpeed Insights

La herramienta más directa. Ve a pagespeed.web.dev, introduce la URL de tu web y obtienes en segundos los valores de LCP, INP y CLS tanto para móvil como para escritorio.

Importante: analiza siempre los resultados de móvil como prioridad. Google indexa tu web con el criterio de la experiencia móvil (mobile-first indexing). Si tu móvil puntúa mal aunque tu escritorio puntúe bien, el posicionamiento sufre.

El informe también te indica los problemas concretos que está detectando y su impacto estimado, lo que te ayuda a priorizar.

Google Search Console: informe de Experiencia de página

Si tienes Search Console configurado (y deberías tenerlo), el informe de Experiencia de página te muestra el estado de tus Core Web Vitals basado en datos reales de usuarios que han visitado tu web, no en una simulación de laboratorio.

La diferencia importa: los datos de campo (usuarios reales) y los datos de laboratorio (simulación) pueden diferir. Google usa los datos de campo para el ranking cuando están disponibles.

Chrome DevTools: pestaña Lighthouse

Si abres tu web en Chrome, pulsas F12 y vas a la pestaña Lighthouse, puedes hacer un análisis completo de rendimiento en tu propio navegador. Útil para hacer pruebas antes de publicar cambios.

Cuándo necesitas un desarrollador

Hay mejoras que puedes hacer tú sin tocar código. Y hay mejoras que requieren a alguien que sepa lo que hace.

Puedes hacer tú:

  • Comprimir y convertir imágenes antes de subirlas.
  • Configurar plugins de caché y optimización en WordPress.
  • Desactivar plugins o scripts innecesarios.
  • Configurar correctamente el plugin de cookies.
  • Añadir dimensiones a imágenes desde el panel del CMS.

Necesitas un desarrollador para:

  • Optimizar el código CSS y JavaScript a nivel de arquitectura.
  • Implementar lazy loading correctamente si tu CMS no lo hace automáticamente.
  • Configurar un CDN con las reglas correctas.
  • Migrar a un servidor con mejor rendimiento manteniendo toda la configuración.
  • Resolver CLS causado por comportamientos específicos del código personalizado.
  • Optimizar el Critical Rendering Path de la web.

La regla práctica es: si puedes hacerlo desde el panel de administración de tu CMS sin tocar archivos de código, adelante. Si implica editar archivos PHP, JavaScript o CSS directamente, busca a alguien que sepa hacerlo. Los errores en esos archivos pueden romper la web.

La relación entre Core Web Vitals y el SEO local

Puede que te preguntes por qué este tema aparece en la categoría de SEO local y no solo en una de técnica web general. La respuesta es directa.

Las búsquedas locales se hacen mayoritariamente desde móvil. Un usuario que busca «dentista en Sevilla» desde su teléfono y llega a tu web tiene cero tolerancia a la lentitud. Si tarda más de tres segundos en ver algo relevante, cierra y vuelve a Google a clicar en el siguiente resultado.

Y Google lo sabe. Por eso el rendimiento móvil pesa en el posicionamiento local quizás más que en ningún otro tipo de búsqueda. Una web local lenta no solo pierde usuarios: pierde posiciones en el Local Pack y en los resultados orgánicos locales frente a competidores con mejor rendimiento.

Además, en el contexto de los AI Overviews y la búsqueda generativa, Google tiene más motivos que nunca para priorizar fuentes rápidas y estables. Si tu página es lenta, el sistema simplemente encuentra la respuesta en otro sitio.

En resumen

Los Core Web Vitals no son un capricho técnico de Google. Son la traducción en métricas de algo que cualquier propietario de negocio ya sabe por intuición: si tu web va lenta, la gente se va.

LCP mide si tu página carga rápido. INP mide si responde bien cuando el usuario interactúa. CLS mide si es estable y no salta inesperadamente. Los tres juntos dibujan la experiencia real que tiene alguien cuando visita tu web desde el móvil.

Mejorar los tres no requiere ser desarrollador en la mayoría de casos. Requiere saber qué medir, entender qué lo está causando y aplicar las soluciones correctas en el orden adecuado.

Empieza por medir. Luego prioriza las mejoras con mayor impacto. Y si hay algo que no puedes hacer tú, al menos sabrás exactamente qué pedirle a quien lo haga.

Preguntas frecuentes sobre Core Web Vitals

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

De forma indirecta, sí. El posicionamiento en el Local Pack depende principalmente de la relevancia, la proximidad y la prominencia de la ficha de GBP. Pero la web enlazada desde la ficha sí recibe el impacto de los Core Web Vitals en los resultados orgánicos. Y una web lenta pierde usuarios antes de que conviertan, independientemente de cómo haya llegado a ella.

¿Mi web tiene que sacar 100 en PageSpeed Insights para posicionar bien?

No. Google no exige puntuación perfecta, exige que los valores de LCP, INP y CLS estén en el rango «Bueno» para el grueso de tus usuarios. Una puntuación de 70-80 en PageSpeed con los tres Core Web Vitals en verde es perfectamente funcional para el SEO. Perseguir el 100 tiene rendimientos decrecientes muy rápidos.

¿Tengo que medir los Core Web Vitals para el móvil o para el escritorio?

Ambos, pero prioriza el móvil. Google usa mobile-first indexing, lo que significa que evalúa tu web principalmente desde la perspectiva del usuario de móvil. Si tu escritorio va bien pero el móvil va mal, el posicionamiento sufre de todas formas.

¿Con qué frecuencia debería revisar mis Core Web Vitals?

Cada vez que hagas cambios significativos en tu web: nuevo diseño, nuevos plugins, nuevas imágenes o nuevas secciones. Y como mínimo, una revisión trimestral aunque no hayas hecho cambios, porque los scripts de terceros (analytics, chat, publicidad) se actualizan solos y a veces introducen regresiones de rendimiento.

¿Qué hosting recomendáis para tener buenas puntuaciones en Core Web Vitals?

El hosting tiene mucho que ver, especialmente en el LCP. Los hostings de entrada de gama baja con servidores compartidos sin caché generan tiempos de respuesta altos que arrastran el LCP hacia abajo. Para negocios locales, un hosting de calidad media con SSD, PHP 8+, caché del servidor activada y servidores en Europa es suficiente en la mayoría de casos. No hace falta un servidor dedicado para tener buenos Core Web Vitals.

¿Quieres que auditemos el rendimiento técnico de tu web y te digamos exactamente qué está frenando tu posicionamiento? Hablemos y lo miramos.

Artículo escrito por el equipo de Blanko • Roto Agencia digital especializada en SEO local, automatización con IA y estrategia de crecimiento para negocios reales.