Core Web Vitals per WordPress: Cosa Rallenta Davvero un Sito

I Core Web Vitals per WordPress aiutano a valutare quanto velocemente una pagina mostra il proprio contenuto principale, quanto rapidamente risponde alle interazioni e quanto rimane stabile durante il caricamento.

Quando un sito ottiene risultati insufficienti, la causa non è quasi mai riconducibile a un solo elemento. Hosting, tema, immagini, plugin, font, JavaScript, database e servizi esterni possono contribuire in modo differente.

Installare un plugin di cache e attivare tutte le opzioni disponibili non garantisce quindi un miglioramento. Prima di intervenire è necessario identificare quale metrica presenta un problema, quali pagine sono coinvolte e quale risorsa produce realmente il rallentamento.

Core Web Vitals per WordPress: Le Tre Metriche Principali

I Core Web Vitals analizzano tre aspetti differenti dell’esperienza utente:

• Largest Contentful Paint, o LCP: misura il tempo necessario per visualizzare il contenuto principale presente nell’area iniziale della pagina;
• Interaction to Next Paint, o INP: misura la velocità con cui la pagina risponde a clic, tocchi e interazioni da tastiera;
• Cumulative Layout Shift, o CLS: misura gli spostamenti imprevisti degli elementi durante l’utilizzo della pagina.

Per essere considerati buoni, i valori dovrebbero essere:

• LCP entro 2,5 secondi;
• INP entro 200 millisecondi;
• CLS non superiore a 0,1.

Questi valori non devono essere osservati soltanto durante un singolo test effettuato dal proprio computer. La valutazione considera l’esperienza reale di una parte significativa degli utenti, con dispositivi, connessioni e condizioni differenti.

LCP: Quando il Contenuto Principale Arriva in Ritardo

Il Largest Contentful Paint non misura il caricamento completo della pagina. Misura quando viene visualizzato l’elemento principale presente nella parte iniziale dello schermo.

L’elemento LCP può essere:

• un’immagine principale;
• un’immagine di sfondo;
• un titolo molto grande;
• un blocco di testo;
• un banner;
• la copertina di un articolo;
• l’immagine principale di un prodotto.

Su molti siti WordPress l’elemento LCP è l’immagine iniziale inserita dal tema. In altri casi è un grande titolo visualizzato sopra la piega.

Per migliorare il valore non basta quindi comprimere tutte le immagini del sito. È necessario individuare l’elemento specifico scelto dal browser e analizzare l’intero percorso necessario per mostrarlo.

Le Parti che Compongono il Tempo LCP

Il tempo necessario per visualizzare l’elemento principale può dipendere da più fasi:

• risposta iniziale del server;
• download del documento HTML;
• individuazione della risorsa principale;
• download dell’immagine o del font;
• elaborazione di CSS e JavaScript;
• rendering finale dell’elemento.

Ottimizzare soltanto il file dell’immagine può produrre un miglioramento limitato se il server risponde lentamente oppure se il browser scopre la risorsa con molto ritardo.

Allo stesso modo, un server veloce non risolve un’immagine principale caricata attraverso uno script eseguito soltanto dopo il rendering della pagina.

Il Tempo di Risposta del Server

Ogni pagina WordPress deve essere generata oppure recuperata dalla cache prima di essere inviata al browser.

Quando la risposta iniziale è lenta, tutte le fasi successive iniziano in ritardo.

Tra le possibili cause ci sono:

• hosting con risorse insufficienti;
• PHP non adeguatamente configurato;
• database lento;
• numerose query eseguite dal tema o dai plugin;
• chiamate verso servizi esterni durante la generazione della pagina;
• assenza di cache;
• cache non funzionante per gli utenti non autenticati;
• processi programmati eseguiti durante le visite.

Prima di modificare il frontend verifico quindi quanto tempo impiega il server a produrre il documento HTML.

Un problema di backend non dovrebbe essere corretto aggiungendo altre ottimizzazioni JavaScript nel browser.

Il Ruolo della Cache in WordPress

La cache permette di evitare che WordPress debba ricostruire completamente una pagina a ogni visita.

Può intervenire su livelli differenti:

• cache della pagina;
• cache degli oggetti;
• cache delle query;
• cache del browser;
• cache del server;
• cache distribuita attraverso una CDN.

La cache della pagina è particolarmente utile per contenuti pubblici che cambiano raramente, come articoli, pagine servizio e schede informative.

