Ottimizzazione dell'LCP mediante Signed Exchange

Come misurare e ottimizzare le piattaforme Signed Exchange per ottimizzarle

Devin Mullins

Le piattaforme di scambio pubblicitario con firma (SXG) sono un mezzo per migliorare la velocità della pagina, in particolare la visualizzazione elemento più grande (LCP). Quando i siti di riferimento (attualmente la Ricerca Google) rimandano a una pagina, possono precaricarla nella cache del browser prima che l'utente faccia clic sul link.

È possibile creare pagine web che, se precaricate, non richiedono la rete nel percorso critico per il rendering della pagina. Con una connessione 4G, il caricamento di questa pagina passa da 2,8 secondi a 0,9 secondi (gli 0,9 secondi rimanenti sono dovuti principalmente all'utilizzo della CPU):

Nota: in precedenza, questo post mostrava un miglioramento da 6 secondi a 0,9 secondi. Era vero, ma al momento il sito in test era insolitamente lento. Tuttavia, può essere utile come esempio rappresentativo di pagine con più risorse secondarie, server più lenti o utenti con tipi di connessione più lenti.

La maggior parte delle persone che pubblica oggi SXG utilizza la funzione di facile utilizzo SXG (Automatic Signed Exchanges) di Cloudflare (sebbene esistano anche opzioni open source):

In molti casi, selezionare la casella per attivare questa funzionalità è sufficiente per ottenere il tipo di miglioramento sostanziale mostrato sopra. A volte, sono necessari alcuni passaggi aggiuntivi per assicurarsi che questi SXG funzionino come previsto in ogni fase della pipeline e per ottimizzare le pagine in modo da sfruttare al meglio il prefetch.

Negli ultimi due mesi, da quando Cloudflare è stato lanciato, ho letto e risposto a domande su diversi forum e ho imparato a consigliare ai siti come ottenere il massimo dai loro implementazioni di SXG. Questo post è una raccolta dei miei consigli. Ti spiegherò la procedura per:

• Analizza le prestazioni di SXG utilizzando WebPageTest.
• Esegui il debug della pipeline SXG se il passaggio Analizza indica che non funziona.
• Ottimizza le pagine per il precaricamento SXG, ad esempio impostando un valore max-age ottimale e precaricando le risorse secondarie che bloccano il rendering.
• Misurare i miglioramenti di SXG utilizzando Google Analytics selezionando i gruppi di esperimento e di controllo appropriati.

Introduzione

Un SXG è un file contenente un URL, un insieme di intestazioni di risposta HTTP e un corpo della risposta, il tutto firmato tramite crittografia da un certificato PKI web. Quando il browser carica un file SXG, verifica quanto segue:

• L'SXG non è scaduto.
• La firma corrisponde all'URL, alle intestazioni, al corpo e al certificato.
• Il certificato è valido e corrisponde all'URL.

Se la verifica non va a buon fine, il browser abbandona l'SXG e recupera l'URL firmato. Se la verifica ha esito positivo, il browser carica la risposta firmata, trattandola come se provenisse direttamente dall'URL firmato. In questo modo, i file SXG possono essere ripubblicati su qualsiasi server, a condizione che non siano scaduti o modificati dopo la firma.

Nel caso della Ricerca Google, SXG consente il precaricamento delle pagine nei risultati di ricerca. Per le pagine che supportano gli SXG, la Ricerca Google può prelevare la copia memorizzata nella cache della pagina, ospitata su webpkgcache.com. Questi URL di webpkgcache.com non influiscono sulla visualizzazione o sul comportamento della pagina, perché il browser rispetta l'URL firmato originale. Il pre-caricamento può consentire di caricare la pagina molto più velocemente.

Nota: gli SXG sono potenzialmente utili per altri casi d'uso non trattati in questo articolo. Ad esempio, potrebbero abilitare la resilienza della connessione: un'app di chat potrebbe pre-scaricare un link inviato all'utente se la pagina supporta SXG, in modo che possa visualizzarlo in un secondo momento offline. Consulta questo elenco più ampio di potenziali casi d'uso.

Analizza

Per scoprire i vantaggi degli SXG, inizia a utilizzare uno strumento di laboratorio per analizzare il rendimento degli SXG in condizioni ripetibili. Puoi utilizzare WebPageTest per confrontare le strutture a cascata e l'LCP con e senza il pre-caricamento SXG.

Attenzione: i risultati del laboratorio potrebbero differire dalle esperienze degli utenti reali, ma sono uno strumento utile per diagnosticare dove eseguire l'ottimizzazione e per eseguire l'iterazione rapidamente. Tratteremo come misurare le metriche utente reali che ne derivano nella sezione Misura.

Genera un test senza SXG nel seguente modo:

• Vai su WebPageTest ed esegui l'accesso. Se accedi viene salvata la cronologia dei test per semplificare il confronto in un secondo momento.
• Inserisci l'URL che vuoi verificare.
• Vai a Configurazione avanzata. (Per il test SXG è necessaria la configurazione avanzata, quindi utilizzarla qui consente di garantire che le opzioni di test siano le stesse).
• Nella scheda Impostazioni test, può essere utile impostare la connessione su 4G e aumentare il "Numero di test da eseguire" a 7.
• Fai clic su Inizia test.

Genera un test con SXG seguendo gli stessi passaggi descritti sopra, ma prima di fare clic su Avvia test, vai alla scheda Script, incolla il seguente script WebPageTest e modifica i due URL navigate come indicato:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

Per il primo URL navigate, se la tua pagina non compare ancora nei risultati della Ricerca Google, puoi utilizzare questa pagina di prefetch per generare una pagina di risultati di ricerca simulata a questo scopo.

Per determinare il secondo URL navigate, visita la tua pagina utilizzando l'estensione di Chrome SXG Validator e fai clic sull'icona dell'estensione per visualizzare l'URL della cache:

Al termine di questi test, vai a Cronologia test, seleziona i due test e fai clic su Confronta:

Aggiungi &medianMetric=LCP all'URL di confronto in modo che WebPageTest selezioni l'esecuzione con LCP mediana per ogni lato del confronto. Il valore predefinito è la mediana per Indice di velocità.

Per confrontare le strutture a cascata, espandi la sezione Opacità struttura a cascata e trascina il cursore. Per visualizzare il video, fai clic su Modifica impostazioni sequenza di immagini, scorri verso il basso nella finestra di dialogo e fai clic su Visualizza video.

Se il pre-caricamento SXG va a buon fine, vedrai che la struttura a cascata "con SXG" non include una riga per l'HTML e i recuperi delle risorse secondarie iniziano prima. Ad esempio, confronta "Prima" e "Dopo" qui:

Debug

Se WebPageTest indica che l'SXG viene precompilato, significa che tutti i passaggi della pipeline sono stati completati correttamente. Puoi passare alla sezione Ottimizzare per scoprire come migliorare ulteriormente il LCP. In caso contrario, dovrai scoprire in quale fase della pipeline si è verificato un errore e perché. Continua a leggere per scoprire come.

Pubblicazione

Assicurati che le pagine vengano generate come messaggi SXG. Per farlo, devi fingerti un crawler. Il modo più semplice è utilizzare l'estensione di Chrome SXG Validator:

Nota: gli SXG sono destinati ai crawler compatibili con gli SXG per abilitare il prefetching. Quando gli utenti visitano direttamente il tuo sito, non dovresti pubblicare SXG per loro, poiché non saranno precaricati, ma verrà solo aggiunto un overhead. Cloudflare ASX esegue automaticamente questa negoziazione del contenuto.

L'estensione recupera l'URL corrente con un'intestazione della richiesta Accept che indica che preferisce la versione SXG. Se vedi un segno di spunta (✅) accanto a Origine, significa che è stato restituito uno SXG; puoi passare alla sezione Indicizzazione.

Se vedi una croce (❌), significa che non è stato restituito un SXG:

Se ASX di Cloudflare è attivato, il motivo più probabile per un segno di spunta (❌) è che un'intestazione di risposta di controllo della cache lo impedisce. ASX esamina le intestazioni con i seguenti nomi:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

Se una di queste intestazioni contiene uno dei seguenti valori, impedisce la generazione di un SXG:

• private
• no-store
• no-cache
• max-age inferiore a 120, a meno che non venga sostituito da s-maxage maggiore o uguale a 120

ASX non crea un SXG in questi casi perché è possibile che vengano memorizzati nella cache e riutilizzati per più visite e più visitatori.

Un altro possibile motivo per un segno di spunta (❌) è la presenza di una di queste intestazioni di risposta con stato, ad eccezione di Set-Cookie. ASX rimuove l'intestazione Set-Cookie per rispettare la specifica SXG.

Nota:queste limitazioni sono riportate in modo più dettagliato nel codice ASX. Ad esempio, le intestazioni di controllo della cache vengono ispezionate dal codice che determina quando firmare e la durata della firma. Le altre intestazioni vengono rimosse prima della firma da questa configurazione o da questo codice. Altre intestazioni impediscono la firma se non vengono rimosse.

Un altro possibile motivo è la presenza di un'intestazione di risposta Vary: Cookie. Googlebot recupera gli SXG senza le credenziali utente e può pubblicarli per più visitatori. Se pubblichi HTML diverso per utenti diversi in base al loro cookie, questi potrebbero visualizzare un'esperienza errata, ad esempio una visualizzazione di accesso non eseguito.

Nota: in futuro, le pagine che utilizzano Vary: Cookie saranno supportate da SXG e saranno mostrate solo ai visitatori senza cookie per il tuo sito. È implementato in Chromium e verrà attivata nella Ricerca Google una volta completata l'implementazione.

In alternativa all'estensione di Chrome, puoi utilizzare uno strumento come curl:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

o dump-signedexchange:

dump-signedexchange -verify -uri $URL

Se l'SXG è presente e valido, viene visualizzata una stampa leggibile dell'SXG. In caso contrario, visualizzerai un messaggio di errore.

Indicizzazione

Assicurati che i tuoi SXG siano stati indicizzati correttamente dalla Ricerca Google. Apri Chrome DevTools, quindi esegui una ricerca su Google per la tua pagina. Se è stata indicizzata come SXG, il link di Google alla tua pagina includerà un data-sxg-url che rimanda alla copia di webpkgcache.com:

Se la Ricerca Google ritiene che sia probabile che l'utente faccia clic sul risultato, lo precarica anche:

L'elemento <link> indica al browser di scaricare l'SXG nella cache di precaricamento. Quando l'utente fa clic sull'elemento <a>, il browser utilizzerà l'elemento SXG memorizzato nella cache per eseguire il rendering della pagina.

Puoi anche vedere la prova del pre-caricamento andando alla scheda Rete in DevTools e cercando gli URL contenenti webpkgcache.

Se <a> rimanda a webpkgcache.com, significa che l'indicizzazione della piattaforma di scambio firmata nella Ricerca Google funziona. Puoi andare avanti fino alla sezione Importazione.

In caso contrario, è possibile che Google non abbia ancora sottoposto a nuova scansione la tua pagina da quando hai attivato SXG. Prova lo strumento Controllo URL di Google Search Console:

La presenza di un'intestazione digest: mi-sha256-03=... indica che Google ha eseguito correttamente la scansione della versione SXG.

Se non è presente un'intestazione digest, potrebbe indicare che un SXG non è stato pubblicato per Googlebot o che l'indice non è stato aggiornato da quando hai attivato gli SXG.

Se la scansione di un SXG viene eseguita correttamente, ma non è ancora collegata, potrebbe trattarsi di un mancato rispetto dei requisiti della cache SXG. Questi aspetti sono trattati nella sezione successiva.

Importazione

Quando la Ricerca Google indicizza uno SXG, ne invia una copia alla cache SXG di Google, che la convalida in base ai requisiti della cache. L'estensione di Chrome mostra il risultato:

Se vedi un segno di spunta (✅), puoi andare direttamente a Ottimizza.

Se non soddisfa i requisiti, viene visualizzato un segno di spunta (❌) e un messaggio di avviso che indica il motivo:

In questo caso, la pagina funzionerà come prima dell'attivazione di SXG. Google collegherà la pagina sull'host originale senza un precaricamento SXG.

Se la copia memorizzata nella cache è scaduta e viene recuperata di nuovo in background, viene visualizzata una clessidra (⌛):

Il documento per gli sviluppatori di Google su SXG contiene anche istruzioni per eseguire query sulla cache manualmente.

Ottimizza

Se l'estensione di Chrome SXG Validator mostra tutti i segni di spunta (✅), hai un SXG che può essere pubblicato per gli utenti. Continua a leggere per scoprire come ottimizzare la tua pagina web in modo da ottenere il massimo miglioramento dell'LCP da SXG.

età massima

Quando gli SXG scadono, la cache SXG di Google ne recupera una nuova in background. Durante l'attesa del recupero, gli utenti vengono indirizzati alla pagina sul suo host originale, che non viene precomprata. Maggiore è il valore impostato per Cache-Control: max-age, minore è la frequenza con cui viene eseguito questo recupero in background e, di conseguenza, maggiore è la frequenza con cui l'LCP può essere ridotto dal pre-caricamento.

Si tratta di un compromesso tra prestazioni e aggiornamento e la cache consente ai proprietari di siti di fornire agli SXG un'età massima compresa tra 2 minuti e 7 giorni, in base alle esigenze specifiche di ogni pagina. A livello aneddotico, abbiamo riscontrato che:

• max-age=86400 (1 giorno) o più è un periodo di tempo ottimale per il rendimento
• max-age=120 (2 minuti) non

Speriamo di scoprire di più sui valori intermedi man mano che studiamo i dati.

Nota: in futuro prevediamo di semplificare la gestione di questo compromesso aggiungendo un'API per l'eliminazione della cache. L'annuncio verrà pubblicato su webpackaging-announce.

user agent

Una volta ho notato un aumento del tempo LCP quando utilizzavo un SXG precompilato. Ho eseguito WebPageTest, confrontando i risultati medi senza e con il prefetch SXG. Fai clic su Dopo di seguito:

Ho notato che il prefetch funzionava. Il codice HTML viene rimosso dal percorso critico e, di conseguenza, tutte le risorse secondarie possono essere caricate prima. Tuttavia, il valore LCP, ovvero la linea tratteggiata verde, è aumentato da 2 secondi a 2,1 secondi.

Per diagnosticare il problema, ho esaminato le strisce di pellicola. Ho notato che la pagina viene visualizzata in modo diverso in SXG. In HTML semplice, Chrome ha stabilito che l'"elemento più grande" per LCP era il titolo. Tuttavia, nella versione SXG, alla pagina è stato aggiunto un banner con caricamento differito, che ha spostato il titolo sotto la piega e ha fatto sì che il nuovo elemento più grande fosse la finestra di dialogo per il consenso all'uso dei cookie con caricamento differito. Il rendering degli elementi è stato eseguito più velocemente di prima, ma a causa di un cambiamento nel layout la metrica lo ha segnalato più lentamente.

Ho approfondito il problema e ho scoperto che la differenza nel layout è dovuta al fatto che la pagina varia in base a User-Agent ed è stato rilevato un errore nella logica. Veniva pubblicata una pagina desktop anche se l'intestazione della scansione SXG indicava il dispositivo mobile. Dopo la correzione, il browser ha identificato di nuovo correttamente il titolo della pagina come elemento più grande.

Ora, facendo clic su "Dopo", ho notato che il tempo LCP precompilato si riduce a 1,3 secondi:

Gli SXG sono abilitati per tutti i fattori di forma. Per prepararti, assicurati che una delle seguenti condizioni sia vera:

• La tua pagina non Vary di User-Agent (ad esempio utilizza il design reattivo o URL separati per dispositivi mobili/desktop).
• Se la tua pagina utilizza la pubblicazione dinamica, si annota come solo per dispositivi mobili o solo per computer utilizzando <meta name=supported-media content=...>.

Risorse secondarie

Gli SXG possono essere utilizzati per prelevare in anticipo le risorse secondarie (incluse le immagini) insieme all'HTML. ASX di Cloudflare eseguirà la scansione del codice HTML alla ricerca di elementi <link rel=preload> dello stesso dominio (proprietari) e li convertirà in intestazioni link compatibili con SXG. Dettagli nel codice sorgente qui e qui.

Se funziona, vedrai ulteriori preletture dalla Ricerca Google:

Per ottimizzare per LCP, esamina attentamente la struttura a cascata e scopri quali risorse si trovano nel percorso critico per il rendering dell'elemento più grande. Se non è possibile prelevare i dati in anticipo, valuta se è possibile rimuoverli dal percorso critico. Fai attenzione agli script che nascondono la pagina fino al termine del caricamento.

La cache SXG di Google consente fino a 20 precarichi di risorse secondarie e ASX garantisce che questo limite non venga superato. Tuttavia, l'aggiunta di troppi precaricamenti di sottorisorse potrebbe comportare il rischio. Il browser utilizzerà le risorse secondarie precaricate solo se tutte hanno terminato il recupero per impedire il monitoraggio tra siti. Più risorse secondarie sono presenti, meno è probabile che il pre-caricamento sia stato completato prima che l'utente faccia clic per accedere alla tua pagina.

Nota: al momento ASX supporta il pre-caricamento solo per le risorse secondarie dello stesso dominio (proprietarie). Se conosci fornitori di risorse secondarie di terze parti che supportano SXG, comunicacelo tramite questo bug per consentirci di dare la priorità all'aggiunta del supporto cross-origin.

Al momento SXG Validator non controlla le risorse secondarie. Nel frattempo, per eseguire il debug, utilizza curl o dump-signedexchange.

Misura

Dopo aver ottimizzato il miglioramento del tempo di caricamento della prima pagina in WebPageTest, è utile misurare l'impatto del pre-caricamento di SXG sul rendimento complessivo del sito.

Metriche lato server

Quando misuri le metriche lato server, come il tempo per primo byte (TTFB), è importante tenere presente che il tuo sito pubblica gli SXG solo per i crawler che accettano il formato. Limita la misurazione del TTFB alle richieste provenienti da utenti reali e non da bot. Potresti notare che la generazione di SXG aumenta il TTFB per le richieste dei crawler, ma questo non influisce sull'esperienza dei visitatori.

Metriche lato client

Gli SXG offrono il maggiore vantaggio in termini di velocità per le metriche lato client, in particolare LCP. Per misurare il loro impatto, puoi semplicemente abilitare Cloudflare ASX, attendere che venga rieseguito la scansione da Googlebot, attendere altri 28 giorni per l'aggregazione Core Web Vitals (CWV) e poi controllare i nuovi numeri CWV. Tuttavia, la variazione potrebbe essere difficile da individuare se si confonde con tutte le altre variazioni durante questo periodo di tempo.

Per me è utile aumentare lo zoom sui caricamenti delle pagine potenzialmente interessati e incorniciarli come "Gli SXG influiscono sull'X% delle visualizzazioni di pagina, migliorando il loro LCP di Y millisecondi al 75° percentile".

Al momento, il pre-caricamento SXG avviene solo in determinate condizioni:

• Browser Chromium (ad es. Chrome o Edge, tranne su iOS), versione M98 o successive
• Referer: google.com o altri domini della rete di ricerca di Google. Tieni presente che in Google Analytics un tag referral si applica a tutte le visualizzazioni di pagina nella sessione, mentre il precaricamento SXG si applica solo alla prima visualizzazione di pagina, direttamente collegata dalla Ricerca Google.

Nota: la Ricerca Google ha in programma di espandere i contesti in cui può essere eseguito il precaricamento SXG, inclusi i sistemi operativi desktop e altro. Ciò potrebbe aumentare la percentuale X nel tempo e significa anche che potresti voler aggiornare le metriche per adattarle alla modifica. In questo caso, l'annuncio dovrebbe essere pubblicato su webpackaging-announce.

Leggi la sezione relativa allo studio contemporaneo per scoprire come misurare la "X% delle visualizzazioni di pagina" e "migliorare l'LCP di Y millisecondi".

Studio contemporaneo

Quando esamini i dati del monitoraggio degli utenti reali (RUM), devi suddividere i caricamenti di pagine in SXG e non SXG. Durante questa operazione, è essenziale limitare l'insieme di caricamenti pagina da esaminare, in modo che le parti non legate a SXG soddisfino le condizioni di idoneità per SXG, in modo da evitare differenziazioni di selezione. In caso contrario, tutto quanto segue esisterebbe solo nell'insieme dei caricamenti di pagine non SXG, che potrebbero avere un LCP intrinsecamente diverso:

• Dispositivi iOS: a causa delle differenze di hardware o velocità di rete tra gli utenti che dispongono di questi dispositivi.
• Browser Chromium meno recenti: per gli stessi motivi.
• Dispositivi desktop: per gli stessi motivi o perché il layout della pagina comporta la scelta di un "elemento più grande" diverso.
• Navigazioni all'interno dello stesso sito (visitatori che seguono i link all'interno del sito): perché possono riutilizzare le risorse secondarie memorizzate nella cache dal caricamento della pagina precedente.

