Google classificava i siti web in base a parole chiave e backlink. Nel 2021 è stato introdotto l’Aggiornamento dell’esperienza sulle pagine. Hanno spostato l’algoritmo per filtrare i siti “fastidiosi”.

Fastidioso = Lento (LCP).
Fastidioso = nervoso (CLS).
Fastidioso = Non risponde (INP).

Se non superi questi Core Web Vitals (CWV), non solo infastidisci gli utenti; perdi traffico organico. Noi di Maison Code Paris trattiamo la performance come una caratteristica. Un sito di lusso lento è una contraddizione in termini.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

1. Largest Contentful Paint (LCP): scadenza 2,5 secondi

LCP misura le Prestazioni di caricamento. Ferma l’orologio quando viene renderizzato il più grande elemento visibile (solitamente l’immagine Hero o il testo bloccante H1). Obiettivo: < 2,5 secondi.

La fisica dell’LCP

LCP è una corsa contro quattro sottoparti:

TTFB (Time to First Byte): tempo di risposta del server.
Ritardo caricamento risorse: tempo trascorso prima che il browser rilevi l’URL dell’immagine.
Tempo di caricamento delle risorse: tempo necessario per scaricare l’immagine.
Ritardo rendering elemento: è il momento di dipingere i pixel.

Come risolverlo (strategia Next.js)

1. Non caricare l’eroe in modo pigro Gli sviluppatori adorano loading="lazy". Ma se lo inserisci nell’immagine Hero, il browser attende finché non analizza il tag "" per avviare il download. È necessario caricare con impazienza il candidato LCP.

“tsx // Cattivo

// Buono (Next.js) <Image src=“/hero.jpg” priorità={true} />


**2. Precarica risorse critiche**
Di' al browser in `<head>`: "Avrai bisogno di questo carattere e di questa immagine immediatamente."

```html
<link rel="preload" href="/hero.webp" as="image" />
<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin />

3. Utilizza il formato AVIF WebP è buono. AVIF è migliore (20% più piccolo). Assicurati che la tua CDN supporti la negoziazione dei contenuti.

2. Spostamento cumulativo del layout (CLS): l’indice di stabilità

Il CLS misura la stabilità visiva. Calcola la quantità di contenuti che si spostano inaspettatamente. Obiettivo: < 0,1.

Scenario: l’utente tenta di fare clic su “Checkout”. Un annuncio viene caricato sopra il pulsante. Il contenuto spinge verso il basso. L’utente fa invece clic su “Annulla”. Questo è uno schema oscuro, anche se accidentale.

Il problema: proporzioni

Se includi un’immagine senza dimensioni: <img src="foto.jpg" /> Il browser non conosce l’altezza finché l’immagine non viene scaricata. Rende l’altezza di 0px, quindi salta a 500px.

Correzione: riserva sempre spazio. Le “proporzioni” CSS sono tue amiche.

.eroe-wrapper {
  proporzioni: 16/9;
  sfondo: #f0f0f0; /* Colore del segnaposto */
}

Lo spostamento del carattere (FOIT/FOUT)

I caratteri personalizzati richiedono tempo per essere caricati. Se il browser nasconde il testo finché non viene caricato il carattere (FOIT), ottieni un flash. Se il browser mostra il carattere di fallback (Arial) e poi lo scambia (Inter), la larghezza cambia. Le interruzioni di riga cambiano. Il layout cambia.

Correzione: utilizza font-display: optional o abbina le metriche. Utilizziamo “@next/font” che allinea automaticamente le metriche dei caratteri di riserva per impedire lo spostamento del layout.

3. Il costo dei caratteri pesanti

I designer adorano i caratteri. Gli ingegneri li temono. Un singolo peso di Circular Std è 30KB (WOFF2). Se carichi Normale, Grassetto, Corsivo, Nero -> 120KB. Ciò blocca la resa del testo (FOIT). Strategia:

Sottoinsieme: non sono necessari caratteri greci/cirillici. Sottoinsieme a Latin-1. (Risparmia il 50%).
Caratteri variabili: utilizzare un file (Inter-Variable.woff2) che contenga tutti i pesi. Gestisce meglio l’animazione.
Self-Host: elimina l’handshake TLS su “fonts.googleapis.com”.

4. Rimando di CSS non critici

Tailwind è fantastico perché è piccolo (10 KB). Ma i vecchi progetti Sass spesso hanno main.css (500KB). Il browser interrompe il rendering finché non viene scaricato main.css. Correzione: estrai “Critical CSS” (stili per l’intestazione/eroe) e incorporalo in <head>. Carica il resto in modo asincrono: <link rel="stylesheet" href="main.css" media="print" onload="this.media='all'"> Questo trucco aumenta l’LCP di circa 1 secondo sulle reti 3G.

5. Interazione con Next Paint (INP): la reattività

Nota: INP ha sostituito FID (First Input Delay) nel marzo 2024.

INP misura la latenza degli eventi. “Quando faccio clic sul pulsante Menu, quanti millisecondi mancano all’apertura effettiva del Menu?” Obiettivo: < 200 millisecondi.

Il colpevole è quasi sempre Il filo conduttore. JavaScript è a thread singolo. Se il browser è impegnato nell’analisi di un enorme pacchetto di idratazione da 5 MB e fai clic su “Menu”, il browser dice: “Aspetta, sono occupato”. L’interfaccia utente si blocca.

Strategie per correggere l’INP

1. Cedi al thread principale Suddividi i compiti lunghi. Se stai ripetendo più di 10.000 elementi, fallo in blocchi.

// Blocco
items.forEach(processo);

// Non bloccante (cedente)
funzione asincrona processAsync() {
  per (costante articolo di articoli) {
    attendono scheduler.postTask(() => processo(elemento));
  }
}

2. Reagisci all’usoTransizione In React 18, usa useTransition per contrassegnare gli aggiornamenti come non urgenti. Questo dice a React: “Se l’utente fa clic, interrompi questo lavoro di rendering per gestire il clic.”

“tsx const [isPending, startTransition] = useTransition();

funzione seleziona scheda(scheda successiva) { startTransizione(() => { setTab(schedasuccessiva); }); }


## 4. Misurazione: dati sul campo e dati di laboratorio

Gli sviluppatori vivono in **Lab Data** (Lighthouse su un MacBook veloce).
Google vive nei **Field Data** (CrUX - Chrome User Experience Report).
CrUX raccoglie dati reali da utenti reali (spesso su telefoni Android lenti).

Il tuo punteggio Faro potrebbe essere 100.
Ma se il tuo utente P75 (75° percentile) ha una connessione lenta, il tuo punteggio CrUX potrebbe essere "Scadente".
**Ottimizza sempre per l'utente P75 su 4G.**

## 5. Impatto su terze parti

Chi sta uccidendo i tuoi Web Vital?
Di solito:
1. **Widget chat** (Intercom/Drift): pacchetti enormi.
2. **Pixel di tracciamento**: blocco del thread principale.
3. **Strumenti di test A/B** (Ottimizzazione): nascondere il contenuto del corpo per un'esperienza "senza sfarfallio" (uccide LCP).

**Soluzione**: spostali su Web Workers utilizzando **Partytown**. (Vedi [Dimensione pacchetto](/it/blog/tech-bundle-size-it)).

## 6. L'API delle regole di speculazione (prerendering)

Questa è l’opzione nucleare per la velocità.
Puoi dire a Chrome di **visualizzare la pagina successiva in background** prima che l'utente faccia clic.
Non basta scaricare l'HTML. *Esegui JS e dipingi i pixel*.
Quando fanno clic, la transizione è **0ms**. Istantaneo.

```json
{
  "prerendering": [
    {
      "fonte": "elenco",
      "url": ["/pagina successiva", "/carrello"]
    }
  ]
}

