LCP, INP e CLS: migliorare le prestazioni del sito

Perché questi tre indicatori contano davvero

LCP, INP e CLS sono tre metriche che raccontano se un sito si vede presto, risponde bene e rimane stabile mentre si carica. Non servono per decorare un report: servono per capire dove l’esperienza utente si rompe. Se una pagina appare subito ma blocca i clic, oppure se gli elementi saltano mentre leggi, il problema è reale anche quando il server risponde “veloce”.

LCP misura il momento in cui l’elemento principale della pagina diventa visibile. INP valuta quanto il sito risponde alle interazioni. CLS controlla quanto il layout si sposta in modo inatteso. Lavorare su questi tre punti significa migliorare caricamento percepito, reattività e stabilità visiva. E in pratica significa più conversioni, meno abbandoni e meno siti “pesanti” anche quando il backend è sano.

Prima diagnosi, poi intervento

Il primo errore è ottimizzare alla cieca. Serve capire quale metrica è fuori soglia e su quali pagine. Una homepage con hero enorme non si tratta come un articolo blog o una scheda prodotto. La diagnosi utile parte sempre da tre domande:

• Qual è il peggior elemento o interazione?
• Il problema è lato contenuto, JavaScript, CSS, font, immagini o rete?
• Succede su tutte le pagine o solo su alcune tipologie?

Se hai accesso a strumenti di analisi, il punto di partenza più pratico è PageSpeed Insights o il report Core Web Vitals di Search Console. In locale o in staging, osserva anche il waterfall e i tempi di rendering: spesso il colpevole non è il server in sé, ma il modo in cui la pagina usa le risorse.

LCP: come far comparire prima il contenuto principale

LCP peggiora quando l’elemento principale arriva tardi. Nella maggior parte dei siti è un’immagine hero, un blocco testo con font esterni, oppure un grande banner inserito da uno slider o da un page builder. Il principio è semplice: ridurre il tempo tra richiesta e primo rendering utile.

1. Ottimizza l’elemento LCP

Se l’elemento principale è un’immagine, deve essere leggera, ben dimensionata e servita nel formato giusto. Non caricare un file da 3000 px per mostrarlo a 1200 px. Usa dimensioni reali, compressione efficace e, quando possibile, formati moderni come WebP o AVIF. Se il contenuto è un blocco testuale, controlla che il font non blocchi la visualizzazione.

• Riduci peso e dimensioni dell’immagine principale.
• Evita slider o caroselli sopra la piega.
• Se l’hero è un video o una animazione, valuta una cover statica.
• Verifica che l’elemento LCP sia nel markup iniziale, non iniettato tardi via JavaScript.

2. Dai priorità al contenuto above the fold

Il browser deve capire subito cosa è importante. Se l’hero è il contenuto principale, non deve aspettare risorse secondarie. In pratica:

• carica prima HTML e CSS essenziali;
• rimanda i componenti non visibili subito;
• evita script che bloccano il rendering;
• non sovraccaricare la testata con widget, popup e tracker.

Quando il tema o il CMS genera troppo codice iniziale, conviene semplificare il template della pagina più importante. Un layout pulito e una gerarchia chiara fanno spesso più di una decina di plugin.

3. Riduci il tempo di risposta del server e della cache

LCP non è solo frontend. Se il TTFB è alto, tutto il resto parte in ritardo. Qui servono controlli pratici: cache di pagina, cache oggetti, PHP aggiornato, query veloci e hosting senza saturazione. Se il sito è WordPress, una cache ben configurata spesso ha impatto immediato. Se è un e-commerce, attenzione a pagine dinamiche e a esclusioni eccessive che annullano il beneficio.

• Attiva cache lato server o plugin di cache affidabile.
• Verifica che HTML statico e asset statici siano serviti con cache corretta.
• Controlla TTFB su homepage, categorie e pagine prodotto.
• Se il backend è lento, analizza query, CPU e I/O prima di toccare il tema.

4. Precarica ciò che serve davvero

Il preload è utile, ma va usato con disciplina. Precaricare tutto peggiora la coda delle risorse. Ha senso per il font principale, per l’immagine LCP se nota e stabile, oppure per un CSS critico. Non è una scorciatoia universale: se sbagli priorità, sottrai banda ai file che servono prima.

Per capire se il preload aiuta, confronta il tempo del LCP prima e dopo. Se il miglioramento non è visibile, torna indietro: il preload non deve diventare una religione.