In Google Analytics (UA), crea due dimensioni personalizzate con ambito "Hit", una denominata "isSXG" e l'altra "referrer". La dimensione "Sorgente" integrata ha ambito a livello di sessione, pertanto non esclude le navigazioni nello stesso sito.

Crea un segmento personalizzato denominato "SXG controfattuale" con i seguenti filtri combinati con l'operatore AND:

• referrer inizia con https://www.google.
• Browser corrisponde esattamente a Chrome
• La versione Browser corrisponde all'espressione regolare ^(9[8-9]|[0-9]{3})
• isSXG corrisponde esattamente a false

Crea una copia di questo segmento, denominata "SXG", tranne per il fatto che isSXG corrisponde esattamente a true.

Nel modello del sito, aggiungi il seguente snippet sopra lo snippet di Google Analytics. Questa è una sintassi speciale che ASX modificherà false in true durante la generazione di un SXG:

<script data-issxg-var>window.isSXG=false</script>

Personalizza lo script dei report di Google Analytics come consigliato per registrare il tempo di caricamento della prima pagina. Se utilizzi gtag.js, modifica il comando 'config' per impostare la dimensione personalizzata (sostituendo 'dimension1' e 'dimension2' con i nomi che Google Analytics dice di utilizzare):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

Se utilizzi analytics.js, modifica il comando 'create' come descritto qui.

