Adattarsi agli utenti con suggerimenti client

Sviluppare siti veloci dappertutto può essere una prospettiva complicata. La varietà di funzionalità dei dispositivi e la qualità delle reti a cui si connettono possono sembrare un compito insormontabile. Possiamo sfruttare le funzionalità del browser per migliorare le prestazioni di caricamento, ma come facciamo a sapere di cosa è capace il dispositivo dell'utente o la qualità della sua connessione di rete? La soluzione sono i suggerimenti clienti.

I client hint sono un insieme di intestazioni di richieste HTTP con attivazione che ci forniscono informazioni su questi aspetti del dispositivo dell'utente e della rete a cui è connesso. Grazie a queste informazioni lato server, possiamo modificare la modalità di pubblicazione dei contenuti in base alle condizioni del dispositivo e/o della rete. Questo può aiutarci a creare esperienze utente più inclusive.

Tutto sta nella negoziazione dei contenuti

I client hint sono un altro metodo di negoziazione dei contenuti, che comporta la modifica delle risposte dei contenuti in base alle intestazioni delle richieste del browser.

Un esempio di negoziazione di contenuti riguarda l'intestazione della richiesta Accept. Descrive quali tipi di contenuti sono compresi dal browser e 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

Sebbene tutti i browser supportino formati dell'immagine come JPEG, PNG e GIF, Accetta indica in questo caso che il browser supporta anche WebP e APNG. Grazie a queste informazioni, possiamo negoziare i tipi di immagine migliori 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 client hint sono un altro modo per negoziare i contenuti, ma nel contesto delle funzionalità del dispositivo e delle condizioni della rete. Con i hint del client, possiamo prendere decisioni relative alle prestazioni lato server in base all'esperienza individuale di un utente, ad esempio decidendo se fornire risorse non critiche agli utenti con condizioni di rete scadenti. In questa guida, descriveremo tutti i suggerimenti disponibili e spiegheremo come utilizzarli per rendere l'importazione dei contenuti più adatta agli utenti.

Attivazione

A differenza dell'intestazione Accept, i suggerimenti del client non appaiono magicamente (ad eccezione di Save-Data, di cui parleremo più avanti). Per mantenere al minimo le intestazioni delle richieste, devi scegliere quali suggerimenti del client 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 successiva richiesta di risorse. Quando il cliente legge questa intestazione, viene visualizzato il messaggio "Questo sito richiede i suggerimenti cliente Viewport-Width e Downlink". Non preoccuparti dei suggerimenti specifici. Li vedremo tra poco.

Puoi impostare queste intestazioni di attivazione in qualsiasi lingua back-end. Ad esempio, potrebbe essere utilizzata la funzione header di PHP. Puoi anche impostare queste intestazioni di attivazione con l'attributo http-equiv in un tag <meta>:

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

Tutti i suggerimenti per il cliente.

I client hint descrivono due cose: il dispositivo utilizzato dagli utenti e la rete che utilizzano per accedere al tuo sito. Esaminiamo brevemente tutti i suggerimenti disponibili.

Suggerimenti sul dispositivo

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

Prima di entrare in questo elenco, potrebbe essere utile conoscere alcuni termini chiave utilizzati per descrivere gli schermi e la risoluzione dei 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 Dimensioni dell'immagine ne descrivono la dimensione intrinseca.

Dimensioni intrinseche corrette per densità: le dimensioni di una risorsa multimediale dopo che è stata corretta per tenere conto della densità dei pixel. Si tratta delle dimensioni intrinseche dell'immagine divise per la percentuale di pixel del 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 la dimensione intrinseca dell'immagine 2x sia 640 x 480. Se questo markup viene analizzato da un client installato su un dispositivo con un rapporto pixel del dispositivo dello schermo pari a 2 (ad esempio uno schermo Retina), viene richiesta l'immagine 2x. La dimensione intrinseca corretta della densità dell'immagine 2x è 320 x 240, poiché 640 x 480 divisa per 2 è 320 x 240.

