Adattarsi agli utenti con suggerimenti client

Jeremy Wagner

Sviluppare siti veloci ovunque può essere un'impresa difficile. La miriade di funzionalità dei dispositivi e la qualità delle reti a cui si connettono possono far sembrare l'impresa insormontabile. Sebbene possiamo sfruttare le funzionalità del browser per migliorare le prestazioni di caricamento, come facciamo a sapere le capacità del dispositivo dell'utente o la qualità della sua connessione di rete? La soluzione è suggerimenti client.

I suggerimenti client sono un insieme di intestazioni delle richieste HTTP con attivazione esplicita che ci forniscono informazioni su questi aspetti del dispositivo dell'utente e della rete a cui è connesso. Accedendo a queste informazioni lato server, possiamo modificare il modo in cui forniamo i contenuti in base alle condizioni del dispositivo e/o della rete. Questo può aiutarci a creare esperienze utente più inclusive.

Tutto dipende dalla negoziazione dei contenuti

I suggerimenti client sono un altro metodo di negoziazione dei contenuti, ovvero la modifica delle risposte dei contenuti in base alle intestazioni della richiesta del browser.

Un esempio di negoziazione dei contenuti riguarda l'intestazione della richiesta Accept. Descrive i tipi di contenuto che il browser comprende, che il server può utilizzare per negoziare la risposta. Per le richieste di immagini, i contenuti dell'intestazione Accept di Chrome sono:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

Mentre tutti i browser supportano formati di immagine come JPEG, PNG e GIF, Accept indica in questo caso che il browser supporta anche WebP e APNG. Utilizzando queste informazioni, possiamo negoziare i migliori tipi di immagini per ogni browser:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

Come Accept, i suggerimenti client sono un altro modo per negoziare i contenuti, ma nel contesto delle funzionalità del dispositivo e delle condizioni di rete. Con i suggerimenti client, possiamo prendere decisioni sul rendimento lato server in base all'esperienza individuale di un utente, ad esempio decidere se le risorse non critiche devono essere pubblicate per gli utenti con condizioni di rete scarse. In questa guida descriveremo tutti i suggerimenti disponibili e alcuni modi in cui puoi utilizzarli per rendere la distribuzione dei contenuti più adatta agli utenti.

Attivazione

A differenza dell'intestazione Accept, gli hint client non vengono visualizzati magicamente (con l'eccezione di Save-Data, di cui parleremo più avanti). Per ridurre al minimo le intestazioni delle richieste, devi attivare gli hint client che vuoi ricevere inviando un'intestazione Accept-CH quando un utente richiede una risorsa:

Accept-CH: Viewport-Width, Downlink

Il valore di Accept-CH è un elenco separato da virgole di suggerimenti richiesti che il sito utilizzerà per determinare i risultati per la richiesta di risorse successiva. Quando il client legge questa intestazione, gli viene comunicato che "questo sito vuole gli hint client Viewport-Width e Downlink". Non preoccuparti degli hint specifici. Ne parleremo tra poco.

Puoi impostare queste intestazioni di attivazione in qualsiasi lingua di backend. Ad esempio, è possibile utilizzare la funzione header di PHP. Puoi anche impostare queste intestazioni di attivazione con l'attributo http-equiv su un tag <meta>:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

Tutti i suggerimenti client.

Gli user agent client hints descrivono una di due cose: il dispositivo che gli utenti utilizzano e la rete che utilizzano per accedere al tuo sito. Vediamo brevemente tutti i suggerimenti disponibili.

Suggerimenti per i dispositivi

Alcuni suggerimenti client descrivono le caratteristiche del dispositivo dell'utente, in genere quelle dello schermo. Alcuni possono aiutarti a scegliere la risorsa multimediale ottimale per lo schermo di un determinato utente, ma non tutti sono necessariamente incentrati sui contenuti multimediali.

Prima di iniziare a leggere l'elenco, potrebbe essere utile conoscere alcuni termini chiave utilizzati per descrivere la risoluzione di schermi e contenuti multimediali:

Dimensioni intrinseche:le dimensioni effettive di una risorsa multimediale. Ad esempio, se apri un'immagine in Photoshop, le dimensioni mostrate nella finestra di dialogo delle dimensioni dell'immagine descrivono le sue dimensioni intrinseche.

