Saltar al contenido

Core Web Vitals: cómo mejorarlos

Qué miden LCP, INP y CLS, cómo revisarlos con datos de campo y qué tocar primero para mejorar tus Core Web Vitals.

seo
Panel de rendimiento web con métricas de velocidad de carga, respuesta a la interacción y estabilidad visual

Los Core Web Vitals son las tres métricas con las que Google mide la experiencia de carga de una página, y para mejorarlos tienes que trabajar tres frentes distintos: cuánto tarda en pintarse el contenido principal (LCP), cómo de rápido responde la página cuando alguien la toca (INP) y cuánto se mueve el diseño mientras carga (CLS). No es una sola palanca, son tres, y cada una se arregla de una forma diferente.

Llevo años optimizando webs de pymes y casi siempre me encuentro el mismo patrón: plantillas cargadas de scripts que no se usan, imágenes pesadas sin comprimir y hosting lento. La buena noticia es que la mayoría de estos fallos se arreglan sin reescribir la web entera. En este artículo te explico qué mide cada métrica, cómo medirlas con datos de usuarios de verdad y, sobre todo, qué tocar primero para pasar de rojo a verde.

Puntos clave

  • Los tres umbrales para aprobar: LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1 (web.dev, Google)
  • Google no mira tu página en un laboratorio, mira a los usuarios que la visitan: necesitas que el 75% de las visitas tengan una experiencia buena en cada métrica para aprobar (Google Search Console)
  • La velocidad sigue floja de forma general: en un análisis de 208.085 páginas, solo el 53,77% tenía un LCP bueno, es decir, casi la mitad cargan su contenido principal demasiado despacio (Backlinko, abril 2025)
  • Desde el 12 de marzo de 2024, INP sustituyó a FID como métrica oficial: ya no se mide solo el primer clic, sino la respuesta a lo largo de toda la visita (Google Search Central)
  • El orden manda: primero ataca el LCP (el que más cuesta aprobar), luego el INP y al final el CLS, que suele ser el arreglo más rápido

Si todavía no tienes claro dónde encaja el rendimiento dentro del SEO completo, lo explico en mi guía de qué es el SEO y cómo funciona para pymes. Y si buscas la revisión técnica completa (rastreo, indexación, móvil), la tienes en mi checklist de auditoría SEO técnica. Aquí voy directo a la velocidad.

Qué mide cada Core Web Vital

Antes de tocar nada conviene entender qué mide cada métrica, porque cada una apunta a un problema distinto de tu web.

LCP (Largest Contentful Paint). Mide cuánto tarda en pintarse el elemento más grande visible al cargar, normalmente la imagen principal o el titular de la portada. Es la métrica de la velocidad percibida: es el momento en el que el usuario siente que la página “ya está”. Se considera buena por debajo de 2,5 segundos, mejorable entre 2,5 y 4 segundos, y mala por encima de 4.

INP (Interaction to Next Paint). Mide cómo de rápido responde la página cuando alguien interactúa (un clic, un toque, escribir en un campo). Sustituyó a FID en marzo de 2024, y el cambio importa: FID medía solo la primera interacción, INP mide todas las de la visita y se queda con la peor. Se considera buena por debajo de 200 milisegundos, mejorable entre 200 y 500, y mala por encima de 500.

CLS (Cumulative Layout Shift). Mide cuánto se mueve el diseño mientras carga. Ese salto molesto en el que vas a pulsar un botón y de repente se desplaza porque ha entrado un banner tarde: eso es CLS. No se mide en segundos, sino en una puntuación de desplazamiento. Se considera bueno por debajo de 0,1, mejorable entre 0,1 y 0,25, y malo por encima de 0,25.

Cómo se miden de verdad (campo, no laboratorio)

Este es el error que veo más a menudo: alguien abre PageSpeed Insights, ve un número de laboratorio bonito y da por hecho que aprueba. Google no puntúa así.

Google usa datos de campo, los de tus usuarios de verdad, recogidos en el informe CrUX (Chrome User Experience Report). No le vale con que tu página cargue rápido en un test aislado, necesita que cargue rápido para la gente que la visita de verdad, con sus móviles y sus conexiones. Y no mira la media, mira el percentil 75: para aprobar una métrica, el 75% de las visitas tiene que tener una experiencia buena. Basta con que una cuarta parte de tus usuarios lo pase mal para suspender.

Dónde mirar tus datos de campo:

  • Google Search Console, informe de Core Web Vitals: te agrupa las URLs por estado (buena, a mejorar, mala) con datos de campo. Es tu fuente de verdad.
  • PageSpeed Insights: fíjate en la sección “Datos de campo” de arriba, no en la de laboratorio de abajo. Si una URL no tiene tráfico suficiente, no habrá datos de campo y tendrás que guiarte por el laboratorio como aproximación.

Con eso claro, vamos a lo que de verdad mueve la aguja: cómo arreglar cada una.

Cómo mejorar el LCP

