Un sito che fa cagare non è un dettaglio estetico. È un costo che paghi ogni giorno.

Il 53% delle visite da mobile abbandona una pagina che impiega più di 3 secondi a caricare. Non è una statistica da slide: è traffico che paghi per portare sul sito e perdi prima ancora che qualcuno legga una parola. La performance tecnica non è un dettaglio per sviluppatori. È una leva diretta su SEO, conversioni e costo di acquisizione.

Cosa misura Google, davvero

I Core Web Vitals sono tre metriche, non un punteggio generico da rincorrere. Largest Contentful Paint (LCP) misura quanto tempo impiega il contenuto principale a comparire: sotto i 2,5 secondi è buono, oltre i 4 è un problema. Interaction to Next Paint (INP) misura la reattività dell'interfaccia quando l'utente clicca, tocca o scrive: sopra i 200 millisecondi il ritardo si sente. Cumulative Layout Shift (CLS) misura quanto la pagina "salta" mentre carica: sotto 0,1 è stabile, sopra 0,25 è quel bottone che si sposta un attimo prima che tu ci clicchi sopra.

Google usa questi tre numeri come segnale di ranking diretto. Ma il motivo per cui contano non è l'algoritmo: è che misurano esattamente il momento in cui un utente decide se restare o andarsene.

Il costo reale di un sito lento

Un sito che carica in 1 secondo converte fino a 3 volte in più di uno che ne impiega 5, secondo uno studio Portent su oltre 100 milioni di visite e-commerce. Non è un margine che si recupera con una campagna ads più aggressiva: è conversione che sparisce prima del funnel, indipendentemente da quanto sia buono il resto del sito.

La maggior parte dei siti aziendali non è lenta per un motivo tecnico complesso. È lenta perché nessuno l'ha mai misurata: immagini non ottimizzate, JavaScript caricato prima che serva, font che bloccano il rendering, terze parti (chat, analytics, pixel pubblicitari) che si sommano senza controllo.

Cosa costruiamo per restare nel verde

Non è una checklist da eseguire una volta a progetto finito. È come scriviamo il codice dal primo commit:

• React Server Components di default: il JavaScript arriva al browser solo dove serve davvero interattività, non per l'intera pagina.
• Immagini servite da next/image con dimensioni esplicite e formati moderni (WebP/AVIF), per eliminare layout shift e peso inutile.
• Font caricati con next/font e self-hosting: zero richieste bloccanti verso Google Fonts, zero flash di testo invisibile.
• Streaming e Suspense per il contenuto sopra la piega, così l'utente vede qualcosa di utile prima che l'intera pagina sia pronta.
• Cache a livello di CDN con invalidazione mirata (tag o path), non un generico "aggiorna ogni ora e spera".

La performance non si aggiunge alla fine

Il pattern più comune che vediamo è il contrario: si costruisce il sito, poi "si ottimizza" nelle ultime due settimane. A quel punto la performance è un vincolo che si scontra con scelte di architettura già prese, non una caratteristica del prodotto.

Noi la trattiamo come un requisito fin dalla prima riga di codice, e la misuriamo dopo il lancio con gli stessi strumenti che usa Google. Non una volta e basta: continuamente, perché ogni nuova feature è un'occasione per rompere quello che avevi già ottimizzato.