Ir al contenido
Lexiik
performance

Core Web Vitals: LCP, INP, CLS — las métricas SEO de Google explicadas

Última actualización : 17 de febrero de 2026

Los Core Web Vitals son tres métricas definidas por Google para medir la calidad de la experiencia del usuario en una página web. Introducidas en 2020 e integradas en el algoritmo de clasificación de Google en 2021 mediante la actualización Page Experience, son hoy en día un factor SEO oficial. Para las tiendas de comercio electrónico, entender y optimizar estos tres indicadores — LCP, INP y CLS — se ha vuelto tan importante como el trabajo de contenidos o el linkbuilding.

¿Qué son los Core Web Vitals?

Antes de los Core Web Vitals, la velocidad de una página web se medía mediante métricas técnicas como el Time to First Byte (TTFB) o el First Contentful Paint (FCP) — indicadores útiles para los desarrolladores, pero que no reflejaban fielmente lo que experimenta realmente un usuario. Google quiso cubrir esa brecha definiendo tres métricas centradas en la experiencia percibida: ¿con qué rapidez aparece el contenido principal? ¿Responde la página rápidamente a las interacciones? ¿El contenido se desplaza de forma inesperada?

Estas tres preguntas corresponden exactamente a los tres Core Web Vitals: LCP para la velocidad de carga, INP para la capacidad de respuesta y CLS para la estabilidad visual. Google recopila estos datos de forma agregada a través de Chrome (el Chrome User Experience Report, o CrUX) y los utiliza en su algoritmo para premiar las páginas que ofrecen una buena experiencia de usuario.

LCP — Largest Contentful Paint: la velocidad de carga del contenido principal

El LCP (Largest Contentful Paint) mide el tiempo transcurrido desde que comienza la carga de una página hasta que su elemento visible más grande se renderiza completamente en pantalla. Este elemento puede ser una imagen, una etiqueta de vídeo, un bloque de texto o cualquier otro contenido en el área visible sin desplazamiento (above the fold).

En las tiendas de comercio electrónico, el LCP casi siempre está determinado por la imagen principal del producto — la fotografía packshot que ocupa una gran parte de la pantalla en la parte superior de la ficha de producto. Esta imagen suele ser la más pesada de la página y, por tanto, la que más tiempo tarda en cargarse. Por eso, la optimización del LCP en el contexto del e-commerce pasa prioritariamente por mejorar la entrega de imágenes.

Buen LCP

Inferior a 2,5 segundos. Google considera que la experiencia del usuario es satisfactoria.

⚠️

LCP a mejorar

Entre 2,5 y 4 segundos. La página está en la zona naranja — se requieren mejoras.

LCP deficiente

Superior a 4 segundos. Google penaliza la página en sus resultados de búsqueda.

Las principales causas de un LCP deficiente en las tiendas de comercio electrónico son: imágenes de producto demasiado pesadas (JPEG sin optimizar), un alojamiento lento con un TTFB elevado, la ausencia de CDN que provoca latencia geográfica, y el lazy loading aplicado incorrectamente a la imagen principal. Este último error es frecuente: el atributo loading="lazy" no debe aplicarse nunca a la imagen above the fold, ya que impide precisamente que el navegador cargue rápidamente el elemento que Google utiliza para calcular el LCP.

INP — Interaction to Next Paint: la capacidad de respuesta de la página

El INP (Interaction to Next Paint) reemplazó al FID (First Input Delay) en marzo de 2024 como Core Web Vital oficial. Mientras que el FID solo medía el retraso de respuesta a la primera interacción, el INP mide la latencia de todas las interacciones del usuario durante toda la vida de la página — clics, toques en móvil, pulsaciones de teclado — y toma el valor en el percentil 98.

En la práctica, el INP mide el tiempo entre el momento en que el usuario interactúa (por ejemplo, hace clic en un botón «Añadir al carrito») y el momento en que el navegador muestra visualmente la respuesta a esa interacción. Si su JavaScript es pesado y monopoliza el hilo principal del navegador, el INP será elevado: la página parece «congelada» o lenta al reaccionar.

Buen INP

Inferior a 200 milisegundos. La interacción parece instantánea para el usuario.

⚠️

INP a mejorar

Entre 200 y 500 milisegundos. El usuario percibe un ligero retraso.

INP deficiente

Superior a 500 milisegundos. La interacción parece lenta y deficiente.

Para las tiendas de comercio electrónico, las principales causas de un INP deficiente son: JavaScript de terceros excesivo (widgets de chat, trackers de análisis, scripts de comparadores de precios), manejadores de eventos demasiado pesados, y bibliotecas de interfaz de usuario voluminosas cargadas de forma síncrona. La optimización del INP pasa por auditar y reducir el JavaScript no esencial, y por diferir la carga de scripts de terceros hasta después de la interacción del usuario.

CLS — Cumulative Layout Shift: la estabilidad visual de la página

El CLS (Cumulative Layout Shift) mide en qué medida los elementos visibles de la página se desplazan de forma inesperada durante la carga. Cada vez que un elemento visible se mueve — un texto que salta porque una imagen se carga sin dimensiones reservadas, un banner publicitario que se inserta y empuja el contenido hacia abajo — el CLS aumenta.

Un CLS elevado es especialmente frustrante en móvil: el usuario está a punto de tocar un enlace y, en el momento en que su dedo toca la pantalla, una imagen se carga y desplaza el contenido. Acaba tocando otro enlace — a veces «Añadir al carrito» cuando quería leer la descripción. Es una experiencia degradada que Google penaliza.

Buen CLS

Inferior a 0,1. La página es visualmente estable durante la carga.

⚠️

CLS a mejorar