Dimensioni estrinseche: la dimensione di una risorsa multimediale dopo che sono stati applicati al CSS e ad 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 con la densità di 320 x 240, ma che presenta anche proprietà CSS width e height a cui sono applicati rispettivamente i valori 256px e 192px. In questo esempio, la dimensione estrinseca dell'elemento <img> diventa 256 x 192.

Partendo da una terminologia specifica, analizziamo l'elenco di suggerimenti per i clienti specifici per dispositivo.

Larghezza area visibile

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

Viewport-Width: 320

Questo suggerimento può essere utilizzato con altri suggerimenti specifici dello schermo per fornire diversi trattamenti (ad es. ritagli) di un'immagine ottimali per specifiche dimensioni dello schermo (ovvero direzioni artistiche) oppure per omettere risorse non necessarie per la larghezza dello schermo corrente.

RPG

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

DPR: 2

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

Larghezza

Il suggerimento Width viene visualizzato per le richieste di risorse immagine attivate dai tag <img> o <source> utilizzando l'attributo sizes. sizes indica al browser quali saranno le dimensioni estrinseche della risorsa; Width utilizza questa dimensione estrinseca per richiedere un'immagine con una dimensione intrinseca ottimale per il layout corrente.

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

Width: 544

In questo caso, il client indica al server che una larghezza intrinseca ottimale per l'immagine richiesta sarebbe l'85% della larghezza dell'area visibile (272 pixel), moltiplicata 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 questa informazione fondamentale con le dimensioni estrinseche dell'immagine all'interno del layout. Ciò offre ai server l'opportunità di negoziare risposte dell'immagine ottimali sia per lo schermo sia per il layout.

Contenuti-RPD

Sebbene tu sappia già che gli schermi hanno un rapporto pixel del dispositivo, le risorse hanno anche proporzioni proprie. Nei casi d'uso più semplici per la selezione delle risorse, le proporzioni pixel tra dispositivi e risorse possono essere le stesse. Ma! Nei casi in cui sono in riproduzione entrambe le intestazioni DPR e Width, la dimensione estrinseca di una risorsa può generare scenari in cui le due sono diverse. È qui che entra in gioco il suggerimento Content-DPR.

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

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

Quando viene inviata l'intestazione di una richiesta Content-DPR, il browser saprà come ridimensionare l'immagine specificata in base alle proporzioni pixel del dispositivo e al layout dello schermo. Senza di esso, le immagini potrebbero non essere ridimensionate correttamente.

Memoria dispositivo

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

Device-Memory: 2

Un possibile caso d'uso per questo suggerimento potrebbe essere la riduzione della quantità di JavaScript inviata ai browser sui dispositivi con memoria limitata, poiché JavaScript è il browser di tipi di contenuti che richiede più risorse e viene generalmente caricato. In alternativa, potresti inviare immagini con DPR inferiore, perché utilizzano meno memoria per la decodifica.

Suggerimenti sulla 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 gli insiemi più utili di suggerimenti. Questi strumenti sono in grado di personalizzare l'esperienza degli utenti cambiando il modo in cui forniamo risorse ai clienti con connessioni lente.

RTT

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

RTT: 125

Questo suggerimento è utile perché la latenza gioca un ruolo importante nelle prestazioni di caricamento. Utilizzando il suggerimento RTT, possiamo prendere decisioni basate sulla reattività della rete, il che può contribuire a velocizzare la distribuzione di un'intera esperienza (ad esempio, l'omissione di alcune richieste).

Downlink

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

Downlink: 2.5

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

ECT

Il suggerimento ECT sta per Effective Connection Type. Il suo valore fa parte di un elenco enumerato di tipi di connessione, ognuno dei quali descrive una connessione in intervalli specificati di entrambi i valori RTT e Downlink.

