Ottimizzazione dell'LCP mediante Signed Exchange

Come misurare e ottimizzare gli standard Signed Exchange per sfruttarli al meglio

Devin Mullins

Signed Exchange (SXG) è uno strumento per migliorare la velocità della pagina, principalmente la Largest Contentful Paint (LCP). Quando rimandi siti (attualmente la Ricerca Google) a una pagina, questi possono precaricarla nella cache del browser prima che l'utente faccia clic sul link.

È possibile creare pagine web che, una volta precaricate, non richiedono alcuna rete nel percorso critico al rendering della pagina. Con una connessione 4G, il caricamento di questa pagina va da 2,8 a 0,9 secondi (i restanti 0,9 secondi sono principalmente dovuti all'utilizzo della CPU):

Nota: in precedenza, questo post mostrava un miglioramento da 6 secondi a 0,9 secondi. Questo era vero, ma il sito sottoposto a test era atipicamente lento all'epoca. Tuttavia, potrebbe fungere da esempio di pagine con più sottorisorse, server più lenti o utenti con tipi di connessione più lenti.

La maggior parte delle persone che pubblicano annunci SXG oggi utilizza l'intuitiva funzionalità Automatic Signed Exchange (ASX) di Cloudflare (anche se esistono anche opzioni open source):

In molti casi, selezionare la casella per attivare questa funzione è sufficiente per ottenere il tipo di miglioramento sostanziale illustrato sopra. A volte sono necessari alcuni altri passaggi per garantire che questi SXG funzionino come previsto in ogni fase della pipeline e per ottimizzare le pagine al fine di sfruttare al meglio il precaricamento.

Negli ultimi due mesi dal lancio di Cloudflare, ho letto e risposto alle domande su vari forum e ho imparato a consigliare ai siti come ottenere il massimo dalle implementazioni SXG. Questo post è una raccolta dei miei consigli. Ti guiderò attraverso i passaggi per:

• Analizza le prestazioni di SXG con WebPageTest.
• Esegui il debug della pipeline SXG se il passaggio Analizza indica che non funziona.
• Ottimizza le pagine per il precaricamento SXG, inclusa l'impostazione di un valore max-age ottimale e il precaricamento di sottorisorse che bloccano la visualizzazione.
• Misura il miglioramento di SXG utilizzando Google Analytics selezionando gruppi di esperimento e di controllo appropriati.

Introduzione

Un SXG è un file che contiene un URL, un insieme di intestazioni di risposta HTTP e un corpo della risposta, tutti firmati tramite crittografia da un certificato Web PKI. Quando il browser carica un file SXG, verifica tutti i seguenti aspetti:

• 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 lo 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, gli SXG possono essere ospitati nuovamente su qualsiasi server, purché non siano scaduti o modificati dopo la firma.

Nel caso della Ricerca Google, SXG attiva il precaricamento delle pagine nei risultati di ricerca. Per le pagine che supportano SXG, la Ricerca Google può precaricare la propria 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 originale firmato. Il precaricamento può consentire un caricamento molto più rapido della pagina.

Nota: gli SXG sono potenzialmente utili per altri casi d'uso non trattati in questo articolo. Ad esempio, potrebbero consentire la resilienza della connessione: un'app di chat potrebbe pre-scaricare un link inviato all'utente se la pagina supporta SXG, in modo da poterlo visualizzare in seguito offline. Consulta questo elenco più lungo di potenziali casi d'uso.

Analizza

Per vedere i vantaggi degli SXG, inizia utilizzando uno strumento da laboratorio per analizzare le prestazioni di SXG in condizioni ripetibili. Puoi utilizzare WebPageTest per confrontare le strutture a cascata e l'LCP con e senza precaricamento SXG.

Attenzione: i risultati del lab possono essere diversi dalle esperienze utente reali, ma sono uno strumento utile per diagnosticare dove ottimizzare e ripetere rapidamente. Vedremo come misurare le metriche relative agli utenti reali risultanti nella sezione Misura.

Genera un test senza SXG nel seguente modo:

• Vai a WebPageTest e accedi. Se accedi, la cronologia dei test viene salvata per un confronto più semplice in un secondo momento.
• Inserisci l'URL da verificare.
• Vai a Configurazione avanzata. È necessaria la configurazione avanzata per il test SXG, quindi utilizzarla qui aiuta a garantire che le opzioni di test siano le stesse.
• Nella scheda Impostazioni test, può essere utile impostare la connessione 4G e aumentare il "Numero di test da eseguire" a 7.
• Fai clic su Start Test (Avvia test).

Genera un test con SXG seguendo gli stessi passaggi descritti sopra, ma prima di fare clic su Inizia il 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 in nessun risultato della Ricerca Google, puoi utilizzare questa pagina di precaricamento per generare una pagina di risultati di ricerca fittizia a questo scopo.

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

Una volta completati questi test, vai a Cronologia dei 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 mediano per ogni lato del confronto. Il valore predefinito è il valore mediano per Indice di velocità.

Per confrontare le strutture a cascata, espandi la sezione Opacità a cascata e trascina il dispositivo di scorrimento. Per visualizzare il video, fai clic su Regola le impostazioni della sequenza, scorri verso il basso all'interno della finestra di dialogo e fai clic su Visualizza video.

Se il precaricamento SXG ha esito positivo, noterai che la struttura a cascata "con SXG" non include una riga per il codice HTML e che i recuperi delle risorse secondarie iniziano prima. Ad esempio, confronta "Prima" e "Dopo" qui:

esegui il debug

Se WebPageTest mostra che SXG è stato precaricato, significa che ha eseguito correttamente tutti i passaggi della pipeline. Puoi passare alla sezione Optimize per scoprire come migliorare ulteriormente LCP. In caso contrario, dovrai scoprire in che punto della pipeline si è verificato l'errore e perché; continua a leggere per scoprire come.

In fase di pubblicazione

Assicurati che le pagine vengano generate come SXG. Per farlo, devi fingere di essere un crawler. Il modo più semplice consiste nell'utilizzare l'estensione di Chrome SXGparking:

Nota: gli SXG sono pensati per consentire ai crawler che supportano SXG di attivare il precaricamento. Quando gli utenti visitano direttamente il tuo sito, non dovresti pubblicare SXG, poiché non saranno precaricati e questo comporta solo un aumento delle spese generali. Cloudflare ASX esegue automaticamente questa negoziazione dei contenuti.

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 un SXG. Puoi passare direttamente alla sezione Indicizzazione.

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

Se Cloudflare ASX è abilitato, il motivo più probabile di un segno incrociato (❌) è che un'intestazione di risposta del controllo cache lo impedisce. ASX controlla 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 di intestazione, impedirà la generazione di un SXG:

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

In questi casi, ASX non crea un SXG perché i file SXG possono essere memorizzati nella cache e riutilizzati per più visite e più visitatori.

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

Nota: queste limitazioni possono essere visualizzate in maggiore dettaglio nel codice ASX. Ad esempio, le intestazioni del controllo cache vengono ispezionate dal codice che determina quando firmare e la durata della firma. Le altre intestazioni vengono rimosse prima della firma tramite questa configurazione o da questo codice. Altre intestazioni impediscono la firma se non vengono rimosse in altro modo.

Un altro possibile motivo è la presenza di un'intestazione della risposta Vary: Cookie. Googlebot recupera gli SXG senza credenziali utente e potrebbe mostrarli a più visitatori. Se pubblichi un codice HTML diverso per utenti diversi in base al loro cookie, questi potrebbero visualizzare un'esperienza non corretta, ad esempio una visualizzazione disconnessa.

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

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

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

oppure dump-signedexchange:

dump-signedexchange -verify -uri $URL

Se l'SXG è presente e valido, verrà visualizzata una stampa leggibile da una persona. In caso contrario, verrà visualizzato 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 è stato indicizzato 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 l'utente sia propenso a fare clic sul risultato, lo precarica anche:

L'elemento <link> indica al browser di scaricare SXG nella sua cache di precaricamento. Quando l'utente fa clic sull'elemento <a>, il browser utilizza l'SXG memorizzato nella cache per visualizzare la pagina.

Puoi anche vedere la prova del precaricamento aprendo la scheda Rete in DevTools e cercando gli URL contenenti webpkgcache.

Se <a> rimanda a webpkgcache.com, significa che l'indicizzazione dello standard Signed Exchange nella Ricerca Google funziona. Puoi andare direttamente alla sezione Importazione.

In caso contrario, è possibile che Google non abbia ancora eseguito nuovamente la scansione della 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, ciò potrebbe indicare che non è stato pubblicato un SXG per Googlebot o che l'indice non è stato aggiornato dopo l'attivazione di SXG.

Se una scansione di SXG viene eseguita correttamente, ma non viene ancora collegata, potrebbe non essere possibile soddisfare i requisiti della cache SXG. Questi aspetti sono trattati nella prossima sezione.

Importazione

Quando la Ricerca Google indicizza un SXG, ne invia la 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 passare direttamente a Ottimizza.

Se non soddisfa i requisiti, vedrai una croce (❌) e un messaggio di avviso che ne indica il motivo:

In questo evento, la pagina funzionerà come prima di attivare SXG. Google si collegherà alla pagina sull'host originale senza un precaricamento SXG.

Nel caso in cui la copia memorizzata nella cache sia scaduta e sia stata recuperata nuovamente in background, verrà visualizzata una clessidra (⌛):

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

Optimize

Se l'estensione di Chrome SXG validation 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.

max-age

Alla scadenza degli SXG, Google SXG Cache recupererà una nuova copia in background. Durante l'attesa del recupero, gli utenti vengono indirizzati alla pagina sull'host originale, che non è precaricato. Più a lungo imposti Cache-Control: max-age, meno spesso viene eseguito questo recupero in background e, di conseguenza, più spesso la LCP può essere ridotta dal precaricamento.

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, per soddisfare le esigenze specifiche di ogni pagina. Ecco un esempio aneddotico:

• max-age=86400 (1 giorno) o più giorni genera un buon rendimento
• max-age=120 (2 minuti) no

Mentre studiamo ulteriormente i dati, ci auguriamo di ottenere maggiori informazioni sui valori che li separano.

Nota: prevediamo di semplificare la gestione di questo compromesso in futuro aggiungendo un'API di eliminazione definitiva della cache. Verrà annunciato il giorno webpackaging-announce.

user agent

Una volta ho notato un aumento del valore LCP quando usavo uno SXG precaricato. Ho eseguito WebPageTest, confrontando i risultati mediani senza e con il precaricamento SXG. Fai clic su Dopo di seguito:

Ho notato che il precaricamento funzionava. L'HTML viene rimosso dal percorso critico e, di conseguenza, tutte le sottorisorse possono essere caricate in precedenza. Tuttavia, il valore LCP, ossia la linea tratteggiata verde, è aumentato da 2 a 2,1 secondi.

Per fare una diagnosi, ho guardato le strisce di pellicola. Ho notato che il rendering della pagina era diverso in SXG. In HTML semplice, Chrome ha stabilito che l'"elemento più grande" per LCP era il titolo. Tuttavia, nella versione SXG, la pagina aggiungeva un banner con caricamento lento, che faceva push del titolo below the fold e faceva sì che il nuovo elemento più grande fosse la finestra di dialogo per il consenso all'uso dei cookie a caricamento lento. Tutto è reso più veloce di prima, ma a causa di una modifica del layout, la metrica ha segnalato un rallentamento.

Ho approfondito e ho scoperto che il motivo della differenza nel layout è che la pagina varia di User-Agent e che si è verificato un errore di logica. Pubblicava una pagina desktop anche se l'intestazione della scansione di SXG indicava la presenza di dispositivi mobili. Una volta risolto il problema, il browser ha identificato correttamente il titolo della pagina come l'elemento più grande.

Ora, facendo clic su "Dopo", ho notato che l'LCP precaricato scende a 1,3 secondi:

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

• La tua pagina non ha Vary User-Agent (ad esempio, utilizza un design adattabile o URL mobile/desktop separati).
• Se la tua pagina utilizza la pubblicazione dinamica, si annotazione come riservata agli utenti di dispositivi mobili o desktop utilizzando <meta name=supported-media content=...>.

Risorse secondarie

Gli SXG possono essere utilizzati per precaricare le sottorisorse (incluse le immagini) insieme al codice HTML. Cloudflare ASX eseguirà la scansione del codice HTML per individuare elementi <link rel=preload> della stessa origine (proprietari) e li convertirà in intestazioni dei link compatibili con SXG. Dettagli nel codice sorgente qui e qui.

Se funziona, vedrai ulteriori precaricamenti nella Ricerca Google:

Per eseguire l'ottimizzazione in base alla metrica LCP, esamina attentamente la tua struttura a cascata e individua le risorse lungo il percorso critico per il rendering dell'elemento più grande. Se non possono essere precaricati, valuta se è possibile abbandonarli dal percorso critico. Presta attenzione agli script che nascondono la pagina fino al termine del caricamento.

Google SXG Cache consente fino a 20 precaricamenti di sottorisorse e ASX garantisce che questo limite non venga superato. Tuttavia, l'aggiunta di troppi precaricamenti di sottorisorse comporta il rischio. Il browser utilizzerà le sottorisorse precaricate solo se tutte hanno terminato il recupero, per impedire il monitoraggio tra siti. Maggiore è il numero di sottorisorse, meno è probabile che tutte abbiano terminato il precaricamento prima che l'utente faccia clic per accedere alla tua pagina.

Nota: al momento ASX supporta solo il precaricamento per le sottorisorse della stessa origine (proprietarie). Se conosci provider di sottorisorse di terze parti che supportano SXG, segnalaci questo bug per consentirci di dare la priorità all'aggiunta del supporto multiorigine.

Al momento lo strumento di convalida SXG non controlla le sottorisorse. Per eseguire il debug, utilizza nel frattempo curl o dump-signedexchange.

Misura

Dopo aver ottimizzato il miglioramento del valore LCP in WebPageTest, ti consigliamo di misurare l'impatto del precaricamento di SXG sulle prestazioni complessive del tuo sito.

Metriche lato server

Quando misuri metriche lato server come Tempo per il primo byte (TTFB), è importante tenere presente che il tuo sito pubblica SXG solo per i crawler che accettano questo 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 ciò non influisce sull'esperienza dei tuoi visitatori.

Metriche lato client

Gli SXG producono i maggiori vantaggi in termini di velocità per le metriche lato client, in particolare per la LCP. Quando misuri il loro impatto, puoi semplicemente abilitare Cloudflare ASX, attendere che Googlebot ne esegua nuovamente la scansione, attendere altri 28 giorni per l'aggregazione di Core Web Vitals (CWV) e quindi controllare i nuovi numeri CWV. Tuttavia, in questo lasso di tempo, la variazione potrebbe essere difficile da individuare se viene unita a tutte le altre.

Invece, trovo utile "aumentare lo zoom" sui caricamenti delle pagine potenzialmente interessate e inquadrarlo come "Gli SXG influiscono sul X% delle visualizzazioni di pagina, migliorando l'LCP di Y millisecondi al 75° percentile".

Al momento, il precaricamento SXG avviene solo in determinate condizioni:

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

Nota:la Ricerca Google ha in programma di espandere i contesti in cui può verificarsi il precaricamento di SXG, inclusi i sistemi operativi desktop e altro ancora. Questo potrebbe aumentare la percentuale X% nel tempo e potrebbe anche essere opportuno aggiornare le metriche per adeguarle. In questo caso, dovrebbe essere annunciato su webpackaging-announce.

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

Studio contemporaneo

Quando esamini i dati di monitoraggio degli utenti reali (RUM), devi suddividere i caricamenti delle pagine in SXG e non SXG. Durante questa operazione, è essenziale limitare l'insieme di caricamenti di pagine osservati, in modo che il lato non SXG corrisponda alle condizioni di idoneità per SXG, in modo da evitare il bias di selezione. In caso contrario, tutto quanto segue esisterebbe solo nel set di caricamenti di pagine non SXG, che potrebbe avere un LCP intrinsecamente diverso:

• Dispositivi iOS:a causa delle differenze di velocità dell'hardware o di rete degli utenti che dispongono di questi dispositivi.
• Browser Chromium meno recenti:per gli stessi motivi.
• Computer: per gli stessi motivi o perché il layout della pagina fa sì che venga scelto un "elemento più grande" diverso.
• Navigazioni sullo stesso sito (visitatori che seguono i link all'interno del sito): perché possono riutilizzare le sottorisorse memorizzate nella cache dal caricamento pagina precedente.

In Google Analytics (UA), crea due dimensioni personalizzate con l'ambito "Hit", una denominata "isSXG" e l'altra denominata "referrer". La dimensione integrata "Origine" include l'ambito sessione, quindi non esclude le navigazioni sullo stesso sito.

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

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

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

Nel modello del tuo 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 di report di Google Analytics come consigliato per registrare il valore LCP. Se utilizzi gtag.js, modifica il comando 'config' per impostare la dimensione personalizzata (sostituendo 'dimension1' e 'dimension2' con i nomi che Google Analytics indica di utilizzare):

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

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

Dopo aver atteso alcuni giorni per raccogliere alcuni dati, vai al report Eventi di Google Analytics e aggiungi una visualizzazione in dettaglio per il segmento SXG. Questo campo deve compilare la X di "SXG influisce sul X% delle visualizzazioni di pagina":

Infine, vai al report Segnali web, seleziona "Scegli segmenti" e "SXG controfattuale" e "SXG".

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

Avvertenze

Una volta applicati tutti i filtri precedenti, i caricamenti delle pagine controfattuale SXG dovrebbero consistere in questi elementi:

• Mancati errori della cache:se la cache SXG di Google non dispone di una copia aggiornata del codice SXG per un determinato URL, reindirizzerà all'URL originale sul tuo sito.
• Altri tipi di risultati:attualmente la Ricerca Google supporta SXG solo per i risultati web standard e per alcuni altri tipi. Altre, come gli snippet in primo piano e il carosello Notizie principali, rimanderanno all'URL originale sul tuo sito.
• URL non idonei:se alcune pagine del tuo sito non sono idonee per SXG (ad esempio perché non possono essere memorizzate nella cache), potrebbero apparire in questo insieme.

Potrebbero esserci ancora dei bias tra il caricamento delle pagine SXG e il gruppo di caricamenti di pagine non SXG riportato sopra, ma il valore dovrebbe essere inferiore rispetto a quelli menzionati all'inizio della sezione Studio Contemporaneo. Ad esempio, le pagine non memorizzabili nella cache potrebbero essere più lente o più veloci di quelle che è possibile memorizzare nella cache. Se sospetti che possa trattarsi di un problema, valuta la possibilità di esaminare i dati limitati a uno specifico URL idoneo a SXG per verificare se i relativi risultati corrispondono allo studio complessivo.

Se il tuo sito ha alcune pagine AMP, è probabile che queste non notino miglioramenti delle prestazioni derivanti dall'attivazione di SXG, in quanto possono essere già precaricate dalla Ricerca Google. Valuta la possibilità di aggiungere un filtro per escludere queste pagine, per aumentare ulteriormente lo zoom sulle modifiche pertinenti.

Infine, anche affrontando tutti i bias di selezione, c'è il rischio che il bias di sopravvivenza faccia sì che i miglioramenti LCP appaiano come degradazioni nelle statistiche RUM. Questo articolo spiega benissimo questo rischio e suggerisce di esaminare una qualche forma di metrica di abbandono per rilevare se questo sta accadendo.

Prima/dopo lo studio

Per verificare i risultati dello studio contemporaneo, può essere utile fare un confronto della metrica LCP prima e dopo aver attivato SXG. Non limitare le visualizzazioni di pagina SXG per eliminare i potenziali bias di cui sopra. Esamina invece i risultati idonei a SXG: le definizioni dei segmenti sopra riportate, ma senza il vincolo di isSXG.

Tieni presente che nella Ricerca Google potrebbero essere necessarie diverse settimane per ripetere la scansione di tutte le pagine del tuo sito, per identificare che SXG è stato attivato per il sito. In queste settimane, potrebbero verificarsi altri potenziali bias:

• Nuove release del browser o miglioramenti dell'hardware degli utenti possono velocizzare il caricamento delle pagine.
• Un evento significativo come una festività può distorcere il traffico rispetto alla normalità.

Inoltre, è utile esaminare l'LCP del 75° percentile complessivo prima e dopo, per confermare gli studi precedenti. Conoscere un sottoinsieme della popolazione non ci fornisce necessariamente informazioni sulla popolazione complessiva. Ad esempio, supponiamo che SXG migliori il 10% dei caricamenti delle pagine di 800 ms.

• Se la pagina si carica già del 10% più velocemente, questo non influirà affatto sul 75° percentile.
• Se sono stati i caricamenti delle pagine più lenti del 10%, ma erano più di 800 ms più lenti rispetto all'LCP del 75° percentile, questo non influirà affatto sul 75° percentile.

Si tratta di esempi estremi, che probabilmente non riflettono la realtà, ma speriamo che illustrino il problema. In pratica, è probabile che SXG influisca sul 75° percentile per la maggior parte dei siti. Le navigazioni tra siti tendono a essere tra le più lente e i miglioramenti del precaricamento tendono a essere significativi.

Disattiva alcuni URL

Infine, un modo per confrontare le prestazioni di SXG potrebbe essere disattivare SXG per alcuni sottoinsiemi di URL del sito. Ad esempio, puoi impostare un'intestazione CDN-Cache-Control: no-store per impedire a Cloudflare ASX di generare un SXG. Sconsiglio questa affermazione.

Probabilmente presenta un rischio maggiore di bias di selezione rispetto agli altri metodi di studio. Ad esempio, può fare una grande differenza se la home page del tuo sito o un URL simile è selezionato nel gruppo di controllo o nel gruppo dell'esperimento.

Studio di holdback

Il modo ideale per misurare l'impatto è condurre uno studio di isolamento. Purtroppo al momento non puoi eseguire questo tipo di test. Abbiamo in programma di aggiungere il supporto per questo tipo di test in futuro.

Uno studio di isolamento ha le seguenti proprietà:

• Nel gruppo sperimentale, alcune frazioni casuali di visualizzazioni di pagina che sarebbero considerate SXG vengono "trattenute" e pubblicate come non SXG. Ciò consente un confronto "da mele" tra utenti, dispositivi, scenari e pagine equivalenti.
• Le visualizzazioni di pagina trattenute (ovvero controfattuale) vengono etichettate come tali nei dati e nelle analisi. Ciò consente una visualizzazione "ingrandita" dei dati, in cui possiamo confrontare i caricamenti di pagine SXG nel controllo con i controfattuali SXG nell'esperimento. Questo, a sua volta, riduce il rumore proveniente dagli altri caricamenti di pagina che non sarebbe interessato dal precaricamento di SXG.

In questo modo si eliminerebbero le suddette possibili fonti di bias di selezione, ma non si eliminerebbe il rischio di bias di sopravvivenza LCP. Per l'attivazione di queste proprietà è necessario il browser o il referrer.

Conclusione

Finalmente. Sono davvero tanti. Ci auguriamo che dia un quadro più completo di come testare le prestazioni di SXG in un test di laboratorio, di come ottimizzarne le prestazioni in un ciclo di feedback ristretto con il test di laboratorio e, infine, di come misurarne le prestazioni nel mondo reale. Raccogliere tutto questo dovrebbe aiutarti a ottenere il massimo da SXG e assicurarti che stiano traendo beneficio dal tuo sito e dai tuoi utenti.

Contattaci per eventuali altri consigli su come acquisire le prestazioni di SXG. Segnala un bug relativo a developer.chrome.com con i miglioramenti che hai suggerito.

Per saperne di più su Signed Exchange, consulta la documentazione di web.dev e la documentazione della Ricerca Google.