**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: [web.dev/vitals](https://web.dev/articles/vitals). INP reemplazó a FID como un Core Web Vital en marzo de 2024 y sigue siendo la métrica para 2026.

## Por qué importan los CWV

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:

1. **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.
2. **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:

1. **Precargar la imagen LCP** con `<link rel="preload" as="image" fetchpriority="high">`:

```html
<link rel="preload" as="image" href="/products/leather-bag/hero.avif" fetchpriority="high" imagesrcset="/products/leather-bag/hero-400.avif 400w, /products/leather-bag/hero-800.avif 800w" imagesizes="(max-width: 768px) 100vw, 50vw" />
```

2. **Usar Next.js `<Image>` con `priority`** en la imagen LCP:

```tsx
<Image
  src={product.heroImage}
  width={800}
  height={800}
  priority
  fetchPriority="high"
  alt={product.altText}
/>
```

3. **Servir formatos modernos**. AVIF supera a WebP que supera a JPEG. Next.js Image maneja esto automáticamente.

4. **No cargar la imagen LCP de manera diferida**. `loading="lazy"` es solo para imágenes que están fuera de la vista.

5. **Incluir CSS crítico para estilos visibles**. Evita bloquear la carga de hojas de estilo en la ruta de renderizado crítica.

6. **Usar renderizado en el borde**. TTFB de ≤ 100ms desde la caché de borde te da la mayor parte del presupuesto de LCP.

## Correcciones de INP (interacción hasta la siguiente pintura)

INP mide el peor caso entre todas las interacciones en una página. Un clic lento en un filtro puede arruinar tu INP durante toda una sesión.

Las grandes ganancias:

1. **Reducir JS del lado del cliente**. Usa React Server Components donde sea posible. Cada kilobyte de JS del cliente afecta a INP.

2. **Usar `startTransition` para actualizaciones de estado no urgentes**:

```tsx
import { startTransition, useState } from 'react';

function FilterButton({ filter }) {
  const [isPending, startTransition] = useTransition();
  return (
    <button onClick={() => startTransition(() => applyFilter(filter))}>
      {filter.label}
    </button>
  );
}
```

3. **Usar `useOptimistic` para retroalimentación instantánea**:

```tsx
import { useOptimistic } from 'react';

function Cart() {
  const [cart, addOptimistic] = useOptimistic(serverCart);
  return (
    <button onClick={() => {
      addOptimistic({ ...newItem });
      addToCartServerAction(newItem);
    }}>Agregar al carrito</button>
  );
}
```

4. **Debounce en entradas**. La autocompletación de búsqueda debe tener un debounce de 150–250ms con `AbortController` para cancelar solicitudes en curso:

```tsx
useEffect(() => {
  const controller = new AbortController();
  const timeout = setTimeout(() => {
    fetch(`/api/search?q=${query}`, { signal: controller.signal });
  }, 200);
  return () => {
    clearTimeout(timeout);
    controller.abort();
  };
}, [query]);
```

5. **Sacar literales de regex fuera de los controladores de eventos** — recrear regex en una ruta caliente cuesta INP medible.

6. **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:

1. **Siempre establecer ancho/alto en imágenes**. Los navegadores reservan el espacio correcto.

```html
<img src="/hero.avif" width="800" height="800" alt="..." />
```

2. **Reservar espacio para contenido embebido**. iframes, anuncios, reproductores de video necesitan dimensiones explícitas o contenedores de relación de aspecto.

3. **Evitar `font-display: swap` sin CSS de respaldo de fuente**. El swap refluye el texto. Usa [size-adjust](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust) para igualar métricas o acepta `font-display: optional`.

4. **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.

5. **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 |

## Cómo Ordiko maneja los CWV por defecto

La pila de la tienda de Ordiko:

- Next.js 16 + React Compiler.
- `cacheComponents: true` + `experimental.ppr: "incremental"`.
- 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.