Un sito può apparire curato, avere contenuti validi e ricevere traffico, ma perdere contatti prima ancora che l’utente legga la proposta. Un case study Core Web Vitals serve a isolare questo problema con dati verificabili: non misura soltanto la velocità percepita, ma collega rendering, interazione e stabilità visiva a SEO, esperienza utente e probabilità di conversione.
Per un’impresa, il punto non è inseguire un punteggio estetico su PageSpeed Insights. Il punto è capire se la pagina che porta un potenziale cliente al contatto è effettivamente rapida sul dispositivo e sulla connessione che usa ogni giorno. Un audit serio distingue tra un sito che ottiene un buon risultato in un test sintetico e un sito che mantiene prestazioni adeguate per gli utenti reali.
Case study Core Web Vitals: il problema iniziale
Consideriamo uno scenario ricorrente: un’azienda con un sito WordPress già online, pagine commerciali ben strutturate e traffico organico stabile. La pagina principale viene costruita con un builder visuale, integra molte sezioni animate, font esterni, immagini hero di grandi dimensioni e diversi script per moduli, cookie banner, analisi e chat.
Su desktop, la pagina sembra veloce. Su smartphone, che per molte attività locali e servizi B2B rappresenta una quota rilevante delle visite, la situazione cambia: il contenuto principale compare tardi, i pulsanti si spostano durante il caricamento e il primo tocco sul modulo di contatto risponde con ritardo.
In un’analisi iniziale, un quadro plausibile può essere questo:
- LCP a 4,6 secondi sul 75° percentile degli utenti reali
- INP a 310 millisecondi
- CLS a 0,19
- TTFB oltre 900 millisecondi sulle pagine non servite dalla cache
Sono valori che non descrivono un sito inutilizzabile. Descrivono però un sito che impone attrito proprio nei momenti in cui l’utente deve capire l’offerta, consultare una prova di competenza o inviare una richiesta.
Google considera buoni, come riferimento, un LCP entro 2,5 secondi, un INP inferiore a 200 millisecondi e un CLS sotto 0,1. Queste soglie non sono una garanzia di posizionamento, né una diagnosi completa della qualità del sito. Sono indicatori concreti di un’esperienza che tende a essere più stabile e reattiva.
Le metriche non sono intercambiabili
L’errore più comune consiste nel trattare i Core Web Vitals come un unico indicatore di velocità. In realtà, ogni metrica indica una causa tecnica diversa e richiede interventi diversi.
LCP: quando appare il contenuto che conta
Largest Contentful Paint misura quando viene visualizzato l’elemento più grande nella parte iniziale della pagina. Spesso coincide con l’immagine hero, il titolo principale o un blocco visivo di apertura.
Nel caso analizzato, l’LCP elevato non dipendeva da un solo file pesante. Era l’effetto combinato di una risposta server lenta, CSS non ottimizzato, immagine hero caricata senza priorità e JavaScript che ritardava il rendering. Comprimere soltanto l’immagine avrebbe migliorato il test, ma non avrebbe risolto l’architettura del problema.
L’intervento corretto parte dall’identificazione precisa dell’elemento LCP. Se è un’immagine, vanno verificati formato moderno, dimensioni reali di visualizzazione, preload selettivo e assenza di lazy loading sull’elemento above the fold. Se è un blocco testuale, la priorità passa a CSS critico, font e catena di rendering.
INP: quando il sito risponde davvero
Interaction to Next Paint misura la latenza tra un’interazione dell’utente e l’aggiornamento visivo successivo. È la metrica che rivela un sito apparentemente rapido ma faticoso da usare: menu che ritardano l’apertura, campi del form poco reattivi, filtri che bloccano la pagina.
Un INP alto è spesso legato a JavaScript eccessivo sul thread principale. I builder visuali molto stratificati possono contribuire al problema con markup ridondante, librerie caricate globalmente e funzioni non necessarie su ogni pagina. Lo stesso accade quando strumenti esterni vengono caricati tutti all’avvio, indipendentemente dal fatto che l’utente li utilizzi.
Qui il compromesso va gestito con lucidità. Un sistema di chat, una mappa interattiva o un widget di prenotazione possono avere valore commerciale. Non vanno eliminati per principio: vanno caricati quando servono, soltanto nelle pagine pertinenti e con una verifica successiva sull’impatto reale.
CLS: quando il layout smette di muoversi
Cumulative Layout Shift rileva gli spostamenti inattesi degli elementi durante il caricamento. Un valore elevato è particolarmente dannoso su pagine con call to action, perché l’utente può trovarsi a cliccare nel punto sbagliato o perdere la posizione mentre legge.
Le cause più comuni sono immagini e iframe senza dimensioni dichiarate, font che sostituiscono il rendering iniziale, banner cookie inseriti senza riservare spazio e componenti dinamici caricati sopra contenuti già visibili. La correzione non richiede effetti grafici o plugin aggiuntivi: richiede regole dimensionali esplicite, gestione corretta dei font e una gerarchia stabile del layout.
Dal dato alla causa: il metodo di analisi
Un case study utile non si limita al confronto prima e dopo. Deve documentare la sequenza che ha prodotto il miglioramento, altrimenti si riduce a un numero privo di contesto.
Il primo livello è la raccolta dei dati sul campo. I dati real-user, aggregati su 28 giorni, mostrano come si comporta il sito nelle condizioni effettive di navigazione. I test di laboratorio, invece, servono per riprodurre il problema, individuare le risorse responsabili e verificare ogni modifica in modo controllato. Usare solo uno dei due livelli porta a decisioni parziali.
Il secondo livello riguarda l’architettura. Si analizzano TTFB, cache delle pagine, cache degli oggetti, query al database, peso del DOM, richieste di rete, CSS inutilizzato, JavaScript bloccante e script terzi. È qui che emerge la differenza tra un intervento cosmetico e un’ottimizzazione strutturale.
Il terzo livello è commerciale. Non tutte le pagine hanno la stessa priorità. Una pagina di servizio che porta richieste, una landing con un form e una pagina prodotto strategica meritano attenzione prima di un articolo marginale del blog. Le performance vanno trattate come parte del percorso di conversione, non come un’attività tecnica scollegata dal business.
L’intervento tecnico e i risultati da verificare
In uno scenario come quello descritto, il piano di lavoro può includere la ricostruzione delle sezioni critiche con markup più essenziale, l’eliminazione delle dipendenze non necessarie, il caricamento condizionale degli script, l’ottimizzazione delle immagini e una configurazione server adeguata.
Uno stack con LiteSpeed Enterprise, cache configurata per il progetto e hosting gestito può ridurre in modo rilevante il tempo di risposta, ma non corregge da solo un frontend inefficiente. Allo stesso modo, un codice pulito non compensa un server lento o un database trascurato. Le prestazioni nascono dall’allineamento tra frontend, backend, cache e risorse esterne.
Dopo gli interventi, un obiettivo realistico potrebbe essere portare il TTFB sotto i 400 millisecondi sulle pagine dinamiche più importanti, ridurre l’LCP sotto 2,5 secondi e stabilizzare il CLS entro 0,1. L’INP richiede spesso un ciclo ulteriore di verifica, perché dipende dalle interazioni effettive degli utenti e dagli script attivati nel tempo.
La verifica non termina con il rilascio. Vanno controllati Search Console, dati di analisi, eventi di conversione e comportamento dei form. Se il sito carica più rapidamente ma le richieste non aumentano, la causa può essere nell’offerta, nella chiarezza della pagina o nel percorso di contatto. La performance migliora le condizioni di conversione, non sostituisce la strategia commerciale.
Perché il tracking completa il case study
Senza tracking, è possibile dimostrare un miglioramento tecnico ma non valutarne il peso sul business. Gli eventi essenziali da rilevare includono visualizzazione delle pagine chiave, clic su telefono o email, invio modulo, avvio di una prenotazione e download di materiali informativi.
Il server-side tracking può rendere più affidabile la raccolta degli eventi rispetto a una configurazione esclusivamente browser-side, soprattutto in presenza di consenso cookie, ad blocker e limitazioni dei browser. Non è una scorciatoia per raccogliere dati senza regole: richiede una configurazione conforme, documentata e coerente con gli obiettivi di misurazione.
Nel metodo di Francesco Russo, performance, SEO tecnica e tracking vengono considerate parti della stessa architettura. Il sito deve essere veloce per gli utenti, leggibile per i motori di ricerca e misurabile per chi investe nel canale digitale.
Quando conviene richiedere un audit
Un audit performance e SEO è particolarmente indicato quando le pagine commerciali sono lente su mobile, i punteggi oscillano dopo ogni modifica, il sito dipende da molti plugin, le conversioni non sono tracciate con precisione oppure il builder rende costoso intervenire sul codice.
L’audit non dovrebbe produrre una lista generica di raccomandazioni. Dovrebbe indicare quali problemi hanno impatto concreto, quale priorità assegnare, quali modifiche comportano rischi e quale miglioramento è ragionevole aspettarsi. In alcuni casi basta ottimizzare lo stack esistente; in altri, continuare ad aggiungere patch a una struttura pesante costa più di una ricostruzione mirata.
Richiedere un’analisi tecnica del sito prima di rifarlo evita decisioni basate su impressioni o punteggi isolati. Un buon dato di partenza non è “il sito è lento”, ma “questa risorsa, su questa pagina e per questo tipo di utente sta ostacolando un’azione misurabile”.
La domanda utile non è se il sito può ottenere qualche punto in più in un report. È se ogni secondo, script e componente presente nella pagina sta giustificando il proprio costo rispetto al contatto che dovrebbe generare.