Non tutte le sezioni possono però essere trattate allo stesso modo. Carrelli, aree riservate, pagine personalizzate e contenuti differenti per ogni utente richiedono regole specifiche.

Una configurazione aggressiva applicata senza controlli può mostrare informazioni non aggiornate o contenuti appartenenti a sessioni differenti.

Il Tema Può Rallentare Tutto il Sito

Il tema non gestisce soltanto colori e impaginazione. Determina spesso la struttura HTML, i template, le risorse caricate e il modo in cui vengono costruite le pagine.

Un tema può rallentare il sito quando:

• carica fogli di stile molto estesi;
• include numerose librerie JavaScript;
• utilizza animazioni in tutte le pagine;
• genera una struttura HTML eccessivamente complessa;
• carica file destinati a funzioni non utilizzate;
• dipende da un page builder pesante;
• esegue query aggiuntive;
• integra direttamente funzioni che dovrebbero essere separate.

Un tema apparentemente semplice può comunque utilizzare molte risorse. Per questo motivo non valuto le prestazioni soltanto osservando il risultato grafico.

Controllo quali file vengono caricati, dove vengono utilizzati e se sono realmente necessari.

Page Builder e Struttura delle Pagine

I page builder permettono di costruire layout complessi senza intervenire direttamente sui template.

Il loro impatto dipende dal modo in cui vengono utilizzati.

Una singola pagina può accumulare:

• numerosi contenitori annidati;
• stili inline;
• file CSS generati dinamicamente;
• widget non necessari;
• animazioni;
• script associati a moduli non utilizzati;
• duplicazioni tra versione desktop e mobile.

Il problema non è sempre il builder in sé. Spesso è la combinazione tra builder, tema, estensioni aggiuntive e struttura della pagina.

Ricostruire un layout con meno elementi può essere più efficace rispetto all’attivazione di ulteriori strumenti di ottimizzazione.

Immagini e Largest Contentful Paint

Le immagini sono una delle cause più comuni di un LCP elevato, soprattutto quando la fotografia iniziale viene caricata a una risoluzione molto superiore rispetto allo spazio effettivamente disponibile.

Durante l’analisi controllo:

• dimensioni reali del file;
• dimensioni con cui viene visualizzato;
• formato utilizzato;
• compressione;
• versioni responsive generate da WordPress;
• attributo srcset;
• priorità di caricamento;
• eventuale lazy loading;
• origine del file.

Un’immagine larga 2500 pixel non è necessariamente utile quando viene mostrata in un contenitore da 700 pixel.

WordPress genera automaticamente diverse dimensioni, ma il tema deve richiamare quella più adatta e mantenere correttamente le informazioni responsive.

Non Applicare il Lazy Loading all’Immagine Principale

Il caricamento differito è utile per le immagini che si trovano più in basso nella pagina.

Applicarlo all’immagine principale può invece ritardare la scoperta della risorsa e peggiorare il Largest Contentful Paint.

L’immagine visibile immediatamente dovrebbe normalmente essere richiesta con priorità, mentre le immagini lontane dall’area iniziale possono essere caricate successivamente.

Il controllo deve essere effettuato sul codice effettivamente prodotto dal tema, perché plugin e sistemi di ottimizzazione possono modificare automaticamente gli attributi delle immagini.

Definire Sempre le Dimensioni delle Immagini

Le dimensioni dichiarate aiutano il browser a riservare lo spazio necessario prima che il file venga scaricato.

Un’immagine priva di larghezza e altezza può provocare lo spostamento del testo quando viene caricata.

Una struttura corretta può essere simile alla seguente:

Gli attributi non obbligano necessariamente il browser a mostrare il file con quelle dimensioni. Permettono di calcolare anticipatamente il rapporto tra larghezza e altezza.

Font Esterni e Testo Iniziale

I font possono rallentare il rendering e produrre spostamenti del layout.

Un sito può caricare:

• più famiglie tipografiche;
• numerosi pesi;
• versioni corsive;
• icone basate su font;
• file provenienti da servizi esterni;
• formati non ottimizzati.

Ogni variante aggiunge una nuova risorsa.

Se il titolo principale dipende da un font scaricato in ritardo, il browser può inizialmente mostrare un carattere alternativo e sostituirlo successivamente.

Questa sostituzione può ritardare il rendering o modificare le dimensioni del testo, contribuendo al CLS.

