Adattarsi agli utenti con suggerimenti client

Creare siti che siano veloci ovunque può essere una prospettiva difficile. La pletora delle funzionalità dei dispositivi e della qualità delle reti a cui si connettono può far sembrare un'attività insormontabile. Anche se possiamo prendere 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 rete connessione? La soluzione è client Suggerimenti!

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

È tutta una questione di negoziazione dei contenuti

I client hint sono un altro metodo di negoziazione dei contenuti, che prevede la modifica risposte dei contenuti basate sulle intestazioni delle richieste del browser.

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

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

Sebbene tutti i browser supportino formati di immagine come JPEG, PNG e GIF, Accetta indica in questo caso il browser supporta anche WebP e APNG. Utilizzando queste informazioni, possiamo negozia i migliori tipi di immagine 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 nel caso di Accept, i suggerimenti del cliente sono un altro modo per negoziare i contenuti, ma in il contesto delle funzionalità del dispositivo e delle condizioni della rete. Con i client hint, possono prendere decisioni sulle prestazioni lato server in base alle singole esperienza, ad esempio nel decidere se mostrare o meno risorse non critiche utenti con condizioni di rete scadenti. In questa guida, illustreremo tutte le i suggerimenti disponibili e alcuni modi in cui puoi utilizzarli per rendere più precisa l'importazione dei contenuti soddisfare le esigenze degli utenti.

Attivazione

A differenza dell'intestazione Accept, i suggerimenti client non vengono visualizzati semplicemente magicamente (con il tranne Save-Data, di cui parleremo più avanti). Nell'interesse di mantenere almeno le intestazioni delle richieste, dovrai attivare i client hint che dovrai vuoi ricevere inviando un'intestazione Accept-CH quando un utente richiede risorsa:

Accept-CH: Viewport-Width, Downlink

Il valore di Accept-CH è un elenco separato da virgole di suggerimenti richiesti per il sito per determinare i risultati per la successiva richiesta di risorse. Quando il cliente legge l'intestazione e gli viene detto "questo sito richiede l'Viewport-Width e Downlink hint del client." Non preoccuparti dei suggerimenti specifici. Le faremo tra poco.

Puoi impostare queste intestazioni di attivazione in qualsiasi lingua di back-end. Ad esempio, PHP È possibile utilizzare la funzione header. Puoi anche impostare queste intestazioni di attivazione con il http-equiv attributo in un tag <meta>:

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

Tutti gli indizi del cliente!

I client hint descrivono uno di questi due aspetti: il dispositivo, beh, utilizzato, e alla rete che utilizzano per accedere al tuo sito. Esaminiamo brevemente tutti i suggerimenti disponibili.

Suggerimenti per i dispositivi

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

Prima di entrare in questo elenco, potrebbe essere utile apprendere alcuni termini chiave utilizzati per descrivere le schermate 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 ne descrivono le dimensioni intrinseche.

Dimensioni intrinseche corrette per la densità: le dimensioni di una risorsa multimediale dopo è stata corretta per la densità dei pixel. Sono le dimensioni intrinseche dell'immagine. diviso per un pixel del dispositivo . Prendiamo ad esempio 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 la dimensione intrinseca dell'immagine 1x in questo caso sia 320 x 240 e Le dimensioni intrinseche dell'immagine 2x sono 640 x 480. Se questo markup viene analizzato da un client installata su un dispositivo con proporzioni pixel dello schermo pari a 2 (ad es. un display Retina) schermo), viene richiesta l'immagine 2x. La dimensione intrinseca corretta per la densità di l'immagine 2x è di 320 x 240, poiché 640 x 480 diviso per 2 è 320 x 240.

Dimensioni estrinseche:le dimensioni di una risorsa multimediale dopo il layout CSS e altro (come gli attributi width e height) sono stati applicati. Iniziamo supponiamo che tu abbia un elemento <img> che carica un'immagine con una densità corretta dimensione intrinseca di 320 x 240, ma ha anche proprietà CSS width e height con valori rispettivamente di 256px e 192px. In questo esempio, le dimensioni estrinseche dell'elemento <img> diventano 256 x 192.

