Ottimizzare le Performance WordPress: Guida Core Web Vitals per Agenzie

Le performance di un sito WordPress non sono più un dettaglio tecnico: sono un fattore di business diretto. Google usa i Core Web Vitals come segnale di ranking dal 2021, e i dati raccolti negli anni successivi confermano la correlazione tra velocità di caricamento e conversioni. Per un’agenzia WordPress che gestisce i siti dei propri clienti, ignorare le performance significa esporre i clienti a perdite di traffico organico, aumenti del bounce rate e una percezione negativa del servizio ricevuto.

Questa guida copre tutto il necessario per ottimizzare le performance WordPress in modo sistematico: dalla comprensione tecnica dei Core Web Vitals, agli interventi concreti su LCP, INP e CLS, fino all’architettura di caching e al monitoraggio continuativo. Ogni sezione è autonoma e operativa, pensata per chi gestisce una media di dieci o più siti WordPress per conto dei propri clienti.

Core Web Vitals Spiegati: LCP, INP e CLS

I Core Web Vitals sono tre metriche definite da Google per misurare l’esperienza utente percepita su una pagina web. Non misurano la velocità “tecnica” del server, ma la velocità percepita dall’utente: quanto presto vede contenuto utile, quanto velocemente risponde il sito ai suoi gesti, quanto si sposta il layout mentre la pagina si carica.

Largest Contentful Paint (LCP)

LCP misura il tempo necessario affinché l’elemento di contenuto più grande visibile nella viewport venga renderizzato. In pratica, misura quando l’utente vede “la cosa principale” della pagina: spesso un’immagine hero, un titolo H1 di grandi dimensioni o un blocco di testo prominente.

Interaction to Next Paint (INP)

INP ha sostituito FID (First Input Delay) a marzo 2024. Misura la latenza complessiva di tutte le interazioni dell’utente con la pagina durante l’intera visita — click, tap, pressioni di tasti — e riporta il valore peggiore (escludendo outlier statistici). Un INP alto significa che il sito sembra “lento” o “bloccato” quando l’utente interagisce.

Cumulative Layout Shift (CLS)

CLS misura la stabilità visiva della pagina: quanto si sposta il contenuto in modo inatteso durante il caricamento. Un banner pubblicitario che compare e sposta il testo verso il basso, un font che cambia dimensione quando viene caricato, un’immagine senza dimensioni definite: tutto contribuisce a un CLS elevato.

Soglie di valutazione Google

Google considera un sito con “buon punteggio” quello in cui almeno il 75° percentile delle visite supera la soglia verde per tutte e tre le metriche. Questo dettaglio è importante: non basta che il sito vada bene in condizioni ideali, deve andare bene anche per gli utenti con connessione lenta o dispositivi meno performanti.

Diagnosi: Come Identificare i Problemi di Performance

Prima di intervenire, è necessario capire dove si trova il problema. Esistono strumenti diversi, ognuno con un angolo prospettico differente.

PageSpeed Insights

PageSpeed Insights (PSI) di Google è il punto di partenza obbligatorio. Combina dati di laboratorio (Lighthouse, eseguito su macchina controllata) con dati di campo (Chrome User Experience Report, dati reali degli utenti Chrome). I dati di campo sono quelli che contano per il ranking: riflettono le condizioni reali di utilizzo.

URL: https://pagespeed.web.dev/

Da controllare subito: il report “Opportunità” nella sezione laboratorio, e i dati CrUX nella sezione campo. Se i dati di campo non sono disponibili, significa che il sito ha troppo poco traffico per avere un campione statistico significativo — in quel caso, i dati di laboratorio sono l’unico riferimento.

Lighthouse in Chrome DevTools

Lighthouse è integrabile direttamente nel browser via DevTools (tab Lighthouse). Permette di eseguire audit in modalità mobile o desktop, con throttling della connessione simulato. Utile per testare localmente le modifiche senza attendere che Google aggiorni i dati PSI.

Importante: i risultati Lighthouse variano tra un’esecuzione e l’altra. Eseguire almeno tre audit e considerare la mediana, non il valore migliore.

