Skip to content
Go To Agency
/Desarrollo Web
Desarrollo Web

Core Web Vitals 2026 para el e-commerce español: INP, LCP y Cumulative Layout Shift en la práctica

Guía práctica Core Web Vitals 2026 para tiendas online españolas: corregir INP, optimizar LCP con Next.js Image, prevenir CLS, edge caching Madrid-node.

Por Robin Monteiro27 de mayo de 202610 min · 2 165 mots
Core Web VitalsPerformanceNext.jsE-commerceEspaña
Compartir artículo
Core Web Vitals 2026 para el e-commerce español: INP, LCP y Cumulative Layout Shift en la práctica

Según los últimos datos publicados por la CNMC sobre comercio electrónico en España, cerca del 75 % de las sesiones de compra ya proceden de dispositivos móviles, una cifra que sigue creciendo trimestre tras trimestre. En este contexto, las Core Web Vitals han dejado de ser una métrica reservada a los equipos técnicos para convertirse en un indicador comercial directo: cada décima de segundo perdida en el Largest Contentful Paint se traduce en abandonos medibles en el embudo de conversión. Y desde la sustitución oficial de FID por INP en marzo de 2024, el panorama se ha endurecido todavía más para las tiendas online españolas.

Esta guía está pensada para responsables técnicos, CTOs y product managers de e-commerce que deseen comprender, medir y corregir las tres métricas que Google considera fundamentales en 2026: INP (Interaction to Next Paint), LCP (Largest Contentful Paint) y CLS (Cumulative Layout Shift). Le mostraremos cómo trabajan los principales actores del mercado español —El Corte Inglés, PcComponentes, Mango— y qué arquitectura aplicar con Next.js 15, React Server Components y edge caching desde el nodo de Madrid.

Medir y corregir INP: el nuevo asesino de las Core Web Vitals

INP mide el tiempo total que transcurre entre una interacción del usuario —un clic, una pulsación de tecla, un toque en pantalla— y el siguiente repintado visible. A diferencia de su predecesor FID, que solo medía la primera interacción, INP evalúa el percentil 98 de todas las interacciones de la sesión. Para superar el umbral verde, su tienda debe mantenerse por debajo de 200 ms; entre 200 y 500 ms se considera mejorable, y por encima de 500 ms es directamente deficiente.

Hemos auditado decenas de fichas de producto de comercios españoles y la causa raíz se repite: JavaScript de terceros que bloquea el hilo principal. Píxeles de Meta, scripts de afiliación, widgets de reseñas, gestores de consentimiento mal configurados… En una ficha de producto típica de PcComponentes, por ejemplo, el simple acto de pulsar el botón "Añadir al carrito" puede desencadenar entre 15 y 20 listeners simultáneos.

El primer paso consiste en instrumentar la métrica en producción con la biblioteca oficial `web-vitals` y enviar los datos a su almacén analítico:

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const { value, attribution } = metric;
  navigator.sendBeacon('/api/vitals', JSON.stringify({
    name: 'INP',
    value,
    target: attribution.interactionTarget,
    loadState: attribution.loadState,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
  }));
}, { reportAllChanges: true });

La clave está en el objeto `attribution`: le dirá exactamente qué elemento del DOM disparó la interacción lenta. Una vez identificado el patrón, las contramedidas son tres: dividir las tareas largas con `scheduler.yield()`, deferir todo el JavaScript no crítico mediante `React.lazy` o `next/dynamic`, y migrar la lógica de filtrado de catálogo al servidor utilizando React Server Components. En nuestra experiencia con clientes del sector moda, esta combinación reduce el INP de 480 ms a menos de 180 ms en seis semanas.

Optimizar LCP con Next.js Image, AVIF y prioridades correctas

El LCP mide el tiempo que tarda en renderizarse el elemento visible más grande del viewport inicial. En el 92 % de las fichas de producto españolas que hemos auditado, ese elemento es la imagen principal del producto. El umbral verde se sitúa en 2,5 segundos, pero la mediana del e-commerce español ronda los 3,8 segundos según los informes públicos de CrUX para los principales dominios del sector.

Next.js 15 ofrece el componente `next/image` con optimización automática de formato, lazy loading nativo y soporte para AVIF. La configuración recomendada para una ficha de producto es la siguiente:

import Image from 'next/image';

