Quanto è importante la velocità della pagina per la SEO | Standard di superamento di Google Core Web Vitals (LCP, FID, CLS)

Google ha confermato ufficialmente che i Core Web Vitals (LCP inferiore a 2,5 secondi, FID inferiore a 100 ms, CLS inferiore a 0,1) sono ormai un segnale chiave di posizionamento, e il 75% delle pagine mobili perde così l’opportunità di raggiungere la Top 3.

Googlebot interrompe la scansione se il tempo supera 1 secondo, causando un ritardo fino al 47% nell’indicizzazione dei nuovi contenuti. Quando il tempo di caricamento di una pagina passa da 1 secondo a 5 secondi, il tasso di rimbalzo aumenta del 90% (dati Adobe), e il 53% degli utenti mobili abbandona immediatamente la pagina se non si carica entro 3 secondi.

HTTP Archive mostra che l’LCP medio globale raggiunge i 2,9 secondi (62% non conforme allo standard), e ogni riduzione di 100 ms nel tempo di risposta del server aumenta il tasso di conversione dell’8,4%.

LCP (Largest Contentful Paint)

Immagina di aprire una pagina web e vedere solo uno schermo vuoto o un’icona di caricamento che gira. Se ci vogliono più di 3 secondi per vedere il contenuto principale, chiuderesti la pagina? Google ha scoperto che se il caricamento della pagina supera i 2,5 secondi, la probabilità che l’utente abbandoni la pagina aumenta del 32%. Se supera i 3 secondi, il 53% degli utenti mobili abbandona immediatamente.

Questo è LCP, che sta per Largest Contentful Paint (tempo di visualizzazione del contenuto più grande). Serve a misurare quando appare l’elemento più importante e grande della pagina, come l’immagine principale, un grande banner o un video di copertina. Non misura il tempo di caricamento completo della pagina, ma quanto velocemente appare il contenuto principale che l’utente nota per primo.

7%!

Qual è il limite accettabile per l’LCP?

Google suddivide le prestazioni LCP in tre livelli, distinti dai colori:

Eccellente (Verde): ≤ 2,5 secondi

—— Questo è lo standard target. Google richiede che almeno il 75% dei visitatori sperimenti questo tempo per considerare l’esperienza “buona”.

Da migliorare (Giallo): 2,5–4 secondi

—— Più di un quarto degli utenti percepirà la pagina come lenta, il tasso di abbandono aumenterà del 5–10% e il ranking nei motori di ricerca potrebbe calare.

Scarso (Rosso): > 4 secondi

—— L’esperienza è molto negativa, fino a metà degli utenti può abbandonare immediatamente la pagina, il tasso di conversione può essere inferiore del 20–30% e il posizionamento nei motori di ricerca diminuirà sensibilmente.

Come controllare il punteggio LCP del tuo sito web

• PageSpeed Insights (PSI): Inserisci l’URL per vedere il valore esatto di LCP, la codifica a colori e i dati degli utenti reali.

• Lighthouse: Disponibile in Chrome DevTools, permette di simulare la velocità di caricamento e fornisce il punteggio LCP (obiettivo: 90+).

• Estensione Web Vitals: Estensione per Chrome che mostra LCP, FID e CLS in tempo reale.

• Rapporto di Search Console: Riassume le prestazioni LCP di tutte le pagine del tuo sito negli ultimi 28–90 giorni e ti aiuta a identificare quali pagine necessitano di ottimizzazione.

Obiettivo molto chiaro: Mantenere LCP inferiore a 2,5 secondi e assicurarsi che almeno il 75% delle visite raggiunga questa velocità.

Problemi comuni di LCP

Ci sono molte ragioni per cui LCP può essere lento, di seguito le più comuni:

Risposta lenta del server (TTFB troppo alto)

—— Se il server risponde lentamente, il contenuto della pagina non si caricherà rapidamente. Il TTFB (Time To First Byte) dovrebbe idealmente essere inferiore a 200 ms e non superare 500 ms.

Fattori influenti:

• Prestazioni del server scarse
• Query lente al database
• Non utilizzo di CDN o CMS troppo pesante

Risorse della prima schermata troppo grandi o lente