Dopo aver aspettato alcuni giorni per raccogliere alcuni dati, vai al report Eventi di Google Analytics e aggiungi un'analisi dettagliata per il segmento SXG. In questo modo, verrà compilata la X per "Gli annunci in scambio di dati influiscono sul X% delle visualizzazioni di pagina":

Infine, accedi al report Web Vitals, seleziona "Scegli segmenti", quindi "Contatore SXG" e "SXG".

Fai clic su "Invia" e dovresti vedere le distribuzioni LCP per i due segmenti. Questo valore dovrebbe riempire la Y per "migliorare l'LCP di Y millisecondi al 75° percentile":

Avvertenze

Una volta applicati tutti i filtri precedenti, i caricamenti di pagine controfattuali SXG dovrebbero essere costituiti da elementi come:

• Mancate corrispondenze della cache:se la cache SXG di Google non dispone di una copia aggiornata dello SXG per un determinato URL, reindirizzerà all'URL originale del tuo sito.
• Altri tipi di risultati: al momento, la Ricerca Google supporta gli SXG solo per i risultati web standard e per alcuni altri tipi. Altri, come gli snippet in primo piano e il carosello Notizie principali, rimanderanno all'URL originale del tuo sito.
• URL non idonei:se alcune pagine del tuo sito non sono idonee per gli SXG (ad es. perché non sono memorizzabili nella cache), potrebbero essere visualizzate in questo insieme.

