**TL;DR.** I Core Web Vitals nel 2026 sono LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 a p75. Nei siti ecommerce, LCP è fissato tramite il preload dell'immagine hero, INP tramite il deferimento del JS e l'uso delle funzionalità concorrenti di React 18+, e CLS tramite la riserva di spazio per immagini e regioni dinamiche. Google valuta a p75 su un intervallo di 28 giorni; le correzioni richiedono settimane per riflettersi.

## Soglie del 2026

| Metri | Buono  | Necessita miglioramenti | Scarso  |
| ------ | ------ | ----------------------- | ------- |
| 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  |

Fonte: [web.dev/vitals](https://web.dev/articles/vitals). INP ha sostituito FID come Core Web Vital a marzo 2024 e rimane il metro per il 2026.

## Perché i CWV sono importanti

Google utilizza i CWV come segnale di esperienza della pagina nel ranking. I dati reali degli utenti mostrano che le pagine con tutti i CWV verdi superano in classifica pagine comparabili con CWV scadenti in nicchie competitive.

Oltre ai ranking, i CWV influenzano direttamente la conversione. Studi nel 2024–2025 mostrano costantemente:

- Miglioramento di 1 secondo in LCP: aumento della conversione del 5–15% su PDP.
- INP sotto i 200ms: riduzione del 10–20% nell'abbandono del carrello.
- CLS sotto 0.1: aumento percepito della qualità dell'UX.

## Misurare nel modo giusto

Due fonti di dati sono importanti:

1. **CrUX (Chrome User Experience Report)**: dati reali degli utenti che Google utilizza per classificarti. Finestra mobile di 28 giorni, p75. Visibile in PageSpeed Insights e Search Console.
2. **Il tuo RUM**: dati reali degli utenti che raccogli tramite la libreria `web-vitals` o il tuo CDN. Mostra dati più freschi, ti consente di segmentare per tipo di pagina, dispositivo, paese.

Gli strumenti sintetici (Lighthouse, WebPageTest) sono utili per la diagnosi ma non per la valutazione.

## Correzioni LCP (largest contentful paint)

Nei siti ecommerce, LCP è quasi sempre:

- L'immagine hero sulla home, PLP e PDP.
- L'H1 + il primo paragrafo sulle pagine di blog/articolo.

I grandi vantaggi:

1. **Precarica l'immagine 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. **Usa Next.js `<Image>` con `priority`** sull'immagine LCP:

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

3. **Servi formati moderni**. AVIF batte WebP che batte JPEG. Next.js Image gestisce questo automaticamente.

4. **Non caricare in modo lazy l'immagine LCP**. `loading="lazy"` è solo per le immagini sotto il fold.

5. **Inline CSS critico per gli stili sopra il fold**. Evita di bloccare i caricamenti dei fogli di stile sul percorso di rendering critico.

6. **Usa il rendering edge**. TTFB di ≤ 100ms dalla cache edge ti garantisce la maggior parte del budget LCP.

## Correzioni INP (interaction to next paint)

INP misura il caso peggiore tra tutte le interazioni su una pagina. Un clic lento su un filtro può rovinare il tuo INP per un'intera sessione.

I grandi vantaggi:

1. **Riduci il JS lato client**. Usa i React Server Components dove possibile. Ogni kilobyte di JS client danneggia l'INP.

2. **Usa `startTransition` per aggiornamenti di stato non urgenti**:

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

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

3. **Usa `useOptimistic` per feedback istantaneo**:

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

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

4. **Debounce gli input**. L'autocompletamento della ricerca dovrebbe avere un debounce di 150–250ms con `AbortController` per annullare le richieste in corso:

```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. **Sposta i letterali regex fuori dai gestori di eventi** — ricreare regex in un percorso caldo costa un INP misurabile.

6. **Deferisci gli script di terze parti non critici**. Pixel di marketing, widget di chat, SDK di test A/B: caricali con `strategy="afterInteractive"` o `lazyOnload`.

## Correzioni CLS (cumulative layout shift)

I grandi vantaggi:

1. **Imposta sempre larghezza/altezza sulle immagini**. I browser riservano lo spazio corretto.

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

2. **Riserva spazio per contenuti incorporati**. iframe, annunci, lettori video necessitano di dimensioni esplicite o contenitori con rapporto d'aspetto.

3. **Evita `font-display: swap` senza CSS di fallback per i font**. Lo swap riformatta il testo. Usa [size-adjust](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust) per abbinare le metriche o accetta `font-display: optional`.

4. **Non iniettare contenuti sopra contenuti esistenti**. Notifiche banner, consenso ai cookie, banner di vendita — rendili in una posizione che non sposti la pagina.

5. **I caricamenti dello scheletro dovrebbero corrispondere alle dimensioni reali del contenuto**. Uno scheletro più piccolo del contenuto caricato sposta la pagina.

## Note specifiche per tipo di pagina

**Pagina principale**

- L'immagine hero è LCP. Precaricala.
- I caroselli sono mine anti CLS. Usa solo CSS o pre-renderizza il primo slide.

**PLP (product list / category)**

- LCP è solitamente l'immagine della prima scheda prodotto.
- INP è per i clic sui filtri e la paginazione. Usa `startTransition` in modo aggressivo.
- CLS è il riempimento della griglia prodotto quando si applicano i filtri. Riserva l'altezza della griglia.

**PDP**

- LCP è l'immagine principale del prodotto.
- INP è il cambio di variante e l'aggiunta al carrello. L'UI ottimistica è obbligatoria.
- CLS è il caricamento delle miniature della galleria prodotto dopo l'immagine principale.

**Carrello / Checkout**

- INP è critico qui. Un pulsante "effettua ordine" lento costa ordini.
- CLS dal caricamento degli iframe di pagamento (Stripe Elements, ecc.). Riserva spazio.

## Strumenti

| Strumento                  | A cosa serve                                           |
| -------------------------- | ------------------------------------------------------ |
| PageSpeed Insights         | Diagnosi di un singolo URL con sovrapposizione di dati reali (CrUX) |
| Lighthouse                 | Misurazione sintetica per flussi di lavoro di sviluppo  |
| WebPageTest                | Misurazione con throttling della rete, multi-locazione |
| Search Console → CWV        | Livello di dominio p75 su 28 giorni                    |
| Il tuo RUM (web-vitals)    | Dati di campo in tempo reale segmentati per pagina, dispositivo, paese |

## Come Ordiko gestisce i CWV per impostazione predefinita

Lo stack del negozio di Ordiko:

- Next.js 16 + React Compiler.
- `cacheComponents: true` + `experimental.ppr: "incremental"`.
- Rendering edge di shell statiche (TTFB ≤ 100ms).
- Immagine LCP precaricata per impostazione predefinita su PDP, PLP, home.
- Confini di Suspense attorno a isole dinamiche (carrello, recentemente visualizzati, hero personalizzato).
- `startTransition` + `useOptimistic` sui controlli di filtro e variante.
- Ricerca debounced a 200ms con `AbortController`.

Tipico p75 reale su un PDP Ordiko predefinito: LCP 1.0–1.8s, INP 80–160ms, CLS < 0.05.

## FAQ

**I Core Web Vitals influenzano i ranking?**
Sì, dal 2021 — ma come fattore di rottura piuttosto che come segnale primario. Due pagine di uguale qualità del contenuto si classificheranno in ordine di CWV. Correggere i CWV su una pagina scarsamente classificata non la farà improvvisamente classificare se il contenuto è debole.

**Perché è più difficile correggere l'INP rispetto all'LCP?**
LCP è principalmente un problema di CDN e ottimizzazione delle immagini con correzioni ben comprese. L'INP è un problema di esecuzione di JavaScript che richiede un'analisi componente per componente. Ogni evento di interazione può avere un collo di bottiglia diverso (clic sul filtro vs. aggiunta al carrello vs. cambio di variante).

**Qual è un buon obiettivo INP per PDP?**
Sotto i 200ms p75 è 'buono'. Sotto i 100ms è raggiungibile su PDP moderni con disciplina (RSC, senza script di terze parti pesanti, input debounced). Sopra i 500ms è 'scarso' e probabilmente influisce sui ranking.

**Come gestisce Ordiko i CWV per impostazione predefinita?**
Ordiko utilizza Next.js 16 Cache Components + PPR, che trasmette una shell statica con l'immagine LCP già precaricata e confini di Suspense per contenuti dinamici. L'INP predefinito rimane sotto i 200ms su PDP tipici senza ottimizzazione su misura.