INP: come rendere il sito reattivo ai clic

INP misura la qualità della risposta alle interazioni: click, tap, input. Un sito può avere un buon LCP e restare comunque irritante se ogni azione ha ritardo. Il colpevole tipico è JavaScript troppo pesante, non ottimizzato o eseguito tutto insieme.

1. Taglia il lavoro principale del thread

Il browser ha un thread principale che gestisce parte del rendering e dell’interazione. Se lo blocchi con script grandi, il sito sembra “duro”. Per ridurre il problema:

• carica in modo deferito gli script non critici;
• rimanda librerie usate solo in sezioni secondarie;
• elimina plugin e widget non indispensabili;
• separa il codice del primo schermo da quello del resto della pagina.

Molti siti moderni soffrono perché caricano framework, tracker, chat, mappe e animazioni insieme. Ogni pezzo può essere legittimo, ma il risultato è una coda di lavoro troppo lunga. La soluzione non è “togliere tutto”, ma far lavorare il browser in modo ordinato.

2. Spezza i compiti lunghi

Un task JavaScript che occupa il thread troppo a lungo penalizza INP. Anche se il codice è corretto, una funzione pesante eseguita al momento sbagliato rovina l’esperienza. È utile dividere il lavoro in blocchi più piccoli, rimandare le operazioni non urgenti e usare solo ciò che serve davvero quando serve davvero.

• Evita script che elaborano grandi liste all’onload.
• Carica i componenti interattivi solo quando entrano in viewport.
• Usa event listener essenziali e non duplicati.
• Controlla il numero di script di terze parti.

3. Limita terze parti e tracker

Ogni script esterno è un rischio per INP. Chat, analytics, pixel pubblicitari, mappe embed e widget social possono essere utili, ma vanno misurati. Se un sito ha molte integrazioni, la domanda non è “funzionano?”, ma “quanto costano?”. Spesso basta disattivarne una o spostarla dopo l’interazione iniziale per migliorare sensibilmente la reattività.

Un test semplice è aprire la pagina con e senza le terze parti attive e confrontare la sensazione d’uso. Se i clic diventano più pronti e il rendering è più fluido, hai trovato una fonte di blocco reale.

4. Migliora il comportamento dei componenti interattivi

Menu, filtri, accordion, slider e modali devono essere leggeri. Un menu che apre un intero framework o una modale che ricalcola il layout di tutta la pagina è un problema. Preferisci componenti semplici, con stato locale e dipendenze minime. Se usi un page builder, controlla che gli elementi dinamici non vengano inizializzati tutti insieme all’avvio.

CLS: come evitare i salti di layout

CLS misura gli spostamenti inattesi degli elementi. È una metrica molto pratica: se l’utente legge un testo e tutto si sposta per l’arrivo di una immagine, di un banner o di un font, l’esperienza peggiora subito. Qui il principio è semplice: riservare spazio prima che il contenuto arrivi.

1. Definisci sempre le dimensioni di immagini e video

Le immagini senza dimensioni note sono tra le cause più comuni di CLS. Il browser non sa quanto spazio riservare e il layout si adatta dopo il caricamento. Specificare width e height, oppure un rapporto d’aspetto coerente, evita lo scatto visivo.

• Imposta dimensioni o aspect ratio per ogni immagine.
• Evita banner e embed senza spazio riservato.
• Usa placeholder coerenti per contenuti caricati in ritardo.
• Controlla anche gli iframe, non solo le immagini.

2. Non inserire contenuti sopra ciò che l’utente sta leggendo

Cookie banner, promo bar, notifiche e popup sono spesso la causa del problema. Se compaiono e spingono il contenuto verso il basso, il CLS sale. La soluzione più pulita è riservare spazio sin dall’inizio, oppure posizionare gli avvisi in overlay senza spostare il layout principale, compatibilmente con accessibilità e conformità legale.

Attenzione anche ai blocchi che si espandono dopo il caricamento, come recensioni, moduli embedded o annunci. Se un elemento può crescere, deve avere già il suo spazio.

3. Gestisci i font con attenzione

I font web possono causare flicker e shift quando cambiano le metriche di testo. Usa una strategia coerente: font di sistema o font web ben ottimizzati, con fallback simili e caricamento controllato. Se il font principale arriva tardi e sostituisce un fallback molto diverso, il testo può ridistribuirsi e spostare il layout.

