Migliorare i Core Web Vitals: l'ordine che aiuta davvero

Attivare un plugin di caching è il primo passo e spesso l'unico che si fa. Dopo, il valore resta su «da migliorare» e lì rimane. Il motivo: le tre metriche misurano tre cose diverse, e il caching aiuta davvero solo con una di esse.

I tre valori, una frase ciascuno

Da qui deriva l'ordine: prima le immagini, poi gli script, poi il layout. Il caching agisce soprattutto sul tempo del server — quindi su una parte dell'LCP, e sull'INP quasi per niente.

Passo 1: l'immagine più grande

Nella maggior parte delle pagine l'immagine hero è la candidata per l'LCP. Tre cose aiutano subito, in quest'ordine:

1. Ridurla alle dimensioni effettivamente necessarie — una foto larga 4000 pixel in un'area larga 1200 pixel è la singola causa più frequente.
2. Convertirla in un formato moderno (WebP o AVIF), con un'alternativa per i browser datati.
3. NON caricarla in lazy-load. L'immagine in cima deve essere caricata subito — qui il lazy-load peggiora il valore invece di migliorarlo.

Verifica dove avviene la conversione. Alcuni plugin inviano per questo le tue immagini a un servizio del produttore. Chi non lo vuole ha bisogno di uno strumento che converta in locale — allora il primo passaggio richiede più tempo, ma nulla esce di casa.

Passo 2: il JavaScript

L'INP è il valore su cui il caching non aiuta. Misura quanto tempo impiega il browser a reagire a un clic — e a bloccarlo sono gli script che lavorano proprio in quel momento.

La leva più efficace è eliminare: uno slider che nessuno usa; una finestra di chat su ogni pagina; tre famiglie di font, di cui due passano inosservate. Solo dopo valgono la pena defer, l'unione dei file e il rinvio fino alla prima interazione.

Passo 3: fermare i salti

• Ogni immagine ha bisogno di width e height nel markup — così il browser riserva lo spazio
• Inserire i contenuti incorporati in un contenitore ad altezza fissa
• Distribuire i font in locale e gestirli con font-display, invece di caricarli dall'esterno in un secondo momento
• Inserire banner dei cookie e barre di avviso in modo che si sovrappongano al contenuto invece di spostarlo

Solo dopo: caching, Minify, Preload

Una cache delle pagine risparmia la generazione della pagina — è molto se il server è lento, e poco se è veloce. Minify risparmia byte ed è la causa più frequente di pagine rotte dopo un'ottimizzazione. Preload è un ordine, non una richiesta: troppi preload scalzano proprio ciò che serve per primo.

Attiva Minify un'opzione alla volta e verifica ogni volta una pagina con un modulo, il carrello e una pagina con un video. Chi attiva tutto in una volta, in caso di errore deve cercare tra dieci interruttori.

Misurare correttamente

Due misurazioni vanno tenute distinte. Un test di laboratorio misura in condizioni fisse ed è utile per confrontare il prima e il dopo. I dati sul campo provengono da visitatori reali con dispositivi e connessioni reali — sono loro a decidere come Google classifica la pagina.

Quindi: misurare sempre nelle stesse condizioni, tre volte invece di una, e tenere presente che i dati sul campo richiedono settimane prima di mostrare una modifica. Chi controlla dopo un'ora e non nota nulla non ha ottimizzato troppo poco, ha guardato troppo presto.

Quando il plugin non aiuta più

C'è un limite oltre il quale nessun plugin di caching può andare: un page builder sovraccarico con trenta script, un hosting con un carico di base elevato, un tema che carica tutto su ogni pagina. Se la risposta del server è lenta già senza contenuto, il problema non è il plugin.

Domande frequenti