Con un po' di terminologia alle spalle, entriamo nell'elenco delle categorie di prodotti client hint a tua disposizione.

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 per lo schermo per fornire diversi trattamenti (ritaglio) di un'immagine, ideali per schermi di dimensioni specifiche (ad es. arte direzione), oppure omettere le risorse che non sono necessarie per l'attuale larghezza dello schermo.

DPR

DPR, acronimo di Device Pixel Ratio, indica il rapporto tra pixel fisici e CSS. pixel dello schermo dell'utente:

DPR: 2

Questo suggerimento è utile per la selezione di fonti di immagini che corrispondono densità dei pixel (come i descrittori x in srcset ).

Larghezza

Il suggerimento Width viene visualizzato nelle richieste di risorse immagine attivate da <img> o Tag <source> che utilizzano sizes attributo. sizes indica al browser 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 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 (ad es. all'85% della larghezza dell'area visibile dimensioni dello schermo). Se il suggerimento Width è stato attivato, il client invierà questo hint Width al server con la richiesta di src di <img>:

Width: 544

In questo caso, il client suggerisce al server che una soluzione intrinseca ottimale la larghezza dell'immagine richiesta corrisponde all'85% della larghezza dell'area visibile (272 pixel) moltiplicato per il DPR dello schermo (2), che corrisponde a 544 pixel.

Questo suggerimento è particolarmente efficace perché non solo prende in considerazione densità dello schermo corretta, ma riconcilia anche questo elemento critico di informazioni con le dimensioni estrinseche dell'immagine all'interno del layout. Ciò consente di ai server l'opportunità di negoziare le risposte delle immagini ottimali sia per lo schermo e il layout.

Contenuti - DPR

Anche se sai già che gli schermi hanno un rapporto pixel tra i dispositivi, anche le risorse hanno proporzioni pixel proprie. Nei casi d'uso più semplici per la selezione delle risorse, i rapporti tra dispositivi e risorse possono essere uguali. Ma! Nei casi in cui sia le intestazioni DPR e Width sono attive, le dimensioni estrinseche di una risorsa creare scenari in cui i due aspetti differiscono. Ecco dove suggerisce il suggerimento Content-DPR entra in gioco.

A differenza di altri suggerimenti client, Content-DPR non è un'intestazione request che deve essere utilizzata server, ma un server di intestazione risposta deve inviare ogni volta che DPR e Per selezionare una risorsa vengono utilizzati Width suggerimenti. Il valore Content-DPR deve sarà il risultato di questa equazione:

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

Quando viene inviata un'intestazione della richiesta Content-DPR, il browser sa come scalare l'immagine data per le proporzioni pixel del dispositivo e il layout dello schermo. Senza, le immagini potrebbero non essere ridimensionate correttamente.

Memoria del dispositivo

Tecnicamente parte della memoria del dispositivo API, Device-Memory rivela lo una quantità approssimativa di Memoria il dispositivo attuale ha in GiB:

Device-Memory: 2

Un possibile caso d'uso per questo hint sarebbe ridurre la quantità di codice JavaScript inviati a browser su dispositivi con memoria limitata, poiché JavaScript è tipi di contenuti che consumano molte risorse caricamento. In alternativa, potresti inviare immagini DPR inferiori in quanto utilizzano meno memoria per la decodifica.

Suggerimenti di rete

L'API Network Information fornisce un'altra categoria di suggerimenti client che descrivono le prestazioni della rete dell'utente connessione. Secondo me, questi sono i suggerimenti più utili. con cui hanno la possibilità di personalizzare le esperienze per gli utenti cambiando il modo in cui offriamo le risorse ai client con connessioni lente.

RTT

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

RTT: 125

Questo hint è utile a causa del ruolo svolto dalla latenza nelle prestazioni di caricamento. Utilizzando il suggerimento RTT, possiamo prendere decisioni in base alla reattività della rete, che possono contribuire a velocizzare la fornitura di un'intera esperienza (ad es. omettere alcune richieste).

Downlink

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

Downlink: 2.5

In combinazione con RTT, Downlink può essere utile per cambiare il modo in cui i contenuti vengono disponibili agli utenti in base alla qualità della connessione di rete.

ECT

