Web e SEO
Sito lento e Core Web Vitals: cosa incide davvero sul posizionamento
La velocità di un sito viene discussa quasi sempre con gli argomenti sbagliati: punteggi da esibire, soglie ripetute a memoria, interventi fatti perché li fanno tutti. Qui separiamo ciò che incide davvero sul posizionamento da ciò che viene ripetuto senza fondamento, e spieghiamo cosa peggiora LCP, INP e CLS nella pratica di tutti i giorni.
La velocità del sito web incide sulla SEO, ma non come viene raccontata
I Core Web Vitals sono un segnale di ranking dichiarato da Google. Questo è vero e non serve discuterlo. Il problema è cosa significa «segnale» in pratica. La velocità non decide quale pagina merita la prima posizione: interviene a parità di pertinenza, quando due risultati rispondono altrettanto bene alla stessa domanda. Un sito rapidissimo che non risponde resta dietro a un sito più lento che risponde meglio. Funziona come rifinitura dentro un gruppo di risultati già pertinenti.
Il guadagno vero sta a valle del posizionamento. Un sito lento perde persone prima che il contenuto venga letto: chi arriva da mobile su una connessione mediocre chiude e torna ai risultati. Quel comportamento resta fuori dai fattori di ranking diretti, però il traffico che se ne va non converte comunque. Chi vende, prenota o fa iscrivere qualcuno se ne accorge nel fatturato molto prima che nella posizione media.
C'è poi un effetto meno visibile e più concreto: la scansione. Un server che risponde lentamente riduce la quantità di pagine che il crawler scarica nello stesso intervallo. Su un sito di venti pagine non cambia nulla. Su un catalogo con migliaia di URL, o su una directory che cresce nel tempo, la lentezza del server diventa un limite alla velocità con cui i contenuti nuovi entrano nell'indice.
Il criterio che usiamo quando ci arriva la richiesta «il sito è lento, sistematelo» è sempre lo stesso. Prima verifichiamo se la pagina risponde davvero alla domanda per cui vorrebbe posizionarsi. Poi la rendiamo veloce. Invertire l'ordine produce siti impeccabili nei punteggi e invisibili nei risultati.
LCP, INP e CLS: cosa misurano davvero i Core Web Vitals e cosa li peggiora
Ognuna delle tre metriche descrive un'esperienza diversa, con cause di degrado proprie, invece di riassumere quanto è veloce il sito. Trattarle come un unico numero porta a interventi sbagliati.
LCP, quando compare l'elemento per cui l'utente è arrivato
Il Largest Contentful Paint registra il momento in cui viene dipinto l'elemento visibile più grande nella prima schermata: di solito l'immagine principale o il blocco di testo del titolo. Peggiora per motivi molto banali. Un'immagine di intestazione servita a piena risoluzione da fotocamera. Il lazy loading applicato anche alla prima immagine, che così viene richiesta in ritardo. Un foglio di stile o un font che bloccano la costruzione della pagina. Una catena di redirect fra dominio con e senza www, http e https. E soprattutto il caso in cui il testo esiste solo dopo l'esecuzione del JavaScript.
INP, quanto tempo passa fra il tocco e la risposta visibile
L'Interaction to Next Paint misura il ritardo fra un'interazione dell'utente e il frame successivo effettivamente disegnato. È la metrica che cattura la sensazione di pagina impastata. Peggiora quando il thread principale è occupato da attività lunghe: idratazione di componenti pesanti, gestori di eventi che ricalcolano mezzo albero, script di terze parti che si svegliano al primo clic. I banner di consenso, i tag manager, le chat di supporto e gli strumenti di registrazione sessione sono i colpevoli più ricorrenti, perché arrivano dopo e nessuno li considera parte del sito.
CLS, quanto la pagina si sposta mentre viene letta
Il Cumulative Layout Shift somma gli spostamenti inattesi degli elementi già visibili. Ha conseguenze pratiche immediate: produce clic sbagliati, pulsanti premuti per errore, righe di testo perse a metà lettura. Le cause tipiche sono immagini e iframe senza dimensioni dichiarate, banner iniettati sopra il contenuto invece che sotto, blocchi di altezza variabile riempiti dopo una chiamata di rete, e font personalizzati con metriche molto diverse dal fallback, che al momento della sostituzione rimescolano il testo.
TTFB, il numero che sta sotto agli altri tre
Il Time To First Byte resta fuori dall'elenco dei Core Web Vitals e li condiziona tutti. Se il server impiega troppo a rispondere, ogni ottimizzazione a valle parte già in ritardo e il tetto massimo dell'LCP è fissato lì. Hosting condiviso sovraccarico, query non indicizzate, pagine ricostruite a ogni richiesta senza alcuna cache: prima di comprimere immagini conviene guardare quanto tempo passa prima che arrivi il primo byte.
Sito lento, cosa fare quando il contenuto arriva solo dopo il JavaScript
Nei siti costruiti come applicazione a pagina singola la causa dominante è quasi sempre la stessa. Il server restituisce un documento HTML sostanzialmente vuoto, con un contenitore e un riferimento al bundle. Il browser deve scaricare quel bundle, analizzarlo, eseguirlo, montare l'applicazione, capire quale rotta è stata richiesta, fare una o più chiamate all'API e solo allora disegnare il testo. L'LCP finisce in fondo a questa catena. Ogni anello aggiunge attesa e ogni anello è fragile.
Sui dispositivi di fascia alta la differenza si nota poco, e questo spiega perché molti problemi non vengono mai visti da chi sviluppa. Su un telefono di fascia media, in rete mobile, il costo di analisi ed esecuzione del JavaScript cresce parecchio, perché dipende dalla CPU e non solo dalla banda. La pagina arriva presto e resta bianca a lungo.
C'è anche il lato indicizzazione. Googlebot esegue il JavaScript, ma in una seconda passata, accodata e non garantita nei tempi. Gli altri consumatori del sito spesso non lo eseguono affatto: i generatori di anteprime dei social e diversi crawler prendono l'HTML così com'è. Se titolo, descrizione e contenuto vivono solo nel risultato del rendering, quello che il resto del mondo vede è una pagina senza contenuto. La questione esce dal perimetro della velocità in senso stretto, però nasce dalla stessa scelta architetturale.
Prerendering SEO e generazione statica: servire HTML già pronto
Il rimedio consiste nello spostare il momento in cui l'HTML viene prodotto, mantenendo React nello stack. Con la generazione statica le pagine vengono costruite in fase di build e servite come file già completi. Con il rendering lato server vengono costruite a ogni richiesta. Con il prerendering un passo successivo alla build visita le rotte pubbliche con un browser headless e salva lo snapshot HTML risultante. In tutti e tre i casi il browser riceve testo leggibile subito, e il JavaScript arriva dopo per rendere la pagina interattiva.
Il sito di DietApp lo abbiamo costruito così: React con Vite, react-helmet-async per i metadati e un passaggio di prerendering statico che produce per ogni rotta pubblica uno snapshot HTML completo, JSON-LD incluso. La scelta ha una logica precisa. Le pagine pubbliche, come la presentazione del prodotto o le informative, contengono materiale stabile e uguale per tutti: fissarle in un file ha senso e costa poco. L'area riservata resta invece completamente lato client, perché dipende dall'utente autenticato, cambia a ogni sessione e non deve finire nell'indice.
Il criterio è quello, e vale al di là dello stack. Prerendering e generazione statica per ciò che è pubblico e stabile. Rendering lato client per ciò che è personale, protetto o volatile. Rendering lato server quando il contenuto è pubblico ma cambia troppo spesso per aspettare una build. Il caso che confonde è il terzo, ed è quello dove serve valutare davvero quanto cambia il dato e quanto costa ricostruire la pagina.
Ottimizzare la velocità del sito: gli interventi in ordine di resa
L'ordine che segue riflette il rapporto fra risultato ottenuto e fatica richiesta. I primi due punti risolvono la maggior parte dei casi reali.
Immagini nel formato e nella dimensione giusti
Il singolo intervento con la resa migliore. Formati moderni come WebP o AVIF al posto di JPEG e PNG. Dimensioni reali coerenti con lo spazio occupato, invece di file enormi rimpiccioliti dal CSS. Attributi srcset e sizes per servire varianti diverse a schermi diversi. Larghezza e altezza dichiarate, oppure un aspect-ratio, per non generare spostamenti. Lazy loading su tutto tranne l'immagine principale, che va invece caricata con priorità alta: metterla in lazy è uno degli errori più comuni e peggiora direttamente l'LCP.
Caratteri tipografici sotto controllo
Font ospitati sul proprio dominio in formato woff2, con il sottoinsieme di caratteri effettivamente usato. Numero di pesi e stili ridotto al minimo davvero necessario. Preload riservato al solo font che compare nella prima schermata. Una strategia di visualizzazione che mostri subito il testo con il fallback invece di lasciarlo invisibile. E un fallback scelto con metriche simili, perché la sostituzione a caldo fra due font molto diversi è una fonte silenziosa di layout shift.
JavaScript che non serve
Il codice più veloce è quello che non viene scaricato. Vale per le librerie usate per una funzione sola e vale soprattutto per gli script di terze parti, che spesso pesano più dell'applicazione stessa. Suddivisione del bundle per rotta, caricamento differito di tutto ciò che non serve alla prima schermata, e verifica onesta di quali strumenti di misurazione siano ancora usati da qualcuno. In Beachfy abbiamo suddiviso il bundle per rotta e abbiamo scritto il generatore di QR code direttamente in SVG, senza libreria: una dipendenza in meno da scaricare a ogni visita.
Richieste bloccanti nel percorso critico
Tutto ciò che il browser deve risolvere prima di poter disegnare va ridotto. CSS essenziale servito subito e il resto rimandato, evitando catene di @import che si scoprono una dopo l'altra. Preconnect solo verso i domini realmente coinvolti nella prima schermata, perché aprirne troppi è controproducente. Redirect eliminati dove possibile. E un banner di consenso che non tenga in ostaggio il rendering del contenuto sottostante.
Cache e distribuzione dei contenuti
Header di cache espliciti, con nomi file versionati per gli asset così da poterli marcare come immutabili. Compressione attiva. Una CDN che avvicini i file all'utente e assorba i picchi. Attenzione però al perimetro: la CDN accorcia il trasporto, mentre un thread principale intasato o una query lenta restano dove sono. Se il problema è l'INP, la CDN non lo tocca.
Quello che conta più della velocità: contenuto, gerarchia, dati strutturati, link interni
La corrispondenza con l'intento di ricerca resta il fattore che sposta di più. Una pagina deve rispondere a una domanda precisa e farlo per intero, senza costringere a cercare altrove il pezzo mancante. Il problema ricorrente sta nell'architettura: i testi possono essere curati, eppure tre pagine che inseguono la stessa query si tolgono forza a vicenda, e nessuna delle tre arriva dove arriverebbe una pagina sola fatta bene.
La gerarchia dei titoli descrive il ragionamento della pagina, e va costruita con quel criterio prima ancora che con criteri grafici. Un H1 che dichiara l'argomento, H2 che corrispondono alle domande reali dentro quell'argomento, nessun salto di livello per ottenere un carattere più piccolo. Chi legge in diagonale usa quella struttura per orientarsi, e i motori la usano per capire cosa contiene ogni sezione.
I dati strutturati aiutano solo se descrivono ciò che si vede davvero nella pagina. Su Beachfy abbiamo rimosso un blocco JSON-LD di recensioni che non corrispondeva a recensioni reali: markup di quel tipo espone a un rischio concreto, e conviene toglierlo prima che sia qualcun altro a notarlo. Il markup utile è quello coerente e verificabile: articolo, prodotto, FAQ, sede fisica, breadcrumb.
I link interni sono la parte più trascurata e la meno costosa. Una pagina raggiungibile solo dalla sitemap è una pagina orfana. Un anchor text generico spreca l'unico segnale che quel collegamento poteva trasmettere. Attenzione anche all'architettura a sottodomini: in BarbierItalia ogni salone abbonato riceve il proprio sito su un sottodominio dedicato, e un sottodominio va trattato come un sito a sé, con la sua sitemap e i suoi collegamenti. Nulla arriva in automatico dal dominio principale.
Miti sulla velocità del sito e posizionamento: come stanno le cose
Le affermazioni che ricorrono più spesso nelle discussioni sulla velocità, messe accanto a quello che si può effettivamente sostenere.
| Si sente dire | Come stanno le cose |
|---|---|
| Se il sito è veloce sale in classifica | La velocità interviene fra pagine di pertinenza confrontabile. Non compensa un contenuto che non risponde alla domanda. |
| Serve il punteggio massimo su PageSpeed Insights | Quel punteggio è una simulazione di laboratorio su una configurazione fissa. Search Console valuta i dati raccolti dagli utenti reali, che possono raccontare tutt'altro. |
| Il lazy loading va messo su tutte le immagini | Applicarlo all'immagine principale della prima schermata ne ritarda la richiesta e peggiora l'LCP. Va escluso proprio da quella. |
| Il CLS è un problema estetico | È un problema di usabilità: produce clic sul bersaglio sbagliato e perdita del punto di lettura, soprattutto da mobile. |
| Le applicazioni a pagina singola non vengono indicizzate | Vengono indicizzate, ma il rendering avviene in una passata differita e non garantita nei tempi. Altri crawler leggono solo l'HTML iniziale. |
| Basta attivare una CDN | La CDN riduce il tempo di trasporto. Un thread principale bloccato, una query lenta o un bundle sovradimensionato restano da sistemare a parte. |
| AMP serve per posizionarsi | Non è più un requisito per comparire nei formati di ricerca che una volta lo richiedevano. |
Misurare la velocità senza illudersi: dati di laboratorio e dati di campo
I dati di laboratorio nascono da una prova sintetica: dispositivo simulato, rete simulata, condizioni identiche a ogni esecuzione. Lighthouse, WebPageTest e il pannello prestazioni del browser stanno qui. Sono lo strumento giusto per diagnosticare, perché isolano la causa e permettono di confrontare due versioni dello stesso codice. Non descrivono però il pubblico reale, che usa dispositivi e reti che nessuna simulazione riproduce fedelmente.
I dati di campo arrivano dai visitatori veri, aggregati nel rapporto CrUX e mostrati in Search Console, oppure raccolti direttamente con la libreria web-vitals. Sono la base su cui viene giudicata l'esperienza della pagina. Hanno due caratteristiche da tenere presenti: sono aggregati su una finestra mobile, quindi un miglioramento pubblicato oggi impiega settimane a manifestarsi, e richiedono traffico sufficiente per essere disponibili. L'INP in particolare esiste solo qui, perché nasce da interazioni umane; il laboratorio può darne al massimo un indizio indiretto attraverso il tempo di blocco del thread principale.
Due abitudini pratiche che seguiamo sempre. Misurare per tipo di pagina e non solo la home, perché il modello di scheda prodotto o di articolo è quello che riceve il traffico organico. E separare sempre mobile e desktop, dato che i problemi seri quasi sempre stanno da un lato solo e la media dei due li nasconde entrambi.
Domande frequenti su velocità del sito e posizionamento
Sì, ed è dichiarato. Va però pesato per quello che è: un segnale che agisce fra risultati di pertinenza simile. Migliorare la velocità di una pagina che non risponde alla domanda dell'utente non la fa salire. Migliorarla su una pagina già pertinente può fare la differenza rispetto a un concorrente equivalente, e in ogni caso riduce gli abbandoni.
Il tempo di risposta del server e l'immagine principale della prima schermata. Se il primo byte arriva tardi, il problema è a monte e nessuna ottimizzazione del front-end lo aggira. Se il primo byte arriva presto ma la pagina resta bianca, si guarda cosa blocca il rendering: quasi sempre un'immagine sovradimensionata, un font bloccante o il fatto che il contenuto esista solo dopo l'esecuzione del JavaScript.
Serve soprattutto in quel caso. Non richiede una riscrittura: un passo aggiuntivo dopo la build visita le rotte pubbliche e ne salva l'HTML risultante, che viene poi servito direttamente. È l'impostazione che abbiamo usato sul sito di DietApp, dove le pagine pubbliche sono snapshot statici e l'area riservata resta lato client. Se invece il contenuto pubblico cambia di continuo, ha più senso il rendering lato server.
I dati di campo sono aggregati su una finestra mobile, quindi la variazione compare gradualmente e non il giorno dopo la pubblicazione. Nel frattempo conviene verificare l'effetto con misurazioni proprie sugli utenti reali, che rispondono subito. Dichiarare vittoria basandosi solo su una prova di laboratorio eseguita dal proprio portatile in fibra è il modo più rapido per sbagliare valutazione.
Sui contenuti, salvo che il sito sia lento in modo evidente anche a occhio nudo. Una pagina che risponde meglio della concorrenza si posiziona anche se non è la più rapida. Una pagina veloce che risponde peggio non recupera. L'ordine che seguiamo è: verificare la corrispondenza con l'intento, sistemare struttura e collegamenti interni, poi lavorare sulle prestazioni.