Core Web Vitals e Latenza: Le Pagine Più Veloci Ottengono Più Citazioni AI?

Core Web Vitals e Latenza: Le Pagine Più Veloci Ottengono Più Citazioni di Intelligenza Artificiale?

Introduzione

Un sito web veloce è più facile da usare per le persone. Potrebbe anche essere più facile da recuperare, renderizzare e comprendere per i motori di ricerca e i sistemi di intelligenza artificiale.

Ma una distinzione importante viene spesso trascurata:

Una pagina più veloce può migliorare il crawling e la disponibilità dei contenuti. Questo non significa che la sola velocità induca un sistema di intelligenza artificiale a citare la pagina.

A partire dal 2 agosto 2026, Google afferma che tempi di risposta del server stabili e una minore latenza possono aumentare la capacità di crawling di un sito. Google afferma inoltre che le sue funzionalità di ricerca basate sull'intelligenza artificiale utilizzano gli stessi sistemi di ricerca e indicizzazione di base della ricerca tradizionale e non richiedono markup speciali per l'intelligenza artificiale o ottimizzazioni della velocità. (developers.google.com)

Questo articolo presenta un piano di test basato sull'evidenza anziché affermare che un esperimento completo sia già stato eseguito. Non sono stati forniti siti, set di pagine, log del server o dataset di citazioni. L'obiettivo è definire uno studio controllato in grado di misurare:

1. Se un time to first byte inferiore aumenta la frequenza di crawling.
2. Se un Largest Contentful Paint inferiore migliora la scoperta o l'indicizzazione.
3. Se un Cumulative Layout Shift inferiore influisce sul crawling o sul recupero da parte dell'intelligenza artificiale.
4. Se i miglioramenti delle prestazioni aumentano la frequenza con cui le pagine vengono visibilmente citate dai sistemi di ricerca basati sull'intelligenza artificiale.

La Risposta Breve

Un time to first byte inferiore può migliorare il crawling nelle giuste condizioni

La documentazione attuale sul crawling di Google afferma che il limite della sua capacità di crawling può aumentare quando un sito ha tempi di risposta stabili o in miglioramento, incluso il time to first byte. Se i tempi di risposta aumentano, o se un sito restituisce troppi errori del server o risposte di rate-limit, Google potrebbe ridurre il crawling. (developers.google.com)

Tuttavia, un tempo di risposta più veloce non garantisce più crawling. La domanda di crawling dipende anche da fattori quali:

• Quante volte il sito cambia.
• Quanto sono popolari il sito e le sue pagine.
• Se il contenuto è utile e unico.
• Quante URL duplicate o di basso valore esistono.
• Se le URL aggiornate sono incluse nelle sitemap.

Ciò significa che una minore latenza dovrebbe avere l'effetto più forte sui siti web grandi, frequentemente aggiornati o con vincoli del server, non necessariamente su un sito piccolo con contenuti nuovi limitati.

Un Largest Contentful Paint inferiore può aiutare indirettamente

Largest Contentful Paint misura quando il contenuto visibile principale appare a un utente. Google afferma inoltre che sia il tempo di risposta del server sia il tempo necessario per il rendering delle pagine e delle risorse incorporate possono influenzare l'efficienza del crawling. (developers.google.com)

La relazione probabile è indiretta:

Minore latenza → consegna più veloce delle risorse → rendering o recupero più efficiente → meno timeout di crawling o recuperi incompleti.

L'effetto dovrebbe essere più forte quando il contenuto importante dipende da:

• JavaScript lento.
• Immagini grandi.
• Fogli di stile che bloccano il rendering.
• Rendering lato client.
• Risorse incorporate pesanti.

Un punteggio Largest Contentful Paint veloce di per sé non è probabilmente un segnale diretto di citazione dell'intelligenza artificiale.

Un Cumulative Layout Shift inferiore probabilmente ha scarso effetto diretto sul crawling

Cumulative Layout Shift misura il movimento inatteso del contenuto visibile. È principalmente una metrica di esperienza utente. Le cause comuni includono immagini senza dimensioni, annunci inseriti dinamicamente, contenuti incorporati e font web. (web.dev)

Un crawler non sperimenta uno spostamento del layout allo stesso modo di un visitatore umano. Pertanto, è improbabile una relazione diretta tra un Cumulative Layout Shift inferiore e un maggiore crawling.