Dimensioni intrinseche corrette per la densità: le dimensioni di una risorsa multimediale dopo la correzione per la densità di pixel. È la dimensione intrinseca dell'immagine divisa per un rapporto pixel dispositivo. Ad esempio, prendiamo questo markup:

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

Supponiamo che le dimensioni intrinseche dell'immagine 1x in questo caso siano 320 x 240 e che quelle dell'immagine 2x siano 640 x 480. Se questo markup viene analizzato da un client installato su un dispositivo con un rapporto pixel del dispositivo schermo di 2 (ad es. uno schermo Retina), viene richiesta l'immagine 2x. Le dimensioni intrinseche corrette per la densità dell'immagine 2x sono 320 x 240, poiché 640 x 480 diviso per 2 è 320 x 240.

Dimensioni estrinseche:le dimensioni di una risorsa multimediale dopo l'applicazione di CSS e altri fattori di layout (come gli attributi width e height). Supponiamo di avere un elemento <img> che carica un'immagine con una dimensione intrinseca corretta per la densità di 320 x 240, ma ha anche proprietà CSS width e height con valori 256px e 192px applicati, rispettivamente. In questo esempio, la dimensione estrinseca dell'elemento <img> diventa 256 x 192.

Dopo aver chiarito alcuni termini, passiamo all'elenco dei suggerimenti client specifici per dispositivo disponibili.

Viewport-Width

Viewport-Width è la larghezza dell'area visibile dell'utente in pixel CSS:

Viewport-Width: 320

Questo suggerimento può essere utilizzato con altri suggerimenti specifici per lo schermo per fornire trattamenti diversi (ad esempio ritagli) di un'immagine ottimali per dimensioni dello schermo specifiche (ad esempio direzione artistica) o per omettere risorse non necessarie per la larghezza dello schermo corrente.

DPR

DPR, abbreviazione di rapporto pixel del dispositivo, indica il rapporto tra i pixel fisici e i pixel CSS dello schermo dell'utente:

DPR: 2

Questo suggerimento è utile quando selezioni origini immagini che corrispondono alla densità di pixel di uno schermo (come fanno i descrittori x nell'attributo srcset).

Larghezza

Il suggerimento Width viene visualizzato nelle richieste di risorse immagine attivate dai tag <img> o <source> che utilizzano l'attributo sizes. sizes indica al browser le dimensioni estrinseche della risorsa; Width utilizza le dimensioni estrinseche per richiedere un'immagine con dimensioni intrinseche ottimali per il layout corrente.

Ad esempio, supponiamo che un utente richieda una pagina con uno schermo largo 320 pixel CSS con un DPR di 2. Il dispositivo carica un documento con un elemento <img> contenente un valore dell'attributo sizes pari a 85vw (ad es. 85% della larghezza dell'area visibile per tutte le dimensioni dello schermo). Se il suggerimento Width è stato attivato, il client invierà questo suggerimento Width al server con la richiesta di src di <img>:

Width: 544

In questo caso, il client suggerisce al server che una larghezza intrinseca ottimale per l'immagine richiesta sarebbe l'85% della larghezza del riquadro (272 pixel) moltiplicato per il DPR dello schermo (2), che equivale a 544 pixel.

Questo suggerimento è particolarmente efficace perché non solo tiene conto della larghezza dello schermo corretta in base alla densità, ma riconcilia anche questo elemento fondamentale con le dimensioni estrinseche dell'immagine all'interno del layout. In questo modo, i server hanno l'opportunità di negoziare risposte di immagini ottimali sia per lo schermo che per il layout.

Content-DPR

Come sai, gli schermi hanno un rapporto pixel del dispositivo, ma anche le risorse hanno i propri rapporti pixel. Nei casi d'uso più semplici di selezione delle risorse, i rapporti tra pixel di dispositivi e risorse possono essere gli stessi. Ma… Nei casi in cui sono in gioco sia le intestazioni DPR che Width, le dimensioni estrinseche di una risorsa possono produrre scenari in cui le due differiscono. È qui che entra in gioco il suggerimento Content-DPR.