WebPageTest

WebPageTest (webpagetest.org) offre test da server fisici in diverse location geografiche, su browser reali. Fornisce filmstrip visuale del caricamento, waterfall delle richieste di rete e metriche avanzate come Time to First Byte (TTFB) e Start Render. Indispensabile per diagnosticare problemi legati all’hosting o alla geografia degli utenti.

Chrome DevTools — Performance e Network

Per diagnosi approfondite, il tab Performance di Chrome DevTools registra ogni attività del browser durante il caricamento: rendering, scripting, layout, painting. Il tab Network mostra ogni richiesta HTTP con timing dettagliato. Questi strumenti sono essenziali per identificare script bloccanti, richieste lente a terze parti e colli di bottiglia specifici.

Ottimizzazione LCP: Immagini, Font e Server Response Time

LCP è spesso la metrica più difficile da migliorare perché dipende da più fattori concatenati: la velocità del server, il peso delle risorse critiche e come il browser le scopre e le carica.

Ottimizzazione delle immagini

Le immagini sono la causa principale di LCP elevato nei siti WordPress. Un’immagine hero da 2 MB non compressa può da sola portare LCP a 5-6 secondi su una connessione mobile.

Formato moderno (WebP e AVIF): WordPress 5.8+ supporta WebP nativamente. AVIF offre compressione superiore ma supporto browser ancora parziale. La strategia corretta è servire AVIF con fallback WebP e JPEG via elemento :

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Descrizione" width="1200" height="630" loading="eager" fetchpriority="high">
</picture>

Attributo fetchpriority="high" sull’immagine LCP: questo dice al browser di scaricare quella risorsa con priorità massima, riducendo il tempo di scoperta e download. È uno degli interventi con il miglior rapporto impegno/risultato.

Lazy loading selettivo: loading="lazy" va applicato a tutte le immagini tranne quelle visibili al caricamento iniziale (above the fold). Applicarlo all’immagine LCP è un errore comune che aumenta drasticamente l’LCP.

Dimensioni esplicite: ogni deve avere gli attributi width e height corrispondenti alle dimensioni di rendering. Questo permette al browser di riservare lo spazio prima del download, contribuendo anche a migliorare il CLS.

Font web e font-display

I font web bloccano il rendering del testo se non vengono caricati prima che il browser li necessiti. La proprietà font-display controlla questo comportamento:

@font-face {
  font-family: 'MioFont';
  src: url('/fonts/miofont.woff2') format('woff2');
  font-display: swap; /* mostra il testo con font di sistema mentre il custom carica */
}

font-display: swap è il valore raccomandato: mostra subito il testo con un font di fallback, poi lo sostituisce quando il font custom è pronto. Questo elimina il problema del testo invisibile (FOIT) che contribuisce all’LCP elevato.

Per i font di Google Fonts, aggiungere il parametro &display=swap all’URL di import.

TTFB: Time to First Byte

Un TTFB elevato — sopra i 600ms — è spesso il collo di bottiglia principale per l’LCP. Le cause più comuni su WordPress:

• PHP senza OPcache: ogni richiesta ricompila i file PHP da zero. OPcache mantiene il bytecode compilato in memoria, riducendo i tempi di esecuzione PHP dell’80-90%.
• Hosting condiviso sovraccarico: su hosting condiviso, il numero di siti sullo stesso server crea contesa di risorse. Un server dedicato o VPS con PHP-FPM è la soluzione.
• Query database non ottimizzate: una homepage con venti widget che eseguono ognuno query separate può generare decine di query sul database. Il caching risolve questo, come dettagliato nella sezione dedicata.
• Assenza di CDN: per siti con utenti in diverse zone geografiche, servire asset statici da un CDN riduce la latenza in modo significativo.

Ottimizzazione INP: JavaScript e Interattività

INP elevato è quasi sempre causato da JavaScript eccessivo o mal gestito. Il browser ha un singolo thread principale: se è occupato a eseguire JavaScript, non può rispondere alle interazioni dell’utente.

Script di terze parti

