Signed Exchange (SXG)

Un SXG è un meccanismo di pubblicazione che consente di autenticare l'origine di una risorsa indipendentemente da come è stata pubblicata.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

Gli exchange firmati (SXG) sono un meccanismo di pubblicazione che consente di autenticare l'origine di una risorsa indipendentemente dal modo in cui è stata pubblicata. L'implementazione di SXG può migliorare il Largest Contentful Paint (LCP) attivando il precaricamento multiorigine che tutela la privacy. Inoltre, questo disaccoppiamento favorisce una serie di casi d'uso, come le esperienze internet offline e la pubblicazione da cache di terze parti.

Questo articolo fornisce una panoramica completa degli SXG: come funzionano, casi d'uso e strumenti.

Compatibilità del browser

SXG è supportato dai browser basati su Chromium (a partire dalle versioni: Chrome 73, Edge 79 e Opera 64).

Panoramica

Come caso d'uso principale, SXG utilizza una cache per precaricare e pubblicare contenuti firmati in modo crittografico dall'origine. In questo modo, è possibile velocizzare le navigazioni cross-origin dai siti referrer, garantendo al contempo che le pagine rimangano inalterate e vengano attribuite correttamente alla loro origine. Tutte le informazioni identitarie potenzialmente identificative vengono nascoste finché l'utente non accede a un sito, proteggendo così la sua privacy. La Ricerca Google è un early adopter delle funzionalità di precaricamento SXG e, per i siti che ricevono gran parte del traffico dalla Ricerca Google, SXG può essere uno strumento importante per offrire agli utenti caricamenti di pagina più rapidi. Nel tempo, ci auguriamo che questo impatto si estenda ad altri referrer.

Come funziona

Un sito firma una coppia di richiesta/risposta (uno "scambio HTTP") in modo da consentire al browser di verificare l'origine e l'integrità dei contenuti indipendentemente da come sono stati distribuiti. Di conseguenza, il browser può visualizzare l'URL del sito di origine nella barra degli indirizzi, anziché l'URL del server che ha pubblicato i contenuti.

Diagramma che spiega come funzionano gli Signed Exchange. Browser che comunica con la cache, che a sua volta comunica con il sito di destinazione

Storicamente, l'unico modo per un sito di utilizzare una terza parte per distribuire i propri contenuti mantenendo l'attribuzione era condividere i propri certificati SSL con il distributore. Questo approccio presenta svantaggi in termini di sicurezza e, inoltre, è ben lontano dal rendere i contenuti veramente portatili.

Il formato SXG

Un SXG è incapsulato in un file con codifica binaria che contiene due componenti principali: uno scambio HTTP e una firma che copre lo scambio. Lo scambio HTTP è costituito da un URL di richiesta, informazioni sulla negoziazione dei contenuti e una risposta HTTP.

Ecco un esempio di file SXG decodificato.

format version: 1b3
request:
  method: GET
  uri: https://example.org/
  headers:
response:
  status: 200
  headers:
    Cache-Control: max-age=604800
    Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=
    Expires: Mon, 24 Aug 2020 16:08:24 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Encoding: mi-sha256-03
    Date: Mon, 17 Aug 2020 16:08:24 GMT
    Vary: Accept-Encoding
signature:
    label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>;
    cert-url=&quot;https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE&quot;;
    date=1597680503;expires=1598285303;integrity=&quot;digest/mi-sha256-03&quot;;sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>;
    validity-url=&quot;https://example.org/webpkg/validity&quot;
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p>

<p>The exchange has a valid signature.
payload [1256 bytes]:</p>
<pre class="prettyprint"><code>&lt;title&gt;SXG example&lt;/title&gt;
&lt;meta charset=&#34;utf-8&#34;&gt;
&lt;meta http-equiv=&#34;Content-type&#34; content=&#34;text/html; charset=utf-8&#34;&gt;
&lt;style type=&#34;text/css&#34;&gt;
body {
    background-color: #f0f0f2;
    margin: 0;
    padding: 0;
}
&lt;/style&gt;
</code></pre>
<div>
    <h1>Hello</h1>
</div>

<p>

Il parametro expires nella firma indica la data di scadenza di un SXG. Un SXG può essere valido per un massimo di 7 giorni. Per saperne di più sull'intestazione della firma, consulta la specifica degli scambi HTTP firmati.

Supporto per la personalizzazione lato server

Un SXG contenente un'intestazione Vary: Cookie verrà mostrato solo agli utenti che non hanno cookie per l'URL della richiesta firmata. Se il tuo sito presenta un codice HTML diverso agli utenti che hanno eseguito l'accesso, puoi utilizzare questa funzionalità per sfruttare gli SXG senza alterare l'esperienza. Consulta i dettagli sulla personalizzazione lato server con SXG dinamici.

Web Packaging