Potrebbe esserci una relazione indiretta quando un elevato spostamento del layout è causato da:

• Contenuto inserito tardivamente da JavaScript.
• Testo importante nascosto fino all'esecuzione degli script.
• Immagini o embed che ritardano la costruzione della pagina.
• Template instabili che producono contenuti diversi durante recuperi diversi.

In questi casi, il vero problema non è il punteggio dello spostamento del layout. Il vero problema è che la pagina potrebbe essere difficile da elaborare o potrebbe esporre contenuti importanti troppo tardi.

Le pagine più veloci non vengono automaticamente citate più spesso

Google afferma che le pagine che appaiono nelle funzionalità di intelligenza artificiale devono prima essere indicizzate ed essere idonee ad apparire nei normali risultati di ricerca con uno snippet. Google afferma inoltre che non ci sono requisiti tecnici aggiuntivi o ottimizzazioni speciali per l'intelligenza artificiale per le sue panoramiche e la modalità AI. (developers.google.com)

OpenAI afferma in modo simile che i ranking di ricerca di ChatGPT dipendono da molteplici fattori e che consentire il suo crawler di ricerca, OAI-SearchBot, è importante per l'inclusione. Non afferma che Core Web Vitals inferiori aumentino direttamente la probabilità di citazione. (help.openai.com)

Ciò suggerisce un modello a quattro stadi:

1. Scoperta — Il sistema apprende che l'URL esiste?
2. Recupero ed elaborazione — Il sistema può recuperare e comprendere la pagina?
3. Indicizzazione e recupero — La pagina viene selezionata per una particolare query?
4. Selezione della citazione — La pagina viene mostrata come fonte visibile nella risposta?

La velocità della pagina può influenzare i primi due stadi. Non è stabilita come causa diretta del quarto stadio.

Ricerche recenti mostrano anche che i sistemi di intelligenza artificiale possono leggere molte pagine pertinenti ma citarne solo alcune. In altre parole, il recupero e la citazione sono eventi separati. (cambridge.org)

Cosa Dovrebbe Essere Testato?

Lo studio dovrebbe testare due domande diverse anziché trattare la “visibilità dell'intelligenza artificiale” come un'unica metrica.

Domanda 1: Le prestazioni influenzano il crawling?

Risultati primari:

• Tempo dalla pubblicazione alla prima richiesta del crawler.
• Numero di richieste del crawler per pagina al giorno.
• Tempo tra un recrawling e l'altro.
• Numero di pagine sottoposte a crawling ogni 1.000 pagine pubblicate.
• Percentuale di recuperi riusciti.
• Tasso di errori del server e risposte di rate-limit.
• Tempo dalla pubblicazione all'indicizzazione.

Domanda 2: Le prestazioni influenzano la selezione delle citazioni?

Risultati primari:

• Percentuale di query testate che producono una citazione visibile.
• Tasso di citazione per pagina idonea.
• Quota di citazioni all'interno di una query.
• Percentuale di pagine recuperate che diventano citazioni visibili.
• Persistenza delle citazioni nel tempo.
• Tasso di citazione per sistema di intelligenza artificiale.

Questi risultati devono essere separati per fornitore. Una panoramica AI di Google, un risultato di ricerca di ChatGPT, una risposta di Microsoft Copilot, una risposta di Perplexity e una risposta di ricerca di Claude possono utilizzare indici, crawler, sistemi di ranking e programmi di aggiornamento diversi.

Progettazione Sperimentale

1. Costruire un set di pagine controllato

Utilizzare un set di pagine sufficientemente ampio da produrre dati significativi di crawling e citazioni.

Un design di partenza pratico includerebbe:

• Da 240 a 800 pagine.
• Almeno 20 pagine per modello di pagina.
• Tre o cinque categorie di contenuto.
• Un mix di pagine evergreen e regolarmente aggiornate.
• Numeri uguali di pagine in ciascun gruppo di trattamento.

Ogni pagina dovrebbe avere:

• Struttura HTML simile.
• Lunghezza del contenuto simile.
• Lo stesso sistema di pubblicazione.
• Lo stesso pattern di link interni.
• Le stesse regole canoniche.
• Lo stesso trattamento della sitemap.
• Le stesse autorizzazioni robots.txt.
• Un argomento unico e utile.