A differenza di altri suggerimenti client, Content-DPR non è un'intestazione di richiesta da utilizzare dai server, ma un'intestazione di risposta che i server devono inviare ogni volta che i suggerimenti DPR e Width vengono utilizzati per selezionare una risorsa. Il valore di Content-DPR deve essere il risultato di questa equazione:

Content-DPR = [Dimensione risorsa immagine selezionata] / ([Width] / [DPR])

Quando viene inviata un'intestazione della richiesta Content-DPR, il browser saprà come scalare l'immagine specificata in base al rapporto tra pixel del dispositivo dello schermo e al layout. Senza questo valore, le immagini potrebbero non essere scalate correttamente.

Device-Memory

Tecnicamente parte dell'API Device Memory, Device-Memory rivela la quantità approssimativa di memoria di cui dispone il dispositivo attuale in GiB:

Device-Memory: 2

Un possibile caso d'uso per questo suggerimento sarebbe quello di ridurre la quantità di JavaScript inviato ai browser sui dispositivi con memoria limitata, in quanto JavaScript è il tipo di contenuto che richiede più risorse che i browser in genere caricano. In alternativa, puoi inviare immagini con un valore DPR inferiore, in quanto utilizzano meno memoria per la decodifica.

Suggerimenti per la rete

L'API Network Information fornisce un'altra categoria di suggerimenti client che descrivono le prestazioni della connessione di rete dell'utente. A mio parere, questi sono i suggerimenti più utili. Con loro, abbiamo la possibilità di personalizzare le esperienze per gli utenti modificando il modo in cui forniamo risorse ai client con connessioni lente.

RTT

Il suggerimento RTT fornisce il tempo di round trip approssimativo, in millisecondi, sul livello applicazione. Il suggerimento RTT, a differenza dell'RTT del livello di trasporto, include il tempo di elaborazione del server.

RTT: 125

Questo suggerimento è utile perché la latenza svolge un ruolo importante nelle prestazioni di caricamento. Utilizzando il suggerimento RTT, possiamo prendere decisioni in base alla reattività della rete, il che può contribuire ad accelerare la distribuzione di un'intera esperienza (ad es. tramite l'omissione di alcune richieste).

Downlink

Sebbene la latenza sia importante per le prestazioni di caricamento, anche la larghezza di banda è influente. Il suggerimento Downlink, espresso in megabit al secondo (Mbps), rivela la velocità di download approssimativa della connessione dell'utente:

Downlink: 2.5

Insieme a RTT, Downlink può essere utile per modificare il modo in cui i contenuti vengono distribuiti agli utenti in base alla qualità di una connessione di rete.

ECT

Il suggerimento ECT sta per Tipo effettivo di connessione. Il suo valore è uno di un elenco enumerato di tipi di connessione, ognuno dei quali descrive una connessione all'interno di intervalli specificati di valori RTT e Downlink.

Questa intestazione non spiega qual è il tipo di connessione effettivo. Ad esempio, non indica se il gateway è una torre cellulare o un punto di accesso Wi-Fi. Analizza invece la latenza e la larghezza di banda della connessione corrente e determina a quale profilo di rete assomiglia di più. Ad esempio, se ti connetti tramite Wi-Fi a una rete lenta, ECT potrebbe essere compilato con un valore di 2g, che è l'approssimazione più vicina della connessione effettiva:

ECT: 2g

I valori validi per ECT sono 4g, 3g, 2g e slow-2g. Questo suggerimento può essere utilizzato come punto di partenza per valutare la qualità della connessione e successivamente perfezionato utilizzando i suggerimenti RTT e Downlink.

Save-Data

Save-Data non è tanto un suggerimento che descrive le condizioni di rete quanto una preferenza dell'utente che indica che le pagine devono inviare meno dati.

Preferisco classificare Save-Data come suggerimento di rete perché molte delle cose che faresti con questo suggerimento sono simili ad altri suggerimenti di rete. Gli utenti potrebbero anche attivarla in ambienti con latenza elevata/larghezza di banda ridotta. Questo suggerimento, se presente, ha sempre questo aspetto:

Save-Data: on

