Usamos cookies para mejorar tu experiencia, analizar el tráfico del sitio y personalizar el contenido. Puedes aceptar todas las cookies o elegir qué categorías permitir. Más información
Core Web Vitals para Ecommerce 2026: Soluciones para LCP, INP, CLS | Ordiko
Guía
Core Web Vitals para Ecommerce 2026: Soluciones para LCP, INP, CLS
Guía práctica 2026 sobre Core Web Vitals en ecommerce — umbrales de LCP/INP/CLS, causas del mundo real y las soluciones que marcan la diferencia en PDP y PLP.
PT1H
TL;DR. Los Core Web Vitals en 2026 son LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 en p75. En sitios de comercio electrónico, LCP se fija mediante la precarga de la imagen principal, INP mediante la postergación de JS y el uso de características concurrentes de React 18+, y CLS mediante la reserva de espacio para imágenes y regiones dinámicas. Google puntúa en p75 durante una ventana de 28 días; las correcciones tardan semanas en reflejarse.
Umbrales de 2026
Métrica
Buena
Necesita mejora
Mala
LCP
≤ 2.5s
2.5s – 4.0s
> 4.0s
INP
≤ 200ms
200ms – 500ms
> 500ms
CLS
≤ 0.1
0.1 – 0.25
> 0.25
TTFB
≤ 800ms
800ms – 1.8s
> 1.8s
Fuente: . INP reemplazó a FID como un Core Web Vital en marzo de 2024 y sigue siendo la métrica para 2026.
Preguntas frecuentes
¿Afectan los Core Web Vitals a los rankings?
Sí, desde 2021 — pero como un desempate en lugar de una señal primaria. Dos páginas de igual calidad de contenido se clasificarán en orden de CWV. Solucionar CWV en una página mal clasificada no la hará clasificar de repente si el contenido es débil.
¿Por qué es más difícil solucionar INP que LCP?
LCP es principalmente un problema de CDN y optimización de imágenes con soluciones bien entendidas. INP es un problema de ejecución de JavaScript que requiere un análisis componente por componente. Cada evento de interacción puede tener un cuello de botella diferente (clic en filtro vs. añadir al carrito vs. cambio de variante).
¿Cuál es un buen objetivo de INP para PDP?
Menos de 200ms p75 es 'bueno'. Menos de 100ms es alcanzable en PDP modernos con disciplina (RSC, sin scripts pesados de terceros, entradas debounced). Más de 500ms es 'pobre' y probablemente impacta en los rankings.
¿Cómo maneja Ordiko CWV por defecto?
Ordiko envía Next.js 16 Cache Components + PPR, que transmite un contenedor estático con la imagen LCP ya precargada y límites de Suspense para contenido dinámico. El INP por defecto se sitúa por debajo de 200ms en PDP típicos sin optimización a medida.
Google utiliza los CWV como una señal de experiencia de página en el ranking. Los datos de usuarios reales muestran que las páginas con todos los CWV en verde superan a páginas comparables con CWV pobres en nichos competitivos.
Más allá de los rankings, los CWV afectan directamente la conversión. Estudios en 2024–2025 muestran consistentemente:
Mejora de LCP de 1 segundo: aumento del 5–15% en la conversión en PDP.
INP por debajo de 200ms: reducción del 10–20% en el abandono del carrito.
CLS por debajo de 0.1: aumento notable en la percepción de calidad de UX.
Midiendo de la manera correcta
Dos fuentes de datos son importantes:
CrUX (Informe de Experiencia de Usuario de Chrome): datos de usuarios reales que Google utiliza para clasificarte. Ventana móvil de 28 días, p75. Aparece en PageSpeed Insights y Search Console.
Tu propio RUM: datos de usuarios reales que recopilas a través de la biblioteca web-vitals o tu CDN. Muestra datos más frescos, te permite segmentar por tipo de página, dispositivo, país.
Las herramientas sintéticas (Lighthouse, WebPageTest) son útiles para diagnosticar, pero no para puntuar.
Correcciones de LCP (pintura de contenido más grande)
En comercio electrónico, LCP es casi siempre:
La imagen principal en la página de inicio, PLP y PDP.
El H1 + primer párrafo en páginas de blog/artículo.
Las grandes ganancias:
Precargar la imagen LCP con <link rel="preload" as="image" fetchpriority="high">:
Sacar literales de regex fuera de los controladores de eventos — recrear regex en una ruta caliente cuesta INP medible.
Diferir scripts de terceros no críticos. Píxeles de marketing, widgets de chat, SDKs de pruebas A/B: cárgalos con strategy="afterInteractive" o lazyOnload.
Correcciones de CLS (desplazamiento acumulativo de diseño)
Las grandes ganancias:
Siempre establecer ancho/alto en imágenes. Los navegadores reservan el espacio correcto.
Reservar espacio para contenido embebido. iframes, anuncios, reproductores de video necesitan dimensiones explícitas o contenedores de relación de aspecto.
Evitar `font-display: swap` sin CSS de respaldo de fuente. El swap refluye el texto. Usa size-adjust para igualar métricas o acepta font-display: optional.
No inyectar contenido por encima del contenido existente. Notificaciones de banner, consentimiento de cookies, banners de venta — renderizarlos en una posición que no desplace la página.
Los cargadores de esqueleto deben coincidir con las dimensiones del contenido real. Un esqueleto que es más pequeño que el contenido cargado desplaza la página.
Notas específicas por tipo de página
Página de inicio
La imagen principal es LCP. Precárgala.
Los carruseles son minas terrestres de CLS. Usa solo CSS o pre-renderiza la primera diapositiva.
PLP (lista de productos / categoría)
LCP es generalmente la imagen de la primera tarjeta de producto.
INP son clics en filtros y paginación. Usa startTransition de manera agresiva.
CLS es el reflujo de la cuadrícula de productos cuando se aplican filtros. Reserva la altura de la cuadrícula.
PDP
LCP es la imagen principal del producto.
INP es el cambio de variante y agregar al carrito. La UI optimista es obligatoria.
CLS son las miniaturas de la galería de productos que se cargan después de la imagen principal.
Carrito / Pago
INP es crítico aquí. Un botón de "realizar pedido" lento cuesta pedidos.
CLS por cargar iframes de pago (Stripe Elements, etc.). Reserva espacio.
Herramientas
Herramienta
Para qué es buena
PageSpeed Insights
Diagnóstico de URL única con superposición de usuario real (CrUX)
Lighthouse
Medición sintética para flujos de trabajo de desarrollo
WebPageTest
Medición con limitación de red, en múltiples ubicaciones
Search Console → CWV
Nivel de dominio p75 durante 28 días
Tu propio RUM (web-vitals)
Datos de campo en tiempo real segmentados por página, dispositivo, país
Renderizado en el borde de shells estáticos (TTFB ≤ 100ms).
Imagen LCP precargada por defecto en PDP, PLP, inicio.
Límites de Suspense alrededor de islas dinámicas (carrito, recientemente visto, héroe personalizado).
startTransition + useOptimistic en controles de filtro y variante.
Búsqueda con debounce de 200ms con AbortController.
P75 típico de usuario real en un PDP de Ordiko por defecto: LCP 1.0–1.8s, INP 80–160ms, CLS < 0.05.
FAQ
¿Afectan los Core Web Vitals a los rankings? Sí, desde 2021 — pero como desempate más que como señal principal. Dos páginas de igual calidad de contenido se clasificarán en orden de CWV. Corregir CWV en una página mal clasificada no hará que de repente se clasifique si el contenido es débil.
¿Por qué es más difícil corregir INP que LCP? LCP es principalmente un problema de CDN y optimización de imágenes con correcciones bien entendidas. INP es un problema de ejecución de JavaScript que requiere un análisis componente por componente. Cada evento de interacción puede tener un cuello de botella diferente (clic en filtro vs. agregar al carrito vs. cambio de variante).
¿Cuál es un buen objetivo de INP para PDP? Por debajo de 200ms p75 es 'bueno'. Por debajo de 100ms es alcanzable en PDP modernos con disciplina (RSC, sin scripts de terceros pesados, entradas con debounce). Por encima de 500ms es 'pobre' y probablemente impacta los rankings.
¿Cómo maneja Ordiko los CWV por defecto? Ordiko envía Next.js 16 Cache Components + PPR, que transmite un shell estático con la imagen LCP ya precargada y límites de Suspense para contenido dinámico. El INP por defecto se mantiene por debajo de 200ms en PDP típicos sin optimización a medida.