Cómo mejorar los Core Web Vitals de tu tienda online

Tienes tráfico, tienes producto, tienes campañas pagando clics. Y aun así las ventas no salen como deberían. Antes de tocar precios o cambiar la creatividad de los anuncios, vale la pena mirar algo que casi nadie del equipo de marketing revisa: cuánto tarda tu tienda en cargar y cómo se siente al usarla desde el móvil. Ahí, en esos tres o cuatro segundos de fricción, se queda buena parte del dinero.

Los Core Web Vitals son las métricas con las que Google mide esa experiencia. No son un capricho técnico ni una moda de desarrolladores: son señales de posicionamiento y, lo que más debería importarte, un reflejo directo de cuántos visitantes abandonan el carrito antes de pagar. En un ecommerce, cada décima de segundo cuenta. Vamos a ver qué significan estas métricas, cómo medirlas bien y, sobre todo, qué hacer para moverlas en la dirección correcta.

Qué son exactamente LCP, INP y CLS

Google resume la experiencia de carga e interacción en tres métricas. Conviene entender qué mide cada una porque las soluciones son distintas.

LCP (Largest Contentful Paint): cuándo se ve lo importante

El LCP mide el tiempo que tarda en renderizarse el elemento de mayor tamaño visible al cargar la página: normalmente la imagen principal del producto, el banner de portada o un bloque grande de texto. Es la métrica que responde a la pregunta "¿cuándo siente el usuario que la página ya ha cargado?".

El umbral que Google considera bueno es 2,5 segundos o menos. Entre 2,5 y 4 segundos hay que mejorar; por encima de 4, estás en zona roja. En tiendas online, el LCP suele ser el villano principal, porque las fichas de producto están llenas de imágenes pesadas.

INP (Interaction to Next Paint): cuándo responde a tus clics

El INP sustituyó oficialmente al antiguo FID en marzo de 2024 y es bastante más exigente. Mide la latencia de todas las interacciones del usuario durante la visita (clics, toques, pulsaciones de teclado) y se queda con la peor experiencia representativa. Es decir: si añadir un producto al carrito tarda medio segundo en responder porque el navegador está ocupado ejecutando scripts, el INP lo penaliza.

Un INP por debajo de 200 milisegundos es bueno. Entre 200 y 500 hay margen de mejora, y por encima de 500 ms la tienda se siente lenta y torpe. Esta métrica es especialmente reveladora en ecommerce, donde el usuario interactúa mucho: filtros, variantes de talla y color, mini-carritos, acordeones de información.

CLS (Cumulative Layout Shift): cuándo se mueve todo de sitio

El CLS mide la estabilidad visual. ¿Te ha pasado que vas a pulsar un botón y, justo en ese momento, carga un banner y el botón salta hacia abajo? Eso es un desplazamiento de diseño, y en una tienda puede hacer que el cliente pulse "eliminar" en vez de "comprar". El CLS penaliza esos saltos inesperados.

Un valor por debajo de 0,1 es bueno; entre 0,1 y 0,25 mejorable; por encima, problemático. Las causas habituales son imágenes sin dimensiones reservadas, banners de cookies que entran de golpe y fuentes que recargan el texto al cambiar de tipografía.

Cómo medir los Core Web Vitals sin engañarte

Aquí se cometen los errores más caros: optimizar contra la métrica equivocada. Hay dos tipos de datos y conviene no confundirlos.

Los datos de laboratorio se generan en un entorno controlado y simulado. Es lo que ves al pasar tu URL por PageSpeed Insights y obtener una puntuación instantánea. Sirven para diagnosticar y depurar, pero no reflejan lo que viven tus usuarios reales con sus móviles de gama media y su 4G en el metro.

Los datos de campo (CrUX, Chrome User Experience Report) recogen las métricas de usuarios reales que han visitado tu tienda durante los últimos 28 días. Estos son los que Google usa para posicionar. La diferencia entre uno y otro puede ser brutal: una página con un 95 de puntuación en laboratorio puede suspender en campo si la mayoría de tu tráfico llega desde dispositivos modestos.

Las herramientas que de verdad usamos en una auditoría:

• PageSpeed Insights: te da laboratorio y, si hay tráfico suficiente, también campo. Empieza siempre por aquí, pero mira la pestaña de datos de campo, no solo el número grande de colores.
• Search Console, informe Core Web Vitals: agrupa tus URLs por estado (buena, mejorable, deficiente) y separa móvil de escritorio. Es la fuente oficial de Google sobre tu sitio entero, no página a página. Si tienes que elegir una herramienta para vigilar el conjunto, es esta.
• Lighthouse y las DevTools de Chrome: para depurar en detalle, identificar qué elemento es el LCP, qué scripts bloquean el hilo principal y qué provoca los saltos de CLS.

Un detalle importante: mide siempre en móvil. En España, la mayoría del tráfico de ecommerce llega desde el teléfono, y Google indexa con el rastreador móvil. Una tienda que vuela en tu portátil con fibra puede ser un calvario en un móvil de hace tres años.

Por qué tu tienda online va lenta: las causas típicas

Casi todos los ecommerce que auditamos comparten el mismo puñado de problemas. Reconocerás varios.

Imágenes de producto sin optimizar. Es, con diferencia, la causa número uno de un LCP malo. Subes la foto que te pasó el fotógrafo a 4.000 píxeles y 3 MB, y se muestra en un recuadro de 600 píxeles. El navegador descarga los 3 MB igualmente. Multiplícalo por las veinte fotos de una página de categoría y tienes el desastre servido.

JavaScript de terceros descontrolado. El píxel de Meta, el de Google Ads, el chat de atención, el widget de reseñas, el de "lo han comprado 14 personas", el banner de cookies, dos o tres herramientas de analítica... Cada script de terceros es una petición que compite por el hilo principal del navegador y dispara el INP. He visto tiendas con más de cuarenta scripts cargando antes de que el usuario pueda hacer nada.

Carruseles y sliders pesados. Ese carrusel de portada con seis imágenes a pantalla completa suele cargar las seis a la vez, aunque solo se vea una. Bonito de presentar al cliente, demoledor para el LCP.

Hosting compartido y barato. Un alojamiento de cinco euros al mes con la base de datos saturada responde al servidor en 800 ms cuando debería hacerlo en menos de 200. Ese tiempo de respuesta del servidor (TTFB) lastra todo lo demás antes incluso de empezar a pintar la página.

Falta de caché y de CDN. Si cada visita regenera la página desde cero consultando la base de datos, y si los visitantes de Canarias o de Sevilla tiran de un servidor en Madrid sin red de distribución de contenido, pagas latencia gratis.

Fuentes web mal gestionadas. Cargar cuatro variantes de una tipografía de Google Fonts desde su servidor, sin precarga y sin un fallback decente, provoca o bien texto invisible durante segundos o bien un salto de CLS cuando la fuente real reemplaza a la provisional.

Acciones concretas para mejorar cada métrica

Vamos a lo accionable, métrica por métrica.

Para bajar el LCP

Empieza por las imágenes, que es donde está el 80% del problema. Sirve formatos modernos como WebP o AVIF, que pesan entre un 30% y un 50% menos que un JPG con la misma calidad. Define el atributo srcset para entregar a cada dispositivo el tamaño que necesita, no la imagen de 4.000 píxeles a todo el mundo.

La imagen principal de la ficha de producto, esa que es el LCP, no debe llevar lazy loading: cárgala con prioridad alta (fetchpriority="high") y, si puedes, con un preload. El lazy loading es estupendo para las imágenes de más abajo, pero aplicarlo al elemento LCP es un error clásico que retrasa justo lo que el usuario necesita ver primero.

Reduce el tiempo de respuesta del servidor con caché de página completa y un buen alojamiento. En tiendas Drupal Commerce, por ejemplo, una configuración correcta de la caché interna, el page cache y un reverse proxy tipo Varnish marca la diferencia entre un TTFB de 700 ms y uno de 120.

Para bajar el INP

El INP se mejora aligerando el trabajo del hilo principal. Audita los scripts de terceros sin piedad: cada uno tiene que justificar su existencia con un retorno medible. Ese widget de "13 personas están viendo esto" probablemente cuesta más en conversión de lo que aporta.

Carga lo que no sea crítico con defer o async, y plantéate aplazar la inicialización de scripts no esenciales (chat, mapas, reseñas) hasta que el usuario interactúe o haga scroll. Divide los paquetes grandes de JavaScript (code splitting) para no enviar de golpe todo el código de la tienda en cada página. Gestiona las etiquetas de marketing desde Google Tag Manager con disparadores sensatos, no cargándolo todo al inicio.