Questa intestazione non spiega il tipo di connessione effettivo, ad esempio non indica se il gateway è un ripetitore di telefonia mobile o un punto di accesso Wi-Fi. Piuttosto, analizza la latenza e la larghezza di banda della connessione attuale e determina il profilo di rete a cui è più simile. Ad esempio, se ti connetti tramite Wi-Fi a una rete lenta, ECT potrebbe essere compilato con il valore 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 hint RTT e Downlink.

Salva dati

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

Preferisco classificare Save-Data come suggerimento di rete, perché molte delle operazioni che si possono eseguire sono simili ad altri hint di rete. È probabile che gli utenti lo abilitino anche in ambienti con latenza elevata/bassa larghezza di banda. Se presente, il suggerimento è sempre simile al seguente:

Save-Data: on

Qui in Google, abbiamo parlato di cosa puoi fare con Save-Data. L'impatto che può avere sul rendimento può essere molto profondo. È un indicatore del fatto che gli utenti ti chiedono letteralmente di inviare loro meno informazioni. Se ascolti e intervieni sul segnale, gli utenti lo apprezzeranno.

Il mix perfetto

Le operazioni che fai con i suggerimenti dei clienti dipende da te. Poiché offrono così tante informazioni, hai molte opzioni. Per un po' di idee, vediamo cosa possono fare i suggerimenti ai clienti per Sconnie Timber, un'azienda fittizia di legname situata nelle zone rurali dell'Upper Midwest. Come spesso accade nelle aree remote, le connessioni di rete possono essere fragili. È qui che una tecnologia come i suggerimenti dei clienti può fare davvero la differenza.

Immagini adattabili

Tutti i casi d'uso delle immagini adattabili, tranne i più semplici, possono essere complicati. E se hai più trattamenti e varianti delle stesse immagini per schermi di dimensioni diverse e formati diversi? Questo markup diventa molto complicato molto rapidamente. È facile sbagliare ed è facile dimenticare o fraintendere concetti importanti (come sizes).

Anche se <picture> e srcset sono strumenti innegabilmente fantastici, la loro gestione e sviluppo per casi d'uso complessi possono richiedere molto tempo. Possiamo automatizzare la generazione del markup, ma farlo è anche difficile perché le funzionalità fornite da <picture> e srcset sono sufficientemente complesse da rendere necessaria l'automazione in modo da mantenere la flessibilità offerta.

I suggerimenti del cliente possono semplificare questo processo. La negoziazione delle risposte di immagini con i suggerimenti dei clienti potrebbe essere simile al seguente:

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

Per quanto riguardava il mio cliente fittizio di produzione di legname, ho sviluppato una routine ingenua di selezione reattiva delle immagini in PHP che utilizza i suggerimenti client. Ciò significava anziché 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>

In base al supporto dei singoli browser, ho potuto ridurlo a quanto segue:

<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. Sono necessari un nome file dell'immagine e parametri aggiuntivi per consentire a uno script di backend di scegliere l'immagine migliore nelle condizioni specificate.

Ho la sensazione che "Ma non è solo reimplementare <picture> e srcset nel back-end?" è la tua prima domanda.

In un certo senso, ma con una distinzione importante: quando un'applicazione utilizza suggerimenti del client per creare risposte multimediali, la maggior parte (se non tutte) il lavoro è molto più facile da automatizzare, ad esempio un servizio (ad esempio una CDN) che può farlo per tuo conto. Invece, con le soluzioni HTML, è necessario scrivere nuovi markup per fornire ogni caso d'uso. Certo, puoi automatizzare la generazione del markup. Tuttavia, se il tuo design o i tuoi requisiti cambiano, ci sono buone probabilità che dovrai rivedere la tua strategia di automazione in futuro.

I client hint consentono di iniziare con un'immagine senza perdita di dati e ad alta risoluzione, che può essere ridimensionata in modo dinamico per essere ottimale per qualsiasi combinazione di schermo e layout. A differenza di srcset, che richiede di enumerare un elenco fisso di possibili immagini da scegliere dal browser, questo approccio può essere più flessibile. Mentre srcset ti obbliga a offrire ai browser un insieme approssimativo di varianti, ad esempio 256w, 512w, 768w e 1024w, una soluzione basata sui client in grado di gestire tutte le larghezze, senza una mole di markup.