Utilizzo quindi soltanto i pesi necessari e controllo che il carattere alternativo abbia proporzioni compatibili.

CSS che Blocca il Rendering

Prima di mostrare correttamente una pagina, il browser deve elaborare gli stili necessari.

Un sito WordPress può caricare file CSS provenienti da:

• tema principale;
• tema child;
• page builder;
• plugin di moduli;
• plugin e-commerce;
• slider;
• icone;
• strumenti di consenso;
• personalizzazioni aggiuntive.

Un singolo file può non essere particolarmente pesante. Il problema può derivare dalla quantità complessiva di richieste e dalla presenza di regole inutilizzate.

Prima di combinare o ritardare automaticamente i fogli di stile verifico quali risorse sono essenziali per la parte iniziale della pagina.

Una configurazione errata può causare pagine temporaneamente prive di stile oppure elementi che cambiano aspetto durante il caricamento.

JavaScript e Interaction to Next Paint

L’INP misura quanto tempo passa tra l’interazione dell’utente e la visualizzazione della risposta successiva.

Una pagina può apparire caricata, ma rispondere lentamente quando l’utente:

• apre il menu;
• seleziona un filtro;
• aggiunge un prodotto al carrello;
• invia un modulo;
• apre una finestra;
• cambia una scheda;
• utilizza una ricerca dinamica.

Il problema si verifica spesso quando il thread principale del browser è occupato da attività JavaScript lunghe.

L’interazione deve attendere che le operazioni già in esecuzione terminino prima di poter essere elaborata.

Cosa Può Peggiorare l’INP in WordPress

Tra le cause più frequenti considero:

• menu gestiti da script complessi;
• filtri e ricerche dinamiche;
• page builder con numerosi eventi;
• slider;
• chat e sistemi di assistenza;
• strumenti di tracciamento;
• script pubblicitari;
• cookie banner;
• validazioni pesanti nei moduli;
• aggiornamenti estesi del DOM;
• librerie caricate anche quando non servono.

Rinviare uno script non risolve necessariamente il problema. Può soltanto spostare la sua esecuzione al momento in cui l’utente sta già tentando di utilizzare la pagina.

Per migliorare l’INP è necessario individuare l’interazione lenta e analizzare quali operazioni vengono eseguite in quel momento.

Caricare gli Script Soltanto Dove Servono

Un plugin può aggiungere file JavaScript e CSS a tutte le pagine anche quando la propria funzione viene utilizzata soltanto in una sezione.

Durante lo sviluppo o l’ottimizzazione verifico se le risorse possano essere caricate in modo condizionale.

Una logica semplificata può essere:

Il principio non consiste nel copiare questa condizione in qualsiasi progetto, ma nel collegare ogni risorsa alle pagine che la utilizzano realmente.

Questo riduce il lavoro del browser e limita possibili conflitti.

I Plugin Non Rallentano Tutti allo Stesso Modo

Il numero totale dei plugin non è sufficiente per stabilire se un sito sia lento.

Un componente semplice che esegue poche operazioni può avere un impatto minimo. Un solo plugin complesso può invece caricare numerose risorse, effettuare query o comunicare con servizi esterni.

Per ogni plugin considero:

• codice eseguito nel frontend;
• query aggiunte;
• file CSS e JavaScript caricati;
• richieste esterne;
• attività programmate;
• funzioni utilizzate realmente;
• impatto nell’area amministrativa;
• possibilità di sostituzione.

Disattivare casualmente i plugin non è un metodo affidabile su un sito operativo. È preferibile analizzarli in un ambiente separato e confrontare il comportamento prima e dopo.

Servizi Esterni e Script di Terze Parti

Un sito può essere tecnicamente ottimizzato e continuare a caricarsi lentamente a causa di risorse provenienti da altri domini.

Tra gli esempi più comuni:

• statistiche;
• strumenti pubblicitari;
• mappe;
• video incorporati;
• chat;
• social widget;
• sistemi di recensioni;
• servizi di consenso;
• font esterni;
• strumenti di personalizzazione.

Il sito non controlla completamente il tempo di risposta e il comportamento di queste risorse.

Prima di mantenerle verifico quindi se siano realmente utilizzate, se possano essere caricate dopo un’interazione o se esista una soluzione più leggera.

Il Database Può Rallentare la Generazione della Pagina

WordPress utilizza il database per contenuti, impostazioni, utenti, metadati e configurazioni dei plugin.

