Come Controllare i Tuoi Core Web Vitals in AmICited

Pagine veloci e stabili contano anche per la visibilità AI — i motori di risposta privilegiano le fonti a caricamento rapido. Prima di addentrarti nell’audit di AmICited, è utile capire cosa misurano realmente i Core Web Vitals e perché un problema di velocità della pagina possa trasformarsi silenziosamente in un problema di citazioni AI.

Cosa sono i Core Web Vitals?

I Core Web Vitals sono un insieme di metriche standardizzate create da Google per quantificare la page experience nel mondo reale: quanto velocemente appare il contenuto principale di una pagina, quanto rapidamente risponde all’interazione dell’utente e quanto rimane visivamente stabile durante il caricamento. Sono state progettate per sostituire vaghe percezioni del tipo “il sito sembra lento” con numeri che è possibile monitorare, confrontare e su cui responsabilizzare i team di ingegneria. Google li ha integrati nei propri segnali di ranking di ricerca già da anni, e gli stessi dati di fondo — raccolti da utenti Chrome reali tramite il Chrome UX Report (CrUX) — influenzano sempre più quali fonti i motori di risposta sono disposti a recuperare, renderizzare e citare.

Le tre metriche principali sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS), ciascuna associata a una soglia di superamento/non superamento che Google pubblica e aggiorna periodicamente. Due metriche di supporto, First Contentful Paint (FCP) e Time to First Byte (TTFB), completano il quadro della velocità della pagina isolando quanto velocemente risponde il server e quanto velocemente qualcosa viene renderizzato, ancora prima che il contenuto principale sia pronto. Poiché CrUX è costruito su dati di campo anonimizzati — visite reali di utenti Chrome reali — i numeri riflettono condizioni effettive (mix di dispositivi, qualità della rete, geografia) piuttosto che un singolo test di laboratorio eseguito su una veloce connessione da ufficio.

Perché tutto questo è rilevante in particolare per la generative engine optimization ? I crawler AI e i sistemi di retrieval dietro AI Overviews, la ricerca di ChatGPT e Perplexity devono recuperare e analizzare la tua pagina prima di poterla citare. Una pagina che va in timeout, si carica lentamente o sposta il contenuto durante il caricamento è più costosa da scansionare su larga scala e meno affidabile da cui estrarre contenuto pulito. Un TTFB lento in particolare può indurre un crawler ad abbandonare una richiesta prima ancora che il tuo contenuto principale arrivi. Nulla di tutto questo è il fattore dominante per ottenere una citazione — la rilevanza del contenuto, l’autorevolezza e la struttura contano molto di più — ma una homepage cronicamente lenta o instabile è un attrito che i motori di risposta non hanno motivo di tollerare quando un concorrente più veloce offre la stessa informazione.

Questo è anche un caso in cui la SEO tecnica e l’answer engine optimization si sovrappongono quasi completamente: gli stessi interventi di ingegneria che migliorano il tuo posizionamento su Google — dimensionamento delle immagini, tempo di risposta del server, stabilità del layout — sono quelli che mantengono le tue pagine accessibili e citabili dai sistemi AI. Questa sovrapposizione è esattamente il motivo per cui AmICited presenta i Core Web Vitals all’interno di un audit di visibilità AI più ampio, anziché come strumento SEO a sé stante: è uno dei tanti fattori che determinano se i motori AI considerano il tuo sito affidabile e facile da lavorare.

Dove trovarlo

Apri Audit → Web Vitals dalla navigazione a sinistra. La pagina lo spiega chiaramente: “Core Web Vitals per la homepage del tuo dominio… la velocità della pagina è un fattore di ranking di Google e i motori di risposta AI privilegiano le pagine a caricamento rapido.” AmICited recupera automaticamente questi dati per il tuo dominio monitorato e per ogni concorrente che stai seguendo, così non devi usare uno strumento separato né incollare manualmente gli URL — è lo stesso set competitivo che stai già utilizzando per monitorare share of voice e citation rank altrove nella piattaforma.

Poiché CrUX richiede un volume minimo di traffico Chrome reale prima di pubblicare numeri stabili per un URL, i domini con poco traffico — inclusi molti siti B2B e di nicchia — a volte mostreranno valori vuoti per un certo periodo. Si tratta di un comportamento previsto, non di un bug: significa che Google non ha ancora accumulato dati di campo sufficienti per riportare valori affidabili, e i dati si popoleranno man mano che il traffico (o il tempo) si accumula.

Cosa significano le metriche

La tabella di confronto tra concorrenti elenca ogni dominio con:

• Score — un riepilogo complessivo superato/non superato dei Core Web Vitals, che ti offre un colpo d’occhio su se un dominio supera o meno le soglie di Google su tutti i fronti.
• LCP (Largest Contentful Paint) — quanto velocemente si carica il contenuto principale, in genere l’immagine o il blocco di testo più grande nel viewport. È la metrica più direttamente legata alla percezione — di un visitatore o di un crawler — che “questa pagina è pronta”.
• INP (Interaction to Next Paint) — quanto è reattiva la pagina quando un utente interagisce effettivamente con essa (clic, tap, digitazione). Ha sostituito la vecchia metrica First Input Delay perché cattura la reattività durante l’intera visita alla pagina, non solo alla prima interazione.
• CLS (Cumulative Layout Shift) — quanto è visivamente stabile la pagina durante il caricamento. Un CLS alto significa che gli elementi si spostano mentre immagini, annunci o font vengono caricati, il che è fastidioso per i visitatori e può rendere il contenuto più difficile da analizzare in modo coerente per i sistemi automatizzati.
• FCP (First Contentful Paint) — quanto velocemente qualcosa appare per la prima volta sullo schermo, ancora prima che il contenuto principale sia pronto. È un segnale precoce che la pagina si sta effettivamente caricando, invece di restare su uno schermo vuoto.
• TTFB (Time to First Byte) — la velocità di risposta del server: il tempo che intercorre tra la richiesta della pagina e la ricezione del primo byte di risposta. È una metrica quasi interamente legata al backend/infrastruttura, ed è spesso la più semplice da correggere con interventi su hosting, caching o CDN.

Il tuo dominio è contrassegnato come You, con le homepage dei tuoi concorrenti monitorati elencate sotto, così ogni metrica viene immediatamente confrontata anziché essere osservata isolatamente.

Come usarlo

1. Confrontati con i rivali. Se le pagine dei concorrenti sono più veloci, si tratta di un ulteriore vantaggio che hanno sia nella ricerca sia nelle risposte AI — e di un divario economico da colmare rispetto al lavoro su contenuti o autorevolezza.
2. Correggi i valori in rosso. Un LCP o un CLS insufficiente indica interventi tecnici specifici: immagini hero sovradimensionate, attributi width/height mancanti, script che bloccano il rendering o font web non ottimizzati sono le cause più comuni.
3. Dai priorità al TTFB se è lento. Poiché si trova a monte di ogni altra metrica, un TTFB lento trascina in basso anche l’LCP, ed è spesso la metrica più veloce da migliorare — spesso tramite caching, una CDN o un upgrade dell’hosting, piuttosto che una riscrittura dei contenuti.
4. Ricontrolla dopo le modifiche. Man mano che i dati sul campo si aggiornano, torna a verificare che i miglioramenti siano stati effettivi. I dati CrUX rappresentano una finestra mobile di 28 giorni, quindi le modifiche impiegano tempo a riflettersi nei numeri — non aspettarti che cambino il giorno dopo un deploy.
5. Considera il TTFB come un segnale di allarme precoce. Un server che impiega regolarmente più di un secondo per restituire il primo byte è un forte candidato ad avere problemi di scansione e rendering ben oltre questo singolo audit — vale la pena approfondire perché gli ingegneri dei crawler considerano sempre più un TTFB veloce come soglia per il successo dei crawler AI piuttosto che un semplice vantaggio accessorio.

Nessuna di queste quattro metriche opera isolata dal resto della tua impronta tecnica. Una homepage che ottiene un buon punteggio sui Core Web Vitals ma blocca i crawler AI nel robots.txt, o serve una pagina prevalentemente vuota ai client senza JavaScript, non verrà comunque citata — la velocità aiuta solo una volta che un crawler è effettivamente autorizzato a entrare e può analizzare ciò che trova. Ecco perché conviene trattare questo audit come un checkpoint all’interno di una routine più ampia, piuttosto che come una correzione una tantum: eseguilo insieme agli altri audit di AmICited con cadenza regolare, allo stesso modo in cui rivisiteresti periodicamente una checklist di audit tecnico più ampia che copra crawlability, dati strutturati ed estraibilità dei contenuti.

I Web Vitals da soli non ti faranno ottenere citazioni, ma pagine lente e instabili possono frenarti — questo audit ti dice a che punto sei rispetto ai siti tra cui i motori AI stanno scegliendo. Se vuoi approfondire la ricerca alla base di questo consiglio, leggi se la velocità della pagina influisce davvero sulla visibilità nella ricerca AI , e abbina questo controllo a un più ampio audit di accessibilità AI del tuo sito per coprire il lato della crawlability. Da qui, il passo successivo naturale è integrare i Web Vitals nella tua cadenza di monitoraggio regolare insieme all’AI rank tracker di AmICited e al tracciamento delle citazioni, così un regresso delle prestazioni viene individuato nello stesso momento in cui noteresti un calo delle menzioni — invece di essere scoperto separatamente, settimane dopo, quando ha già avuto un costo in termini di visibilità.