Potrebbero esserci bias rimanenti tra i caricamenti di pagine SXG e l'insieme di caricamenti di pagine non SXG sopra indicato, ma la loro entità dovrebbe essere inferiore a quella dei bias menzionati nella parte superiore della sezione relativa allo studio contemporaneo. Ad esempio, le pagine non memorizzabili nella cache potrebbero essere più lente o più veloci delle pagine memorizzabili nella cache. Se sospetti che questo possa essere un problema, valuta la possibilità di esaminare i dati limitati a un URL specifico idoneo a SXG per vedere se i relativi risultati corrispondono allo studio complessivo.

Se il tuo sito ha alcune pagine AMP, probabilmente non noterà miglioramenti del rendimento dall'attivazione di SXG, in quanto possono già essere prelevate dalla Ricerca Google. Valuta la possibilità di aggiungere un filtro per escludere queste pagine, in modo da "aumentare lo zoom" sulle modifiche pertinenti.

Infine, anche se vengono affrontati tutti i bias di selezione, esiste il rischio che il bias di sopravvivenza faccia apparire i miglioramenti LCP come degradazioni nelle statistiche RUM. Questo articolo spiega molto bene questo rischio e suggerisce di esaminare una forma di metrica di abbandono per rilevare se si verifica.

Studio prima/dopo