Naturalmente, non è necessario scrivere autonomamente la logica di selezione delle immagini. Cloudinary utilizza i suggerimenti client per creare risposte di immagini quando si utilizza il parametro w_auto e ha osservato che gli utenti mediani hanno scaricato il 42% di byte in meno quando utilizzano browser che supportano i client hint.

Ma fai attenzione. Le modifiche nella versione desktop di Chrome 67 hanno rimosso il supporto per i suggerimenti client multiorigine. Fortunatamente, queste limitazioni non interessano le versioni mobile di Chrome e verranno rimosse del tutto per tutte le piattaforme una volta che l'impostazione Feature Policy sarà completata.

Aiutare gli utenti che utilizzano reti lente

Il concetto di prestazioni adattive consiste nell'adeguare il modo in cui pubblichiamo le risorse in base alle informazioni che ci vengono messe a disposizione dai client, in particolare le informazioni relative allo stato attuale della connessione di rete dell'utente.

Per quanto riguarda il sito di Sconnie Timber, adottiamo misure per alleggerire il carico quando le reti sono lente e le intestazioni Save-Data, ECT, RTT e Downlink vengono esaminate nel nostro codice back-end. Una volta eseguita questa operazione, generiamo un punteggio di qualità della rete che possiamo utilizzare per determinare se è necessario intervenire per migliorare l'esperienza utente. Questo punteggio di rete è compreso tra 0 e 1, dove 0 è la peggiore qualità di rete possibile e 1 è la migliore.

Inizialmente, controlliamo la presenza di Save-Data. In questo caso, il punteggio è impostato su 0, perché supponiamo che l'utente voglia che facciamo tutto il necessario per rendere l'esperienza più leggera e veloce.

Se Save-Data non è presente, tuttavia, passiamo oltre e pesiamo 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 dei punteggi di rete è disponibile su GitHub. Il punto è che, utilizzando i suggerimenti relativi alla rete in qualche modo, possiamo migliorare l'esperienza di chi fa uso di reti lente.

Quando i siti si adattano alle informazioni fornite dai suggerimenti dei clienti, 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 a un determinato display in modo da velocizzare le prestazioni di caricamento quando la qualità della rete è scadente.

In questo esempio, possiamo vedere l'impatto dei suggerimenti dei clienti quando si tratta di migliorare le prestazioni dei siti su reti più lente. Di seguito è riportata una struttura a cascata WebPagetest di un sito su una rete lenta che non si adatta agli hint dei client:

Ora è presente una struttura a cascata per lo stesso sito nella stessa connessione lenta. Questa volta il sito utilizza i suggerimenti del client per eliminare risorse della pagina non critiche:

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

Inoltre, è possibile utilizzare i suggerimenti client senza interrompere l'esperienza per i browser che non li supportano. Ad esempio, se vogliamo modificare la pubblicazione delle risorse utilizzando il valore del suggerimento ECT, continuando a offrire l'esperienza completa per i browser che non supportano, possiamo impostare un valore predefinito come questo:

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

Qui, "4g" rappresenta la connessione di rete di più alta qualità descritta dall'intestazione ECT. Se inizializzamo $ect in "4g", i browser che non supportano i suggerimenti client non saranno interessati. Attiva FTW

Attenti a quelle cache!

Ogni volta che modifichi una risposta basata su un'intestazione HTTP, devi sapere in che modo le cache gestiranno i recuperi futuri della risorsa. L'intestazione Vary è indispensabile in questo caso, poiché chiave che memorizza le voci nella cache per il valore delle intestazioni delle richieste fornite. In breve, se modifichi una risposta in base a una determinata intestazione della richiesta HTTP, dovresti quasi sempre includere la richiesta in questione in Vary, in questo modo:

Vary: DPR, Width