Entre 0,1 y 0,25. Desplazamientos notables afectan a la experiencia.

CLS deficiente

Superior a 0,25. La página es inestable y penalizada por Google.

La principal causa de CLS elevado en las tiendas de comercio electrónico es la ausencia de dimensiones explícitas en las imágenes (atributos width y height en el HTML). Cuando el navegador analiza el HTML y encuentra una etiqueta img sin dimensiones, no puede reservar el espacio necesario en el diseño. Cuando la imagen se carga y revela sus dimensiones reales, el diseño se recalcula y todo se desplaza. La solución es sencilla: especificar siempre width y height en las etiquetas img, o utilizar la propiedad CSS aspect-ratio.

Cómo influyen los Core Web Vitals en el posicionamiento de Google

Google utiliza los Core Web Vitals como señal de posicionamiento desde junio de 2021. Técnicamente forman parte de una señal más amplia llamada «Page Experience», que también incluye la compatibilidad con móviles, la seguridad HTTPS y la ausencia de contenidos intersticiales intrusivos. Google ha aclarado que el contenido de calidad sigue siendo la señal dominante, pero que los Core Web Vitals pueden marcar la diferencia entre dos páginas de calidad equivalente.

En la práctica, Google evalúa los Core Web Vitals a través de dos fuentes de datos: los datos de campo (field data), recopilados de forma anónima a través de Chrome en visitas reales de usuarios, y los datos de laboratorio (lab data), calculados por herramientas como Lighthouse en condiciones controladas. Los datos de campo — agregados en el Chrome User Experience Report (CrUX) — son los que alimentan el algoritmo. Una página debe recibir suficiente tráfico de Chrome para aparecer en CrUX; las páginas poco visitadas se evalúan a nivel de dominio o URL raíz.

Mobile-first: los Core Web Vitals se evalúan prioritariamente en móvil

Google prioriza los datos móviles al evaluar los Core Web Vitals en su algoritmo. Las conexiones móviles son más lentas y los procesadores menos potentes que en escritorio. Una tienda que obtiene buenas puntuaciones en escritorio puede tener malas puntuaciones en móvil si sus imágenes no están optimizadas para redes 4G/5G.

Desafíos específicos del comercio electrónico

Las tiendas online concentran varios desafíos que hacen que la optimización de los Core Web Vitals sea especialmente difícil. En primer lugar, el volumen de imágenes: una tienda con 1.000 referencias y 5 fotos por producto debe gestionar 5.000 imágenes, cada una de las cuales debe optimizarse en tamaño, formato y dimensiones. Luego, la complejidad de las páginas: fichas de producto con galerías, carruseles, zooms, pestañas de descripción, widgets de reseñas de clientes, configuradores de variantes — todos son componentes JavaScript que pueden degradar el INP.

  • Imágenes de producto pesadas sin optimización de formato (JPEG sin optimizar frente a WebP/AVIF)
  • Carruseles y galerías con JavaScript de terceros que bloquean el hilo principal
  • Lazy loading mal configurado aplicado a la imagen hero (degrada el LCP)
  • Imágenes sin atributos width/height explícitos en las plantillas (degrada el CLS)
  • Scripts de seguimiento de análisis y remarketing cargados de forma síncrona (degrada el INP)
  • Alojamiento compartido lento con TTFB elevado que afecta a todos los Core Web Vitals

Cómo Lexiik mejora sus Core Web Vitals

Lexiik actúa principalmente sobre el LCP y el CLS — los dos Core Web Vitals más directamente relacionados con las imágenes. Para el LCP, el CDN de Cloudflare reduce drásticamente el tiempo de entrega de la imagen principal del producto sirviéndola desde un nodo geográficamente cercano al visitante, con cabeceras de caché de un año. Para el CLS, Lexiik garantiza que las imágenes servidas desde el CDN mantengan sus dimensiones originales, permitiendo al navegador reservar el espacio correcto antes de la carga completa.

La conversión automática a WebP y AVIF reduce el tamaño de las imágenes entre un 30 y un 50 % sin pérdida visible de calidad, lo que no solo acelera el LCP sino que también mejora el conjunto de las métricas de rendimiento percibidas. En conexiones móviles 4G, pasar de una imagen JPEG de 400 KB a una imagen WebP de 120 KB puede reducir el LCP de 3,5 segundos a menos de 1,5 segundos.

Cómo verificar sus puntuaciones de Core Web Vitals

Varias herramientas permiten medir y supervisar sus Core Web Vitals. Google Search Console es la herramienta de referencia para los datos de campo reales (CrUX): la sección «Experiencia de página» muestra el porcentaje de URLs de su sitio clasificadas como «Buena experiencia», «A mejorar» o «Mala experiencia», con un desglose por métrica. Es esta herramienta la que refleja lo que Google realmente ve.

  • Google Search Console (search.google.com/search-console): datos de campo reales, por URL o grupo de URLs
  • PageSpeed Insights (pagespeed.web.dev): datos de campo + datos de laboratorio para una URL específica
  • Google Lighthouse (integrado en Chrome DevTools): solo datos de laboratorio, útil para el desarrollo
  • Chrome DevTools > pestaña Rendimiento: análisis detallado de eventos de renderizado e interacciones
  • web.dev/measure: herramienta de Google para un análisis rápido en línea

Datos de campo vs. datos de laboratorio

Los datos de laboratorio (Lighthouse) miden la página en condiciones simuladas sobre una red simulada. Los datos de campo (CrUX) reflejan las visitas reales de usuarios reales. Estas dos fuentes pueden divergir significativamente. Para el SEO, lo que importa son los datos de campo. Para el diagnóstico de problemas, los datos de laboratorio son más útiles porque ofrecen un detalle preciso de las causas.