El LCP es el que más cuesta aprobar y por el que yo empiezo siempre. Casi la mitad de las webs suspende aquí, así que hay mucho margen. Las causas habituales en pymes son casi siempre las mismas.

Optimiza la imagen principal. Si tu LCP es una imagen (lo más común), sírvela comprimida y en formato moderno (WebP o AVIF), con el tamaño exacto que se muestra, no una foto de 4000 píxeles reescalada por CSS. Y quítale el loading="lazy" a esa imagen concreta: la carga diferida es buena para lo que está más abajo, pero retrasa justo lo que Google cronometra.

Reduce el peso muerto que bloquea la carga. Cada script de terceros que metes (chats, mapas, píxeles de seguimiento, plugins que ya no usas) compite por bloquear el pintado. Haz limpieza: quita lo que no aporta y carga en diferido lo que pueda esperar.

Mejora el servidor y la caché. Un hosting lento retrasa el primer byte, y ese retraso se arrastra a todo lo demás. Un buen alojamiento, una caché decente y un CDN que sirva los recursos desde cerca del usuario recortan segundos sin tocar el diseño.

Cómo mejorar el INP

El INP es un problema de JavaScript. Cuando el usuario toca algo y la página tarda en responder, casi siempre es porque el hilo principal del navegador está ocupado ejecutando código pesado y no puede atender la interacción a tiempo.

Adelgaza el JavaScript. Menos código que ejecutar significa un hilo principal más libre para responder. Elimina librerías que arrastras sin usar, divide los paquetes grandes y carga solo lo que hace falta en cada página.

Parte las tareas largas. Una función que bloquea el hilo 300 milisegundos deja al usuario esperando. Trocear ese trabajo en tareas más pequeñas o mandarlo a segundo plano libera el navegador para responder al toque enseguida.

Vigila los scripts de terceros. El mismo chat o widget que te lastra el LCP suele lastrarte el INP. Mídelos, y si uno te está costando la interactividad, cárgalo más tarde o busca una alternativa más ligera.

Cómo mejorar el CLS

El CLS suele ser el arreglo más rápido de los tres, y muchas veces se soluciona reservando el espacio de las cosas antes de que carguen.

Reserva sitio para imágenes y vídeos. Declara el ancho y el alto de cada imagen (o su proporción por CSS) para que el navegador guarde el hueco antes de descargarla. Sin eso, el texto de debajo salta cuando la imagen aparece.

Deja hueco a los anuncios y elementos que entran tarde. Banners, cookies, avisos: si aparecen sin espacio reservado, empujan el contenido y disparan el CLS. Reserva su altura desde el principio.

Precarga las fuentes. Un cambio brusco de tipografía cuando carga la fuente definitiva provoca reflujo. Precargar la fuente y usar font-display: swap con una alternativa de sistema parecida reduce ese salto.

Por dónde empezar

Si tuviera que resumirlo en una hoja de ruta, sería esta. Primero mide con datos de campo en Search Console para saber qué métrica suspendes de verdad, no cuál crees que suspendes. Después ataca el LCP, que es el que más pesa y el que más webs suspenden, casi siempre optimizando la imagen principal y el hosting. Luego el INP, revisando el JavaScript. Y al final el CLS, reservando espacio, que suele ser una tarde de trabajo.

Y una idea que repito mucho: de nada sirve optimizar la velocidad de una página que Google ni siquiera indexa. Por eso el rendimiento va después del rastreo y la indexación en cualquier auditoría seria, como cuento en mi checklist técnico.

Si has medido tu web y te salen números en rojo que no sabes por dónde coger, es justo el tipo de trabajo que hago a diario. Puedes ver cómo enfoco el posicionamiento orgánico como consultor SEO o escribirme directamente desde la página de contacto y le echo un ojo a tus Core Web Vitals para decirte qué arreglaría primero.

Preguntas frecuentes

¿Cuáles son los valores buenos de los Core Web Vitals? LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. Para aprobar, el 75% de tus visitas tiene que estar dentro de esos umbrales.

¿Los Core Web Vitals afectan al posicionamiento? Sí, son una señal de posicionamiento confirmada por Google, aunque no la más fuerte. Por sí solos no te suben a la primera posición, pero cuando dos páginas compiten por la misma búsqueda, la más rápida tiene ventaja. Y una experiencia lenta hunde las conversiones aunque el ranking aguante.

¿Cada cuánto se actualizan mis datos en Search Console? El informe usa una ventana móvil de 28 días de datos de campo, así que los cambios que hagas tardan semanas en reflejarse del todo. Mide, aplica los arreglos y ten paciencia antes de dar por hecho que no funcionó.

Raúl Veneri
Raúl Veneri · Consultor de Agentic Marketing en Málaga

Consultor independiente. Automatizo SEO, GEO, campañas SEM y tracking con agentes IA. Ayudo a negocios a escalar su marketing sin multiplicar el equipo ni depender de intermediarios.