Per confermare i risultati dello studio contemporaneo, potrebbe essere utile fare un confronto dell'LCP prima e dopo l'attivazione di SXG. Non limitare le visualizzazioni di pagina tramite SXG per eliminare i potenziali bias di cui sopra. Esamina, invece, i risultati idonei per SXG: le definizioni dei segmenti precedenti, ma senza il vincolo isSXG.

Tieni presente che la Ricerca Google potrebbe impiegare fino a diverse settimane per eseguire nuovamente la scansione di tutte le pagine del tuo sito, al fine di identificare che la funzionalità SXG è stata attivata per queste pagine. In queste settimane potrebbero verificarsi altri potenziali bias:

• Nuove release del browser o miglioramenti dell'hardware degli utenti possono velocizzare i caricamenti delle pagine.
• Un evento significativo come una festività può alterare il traffico normale.

È utile anche controllare l'LCP complessivo del 75° percentile prima e dopo, per confermare gli studi sopra riportati. Le informazioni su un sottoinsieme della popolazione non ci dicono necessariamente qualcosa sulla popolazione complessiva. Ad esempio, supponiamo che SXG migliori il 10% dei caricamenti di pagine di 800 ms.

• Se si tratta già del 10% dei caricamenti di pagine più rapidi, non influirà affatto sul 75° percentile.
• Se si tratta del 10% dei caricamenti di pagine più lenti, ma sono più lenti di oltre 800 ms rispetto al LCP del 75° percentile, non influiscono affatto sul 75° percentile.

