Distribuire applicazioni veloci e leggere con il risparmio di dati

Suggerimenti per l'implementazione e best practice

1. Quando utilizzi Save-Data, fornisci alcuni dispositivi dell'interfaccia utente che lo supportano e consentono agli utenti di passare facilmente da un'esperienza all'altra. Ad esempio:
   • Informa gli utenti che Save-Data è supportato e incoraggiali a utilizzarlo.
   • Consenti agli utenti di identificare e scegliere la modalità con prompt appropriati e pulsanti o caselle di controllo on/off intuitivi.
   • Quando viene selezionata la modalità di risparmio dati, annuncia e fornisci un modo semplice e ovvio per disattivarla e tornare all'esperienza completa, se lo desideri.
2. Ricorda che le applicazioni leggere non sono applicazioni inferiori. Non omettono funzionalità o dati importanti, ma sono più consapevoli dei costi coinvolti e dell'esperienza utente. Ad esempio:
   • Un'applicazione per la galleria fotografica può fornire anteprime a risoluzione inferiore o utilizzare un meccanismo di carosello con meno codice.
   • Un'applicazione di ricerca può restituire meno risultati alla volta, limitare il numero di risultati con molti contenuti multimediali o ridurre il numero di dipendenze necessarie per il rendering della pagina.
   • Un sito orientato alle notizie può mostrare meno storie, omettere le categorie meno popolari o fornire anteprime multimediali più piccole.
3. Fornisci la logica del server per verificare l'intestazione della richiesta Save-Data e valuta la possibilità di fornire una risposta alternativa e più leggera della pagina quando è attivata, ad esempio riducendo il numero di risorse e dipendenze richieste, applicando una compressione delle risorse più aggressiva e così via.
   • Se pubblichi una risposta alternativa in base all'intestazione Save-Data, ricordati di aggiungerla all'elenco Vary — Vary: Save-Data — per indicare alle cache upstream che devono memorizzare nella cache e pubblicare questa versione solo se è presente l'intestazione della richiesta Save-Data. Per maggiori dettagli, consulta le best practice per l'interazione con le cache.
4. Se utilizzi un service worker, l'applicazione può rilevare quando l'opzione di risparmio dati è attivata verificando la presenza dell'intestazione della richiesta Save-Data o il valore della proprietà navigator.connection.saveData. Se è attivata, valuta se puoi riscrivere la richiesta per recuperare meno byte o utilizzare una risposta già recuperata.
5. Valuta la possibilità di aumentare Save-Data con altri segnali, ad esempio informazioni su tipo e tecnologia di connessione dell'utente (vedi API NetInfo). Ad esempio, potresti voler offrire l'esperienza leggera a qualsiasi utente con una connessione 2G, anche se Save-Data non è attivato. Al contrario, il fatto che l'utente abbia una connessione 4G "veloce" non significa che non sia interessato a salvare i dati, ad esempio in roaming. Inoltre, puoi aumentare la presenza di Save-Data con il suggerimento client Device-Memory per adattarti ulteriormente agli utenti su dispositivi con memoria limitata. La memoria del dispositivo dell'utente viene pubblicizzata anche nel suggerimento client navigator.deviceMemory.

Ricette

Ciò che puoi ottenere tramite Save-Data è limitato solo a ciò che ti viene in mente. Per darti un'idea di cosa è possibile fare, esaminiamo un paio di casi d'uso. Mentre leggi, potresti trovare altri casi d'uso, quindi non esitare a sperimentare e vedere cosa è possibile fare.

Verificare la presenza di Save-Data nel codice lato server

Sebbene lo stato Save-Data sia qualcosa che puoi rilevare in JavaScript tramite la proprietà navigator.connection.saveData, a volte è preferibile rilevarlo lato server. In alcuni casi, JavaScript potrebbe non essere eseguito. Inoltre, il rilevamento lato server è l'unico modo per modificare il markup prima che venga inviato al client, che è coinvolto in alcuni dei casi d'uso più vantaggiosi di Save-Data.

La sintassi specifica per rilevare l'intestazione Save-Data nel codice lato server dipende dal linguaggio utilizzato, ma l'idea di base dovrebbe essere la stessa per qualsiasi backend dell'applicazione. In PHP, ad esempio, le intestazioni delle richieste vengono memorizzate nell' $_SERVERarray superglobale negli indici che iniziano con HTTP_. Ciò significa che puoi rilevare l'intestazione Save-Data controllando l'esistenza e il valore della variabile $_SERVER["HTTP_SAVE_DATA"] come segue:

// false by default.
$saveData = false;

// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
  // `Save-Data` detected!
  $saveData = true;
}

Se inserisci questo controllo prima che venga inviato qualsiasi markup al client, la variabile $saveData conterrà lo stato Save-Data e sarà disponibile ovunque per l'utilizzo nella pagina. Dopo aver illustrato questo meccanismo, esaminiamo alcuni esempi di come possiamo utilizzarlo per limitare la quantità di dati che inviamo all'utente.

Pubblicare immagini a bassa risoluzione per schermi ad alta risoluzione

