Settimana scorsa un cliente chiama disperato: "Il mio sito è sparito dalla prima pagina, eppure i contenuti sono perfetti". Apro Search Console e boom — tutti i Core Web Vitals in rosso. LCP a 4.8 secondi, CLS che salta ovunque come un grillo impazzito.

Due settimane dopo, stesso sito: LCP a 1.6s, CLS a 0.04, e il traffico organico aumentato del 130%. Non abbiamo toccato neanche una virgola del contenuto. Solo performance.

Ecco il punto: da quando Google ha inserito i Core Web Vitals nell'algoritmo (metà 2021), la velocità non è più "nice to have" — è un fattore di ranking vero e proprio. E non parliamo di test sintetici fatti su Lighthouse da un Mac super performante. Google prende i dati reali da milioni di utenti Chrome che visitano il sito ogni giorno (field data). Se il sito è lento per loro, il posizionamento ne risente.

Le 3 metriche fondamentali dei Core Web Vitals

1. Largest Contentful Paint (LCP) - quanto ci vuole a caricare?

Target: sotto 2.5 secondi (ma puntare a 1.8s è meglio)

L'LCP misura semplicemente quanto ci vuole a mostrare il pezzo più grosso della pagina: l'immagine hero principale, il titolo grande, il video in cima. Quello è il valore LCP.

Il problema classico: immagine hero da 3.2MB perché il cliente ha caricato la foto direttamente dal telefono senza passare per un tool di compressione. Risultato? LCP di 4+ secondi anche con fibra.

Checklist di debug (in ordine di impatto):

  1. Immagini ottimizzate — convertire tutto in WebP o AVIF. Un JPG da 800KB diventa un WebP da 120KB. Stessa qualità visiva, 85% di peso in meno.
  2. Preload dell'hero image — aggiungere <link rel="preload" as="image" href="/hero.webp"> nell'head. Così il browser la carica subito invece di scoprirla solo dopo aver parsato tutto il CSS.
  3. CDN decente — se il server è a Milano e un utente visita da Palermo, la latenza da sola può aggiungere 200-300ms. Cloudflare gratis risolve questo problema in 5 minuti.
  4. TTFB sotto i 600ms — se il server impiega più di mezzo secondo solo per rispondere, c'è un problema di backend/hosting. Spesso basta passare da un shared hosting a un VPS base per vedere miglioramenti del 70%.

Implementazione pratica:

html
<!-- Preload dell'immagine hero critica -->
<link rel="preload" href="/hero.webp" as="image">

<!-- Lazy loading per immagini below-the-fold -->
<img src="/image.webp" loading="lazy" width="800" height="600" alt="Descrizione immagine">

2. First Input Delay (FID) / Interaction to Next Paint (INP) - quando si clicca, rispondere subito