• Limita il numero di varianti font.
• Usa fallback simili per dimensioni e spaziatura.
• Valuta il caricamento con font-display appropriato.
• Precarica solo il file realmente usato above the fold.

4. Evita annunci e componenti dinamici senza contenitore

Molti siti editoriali soffrono per blocchi pubblicitari inseriti dopo il render iniziale. Se il contenitore non ha dimensioni fisse, l’intera colonna può saltare. La regola pratica è semplice: ogni slot dinamico deve avere una riserva di spazio stabile, anche quando il contenuto non è ancora arrivato.

Una strategia di lavoro che funziona davvero

Non conviene partire dalla singola ottimizzazione “alla moda”. Conviene seguire un ordine stabile:

1. Individua la metrica peggiore tra LCP, INP e CLS.
2. Trova la pagina più colpita e il componente responsabile.
3. Se il problema è visivo, intervieni su immagini, font, spazi riservati e contenuti above the fold.
4. Se il problema è reattivo, riduci JavaScript, terze parti e task lunghi.
5. Se il problema è lato server, migliora cache, query, PHP e risorse hosting.
6. Rimisura dopo ogni modifica, non dopo dieci insieme.

Questo approccio evita due errori classici: fare cambi casuali senza capire il risultato, oppure introdurre una modifica che migliora una metrica e ne peggiora un’altra. Per esempio, una hero immagine troppo aggressivamente compressa può migliorare LCP ma peggiorare la percezione del brand. Un sito più leggero non deve diventare un sito povero.

Interventi rapidi ad alto rendimento

Se devi scegliere da dove partire, ci sono alcune azioni che danno spesso i risultati migliori con il rischio più basso:

• ridurre il peso dell’immagine principale;
• rimandare gli script non critici;
• eliminare slider e animazioni inutili sopra la piega;
• assegnare dimensioni fisse a immagini, embed e annunci;
• attivare cache e compressione correttamente;
• rimuovere terze parti non essenziali;
• controllare font e fallback.

Questi interventi non richiedono rivoluzioni architetturali e spesso sono reversibili. È il tipo di lavoro giusto quando si vuole migliorare il sito senza rischiare downtime o regressioni pesanti.

Errori comuni da evitare

Ci sono alcune scorciatoie che sembrano utili ma spesso peggiorano tutto:

• Precaricare troppo: occupa banda e non sempre aiuta.
• Minificare senza misurare: la minificazione non risolve un problema di architettura.
• Installare plugin a catena: ogni plugin in più può aggiungere JS, CSS e query.
• Nascondere il problema con il cache: la cache aiuta, ma non corregge un layout instabile o uno script pesante.
• Ignorare il mobile: spesso il punteggio peggiore è lì, non su desktop.

La regola è sempre la stessa: il miglioramento deve essere misurabile e ripetibile. Se non riesci a spiegare quale risorsa, quale componente o quale blocco di codice ha cambiato la metrica, la modifica è ancora sospetta.

Come verificare se hai davvero migliorato

Un sito migliora davvero quando il visitatore lo percepisce più rapido e stabile. Per verificarlo, controlla sempre gli stessi punti dopo ogni intervento:

1. il LCP scende e l’elemento principale appare prima;
2. l’INP migliora e i clic rispondono senza ritardi evidenti;
3. il CLS resta basso e non ci sono salti visibili;
4. la pagina resta coerente su mobile e desktop;
5. non sono stati introdotti nuovi blocchi o regressioni.

Se puoi usare strumenti di test, confronta prima e dopo sulla stessa pagina, con la stessa connessione e possibilmente nello stesso stato di cache. Se il sito usa un CMS, prova anche una pagina nuova e una già cache-ata: i risultati possono essere molto diversi.

Conclusione pratica

Migliorare LCP, INP e CLS non significa inseguire un punteggio perfetto. Significa togliere attrito dove l’utente lo sente davvero: prima che il contenuto appaia, mentre prova a interagire e quando il layout cambia senza motivo. La strada più efficace è quasi sempre la stessa: contenuto principale più leggero, JavaScript più sobrio, spazio riservato agli elementi dinamici e cache ben configurata.

Se lavori con metodo, una pagina più veloce non è solo più bella nei report: è più semplice da usare, più affidabile e più solida nel tempo. E soprattutto smette di sorprendere l’utente nel modo sbagliato.

Ordine giusto: misura, isola il colpevole, applica un fix reversibile, verifica di nuovo. È così che le Core Web Vitals smettono di essere teoria e diventano manutenzione reale.