Un caso d'uso comune per le immagini sul web prevede la pubblicazione di immagini in set di due: un'immagine per gli schermi "standard" (1x) e un'altra immagine due volte più grande (2x) per gli schermi ad alta risoluzione (ad es. Retina Display). Questa classe di schermi ad alta risoluzione non è necessariamente limitata ai dispositivi di fascia alta e sta diventando sempre più comune. Nei casi in cui è preferibile un'esperienza applicativa più leggera, potrebbe essere prudente inviare immagini a risoluzione inferiore (1x) a questi schermi, anziché varianti più grandi (2x). Per ottenere questo risultato quando è presente l'intestazione Save-Data, modifichiamo semplicemente il markup che inviamo al client:

if ($saveData === true) {
  // Send a low-resolution version of the image for clients specifying `Save-Data`.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
  // Send the usual assets for everyone else.
  ?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}

Questo caso d'uso è un esempio perfetto di quanto sia facile soddisfare la richiesta di un utente di inviare meno dati. Se non ti piace modificare il markup sul backend, puoi ottenere lo stesso risultato utilizzando un modulo di riscrittura degli URL come quello di Apache mod_rewrite. Esistono esempi di come ottenere questo risultato con una configurazione relativamente semplice.

Puoi anche estendere questo concetto alle proprietà CSS background-image aggiungendo semplicemente una classe all'elemento <html>:

<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">

A questo punto, puoi scegliere come target la classe save-data nell'elemento <html> nel tuo CSS per modificare la modalità di pubblicazione delle immagini. Puoi inviare immagini di sfondo a bassa risoluzione agli schermi ad alta risoluzione, come mostrato nell'esempio HTML riportato sopra, oppure omettere del tutto alcune risorse.

Omettere le immagini non essenziali

Alcuni contenuti immagine sul web non sono essenziali. Sebbene queste immagini possano essere utili per i contenuti, potrebbero non essere desiderabili per chi cerca di ottenere il massimo dai piani dati a consumo. In quello che è forse il caso d'uso più semplice di Save-Data, possiamo utilizzare il codice di rilevamento PHP precedente e omettere del tutto il markup delle immagini non essenziali:

<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
  // Only send this image if `Save-Data` hasn't been detected.
  ?><img src="meme.jpg" alt="One does not simply consume data."><?php
}

Questa tecnica può sicuramente avere un effetto pronunciato, come puoi vedere nella figura seguente:

Naturalmente, l'omissione delle immagini non è l'unica possibilità. Puoi anche agire su Save-Data per evitare di inviare altre risorse non critiche, come determinati caratteri.

Omettere i caratteri web non essenziali

Sebbene i caratteri web di solito non rappresentino una parte significativa del payload totale di una determinata pagina come spesso fanno le immagini, sono comunque molto diffusi. Inoltre, non consumano una quantità di dati insignificante. Inoltre, il modo in cui i browser recuperano ed eseguono il rendering dei caratteri è più complicato di quanto si possa pensare, con concetti come FOIT, FOUT e le euristiche del browser che rendono il rendering un'operazione sfumata.

Potrebbe essere ragionevole quindi escludere i caratteri web non essenziali per gli utenti che desiderano esperienze utente più snelle. Save-Data rende questa operazione ragionevolmente semplice.

Ad esempio, supponiamo che tu abbia incluso Fira Sans da Google Fonts sul tuo sito. Fira Sans è un ottimo carattere per il corpo del testo, ma forse non è così fondamentale per gli utenti che cercano di risparmiare dati. Aggiungendo una classe save-data all'elemento <html> quando è presente l'intestazione Save-Data, possiamo scrivere stili che richiamano il carattere non essenziale all'inizio, ma poi lo escludono quando è presente l'intestazione Save-Data:

/* Opt into web fonts by default. */
p,
li {
  font-family: 'Fira Sans', 'Arial', sans-serif;
}

/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
  font-family: 'Arial', sans-serif;
}

Utilizzando questo approccio, puoi lasciare lo snippet <link> di Google Fonts al suo posto, perché il browser carica in modo speculativo le risorse CSS (inclusi i caratteri web) applicando prima gli stili al DOM e poi verificando se gli elementi HTML richiamano una delle risorse nel foglio di stile. Se qualcuno visita il sito con Save-Data attivato, Fira Sans non verrà mai caricato perché il DOM con lo stile non lo richiama mai. Verrà invece utilizzato Arial. Non è bello come Fira Sans, ma potrebbe essere preferibile per gli utenti che cercano di estendere i propri piani dati.

Riepilogo

L'intestazione Save-Data non ha molte sfumature: è attiva o disattivata e l'applicazione ha l'onere di fornire esperienze appropriate in base alla sua impostazione, indipendentemente dal motivo.

Ad esempio, alcuni utenti potrebbero non consentire la modalità di risparmio dati se sospettano che si verificherà una perdita di contenuti o funzionalità dell'app, anche in una situazione di scarsa connettività. Al contrario, alcuni utenti potrebbero attivarla di default per mantenere le pagine il più piccole e semplici possibile, anche in una situazione di buona connettività. È preferibile che l'app presupponga che l'utente voglia l'esperienza completa e illimitata finché non hai un'indicazione chiara del contrario tramite un'azione esplicita dell'utente.

In qualità di proprietari di siti e sviluppatori web, assumiamoci la responsabilità di gestire i nostri contenuti per migliorare l'esperienza utente per gli utenti con vincoli di dati e costi.

Per maggiori dettagli su Save-Data ed esempi pratici eccellenti, consulta Aiutare gli utenti a Save Data.