Lo utilizziamo per il flusso “Aggiungi al carrello” -> “Pagamento”. Sembra un’app nativa.

7. Navigazioni morbide e CWV

In un’app a pagina singola (Next.js), la navigazione dalla home alla pagina del prodotto è una navigazione morbida. In precedenza, Core Web Vitals li ignorava pesantemente. Nel 2024, Google ha aggiornato le metriche per monitorare “INP su Soft Navigations”. Se la transizione JS impiega 500 ms per recuperare JSON ed eseguire il rendering della nuova pagina, non è riuscito LCP/INP. Correzione: utilizza l’interfaccia utente ottimistica. Mostra immediatamente uno scheletro. Non attendere il completamento di await fetch() prima di modificare l’URL.

9. Monitoraggio degli utenti reali (RUM)

Lighthouse è un “test di laboratorio”. Funziona in un ambiente pulito. Gli utenti reali hanno Spotify in esecuzione in background e 50 schede aperte. Hai bisogno di RUM. Utilizziamo Vercel Analytics (o SpeedCurve). Tiene traccia dei dati vitali dei visitatori effettivi. Se il tuo LCP è 1,2s su iPhone 15 ma 4,5s su iPhone 11, te lo dice RUM. I dati di laboratorio mentono. I dati sul campo rilevano perdite di entrate.

10. Perché Maison Code?

Noi di Maison Code siamo estremisti della performance. Non ci limitiamo a “minimizzare i CSS”. Progettiamo per Zero-Layout-Shift e Interazione istantanea. Sappiamo che per i marchi di lusso, “Slow” = “Cheap”. Controlliamo l’intero stack, dall’Edge CDN al React Hydration. Forniamo siti che sembrano nativi, anche su reti 4G del terzo mondo. Perché 100 ms di latenza = calo delle entrate dell’1% (studio Amazon).

12. La differenza tra TBT e INP

Il tempo di blocco totale (TBT) è una metrica di laboratorio. L’interazione con Next Paint (INP) è una metrica di campo. TBT prevede INP. Se il tuo TBT è alto (>200 ms), il tuo INP sarà probabilmente scarso. Ciclo di ottimizzazione:

Esegui Lighthouse (misura TBT).
Ottimizza l’idratazione.
Distribuire.
Attendere 28 giorni per i dati CrUX (misurare INP).
Ripeti. Non aspettare 28 giorni per sapere se hai risolto il problema. Usa TBT come proxy.

13. Conclusione

I Core Web Vitals non sono solo parametri. Sono delegati al rispetto. Rispettando il tempo dei tuoi utenti. Rispettando la batteria del loro dispositivo. Google sta semplicemente imponendo le buone maniere. Se tratti bene l’utente, Google tratta bene te.

Il tuo sito è lento?

La tua Search Console mostra “URL scadenti”? Effettuiamo controlli approfonditi delle prestazioni per risolvere l’inferno dell’idratazione.

Rimediare ai miei parametri vitali. Assumi i nostri architetti.