Non creare centinaia di pagine sottili o quasi duplicate solo per l'esperimento. Le linee guida di Google avvertono che URL duplicati e di basso valore possono sprecare risorse di crawling e ridurre l'efficienza di un sito. (developers.google.com)

Un design a coppie abbinate è utile. Ad esempio, abbinare pagine con caratteristiche simili:

• Lunghezza del contenuto.
• Domanda sull'argomento.
• Frequenza di aggiornamento.
• Conteggio dei link interni.
• Conteggio dei link esterni.
• Traffico storico.
• Posizione di ranking nella ricerca.

Quindi posizionare una pagina di ogni coppia nel gruppo di controllo e l'altra in un gruppo di trattamento.

2. Utilizzare un design di trattamento fattoriale

I principali trattamenti di performance dovrebbero essere testati indipendentemente e insieme.

Questo crea un esperimento controllato per le tre ottimizzazioni richieste:

• HTTP/3.
• Caching edge della rete di distribuzione dei contenuti.
• Compressione delle immagini.

Il trattamento di stabilità del layout è necessario perché le prime tre ottimizzazioni non isolano in modo affidabile il Cumulative Layout Shift. La compressione delle immagini può ridurre il Largest Contentful Paint senza modificare affatto la stabilità del layout.

Perché HTTP/3 necessita di una propria misurazione

HTTP/3 utilizza il protocollo di trasporto QUIC e fornisce stream indipendenti, che possono evitare il blocco di tipo head-of-line a livello di trasporto riscontrato in HTTP/2 su TCP. I suoi benefici dipendono dal fatto che il client o il crawler negozino effettivamente HTTP/3. (rfc-editor.org)

Pertanto, registrare il protocollo negoziato per ogni richiesta:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Non dare per scontato che l'abilitazione di HTTP/3 significhi che ogni crawler lo utilizzi. Se Googlebot, OAI-SearchBot o un altro crawler continua a utilizzare HTTP/2, HTTP/3 non può influenzare le richieste di quel crawler.

Perché il caching edge dovrebbe essere testato con attenzione

Una rete di distribuzione dei contenuti (CDN) può ridurre il time to first byte servendo il contenuto più vicino al richiedente. Può anche ridurre il numero di richieste che raggiungono il server di origine. (web.dev)

Testare almeno tre stati della cache:

1. Cache fredda — L'edge deve contattare l'origine.
2. Cache calda — L'edge serve la pagina senza contattare l'origine.
3. Cache riconvalidata — L'edge o il crawler utilizza un valore ETag o Last-Modified e riceve una risposta 304 Not Modified.

Google raccomanda specificamente il caching HTTP efficiente e supporta l'uso delle risposte 304 Not Modified per ridurre l'elaborazione e la larghezza di banda non necessarie. (developers.google.com)

Non permettere al caching di servire contenuti obsoleti o errati ai crawler. Registrare:

• Cache hit o miss.
• Età della cache.
• Località dell'edge.
• Tempo di risposta dell'origine.
• Versione del contenuto.
• Codice di stato.
• Header di validazione.

Perché la compressione delle immagini dovrebbe essere collegata al Largest Contentful Paint

WebP e AVIF generalmente offrono una migliore compressione rispetto ai formati immagine più vecchi. Immagini più piccole possono ridurre il tempo di trasferimento e possono migliorare il Largest Contentful Paint quando l'immagine è l'elemento Largest Contentful Paint. (web.dev)

Il test dovrebbe utilizzare:

• Le stesse dimensioni dell'immagine.
• Lo stesso obiettivo di qualità visiva.
• Immagini srcset responsive.
• Un formato moderno con un fallback adatto.
• Valori espliciti di width e height.
• Nessun caricamento lazy per l'immagine Largest Contentful Paint.
• Un URL immagine visibile nell'HTML iniziale.

La sola compressione delle immagini potrebbe non migliorare il Largest Contentful Paint se il vero ritardo proviene da JavaScript o dalla scoperta tardiva delle risorse. Le linee guida sulle prestazioni di Google notano che ridurre il tempo di download delle immagini può semplicemente spostare il ritardo su un'altra parte della pagina se l'elemento Largest Contentful Paint viene rivelato in ritardo. (web.dev)

3. Eseguire il test per un periodo sufficiente