• Immagini/Video troppo grandi: 2MB, 5MB o più, specialmente immagini grandi nella home page. Usare formati WebP o AVIF può ridurre le dimensioni del 30%-50%.

JavaScript/CSS che bloccano il rendering: JS troppo grandi o senza defer/async, e ordine di caricamento CSS non corretto possono bloccare il caricamento dei contenuti principali.

Ordine di caricamento delle risorse confuso

—— Il browser non sa quale immagine sia l’elemento LCP principale, caricando prima contenuti meno importanti. La soluzione è usare preload o fetchpriority="high" per indicare al browser quale elemento è prioritario.

Problemi con il Client-Side Rendering (CSR)

—— Nelle pagine costruite con React/Vue, se non viene eseguito il rendering lato server, l’utente vede inizialmente uno schermo vuoto finché il JS non viene eseguito. Pacchetti JS grandi (1MB+) ed esecuzione lenta possono facilmente far superare i 4 secondi al LCP.

Non utilizzo di CDN o CDN mal configurata

—— Gli utenti lontani dal server (es. utenti in Cina che accedono a un server negli USA) sperimenteranno un caricamento lento. Un CDN distribuisce le risorse più vicino all’utente, accelerando significativamente la velocità.

Troppi script di terze parti o troppo pesanti

—— Pubblicità, strumenti di analisi, tracker ecc. occupano il thread principale e ritardano il rendering della pagina. Un singolo script pubblicitario può rallentare la pagina di oltre 500 ms.

Come ottimizzare il LCP

Migliorare la velocità di risposta del server (TTFB)

Usare un CDN: Distribuisci immagini, CSS e JS tramite Cloudflare o altri CDN. Questo riduce il carico sul server e accelera la risposta. La velocità di accesso globale può aumentare del 30%-70%.

Ottimizzare le prestazioni del server: Aumenta la memoria, ottimizza il database, usa cache (Redis, Memcached) e aggiorna l’ambiente di esecuzione.

Scegliere un buon hosting: Hosting condiviso lento? Passa a VPS o hosting cloud ottimizzato. Spendere qualche euro in più al mese può rendere il LCP più veloce di 1 secondo e aumentare significativamente il tasso di conversione.

Ottimizzare immagini e video

Individuare l’elemento di contenuto più grande (LCP): Di solito è l’immagine o il video principale della prima schermata. Usa strumenti per individuarlo.

Strategie di ottimizzazione delle immagini:

• Dimensioni adeguate: Non usare immagini grandi su schermi piccoli. Usa immagini piccole su mobile e grandi su desktop.
• Formati moderni: Usa WebP o AVIF invece di JPG/PNG per ridurre notevolmente le dimensioni del file.
• Compressione: Usa strumenti come Squoosh per ridurre le immagini a poche centinaia di KB.
• Lazy loading: Per le immagini sotto la prima schermata, usa loading="lazy". Ma non applicarlo all’immagine LCP!

Regolare la priorità di caricamento delle risorse

• Precaricare le risorse critiche: Usa <link rel="preload"> per caricare in anticipo gli elementi LCP (immagini, CSS, font).
• Aumentare la priorità: Usa fetchpriority="high" per indicare al browser quali risorse sono più importanti.
• Caricare JS non essenziali in modalità asincrona: Script di annunci o analisi devono usare async o defer per non bloccare il main thread.

Ridurre il blocco del rendering

• CSS critico inline: Gli stili necessari per la prima schermata vanno inseriti direttamente nell’HTML, preferibilmente meno di 15 KB.
• Server-Side Rendering (SSR) o Static Site Generation (SSG): I progetti React/Vue con Next.js o Nuxt.js generano HTML già con contenuti lato server, riducendo il LCP da 4–6 secondi a 1–2 secondi.

Gestire gli script di terze parti

• Snellire e controllare: Usa strumenti per identificare script lenti (caricamento >500ms o esecuzione >300ms). Rimuovi se possibile, altrimenti sostituisci con versioni più leggere.
• Caricamento ritardato: Gli script non essenziali devono essere eseguiti dopo il caricamento completo della pagina (ad esempio dopo window.onload).
• Isolamento sandbox: Usa iframe per isolare script ad alto rischio e non compromettere le prestazioni della pagina principale.