SXG fa parte della più ampia famiglia di proposte di specifiche di Web Packaging. Oltre agli SXG, l'altro componente principale della specifica Web Packaging sono i bundle web ("scambi HTTP in bundle"). I bundle web sono una raccolta di risorse HTTP e dei metadati necessari per interpretare il bundle.

La relazione tra SXG e Web Bundle è un punto che spesso genera confusione. SXG e Web Bundle sono due tecnologie distinte che non dipendono l'una dall'altra. I Web Bundle possono essere utilizzati sia con Signed Exchange che con Unsigned Exchange. Un obiettivo comune promosso sia dagli SXG che dai Web Bundle è la creazione di un formato di "pacchetto web" che consenta di condividere i siti nella loro interezza per la fruizione offline.

Velocizzare i caricamenti delle pagine con Signed Exchange

L'attivazione degli Signed Exchange può contribuire a velocizzare le prestazioni delle pagine web e, di conseguenza, influire sui Core Web Vitals del tuo sito, in particolare su Largest Contentful Paint (LCP). In qualità di early adopter, la Ricerca Google utilizza SXG per offrire agli utenti un'esperienza di caricamento pagina più rapida per le pagine caricate dalla pagina dei risultati di ricerca.

La Ricerca Google esegue la scansione e memorizza nella cache gli SXG, quando disponibili, e precarica l'SXG che l'utente probabilmente visiterà, ad esempio la pagina corrispondente al primo risultato di ricerca.

Gli SXG funzionano meglio in combinazione con altre ottimizzazioni delle prestazioni, come l'utilizzo di CDN e la riduzione delle risorse secondarie che bloccano il rendering. Dopo l'implementazione, segui questi consigli per massimizzare i vantaggi dell'LCP derivanti dal precaricamento degli SXG. In molti casi, questa ottimizzazione può comportare caricamenti quasi istantanei delle pagine provenienti dalla Ricerca Google:

Impatto di Signed Exchange

Da esperimenti precedenti abbiamo osservato una riduzione media di 300-400 ms della metrica LCP dai precaricamenti abilitati per SXG. In questo modo, i siti fanno una migliore prima impressione sugli utenti e spesso hanno un impatto positivo sulle metriche aziendali.

Diversi brand e siti globali hanno già beneficiato degli Signed Exchange. Come case study, vediamo in che modo l'implementazione degli Signed Exchange ha aiutato RebelMouse, un importante sistema di gestione dei contenuti (CMS), a migliorare le prestazioni e le metriche aziendali dei suoi clienti:

  • Narcity ha migliorato l'LCP del 41%
  • Paper Magazine ha registrato un aumento del 27% delle sessioni per utente
  • MLT Blog ha ridotto il tempo di caricamento della pagina del 21%

Cloudflare ha rilevato che SXG ha migliorato il TTFB per il 98% dei siti testati e ha migliorato l'LCP per l'85% dei siti, con un miglioramento medio di oltre il 20% nei caricamenti pagina idonei per SXG.

Indicizzazione

Le rappresentazioni SXG e non SXG di una pagina non vengono classificate o indicizzate in modo diverso dalla Ricerca Google. SXG è in definitiva un meccanismo di pubblicazione, non modifica i contenuti sottostanti.

AMP

I contenuti AMP possono essere pubblicati utilizzando SXG. SXG consente di precaricare e visualizzare i contenuti AMP utilizzando il relativo URL canonico, anziché l'URL AMP.AMP dispone di strumenti separati per la generazione di SXG.Scopri come pubblicare AMP utilizzando Signed Exchange su amp.dev.

Debug degli SXG con Chrome DevTools

Per vedere un SXG in prima persona, utilizza un browser Chromium, apri DevTools, apri il riquadro Rete e visita questa pagina di ricerca di esempio. Gli exchange firmati possono essere identificati cercando signed-exchange nella colonna Tipo.

Screenshot che mostra una richiesta SXG nel riquadro &quot;Rete&quot; di DevTools
Il riquadro Rete in DevTools

La scheda Anteprima fornisce ulteriori informazioni sui contenuti di un SXG.

Screenshot della scheda &quot;Anteprima&quot; per un SXG
La scheda Anteprima in DevTools

Strumenti

L'implementazione degli SXG consiste nel generare l'SXG corrispondente a un determinato URL e poi nel pubblicarlo per i richiedenti (di solito i crawler).

Certificati

Per generare un SXG, avrai bisogno di un certificato in grado di firmare gli SXG, anche se alcuni strumenti li acquisiscono automaticamente. In questa pagina sono elencate le autorità di certificazione che possono emettere questo tipo di certificato. I certificati possono essere ottenuti automaticamente dall'autorità di certificazione di Google utilizzando qualsiasi client ACME. Web Packager Server ha un client ACME integrato e sxg-rs lo avrà presto.

Strumenti SXG specifici per la piattaforma

Questi strumenti supportano stack tecnologici specifici. Se utilizzi già una piattaforma supportata da uno di questi strumenti, potresti trovare più semplice la configurazione rispetto a uno strumento per uso generico.

Strumenti SXG per uso generico

