MAISON CODE .
/ Performance · Core Web Vitals · INP · React

Prestazioni Web: la regola dei 100 ms e la nuova metrica INP

Google ha cambiato le regole con INP (Interaction to Next Paint). ottimizzazione per React Hydration e Edge Caching.

AB
Alex B.
Prestazioni Web: la regola dei 100 ms e la nuova metrica INP

La velocità non è una cosa “bello da avere”. La velocità è l’unica caratteristica che ogni utente sperimenta. Amazon ha scoperto che ogni 100 ms di latenza costano l’1% delle vendite. Walmart ha scoperto che migliorare il tempo di caricamento di 1 secondo ha aumentato le conversioni del 2%. Nel 2025, l’asticella sarà più alta. I Core Web Vitals di Google hanno spostato l’attenzione da LCP (Caricamento) a INP (Interazione con Next Paint). Non è più sufficiente caricare velocemente. Devi rispondere velocemente.

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.

Perché Maison Code è ossessionato da oltre 100 ms

La velocità è il nostro marchio. Non ci limitiamo a “ottimizzare le immagini”. Riarchitettiamo l’intera pipeline di distribuzione.

  • Infrastruttura: eseguiamo l’implementazione sull’Edge (Vercel/Cloudflare) per trovarci entro 50 ms dall’utente.
  • Idratazione: utilizziamo l’idratazione selettiva per rendere interattivo il “pulsante Acquista” prima ancora che venga caricato il piè di pagina.
  • Risultato: i nostri clienti superano costantemente i Core Web Vitals, portando a un miglioramento SEO misurato del 15-20%. Trattiamo i budget di performance come budget finanziari. La spesa eccessiva non è un’opzione.

L’API delle regole di speculazione

La richiesta di rete più veloce è quella che non fai. Nel 2025, utilizziamo la Speculation Rules API per eseguire il pre-rendering delle pagine prima che l’utente faccia clic. Questo non è un “precaricamento” standard. Chrome costruisce letteralmente il DOM in una scheda in background. Quando l’utente fa clic, la transizione è 0 ms. Istantaneo.

<!-- Inserimento di regole di speculazione -->
<script type="speculationrules">
{
  "prerendering": [
    {
      "fonte": "documento",
      "dove": {
        "e": [
          { "href_matches": "/products/*" },
          { "selector_matches": "a:hover" }
        ]
      }
    }
  ]
}
</script>

Sicurezza e utilizzo dei dati

Una delle preoccupazioni legate alla speculazione è l’utilizzo dei dati. Se prerenderizziamo 10 pagine e l’utente ne visita 0, sprecheremo larghezza di banda. Il browser è intelligente. Si ipotizza solo se:

  1. L’utente è connesso al Wi-Fi (non in modalità Risparmio dati).
  2. Il dispositivo dispone di memoria sufficiente. Tuttavia, per un sito di e-commerce, la “Prossima Azione” è estremamente prevedibile. In una PDP (pagina dei dettagli del prodotto), l’azione successiva è “Aggiungi al carrello” o “Torna alla collezione”. Speculando su questi due percorsi si ottiene un tasso di successo del 90%.

INP: il killer della reazione?

INP misura il tempo dal “clic” al “dipingere”. L’idratazione di React è nemica dell’INP. Se un utente fa clic su “Aggiungi al carrello” mentre React sta idratando il piè di pagina, il thread principale viene bloccato. Il pulsante ignora il clic. Il punteggio INP arriva a 400 ms (Scarso). Google penalizza il tuo SEO.

Ottimizzazione dell’INP in Headless

  1. Idratazione selettiva: idrata solo i componenti visibili. (Vedi Atomic Design per l’isolamento dei componenti).
  2. Web Worker: sposta la logica pesante (Analytics, GTM) su un Web Worker tramite Partytown.
  3. API di transizione: utilizza useTransition per contrassegnare gli aggiornamenti non urgenti.

“tsx // Implementazione di React 19 useTransition importa { useTransition } da ‘react’;

funzione Aggiungi al carrello({ id }) { const [isPending, startTransition] = useTransition();

const handleClick = () => { // Urgente: aggiorna immediatamente l’interfaccia utente setOptimisticCartCount(c => c + 1);

// Non urgente: richiesta di rete/aggiornamento dello stato
startTransizione(() => {
  addToCart(id);
});

};

ritorno ( {è in sospeso? ‘Aggiunta…’: ‘Aggiungi al carrello’} ); }


## The Edge: la geografia conta
Se il tuo server è in Virginia (us-east-1) e il tuo cliente è a Parigi, la velocità della luce impone una penalità di 100 ms.
Non puoi battere la fisica.
È necessario spostare il computer.
**Edge Rendering** (Oxygen/Vercel) esegue la logica SSR in un data center più vicino all'utente.

