Un sito che impiega quattro o cinque secondi per mostrare il contenuto principale raramente ha un problema soltanto estetico. Sta perdendo attenzione, richieste di contatto e, spesso, dati utili per capire dove si interrompe il percorso dell’utente. I Core Web Vitals servono proprio a misurare questa parte dell’esperienza: non la percezione generica di un sito “veloce”, ma il modo in cui le persone reali vedono, usano e subiscono una pagina.
Per un’impresa, il punto non è inseguire un punteggio perfetto in un report. Il punto è ridurre gli attriti che separano una visita da un’azione: una telefonata, una richiesta di preventivo, una prenotazione, l’invio di un modulo. Le metriche di Google aiutano a individuare questi attriti, ma richiedono un intervento architetturale, non una serie di plugin installati alla cieca.
Cosa misurano davvero i Core Web Vitals
Le metriche principali sono tre: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Ognuna intercetta un problema diverso e tutte hanno una ricaduta concreta sull’esperienza di chi visita il sito da mobile, spesso con una connessione non ottimale.
LCP: quanto tarda a comparire ciò che conta
LCP misura il tempo necessario perché l’elemento visivo più rilevante nella porzione iniziale della pagina diventi visibile. Può essere il titolo principale, un’immagine hero, una foto prodotto o un blocco promozionale. Per essere considerato buono, il valore dovrebbe restare entro 2,5 secondi al 75° percentile delle visite reali.
Se l’LCP è alto, l’utente apre la pagina e per troppo tempo non riceve una risposta utile. Il browser può mostrare lo sfondo, il menu o un loader, ma il messaggio commerciale rimane invisibile. È un problema frequente nei siti con immagini hero pesanti, font caricati in ritardo, CSS inutilizzato, script di tracciamento non governati o server lenti nella generazione della pagina.
Non sempre la soluzione consiste nel comprimere un’immagine. Se il Time to First Byte (TTFB) è elevato, il server sta ritardando l’intera risposta. Se invece l’HTML arriva rapidamente ma l’elemento LCP resta bloccato, bisogna verificare priorità di caricamento, risorse render-blocking, lazy loading applicato nel punto sbagliato e struttura del template.
INP: la reattività dopo il primo clic
INP misura la velocità con cui una pagina risponde alle interazioni dell’utente: clic su un menu, apertura di un modulo, selezione di una variante, invio di un filtro, tap su una call to action. Un valore inferiore a 200 millisecondi è l’obiettivo; tra 200 e 500 millisecondi richiede attenzione, oltre 500 millisecondi segnala una risposta percepibilmente lenta.
Questa metrica ha sostituito First Input Delay perché non valuta solo la prima interazione. Considera la reattività complessiva della pagina. È una distinzione rilevante per siti con configuratori, cataloghi, moduli multi-step o componenti dinamici: una pagina può sembrare rapida al caricamento e diventare frustrante nel momento in cui l’utente prova a usarla.
La causa più comune è il lavoro eccessivo del browser, in particolare JavaScript che occupa il main thread. Builder visuali molto stratificati, widget non necessari, popup, chat, mappe, strumenti analytics duplicati e librerie caricate su tutte le pagine possono trasformare un clic semplice in una sequenza lenta di elaborazioni.
CLS: quando la pagina si sposta sotto le dita
CLS misura la stabilità visiva. Il problema è familiare: l’utente sta per premere un pulsante e, un attimo prima del tap, compare un banner o si carica un’immagine senza dimensioni riservate. Il layout si sposta e il clic finisce altrove. Un CLS inferiore a 0,1 è considerato buono.
Qui il danno non è solo tecnico. Un layout instabile riduce la fiducia, soprattutto su pagine dove la decisione è delicata: richiesta di consulenza, checkout, contatto per un servizio ad alta marginalità. Spesso il problema nasce da immagini o iframe senza width e height definiti, font web che cambiano le dimensioni del testo dopo il rendering, banner cookie invasivi o moduli inseriti dinamicamente sopra il contenuto.
Dati reali e test di laboratorio non sono la stessa cosa
Un audit in PageSpeed Insights o Lighthouse è utile, ma non rappresenta da solo la realtà del sito. I Core Web Vitals vengono valutati anche attraverso dati di campo, raccolti da utenti reali e aggregati nel Chrome UX Report. La soglia di riferimento è il 75° percentile: la pagina deve offrire una buona esperienza almeno al 75% delle visite analizzate.
Questo spiega perché un sito può ottenere ottimi risultati in un test isolato e continuare a mostrare criticità nei dati reali. Un report di laboratorio usa condizioni controllate; gli utenti arrivano con smartphone diversi, reti mobili variabili, cache fredda, pagine interne e percorsi non previsti dal test.
L’analisi corretta parte quindi dalle URL che ricevono traffico e generano valore. La home page non è necessariamente la priorità. Per una realtà locale potrebbe esserlo la pagina servizio; per un’azienda B2B, una landing organica ben posizionata; per un e-commerce, una categoria o la scheda prodotto. Ottimizzare una pagina irrilevante migliora un grafico, non il business.
Perché le performance incidono su SEO e conversioni
Google considera l’esperienza di pagina tra i segnali utili alla qualità complessiva, ma sarebbe riduttivo descrivere i Core Web Vitals come una leva SEO isolata. Non compensano contenuti deboli, architettura informativa confusa o assenza di rilevanza rispetto alla ricerca dell’utente.
Il loro impatto è più concreto quando agiscono insieme a una base SEO tecnica corretta. Un sito rapido consente al crawler di elaborare le risorse con minori ostacoli, rende le pagine più accessibili da mobile e riduce il rischio che l’utente abbandoni prima di leggere l’offerta. Se il traffico acquisito con attività SEO atterra su una pagina lenta o instabile, il costo dell’inefficienza non appare in una sola metrica: si distribuisce tra minore coinvolgimento, meno conversioni e segnali comportamentali peggiori.
Va evitato anche l’equivoco opposto: un punteggio 100/100 non garantisce più contatti. Ridurre immagini, script e componenti senza valutare il funnel può eliminare elementi utili alla conversione. La priorità è mantenere ciò che aiuta la decisione dell’utente e rimuovere o riprogettare ciò che aggiunge peso senza funzione.
Gli interventi che producono miglioramenti misurabili
Un intervento efficace non parte dalla cache. Parte da una diagnosi. Occorre distinguere i problemi di infrastruttura da quelli di front-end, quindi verificare TTFB, query lente, dimensione del DOM, richieste di rete, script terzi, immagini, font e comportamento dei template.
Su WordPress, spesso la causa non è il CMS ma il modo in cui è stato assemblato il sito. Tema pesante, builder che genera markup ridondante, plugin sovrapposti e hosting condiviso senza risorse adeguate formano una catena. Ottimizzare solo un anello può produrre un miglioramento temporaneo, ma non risolve il limite strutturale.
Le leve tecniche più ricorrenti includono un hosting configurato correttamente, caching lato server, object cache dove necessaria, ottimizzazione delle query, immagini in formati moderni con dimensioni coerenti, caricamento selettivo di CSS e JavaScript, preload delle risorse realmente critiche e gestione rigorosa degli script di terze parti. Su stack LiteSpeed Enterprise, ad esempio, caching e ottimizzazione possono lavorare a livello infrastrutturale, ma restano efficaci solo se il codice e la struttura del sito non creano inefficienze a monte.
Il codice custom e un approccio code-first offrono un vantaggio preciso: caricare solo ciò che serve alla pagina e mantenere controllo sul markup. Non significa che ogni progetto debba essere riscritto da zero. Dipende dalla gravità dei problemi, dalla vita utile prevista per il sito e dal valore delle pagine coinvolte. In alcuni casi è sufficiente intervenire sui template critici; in altri, continuare ad aggiungere correzioni a una base fragile costa più di una ricostruzione mirata.
Un processo tecnico, prima delle ottimizzazioni
Un audit serio collega le metriche alla struttura e agli obiettivi del sito. Si analizzano le principali pagine di ingresso, i dati di campo, la configurazione del server, il peso delle risorse e gli eventi di conversione. Senza tracking affidabile, è difficile stabilire se una modifica abbia migliorato soltanto la velocità o anche la qualità dei contatti.
L’approccio di Francesco Russo parte da questa lettura: identificare il collo di bottiglia, definire interventi con impatto misurabile e verificare gli effetti dopo il rilascio. LCP, INP e CLS diventano così indicatori operativi, insieme a TTFB, tasso di conversione, invii modulo e qualità del traffico organico.
Se il vostro sito ha buoni contenuti ma rimane lento, instabile o difficile da usare su mobile, una analisi tecnica delle performance può chiarire se il problema è correggibile con un’ottimizzazione selettiva o se richiede una revisione dell’architettura. Prima di investire in nuovo traffico, vale la pena verificare che le pagine che lo ricevono siano davvero in grado di trasformarlo in opportunità commerciali.
La velocità utile non è quella che impressiona un report per pochi secondi: è quella che lascia all’utente il tempo e la fiducia necessari per compiere l’azione successiva.