Ottimizzazione dell'LCP mediante Signed Exchange

Come misurare e ottimizzare le piattaforme Signed Exchange per ottimizzarle

Devin Mullins

Le piattaforme Signed Exchange (SXG) sono un mezzo per migliorare la velocità delle pagine, principalmente Largest Contentful Paint (LCP). Quando i siti referenti (attualmente la Ricerca Google) rimandano a una pagina, possono precaricarla nella cache del browser prima che l'utente faccia clic sul link.

È possibile rendere le pagine web che, una volta precaricate, non richiedono alcuna rete sul percorso critico per il rendering della pagina. Su una connessione 4G, il caricamento della pagina va da 2,8 secondi a 0,9 secondi (i restanti 0,9 secondi sono principalmente in base all'utilizzo della CPU):

La maggior parte delle persone che pubblica oggi SXG utilizza la funzione di facile utilizzo SXG (Automatic Signed Exchanges) di Cloudflare (anche se esistono 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 in più per garantire che questi SXG funzionino come previsto in ogni fase della pipeline e per ottimizzare le pagine in modo da sfruttare appieno il precaricamento.

Negli ultimi due mesi dal lancio di Cloudflare, ho letto e risposto alle domande su vari forum e ho imparato a dare consigli ai siti su come assicurarsi che sfruttino al meglio le loro implementazioni 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, tra cui l'impostazione di un max-age ottimale e il precaricamento delle sottorisorse di blocco del 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 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 invece 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 ospitata su webpkgcache.com. Questi URL webpkgcache.com non influiscono sulla visualizzazione o sul comportamento della pagina, perché il browser rispetta l'URL originale firmato. Il precaricamento può accelerare il caricamento della pagina.

Analizza

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

Genera un test senza SXG nel seguente modo:

• Vai a WebPageTest e accedi. 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 aiuta a garantire che le opzioni di test siano le stesse.)
• Nella scheda Impostazioni di test, potrebbe essere utile impostare la connessione su 4G e aumentare il numero di test da eseguire. a 7.
• Fai clic su Inizia il test.

Genera un test con SXG seguendo gli stessi passaggi di cui 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 precaricamento per generare una pagina dei risultati di ricerca fittizia a questo scopo.

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

Una volta completati 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 mediano per ogni lato del confronto. L'impostazione predefinita è la mediana per Indice di velocità.

Per confrontare le cascate, espandi la sezione Opacità della 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 "con SXG" la struttura a cascata 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 mostra che SXG è in fase di precaricamento, significa che tutti i passaggi della pipeline sono stati eseguiti correttamente. puoi passare direttamente alla sezione Ottimizzazione per scoprire come migliorare ulteriormente la metrica 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 fingere di essere un crawler. Il modo più semplice consiste nell'utilizzare l'estensione di Chrome Strumento di convalida SXG:

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 Origin, significa che è stato restituito un SXG; puoi passare direttamente alla sezione Indicizzazione.

La croce (❌) indica che non è stato restituito un SXG:

Se Cloudflare ASX è abilitato, il motivo più probabile di una croce (❌) è che un'intestazione della 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 qualsiasi di queste intestazioni contiene uno dei seguenti valori di intestazione, impedirà la generazione di uno scambio 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

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 della croce (❌) è la presenza di una di queste intestazioni di risposte stateful, ad eccezione di Set-Cookie. ASX rimuove l'intestazione Set-Cookie per rispettare la specifica SXG.

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

In alternativa all'estensione di Chrome, puoi usare 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 ed è valido, verrà visualizzata una stampa leggibile dell'SXG. In caso contrario, visualizzerai un messaggio di errore.

Indicizzazione

Assicurati che i tuoi SXG siano indicizzati correttamente dalla Ricerca Google. Apri Chrome DevTools, poi esegui una Ricerca 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 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'SXG memorizzato nella cache per visualizzare la pagina.

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

Se <a> rimanda a webpkgcache.com, significa che l'indicizzazione della Ricerca Google dello standard Signed Exchange funziona. Puoi passare 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 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. Ne parleremo nella prossima sezione.

Importazione

Quando la Ricerca Google indicizza un SXG, ne invia la copia alla cache SXG di Google, che la convalida a fronte dei requisiti relativi alla cache. L'estensione di Chrome mostra il risultato:

Se vedi il segno di spunta (✅), puoi passare direttamente a Ottimizzazione.

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

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

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

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

Ottimizza

Se l'estensione di Chrome Strumento di convalida SXG mostra tutti i segni di spunta (✅), significa che hai un codice 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 per l'LCP da SXG.

età massima

Quando i messaggi SXG scadono, la cache SXG di Google recupererà una nuova copia in background. Mentre attendi il recupero, gli utenti vengono indirizzati alla pagina sul suo host originale, che non è precaricato. Più a lungo imposti Cache-Control: max-age, meno spesso si verifica questo recupero in background, quindi più spesso la metrica 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 una durata massima compresa tra 2 minuti e 7 giorni, per soddisfare le esigenze specifiche di ogni pagina. Secondo i nostri studi:

• max-age=86400 (1 giorno) o più è adatto per le prestazioni
• max-age=120 (2 minuti) non

Ci auguriamo di conoscere meglio i valori tra questi due valori, man mano che studiamo ulteriormente i dati.

user agent

Una volta, ho notato un aumento dell'LCP durante l'utilizzo di un SXG precaricato. Ho eseguito WebPageTest, confrontando i risultati mediani senza e con il precaricamento SXG. Fai clic su Dopo di seguito:

Ho visto che il precaricamento funzionava. L'HTML viene rimosso dal percorso critico e, di conseguenza, tutte le risorse secondarie potranno essere caricate prima. Tuttavia, il valore LCP (la linea tratteggiata verde) è passato da 2 a 2,1 secondi.

Per fare una diagnosi, ho guardato le strisce di pellicola. Ho notato che il rendering della pagina è diverso in SXG. In HTML semplice, Chrome ha stabilito che l'"elemento più grande" di LCP era il titolo. Tuttavia, nella versione SXG, la pagina ha aggiunto un banner con caricamento lento che spinge il 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 con caricamento lento. 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 l'argomento e ho scoperto che il motivo della differenza nel layout è che la pagina varia di User-Agent e c'era un errore nella logica. Pubblicava una pagina desktop anche se l'intestazione della scansione SXG indicava il dispositivo mobile. Una volta risolto il problema, il browser ha nuovamente identificato correttamente il titolo della pagina come elemento più grande.

Facendo clic su "Dopo", ho visto che l'LCP precaricato scende 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 solo come mobile o solo desktop utilizzando <meta name=supported-media content=...>.

Risorse secondarie

Gli SXG possono essere utilizzati per precaricare le risorse secondarie (incluse le immagini) insieme all'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 dalla Ricerca Google:

Per ottimizzare per LCP, guarda attentamente la struttura a cascata e scopri quali risorse si trovano sul percorso critico per il rendering dell'elemento più grande. Se non possono essere precaricati, valuta se possono essere eliminati dal percorso critico. Presta attenzione agli script che nascondono la pagina fino al termine del caricamento.

La cache SXG di Google consente fino a 20 precaricamenti di sottorisorse e ASX garantisce che questo limite non venga superato. Tuttavia, c'è il rischio di aggiungere troppi precaricamenti di sottorisorse. Il browser utilizzerà le sottorisorse precaricate solo se tutte hanno completato il recupero, al fine di impedire il monitoraggio tra siti. Maggiore è il numero di sottorisorse, minore è la probabilità che tutte abbiano terminato il precaricamento prima che l'utente faccia clic per accedere alla tua pagina.

Lo strumento di convalida SXG al momento non controlla le risorse secondarie. per eseguire il debug, usa curl o dump-signedexchange nel frattempo.

Misura

Dopo aver ottimizzato il miglioramento LCP in WebPageTest, è utile misurare l'impatto del precaricamento SXG sul rendimento complessivo del sito.

Metriche lato server

Quando misuri metriche lato server come Time to First Byte (TTFB), è importante notare che il tuo sito pubblica solo SXG per i crawler che accettano questo formato. Limita la misurazione delle TTFB alle richieste provenienti da utenti reali e non da bot. Potresti notare che la generazione di SXG aumenta il TTFB per le richieste del crawler, ma questo non influisce sui visitatori un'esperienza senza intervento manuale.

Metriche lato client

Gli SXG garantiscono il massimo vantaggio in termini di velocità per le metriche lato client, in particolare LCP. Per misurare il loro impatto, puoi semplicemente attivare 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, potrebbe essere difficile da individuare se mista a tutte le altre in questo arco di tempo.

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

Attualmente, il precaricamento SXG viene eseguito solo in determinate condizioni:

• Browser Chromium (ad es. Chrome o Edge tranne 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.

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

Studio contemporaneo

Quando esamini i dati RUM (Real User Monitoring), dovresti suddividere i caricamenti delle pagine in SXG e non SXG. Durante questa operazione, è essenziale limitare l'insieme di caricamenti pagina da osservare, 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, tutti i seguenti elementi sarebbero presenti solo nel set di caricamenti di pagine non SXG, che potrebbero avere un LCP innata diverso:

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

In Google Analytics (UA), crea due dimensioni personalizzate con ambito "Hit", una denominata "isSXG" e uno denominato "referrer". La dimensione integrata "Sorgente" ha un ambito sessione, quindi non esclude le navigazioni all'interno dello stesso sito.

Crea un segmento personalizzato denominato "Contatore SXG" con i seguenti filtri in relazione con l'operatore AND:

• referrer inizia con https://www.google.
• Browser corrisponde esattamente a Chrome
• Browser La versione 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 di sito, aggiungi il seguente snippet sopra lo snippet di Google Analytics. Questa è una sintassi speciale che ASX cambierà 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 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 dice 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 dettagliata del segmento SXG. Questo comando dovrebbe compilare la X di "Gli SXG influiscono sul X% delle visualizzazioni di pagina":

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

Fai clic su "Invia". 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 delle pagine controfattuale SXG devono consistere come segue:

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

Potrebbero esserci residui tra i caricamenti di pagine SXG e l'insieme di caricamenti di pagine non SXG sopra indicato, ma la loro grandezza dovrebbe essere inferiore a quella indicata nella parte superiore della sezione Studio contemporaneo. Ad esempio, è possibile che le pagine non memorizzabili nella cache siano più lente o più veloci di quelle non 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 noteranno miglioramenti delle prestazioni dopo l'attivazione di SXG, poiché queste pagine possono già essere precaricate dalla Ricerca Google. Valuta la possibilità di aggiungere un filtro per escludere queste pagine e "aumentare ulteriormente lo zoom" sulle modifiche pertinenti.

Infine, anche se prendiamo in considerazione tutti i bias di selezione, c'è il rischio che questi bias di sopravvivenza rendano i miglioramenti LCP simili a degradazioni delle statistiche RUM. Questo articolo spiega perfettamente questo rischio e suggerisce di esaminare una qualche forma di metrica relativa all'abbandono per stabilire se ciò si verifica.

Studio prima/dopo

Per confermare i risultati dello studio contemporaneo, può 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 nuova scansione di tutte le pagine del tuo sito potrebbe richiedere diverse settimane per identificare che SXG è stato attivato per le pagine in questione. In queste settimane, potrebbero verificarsi altri potenziali bias:

• Nuove release del browser o miglioramenti degli utenti l'hardware può velocizzare il caricamento delle pagine.
• Un evento significativo, come una festività, può disallineare il traffico dal normale.

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

• Se si trattava già del 10% di caricamenti pagina più veloci, non influirà affatto sul 75° percentile.
• Se fossero i caricamenti pagina più lenti del 10%, ma fossero più di 800 ms più lenti del 75° percentile LCP, allora non influirà affatto sul 75° percentile.

Si tratta di esempi estremi, probabilmente non riflettono la realtà, ma si spera che illustri 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 apportati al 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 sul tuo sito. Ad esempio, puoi impostare un'intestazione CDN-Cache-Control: no-store per impedire che Cloudflare ASX generi un SXG. Ti sconsiglio di farlo.

Probabilmente presenta 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 di holdback

Il modo ideale per misurare l'impatto sarebbe quello di condurre uno studio di isolamento. Purtroppo al momento non è possibile 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 porzione casuale delle visualizzazioni di pagina che sarebbero registrate su SXG vengono "trattenute" e pubblicate come non SXG. Ciò consente di ottenere una il confronto tra utenti, dispositivi, scenari e pagine equivalenti.
• Le visualizzazioni di pagina trattenute (note anche come controfattuale) vengono etichettate come tali in Analytics. In questo modo, puoi aumentare lo zoom visualizzazione dei dati, in cui è possibile confrontare i caricamenti pagina SXG nel controllo con i controfattuale SXG dell'esperimento. Questo, a sua volta, riduce il rumore proveniente dagli altri caricamenti delle pagine che non sarebbe interessato dal precaricamento SXG.

Ciò eliminerebbe le suddette possibili fonti di bias di selezione, anche se non eliminerebbe il rischio di bias di sopravvivenza LCP. Entrambe queste proprietà richiedono l'abilitazione del browser o del referrer.

Conclusione

Finalmente. Sono state tante. Speriamo 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 serrato con il test di laboratorio e, infine, come misurarle nel mondo reale. Raggruppando tutto questo, dovresti riuscire a ottenere il massimo da SXG e assicurarti che siano vantaggiosi per il tuo sito e i tuoi utenti.

Se hai altri consigli su come ottenere il rendimento di SXG, non esitare a contattarci. Segnala un bug su developer.chrome.com con i miglioramenti che hai suggerito.

Per ulteriori informazioni su Signed Exchange, consulta la documentazione web.dev e la documentazione della Ricerca Google.