La pagina si apre, ma il contenuto principale arriva tardi: come migliorare l’LCP

Partire dalle pagine e dalle attese dei clienti

Raccogli alcuni indirizzi che contano per l’attività: la pagina di un servizio cercato, una scheda prodotto e la destinazione di una campagna. Aggiungi una pagina che sembra funzionare bene. Per ciascuna annota dispositivo, browser, rete e ciò che compare per ultimo. Una registrazione della prima apertura è più utile della sola frase “la home è lenta”.

Ripeti la prova senza confondere la prima visita con il ritorno a una pagina già caricata. Indica se il banner è già stato accettato e se l’utente è collegato a un account. Sono condizioni da riportare, non variabili da cambiare contemporaneamente. Se la difficoltà riguarda soprattutto i comandi dopo l’apertura, consulta invece la guida su pulsanti, menu e INP.

Capire quale elemento misura l’LCP

Largest Contentful Paint osserva quando viene mostrato il più grande elemento di contenuto idoneo nell’area visibile: può essere un’immagine, un blocco di testo o un video. Non coincide necessariamente con il logo né con il momento in cui ogni file ha terminato il download. La documentazione web.dev sull’LCP (si apre in una nuova scheda) considera buono un valore entro 2,5 secondi al 75° percentile delle visite.

Chiedi al tecnico di mostrarti l’elemento identificato nella prova. Sul telefono potrebbe essere diverso da quello sul computer perché cambiano impaginazione e porzione visibile. Conserva insieme screenshot, URL e misura. Ridurre una galleria più in basso può essere utile, ma non dimostra di aver corretto il ritardo osservato nella prima schermata.

Separare le quattro fasi dell’attesa

Il metodo di ottimizzazione di web.dev (si apre in una nuova scheda) distingue quattro contributi: attesa della prima risposta, ritardo prima di richiedere la risorsa, trasferimento della risorsa e attesa prima di mostrarla. Questa scomposizione evita di attribuire ogni problema al peso della fotografia. Per contenuti che non richiedono una risorsa aggiuntiva, alcune fasi possono essere assenti.

Fatti consegnare una breve diagnosi con la fase prevalente e una prova che la sostiene. Una risposta iniziale lenta richiede controlli su rete, server e cache; un’immagine richiesta tardi richiede di capire come viene scoperta. Se il file arriva rapidamente ma il contenuto resta invisibile, la verifica si sposta sul lavoro del browser e sulle regole di visualizzazione. Non serve applicare tutte le ottimizzazioni insieme.

Far trovare presto la risorsa che serve davvero

La risorsa principale dovrebbe essere individuabile senza aspettare operazioni secondarie. Immagini inserite soltanto da script o richiamate in fogli di stile possono richiedere verifiche specifiche. Anche il caricamento differito, utile per immagini lontane dalla prima schermata, può diventare controproducente se applicato all’immagine LCP.

Lo sviluppatore può valutare priorità e precaricamenti mirati, controllando che il browser scarichi la variante effettivamente usata. Precaricare tutte le fotografie non stabilisce una priorità: mette più risorse in competizione. Per formati, qualità e dimensioni consulta la guida alle immagini responsive del sito. Conserva un confronto visivo: ridurre il peso non dovrebbe rendere il prodotto irriconoscibile.

Controllare ciò che ritarda la comparsa del contenuto

Un file scaricato può restare in attesa mentre la pagina esegue codice, applica stili oppure aspetta la fine di un effetto introduttivo. Riproduci l’apertura osservando anche schermate di caricamento, animazioni e componenti che diventano visibili soltanto quando tutto il sito è pronto. Il contenuto necessario per capire l’offerta merita un controllo separato dagli effetti decorativi.

Se l’elemento è un titolo, verifica anche i font che ne ritardano la lettura. Se l’attesa precede qualsiasi contenuto, approfondisci la risposta iniziale del server. Chiedi una correzione circoscritta e reversibile: togliere uno script condiviso senza verificarne le dipendenze può compromettere menu, consenso o richieste commerciali.

Confrontare una modifica con la situazione iniziale

Esempio ipotetico: la foto di un servizio è già leggera, ma compare solo dopo che uno slider ha preparato tutte le immagini. La registrazione mostra che il ritardo nasce prima della richiesta del file principale. In questo caso la prima prova consiste nel rendere disponibile subito quella risorsa; comprimere ancora le altre foto risponderebbe a un problema differente.

Ripeti le misure con lo stesso dispositivo e le stesse condizioni, conservando più prove comparabili. Controlla poi titolo, ritaglio dell’immagine, menu e pulsante di contatto. Un miglioramento numerico ottenuto mostrando un’apertura incompleta non soddisfa l’obiettivo. Nel verbale del controllo scrivi che cosa è cambiato e quali percorsi sono stati riprovati.

Leggere i risultati nel tempo senza inseguire il punteggio

Le prove di laboratorio aiutano a riprodurre il difetto; i dati delle visite descrivono esperienze aggregate, quando disponibili. Per il rapporto con la ricerca, Google chiarisce che buoni Core Web Vitals (si apre in una nuova scheda) contribuiscono all’esperienza ma non garantiscono i primi risultati. Non trasformare una soglia tecnica in una promessa commerciale.

Assegna un referente alla verifica dopo nuove copertine, aggiornamenti del tema e integrazioni esterne. Mantieni un piccolo campione di pagine rappresentative, annota la data del rilascio e confronta periodi coerenti. Se mancano dati reali, documenta questo limite e continua con prove controllate, senza interpretare l’assenza del report come un risultato positivo.

Domande frequenti

Devo portare ogni test PageSpeed a 100?

Il criterio utile è rendere la pagina comprensibile e utilizzabile con tempi adeguati. Un singolo punteggio non sostituisce il confronto fra elementi, dispositivi e visite.

L’LCP lento dipende sempre dall’immagine iniziale?

No. L’elemento può essere testo o video; anche con una fotografia possono pesare soprattutto risposta iniziale, scoperta tardiva o attesa di visualizzazione.