C'è un'importante allerta a questo proposito, tuttavia: non vuoi mai Vary risposte memorizzabili nella cache per un'intestazione che cambia di frequente (come Cookie) perché queste risorse diventano effettivamente non memorizzabili nella cache. Sapendo questo, è consigliabile evitare di utilizzare Vary nelle intestazioni dei hint del client come RTT o Downlink, perché questi sono fattori di connessione che potrebbero cambiare abbastanza spesso. Se vuoi modificare le risposte su queste intestazioni, ti consigliamo di inserire solo l'intestazione ECT, che ridurrà al minimo i fallimenti della cache.

Ovviamente, questo si applica solo se inizialmente devi memorizzare una risposta nella cache. Ad esempio, se il contenuto è dinamico, gli asset HTML non vengono memorizzati nella cache, in quanto ciò potrebbe interrompere l'esperienza utente in caso di visite ripetute. In questi casi, puoi modificare queste risposte in base alle tue esigenze, senza preoccuparti di Vary.

Suggerimenti client nei service worker

La negoziazione dei contenuti non è più riservata ai server. Poiché i service worker fungono da proxy tra i client e i server, puoi controllare la modalità di distribuzione delle risorse tramite JavaScript. Sono inclusi i suggerimenti client. Nell'evento fetch del service worker, puoi utilizzare il metodo request.headers.get dell'oggetto event per leggere le intestazioni delle richieste di una risorsa in questo 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!
    })(),
  );
});

L'intestazione dei suggerimenti client che attivi può essere letta in questo modo. Anche se questo non è l'unico modo per ottenere queste informazioni. Puoi leggere i suggerimenti specifici della rete nelle seguenti proprietà JavaScript equivalenti nell'oggetto navigator:

Plug-in Imagemin per tipi di file.

Suggerimento client	Equivalente JS
"ECT"	`navigator.connection.effectiveType`
"RTT"	"navigator.connection.rtt"
"Salva dati"	`navigator.connection.saveData`
"Link in basso"	`navigator.connection.downlink`
"Memoria dispositivo"	"navigator.deviceMemory"

Poiché queste API non sono disponibili ovunque sia necessario eseguire il controllo delle 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, ad eccezione del fatto che non è necessario un server per negoziare i contenuti con i client hint. I Service worker da soli possono rendere le esperienze più rapide e resilienti, grazie alla maggiore possibilità di pubblicare contenuti quando l'utente è offline.

In sintesi

Con i client hint, possiamo 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 a <picture> e srcset, soprattutto per casi d'uso complessi. Questo ci consente non solo di ridurre tempo e impegno sul lato sviluppo, ma anche di ottimizzare le risorse, in particolare le immagini, in modo da raggiungere gli schermi degli utenti in modo più preciso rispetto a e srcset.

Ma soprattutto, siamo in grado di individuare connessioni di rete deboli e colmare il divario per gli utenti modificando ciò che inviamo e il modo in cui li inviamo. Ciò può contribuire lunghi a facilitare l'accesso ai siti da parte degli utenti su reti fragili. Grazie alla combinazione con i service worker, possiamo creare siti incredibilmente veloci disponibili offline.

Sebbene i suggerimenti client siano disponibili solo in Chrome e nei browser basati su Chromium, è possibile utilizzarli in modo tale che non ingombrano i browser che non li supportano. Prendi in considerazione l'utilizzo dei suggerimenti dei client per creare esperienze davvero inclusive e adattabili, che siano consapevoli delle funzionalità del dispositivo di ogni utente e delle reti a cui si connettono. Si spera che altri fornitori di browser ne vedano il valore e dimostrino l'intenzione di implementarli.

Risorse

• Immagini adattabili automatiche con client hint
• Suggerimenti client e immagini adattabili: che cosa è cambiato in Chrome 67
• Dai un suggerimento (client) (Presentazioni)
• Fornitura di applicazioni veloci e leggere con Save-Data

Grazie a Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss e Estelle Weyl per il loro prezioso feedback e le loro modifiche in questo articolo.