Un sito può essere visivamente curato, ricevere traffico organico e risultare comunque inefficace nel momento decisivo: quando l’utente attende il caricamento della pagina, prova a interagire o vede il layout spostarsi sotto il dito. Questo caso reale di ottimizzazione Core Web Vitals mostra cosa accade quando il problema non è un singolo punteggio basso, ma un’architettura web che accumula ritardi ad ogni visita.
Il progetto riguardava un sito WordPress di un’attività ad alta marginalità. Il sito generava già richieste, ma il costo di acquisizione dai canali a pagamento cresceva e le landing principali convertivano meno del previsto sui dispositivi mobili. La prima ipotesi del cliente era semplice: serviva una cache migliore. L’analisi ha mostrato una situazione più articolata.
Il problema: un sito che caricava, ma troppo tardi
Nei test di laboratorio la home e le pagine servizio superavano facilmente i 4 secondi di Largest Contentful Paint su rete mobile simulata. Il Time to First Byte oscillava tra 1,1 e 1,8 secondi, mentre il Cumulative Layout Shift era superiore a 0,20 su alcune pagine. Il riferimento per una buona esperienza utente è diverso: LCP entro 2,5 secondi, CLS sotto 0,1 e Interaction to Next Paint entro 200 millisecondi per almeno il 75% delle visite reali.
Il dato più interessante, però, non era PageSpeed in sé. Nel tracciamento delle conversioni emergeva che gli utenti mobile abbandonavano con maggiore frequenza prima di raggiungere il modulo di contatto e che la quota di sessioni con interazione significativa era inferiore rispetto al traffico desktop. Non si poteva attribuire ogni mancata richiesta al solo tempo di caricamento, ma ignorare quel collo di bottiglia sarebbe stato un errore.
Un punteggio sintetico serve a individuare priorità. Non sostituisce l’analisi del percorso utente, della struttura del codice, dei dati raccolti sul campo e delle risorse richieste dal browser. Un sito può ottenere un buon risultato in laboratorio e restare lento per utenti reali con smartphone meno recenti o connessioni mobili instabili.
L’audit tecnico: perché la cache non bastava
L’intervento è iniziato con una mappatura delle pagine che ricevevano più traffico e generavano più contatti. Sono stati confrontati i dati di Chrome User Experience Report, quando disponibili, con test ripetuti su dispositivi e reti differenti. Poi sono state analizzate waterfall delle richieste, query al database, script di terze parti, peso delle immagini e DOM generato dal builder.
Le cause principali erano cinque:
- il server rispondeva tardi perché ogni richiesta attivava una catena di plugin, query e logiche non necessarie per utenti non autenticati;
- l’elemento LCP era un’immagine hero molto pesante, caricata senza priorità esplicita e accompagnata da varianti responsive non ottimali;
- fogli di stile e script venivano caricati globalmente, anche quando servivano a componenti assenti nella pagina;
- un widget esterno e alcuni strumenti di tracking bloccavano il thread principale nelle fasi iniziali;
- immagini, banner e moduli non avevano sempre dimensioni riservate, provocando spostamenti di layout.
Questo è un punto che spesso viene sottovalutato. La lentezza non derivava da un’unica immagine da comprimere, ma dalla somma di scelte tecniche stratificate. Un tema pesante, plugin installati per singole funzioni, script caricati ovunque e hosting non configurato per il carico reale possono convivere senza produrre errori evidenti. Il sito “funziona”, ma utilizza risorse in modo inefficiente.
L’intervento sull’architettura, non sul trucco del punteggio
La priorità era ridurre il lavoro necessario per mostrare il contenuto utile e rendere interattiva la pagina. Non era sensato rimuovere funzioni importanti per ottenere un report migliore: il sito doveva continuare a raccogliere lead, misurare le conversioni e mantenere l’esperienza richiesta dal brand.
Riduzione del TTFB con cache e stack server
Il primo intervento ha riguardato il percorso server. Le pagine pubbliche sono state configurate per essere servite da cache full-page, con esclusioni precise per aree dinamiche e contenuti personalizzati. Sono state eliminate chiamate non essenziali e riviste alcune query che venivano eseguite ad ogni caricamento.
L’hosting è stato configurato su stack LiteSpeed Enterprise, con cache lato server e regole coerenti con la logica del sito. Questo passaggio non è una scorciatoia universale: un ecommerce con carrello dinamico, un portale con aree riservate o contenuti geolocalizzati richiede esclusioni e verifiche diverse. Per le pagine informative e di acquisizione lead, però, una cache ben progettata può cambiare in modo concreto il tempo di risposta.
Il TTFB mediano delle pagine analizzate è sceso da circa 1,4 secondi a 0,32 secondi nei test controllati. Il risultato è stato verificato anche dopo la pubblicazione, perché una configurazione efficace in staging può comportarsi diversamente sotto traffico reale.
LCP: la hero come contenuto prioritario
L’immagine principale era il candidato LCP sulla maggior parte delle pagine servizio. È stata ricreata nelle dimensioni effettivamente necessarie, convertita in formato moderno e fornita con varianti responsive corrette. Soprattutto, è stata esclusa dal lazy loading e indicata al browser come risorsa prioritaria.
Sembra un dettaglio, ma è una delle incoerenze più comuni: applicare lazy loading a tutte le immagini senza distinguere quelle visibili subito. Il risultato è che il browser rimanda proprio la risorsa che deve mostrare per prima. Il lazy loading è utile sotto la piega della pagina, non per rallentare il contenuto iniziale.
Sono stati inoltre estratti e ottimizzati gli stili critici per la parte visibile al caricamento, rimandando il CSS non essenziale. Il lavoro non ha comportato la rimozione del design, ma una ricostruzione più pulita dei componenti. Un approccio code-first consente di caricare solo ciò che serve alla pagina, invece di ereditare markup e asset da moduli generici.
CLS e INP: stabilità prima, interazioni poi
Per risolvere il CLS sono stati definiti rapporti dimensionali espliciti per immagini e contenitori dinamici. Il modulo di contatto, le testimonianze e i banner informativi riservano ora lo spazio necessario prima che i contenuti completino il caricamento. Anche i font sono stati gestiti per limitare variazioni nella resa tipografica.
L’Interaction to Next Paint richiedeva un lavoro diverso. Alcuni script esterni venivano inizializzati subito, pur essendo utili soltanto dopo una scelta dell’utente o in sezioni non immediatamente visibili. Sono stati rinviati con criteri precisi, mentre il tracking delle conversioni è stato rivisto per preservare gli eventi essenziali senza appesantire l’avvio della pagina.
Rinviare ogni script non è una buona pratica in assoluto. Se un modulo di prenotazione è la funzione centrale della landing, ritardarlo troppo può peggiorare l’esperienza e falsare il tracciamento. La regola corretta è verificare il peso di ogni risorsa rispetto al suo valore nel percorso di conversione.
I risultati misurati dopo la pubblicazione
Dopo il rilascio, le principali landing hanno registrato un LCP tra 1,8 e 2,4 secondi nei test mobili controllati, rispetto ai valori iniziali oltre i 4 secondi. Il CLS è rientrato sotto 0,05 nelle pagine ottimizzate. Il peso trasferito alla prima visita si è ridotto di circa il 46%, soprattutto grazie a immagini, asset globali e script non più necessari.
Nei dati di comportamento successivi all’intervento, confrontati su periodi omogenei, il tasso di abbandono nelle prime fasi della sessione è diminuito e la quota di utenti che raggiungeva il modulo è aumentata. Non attribuirei questi segnali esclusivamente ai Core Web Vitals: stagionalità, qualità del traffico e offerta commerciale incidono sempre. Ma una pagina che appare prima, rimane stabile e risponde senza ritardi elimina una frizione concreta dal processo di acquisizione.
L’aspetto più rilevante è stato il mantenimento del risultato. A distanza di settimane, aggiornamenti, nuovi contenuti e modifiche al tracciamento non hanno riportato le metriche ai livelli iniziali, perché l’ottimizzazione non era basata su interventi casuali. Era stata corretta la struttura che generava sprechi.
Cosa insegna questo caso reale di ottimizzazione Core Web Vitals
Il valore di un audit non sta nel dire che un sito è lento. Sta nell’individuare quale ritardo conta davvero, dove nasce e quale intervento produce un miglioramento senza danneggiare design, SEO, funzionalità o misurazione delle conversioni.
Un tema standard e molti plugin possono essere una scelta ragionevole per un sito semplice, con requisiti limitati e budget ristretto. Quando il sito diventa un canale commerciale, però, ogni dipendenza aggiunta senza controllo aumenta il rischio di debito tecnico. Non sempre occorre rifare tutto da zero, ma spesso serve decidere se conviene ottimizzare l’esistente o ricostruire le pagine strategiche su una base più leggera e controllabile.
Se il tuo sito ha buoni contenuti ma tempi di caricamento incerti, punteggi instabili o conversioni difficili da leggere, un audit performance e SEO può separare i problemi percepiti da quelli misurabili. L’analisi dovrebbe partire dalle pagine che generano valore, non dalla homepage scelta a caso.
Una performance credibile non è il risultato di un test eseguito una volta. È la capacità del sito di restare veloce mentre il business aggiunge pagine, campagne, integrazioni e nuove esigenze. È da questa disciplina tecnica che un sito smette di essere una vetrina e diventa un’infrastruttura commerciale affidabile.