Un test breve potrebbe perdere gli effetti della pianificazione del crawling e dell'aggiornamento dell'indice.

Un design pratico è:

• Due settimane di misurazione di base.
• Da sei a dodici settimane di misurazione del trattamento.
• Un periodo finale di inversione o crossover se possibile.

Per un test crossover, scambiare i trattamenti tra gruppi di pagine abbinate. Se l'effetto prestazionale scompare quando il trattamento viene rimosso, il risultato è più forte di un semplice confronto prima-dopo.

I dati sul campo dei Core Web Vitals dovrebbero essere valutati per un periodo adeguato. Il Chrome User Experience Report utilizza un'aggregazione mobile di 28 giorni, quindi non è progettato per mostrare cambiamenti istantanei dopo una distribuzione. (developer.chrome.com)

4. Misurare l'intera popolazione di crawler

Non trattare tutto il traffico automatizzato come un unico gruppo.

Al minimo, separare:

Crawler di ricerca

• Googlebot.
• Bingbot.

Crawler di ricerca per l'intelligenza artificiale

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Fetcher richiesti dall'utente

• Perplexity-User.
• Claude-User.
• Fetcher utente ChatGPT dove identificabili.

Crawler per l'addestramento

• GPTBot.
• ClaudeBot.
• Controlli Google-Extended.

I crawler di addestramento non dovrebbero essere usati come proxy per le citazioni di ricerca dell'intelligenza artificiale. Anthropic, OpenAI e Google distinguono tra i crawler utilizzati per l'addestramento, la ricerca o il recupero richiesto dall'utente. Google afferma inoltre che Google-Extended non influisce sull'inclusione o sul ranking di Google Search. (help.openai.com)

Perplexity distingue in modo simile tra PerplexityBot, che supporta l'indicizzazione della ricerca, e Perplexity-User, che può recuperare una pagina in risposta a una richiesta dell'utente. (docs.perplexity.ai)

Verificare l'identità del crawler utilizzando gli intervalli IP pubblicati o il DNS inverso dove il provider lo supporta. Le stringhe user-agent possono essere copiate da crawler non correlati. Google avverte specificamente che le stringhe user-agent di Googlebot possono essere falsificate. (developers.google.com)

Metriche da Raccogliere

Metriche di performance

Raccogliere dati sia di laboratorio che di utenti reali:

• Time to first byte.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Peso totale della pagina.
• Dimensione iniziale dell'HTML.
• Dimensione di trasferimento dell'immagine.
• Numero di richieste.
• Tempo trascorso nell'elaborazione del server.
• Tempo trascorso in attesa della risorsa Largest Contentful Paint.
• Protocollo HTTP.
• Stato della cache.

Google raccomanda un obiettivo approssimativo di time to first byte di 800 millisecondi o meno, ma il time to first byte non è di per sé un Core Web Vital. (web.dev)

Le attuali soglie “buone” dei Core Web Vitals al 75° percentile sono:

• Largest Contentful Paint: 2,5 secondi o meno.
• Cumulative Layout Shift: 0,1 o meno.
• Interaction to Next Paint: 200 millisecondi o meno. (web.dev)

Metriche di crawling

Per ogni richiesta verificata del crawler, registrare:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Calcolare:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Metriche di citazione dell'intelligenza artificiale

Utilizzare un set fisso di query su ogni piattaforma. Il set di query dovrebbe includere:

• Domande fattuali dirette.
• Domande di confronto.
• Domande su “migliori” o raccomandazioni.
• Domande sensibili alla freschezza.
• Domande in cui la pagina testata è la risposta più forte.
• Domande in cui la pagina testata è pertinente ma non dominante.

Per ogni query, registrare:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Ripetere le query perché le risposte dell'intelligenza artificiale possono variare. Utilizzare un programma fisso, ad esempio tre volte a settimana, e registrare i cambiamenti nel motore o nel modello.

Microsoft Bing Webmaster Tools ora fornisce un rapporto sulle prestazioni dell'intelligenza artificiale che mostra le pagine citate, le query di base e le tendenze delle citazioni attraverso le esperienze di intelligenza artificiale supportate da Microsoft. Microsoft avverte che i dati sono aggregati, campionati e osservazionali; non possono provare che un particolare cambiamento di pagina abbia causato un cambiamento di citazione. (bing.com)