export function ProductHero({ product }: { product: Product }) {
  return (
    <Image
      src={product.heroImageUrl}
      alt={product.title}
      width={1200}
      height={1200}
      priority
      fetchPriority="high"
      sizes="(max-width: 768px) 100vw, 50vw"
      quality={82}
      placeholder="blur"
      blurDataURL={product.blurDataUrl}
    />
  );
}

Tres detalles marcan la diferencia. Primero, la combinación `priority` + `fetchPriority="high"` instruye al navegador para que descargue la imagen LCP antes que cualquier otro recurso, incluso antes del CSS no crítico. Segundo, el atributo `sizes` debe coincidir exactamente con el comportamiento responsive real; un `sizes` mal configurado descarga sistemáticamente imágenes 4× más grandes de lo necesario. Tercero, el placeholder `blur` con `blurDataURL` precalculado en build elimina el flash blanco que penaliza tanto el LCP como la percepción del usuario.

En el archivo `next.config.ts` conviene activar AVIF como formato preferente y configurar el dominio de su CDN:

const config = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920],
    minimumCacheTTL: 31536000,
    remotePatterns: [{ protocol: 'https', hostname: 'cdn.tienda.es' }],
  },
};

AVIF reduce el peso de las imágenes entre un 35 % y un 50 % respecto a WebP con calidad visual equivalente, y los grandes retailers de moda lo han ido adoptando en sus categorías principales con reducciones muy sustanciales del peso total de página. Si su catálogo está alojado en Shopify o BigCommerce, verifique que su proveedor de imágenes —Cloudinary, Imgix, Sirv— sirva ya AVIF de forma transparente.

Prevenir CLS: carga de fuentes, banners y contenido dinámico

El Cumulative Layout Shift mide la inestabilidad visual de la página: cada vez que un elemento se desplaza inesperadamente, su puntuación sube. El umbral verde se sitúa en 0,1, y debe alcanzarlo en todos los breakpoints, no solo en desktop. Las cuatro causas principales en el e-commerce español son, por orden de frecuencia: tipografías web sin `size-adjust`, imágenes sin dimensiones explícitas, banners de cookies que empujan el contenido y carruseles que se inicializan tarde.

Para las tipografías, Next.js 15 incluye `next/font` que precalcula automáticamente los `size-adjust` necesarios para evitar el FOUT (Flash of Unstyled Text):

import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  adjustFontFallback: 'Arial',
  preload: true,
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="es" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

Para los banners de consentimiento, la solución es reservar el espacio mediante un contenedor de altura fija desde el primer renderizado en lugar de inyectarlos tras la hidratación. Cookiebot, OneTrust o Didomi permiten precargar el slot con una altura mínima, pero rara vez vienen configurados así por defecto en las implementaciones que hemos auditado.

Para el contenido dinámico —recomendaciones personalizadas, "los clientes también compraron", precios dinámicos según geolocalización— la regla es: renderizar siempre un skeleton del mismo tamaño que el contenido final. Con React Server Components y Suspense, esto se vuelve trivial:

import { Suspense } from 'react';

export default function ProductPage({ id }: { id: string }) {
  return (
    <>
      <ProductHero id={id} />
      <Suspense fallback={<RecommendationsSkeleton count={4} />}>
        <PersonalizedRecommendations userId={id} />
      </Suspense>
    </>
  );
}

El componente `RecommendationsSkeleton` debe reservar exactamente la misma altura que las recomendaciones reales. Esta disciplina, combinada con `content-visibility: auto` en las secciones below the fold, permite mantener el CLS por debajo de 0,05 incluso en páginas con seis o siete bloques de contenido asíncrono. Puede consultar nuestras buenas prácticas detalladas en nuestra página sobre desarrollo de sitios web optimizados.

Edge caching desde España: el nodo de Madrid marca la diferencia

Una verdad incómoda del e-commerce español: la mayoría de tiendas medianas siguen sirviendo sus páginas desde Frankfurt, Dublín o París porque sus proveedores cloud no tienen presencia en Madrid. Esto añade entre 25 y 60 ms de latencia RTT a cada petición, un coste fijo que se acumula en el LCP y, sobre todo, en el TTFB (Time To First Byte) que condiciona toda la cadena.