FID (First Input Delay – Ritardo della prima interazione)

Quando un utente clicca per la prima volta su un pulsante in una pagina web (ad esempio “Acquista ora” o “Apri menu”), se la pagina impiega più di 300 ms per rispondere, il 76 % degli utenti percepisce la pagina come lenta.

Questo tempo di attesa è chiamato FID (Ritardo della prima interazione). Misura il tempo tra la prima interazione dell’utente e l’inizio della risposta del browser.

Il FID non misura quanto tempo impiega a eseguire l’intero script, ma si concentra solo su se il “thread principale” del browser è occupato da altre attività, impedendo una risposta immediata all’azione dell’utente.

Perché la pagina sembra lenta?

Perché il browser può eseguire un solo compito alla volta (ha un solo thread principale). Quando si clicca sulla pagina, se il thread principale sta eseguendo un altro compito, ad esempio caricando un grande script pubblicitario, il clic dovrà attendere che il compito sia completato.

I dati mobili di Google del 2023 mostrano:

• Se il FID supera i 300 ms, il tasso di conversione diminuisce del 22 %

• Ogni 100 ms di ritardo aggiuntivo aumentano le probabilità che l’utente abbandoni la pagina del 8 %

• Nelle pagine di checkout e-commerce, se il FID supera i 250 ms, il tasso di abbandono del carrello aumenta del 18 %

📌 Il FID misura il tempo reale tra il primo clic, tocco o digitazione dell’utente e la risposta del browser. I test simulati non possono replicarlo completamente; l’analisi deve basarsi sui dati degli utenti reali (RUM).

Quanti millisecondi sono considerati “fluido”?

I Core Web Vitals di Google stabiliscono gli standard di FID basati sui dati reali degli utenti degli ultimi 28 giorni:

Soglia di superamento:
Almeno il 75% delle visite devono avvenire in 100ms, soprattutto su dispositivi mobili.

Strumenti consigliati:

• Chrome User Experience Report (CrUX): Vedere la distribuzione dei dati FID dell’intero dominio

• PageSpeed Insights: Combina dati simulati e reali

• Search Console: Controllare la percentuale di pagine conformi

Perché i clic non rispondono?

🔸 Attività lunghe occupano il thread principale

Qualsiasi script JS che impiega più di 50ms è considerato un “lunga attività”.
Ad esempio, caricare uno script pubblicitario non ottimizzato può bloccare il thread principale per più di 400ms, durante i quali i clic degli utenti vengono completamente ignorati.

🔸 File JS troppo grandi

Caricare file JS superiori a 500KB, specialmente su dispositivi mobili di fascia bassa, può richiedere 800ms solo per l’analisi.
Questo è particolarmente evidente con framework come React o Vue, specialmente durante la fase di hydration al caricamento iniziale della pagina.

🔸 Troppi script di terze parti

In media, una pagina carica più di 22 risorse di terze parti.
Ad esempio, i plugin dei social media sui dispositivi mobili di fascia bassa possono variare notevolmente, con tempi di esecuzione da 200ms a 800ms.

🔸 Carico CPU troppo elevato

Ad esempio, su uno smartphone di fascia media (Snapdragon 6 series), se il thread principale è occupato per più del 80%, i clic degli utenti verranno messi in coda, con tempi di attesa da 150ms a 1200ms.

💡 Strumento consigliato:

Usa il pannello Performance di Chrome DevTools per visualizzare le lunghe attività e il grafico a cascata del thread principale.

Come rendere le interazioni più fluide?

✅ Metodo 1: Suddividere le attività lunghe

In precedenza, un’attività richiedeva 120ms per essere eseguita, impedendo al browser di gestire le azioni dell’utente.

// Dopo la suddivisione, limitare ogni elaborazione a massimo 30ms
function chunkedProcess() {
let index = 0;
function doChunk() {
const start = Date.now();
while (index < data.length && Date.now() – start < 30) {
processItem(data[index++]);
}
if (index < data.length) {
setTimeout(doChunk, 0); // liberare il thread principale
}
}
doChunk();
}

Risultato: Un’attività che originariamente richiedeva 250ms è stata compressa a un massimo di 32ms, e il FID è diminuito del 85%

✅ Metodo 2: Ottimizzare la priorità di caricamento del JS