Target INP: sotto 200ms (il FID è praticamente morto, Google usa l'INP dal marzo 2024)

Chi non ha mai cliccato su un pulsante e il sito ha fatto finta di niente per 2 secondi? Quell'esperienza corrisponde a un INP alto. La metrica misura il tempo che passa tra un'interazione utente (click, tap, digitazione) e la risposta visiva del browser.

Il colpevole numero uno? JavaScript. Troppo JavaScript che blocca il main thread.

Esempio reale:

Sito e-commerce, INP a 680ms. Aperto Chrome DevTools → Performance, registrati 6 secondi di interazione: un long task di 1.2 secondi causato da Google Analytics che si caricava in modo sincrono insieme a 4 altri script di tracking. Fix: tutto spostato in defer, INP sceso a 140ms.

Come risolvere (ordine di priorità):

  1. Defer di tutto lo script non critico — analytics, chatbot, pixel di tracciamento. Aggiungere defer o async su tutti i tag script non necessari per il rendering.
  2. Code splitting — un bundle JS da 800KB causa rallentamenti. Suddividerlo e caricare solo quello che serve per la pagina corrente.
  3. Lazy load dei componenti pesanti — la chat di supporto in homepage può aspettare 2 secondi prima di caricarsi.
  4. Rimozione librerie inutili — jQuery + Lodash + Moment.js su un sito che usa 3 funzioni. Rimpiazzarle con vanilla JS moderno risparmia 150KB.

Implementazione pratica:

html
<!-- Differimento di script analytics non critici -->
<script src="/analytics.js" defer></script>

<!-- Caricamento asincrono di librerie terze -->
<script async src="/third-party-lib.js"></script>

3. Cumulative Layout Shift (CLS) - basta layout che saltano

Target: sotto 0.1 (ma sotto 0.05 è meglio)

Il CLS è la metrica più fastidiosa da debuggare ma anche la più importante per l'UX. Misura quanto la pagina "salta" mentre si carica.

Scenario classico: si sta per cliccare su un link, improvvisamente salta giù un banner pubblicitario, e il click finisce sull'annuncio invece che sul link. Oppure: si sta leggendo un articolo, si carica un'immagine senza dimensioni predefinite, tutto il testo scende di 400px.

Il peggior caso visto:

Sito di news, CLS a 0.87. Il problema? Banner pubblicitari caricati asincronamente senza placeholder. Ogni 3 secondi si caricava un nuovo banner e il contenuto saltava su e giù. Bounce rate altissimo.

Soluzione: riservato lo spazio fisso per i banner prima che si carichino. CLS sceso a 0.03 e bounce rate diminuito del 40%.

I 4 colpevoli principali del CLS (e come risolverli):

  1. Immagini senza dimensioni — aggiungere sempre width e height nell'HTML. Il browser può riservare lo spazio giusto prima che l'immagine si carichi.
  2. Font web che si caricano tardi — usare font-display: swap o optional. Altrimenti il browser mostra il font di sistema, poi carica quello custom e ricalcola tutto il layout.
  3. Banner/annunci dinamici — riservare sempre lo spazio con un placeholder CSS. Meglio un buco vuoto per 2 secondi che far saltare tutta la pagina.
  4. Contenuti caricati via JavaScript — se si caricano contenuti dinamicamente, riservare lo spazio prima. Usare skeleton loaders o placeholder con altezza minima.

Implementazione pratica:

html
<!-- Specifica width e height per prevenire layout shift -->
<img src="/logo.png" width="200" height="100" alt="Logo aziendale">

<!-- Font loading ottimizzato -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap">

CSS per animazioni performanti:

css
/* ✅ Performante - usa GPU acceleration */
.element {
  transform: translateY(0);
  transition: transform 0.3s ease;
}

.element:hover {
  transform: translateY(-5px);
}

/* ❌ Causa reflow - evitare */
.element {
  top: 0;
  transition: top 0.3s ease;
}

Gli strumenti che usiamo davvero

Per misurare i dati reali:

  • Google Search Console — vai su "Core Web Vitals" nella sidebar. Mostra i dati veri degli ultimi 28 giorni da utenti reali. Se è rosso lì, c'è un problema vero.
  • PageSpeed Insights — inserire l'URL, scorrere fino a "Field Data". I lab data servono per il debug, ma i dati reali sono quelli che contano.

Per debuggare:

  • Chrome DevTools (tab Performance) — registrare 6-10 secondi di caricamento pagina e vedere esattamente cosa rallenta. I long tasks sopra i 50ms sono i nemici principali.
  • WebPageTest — utile per simulare connessioni 3G o verificare il comportamento del sito da diverse città.

Attenzione: non ossessionarsi con i punteggi di Lighthouse. Abbiamo visto siti con 95/100 su Lighthouse che deludevano sui field data perché testati da ufficio con fibra 1Gbps. I dati reali di Search Console sono quelli che contano.

Il processo step-by-step per ottimizzare un sito

Settimana 1 — diagnosi:

  1. Aprire Search Console → Core Web Vitals
  2. Identificare le pagine peggiori (di solito homepage e pagine prodotto)
  3. Testarle su PageSpeed Insights + WebPageTest
  4. Fare uno screenshot del "prima" per avere confronto dopo

Settimana 2-3 — fix:

  1. Iniziare sempre dall'LCP (impatto maggiore)
  2. Poi CLS (spesso fix veloci)
  3. Infine INP (di solito richiede più tempo)

Settimana 4+ — monitoraggio: Attendere che Google raccolga dati nuovi (ci vogliono ~28 giorni). Controllare Search Console ogni settimana. Se i numeri migliorano, continuare. Se no, tornare al punto 3.

Errore comune: modificare 15 cose insieme e non sapere cosa ha funzionato. Una modifica alla volta, qualche giorno di attesa, misurazione. Poi si ripete.

La verità sui Core Web Vitals

Ottimizzare le performance è un lavoro continuo. Non è "fai una volta e via". Le cose cambiano — si aggiungono nuove feature, si caricano più script, i clienti vogliono quel banner animato che pesa 2MB.

Ma ne vale la pena? Assolutamente sì. Negli ultimi 2 anni abbiamo visto:

  • E-commerce passare da 2.1% a 3.8% di conversion rate solo fixando il CLS nel checkout
  • Blog aumentare il tempo medio di permanenza da 1:20 a 3:45 dopo aver ottimizzato LCP
  • Siti aziendali scalare dalla pagina 2 alla pagina 1 in 6 settimane (nessuna modifica ai contenuti)

Il punto è questo: Google premia chi fa le cose bene. Un sito veloce non è solo "nice to have" — è un vantaggio competitivo reale.

Per un check gratuito, PerSeo Insights esegue una scansione completa e indica esattamente cosa ottimizzare, in ordine di priorità. Poi si può implementare autonomamente o chiedere una mano.