Sito lento: come capire perché e cosa sistemare per primo

“Il sito è lento” è una delle frasi che sentiamo più spesso, ed è anche una delle più difficili da usare così com’è. Lento per chi, su quale pagina, con che telefono e con quale connessione? Senza queste risposte si finisce a inseguire un punteggio invece di risolvere il problema di chi sta comprando.

Questo articolo parte dal sintomo e arriva a cosa sistemare per primo, con i numeri che contano davvero e nell’ordine in cui conviene guardarli.

Prima domanda: lento davvero o lento in laboratorio?

Esistono due modi di misurare la velocità di un sito, e vengono confusi in continuazione.

Il primo è la simulazione: uno strumento carica la pagina da un server, con una connessione finta, e dà un punteggio. È utile per capire cosa migliorare, ed è il motivo per cui il numero cambia a ogni prova.

Il secondo sono i dati di campo: le misure raccolte dai browser delle persone che visitano davvero il sito, con i loro telefoni e le loro connessioni. Questo è il dato che Google usa, ed è l’unico che descrive la tua situazione reale.

Prima di toccare qualcosa, guarda i dati di campo in Search Console, nella sezione dedicata ai segnali web. Se lì è tutto verde e il punteggio della simulazione è basso, il tuo sito non ha un problema di velocità: ha un problema di punteggio, che è un’altra cosa e vale molto meno.

Seconda domanda: lento dove

Un sito non è lento in blocco. Di solito lo è in un punto preciso, e quasi sempre quello che conta.

Le pagine da guardare sono tre: quella su cui arriva la maggior parte del traffico, quella che porta i contatti o le vendite, e la scheda prodotto o servizio più visitata. Se sono veloci quelle, il resto può aspettare. Se sono lente quelle, tutto il resto è irrilevante.

Search Console raggruppa le pagine per comportamento simile, ed è un aiuto concreto: quasi sempre il problema non è di una pagina ma di un modello, cioè di come sono costruite tutte le pagine di quel tipo. Si corregge una volta e vale per tutte.

Terza domanda: lento per cosa

Le misure che contano sono tre, e descrivono tre fastidi diversi.

La prima è quanto ci mette a comparire la cosa principale della pagina, in genere l’immagine grande in alto o il titolo. È quella che decide la sensazione di lentezza, e la causa numero uno è sempre la stessa: un’immagine troppo pesante caricata a piena risoluzione.

La seconda è quanto tempo passa fra il tocco e la reazione. Se il menu si apre mezzo secondo dopo il tap, o il pulsante di acquisto sembra non funzionare e la persona lo preme due volte, il problema è questo, e la causa è quasi sempre troppo codice che gira mentre l’utente sta già interagendo.

La terza è quanto la pagina balla mentre carica. È il difetto più irritante: stai per toccare un link e il contenuto si sposta, perché un’immagine senza dimensioni dichiarate o un banner sono comparsi sopra.

Le soglie precise le trovi nella sezione qui sotto, insieme a cosa fare per ciascuna.

Le soglie, e cosa fare quando non le rispetti

Google misura la performance percepita con tre numeri. Ognuno ha una soglia “verde” che vuoi raggiungere.

LCP: Largest Contentful Paint < 2.5s

Quanto tempo passa dal click utente al momento in cui il contenuto principale della pagina è visibile. Tipicamente è la hero image, l’H1, una featured image. Sotto i 2.5 secondi sei nel verde. Sopra i 4 sei nel rosso e Google ti penalizza.

Cause comuni di LCP cattivo: immagini hero pesantissime, CSS render-blocking nel head, font che caricano in ritardo bloccando il testo, server lento.

INP: Interaction to Next Paint < 200ms

La metrica che ha sostituito FID a marzo 2024. Misura quanto è reattiva la pagina ai click, tap, input dell’utente. Se clicchi un pulsante e la pagina ci mette 500ms a rispondere visivamente, INP è alto.

Cause comuni: troppi script di tracking (GTM caricato in async con 15 tag dentro), plugin WP pesanti che eseguono JavaScript ad ogni evento, animazioni JS non hardware-accelerated.

CLS: Cumulative Layout Shift < 0.1

Quanto il layout della pagina “salta” durante il caricamento. Un’immagine che carica senza dimensioni dichiarate, un banner cookie che spinge giù il contenuto, un font che cambia dimensione del testo a metà rendering.

Sotto 0.1 è verde. Sopra 0.25 è rosso. Una pagina con CLS alto è frustrante anche prima che l’utente capisca perché, clicchi un pulsante, il pulsante si sposta, clicchi su un banner ads.

Gli strumenti, in ordine di utilità

Le metriche dei Core Web Vitals che Google usa per il ranking sono field data, misure reali da utenti veri, non i lab data del PageSpeed Insights. Tre strumenti che usiamo sui clienti:

• Search Console > Core Web Vitals, i dati che Google effettivamente usa per ranking. Aggregati per URL pattern. È la fonte di verità.
• PageSpeed Insights (pagespeed.web.dev), combina field data (se ci sono) e lab data. Utile per debug puntuale.
• WebPageTest.org, lab data ma con scelta geografica, browser, network throttling. Insostituibile per debug profondo.

