Sviluppare siti che siano 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 questo compito insormontabile. Sebbene sia possibile sfruttare le funzionalità del browser per migliorare le prestazioni di caricamento, come facciamo a sapere di cosa è capace il dispositivo dell'utente o la qualità della sua connessione di rete? La soluzione sono gli hint client.
I client hint sono un insieme di intestazioni delle richieste HTTP che ci forniscono informazioni su questi aspetti del dispositivo dell'utente e della rete a cui è connesso. Sfruttando 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 si gioca sulla negoziazione dei contenuti
I client hint 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 contenuti compresi dal browser, 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 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 client hint sono un altro modo per negoziare i contenuti, ma nel contesto delle funzionalità del dispositivo e delle condizioni della rete. Con i client hint, possiamo prendere decisioni sulle prestazioni 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 scadenti. In questa guida descriveremo tutti gli hint disponibili e alcuni modi in cui puoi utilizzarli per rendere l'importazione dei contenuti più adatta agli utenti.
Attivazione
A differenza dell'intestazione Accept, i client hint non vengono visualizzati magicamente (con l'eccezione di Save-Data, di cui parleremo più avanti). Per mantenere al minimo le intestazioni della richiesta, dovrai attivare i client hint 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, riceve l'istruzione "questo sito vuole i client hint Viewport-Width e Downlink". Non preoccuparti degli hint specifici.
Ne parleremo tra un attimo.
Puoi impostare queste intestazioni di attivazione in qualsiasi linguaggio 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.
I client hint descrivono una di queste due cose: il dispositivo che i tuoi utenti utilizzano e la rete che usano per accedere al tuo sito. Vediamo brevemente tutti i suggerimenti disponibili.
Suggerimenti per i dispositivi
Alcuni client hint descrivono le caratteristiche del dispositivo dell'utente, in genere le caratteristiche dello schermo. Alcune possono aiutarti a scegliere la risorsa multimediale ottimale per lo schermo di un determinato utente, ma non tutte sono necessariamente incentrate sui contenuti multimediali.
Prima di entrare nel dettaglio di questo elenco, potrebbe essere utile apprendere 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 delle dimensioni dell'immagine descrivono le sue dimensioni intrinseche.
Dimensioni intrinseche con correzione della densità: le dimensioni di una risorsa multimediale dopo la correzione della densità di pixel. Si tratta delle dimensioni intrinseche dell'immagine divise per un rapporto dei 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 le dimensioni intrinseche dell'immagine 2x siano 640 x 480. Se questo markup viene analizzato da un client installato su un dispositivo con un rapporto di pixel del dispositivo dello schermo pari a 2 (ad es. uno schermo Retina), viene richiesta l'immagine 2x. Le dimensioni intrinseche con correzione della densità dell'immagine 2x sono 320 x 240, poiché 640 x 480 diviso 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 con correzione della densità di 320 x 240, ma che ha anche proprietà CSS width e height con valori rispettivamente di 256px e 192px. In questo esempio,
la dimensione estrinseca dell'elemento <img> diventa 256 x 192.
width: 256px;
e height: 192px; trasforma un'immagine con dimensioni intrinseche di 320 x 240
in un'immagine con dimensioni estrinseche di 256 x 192.Ora che abbiamo acquisito un po' di terminologia, passiamo all'elenco degli hint client specifici per i dispositivi a tua disposizione.
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 art direction) 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à dei 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> utilizzando l'attributo sizes.
sizes indica al browser quale sarà la dimensione estrinseca 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 320 pixel CSS con un DPR pari a 2. Il dispositivo carica un documento con un elemento <img> contenente un valore dell'attributo sizes pari a 85vw (ovvero 85% della larghezza dell'area visibile per tutte le dimensioni dello schermo). Se è stato attivato l'hint Width, il client invierà questo hint Width al server con la richiesta per 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 dell'area visibile (272 pixel) moltiplicata per il DPR dello schermo (2), ovvero 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. In questo modo, i server possono negoziare risposte alle immagini ottimali sia per lo schermo sia per il layout.
Content-DPR
Anche se sai già che gli schermi hanno un rapporto pixel del dispositivo, anche le risorse hanno i propri rapporti pixel. Nei casi d'uso più semplici di selezione delle risorse, i rapporti tra i pixel dei dispositivi e delle risorse possono essere gli stessi. Ma… Nei casi in cui sono presenti entrambe le intestazioni DPR e Width, la dimensione estrinseca di una risorsa può produrre scenari in cui le due intestazioni differiscono. È qui che entra in gioco il suggerimento Content-DPR.
A differenza di altri suggerimenti client, Content-DPR non è un'intestazione della richiesta che deve essere utilizzata dai server, ma piuttosto un'intestazione della 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 = [Selected image resource size] / ([Width] / [DPR])
Quando viene inviata un'intestazione della richiesta Content-DPR, il browser saprà come ridimensionare l'immagine specificata in base al rapporto dei pixel del dispositivo dello schermo e al layout. Senza questo attributo, le immagini potrebbero non essere ridimensionate correttamente.
Device-Memory
Tecnicamente parte dell'API Device Memory, Device-Memory rivela la quantità approssimativa di memoria del dispositivo corrente in GiB:
Device-Memory: 2
Un possibile caso d'uso di questo suggerimento è ridurre la quantità di JavaScript inviata ai browser su dispositivi con memoria limitata, poiché JavaScript è il tipo di contenuto che richiede più risorse tra quelli che i browser caricano in genere. In alternativa, puoi inviare immagini con DPR inferiore, poiché richiedono meno memoria per la decodifica.
Suggerimenti di 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 questi, abbiamo la possibilità di personalizzare le esperienze per gli utenti modificando il modo in cui forniamo le risorse ai client con connessioni lente.
RTT
Il suggerimento RTT fornisce il tempo di round trip approssimativo, in millisecondi, sul livello di applicazione. Il suggerimento RTT, a differenza dell'RTT del livello di trasporto, include il tempo di elaborazione del server.
RTT: 125
Questo suggerimento è utile per via del ruolo che la latenza svolge nelle prestazioni di caricamento.
Utilizzando il suggerimento RTT, possiamo prendere decisioni in base alla reattività della rete, il che può contribuire a velocizzare la pubblicazione di un'intera esperienza (ad esempio omettendo 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 downstream approssimativa della connessione dell'utente:
Downlink: 2.5
In combinazione con RTT, Downlink può essere utile per modificare il modo in cui i contenuti vengono forniti agli utenti in base alla qualità di una connessione di rete.
ECT
Il suggerimento ECT indica il tipo di connessione effettiva. 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 della rete, quanto una preferenza dell'utente che indica che le pagine devono inviare meno dati.
Preferisco classificare Save-Data come un suggerimento di rete perché molte delle cose che faresti con questo suggerimento sono simili ad altri suggerimenti di rete. Gli utenti potrebbero anche essere propensi ad attivarla in ambienti con latenza elevata/larghezza di banda ridotta. Questo suggerimento, se presente, ha sempre questo aspetto:
Save-Data: on
Qui in Google, abbiamo parlato di cosa puoi fare con
Save-Data.
L'impatto che può avere sul rendimento può essere significativo. È un segnale che gli utenti ti stanno letteralmente chiedendo di inviare loro meno contenuti. Se ascolti e agisci in base a questo segnale, gli utenti lo apprezzeranno.
Il mix perfetto
Cosa fare con i client hint dipende da te. Poiché offrono così tante informazioni, hai molte opzioni. Per trovare qualche idea, vediamo cosa possono fare gli hint client per Sconnie Timber, un'azienda fittizia di legname situata nell'Upper Midwest rurale. Come spesso accade nelle aree remote, le connessioni di rete possono essere instabili. È qui che una tecnologia come i client hint può fare davvero la differenza per gli utenti.
Immagini adattabili
Tutti i casi d'uso delle immagini adattabili, ad eccezione di quelli più semplici, possono diventare complicati. Cosa succede se hai più trattamenti e varianti delle stesse immagini per dimensioni dello schermo diverse e formati diversi? Questo markup diventa molto complicato molto rapidamente.
È facile sbagliare e dimenticare o fraintendere concetti importanti (come sizes).
Sebbene <picture> e srcset siano indubbiamente strumenti fantastici, possono richiedere molto tempo per lo sviluppo e la manutenzione in casi d'uso complessi. Possiamo automatizzare la generazione del markup, ma anche questo è difficile perché la funzionalità fornita da <picture> e srcset è abbastanza complessa da richiedere un'automazione che mantenga la flessibilità che forniscono.
I client hint possono semplificare questo processo. La negoziazione delle risposte delle immagini con i client hint potrebbe essere simile alla seguente:
- Se applicabile al tuo flusso di lavoro, seleziona prima un trattamento dell'immagine (ovvero immagini con direzione artistica) selezionando il suggerimento
Viewport-Width. - Seleziona una risoluzione dell'immagine controllando i suggerimenti
WidtheDPRe scegliendo una sorgente adatta alle dimensioni del layout e alla densità dello schermo dell'immagine (in modo simile al funzionamento dei descrittorixewinsrcset). - Seleziona il formato file più ottimale supportato dal browser (un'operazione che
Acceptci aiuta a eseguire nella maggior parte dei browser).
Per quanto riguarda il mio cliente fittizio, l'azienda di legname, ho sviluppato una semplice routine di selezione delle immagini adattabili in PHP che utilizza i client hint. Ciò significa che, 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>
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. Accetta un nome file dell'immagine e parametri aggiuntivi per aiutare uno script di backend a scegliere l'immagine migliore nelle condizioni indicate.
Immagino 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 un'importante distinzione: quando un'applicazione utilizza i client hint 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 ogni caso d'uso. Sì, puoi automatizzare la generazione del markup. Tuttavia, se il design o i requisiti cambiano, è molto probabile che in futuro dovrai rivedere la tua strategia di automazione.
I client hint consentono di iniziare con un'immagine ad alta risoluzione senza perdita di dati 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 candidati di immagini tra cui il browser può scegliere, questo approccio può essere più flessibile. Mentre srcset ti costringe a offrire ai browser un insieme approssimativo di varianti, ad esempio 256w, 512w, 768w e 1024w, una soluzione basata su client hint può gestire tutte le larghezze, senza un'enorme quantità di markup.
Naturalmente, non devi scrivere tu la logica di selezione delle immagini. Cloudinary utilizza i client hint 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 utilizzavano browser che supportano i client hint.
Ma fai attenzione! Le modifiche apportate alla versione desktop di Chrome 67 hanno rimosso il supporto per i client hint multiorigine. Fortunatamente, queste limitazioni non influiscono sulle versioni mobile di Chrome e verranno rimosse del tutto per tutte le piattaforme al termine del lavoro sulla policy sulle funzionalità.
Aiutare gli utenti con reti lente
Le prestazioni adattive si basano sull'idea che possiamo regolare il modo in cui forniamo le risorse in base alle informazioni che i client hint ci mettono a disposizione, in particolare quelle 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, 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 dobbiamo 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 se Save-Data è presente. In questo caso, il punteggio viene impostato su 0, poiché supponiamo che l'utente voglia che facciamo tutto il necessario per rendere l'esperienza più leggera e veloce.
Tuttavia, se Save-Data non è presente, passiamo oltre e valutiamo i valori dei suggerimenti ECT, RTT e Downlink per calcolare un punteggio che descrive la qualità della connessione di rete. Il codice sorgente per la generazione del punteggio di rete è disponibile su GitHub. In conclusione, se utilizziamo i suggerimenti relativi alla rete in
qualche modo, possiamo migliorare le esperienze per chi utilizza reti
lente.
Quando i siti si adattano alle informazioni fornite dagli hint 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 responsive per inviare immagini di qualità inferiore per un determinato display, in modo da velocizzare le prestazioni di caricamento quando la qualità della rete è scarsa.
In questo esempio, possiamo vedere l'impatto dei client hint sul miglioramento delle prestazioni dei siti su reti più lente. Di seguito è riportata una cascata di WebPagetest di un sito su una rete lenta che non si adatta ai Client Hint:
Ora vediamo una cascata per lo stesso sito sulla stessa connessione lenta, ma questa volta il sito utilizza i client hint per eliminare le 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 di quel tempo. I vantaggi dei client hint in questo scenario non possono essere sottolineati abbastanza e possono essere un serio vantaggio per gli utenti che cercano informazioni critiche su reti lente.
Inoltre, è possibile utilizzare i client hint senza interrompere l'esperienza per i browser che non li supportano. Ad esempio, se vogliamo modificare la distribuzione delle risorse utilizzando il valore del suggerimento ECT, pur continuando a offrire l'esperienza completa per i browser non supportati, possiamo impostare il valore di riserva su un valore predefinito come questo:
// 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 client hint non saranno interessati. Attiva 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 di quella risorsa. L'intestazione Vary è indispensabile in questo caso, poiché associa le voci della cache al valore delle intestazioni della richiesta fornite. In parole povere, se modifichi una risposta in base a una determinata intestazione della richiesta HTTP, devi quasi sempre includere l'intestazione della richiesta in Vary, in questo modo:
Vary: DPR, Width
Tuttavia, esiste un'importante eccezione: non devi mai Vary risposte memorizzabili nella cache su un'intestazione che cambia di frequente (come Cookie) perché queste risorse diventano effettivamente non memorizzabili nella cache. Sapendo questo, potresti voler evitare di utilizzare Vary sulle intestazioni degli hint client come RTT o Downlink, perché si tratta di fattori di connessione che potrebbero cambiare abbastanza spesso. Se vuoi modificare le risposte su queste intestazioni, valuta la possibilità di utilizzare solo l'intestazione ECT, in modo da ridurre al minimo i fallimenti 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 nelle visite ripetute. In casi come questi, non esitare a modificare le risposte in base a ciò che ritieni necessario e non preoccuparti di Vary.
Client hints 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 pubblicate 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, 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!
})(),
);
});
Qualsiasi intestazione di suggerimento client che attivi può essere letta in questo modo. Tuttavia, questo 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:
| Client hint | Equivalente JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Poiché queste API non sono disponibili ovunque, devi eseguire un 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 utilizzeresti sul server, con la differenza che non hai bisogno di un server per negoziare i contenuti con i client hint. I service worker da soli hanno il potere di rendere le esperienze più veloci e resilienti grazie alla loro capacità aggiuntiva di pubblicare contenuti quando l'utente è offline.
Conclusioni
Con i client hint, 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 casi d'uso complessi. In questo modo, non solo riduciamo i tempi e gli sforzi di sviluppo, ma ottimizziamo anche le risorse, in particolare le immagini, in modo da scegliere come target gli schermi degli utenti in modo più preciso di quanto possano fare
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ò essere di grande aiuto per rendere i siti più facili da consultare per gli utenti con reti instabili. In combinazione con i service worker, possiamo creare siti incredibilmente veloci disponibili offline.
Sebbene i client hint siano disponibili solo in Chrome e nei browser basati su Chromium, è possibile utilizzarli in modo da non appesantire i browser che non li supportano. Valuta la possibilità di utilizzare i client hint per creare esperienze veramente inclusive e adattabili che tengano conto delle funzionalità del dispositivo di ogni utente e delle reti a cui si connettono. Ci auguriamo che altri fornitori di browser ne comprendano il valore e mostrino l'intenzione di implementarle.
Risorse
- Automatic Responsive Images with Client Hints
- Client Hints and Responsive Images—What Changed in Chrome 67
- Take a (Client) Hint! (Presentazioni)
- Distribuzione di applicazioni veloci e leggere con
Save-Data
Ringraziamo Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss ed Estelle Weyl per i loro preziosi feedback e le modifiche a questo articolo.