Los Core Web Vitals pasaron de «señal importante» a «factor de clasificación» entre 2021 y 2024. En 2026, una tienda e-commerce con malos Core Web Vitals pierde a la vez tráfico orgánico (SEO) y conversión (visitantes que renuncian porque la página es lenta). Esta guía cubre las tres métricas actuales, cómo medirlas y las palancas concretas para pasarlas en verde en PrestaShop y WooCommerce.
Las 3 métricas Core Web Vitals en 2026
Google ha refinado su conjunto de vitals con los años. En 2026, tres métricas cuentan:
- LCP (Largest Contentful Paint) — tiempo de aparición del elemento visible más grande. Objetivo: por debajo de 2,5 segundos. Por encima de 4 segundos, está en «pobre».
- CLS (Cumulative Layout Shift) — estabilidad visual durante la carga. Objetivo: por debajo de 0,1. Por encima de 0,25, la página salta demasiado.
- INP (Interaction to Next Paint) — tiempo de respuesta a las interacciones del usuario. Objetivo: por debajo de 200 ms. El INP reemplazó al FID en marzo de 2024.
Nota importante: Google mide estas métricas sobre los usuarios reales (CrUX field data), no en laboratorio. Una prueba PageSpeed simulada le da una indicación, pero la nota que cuenta para el SEO es la basada en los 28 días anteriores de visitas reales.
Cómo medir sus Core Web Vitals
Tres herramientas gratuitas para empezar:
PageSpeed Insights
Herramienta Google gratuita en pagespeed.web.dev. Prueba una página, muestra los datos de laboratorio y los datos de campo (usuarios reales) si están disponibles. Sugerencias de optimización granulares. Útil para verificar puntualmente una página específica.
Search Console — informe Core Web Vitals
En Google Search Console, el informe Experiencia > Core Web Vitals agrega los datos de campo sobre cada página crawleada por Google. Identifica los «grupos de URL» que tienen problemas similares. Es el primer lugar a verificar para conocer el estado real de su sitio.
Biblioteca JavaScript Web Vitals
Para una monitorización continua, la biblioteca web-vitals (Google) permite enviar los Core Web Vitals de sus usuarios reales a Google Analytics 4. Instalación en 5 minutos, datos RUM (Real User Monitoring) accesibles en su GA4. Imprescindible para un sitio serio.
Optimizar el LCP (Largest Contentful Paint)
El LCP es casi siempre una imagen en una tienda e-commerce: el hero de la página de inicio, la foto principal del producto, o el primer banner de una página de categoría. Cinco palancas ganadoras:
1. Convertir las imágenes a WebP/AVIF
El WebP gana del 25 al 35% de peso a calidad igual, el AVIF va más lejos (-50%). Ambos formatos son soportados por todos los navegadores modernos (95%+). Use ImageMagick, Squoosh o un módulo dedicado para convertir su biblioteca por lotes.
2. Dimensionar correctamente las imágenes
Una imagen mostrada en 800×600px no necesita pesar 2400×1800px. Genere varios tamaños vía los atributos srcset y sizes — el navegador elige el bueno automáticamente.
3. Lazy loading salvo para el LCP
El lazy loading (loading="lazy") retrasa la carga de las imágenes off-screen. Regla crítica: nunca lazy-loading en la imagen LCP. El navegador tarda demasiado en identificarla. La primera imagen de la home y la foto principal del producto siempre tienen loading="eager" + fetchpriority="high".
4. Precargar la imagen LCP
Añada <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> en la cabecera de la página. El navegador empieza la descarga en paralelo con el HTML, ganancia de 200-500 ms en LCP.
5. CSS crítico inline
El CSS necesario para mostrar el above-the-fold debe estar embebido directamente en el <head>, no cargado vía un archivo externo. El resto del CSS se carga de forma asíncrona. Las herramientas de generación de CSS crítico (Penthouse, Critical, módulo PrestaShop dedicado) automatizan esto.
Optimizar el CLS (Cumulative Layout Shift)
El CLS mide los saltos visuales durante la carga. Las cinco causas más frecuentes:
1. Imágenes sin dimensiones especificadas
Indique siempre los atributos width y height en sus etiquetas <img>. El navegador reserva el espacio correcto antes de que la imagen llegue, ningún salto.
2. Web fonts cargados tarde
Los web fonts (Google Fonts, Adobe Fonts) provocan «FOUT» (Flash of Unstyled Text) — la página se renderiza primero con la fuente sistema, luego salta cuando la web font se carga. Solución: font-display: swap + preload sobre la fuente principal.
3. Anuncios cargados en lazy
Los emplazamientos publicitarios que aparecen después del render de la página empujan el contenido existente. Reserve el espacio antes con un contenedor de altura fija.
4. Banners cookies que empujan el contenido
Anti-pattern: un banner cookies que aterriza en la parte superior de la página tras 500 ms y empuja todo el resto. O bien aparece en position: fixed en overlay, o se reserva al inicio de la página.
5. Botones que cambian de tamaño
Los botones «Añadir al carrito» que cambian de tamaño cuando su texto se carga (traducción, precio dinámico) provocan CLS. Reserve un tamaño mínimo fijo con min-width y min-height.
Optimizar el INP (Interaction to Next Paint)
El INP mide la rapidez con la que su sitio reacciona a un clic, un toque o una pulsación de tecla. Las causas más frecuentes de un mal INP:
1. JavaScript pesado o mal optimizado
El JavaScript que bloquea el thread principal durante más de 50 ms degrada el INP. Solución: dividir su JS en chunks más pequeños, diferir las cargas no críticas, usar async y defer.
2. Scripts third-party
Google Analytics, Facebook Pixel, widgets de chat, herramientas A/B test — cada script cuesta INP. Defiéralos vía Tag Manager y cárguelos solo en interacción usuario cuando sea posible.
3. DOM pesado
Una página con 3000+ elementos DOM tiene problemas para reaccionar rápido. Reduzca el anidamiento, use la virtualización para las listas largas (resultados de búsqueda, catálogos grandes).
Optimizaciones específicas PrestaShop
PrestaShop tiene debilidades conocidas en Core Web Vitals: tema por defecto pesado, jQuery usado en todas partes, caché a veces mal hecha. Acciones concretas:
- Activar la caché Smarty y el CCC (Combine, Compress, Cache) en Parámetros avanzados → Rendimiento
- Pasar a un tema moderno (Hummingbird, Warehouse, Wojo) optimizado Core Web Vitals
- Instalar un generador de CSS crítico — vea nuestra categoría Administración & Productividad
- Convertir todas las imágenes a WebP vía módulo dedicado
- Activar OPcache y Redis en su servidor
Optimizaciones específicas WordPress / WooCommerce
WooCommerce comparte los mismos problemas amplificados por la dependencia jQuery. Las buenas prácticas:
- Instalar un plugin de caché serio: WP Rocket, LiteSpeed Cache o W3 Total Cache
- Plugin de conversión WebP/AVIF — vea nuestra categoría Medios & Optimización de imágenes
- CDN para las imágenes (Cloudflare R2, Bunny CDN, KeyCDN)
- Desactivar los plugins inútiles (cada plugin = JS/CSS cargado)
- Pasar a un tema «moderno» basado en bloques Gutenberg en lugar de un page builder pesado
Errores frecuentes a evitar
- Optimizar para el score lab, no para el score field. Un PageSpeed a 95 en simulación no quiere decir nada si los usuarios reales en 4G lenta están a 50.
- Olvidar el móvil. Los Core Web Vitals de Google miran el score móvil prioritariamente, no el escritorio.
- Sacrificar la calidad visual. Comprimir sus imágenes a 30% de calidad WebP gana bytes pero mata la experiencia.
- Acumular plugins de optimización. Tres plugins de caché activos a la vez = caos. Un plugin serio, bien configurado.
Para ir más lejos
La optimización de los Core Web Vitals es un trabajo iterativo. Explore nuestra categoría Rendimiento y Core Web Vitals para análisis mensuales. Para módulos dedicados que cubren el CSS crítico, la conversión de imágenes y la optimización del rendimiento global, vea nuestras categorías Administración & Productividad PrestaShop y SEO & Rendimiento WordPress.