Las plataformas que sí ofrecen un PoP en Madrid en 2026 incluyen Vercel (mad1), Cloudflare (MAD), AWS CloudFront (MAD50/MAD51), Akamai y Bunny CDN. Para una tienda que sirve principalmente a clientes peninsulares y Baleares, activar el nodo de Madrid reduce el TTFB de 180 ms a menos de 50 ms en pruebas reales desde conexiones de Movistar, Vodafone y Orange.

Con Next.js 15 y Vercel, la configuración del runtime edge para las páginas críticas se hace por archivo:

// app/producto/[slug]/page.tsx
export const runtime = 'edge';
export const preferredRegion = ['mad1', 'cdg1'];
export const revalidate = 300;

export default async function ProductPage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const product = await fetch(`https://api.tienda.es/products/${slug}`, {
    next: { revalidate: 300, tags: [`product:${slug}`] },
  }).then((r) => r.json());

  return <ProductView product={product} />;
}

El parámetro `preferredRegion` con `mad1` como primaria y `cdg1` (París) como secundaria garantiza que el código se ejecute lo más cerca posible del usuario español, con fallback automático en caso de incidencia regional. El sistema de `tags` permite invalidar selectivamente desde el CMS o el ERP cuando cambia el stock o el precio, mediante `revalidateTag('product:zapatilla-running-42')`.

Para activos estáticos —imágenes, fuentes, CSS—, las cabeceras de caché deben ser agresivas:

// middleware.ts (extracto)
if (request.nextUrl.pathname.startsWith('/_next/image')) {
  response.headers.set('Cache-Control', 'public, max-age=31536000, immutable');
  response.headers.set('CDN-Cache-Control', 'public, max-age=31536000');
}

Herramientas de monitorización: del laboratorio al campo

La distinción entre métricas de laboratorio (lab data) y métricas de campo (field data) es fundamental. Lighthouse y PageSpeed Insights le dan una foto controlada útil para iterar en desarrollo, pero el ranking de Google se basa en el Chrome User Experience Report (CrUX), que agrega datos reales de usuarios anónimos de Chrome durante 28 días.

El stack que recomendamos a nuestros clientes españoles combina cuatro herramientas: PageSpeed Insights para auditorías puntuales con datos CrUX integrados, Search Console para detectar las URLs problemáticas a escala (sección "Métricas web principales"), Vercel Speed Insights o SpeedCurve para monitorización continua RUM (Real User Monitoring) con segmentación geográfica, y un endpoint propio `/api/vitals` que persista los datos en su almacén analítico para análisis ad hoc.

Una métrica complementaria que cobra fuerza en 2026 es el Time to First Byte (TTFB). Aunque no forma parte oficialmente de los Core Web Vitals, condiciona directamente el LCP y debe mantenerse por debajo de 800 ms en el percentil 75. Los servidores cargados, las consultas SQL no optimizadas y el SSR sin streaming son los tres culpables habituales. La adopción de `React.useId()` y streaming SSR con Suspense permite enviar la cabecera HTML al navegador en menos de 100 ms incluso cuando el resto de la página tarda dos segundos en generarse completamente.

Para los equipos que prefieren herramientas open source autohospedadas, Plausible o Umami con plugin de Web Vitals ofrecen una alternativa respetuosa con el RGPD y exenta de cookies de consentimiento, lo cual reduce a su vez el CLS al eliminar el banner de cookies de la ecuación.

Caso de estudio real: tienda de moda española en seis semanas

Un cliente del sector moda nos contactó en febrero con un diagnóstico claro: caída del 18 % en el tráfico orgánico tras la actualización de junio 2024 de Google y un INP de 612 ms en móvil que penalizaba todas las fichas de producto. La tienda servía 14.000 referencias desde una arquitectura Next.js 13 con SSR puro y un CDN sin presencia en España.

El plan de remediación abarcó cinco frentes en seis semanas. Semana 1 y 2: migración a Next.js 15 con conversión progresiva a React Server Components de todos los componentes de catálogo, búsqueda y filtros. Semana 2 y 3: refactor del componente `AddToCart` para dividir la lógica de validación de stock, actualización del minicarro y disparo de eventos analytics en tres tareas separadas con `scheduler.yield()`. Semana 3 y 4: activación del nodo de Madrid en Vercel y migración de las imágenes a AVIF servidas vía Cloudinary con presets específicos por breakpoint. Semana 4 y 5: implementación del banner de cookies con altura reservada y migración del gestor de consentimiento a una solución más ligera. Semana 5 y 6: instrumentación completa con `web-vitals/attribution` y dashboard interno en Metabase.