Google ha anche iniziato a implementare rapporti sulle prestazioni dell'intelligenza artificiale generativa dedicati in Search Console nel giugno 2026. I rapporti erano inizialmente disponibili solo per un sottoinsieme di siti web, quindi l'accesso può variare. (developers.google.com)

Analisi Statistica

Frequenza di crawling

Utilizzare un modello di conteggio a effetti misti, come un modello binomiale negativo:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Gli effetti della pagina e del crawler sono importanti perché alcune pagine ricevono naturalmente più attenzione di altre, e diversi crawler hanno programmi diversi.

Scoperta e indicizzazione

Utilizzare l'analisi di sopravvivenza per:

• Tempo dalla pubblicazione al primo recupero.
• Tempo dalla pubblicazione alla prima indicizzazione.
• Tempo dall'aggiornamento al recrawling.

Il risultato chiave non è semplicemente se una pagina sia stata infine sottoposta a crawling. È se il trattamento ha ridotto il tempo necessario affinché la pagina fosse trovata ed elaborata.

Selezione delle citazioni dell'intelligenza artificiale

Utilizzare un modello logistico gerarchico:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Eseguire due modelli separati:

1. Modello di recupero — La pagina è stata recuperata o mostrata come candidata?
2. Modello di citazione — Se recuperata, la pagina è stata visibilmente citata?

Questa distinzione è essenziale. Un miglioramento delle prestazioni che aumenta il crawling ma non il recupero non è un effetto di citazione dell'intelligenza artificiale. Un miglioramento delle prestazioni che aumenta il recupero ma non le citazioni suggerisce che la pagina è presa in considerazione ma perde durante la selezione della fonte.

Risultati Attesi

Queste sono ipotesi di lavoro, non risultati sperimentali dichiarati.

Ipotesi 1: Il time to first byte avrà l'effetto di crawling più chiaro

Aspettarsi una relazione positiva tra un time to first byte inferiore e la capacità di crawling quando:

• Il sito ha molte pagine.
• Le pagine cambiano spesso.
• Il server di origine è lento o sovraccarico.
• Il sito restituisce risposte 5xx o 429.
• Il crawler trascorre molto tempo in attesa di risposte.

Aspettarsi uno scarso effetto misurabile su un sito piccolo con bassa domanda di crawling.

Ipotesi 2: Largest Contentful Paint sarà importante attraverso il rendering e la consegna delle risorse

Aspettarsi che un Largest Contentful Paint inferiore aiuti quando:

• La pagina dipende dal rendering del browser.
• Il contenuto importante è dietro JavaScript.
• Immagini o fogli di stile grandi sono richiesti per l'indicizzazione.
• Il crawler recupera molte risorse della pagina.
• Il trattamento più lento produce timeout o rendering incompleto.

Aspettarsi una relazione debole quando il testo importante della pagina è già presente nell'HTML iniziale.

Ipotesi 3: Cumulative Layout Shift avrà scarso effetto diretto

Non aspettarsi alcuna relazione diretta significativa tra Cumulative Layout Shift e frequenza di crawling o tasso di citazione dopo aver controllato la struttura della pagina e il comportamento JavaScript.

Se Cumulative Layout Shift sembra prevedere le citazioni, indagare se sta agendo come proxy per:

• Rendering lato client.
• Inserimento tardivo del contenuto.
• Annunci instabili.
• Testo nascosto o ritardato.
• HTML mal strutturato.

Ipotesi 4: La sola velocità non produrrà più citazioni di intelligenza artificiale

I predittori più forti della selezione delle citazioni probabilmente rimarranno:

• Rilevanza per la query.
• Qualità del contenuto.
• Risposte chiare.
• Freschezza.
• Autorità e fiducia.
• Idoneità all'indice di ricerca.
• Rango di recupero.
• Se la pagina supporta direttamente l'affermazione fatta.

Le linee guida di Google sottolineano contenuti utili, affidabili e incentrati sulle persone e affermano che le funzionalità di ricerca dell'intelligenza artificiale si basano sui sistemi di ricerca e indicizzazione esistenti. (developers.google.com)

Un Budget di Performance Tarato per il Recupero dell'Intelligenza Artificiale

Il seguente è un budget operativo proposto. Non è una formula di ranking di intelligenza artificiale pubblicata.