Il database può diventare un problema quando:

• vengono eseguite troppe query;
• le query analizzano grandi quantità di dati;
• sono presenti metadati utilizzati male;
• le opzioni caricate automaticamente sono eccessive;
• plugin rimossi hanno lasciato molte tabelle;
• le ricerche non utilizzano indici adeguati;
• il server dispone di poche risorse;
• vengono generate pagine senza cache.

Eliminare revisioni o dati temporanei può ridurre la dimensione complessiva, ma non risolve automaticamente query inefficienti.

Prima di ripulire il database individuo quali operazioni incidono realmente sul tempo di risposta.

CLS: Perché gli Elementi si Spostano

Il Cumulative Layout Shift misura gli spostamenti imprevisti degli elementi visibili.

Un problema evidente si verifica quando l’utente sta leggendo o sta per selezionare un pulsante e il contenuto cambia improvvisamente posizione.

Tra le cause frequenti ci sono:

• immagini senza dimensioni;
• video e iframe senza spazio riservato;
• cookie banner inseriti sopra il contenuto;
• annunci caricati successivamente;
• font che cambiano dimensione;
• menu o barre superiori aggiunte dinamicamente;
• contenuti recuperati attraverso AJAX;
• slider con altezze differenti;
• messaggi amministrativi mostrati nel frontend.

La soluzione consiste spesso nel riservare anticipatamente lo spazio necessario e nel non inserire nuovi elementi sopra contenuti già visibili.

Cookie Banner e Stabilità del Layout

Il banner di consenso può influire sia sull’INP sia sul CLS.

Può peggiorare la stabilità quando viene inserito dopo che la pagina ha già iniziato a essere mostrata. Può rallentare le interazioni quando carica numerosi script o gestisce il blocco preventivo di servizi esterni.

Durante il controllo verifico:

• quando viene caricato;
• dove viene inserito;
• se sposta il contenuto;
• quali script blocca;
• quali servizi attiva dopo il consenso;
• come si comporta su smartphone.

Un sistema di consenso non dovrebbe essere valutato soltanto nella sua schermata di configurazione. Deve essere testato nel sito pubblico, con cache vuota e preferenze non ancora salvate.

Prestazioni su Smartphone

Un sito può funzionare bene su un computer recente e risultare lento su uno smartphone meno potente.

I dispositivi mobili possono avere:

• processori più lenti;
• meno memoria;
• connessioni instabili;
• latenza più elevata;
• schermi che richiedono layout differenti;
• browser con risorse limitate.

Il JavaScript che viene elaborato rapidamente su un computer può bloccare più a lungo il browser di uno smartphone.

Per questo motivo non considero sufficiente un test eseguito soltanto dal dispositivo utilizzato per sviluppare il sito.

Dati Reali e Test di Laboratorio

PageSpeed Insights può mostrare sia dati raccolti dagli utenti reali sia risultati prodotti da un test controllato.

I due gruppi di dati rispondono a domande differenti.

I dati reali aiutano a capire cosa hanno sperimentato gli utenti nel tempo. I test di laboratorio aiutano a riprodurre la pagina in condizioni definite e a individuare possibili cause.

Una pagina può ottenere un buon test di laboratorio e presentare dati reali insufficienti a causa di:

• utenti con dispositivi meno potenti;
• connessioni differenti;
• contenuti personalizzati;
• cookie banner;
• interazioni eseguite dopo il caricamento;
• pagine appartenenti allo stesso gruppo;
• variazioni introdotte nel tempo.

Al contrario, un singolo test lento non dimostra necessariamente che tutti gli utenti abbiano la stessa esperienza.

Perché il Punteggio PageSpeed Non È l’Unico Obiettivo

Il punteggio complessivo di Lighthouse è utile come indicazione diagnostica, ma non deve diventare l’unico obiettivo del progetto.

Raggiungere 100 non garantisce automaticamente:

• un buon posizionamento;
• un sito facile da utilizzare;
• contenuti utili;
• assenza di problemi per gli utenti reali;
• buoni risultati commerciali;
• stabilità dopo gli aggiornamenti.

Alcune modifiche applicate soltanto per aumentare il punteggio possono creare problemi funzionali, ritardare strumenti necessari o rendere instabile il layout.

L’obiettivo è migliorare l’esperienza reale e rimuovere i colli di bottiglia, non inseguire un numero isolato.

Un Plugin di Ottimizzazione Non Risolve Tutto