Il suggerimento ECT è l'acronimo di Effective Connection Type (Tipo di connessione effettiva). Il suo valore è uno di elenco enumerato di tipi di connessioni, ognuno dei quali descrive una connessione all'interno di intervalli specificati di RTT e Downlink predefiniti.

Questa intestazione non spiega cos'è il tipo di connessione effettivo, Ad esempio, non segnala se il gateway è una torre cellulare o un accesso Wi-Fi. punto di accesso. Piuttosto, analizza la latenza e la larghezza di banda della connessione corrente e determina il profilo di rete a cui assomiglia di più. Ad esempio, se colleghi tramite Wi-Fi a una rete lenta, il valore di ECT potrebbe essere 2g, che è l'approssimazione più vicina alla connessione efficace:

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 perfezionato utilizzando i suggerimenti RTT e Downlink.

Salva dati

Save-Data non è un suggerimento che descrive le condizioni di rete, ma è un utente. che indica che le pagine devono inviare meno dati.

Preferisco classificare Save-Data come suggerimento di rete perché molte delle cose che farebbero in modo simile ad altri hint di rete. Gli utenti possono inoltre essere in ambienti con latenza elevata/bassa larghezza di banda. Questo suggerimento, quando presente, avrà sempre il seguente aspetto:

Save-Data: on

Qui di Google abbiamo parlato di cosa puoi fare con Save-Data. L'impatto che può avere sulle prestazioni può essere profondo. Rappresenta un indicatore della posizione degli utenti ti chiedono letteralmente di inviare meno cose. Se ascolti e intervieni in merito gli utenti lo apprezzeranno.

Il mix perfetto

Le fasi che devi eseguire con i client hint dipendono da te. Perché offrono moltissimo informazioni, hai molte opzioni. Per far fluire le idee, vediamo cosa i suggerimenti del client per Sconnie Timber, un'opera fittizia un'azienda con sede nell'Upper Midwest rurale. Come accade spesso per i modelli aree geografiche, le connessioni di rete possono essere fragili. È qui che una tecnologia come client hint può fare davvero la differenza per gli utenti.

Immagini adattabili

Tutti i casi d'uso di immagini adattabili, tranne quelli più semplici, possono complicarsi. E se avere più trattamenti e varianti delle stesse immagini per schermi diversi dimensioni—e formati diversi? Questo markup diventa molto complicato molto rapidamente. È facile sbagliare e facile dimenticare o fraintendere importanti (ad esempio sizes).

Sebbene <picture> e srcset siano strumenti indubbiamente fantastici, possono essere e richiede molto tempo per lo sviluppo e la manutenzione per casi d'uso complessi. Possiamo automatizzare del markup, ma farlo è difficile anche perché la funzionalità Le offerte di <picture> e srcset sono abbastanza complesse da richiedere alle loro esigenze di automazione in modo da mantenere la flessibilità che offrono.

I client hint possono semplificare questo processo. Negoziazione delle risposte alle immagini con il client I suggerimenti potrebbero avere il seguente aspetto:

1. Se applicabile al tuo flusso di lavoro, seleziona prima un trattamento immagine (ad es. immagini di opere d'arte) selezionando il suggerimento Viewport-Width.
2. Seleziona la risoluzione dell'immagine selezionando il suggerimento Width e il suggerimento DPR. scegliendo un'origine in linea con le dimensioni del layout e la densità dello schermo dell'immagine (simile al funzionamento dei descrittori x e w in srcset).
3. Seleziona il formato file ottimale supportato dal browser (Accept) nella maggior parte dei browser).

Per quanto riguarda il mio cliente fittizio di aziende di legname, ho sviluppato una una routine di selezione reattiva delle immagini in PHP che utilizza i client hint. 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, sono riuscito a ridurlo come 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 riscritto da mod_rewrite. it prende un nome file immagine e parametri aggiuntivi per aiutare uno script back-end scegliere l'immagine migliore nelle condizioni date.

Ho la sensazione che "Ma non si tratta solo di reimplementare <picture> e srcset sulla "back-end?" è la prima domanda.