In Google, abbiamo parlato di cosa puoi fare con Save-Data. L'impatto sulle prestazioni può essere profondo. È un segnale in cui gli utenti ti chiedono letteralmente di inviargli meno contenuti. Se ascolti e agisci in base a questo segnale, gli utenti lo apprezzeranno.

Il mix perfetto

Ciò che fai con i suggerimenti per i client dipende da te. Poiché offrono molte informazioni, hai molte opzioni. Per trovare qualche idea, vediamo cosa possono fare gli hint client per Sconnie Timber, un'azienda fittizia di legname situata nel Midwest rurale. Come spesso accade nelle aree remote, le connessioni di rete possono essere instabili. È qui che una tecnologia come i suggerimenti client può fare davvero la differenza per gli utenti.

Immagini adattabili

Tutti i casi d'uso delle immagini adattabili, tranne quelli più semplici, possono diventare complicati. Cosa succede se hai più trattamenti e varianti delle stesse immagini per diverse dimensioni dello schermo e formati diversi? Questo markup diventa molto complicato molto velocemente. È facile sbagliare, dimenticare o fraintendere concetti importanti (come sizes).

Anche se <picture> e srcset sono strumenti eccezionali, possono richiedere molto tempo per lo sviluppo e la manutenzione per casi d'uso complessi. Possiamo automatizzare la generazione del markup, ma farlo è difficile perché la funzionalità <picture> e srcset è abbastanza complessa da richiedere un'automazione che mantenga la flessibilità che offre.

I suggerimenti client possono semplificare questa operazione. La negoziazione delle risposte con immagini con i suggerimenti del client potrebbe avere il seguente aspetto:

1. Se applicabile al tuo flusso di lavoro, seleziona innanzitutto un trattamento dell'immagine (ad es. immagini con direzione artistica) selezionando il suggerimento Viewport-Width.
2. Seleziona una risoluzione dell'immagine controllando il suggerimento Width e il suggerimento DPR e scegli una sorgente adatta alle dimensioni del layout dell'immagine e alla densità dello schermo (in modo simile al funzionamento dei descrittori x e w in srcset).
3. Seleziona il formato di file più ottimale supportato dal browser (operazione che Accept ci aiuta a fare nella maggior parte dei browser).

Per quanto riguarda il mio cliente fittizio, un'azienda di legname, ho sviluppato una routine di selezione delle immagini adattabile in PHP che utilizza i suggerimenti client. Ciò significava che invece di inviare questo markup a tutti gli utenti:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

Sono riuscito a ridurlo al seguente in base al supporto dei singoli browser:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

In questo esempio, l'URL /image è uno script PHP seguito da parametri riscritti da mod_rewrite. Prende un nome file immagine e parametri aggiuntivi per aiutare uno script di backend a scegliere l'immagine migliore nelle condizioni date.

Intuisco che la tua prima domanda sia: "Ma non si tratta solo di reimplementare <picture> e srcset nel backend?"

In un certo senso sì, ma con una distinzione importante: quando un'applicazione utilizza i suggerimenti per i client per creare risposte multimediali, la maggior parte (se non tutto) del lavoro è molto più facile da automatizzare, il che può includere un servizio (come una CDN) che può farlo per tuo conto. Con le soluzioni HTML, invece, è necessario scrivere un nuovo markup per prevedere ogni caso d'uso. Certo, puoi automatizzare la generazione del markup. Se però il tuo design o i tuoi requisiti cambiano, è molto probabile che in futuro dovrai rivedere la tua strategia di automazione.

I suggerimenti client consentono di iniziare con un'immagine ad alta risoluzione senza perdita di qualità che può essere ridimensionata dinamicamente per essere ottimale per qualsiasi combinazione di schermo e layout. A differenza di srcset, che richiede di enumerare un elenco fisso di possibili immagini candidate tra cui il browser può scegliere, questo approccio può essere più flessibile. Mentre srcset ti costringe a offrire ai browser un insieme grossolano di varianti, ad esempio 256w, 512w, 768w e 1024w, una soluzione basata sugli hint client può pubblicare tutte le larghezze, senza un'enorme quantità di markup.