Sui clienti tracciamo i CWV in continuo con un dashboard custom che pesca da Search Console API. Il dato lab di PageSpeed può essere ingannevole se vario.

Le 7 ottimizzazioni che fanno la differenza

Dopo decine di interventi su siti WP, e-commerce, landing, queste sono le 7 cose che muovono davvero l’ago. Non tutte si applicano a ogni sito, ma valutarle è la base.

1. Immagini in AVIF + lazy loading nativo

AVIF è il formato 2026. Compressione 30-50% migliore di WebP, supportato da tutti i browser moderni. Plugin LiteSpeed Image Optimization o Smush convertono automaticamente. Per le immagini sotto la fold, loading="lazy" nativo HTML, niente più plugin LazyLoad.

2. Hero LCP ottimizzata con preload

L’immagine principale della hero deve essere preloaded nel <head>:

<link rel="preload" as="image" href="hero.avif"
      imagesrcset="hero-mobile.avif 800w, hero.avif 1920w"
      imagesizes="100vw">

Il browser inizia a scaricare l’immagine prima ancora di parsare il CSS. Tipicamente abbatte LCP di 500-1000ms su mobile.

3. Pulizia ferocia degli script di tracking

GTM con 20 tag attivi è un assassino INP. Pulisci i tag che non usi davvero (controlla GA4 ultimi 90 giorni: i tag che non generano dati vanno via). Sposta GTM in defer dove possibile. Considera Server-Side Tagging per i tag critici (conversion, e-commerce).

4. Critical CSS inline + rest deferred

I primi 14KB di CSS che servono per renderizzare il fold inline nel <head>. Il resto del CSS caricato con <link rel="preload" as="style"> o asynchronously. Plugin: WP Rocket o LiteSpeed lo fanno automaticamente, sui siti custom va fatto a mano.

5. Font in font-display: swap e preloaded

Mai mostrare testo invisibile mentre il font carica. font-display: swap nel @font-face mostra il fallback sistema, poi swappa al font custom. Per i font critici (display dei titoli) <link rel="preload" as="font" type="font/woff2" crossorigin>.

6. Plugin audit serio

WordPress su 30+ plugin attivi è quasi sempre lento. Audit con Query Monitor: scopri quali plugin pesano sulle query database, quali caricano script in homepage anche se servono solo in checkout. Disattiva quello che non usi attivamente. Spesso recuperi 500ms-1s di LCP.

7. CDN + HTTP/3 attivi

Cloudflare gratis copre il 90% dei casi. Cache statica, immagini ottimizzate, HTTP/3. Setup di 30 minuti, beneficio sui CWV immediato. Per siti enterprise: Cloudflare Pro o Bunny CDN.

Trappole comuni

Tre errori che vediamo continuamente.

• “Ho installato il plugin di cache, sono a posto”, no. Il plugin di cache aiuta server response time, ma non risolve immagini pesanti, JS bloccante, CLS. È uno dei sette interventi, non l’unico.
• “PageSpeed mi dà 95, sono ok”, il lab data può essere ottimo, ma se gli utenti veri vedono LCP a 3s (rete lenta, dispositivo vecchio) la Search Console mostrerà rosso. Guarda sempre i field data.
• “Ho ottimizzato la home”, Google misura i CWV per URL pattern (gruppo di pagine simili). Ottimizzare solo la home non basta: le pagine articolo, le pagine prodotto, il checkout vanno ottimizzati ognuno per sé.

Cosa portarsi a casa

• LCP < 2.5s, INP < 200ms, CLS < 0.1, le tre soglie verdi del 2026. Sotto le quali Google sorride.
• Field data > lab data. Search Console è la fonte di verità, non PageSpeed Insights.
• I 7 interventi base: AVIF, hero preload, pulizia tracking, critical CSS, font swap, plugin audit, CDN. Applicarli risolve il 90% dei problemi.

“Bello, sì, ma prima funzionante.” Un sito veloce è il prerequisito di un sito che genera business. Tutto il resto viene dopo.

Conclusione

Performance non è “ottimizzazione finale”, è una scelta strutturale del sito. Si paga ora o si paga dopo (in perdita di conversioni, di posizionamento, di reputazione). I siti che costruiamo nascono già ottimizzati su CWV: è più facile farlo bene la prima volta che riparare dopo.

Se il tuo sito ha un Core Web Vitals score in rosso, è uno dei primi interventi che facciamo come servizio. Audit + roadmap + esecuzione in 2-4 settimane. Niente vetrine, solo strumenti che vendono, e che vendono velocemente.

Domande frequenti

Se il tuo sito è lento e non sai da dove cominciare, la prima cosa utile è misurare sui dati reali invece che sui punteggi: è il primo passo dell’audit digitale, e il lavoro di fondo lo trovi nella pagina siti web.

Se vuoi che ne parliamo, scrivici.