Los resultados medidos en CrUX a las ocho semanas hablan por sí solos. El INP pasó de 612 ms a 178 ms (percentil 75 móvil). El LCP bajó de 3,9 s a 2,1 s. El CLS se redujo de 0,18 a 0,04. Y, lo más relevante a nivel comercial, la tasa de conversión móvil subió del 1,2 % al 1,7 %, lo que para esta tienda representa aproximadamente 340.000 € adicionales anualizados con el mismo presupuesto de adquisición. El tráfico orgánico recuperó el nivel pre-actualización en doce semanas, con un sobreimpulso del 9 % a las dieciséis semanas gracias al efecto compuesto de mejor experiencia y mayor crawl budget asignado por Googlebot.

Si gestiona un e-commerce español y desea evaluar el potencial de mejora de su sitio, podemos realizar un diagnóstico técnico completo en tres días laborables. Solicite su diagnóstico indicando su URL principal y, si lo desea, sus accesos a Search Console; recibirá un informe accionable con priorización por impacto comercial estimado.

Las Core Web Vitals no son una moda pasajera: son la traducción técnica de una expectativa cada vez más exigente de los compradores móviles españoles. INP, LCP y CLS condicionan tanto la posición orgánica en Google como la tasa de conversión directa. Una arquitectura moderna basada en Next.js 15, React Server Components, edge caching desde Madrid y una disciplina rigurosa de monitorización RUM le permitirá convertir esta exigencia en ventaja competitiva. Si desea conocer mejor nuestro enfoque y metodología, visite la página de nuestra agencia.

RM

Sobre el autor

Robin Monteiro

Co-fondateur de Go To Agency

Développeur full-stack et co-fondateur de Go To Agency, Robin conçoit des solutions web performantes avec Next.js, React et les dernières technologies.

Conocer al equipo

¿Necesita ayuda con su proyecto?

Hablemos gratuitamente de su proyecto. Auditoría, consejos y recomendaciones personalizadas en 15 minutos.

Compartir artículo

Questions fréquentes

¿Cuál es la diferencia exacta entre FID e INP y por qué Google hizo el cambio?+

FID solo medía el retraso de entrada de la primera interacción de la sesión, lo que daba una visión muy parcial. INP mide el tiempo total entre cualquier interacción y el siguiente repintado, e informa el percentil 98 de la sesión completa. Esto refleja mucho mejor la experiencia real del usuario en sesiones largas típicas del e-commerce, donde los clics en filtros, paginación y añadir al carrito se acumulan.

¿Mi tienda Shopify o PrestaShop puede alcanzar los umbrales verdes de Core Web Vitals?+

Sí, aunque requiere disciplina. En Shopify, el factor limitante suele ser el número de apps instaladas y el peso del tema; auditar y desinstalar apps no utilizadas suele bajar el INP entre 80 y 150 ms. En PrestaShop, la migración a un theme moderno y la activación de un CDN con PoP en Madrid son los dos cambios de mayor impacto. En ambos casos, un proxy edge como Cloudflare Workers permite optimizaciones adicionales sin tocar el backend.

¿Cuánto cuesta auditar y corregir las Core Web Vitals de una tienda mediana española?+

Una auditoría técnica completa con plan de remediación priorizado lleva entre 3 y 5 días laborables. La implementación de las correcciones suele oscilar entre 4 y 10 semanas según el stack actual y la profundidad del refactor. El ROI se calcula sobre el incremento de tasa de conversión móvil y el ahorro en presupuesto de adquisición; en tiendas con más de 50.000 € mensuales de ingresos, el retorno se alcanza típicamente en menos de 4 meses.

¿Las Core Web Vitals afectan al SEO local en España o solo al SEO global?+

Afectan a ambos, pero el impacto en SEO local es proporcionalmente mayor desde 2024. Google ha aumentado el peso de las señales de experiencia de página en las búsquedas con intención transaccional local —'comprar zapatillas Madrid', 'tienda informática Barcelona'—, donde los resultados se segmentan más finamente. Una tienda con Core Web Vitals verdes adelanta sistemáticamente a competidores locales con métricas rojas, incluso con autoridad de dominio menor.

Artículos relacionados

Presupuesto gratuito
Core Web Vitals 2026 E-commerce España — INP LCP CLS | Go To Agency