Si tratta di esempi estremi, probabilmente non corrispondenti alla realtà, ma che speriamo possano illustrare il problema. In pratica, è probabile che gli SXG influiscano sul 75° percentile per la maggior parte dei siti. Le navigazioni tra siti tendono ad essere tra le più lente e i miglioramenti apportati dal pre-caricamento tendono ad essere significativi.

Disattivare alcuni URL

Infine, un modo per confrontare il rendimento di SXG potrebbe essere disattivare SXG per un sottoinsieme di URL sul tuo sito. Ad esempio, puoi impostare un'intestazione CDN-Cache-Control: no-store per impedire ad ASX di Cloudflare di generare uno SXG. Non lo consiglio.

Ha probabilmente un rischio maggiore di bias di selezione rispetto agli altri metodi di studio. Ad esempio, potrebbe fare una grande differenza se la home page del tuo sito o un URL simile sia selezionato nel gruppo di controllo o nel gruppo sperimentale.

Studio sull'isolamento

Il modo ideale per misurare l'impatto è condurre uno studio di blocco. Purtroppo, al momento non puoi eseguire questo tipo di test. Abbiamo in programma di supportare questo test in futuro.

Uno studio di isolamento ha le seguenti proprietà:

• Nel gruppo sperimentale, una frazione casuale delle visualizzazioni di pagina che sarebbero SXG viene "tratteggiata" e pubblicata come non SXG. In questo modo è possibile effettuare un confronto "in termini equivalenti" tra utenti, dispositivi, scenari e pagine equivalenti.
• Queste visualizzazioni di pagina trattenute (ovvero controfattuali) sono contrassegnate come tali negli analytics. Ciò consente di visualizzare i dati con "zoom", in modo da poter confrontare i caricamenti di pagine SXG nel gruppo di controllo con i controfattuali SXG nell'esperimento. Ciò, a sua volta, riduce il rumore causato dagli altri caricamenti di pagine che non sarebbero interessati dal pre-caricamento SXG.

In questo modo, verrebbero eliminate le possibili fonti di bias di selezione sopra menzionate, anche se non il rischio di bias di sopravvivenza dei clienti di lunga durata. Entrambe queste proprietà richiedono l'attivazione del browser o del referrer.

Conclusione

Finalmente. È stato molto. Ci auguriamo che offra un quadro più completo su come testare il rendimento di SXG in un test di laboratorio, su come ottimizzarlo in un ciclo di feedback stretto con il test di laboratorio e, infine, su come misurarlo nel mondo reale. Mettere insieme tutti questi elementi dovrebbe aiutarti a ottenere il massimo dagli SXG e a garantire che siano vantaggiosi per il tuo sito e i tuoi utenti.

Se hai altri consigli su come misurare il rendimento degli annunci di Shopping, non esitare a contattarci. Segnala un bug su developer.chrome.com con i miglioramenti suggeriti.

Per ulteriori informazioni sulle piattaforme di scambio pubblicitario con firma, consulta la documentazione di web.dev e la documentazione della Ricerca Google.