Core Web Vitals en ficha de producto: bajar LCP

Core Web Vitals en una ficha de producto: reducir LCP sin sacrificar las imágenes

Desde 2021, Google utiliza los Core Web Vitals como señal de ranking. En 2026, su peso ha seguido aumentando, y las fichas de producto son el escenario principal: imágenes de alta resolución, sliders, botones de añadir al carrito, reviews dinámicas... todo lo que degrada el rendimiento.

Aquí tienes cómo optimizar las 3 métricas que importan (LCP, CLS, INP) en una ficha de producto sin perder calidad visual ni UX.

Los 3 Core Web Vitals en 2026

LCP (Largest Contentful Paint) — el tiempo que tarda en mostrarse el elemento visible más grande (normalmente la imagen principal del producto). Objetivo: <2,5 s.

CLS (Cumulative Layout Shift) — la estabilidad visual: los elementos no deben moverse durante la carga. Objetivo: <0,1.

INP (Interaction to Next Paint) — desde marzo de 2024, INP sustituye a FID. Mide el retraso entre un clic del usuario (añadir al carrito, abrir un menú) y la respuesta visual. Objetivo: <200 ms.

Una ficha de producto que supera los 3 umbrales en verde tiene ventaja de ranking frente a las que no los superan. La diferencia puede representar 3-5 posiciones en una keyword competitiva.

LCP en la imagen hero: el gran trabajo

En el 90 % de las fichas de producto, el LCP es la imagen hero (la primera imagen del producto). Su peso y su tiempo de carga lo determinan todo.

Formato de imagen

WebP: un 25-35 % más ligero que JPEG, compatible en todas partes en 2026. El estándar.
AVIF: un 40-50 % más ligero que JPEG, mejor calidad. Compatible con Chrome/Firefox/Safari desde 2022. Priorízalo cuando sea posible.
JPEG: fallback solo para navegadores muy antiguos (<1 % del tráfico en 2026).

Sirve el formato correcto según el navegador con <picture>:

<picture>
  <source srcset="/product.avif" type="image/avif" />
  <source srcset="/product.webp" type="image/webp" />
  <img src="/product.jpg" alt="..." />
</picture>

Dimensiones y densidad

Una imagen hero que se muestra a 600×600 píxeles en pantalla no debe pesar 4000×4000 píxeles. Sirve la imagen al tamaño correcto + versión 2x para pantallas retina:

<img
  src="/product-600.webp"
  srcset="/product-600.webp 1x, /product-1200.webp 2x"
  width="600"
  height="600"
  alt="..."
/>

En Shopify, la sintaxis Liquid img_url: '600x600' gestiona esto automáticamente. En WooCommerce, mediante WP Fastest Image Optimizer o Smush.

Lazy-loading inteligente

No apliques lazy-load a la imagen hero (la primera imagen visible): debe cargarse de inmediato. Añade fetchpriority="high":

<img
  src="/product-hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="..."
/>

Aplica lazy-load a todo lo demás (imágenes secundarias, reviews con fotos, productos similares al final de la página):

<img
  src="/product-thumbnail.webp"
  loading="lazy"
  alt="..."
/>

CDN y caché

Todas las imágenes de producto deben pasar por un CDN (Cloudflare, Fastly, Bunny). Ganancia típica en LCP: 30-50 % en Europa, 50-70 % fuera de Europa.

Shopify incluye su propio CDN (Fastly). WooCommerce requiere una configuración explícita.

CLS: causas y correcciones

El CLS en una ficha de producto viene principalmente de:

Imágenes sin dimensiones

<!-- ❌ Causa CLS -->
<img src="/product.webp" alt="..." />

<!-- ✅ Reserva el espacio -->
<img src="/product.webp" width="600" height="600" alt="..." />

Incluso en una imagen responsive (CSS que sobrescribe la width/height), especifica los atributos HTML: sirven como pista para reservar el espacio antes de la carga.

Anuncios o banners que aparecen tarde

Un banner de "Envío gratis a partir de 50 €" que aparece 500 ms después de la carga y empuja todo el contenido hacia abajo = CLS catastrófico.

Solución: reserva el espacio en el HTML inicial con min-height, y rellena el contenido después.

Fuentes web que cambian el tamaño del texto

Si cargas una fuente personalizada, llega con retraso. Mientras tanto, el texto se muestra con una fuente fallback con métricas distintas. Cuando llega la fuente final, todo se mueve.

Solución: font-display: optional o font-display: swap con size-adjust ajustado:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%; /* Match fallback metrics */
}

Carrusel / slider de imágenes de producto

Los sliders son una causa frecuente de CLS si están mal implementados. Reglas:

Fijar la altura del contenedor del slider (height: 600px, por ejemplo)
Sin paginación JS que cambie la altura al hacer clic
Las thumbnails tienen sus dimensiones especificadas

INP: añadir al carrito y otras interacciones críticas

INP mide el peor tiempo de respuesta a las interacciones del usuario. En una ficha de producto, las interacciones clave son:

Clic en "Añadir al carrito"
Cambio de variante (talla, color)
Apertura de un menú burger
Scroll en un carrusel

Causas típicas de un INP alto:

JavaScript bloqueante