### Stale-While-Revalidate (SWR)
Non vogliamo colpire l'origine per ogni richiesta.
Utilizziamo la strategia della cache SWR, un vantaggio fondamentale di [Headless Architecture](/it/blog/tech-idrogen-vs-liquid-it).
1. L'utente A visita "/prodotti/scarpe".
2. Edge offre la versione stale (istantanea).
3. Edge recupera la versione fresca in background.
4. L'utente B ottiene la versione Fresh.

Nelle intestazioni Remix/Hydrogen:
"dattiloscritto".
intestazioni delle funzioni di esportazione() {
  ritorno {
    'Cache-Control': 'public, max-age=60, s-maxage=3600, stale- while-revalidate=86400',
  };
}

Ottimizzazione dell’immagine: AVIF è il re

Dimentica WebP. AVIF è lo standard. È più piccolo del 30% rispetto a WebP e supporta le gamme di colori HDR (essenziali per la moda). Il CDN di Shopify supporta la formattazione automatica AVIF. Forza sempre format=auto nel caricatore di immagini.

La strategia “LQIP”.

Segnaposto per immagini di bassa qualità. Mentre l’immagine ad alta risoluzione viene caricata, mostra una versione sfocata di 10 px. Ciò impedisce il “Layout Shift” (CLS) e dà la percezione della velocità. Generiamo LQIP in fase di compilazione o tramite una funzione serverless.

Script di terze parti: The Silent Killer

Le agenzie adorano installare script. Hotjar, Klaviyo, Yotpo, Facebook Pixel, TikTok Pixel, Snap Pixel. Ognuno consuma 50 ms di tempo del thread principale. Totale = blocco di 300 ms.

Il problema con “Async”

Gli sviluppatori pensano che “Async” significhi “Non bloccante”. Significa “recupero non bloccante”. Ma l’Esecuzione è bloccante. Quando Facebook Pixel viene eseguito, blocca il thread principale per raschiare il DOM.

Soluzione: GTM lato server

Sposta i pixel sul server.

  1. Il browser invia UN evento al tuo server (ad esempio POST /api/events).
  2. Il tuo server (GTM Server Container) lo riceve.
  3. Il tuo server lo invia a Facebook, TikTok, Google Ads. Impatto lato client pari a zero. Bonus: ignora gli AdBlocker perché la richiesta va al tuo dominio.

Soluzione: Partytown

Se DEVI eseguire script lato client (come Hotjar, che necessita del DOM), eseguili in un Web Worker. Partytown è una libreria che proxy mutazioni DOM da un lavoratore al thread principale. Crea una sandbox in cui è possibile eseguire pesanti script di terze parti senza bloccare l’interfaccia utente.

<script type="text/partytown" src="https://connect.facebook.net/en_US/fbevents.js"></script>

Strategie di caricamento dei caratteri

La tipografia è sorprendentemente pesante. Un file di caratteri personalizzati (WOFF2) è ~50kb. Se blocchi il rendering fino al caricamento del carattere (FOIT - Flash of Invisible Text), l’utente fissa uno schermo vuoto. Se mostri il carattere di fallback (FOUT - Flash of Unstyled Text), il layout cambia.

Lo stack di caricamento dei caratteri perfetto

  1. Sottoinsieme: includi solo i caratteri che ti servono (Latin-1).
  2. Preload: utilizzare <link rel="preload"> per il carattere critico (intestazione).
  3. Scambia: utilizza font-display: swap. Mostra immediatamente il testo in Helvetica, quindi passa al tuo carattere.
  4. Regolazione dimensione: utilizza CSS “regolazione dimensione” per fare in modo che il carattere di riserva occupi esattamente lo stesso spazio del carattere personalizzato. Ciò elimina lo spostamento del layout.
@font-face {
  famiglia di caratteri: 'Bodoni Fallback';
  src: local('Times New Roman');
  forzatura salita: 90%;
  esclusione discesa: 20%;
  regolazione della dimensione: 140%;
}

RUM rispetto ai dati di laboratorio

Lighthouse (Lab Data) è una simulazione. Si presuppone un Motorola G4 su rete 3G. RUM (Real User Monitoring) è realtà. Misura ciò che sperimentano gli utenti reali. Potresti avere un punteggio Lighthouse di 100, ma se i tuoi utenti reali utilizzano vecchi iPhone in una metropolitana, i tuoi dati RUM mostreranno 3s LCP. Integriamo Vercel Analytics o Datadog RUM per tracciare il p75 (75° percentile) delle esperienze reali. Se il tuo p75 è verde, sei a posto. Se il tuo Faro è 100 ma p75 è rosso, stai fallendo.

Conclusione

La performance è una cultura ingegneristica. Devi disporre di un Budget di rendimento. “Se questo PR aggiunge 10kb al pacchetto, qualcos’altro deve andare.” Attenersi alla regola dei 100 ms. Se impiega più di 100 ms, sembra rotto. I siti di e-commerce più veloci non si limitano a “sentirsi” veloci. Si sentono invisibili. L’interfaccia scompare, lasciando solo il desiderio e il prodotto.

Assumi i nostri architetti.