I plugin WordPress caricano spesso script di terze parti: analytics, chat live, heatmap, widget social, pixel pubblicitari. Ognuno di questi script aggiunge latenza e può bloccare il thread principale.

Audit degli script presenti: aprire il tab Network in Chrome DevTools, filtrare per JS, e identificare le richieste verso domini esterni. Per ogni script, valutare se è realmente necessario su quella pagina.

Caricare script in differita: gli script non critici devono essere caricati con defer o async:

// In functions.php di WordPress
function my_theme_scripts() {
    wp_enqueue_script(
        'analytics-script',
        'https://cdn.example.com/analytics.js',
        [],
        null,
        ['strategy' => 'defer'] // WordPress 6.3+ supporta strategy
    );
}
add_action('wp_enqueue_scripts', 'my_theme_scripts');

Per WordPress < 6.3, aggiungere l'attributo manualmente:

function add_defer_to_scripts($tag, $handle, $src) {
    $defer_handles = ['analytics-script', 'chat-widget'];
    if (in_array($handle, $defer_handles)) {
        return '<script defer src="' . esc_url($src) . '"></script>';
    }
    return $tag;
}
add_filter('script_loader_tag', 'add_defer_to_scripts', 10, 3);

Code splitting e caricamento condizionale

Non tutti gli script devono essere caricati su tutte le pagine. Un plugin di prenotazione appuntamenti non deve caricare i suoi 200KB di JavaScript sulla homepage o sulle pagine blog.

// Carica script solo sulle pagine che ne hanno bisogno
function my_booking_scripts() {
    if (is_page('prenota') || is_page('contatti')) {
        wp_enqueue_script('booking-script', '/assets/booking.js', [], '1.0', true);
    }
}
add_action('wp_enqueue_scripts', 'my_booking_scripts');

Ridurre il Long Tasks

Un Long Task è un’operazione JavaScript che blocca il thread principale per più di 50ms. Chrome DevTools li evidenzia in rosso nel tab Performance. Le cause comuni includono librerie animate, parser JSON su dati grandi, e cicli di rendering inefficienti in custom JavaScript.

Per ogni Long Task identificato, valutare se il codice può essere spostato in un Web Worker o suddiviso in task più piccoli tramite scheduler.yield() (API moderna) o setTimeout(fn, 0) (fallback compatibile).

Ottimizzazione CLS: Stabilità del Layout

Il CLS peggiora quando il browser non conosce le dimensioni di un elemento prima di scaricarlo. La soluzione è quasi sempre dichiarare esplicitamente le dimensioni in anticipo.

Immagini e media con dimensioni esplicite

Come già menzionato per l’LCP, ogni immagine deve avere width e height. In WordPress, la funzione wp_get_attachment_image() li include automaticamente. Per immagini responsive, usare aspect-ratio nel CSS:

.post-thumbnail {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  overflow: hidden;
}

Questo approccio riserva lo spazio corretto nel layout anche prima che l’immagine venga scaricata.

Iframe e embed

I video YouTube, le mappe Google Maps e gli iframe in generale non hanno dimensioni implicite. Il container deve avere dimensioni fisse o usare il padding-top trick per il responsive:

.video-wrapper {
  position: relative;
  padding-top: 56.25%; /* 16:9 */
  height: 0;
  overflow: hidden;
}