Naturalmente, non devi scrivere tu la logica di selezione delle immagini. Cloudinary utilizza i suggerimenti client per creare risposte alle immagini quando utilizzi il parametro w_auto e ha osservato che gli utenti medi hanno scaricato il 42% di byte in meno quando utilizzano browser che supportano i suggerimenti client.

Ma fai attenzione: Le modifiche apportate alla versione desktop di Chrome 67 hanno rimosso il supporto per i suggerimenti client cross-origin. Fortunatamente, queste limitazioni non influiscono sulle versioni mobile di Chrome e verranno rimosse del tutto per tutte le piattaforme al termine del lavoro sulle norme relative alle funzionalità.

Aiutare gli utenti con reti lente

Adaptive Performance è l'idea che possiamo modificare il modo in cui forniamo le risorse in base alle informazioni che i suggerimenti client ci mettono a disposizione, in particolare le informazioni sullo stato attuale della connessione di rete dell'utente.

Per quanto riguarda il sito di Sconnie Timber, adottiamo misure per ridurre il carico quando le reti sono lente, con le intestazioni Save-Data, ECT, RTT e Downlink esaminate nel nostro codice di backend. Al termine, generiamo un punteggio di qualità della rete che possiamo utilizzare per determinare se intervenire per migliorare l'esperienza utente. Il punteggio di rete è compreso tra 0 e 1, dove 0 è la qualità di rete peggiore possibile e 1 è la migliore.

Inizialmente, controlliamo se è presente Save-Data. In questo caso, il punteggio viene impostato su 0, in quanto presumiamo che l'utente voglia che facciamo tutto il necessario per rendere l'esperienza più leggera e veloce.

Se Save-Data è assente, tuttavia, andiamo avanti e valutiamo i valori dei suggerimenti ECT, RTT e Downlink per calcolare un punteggio che descriva la qualità della connessione di rete. Il codice sorgente per la generazione del punteggio di rete è disponibile su GitHub. Il punto è che, se utilizziamo i suggerimenti relativi alla rete in qualche modo, possiamo migliorare l'esperienza per chi utilizza reti lente.

Quando i siti si adattano alle informazioni fornite dai suggerimenti client, non dobbiamo adottare un approccio "tutto o niente". Possiamo decidere in modo intelligente quali risorse inviare. Possiamo modificare la nostra logica di selezione delle immagini adattabili per inviare immagini di qualità inferiore per un determinato display per velocizzare le prestazioni di caricamento quando la qualità della rete è scarsa.

In questo esempio, possiamo vedere l'impatto degli hint client sul miglioramento del rendimento dei siti su reti più lente. Di seguito è riportato un diagramma a cascata di WebPagetest di un sito su una rete lenta che non si adatta ai suggerimenti del client:

Ora, una cascata per lo stesso sito sulla stessa connessione lenta, tranne che questa volta il sito utilizza i suggerimenti client per eliminare le risorse della pagina non critiche:

I suggerimenti client hanno ridotto il tempo di caricamento della pagina da oltre 45 secondi a meno di un decimo di questo tempo. I vantaggi dei suggerimenti client in questo scenario non possono essere sottolineati abbastanza e possono essere un vantaggio significativo per gli utenti che cercano informazioni critiche su reti lente.

Inoltre, è possibile utilizzare gli hint client senza interrompere l'esperienza per i browser che non li supportano. Ad esempio, se vogliamo regolare la distribuzione delle risorse utilizzando il valore del suggerimento ECT, continuando a offrire l'esperienza completa per i browser non supportati, possiamo impostare il fallback su un valore predefinito come segue:

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

In questo caso, "4g" rappresenta la connessione di rete di qualità più elevata descritta dall'intestazione ECT. Se inizializziamo $ect su "4g", i browser che non supportano i suggerimenti client non saranno interessati. Attivazione FTW!

Attenzione alle cache!

Ogni volta che modifichi una risposta in base a un'intestazione HTTP, devi tenere presente in che modo le cache gestiranno i recuperi futuri per quella risorsa. L'intestazione Vary è indispensabile qui, in quanto associa le voci della cache al valore delle intestazioni della richiesta fornite. In parole semplici, se modifichi una risposta in base a una determinata intestazione della richiesta HTTP, devi quasi sempre includere l'intestazione nella richiesta Vary come segue:

Vary: DPR, Width

Tuttavia, c'è un grande avvertimento: non vuoi mai Vary risposte memorizzabili nella cache su un'intestazione che cambia frequentemente (come Cookie) perché queste risorse diventano effettivamente non memorizzabili nella cache. Per questo motivo, ti consigliamo di evitare di Varyfare affidamento su intestazioni di suggerimenti client come RTT o Downlink, perché si tratta di fattori di connessione che potrebbero cambiare molto spesso. Se vuoi modificare le risposte in queste intestazioni, valuta la possibilità di utilizzare solo l'intestazione ECT, che ridurrà al minimo gli errori della cache.

Naturalmente, questo vale solo se memorizzi nella cache una risposta. Ad esempio, non memorizzerai nella cache gli asset HTML se i loro contenuti sono dinamici, perché ciò può compromettere l'esperienza utente durante le visite ripetute. In questi casi, sentiti libero di modificare queste risposte in base a ciò che ritieni necessario e non preoccuparti di Vary.

Suggerimenti client nei service worker

La negoziazione dei contenuti non è più solo per i server. Poiché i service worker fungono da proxy tra i client e i server, hai il controllo su come le risorse vengono distribuite tramite JavaScript. Sono inclusi gli hint client. Nell'evento fetch del service worker, puoi utilizzare il metodo request.headers.get dell'oggetto event per leggere le intestazioni della richiesta di una risorsa nel seguente modo:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

Qualsiasi intestazione di suggerimento client a cui acconsenti può essere letta in questo modo. Tuttavia, non è l'unico modo per ottenere alcune di queste informazioni. I suggerimenti specifici per la rete possono essere letti in queste proprietà JavaScript equivalenti nell'oggetto navigator:

Poiché queste API non sono disponibili ovunque, devi verificare la funzionalità con l'operatore in:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

Da qui, puoi utilizzare una logica simile a quella che useresti sul server, tranne per il fatto che non hai bisogno di un server per negoziare i contenuti con i suggerimenti client. I service worker hanno il potere di rendere le esperienze più veloci e resilienti grazie alla capacità aggiuntiva di pubblicare contenuti quando l'utente è offline.

In sintesi

Con i suggerimenti client, abbiamo la possibilità di rendere le esperienze più veloci per gli utenti in modo completamente progressivo. Possiamo pubblicare contenuti multimediali in base alle funzionalità del dispositivo dell'utente in modo da semplificare la pubblicazione di immagini adattabili rispetto all'utilizzo di <picture> e srcset, soprattutto per i casi d'uso complessi. Ciò ci consente non solo di ridurre i tempi e gli sforzi per lo sviluppo, ma anche di ottimizzare le risorse, in particolare le immagini, in modo da adattarle in modo più preciso agli schermi degli utenti rispetto a quanto possibile con e srcset.

Ancora più importante, possiamo rilevare connessioni di rete scadenti e colmare il divario per gli utenti modificando ciò che inviamo e come lo inviamo. Questo può contribuire notevolmente a rendere i siti più accessibili agli utenti su reti instabili. In combinazione con i service worker, possiamo creare siti incredibilmente veloci disponibili offline.

Anche se gli hint client sono disponibili solo in Chrome e nei browser basati su Chromium, è possibile utilizzarli in modo da non ostacolare i browser che non li supportano. Valuta la possibilità di utilizzare i suggerimenti client per creare esperienze veramente inclusive e adattabili che tengano conto delle funzionalità del dispositivo di ogni utente e delle reti a cui si connette. Ci auguriamo che altri fornitori di browser ne vedano il valore e mostrino l'intenzione di implementarli.

Risorse

• Immagini adattabili automatiche con suggerimenti per i client
• Client Hints e immagini adattabili: cosa è cambiato in Chrome 67
• Prendi un (client) hint! (Presentazioni)
• Pubblicazione di applicazioni veloci e leggere con Save-Data

Grazie a Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss ed Estelle Weyl per i loro preziosi feedback e modifiche a questo articolo.