I plugin di ottimizzazione possono gestire cache, compressione, caricamento differito e riduzione delle risorse.

Non possono però correggere automaticamente:

• un hosting insufficiente;
• un tema strutturalmente pesante;
• query inefficienti;
• plugin che eseguono processi complessi;
• immagini scelte con dimensioni sbagliate;
• un’interfaccia amministrativa mal progettata;
• script esterni indispensabili;
• layout costruiti con troppi elementi.

Attivare contemporaneamente tutte le opzioni può inoltre causare conflitti, errori JavaScript o elementi visualizzati in ritardo.

Ogni funzione deve essere testata separatamente e verificata sulle pagine principali.

Un Esempio di Analisi su WordPress

Un sito aziendale può presentare un LCP elevato nella home page.

Un controllo superficiale potrebbe suggerire di comprimere tutte le immagini. L’analisi può invece mostrare che:

• l’immagine principale è già sufficientemente leggera;
• la risorsa viene inserita attraverso uno slider;
• lo slider viene inizializzato da JavaScript;
• il browser scopre l’immagine soltanto dopo il caricamento dello script;
• il tema carica più immagini per la stessa area;
• il server impiega molto tempo a generare la pagina.

In questa situazione una compressione ulteriore produce un beneficio limitato.

Può essere più efficace sostituire lo slider con un’immagine statica, rendere la risorsa immediatamente individuabile e migliorare la risposta iniziale del server.

Cosa Controllo Prima di Ottimizzare

Prima di modificare il sito seguo una sequenza precisa:

1. Controllo i dati reali disponibili.
2. Individuo la metrica insufficiente.
3. Verifico quali gruppi di pagine sono coinvolti.
4. Riproduco il problema in laboratorio.
5. Identifico l’elemento LCP, l’interazione lenta o lo spostamento.
6. Analizzo server, tema, plugin e risorse esterne.
7. Applico una modifica alla volta.
8. Confronto i risultati prima e dopo.
9. Controllo che il sito continui a funzionare correttamente.
10. Monitoro i dati dopo la pubblicazione.

Questa procedura evita di applicare ottimizzazioni generiche senza sapere quale problema debbano risolvere.

Stabilire le Priorità

Non tutti i problemi devono essere affrontati contemporaneamente.

Generalmente parto dagli interventi che incidono maggiormente:

• risposta del server;
• elemento LCP;
• risorse che bloccano il rendering;
• JavaScript che blocca le interazioni;
• spostamenti evidenti del layout;
• script esterni non necessari;
• risorse caricate globalmente.

Successivamente lavoro sulle ottimizzazioni minori.

Ridurre pochi kilobyte da un’icona ha un valore limitato se la pagina continua a caricare uno slider pesante, una chat, tre font e numerosi script pubblicitari.

Monitorare le Prestazioni Dopo gli Aggiornamenti

Le prestazioni non sono un risultato definitivo.

Possono cambiare dopo:

• aggiornamenti del tema;
• installazione di nuovi plugin;
• aggiunta di strumenti di tracciamento;
• modifiche al cookie banner;
• pubblicazione di nuove immagini;
• cambiamenti dell’hosting;
• aggiornamenti di WordPress;
• nuove funzionalità.

Una pagina ottimizzata oggi può peggiorare quando viene aggiunto un nuovo componente.

Per questo motivo considero il controllo delle prestazioni come un’attività periodica, soprattutto per le pagine che ricevono più traffico o generano contatti e vendite.

Cosa Rallenta Davvero un Sito WordPress

Non esiste una causa valida per tutti i progetti.

In alcuni siti il problema principale è il server. In altri è l’immagine iniziale, il tema, un page builder, uno script esterno o una funzione JavaScript eseguita durante le interazioni.

Il numero dei plugin, il peso totale della pagina e il punteggio ottenuto in un singolo test sono informazioni utili, ma non spiegano da sole il comportamento del sito.

I Core Web Vitals per WordPress devono quindi essere utilizzati come punto di partenza per individuare problemi concreti, non come un elenco di valori da migliorare attraverso impostazioni automatiche.

Un intervento efficace parte dai dati, identifica la risorsa responsabile e applica una modifica proporzionata senza compromettere contenuti e funzionalità.

L’obiettivo finale non è soltanto ottenere un risultato migliore negli strumenti di test, ma rendere il sito più rapido, stabile e reattivo per le persone che lo utilizzano realmente.