Un sito lento non è un difetto di finitura. È il prodotto che l'utente sta usando. LCP, INP e CLS: cosa misurare sul campo prima di comprare RAM, plugin o una CDN.
Un sito lento non è un difetto di finitura. È il prodotto che l'utente sta usando, nel momento in cui decide se restare o andarsene. Prima di parlare di CDN, cache o "un po' di RAM in più", conviene misurare tre cose: quanto impiega a comparire il contenuto principale, quanto è reattivo al clic, quanto salta il layout mentre si legge.
In breve: Google chiama queste tre misure Core Web Vitals. Per un'esperienza considerata buona, al 75° percentile delle visite, servono un LCP entro 2,5 secondi, un INP entro 200 millisecondi e un CLS entro 0,1. Il resto, plugin, hosting, framework, viene dopo.
Cosa trovi in questo articolo
Il problema reale non è il punteggio PageSpeed
Chi gestisce un sito finisce spesso a inseguire un numero verde su PageSpeed Insights. È comprensibile: è visibile, si può mandare in una chat, dà l'impressione di aver "fatto la performance". Il limite è che quel numero nasce da un test in laboratorio, su un dispositivo e una rete simulati. L'utente vero arriva da un telefono mediocre, su 4G instabile, con la cache vuota e dieci schede aperte.
Il prodotto, per lui, è il tempo che passa tra il tap e la pagina che risponde. Se l'hero image arriva dopo tre secondi, se il bottone "Acquista" non fa nulla per mezzo secondo, se il testo gli scappa sotto il dito mentre carica un banner, il sito sta dicendo una cosa precisa: questo pezzo non è finito. Non è un tema estetico. È una funzione mancante.
Google lo tratta in questi termini. I Core Web Vitals fanno parte della page experience usata in Search, insieme ad altri segnali. Non sostituiscono contenuti pertinenti e non "regalano" da soli una prima pagina. Restano però il modo più onesto, e ripetibile, per dire se il sito è usabile sul campo. Su Roxxo la performance sta nel cluster Performance: qui si parte dalle metriche, non dalle offerte.
Cosa misurare: LCP, INP, CLS
Le tre metriche non sono un elenco da spuntare. Coprono tre momenti diversi della visita. Vale la pena tenerle distinte, perché si aggiustano in modi diversi.
LCP: quando il contenuto principale diventa visibile
Il Largest Contentful Paint misura quanto tempo passa, dall'inizio del caricamento, prima che l'elemento più grande nel viewport sia dipinto. Di solito è un'immagine hero, un video, un blocco di testo in evidenza. Per un'esperienza buona deve avvenire entro 2,5 secondi. Oltre i 4 secondi si parla di esperienza scarsa. Il riferimento è sempre il 75° percentile delle visite, mobile e desktop separati.
Se l'LCP è alto, il colpevole raramente è "il server in sé". Più spesso è una combinazione: HTML che arriva tardi, CSS che blocca il rendering, un'immagine troppo pesante senza dimensioni dichiarate, un font che nasconde il testo, JavaScript che ruba il thread principale prima che la pagina possa dipingere. Prima misura quale elemento è l'LCP. Poi decidi. Senza quel dato si finisce a ottimizzare il footer.
INP: la pagina risponde al clic, o fa finta?
L'Interaction to Next Paint misura la reattività. Dal 12 marzo 2024 ha sostituito il First Input Delay come Core Web Vital: il FID guardava solo il ritardo del primo input, l'INP guarda le interazioni lungo tutta la vita della pagina. Un valore entro 200 millisecondi è buono. Tra 200 e 500 millisecondi l'esperienza ha bisogno di lavoro. Sopra i 500 è scarsa.
In pratica: l'utente preme, e il browser deve arrivare al frame successivo in cui si vede un cambiamento. Se in mezzo c'è un task JavaScript lungo, un listener pesante, una libreria che ricalcola mezzo DOM a ogni keyup, l'INP sale. Non si sistema con una CDN. Si sistema togliendo lavoro dal thread principale, spezzando i task lunghi, rinviando ciò che non serve al primo gesto.
CLS: il layout che salta mentre stai leggendo
Il Cumulative Layout Shift misura quanto il contenuto si sposta in modo inatteso. Soglia buona: 0,1 o meno. Oltre 0,25 l'esperienza è scarsa. Le cause sono noiose e sempre le stesse: immagini e embed senza width e height, web font che sostituiscono il fallback in ritardo, banner che si iniettano sopra l'articolo, cookie wall che spingono giù la pagina dopo il primo paint.
Il CLS non "fa lento" il sito. Lo rende infido. È il tipo di difetto che l'utente non sa nominare, ma ricorda. E in un form, in un checkout, in un articolo lungo, costa clic sbagliati.
Laboratorio e campo non raccontano la stessa storia
PageSpeed Insights, Lighthouse e i test in locale servono. Mostrano cosa succede in condizioni controllate e danno una lista di cause possibili. Non dicono, da soli, cosa vive l'utente.
I Core Web Vitals che contano per Search arrivano dai dati di campo, il Chrome User Experience Report. Search Console li aggrega per URL e per origine. PageSpeed Insights, quando i dati bastano, mostra entrambi i lati: laboratorio in basso, campo in alto. Se i due discordano, si crede al campo. Un sito può prendere 90 in laboratorio e fallire LCP sul mobile reale, perché l'hero è una JPEG da 2 MB servita a 400 kbps.
La soglia da usare è il 75° percentile, non la media e non il best case del tuo Mac. web.dev lo dice senza giri di parole: si mira a coprire la maggioranza delle visite, non il test più lusinghiero. Se misuri solo in ufficio, stai progettando per te stesso.
Chi vuole una panoramica più tecnica di cosa succede nel browser può partire dal glossario MDN sui Core Web Vitals. Non sostituisce i dati di campo. Aiuta a non confondere una metrica con un'altra.
Cosa controllare prima di aggiungere risorse
Quando un sito è lento, la tentazione è comprare potenza: piano hosting superiore, CDN, un plugin "optimizer", più RAM al database. A volte serve. Spesso è un modo per non aprire DevTools. L'ordine più onesto è un altro.
Identifica l'elemento LCP. In Chrome, Performance o l'overlay Web Vitals. Se è un'immagine, pesa, formato, dimensioni, priorità di fetch. Se è un testo, guarda CSS e font. Non si ottimizza "la home": si ottimizza quell'elemento.
Guarda la catena critica. TTFB alto? Allora sì, c'è un discorso di origine, di cache, di applicazione. TTFB accettabile e LCP alto? Il problema è sul client: risorse che bloccano, immagini, JS.
Pesare JavaScript. Byte scaricati, tempo di parse, task lunghi. L'INP nasce quasi sempre qui. Un carosello, un tag manager gonfio, un A/B test che riscrive il DOM: sono costi di prodotto, non "dettagli di front-end".
Riservare lo spazio. width e height sulle immagini, aspect-ratio, slot per gli ad. Il CLS si previene, non si "mitiga" a posteriori con animazioni.
Poi, e solo poi, l'infrastruttura. Cache HTTP, CDN, HTTP/2 o HTTP/3, un'origine più vicina. Hanno senso quando hai già tolto il lavoro inutile. Altrimenti stai distribuendo più in fretta un payload che non doveva esistere. Il cluster Infrastruttura serve proprio a questo passaggio successivo: DNS, hosting, rete. Non al primo.
La formula è secca, e vale la pena ripeterla: prima misura, poi decidi. Un upgrade di piano senza una misura di campo è una spesa, non una strategia.
Ha senso quando. Non serve quando
Ha senso trattare la performance come requisito di prodotto quando il sito è il canale: ecommerce, lead, app web, contenuti che si leggono sul telefono. In quei casi LCP, INP e CLS non sono "SEO tecnica". Sono il tempo di risposta del negozio. Vanno in backlog con priorità, con un owner, con una soglia. Non in un ticket aperto tre giorni prima del lancio.
Non serve ossessionarsi quando il traffico è interno, il pubblico è su desktop cablato e la pagina è un documento raro. Anche lì le tre metriche restano un buon igiene. Ma inseguire il 100 di Lighthouse su una pagina che nessuno usa è teatro. Il compromesso onesto è: le pagine che portano soldi o decisioni passano al 75° percentile. Le altre non devono diventare un progetto eterno.
Il punto in cui molti team sbagliano è delegare la performance all'ultimo fornitore della catena, "quello dell'hosting" o "quello dei plugin". L'hosting può togliere millisecondi di TTFB. Non può decidere il peso dell'hero, il numero di tag nel GTM, il font che carica quattro pesi per un titolo. Quella è progettazione. Se la si tratta come un extra, il prodotto arriva già lento.
Errori da evitare
Inseguire il punteggio e ignorare il campo. Un 95 in laboratorio con LCP mobile oltre i 4 secondi sul CrUX non è un sito veloce. È un sito ben testato in condizioni irrealistiche.
Mettere una CDN davanti a una pagina da 4 MB di JavaScript. La rete aiuta il download. Non accorcia il parse sul telefono dell'utente.
Ottimizzare immagini e lasciare i layout shift. Si ottiene un LCP migliore e un CLS peggiore, e l'utente continua a cliccare nel punto sbagliato.
Misurare solo la home. Search e utenti atterrano su URL interni. I Core Web Vitals si valutano per pagina. Una home veloce e una scheda prodotto lenta sono due prodotti diversi.
Confondere cache piena e prima visita. Chi torna sul sito ha già tutto in locale. Chi arriva da Google no. Le soglie si giudicano su quest'ultimo.
Aggiungere un plugin "optimizer" sopra un tema già pesante. Si accumulano layer. Si perde il controllo su cosa viene deferrito, e a volte si rompe l'INP per sistemare l'LCP.
In sintesi
La performance di un sito web non è un'attività di abbellimento da fare a lancio avvenuto. È il modo in cui il prodotto si manifesta: contenuto visibile, interfaccia che risponde, pagina che sta ferma mentre la si usa. Le tre soglie di web.dev, LCP 2,5 s, INP 200 ms, CLS 0,1, al 75° percentile, bastano come contratto minimo. Si misura sul campo, si interviene prima sul lavoro inutile del client, e solo dopo si parla di macchina e di rete. Il resto è rumore.
Gli altri pezzi del laboratorio, stack, sicurezza, operatività, stanno nel blog di RoxxoItalia. Questo è il punto di partenza: se il sito è lento, il prodotto è lento. Punto.
Fonti
web.dev, Web Vitals (soglie LCP, INP, CLS e 75° percentile).
web.dev, Largest Contentful Paint (LCP).
web.dev, Interaction to Next Paint (INP).
web.dev, Cumulative Layout Shift (CLS).
web.dev, INP diventa Core Web Vital il 12 marzo 2024 (sostituzione del FID).
Google Search Central, Understanding Core Web Vitals and Google search results.
MDN, Core Web Vitals.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