.video-wrapper iframe {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

Font e FOUT controllato

Il Flash of Unstyled Text (FOUT) — il momento in cui il testo cambia font — contribuisce al CLS se le dimensioni del font di fallback differiscono molto da quelle del font finale. La proprietà size-adjust in @font-face permette di calibrare il font di sistema per minimizzare il layout shift:

@font-face {
  font-family: 'FallbackFont';
  src: local('Arial');
  ascent-override: 90%;
  descent-override: 10%;
  size-adjust: 108%;
}

Questo è un intervento avanzato, ma può ridurre il CLS causato dai font dallo 0,05 allo 0,02 o meno.

Banner e contenuti dinamici

I banner che compaiono dopo il caricamento (cookie consent, notifiche, chat bubble) sono cause frequenti di CLS alto. La soluzione è riservare lo spazio fisico nel layout prima che l’elemento venga reso visibile, oppure usare posizionamento fisso/sticky che non influisce sul flusso del documento.

Caching e CDN: Architettura per WordPress

Il caching è la leva più potente per migliorare le performance WordPress in modo trasversale. Riducendo il numero di operazioni PHP e query database necessarie a generare una pagina, il caching abbassa simultaneamente TTFB, LCP e carico del server.

Page cache

La page cache salva l’output HTML completo di ogni pagina e lo serve direttamente senza eseguire PHP o interrogare il database. Per siti WordPress statici o con aggiornamenti infrequenti, è la singola ottimizzazione con il maggiore impatto.

Plugin consigliati: WP Rocket (commerciale, configurazione minimale), W3 Total Cache (gratuito, configurazione più complessa), LiteSpeed Cache (se l’hosting usa LiteSpeed Web Server — gratis e performante).

Regola fondamentale: non cachare le pagine degli utenti autenticati, i checkout WooCommerce, e le pagine con contenuto personalizzato.

Object cache con Redis

La object cache conserva in memoria i risultati delle query database e le chiamate API costose. WordPress ha una object cache nativa in-memory, ma viene svuotata a ogni richiesta. Redis o Memcached persistono questa cache tra le richieste.

Per abilitare Redis come persistent object cache:

// wp-config.php
define('WP_CACHE_KEY_SALT', 'miosito_');
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

Con il plugin Redis Object Cache (gratuito su WordPress.org), ogni transient, query WP_Query e risultato get_option viene mantenuto in Redis fino alla scadenza configurata. Su siti con molti widget e query complesse, Redis può ridurre il TTFB del 40-60%.

Browser cache e header HTTP

I browser salvano le risorse statiche localmente se il server dichiara i corretti header HTTP. In .htaccess per server Apache:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType application/x-font-woff2 "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(webp|avif|jpg|jpeg|png|gif|svg|ico|woff2)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  <FilesMatch "\.(css|js)$">
    Header set Cache-Control "public, max-age=2592000"
  </FilesMatch>
</IfModule>

Per siti versionati (file CSS e JS con hash nel nome), il max-age di un anno è sicuro: quando il file cambia, cambia anche il nome, forzando il browser a scaricarlo di nuovo.

CDN: Cloudflare e Bunny.net

Un CDN distribuisce le risorse statiche su server edge in diverse location geografiche. Per un sito italiano con utenti principalmente italiani, il beneficio è limitato per i file statici, ma significativo per la compressione, l’HTTP/3 e la protezione DDoS.

Cloudflare (piano free) offre: CDN per risorse statiche, minificazione automatica di CSS e JS, compressione Brotli e gzip, HTTP/3 con QUIC. Configurazione: basta puntare i nameserver del dominio a Cloudflare.

Bunny.net è una scelta eccellente per siti con media pesanti (portfolio fotografici, siti e-commerce con molte immagini): offre storage CDN dedicato con prezzi molto competitivi e pull zone configurabile su WordPress in pochi minuti.

Database e Backend: Ottimizzazioni Server-Side

Le performance front-end dipendono dalla qualità del back-end. Un database mal ottimizzato o un PHP non configurato correttamente rendono inutili tutti gli interventi precedenti una volta che la cache si svuota.

Pulizia e ottimizzazione del database

WordPress accumula nel tempo dati obsoleti che appesantiscono le query:

• Revisioni dei post: WordPress salva ogni bozza di ogni post. Su siti con molti contenuti, si accumulano migliaia di righe.
• Transient scaduti: la tabella wp_options accumula transient scaduti che non vengono eliminati automaticamente in modo affidabile.
• Sessioni e commenti spam: dati che occupano spazio e rallentano le query.

Limitare le revisioni in wp-config.php:

define('WP_POST_REVISIONS', 3); // mantieni solo 3 revisioni per post
define('AUTOSAVE_INTERVAL', 300); // autosalvataggio ogni 5 minuti invece di 1

Pulizia periodica dei transient scaduti con WP-Cron:

function cleanup_expired_transients() {
    global $wpdb;
    $wpdb->query(
        "DELETE FROM {$wpdb->options}
         WHERE option_name LIKE '_transient_timeout_%'
         AND option_value < UNIX_TIMESTAMP()"
    );
    $wpdb->query(
        "DELETE FROM {$wpdb->options}
         WHERE option_name LIKE '_transient_%'
         AND option_name NOT LIKE '_transient_timeout_%'
         AND REPLACE(option_name, '_transient_', '_transient_timeout_')
         NOT IN (SELECT option_name FROM {$wpdb->options})"
    );
}
add_action('weekly_transient_cleanup', 'cleanup_expired_transients');

if (!wp_next_scheduled('weekly_transient_cleanup')) {
    wp_schedule_event(time(), 'weekly', 'weekly_transient_cleanup');
}

Autoload options: un problema sottovalutato

Ogni opzione in wp_options con autoload = yes viene caricata a ogni richiesta WordPress, indipendentemente che venga usata. Plugin abbandonati o mal sviluppati lasciano spesso centinaia di opzioni autoloaded.

Query per identificare il problema:

SELECT
  COUNT(*) AS total_options,
  SUM(LENGTH(option_value)) / 1024 AS total_size_kb
FROM wp_options
WHERE autoload = 'yes';

Se il risultato supera i 500KB di dati autoloaded, vale la pena identificare le opzioni più pesanti:

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;

Le opzioni dei plugin non più attivi possono essere disabilitate dall’autoload o eliminate direttamente.

PHP OPcache: configurazione corretta

OPcache è attivo su quasi tutti gli hosting moderni, ma spesso con configurazione di default non ottimale. Aggiungere o verificare queste direttive in php.ini:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.save_comments=1
opcache.fast_shutdown=1

memory_consumption=256 (MB) è adeguato per la maggior parte dei siti WordPress. Su hosting condiviso, il valore potrebbe essere limitato dall’host.

Monitorare le Performance nel Tempo

Ottimizzare le performance una volta sola non basta. Un aggiornamento di plugin può introdurre un nuovo script pesante. Un cambiamento di template può aggiungere un’immagine senza dimensioni esplicite. Un nuovo widget in sidebar può portare il TTFB da 200ms a 800ms.

Il monitoraggio continuativo è la differenza tra un’agenzia che mantiene i risultati nel tempo e una che deve ripetere lo stesso lavoro ogni sei mesi.

Cosa monitorare regolarmente

• CWV da campo (CrUX): i dati Google Search Console > Core Web Vitals mostrano l’andamento reale nel tempo per dispositivo. Va controllato mensilmente.
• PageSpeed Score su pagine chiave: homepage, pagina contatti, pagina prodotto principale (per siti e-commerce). Non basta monitorare la homepage.
• TTFB e uptime: un TTFB che peggiora gradualmente indica un database che si riempie, un server sovraccarico o una cache che non funziona correttamente.
• Dimensione pagina e numero di richieste HTTP: metriche che tendono a crescere nel tempo con ogni plugin aggiunto.

Frequenza raccomandata per le agenzie

Come AgencyPilot Monitora le Performance per Te

Eseguire manualmente questi controlli su un singolo sito richiede dai 30 ai 60 minuti. Su venti siti clienti, il tempo esplode rapidamente: due ore a settimana solo per i controlli PageSpeed, senza considerare l’analisi e l’eventuale intervento.

AgencyPilot automatizza il monitoraggio delle performance WordPress per tutte le proprietà dei tuoi clienti da un’unica dashboard. Il sistema esegue audit PageSpeed automatici con cadenza configurabile — giornaliera, settimanale o mensile — su tutte le pagine chiave che definisci per ogni sito.

Quando un sito scende sotto la soglia di Performance Score che hai configurato (ad esempio, PSI < 70), AgencyPilot invia un alert immediato via email o webhook, con il dettaglio delle metriche che sono peggiorate e la variazione rispetto all'ultima misurazione. Non devi più controllare manualmente: ricevi una notifica solo quando qualcosa ha bisogno della tua attenzione.

Ogni misura PageSpeed viene storicizzata e inclusa automaticamente nei report mensili per i clienti. Il cliente vede l’andamento nel tempo del proprio sito — velocità, Core Web Vitals, punteggio mobile vs desktop — senza che tu debba assemblare dati da fonti diverse.

Questo si integra con tutto il resto della gestione siti WordPress per agenzie: uptime monitoring, aggiornamenti automatici, backup e report AI in un’unica piattaforma. Il risultato è una riduzione del tempo operativo dell’agenzia e una comunicazione del valore verso il cliente molto più efficace.

Conclusioni

Ottimizzare le performance WordPress non è un’operazione una tantum: è un processo continuativo che richiede diagnosi accurata, interventi mirati e monitoraggio sistematico.

I punti chiave da ricordare:

• LCP si migliora ottimizzando immagini (WebP/AVIF, fetchpriority="high"), gestendo correttamente i font (font-display: swap) e riducendo il TTFB con caching e OPcache.
• INP richiede di auditare e differire gli script JavaScript di terze parti, caricare in modo condizionale i plugin pesanti e identificare i Long Tasks nel thread principale.
• CLS si risolve dichiarando dimensioni esplicite per immagini e iframe, usando aspect-ratio nel CSS e calibrando il fallback dei font.
• Caching — page cache, Redis object cache, header browser e CDN — è la leva con il maggior impatto trasversale su tutte le metriche.
• Database e PHP vanno ottimizzati a monte: OPcache configurato correttamente, autoload options sotto controllo, revisioni limitate.
• Monitoraggio continuativo è l’unico modo per mantenere i risultati nel tempo senza rieseguire tutto da capo ogni semestre.

Per un’agenzia che gestisce decine di siti WordPress, la scalabilità di questo processo dipende dagli strumenti. Eseguire audit manuali su ogni sito ogni settimana non è sostenibile. Automatizzare il monitoraggio e delegare la reportistica a una piattaforma dedicata libera il tempo tecnico per il lavoro ad alto valore: l’intervento, non il controllo.

FAQ

Come migliorare il Core Web Vitals di un sito WordPress?
Le azioni più impattanti per ogni metrica sono: per LCP (Largest Contentful Paint), ottimizza le immagini hero con lazy load escluso sul primo elemento visibile, usa un CDN e abilita il preload dei font. Per INP (Interaction to Next Paint, ex FID), riduci il JavaScript bloccante e usa il defer su script non critici. Per CLS (Cumulative Layout Shift), specifica sempre width e height sugli elementi immagine e evita l’inserimento dinamico di contenuto sopra il fold.

Qual è il plugin di caching migliore per WordPress?
WP Rocket è il più completo ed efficace ma è a pagamento. Per soluzioni gratuite, LiteSpeed Cache è eccellente se il server usa LiteSpeed (molto comune in hosting italiani come Aruba e SiteGround). W3 Total Cache è potente ma complesso da configurare. WP Fastest Cache è la scelta più semplice per chi non vuole configurazioni avanzate. La scelta dipende dall’hosting: usa il plugin ottimizzato per il tuo stack server.

Come ottimizzare le immagini in WordPress per le performance?
Tre passaggi fondamentali: converti le immagini in formato WebP (supportato da tutti i browser moderni), comprimile prima dell’upload con strumenti come Squoosh o plugin come Imagify, e abilita il lazy loading nativo con l’attributo loading=”lazy” su tutte le immagini eccetto quella above-the-fold principale. Per siti con molte immagini, un CDN per le immagini (Cloudflare Images, Bunny CDN) riduce il TTFB in modo significativo.

Come misurare le performance WordPress prima e dopo le ottimizzazioni?
Usa PageSpeed Insights di Google per il punteggio Core Web Vitals su dati reali (CrUX) e simulati. GTmetrix fornisce una analisi waterfall dettagliata per identificare le risorse più lente. WebPageTest permette test da location geografiche specifiche e su connessioni simulate (3G, 4G). Per il monitoraggio continuo in produzione, Google Search Console mostra i Core Web Vitals aggregati per URL nelle ultime 28 giorni.