Las bibliotecas de terceros (Facebook Pixel, Google Tag Manager, Hotjar, widgets de reviews) son las primeras culpables. Cada script que se ejecuta en el main thread bloquea las interacciones.

Soluciones:

Cargar los scripts de terceros con defer o async cuando sea posible
Moverlos a un Web Worker si es crítico
Consolidar los píxeles de analytics con una sola etiqueta (GTM)
Retrasos voluntarios: no cargar Hotjar hasta 3 segundos después del First Contentful Paint

Handlers JavaScript pesados al hacer clic

Un clic en "Añadir al carrito" que lanza 5 llamadas API, anima 3 elementos y abre una modal puede tardar 500 ms en responder.

Optimizaciones:

Optimistic UI: muestra el feedback de inmediato (el botón cambia de estado), aunque la API tarde 300 ms en responder
Aplica debounce a los handlers: evita relanzar cálculos en cada hover
Mueve las animaciones a CSS en lugar de JS cuando sea posible

Hydration en SPA / frameworks

Si usas React/Next/Vue, la hydration inicial puede bloquear el main thread durante 1-2 segundos. Durante ese tiempo, los clics no funcionan.

Soluciones:

Server-side rendering con contenido interactivo limitado al principio
Progressive hydration: hidrata primero las partes críticas
En Next.js 16+, usa "use client" con moderación: cuanto más server sea el componente, mejor será el INP

Herramientas de medición

Lab tools (datos simulados, útiles en desarrollo):

PageSpeed Insights — rápido, público
Lighthouse (integrado en Chrome DevTools) — detallado
WebPageTest — más configuración, pruebas en varios dispositivos

Field data (datos reales de usuarios, críticos para Google):

Chrome User Experience Report (CrUX) — datos agregados públicos
Google Search Console → Core Web Vitals — tu sitio específicamente
PostHog, Vercel Analytics, Cloudflare Web Analytics — monitorización continua

Regla importante: solo el field data cuenta para el ranking. Una puntuación perfecta en lab con malas puntuaciones en field = ningún efecto positivo en SEO.

Por plataforma

Shopify

Shopify ofrece unos Core Web Vitals decentes por defecto. Los temas oficiales (Dawn, Studio, Crave) están optimizados. Los malos Core Web Vitals en Shopify casi siempre vienen de:

Apps third-party que inyectan JS pesado
Temas premium de terceros mal optimizados
Imágenes sin comprimir

Auditoría en Shopify: elimina las apps innecesarias (Online Store → Apps), usa un tema oficial reciente y comprime las imágenes.

WooCommerce

Más variabilidad según el hosting y los plugins. Stack recomendado:

Hosting de buen rendimiento: Kinsta, WP Engine, Hostinger Cloud (no un compartido low-cost)
Tema ligero: Storefront oficial o un tema personalizado optimizado (no Divi ni Avada)
Solo plugins esenciales
Plugin de caché: WP Rocket, Cache Enabler
Plugin de optimización de imágenes: ShortPixel, Imagify

Headless

En Next.js con next/image, optimización automática. En un frontend personalizado: impleméntalo manualmente (formatos, lazy, fetchpriority).

FAQ

¿Cuánto tarda Google en tener en cuenta las mejoras de Core Web Vitals?

Se agregan 28 días de "field data" para CrUX. Después de desplegar optimizaciones, cuenta con 4-6 semanas antes de que la puntuación de Google refleje la realidad. Ten paciencia, no reviertas tras 1 semana.

¿Son los Core Web Vitals más importantes que el contenido para el ranking?

No. El contenido (relevancia, calidad, backlinks) sigue siendo el factor dominante. Los Core Web Vitals son un tie-breaker: entre dos páginas equivalentes en contenido, la que tenga mejores CWV posiciona mejor. Empeorar el contenido para ganar en CWV es contraproducente.

¿Puedo estar en verde sin CDN?

Para un sitio de España con audiencia solo en España, sí, si tu servidor está en España y bien configurado. Para tráfico internacional, el CDN es casi obligatorio. Cloudflare gratis basta en el 80 % de los casos.

¿Debo sacrificar la calidad de imagen para ganar en LCP?

No. La configuración correcta (WebP/AVIF + dimensiones + CDN + fetchpriority) permite tener una imagen de 600×600 en 40 KB con una calidad equivalente a un JPEG de 200 KB. El sacrificio ya no es necesario desde 2023.

¿Son los Core Web Vitals iguales en móvil y desktop?

Los umbrales sí, pero Google mide las puntuaciones por separado. Una página puede estar "Good" en desktop y "Poor" en móvil (es frecuente). Google utiliza principalmente las métricas mobile para el ranking (Mobile-First Indexing).

¿Cuánto dinero invertir en la optimización de CWV?

Orientación: si tus páginas ya están en "Good", no hace falta invertir más. Si estás en "Needs improvement", 1-3 semanas de desarrollo en las correcciones principales (imágenes, scripts third-party, CDN) suelen bastar. Si estás en "Poor" en todo el sitio, quizá haga falta una refactorización técnica: empieza por una auditoría completa.

Ecomptimize optimiza automáticamente los Core Web Vitals en las fichas de producto de tu catálogo. Ver Ecomptimize para Shopify o Ecomptimize para WooCommerce.