Para bajar el CLS

Reserva siempre el espacio. Declara width y height (o aspect-ratio en CSS) en todas las imágenes y vídeos para que el navegador deje el hueco antes de descargarlos. Reserva también el espacio de banners, anuncios y del aviso de cookies, de modo que no empujen el contenido cuando aparecen.

Con las fuentes, usa font-display: swap junto a una precarga de la tipografía principal y un fallback de métricas similares, para que el cambio de tipo de letra no recoloque medio párrafo. Y nunca insertes contenido dinámico (un "envío gratis a partir de 50 €", una recomendación) por encima de algo que el usuario ya está mirando.

Lo que de verdad te importa: rendimiento, conversión y SEO

Toda esta ingeniería tiene una traducción comercial muy concreta, y es la razón por la que merece tu atención.

Por el lado del SEO, los Core Web Vitals son un factor de posicionamiento confirmado. No el más importante (el contenido y la autoridad pesan más), pero sí un desempate real: ante dos tiendas con producto y precio parecidos, Google favorece a la que ofrece mejor experiencia. Y aprobar los Core Web Vitals mejora el rastreo y la indexación, algo crítico cuando tienes miles de URLs de producto y categoría.

Por el lado de la conversión, la relación es aún más directa y más fácil de medir en tu propia caja. Según nuestra experiencia optimizando tiendas, recortar uno o dos segundos del tiempo de carga se traduce en mejoras de la tasa de conversión que van del 7% al 20%, dependiendo del punto de partida. Una página que tardaba 5 segundos y pasa a 2,5 no solo posiciona mejor: recupera carritos que antes se abandonaban en la pantalla de pago. Para un ecommerce que factura 30.000 € al mes, un 10% adicional son 3.000 € mensuales por un trabajo que se hace una vez y se mantiene.

El móvil amplifica todo esto. Tu cliente medio te visita desde el teléfono, a menudo con conexión irregular y mientras hace otra cosa. Su paciencia es mínima. Si la ficha tarda en pintar o el botón de comprar salta de sitio, no te llama para quejarse: se va a la competencia, y tú lo registras como un anuncio que "no funcionó".

Checklist accionable para tu tienda

Para ordenar el trabajo, este es el orden por el que solemos atacar una optimización:

• Mide el estado real en Search Console (informe Core Web Vitals) y PageSpeed Insights, en móvil y con datos de campo.
• Identifica el elemento LCP de tus plantillas clave (portada, categoría, ficha de producto) y dale prioridad de carga.
• Convierte las imágenes a WebP/AVIF, aplica srcset y reserva sus dimensiones.
• Audita y poda los scripts de terceros; aplaza los no críticos.
• Activa caché de página completa, compresión y una CDN con nodos en España.
• Reserva espacio para banners, cookies y fuentes; usa font-display: swap con precarga.
• Revisa el TTFB y, si el hosting es el cuello de botella, plantéate migrar.
• Vuelve a medir a los 28 días: recuerda que los datos de campo necesitan ese plazo para reflejar los cambios.

Ese último punto es clave y genera muchas falsas alarmas: aunque arregles todo hoy, el informe de Search Console tardará semanas en moverse, porque promedia 28 días de tráfico real. La paciencia forma parte del método.

Empieza por saber dónde pierdes velocidad

Mejorar los Core Web Vitals de una tienda no es aplicar una lista de trucos sueltos, sino diagnosticar con datos de campo, priorizar lo que afecta a la conversión y ejecutar con criterio técnico sin romper la tienda por el camino. Hay un orden, hay dependencias y hay decisiones (hosting, CDN, refactor de plantillas) que conviene tomar bien a la primera.

Si tu tienda tarda en cargar, suspende en Search Console o simplemente sospechas que la lentitud te está costando ventas, podemos auditarla y darte un plan de optimización con impacto medible. Cuéntanos tu caso en la página de contacto de Tangram Consulting para una auditoría de rendimiento de tu ecommerce y te diremos exactamente dónde estás perdiendo velocidad y dinero.

Llevamos años construyendo y afinando tiendas con Drupal y otras plataformas, y casi siempre el patrón se repite: el potencial de mejora está ahí, esperando, en métricas que nadie estaba mirando. Mirarlas es el primer paso para convertir visitantes en clientes.