Inserire il codice JS critico direttamente nell’HTML (meno di 15KB)

Caricare in ritardo gli script JS non critici

<!– Caricare successivamente gli script non necessari per la prima schermata –>
<script defer src=”non-critical.js”></script>

<!– Inserire script pubblicitari o di analisi dopo il caricamento della pagina –>
<script>
window.addEventListener(‘load’, () => {
const script = document.createElement(‘script’);
script.src = “ads.js”;
document.body.appendChild(script);
});
</script>

Risultato: Il carico sul thread principale è diminuito del 40%~70%

✅ Metodo 3: Eseguire il codice di terze parti “isolato”

Usare un iframe sandbox:<iframe sandbox=”allow-scripts” src=”third-party-ad.html”></iframe>

In questo modo, il codice di terze parti non interferisce con il thread principale.

• Usare Web Worker per attività pesanti

// Thread principale
const worker = new Worker(‘crypto-worker.js’);
worker.postMessage(data);

// Il worker elabora le attività pesanti
self.onmessage = (e) => {
const result = heavyCryptoWork(e.data);
self.postMessage(result);
};

Risultato: Ad esempio, un’attività di crittografia riduce il tempo sul thread principale da 300ms a 20ms

CLS (Cumulative Layout Shift)

Ti è mai capitato di aprire una pagina web e che il contenuto si muovesse improvvisamente, facendoti cliccare il pulsante sbagliato? Questo è un problema di CLS.

CLS significa Cumulative Layout Shift (spostamento cumulativo del layout) e misura la stabilità visiva di una pagina durante il caricamento. Il punteggio varia da 0 a 1, più basso è il punteggio, più stabile è la pagina; più alto è, più frequenti sono gli spostamenti. Google consiglia: un punteggio CLS inferiore a 0,1 è ideale, inferiore a 0,05 eccellente, e superiore a 0,25 deve essere ottimizzato immediatamente.

Perché il CLS merita attenzione? Perché influisce direttamente sull’esperienza dell’utente e può persino causare perdite di ricavi. Ad esempio:

• Quando il CLS supera 0,2, il tasso di rimbalzo aumenta in media del 25% e il tasso di conversione diminuisce del 18%;

• Se il caricamento della pagina subisce un ritardo di soli 100 millisecondi, il rischio di CLS aumenta del 15%;

• Le immagini senza dimensioni predefinite rappresentano il 65% degli eventi che causano CLS;

• Se il CLS può essere ridotto sotto 0,05, il tasso di ritenzione degli utenti può aumentare del 20% e il tempo medio di sessione aumentare di 30 secondi.

Soglie CLS

Google ha definito soglie chiare per il CLS: inferiore a 0,1 = accettabile, inferiore a 0,05 = eccellente, superiore a 0,25 = avviso. E il 90% dei siti web a livello globale imposta l’obiettivo sotto 0,1, per una buona ragione.

I dati mostrano: le pagine con CLS < 0,1 hanno un tasso di abbandono medio del 5%; mentre le pagine con CLS > 0,25 possono arrivare fino al 30%. Soprattutto per siti e-commerce e di notizie, la mediana del CLS deve essere sotto 0,08, e la deviazione standard non deve superare 0,02, altrimenti influenzerà ranking e traffico.

I problemi di caricamento ritardato non possono essere ignorati. Se gli elementi della pagina vengono caricati con 0,3 secondi di ritardo, il punteggio CLS aumenta di circa 0,05; se gli annunci non hanno dimensioni specificate (ad esempio 400px × 200px), il CLS può salire a 0,15.

Dal punto di vista economico, un CLS conforme può aumentare stabilmente il tasso di conversione del 10% e il ROI dell’8%. Statisticamente, il 65% dei siti ha un CLS medio di 0,12, ma è importante notare che la mediana per essere considerata accettabile è 0,07, e le pagine con picchi superiori a 0,4 richiedono in media 3 giorni per essere corrette, con un costo di circa 500 USD.

Inoltre, la precisione del CLS deve considerare le differenze tra dispositivi e la complessità della pagina. Quando la pagina ha più di 100 elementi, la tolleranza CLS deve rimanere entro ±0,02 e la precisione raggiungere il 95%. Altrimenti, il tasso di abbandono può aumentare del 25% e il profitto diminuire del 10%.