In un certo senso sì, ma con una distinzione importante: quando un'applicazione utilizza suggerimenti del cliente per la creazione di risposte multimediali; gran parte del lavoro (se non tutto) è molto più facile da automatizzare, il che può includere un servizio (ad esempio una CDN) in grado di eseguire questa operazione per tuo conto. Mentre con le soluzioni HTML, il nuovo markup deve essere scritto per ogni caso d'uso. Certo, puoi automatizzare la generazione del markup. Se le tue o requisiti che cambiano, tuttavia, c'è una buona probabilità che dovrete a rivedere la tua strategia di automazione in futuro.

I client hint consentono di iniziare con un'architettura senza perdita di dati e ad alta immagine che può essere poi ridimensionata dinamicamente per essere ottimale per qualsiasi combinazione di schermo e layout. A differenza di srcset, che richiede di enumerare un fisso un elenco di possibili immagini da cui il browser può scegliere, 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, suggerimenti del cliente una soluzione basata su tecnologia può servire tutte le larghezze, senza un'enorme quantità di markup.

Naturalmente, non devi scrivere personalmente la logica di selezione delle immagini. Cloudinario utilizza i client hint per creare risposte alle immagini quando utilizzi w_auto predefinito, e osservato che gli utenti medi scaricano il 42% di byte in meno utilizzando i browser a supporto dei clienti.

Ma fai attenzione. Le modifiche alla versione desktop di Chrome 67 hanno rimosso il supporto per client multiorigine suggerimenti. Fortunatamente, queste limitazioni non interessano le versioni mobile di Chrome. saranno rimosse completamente per tutte le piattaforme quando si utilizza la funzionalità Il criterio è stato completato.

Aiutare gli utenti con reti lente

Il rendimento adattivo indica che possiamo regolare il modo in cui forniamo le risorse sulla base delle informazioni che ci mette a disposizione il cliente; nello specifico le informazioni sullo stato corrente della connessione di rete dell'utente.

Per quanto riguarda il sito di Sconnie Timber, adottiamo delle misure per alleggerire il carico quando Le reti sono lente, con intestazioni Save-Data, ECT, RTT e Downlink esaminati nel nostro codice di backend. Fatto ciò, generiamo una qualità della rete punteggio che possiamo utilizzare per determinare se dobbiamo intervenire per un utente migliore un'esperienza senza intervento manuale. Questo punteggio di rete è compreso tra 0 e 1, dove 0 è il punteggio peggiore la qualità di rete possibile e 1 è la migliore.

Inizialmente, controlliamo se è presente Save-Data. Se lo è, il punteggio è impostato su 0, poiché presupponiamo che l'utente voglia che facciamo tutto ciò che è necessario per rendere in modo più leggero e veloce.

Se il valore Save-Data è assente, tuttavia, andiamo avanti e pesiamo i valori dell'attributo ECT. RTT e Downlink suggerimenti per calcolare un punteggio che descrive la rete e la qualità della connessione. L'origine per la generazione del punteggio di rete codice è disponibile su GitHub. Il concetto è che, se usiamo i suggerimenti relativi alla rete un po' di moda, possiamo migliorare le esperienze per chi è lento reti.

Quando i siti si adattano alle informazioni fornite dal cliente, non dobbiamo adottare un approccio "tutto o niente". Possiamo decidere in modo intelligente quali risorse invia. Possiamo modificare la nostra logica di selezione adattabile delle immagini per inviare immagini di qualità inferiore immagini per un determinato display per velocizzare il caricamento quando la qualità della rete è scadente.

In questo esempio possiamo vedere l'impatto dei suggerimenti del cliente migliorando le prestazioni dei siti su reti più lente. Di seguito è riportato WebPagetest struttura a cascata di un sito su una rete lenta che non si adatta ai suggerimenti del client:

Ora una struttura a cascata per lo stesso sito sulla stessa connessione lenta, tranne che nel tempo, 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 del tempo totale. I vantaggi dei client hint in questo scenario non possono abbastanza enfatizzato e può rappresentare un grande vantaggio per gli utenti che cercano informazioni 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 le risorse pubblicazione facendo ricorso al valore del suggerimento ECT continuando a pubblicare l'intero per i browser non supportati, possiamo impostare il fallback su un valore predefinito in questo modo:

// 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 massima qualità per l'intestazione ECT. che descrive il problema. Se inizializziamo $ect in "4g", i browser che non supportano il client I suggerimenti non saranno interessati. Attiva ora

Fai attenzione a queste cache!

