Core Web Vitals en ecommerce: qué medir y qué arreglar primero

Por Julián, fundador de Rankedora · 2 de noviembre de 2026 · 8 min de lectura

Una tienda online lenta o inestable no solo molesta al comprador: también le cuesta pedidos. Google mide la experiencia real de carga con tres métricas llamadas Core Web Vitals, y las usa como una de las señales de experiencia de página. Conviene ponerlas en su sitio: no son un atajo mágico para subir posiciones, porque Google insiste en que la relevancia del contenido pesa más, pero una tienda con malas cifras pierde visitas y ventas aunque posicione bien. Esta guía te ayuda a medir lo importante y a no perder semanas en lo que no mueve nada.

Las tres métricas y sus umbrales

Google evalúa cada métrica con el percentil 75 de las visitas reales, por separado en móvil y en ordenador. Es decir, para que una página se considere buena, tres de cada cuatro visitas deben cumplir el umbral. El INP sustituyó al antiguo FID como métrica de interactividad en marzo de 2024, y es la que más suspende en tiendas con muchos scripts de terceros.

Dónde medirlas y con qué datos

• Search Console, informe de Core Web Vitals: usa datos de campo, es decir, de usuarios reales, y agrupa las URLs por tipo de problema. Es el punto de partida porque te dice qué grupos de páginas suspenden.
• PageSpeed Insights: muestra datos de campo de la URL cuando hay suficientes visitas y, aparte, una simulación de laboratorio con Lighthouse para diagnosticar. Los dos pueden no coincidir, y los de campo son los que cuentan para Google.
• Datos propios: si tienes mucho tráfico, puedes recoger las métricas en tu analítica con la librería web-vitals de Google para ver qué plantillas y qué dispositivos sufren más.

Mide siempre por plantilla: portada, categoría, ficha de producto, carrito y checkout. Es lo que lo hace accionable. Un arreglo en la plantilla de ficha mejora miles de URLs a la vez.

LCP: lo que suele frenar la carga en una tienda

En una ficha o una categoría, el elemento principal suele ser la imagen del producto o el banner de cabecera. Lo que más ayuda:

• No cargar con carga diferida (lazy loading) la imagen principal. Es un error muy habitual: lo que se ve primero debe pedirse primero. Puedes indicar su prioridad con fetchpriority='high'.
• Servir la imagen en el tamaño real que se muestra y en un formato moderno como WebP o AVIF.
• Reducir el tiempo de respuesta del servidor: hosting, caché y menos consultas pesadas en categorías con filtros.
• Quitar CSS y JavaScript que bloquean el renderizado antes del primer contenido.
• Cargar las fuentes con una estrategia que no retrase el texto principal.

INP: casi siempre es un problema de scripts

El INP empeora cuando el navegador está ocupado ejecutando JavaScript justo cuando el usuario quiere pulsar. En una tienda, los culpables típicos son:

• Gestores de etiquetas con muchas etiquetas de marketing y píxeles acumulados.
• Widgets de chat, reseñas, programas de fidelización, pop-ups y personalización.
• Filtros y buscadores que vuelven a pintar toda la lista con cada clic.
• Eventos de añadir al carrito que ejecutan demasiadas acciones seguidas.

El enfoque es siempre el mismo: quitar lo que no aporta, retrasar lo que no es necesario al cargar y dividir las tareas largas. Muchas tiendas tienen scripts de herramientas que dejaron de usar hace años y siguen cargando en cada página.

CLS: los saltos que hacen fallar el clic

• Imágenes y vídeos sin ancho y alto declarados, que empujan el contenido al cargar.
• Banners, barras de envío gratis y avisos de cookies que se inyectan después y desplazan la página.
• Estrellas de reseñas o precios que aparecen tarde y cambian la altura del bloque.
• Fuentes que al cambiar alteran el tamaño del texto.

La solución es reservar el espacio de cada elemento antes de que cargue.

Por dónde empezar según tu plataforma

Un sprint de seis pasos

1. Abre el informe de Core Web Vitals en Search Console y anota qué grupos de URL suspenden en móvil.
2. Elige una plantilla y analiza una URL representativa en PageSpeed Insights.
3. Identifica el elemento LCP, los scripts de mayor coste y los elementos que se desplazan.
4. Corrige primero lo que afecta a muchas páginas: imagen principal, scripts globales, espacio reservado.
5. Publica los cambios y espera. El informe de campo usa datos de las últimas semanas, así que no verás la mejora al instante.
6. Repite con la siguiente plantilla y vuelve a medir cada vez que instales una app o un plugin.

Qué no hacer

• Perseguir un 100 en la simulación de laboratorio. Lo que cuenta son los datos de campo y la experiencia real.
• Optimizar solo la portada y olvidar fichas y categorías.
• Instalar una app de aceleración que añade más JavaScript del que quita.
• Medir justo después de un cambio y sacar conclusiones antes de que haya datos suficientes.

Checklist rápida

• Métricas revisadas en móvil y por plantilla.
• Imagen principal sin carga diferida y con prioridad alta.
• Imágenes con dimensiones declaradas y en formato moderno.
• Scripts de terceros auditados y reducidos.
• Espacio reservado para banners, reseñas y avisos.
• Medición de nuevo tras cada app o plugin nuevo.

Preguntas frecuentes

Fuentes consultadas

• web.dev: Web Vitals
• web.dev: Interaction to Next Paint (INP)
• web.dev: optimizar el Largest Contentful Paint
• Google Search Central: Core Web Vitals y la Búsqueda de Google