Problemi comuni di CLS

La prima categoria è caricamento di contenuti dinamici. Ad esempio, annunci o popup, se non hanno dimensioni fisse, possono spingere altri elementi della pagina durante il caricamento. In questi casi, il punteggio di spostamento varia tra 0,1 e 0,15 e rappresenta fino al 60%, e ogni volta può comportare una perdita del 5% delle interazioni degli utenti.

La seconda categoria è ritardo degli script di terze parti. Molti siti caricano script esterni per assistenza clienti online o analisi dei dati, causando un ritardo di 200 ms e aumentando il CLS di 0,05. Il 75% dei siti web vede peggiorare l’esperienza utente a causa di ciò. Ad esempio, uno script di e-commerce che utilizza 10 Mbps di larghezza di banda rallenta il caricamento della pagina a 4 secondi, il CLS sale a 0,25 e il tasso di rimbalzo aumenta del 20%.

La terza categoria è immagini/video senza dimensioni definite. Contenuti di 800px × 600px senza dimensioni definite possono facilmente spingere i componenti circostanti durante il caricamento, rappresentando il 45% degli eventi di spostamento, con variazioni CLS ±20%. In un campione di 50 pagine, il tasso di deviazione superava il 70%, e il costo per la correzione era di circa 200 USD per volta.

Successivamente, abbiamo la sovrapposizione degli elementi. Se più div alti 100px sono disposti densamente, il carico della pagina aumenta del 50% e il rischio di CLS sale del 30%.

Ci sono anche fattori temporali: se il caricamento delle risorse supera i 500 ms, ogni 10 richieste aggiuntive aumentano il CLS di 0,03; se un annuncio si aggiorna automaticamente ogni 30 secondi, il picco CLS può raggiungere 0,35.

Se questi problemi non vengono risolti tempestivamente, si potrebbero perdere dal 5 al 10% delle entrate mensili, e il CLS potrebbe peggiorare del 2% a settimana.

Come migliorare efficacemente il CLS

Passo 1: Inizia dalle basi: “definire le dimensioni”. Tutte le immagini, gli annunci e i componenti video devono avere larghezza e altezza predefinite (ad esempio 400px × 250px), riducendo del 40% i problemi di spostamento. L’uso della proprietà CSS max-width: 100% migliora la responsività e accelera il caricamento di circa 0,2 secondi, riducendo il rischio CLS del 35%.

Passo 2: Ottimizzare il caricamento delle risorse. Comprimere le immagini a meno di 500KB riduce il 70% della frequenza di attivazione e diminuisce il CLS di 0,1; allo stesso tempo, mantenere dimensioni di font, video e altre risorse sotto i 10MB e tempi di caricamento inferiori a 100 ms riduce la probabilità di spostamento del 30%.

Passo 3: Gestire gli script di terze parti. Si consiglia di utilizzare caricamento asincrono o differito, ad esempio posticipando di 500 ms il caricamento degli strumenti esterni. Ciò ottimizza la frequenza di attivazione, riduce il CLS mediano a 0,05 e aumenta il tasso di conversione del 10%.

Anche il contenuto dinamico deve essere inserito “dolcemente”. È possibile aggiungere una transizione animata di 50 ms o riservare il 20% dello spazio di buffer, riducendo l’errore CLS a ±0,01 e garantendo un caricamento fluido.

Passo 4: Utilizzare strumenti di test appropriati. Si consiglia Lighthouse e Chrome DevTools con precisione fino al 95%. Monitorare per una settimana e fare un’analisi di regressione aiuta a identificare i principali obiettivi di ottimizzazione.

Costo: il costo medio per correggere il CLS è di circa 50 USD per intervento, e il ciclo di ottimizzazione richiede solo 1 giorno. I benefici sono significativi: la retention degli utenti aumenta del 15%, la vita utile del sito aumenta di 2 anni, il CLS mediano scende da 0,15 a 0,06, la variazione si dimezza e i ricavi finali aumentano del 5%.

Usa PageSpeed Insights per controllare il tuo sito ora — in soli 30 minuti troverai i punti di ottimizzazione più importanti!