Server HTTP sxg-rs

sxg-rs http_server funge da reverse proxy per la pubblicazione di SXG. Per le richieste provenienti dai crawler SXG, http_server firmerà le risposte dal backend e risponderà con un SXG. Per le istruzioni di installazione, consulta il file README.

Server Web Packager

Il server Web Packager, webpkgserver, è un'alternativa a sxg-rs http_server, scritta in Go. Per istruzioni sulla configurazione del server Web Packager, consulta Come configurare Signed Exchange tramite Web Packager.

Interfaccia a riga di comando di Web Packager

L'interfaccia a riga di comando di Web Packager genera un SXG corrispondente a un determinato URL.

webpackager \
    --private\_key=private.key \
    --cert\_url=https://example.com/certificate.cbor \
    --url=https://example.com

Una volta generato il file SXG, caricalo sul tuo server e pubblicalo con il tipo MIME application/signed-exchange;v=b3. Inoltre, dovrai pubblicare il certificato SXG come application/cert-chain+cbor.

Librerie SXG

Queste librerie possono essere utilizzate per creare il tuo generatore di SXG:

  • sxg_rs è una libreria Rust per la generazione di SXG. È la libreria SXG più completa e viene utilizzata come base per gli strumenti cloudflare_worker e fastly_compute.

  • libsxg è una libreria C minima per la generazione di SXG. Viene utilizzato come base per il modulo NGINX SXG e il filtro Envoy SXG.

  • go/signed-exchange è una libreria Go minima fornita dalla specifica webpackage come implementazione di riferimento per la generazione di SXG. Viene utilizzato come base per lo strumento CLI di riferimento, gen-signedexchange e per gli strumenti Web Packager più ricchi di funzionalità.

Negoziazione dei contenuti

I server devono pubblicare SXG quando l'intestazione Accept indica che il valore q per application/signed-exchange è maggiore o uguale al valore q per text/html. In pratica, ciò significa che un server di origine pubblicherà SXG per i crawler, ma non per i browser. Molti degli strumenti sopra indicati lo fanno per impostazione predefinita, ma per altri strumenti è possibile utilizzare la seguente espressione regolare per trovare l'intestazione Accept delle richieste che devono essere pubblicate come SXG: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

Questo consiglio include esempi per Apache e nginx.

API Update cache

La cache SXG di Google dispone di un'API che i proprietari dei siti possono utilizzare per rimuovere gli SXG dalla cache prima della loro scadenza a causa di Cache-Control: max-age. Per maggiori dettagli, consulta il Riferimento API update-cache.

Link a SXG

Qualsiasi sito può memorizzare nella cache, pubblicare e precaricare gli SXG delle pagine a cui rimanda, se disponibili, utilizzando i tag e : html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg"> Questo articolo illustra come utilizzare nginx per distribuire gli SXG.

Vantaggi unici

SXG è una delle tante tecnologie possibili per abilitare il precaricamento multiorigine. Quando decidi quale tecnologia utilizzare, potresti dover trovare un compromesso tra l'ottimizzazione di diversi aspetti. Le sezioni seguenti illustrano alcuni dei valori unici che SXG offre nell'ambito delle possibili soluzioni. Questi fattori possono cambiare nel tempo con l'evoluzione dello spazio delle soluzioni disponibili.

Meno richieste da gestire

Con il precaricamento tra siti, il tuo server potrebbe dover gestire richieste aggiuntive. Ciò corrisponde ai casi in cui una pagina è stata precaricata, ma l'utente non l'ha visitata o i byte precaricati non hanno potuto essere mostrati all'utente. Per SXG, queste richieste aggiuntive inutilizzate possono essere ridotte in modo significativo:

  • Gli SXG vengono memorizzati nella cache e possono essere inviati agli utenti fino alla loro scadenza. In questo modo, molti precaricamenti possono essere gestiti esclusivamente dal server di cache.
  • Gli SXG possono essere mostrati agli utenti con e senza cookie sul tuo sito. In questo modo, la pagina dovrà essere recuperata meno volte dopo la navigazione.

Miglioramento di Page Speed

Potresti notare un ulteriore miglioramento della Page Speed grazie alle piattaforme e alle funzionalità di precaricamento attualmente supportate:

  • Gli SXG possono essere mostrati agli utenti con cookie per il tuo sito.
  • SXG esegue anche il precaricamento delle risorse secondarie per le tue pagine, come JavaScript, CSS, caratteri e immagini, se specificato utilizzando un'intestazione Link.
  • Nel prossimo futuro, il precaricamento SXG dalla Ricerca Google sarà disponibile per altri tipi di risultati di ricerca.

Conclusione

Gli Signed Exchange sono un meccanismo di pubblicazione che consente di verificare l'origine e la validità di una risorsa indipendentemente dal modo in cui è stata pubblicata. Di conseguenza, gli SXG possono essere distribuiti da terze parti mantenendo la piena attribuzione del publisher.

Per approfondire