La documentazione attuale di Google afferma che Googlebot recupera i primi 2 megabyte di un file supportato e recupera script e fogli di stile esterni separatamente. Raccomanda anche di posizionare metadati e dati strutturati importanti all'inizio dell'HTML. (developers.google.com)

Raccomandazioni di Implementazione

HTTP/3

Utilizzare HTTP/3 quando è supportato dal provider di hosting e dalla rete di distribuzione dei contenuti.

Misurare:

• Tasso di negoziazione HTTP/3.
• Tasso di fallback HTTP/2.
• Tempo di configurazione della connessione.
• Time to first byte.
• Performance per regione geografica.
• Performance per crawler.

Non trattare HTTP/3 come un'ottimizzazione garantita per la ricerca o l'intelligenza artificiale. È un miglioramento del trasporto che può aiutare solo i client che lo utilizzano.

Caching Edge della Rete di Distribuzione dei Contenuti

Per pagine pubbliche e non personalizzate:

• Impostare regole chiare di Cache-Control.
• Utilizzare il caching a lunga durata per gli asset statici versionati.
• Utilizzare il caching breve ma utile per l'HTML frequentemente aggiornato.
• Evitare la frammentazione della cache da parametri di query non necessari.
• Preservare gli URL canonici.
• Supportare ETag e Last-Modified.
• Testare gli stati della cache fredda, calda e riconvalidata.
• Confermare che le richieste del crawler ricevano lo stesso contenuto importante delle richieste umane.

Una rete di distribuzione dei contenuti dovrebbe ridurre la latenza senza creare versioni di pagina obsolete, incoerenti o specifiche per bot.

Compressione delle Immagini

Per le immagini:

• Utilizzare AVIF o WebP quando la qualità visiva è accettabile.
• Fornire dimensioni immagine responsive.
• Non servire un'immagine di dimensioni desktop a uno schermo mobile piccolo.
• Non caricare in lazy-loading l'immagine Largest Contentful Paint.
• Includere le dimensioni dell'immagine.
• Posizionare l'immagine Largest Contentful Paint nell'HTML iniziale.
• Utilizzare fetchpriority="high" solo quando appropriato.
• Mantenere le spiegazioni importanti nel testo anziché incorporarle solo all'interno delle immagini.

La compressione delle immagini è più preziosa quando l'immagine è l'elemento Largest Contentful Paint. Non risolverà una pagina il cui ritardo principale deriva dal rendering del server o dall'esecuzione di JavaScript. (web.dev)

Stabilità del Layout

Per ridurre il Cumulative Layout Shift:

• Impostare attributi di larghezza e altezza sulle immagini.
• Riservare spazio per gli annunci.
• Riservare spazio per i video incorporati e i contenuti social.
• Evitare di inserire banner sopra il testo esistente.
• Utilizzare strategie di caricamento font stabili.
• Evitare di sostituire grandi blocchi di contenuto renderizzato dal server dopo il caricamento della pagina.

Questi cambiamenti migliorano l'esperienza utente anche se non hanno un effetto misurabile sul crawling o sulle citazioni. (web.dev)

Strumenti e Monitoraggio

Strumenti di performance

Utilizzare:

• Chrome User Experience Report per i Core Web Vitals degli utenti reali.
• API del Chrome User Experience Report per la raccolta automatizzata di dati sul campo.
• PageSpeed Insights per audit di laboratorio e dati sul campo.
• Lighthouse per test di laboratorio ripetibili.
• Lighthouse Continuous Integration per i budget di performance delle pull-request.
• WebPageTest per test multi-locazione, stati della cache e confronti di protocollo.
• Chrome DevTools per il debug di Largest Contentful Paint e layout shift.
• La libreria JavaScript web-vitals per il monitoraggio degli utenti reali.

L'API del Chrome User Experience Report fornisce dati sul campo aggregati a livello di pagina e di origine, inclusi Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint e un time to first byte sperimentale. (developer.chrome.com)

Lighthouse Continuous Integration può eseguire controlli di performance su ogni modifica del codice e far fallire le build quando i budget vengono superati. (github.com)

Monitoraggio dei crawler

Utilizzare log del server, log edge e un piccolo set di probe sintetici.

Esempio di probe:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Eseguire lo stesso test con:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Un normale user-agent del browser.

Il test dovrebbe verificare:

• Codice di stato.
• Autorizzazione Robots.
• Header di risposta.
• Contenuto HTML.
• Versione HTTP.
• Stato della cache.
• Tempo di risposta.
• Se il testo importante è presente senza JavaScript.

Monitoraggio della ricerca e dell'indicizzazione

Utilizzare:

• Statistiche di crawling di Google Search Console.
• Rapporti sull'indicizzazione delle pagine di Google Search Console.
• Controllo URL di Google Search Console.
• Dati della sitemap di Google Search Console.
• Rapporti sull'intelligenza artificiale generativa di Google Search Console quando disponibili.
• Richieste di crawling e pagine indicizzate di Bing Webmaster Tools.
• Prestazioni dell'intelligenza artificiale di Bing Webmaster Tools.
• Controlli quotidiani della sitemap e di lastmod.

L'API di Search Console può recuperare dati di performance per pagina, query, data, dispositivo e aspetto della ricerca, soggetti ai suoi limiti di dati. (developers.google.com)

Monitoraggio delle citazioni

Creare un pannello di citazioni contenente da 50 a 200 query stabili per argomento. Eseguire il pannello con un programma fisso e registrare:

• Se la piattaforma ha cercato.
• Quali fonti sono apparse.
• Se l'URL testato è stato citato.
• Ordine di citazione.
• Data e ora della risposta.
• Se la pagina è cambiata.
• Se il modello o l'esperienza di ricerca sono cambiati.

Non confrontare i conteggi delle citazioni da sistemi diversi come se fossero equivalenti. Microsoft afferma che l'attività di citazione non è un punteggio di ranking, un punteggio di autorità, una misura del traffico o un punteggio di qualità. (bing.com)

Regole di Avviso

Creare avvisi per:

• Time to first byte in aumento di oltre il 25 percento.
• Largest Contentful Paint che supera i 2,5 secondi al 75° percentile.
• Cumulative Layout Shift che supera 0,1.
• Un aumento sostenuto delle risposte 5xx o 429.
• Un calo del tasso di successo del crawler.
• Una modifica a robots.txt.
• Un errore nella sitemap.
• Un calo improvviso delle pagine indicizzate.
• Un calo improvviso delle citazioni di intelligenza artificiale su diverse piattaforme.
• Una modifica nel volume delle citazioni che interessa solo una piattaforma.

Un calo delle citazioni che interessa una piattaforma può essere causato da un cambiamento del modello, dell'indice, della query o del prodotto piuttosto che da un problema di performance della pagina. Microsoft avverte esplicitamente che le tendenze delle citazioni sono osservazionali e possono cambiare a causa di aggiornamenti dei contenuti, domanda degli utenti e modifiche al sistema o al modello. (bing.com)

Conclusione Finale

La conclusione più difendibile è:

Le pagine più veloci possono migliorare l'efficienza del crawling, specialmente quando la latenza del server, la dimensione delle risorse, gli errori o i ritardi di rendering sono fattori limitanti. Ma attualmente non ci sono prove concrete che Core Web Vitals inferiori inducano direttamente i sistemi di intelligenza artificiale a selezionare una pagina come citazione.

La catena causale attesa è:

text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations

Il passo finale rimane incerto perché la selezione delle citazioni dipende dalla rilevanza, dalla qualità, dalla freschezza, dall'autorità, dall'intento della query, dal ranking di recupero e dal comportamento di ogni sistema di intelligenza artificiale.

Per la maggior parte dei siti web, la strategia di performance corretta non è quindi “ottimizzare per le citazioni di intelligenza artificiale” in isolamento. È:

1. Mantenere i contenuti importanti disponibili nell'HTML iniziale.
2. Mantenere stabile il time to first byte.
3. Utilizzare il caching edge per i contenuti pubblici.
4. Comprimere e dare priorità alle immagini importanti.
5. Prevenire gli spostamenti del layout.
6. Restituire codici di stato affidabili.
7. Mantenere aggiornate le sitemap e i link interni.
8. Consentire i crawler di ricerca corretti.
9. Misurare il crawling, l'indicizzazione, il recupero e la citazione come fasi separate.

Questo approccio produce un sito web più veloce per le persone, un sito più sano per i crawler di ricerca e una base testabile per comprendere la visibilità dell'intelligenza artificiale.