Ogni volta che modifichi una risposta basata su un'intestazione HTTP, devi tenere presente il modo in cui le cache gestiranno i recuperi futuri per quella risorsa. La Vary intestazione è indispensabile qui, in quanto le voci della cache corrispondono al valore delle intestazioni delle richieste. che riceve. In poche parole, se modifichi una risposta basata su un determinato HTTP intestazione della richiesta, dovresti quasi sempre includere la richiesta dell'intestazione in Vary in questo modo:

Vary: DPR, Width

Tuttavia, c'è un'importante avvertenza: non è mai consigliabile Vary memorizzabile nella cache. risposte su un'intestazione che cambia frequentemente (ad esempio Cookie) perché quelle le risorse diventano di fatto non memorizzabili nella cache. Tenendo conto di questo, è consigliabile evitare Vary su intestazioni del suggerimento client come RTT o Downlink, perché sono fattori di connessione che potrebbero cambiare abbastanza spesso. Se vuoi modificare risposte su queste intestazioni, ti consigliamo di digitare solo l'intestazione ECT, che minimizzare gli errori della cache.

Naturalmente, ciò si applica solo se in primo luogo stai memorizzando nella cache una risposta. Ad esempio, non memorizzi nella cache asset HTML se il loro contenuto è dinamico, che possono interrompere l'esperienza utente nelle visite ripetute. In casi come questi, sentite libero di modificare tali risposte come ritieni necessario e non hai problemi con Vary.

Suggerimenti client nei service worker

La negoziazione dei contenuti non riguarda più solo i server. Poiché i service worker agiscono come proxy tra i client e i server, hai il controllo sul modo in cui le risorse vengono pubblicati tramite JavaScript. Sono inclusi i client hint. Nel service worker fetch, puoi utilizzare l'attributo event request.headers.get 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!
    })(),
  );
});

Qualsiasi intestazione del suggerimento client attivata può essere letta in questo modo. Anche se è non è l'unico modo per ottenere alcune di queste informazioni. Suggerimenti specifici per la rete può essere letta nelle seguenti proprietà JavaScript equivalenti nell'oggetto navigator:

. Plug-in Imagemin per i tipi di file.

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

Poiché queste API non sono disponibili ovunque sia necessario controllare le funzionalità con in operatore:

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 non è bisogno di un server per negoziare i contenuti con i suggerimenti del client. Servizio I lavoratori da soli hanno il potere di rendere le esperienze più rapide e resilienti grazie alla capacità aggiuntiva di pubblicare contenuti quando l'utente è offline.

In sintesi

I suggerimenti dei clienti ci consentono di velocizzare l'esperienza per gli utenti in un in modo completamente progressivo. Possiamo pubblicare contenuti multimediali in base al dispositivo dell'utente in un modo che semplifica la pubblicazione di immagini reattive rispetto all'utilizzo su <picture> e srcset, soprattutto per i casi d'uso complessi. Questo ci consente per ridurre non solo i tempi e l'impegno necessari per lo sviluppo, ma anche per le risorse, in particolare le immagini, in modo da indirizzare gli utenti verso gli schermi più finemente di e srcset possono.

Ma cosa ancora più importante, possiamo sniffare le connessioni di rete scadenti il divario per gli utenti modificando ciò che inviamo e il modo in cui lo inviamo. Questo può si adoperano altamente per facilitare l'accesso dei siti agli utenti che si trovano in reti fragili. Combinando i Service worker, possiamo creare siti incredibilmente veloci che disponibile offline.

Sebbene i client hint siano disponibili solo in Chrome e basato su Chromium browser, è possibile utilizzarli in modo da non complicare browser che non li supportano. Valuta la possibilità di utilizzare i client hint per creare esperienze inclusive e adattabili che riconoscono il dispositivo di ogni utente funzionalità e le reti a cui si connettono. Si spera che altri fornitori di browser ne vedranno il valore e manifesteranno l'intenzione di implementarli.

Risorse

• Immagini adattabili automatiche con client Suggerimenti
• Suggerimenti per client e immagini adattabili: cosa è cambiato in Chrome 18
• Dai un suggerimento (cliente). (Presentazioni)
• Applicazioni veloci e leggere con Save-Data

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