Beradaptasi dengan Pengguna berdasarkan Petunjuk Klien

Mengembangkan situs yang cepat di mana saja bisa menjadi prospek yang rumit. Kebanyakan kemampuan perangkat—dan kualitas jaringan yang terhubung —dapat membuat tugas tampak seperti tugas yang tidak dapat diatasi. Meskipun kita dapat mengambil memanfaatkan fitur browser untuk meningkatkan kinerja pemuatan, bagaimana kita mengetahui kemampuan perangkat pengguna, atau kualitas jaringannya koneksi internet? Solusinya adalah klien petunjuk!

Client hints adalah kumpulan header permintaan HTTP keikutsertaan yang memberi kita insight tentang aspek-aspek perangkat pengguna dan jaringan yang tersambung. Menurut dengan memanfaatkan sisi server informasi ini, kami dapat mengubah cara menampilkan berdasarkan kondisi perangkat dan/atau jaringan. Hal ini dapat membantu kita untuk membuat membuat {i>user experience<i} yang lebih inklusif.

Ini Semua Tentang Negosiasi Konten

Petunjuk klien adalah metode negosiasi konten lain, yang berarti mengubah respons konten berdasarkan header permintaan browser.

Salah satu contoh negosiasi konten melibatkan Accept header permintaan. Ini menjelaskan jenis konten apa saja yang dipahami browser, yang yang dapat digunakan server untuk menegosiasikan respons. Untuk permintaan gambar, konten dari header Accept Chrome adalah:

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

Meskipun semua browser mendukung format gambar seperti JPEG, PNG, dan GIF, Accept memberi tahu dalam hal ini, browser juga mendukung WebP dan APNG. Menggunakan informasi ini, kita dapat menegosiasikan jenis gambar terbaik untuk setiap 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!">

Seperti Accept, client hints adalah cara lain untuk menegosiasikan konten, tetapi dalam konteks kemampuan perangkat dan kondisi jaringan. Dengan petunjuk klien, kita dapat membuat keputusan kinerja sisi server berdasarkan pengalaman, seperti memutuskan apakah sumber daya yang tidak kritis harus disediakan untuk dengan kondisi jaringan yang buruk. Dalam panduan ini, kami akan menjelaskan semua petunjuk yang tersedia dan beberapa cara untuk menggunakannya agar pengiriman konten akomodasi bagi pengguna.

Ikut serta

Tidak seperti header Accept, client hints tidak hanya muncul secara ajaib (dengan pengecualian Save-Data, yang akan kita bahas nanti). Demi menjaga header permintaan, Anda harus memilih petunjuk klien mana yang akan ingin Anda terima dengan mengirimkan header Accept-CH saat pengguna meminta referensi:

Accept-CH: Viewport-Width, Downlink

Nilai untuk Accept-CH adalah daftar petunjuk yang diminta yang dipisahkan koma untuk situs akan digunakan dalam menentukan hasil permintaan resource berikutnya. Jika klien membaca header ini, akan diberi tahu “situs ini menginginkan Viewport-Width dan Downlink client hints.” Tidak perlu memikirkan petunjuk spesifik. Kita akan membahasnya sebentar lagi.

Anda dapat menyetel header keikutsertaan ini dalam bahasa backend apa pun. Misalnya, PHP Fungsi header dapat digunakan. Anda bahkan dapat menetapkan header keikutsertaan ini dengan http-equiv atribut pada tag <meta>:

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

Semua petunjuk klien.

Petunjuk klien menjelaskan salah satu dari dua hal: perangkat yang digunakan pengguna, gunakan, dan jaringan yang mereka gunakan untuk mengakses situs Anda. Mari kita bahas secara singkat semua petunjuk yang tersedia.

Petunjuk perangkat

Beberapa client hints menggambarkan karakteristik perangkat pengguna, biasanya layar karakteristik. Beberapa di antaranya dapat membantu Anda memilih sumber daya media yang optimal layar pengguna tertentu, tetapi tidak semuanya berpusat pada media.

Sebelum kita masuk ke daftar ini, mungkin akan membantu untuk mempelajari beberapa istilah kunci yang digunakan untuk menggambarkan layar dan resolusi media:

Ukuran intrinsik: dimensi sebenarnya dari resource media. Misalnya, jika Anda membuka gambar di Photoshop, dimensi yang ditunjukkan dalam dialog ukuran gambar menjelaskan ukuran intrinsiknya.

Ukuran intrinsik yang dikoreksi kepadatannya: dimensi resource media setelah telah dikoreksi kepadatan pikselnya. Ini merupakan ukuran intrinsik gambar dibagi dengan piksel perangkat rasio. Misalnya, mari kita ambil markup ini:

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

Misalnya ukuran intrinsik gambar 1x dalam hal ini adalah 320x240, dan Ukuran intrinsik gambar 2x adalah 640x480. Jika markup ini diuraikan oleh klien diinstal pada perangkat dengan rasio piksel perangkat layar 2 (mis., Retina layar), gambar 2x akan diminta. Ukuran intrinsik yang dikoreksi kepadatan kepadatannya dari gambar 2x adalah 320x240, karena 640x480 dibagi 2 adalah 320x240.

Ukuran ekstrinsik: ukuran resource media setelah CSS dan tata letak lainnya faktor (seperti atribut width dan height) telah diterapkan. Mari misalnya Anda memiliki elemen <img> yang memuat gambar dengan kepadatan yang dikoreksi ukuran intrinsik 320x240, tetapi juga memiliki properti width dan height CSS dengan nilai 256px dan 192px yang masing-masing diterapkan padanya. Dalam contoh ini, ukuran ekstrinsik elemen <img> tersebut menjadi 256x192.

Dengan beberapa terminologi, mari kita masuk ke daftar istilah khusus perangkat client hints yang tersedia untuk Anda.

Lebar Area Pandang

Viewport-Width adalah lebar area tampilan pengguna dalam piksel CSS:

Viewport-Width: 320

Petunjuk ini dapat digunakan dengan petunjuk khusus layar lainnya untuk memberikan hasil perlakuan (yaitu pemangkasan) gambar yang optimal untuk ukuran layar tertentu (yaitu, seni arah), atau untuk menghilangkan sumber daya yang tidak diperlukan untuk lebar layar saat ini.

DPR

DPR, singkatan dari rasio piksel perangkat, melaporkan rasio piksel fisik terhadap CSS {i>pixel<i} pada layar pengguna:

DPR: 2

Petunjuk ini berguna saat memilih sumber gambar yang sesuai dengan kepadatan piksel (seperti yang dilakukan deskriptor x di srcset ).

Lebar

Petunjuk Width muncul saat ada permintaan resource gambar yang diaktifkan oleh <img> atau <source> tag menggunakan sizes . sizes memberi tahu browser tentang ukuran ekstrinsik resource; Width menggunakan ukuran eksternal tersebut untuk meminta gambar dengan ukuran intrinsik yang sudah optimal untuk tata letak saat ini.

Misalnya, pengguna meminta halaman dengan layar lebar 320 piksel CSS dengan DPR 2. Perangkat memuat dokumen dengan elemen <img> yang berisi nilai atribut sizes dari 85vw (yaitu, 85% dari lebar area pandang untuk semua ukuran layar). Jika petunjuk Width telah diikutsertakan, klien akan mengirim petunjuk Width ini ke server dengan permintaan untuk src <img>:

Width: 544

Dalam hal ini, klien mengisyaratkan ke server bahwa nilai intrinsik yang optimal lebar untuk gambar yang diminta akan menjadi 85% dari lebar area pandang (272 piksel) dikalikan dengan DPR layar (2), yang sama dengan 544 {i>pixel<i}.

Petunjuk ini sangat bermanfaat karena tidak hanya memperhitungkan dengan koreksi kepadatan layar, tetapi juga merekonsiliasi bagian penting ini dengan ukuran eksternal gambar dalam tata letak. Ini memberi server untuk menegosiasikan respons gambar yang optimal bagi layar dan tata letak.

Konten-DPR

Meskipun Anda sudah mengetahui bahwa layar memiliki rasio piksel perangkat, resource juga memiliki rasio pikselnya sendiri. Dalam kasus penggunaan pemilihan resource yang paling sederhana, piksel rasio antara perangkat dan resource bisa sama. Tapi! Dalam kasus di mana header DPR dan Width berperan, ukuran ekstrinsik resource dapat menghasilkan skenario di mana keduanya berbeda. Di sinilah petunjuk Content-DPR mulai berperan.

Tidak seperti client hints lainnya, Content-DPR bukan header request yang akan digunakan oleh server, melainkan server header respons harus dikirim setiap kali DPR dan Petunjuk Width digunakan untuk memilih resource. Nilai Content-DPR harus adalah hasil dari persamaan ini:

Content-DPR = [Ukuran resource gambar yang dipilih] / ([Width] / [DPR])

Saat header permintaan Content-DPR dikirim, browser akan mengetahui cara melakukan penskalaan gambar yang diberikan untuk tata letak dan rasio piksel perangkat layar. Tanpa hal tersebut, gambar mungkin tidak diskalakan dengan benar.

Memori Perangkat

Secara teknis merupakan bagian dari Memori Perangkat API, Device-Memory menampilkan jumlah perkiraan memori perangkat saat ini memiliki dalam GiB:

Device-Memory: 2

Kasus penggunaan yang mungkin untuk petunjuk ini adalah untuk mengurangi jumlah JavaScript dikirim ke browser pada perangkat dengan memori terbatas, karena JavaScript adalah {i>browser<i} jenis konten yang memerlukan banyak sumber daya biasanya pemuatan. Atau, Anda dapat mengirim gambar DPR yang lebih rendah karena menggunakan lebih sedikit memori untuk mendekode.

Petunjuk jaringan

Network Information API menyediakan kategori client hints yang menggambarkan performa jaringan pengguna koneksi jarak jauh. Menurut pendapat saya, ini adalah kumpulan petunjuk yang paling berguna. Dengan mereka, kita memiliki kemampuan untuk menyesuaikan pengalaman bagi pengguna dengan mengubah cara kami memberikan sumber daya ke klien pada koneksi yang lambat.

RTT

Petunjuk RTT memberikan perkiraan Waktu Round Trip, dalam milidetik, di lapisan aplikasi Petunjuk RTT, tidak seperti RTT lapisan transpor, mencakup dapat mengurangi waktu pemrosesan server.

RTT: 125

Petunjuk ini berguna karena latensi peran yang dimainkan dalam performa pemuatan. Dengan menggunakan petunjuk RTT, kita dapat membuat keputusan berdasarkan responsivitas jaringan, yang dapat membantu mempercepat penyampaian seluruh pengalaman (mis., melalui menghilangkan beberapa permintaan).

Downlink

Meskipun latensi penting dalam performa pemuatan, {i>bandwidth<i} berperan, berikutnya Petunjuk Downlink, yang dinyatakan dalam megabit per detik (Mbps), mengungkapkan perkiraan kecepatan downstream koneksi pengguna:

Downlink: 2.5

Bersama dengan RTT, Downlink dapat berguna untuk mengubah cara konten yang dikirimkan ke pengguna berdasarkan kualitas koneksi jaringan.

ECT

Petunjuk ECT adalah singkatan dari Effective Connection Type. Nilainya adalah salah satu daftar jenis koneksi terenumerasi, yang masing-masing menjelaskan koneksi dalam rentang yang ditentukan, baik RTT maupun Downlink Google Cloud Platform.

Header ini tidak menjelaskan apa jenis koneksi sebenarnya—untuk tidak melaporkan apakah {i>gateway<i} Anda adalah menara BTS atau akses Wi-Fi poin. Sebaliknya, ia menganalisis latensi dan {i>bandwidth <i} koneksi saat ini dan menentukan profil jaringan yang paling mirip. Misalnya, jika Anda menghubungkan melalui Wi-Fi ke jaringan lambat, ECT dapat diisi dengan nilai 2g, yang merupakan perkiraan terdekat dari koneksi efektif:

ECT: 2g

Nilai yang valid untuk ECT adalah 4g, 3g, 2g, dan slow-2g. Petunjuk ini dapat berupa digunakan sebagai titik awal untuk menilai kualitas koneksi, dan selanjutnya yang ditingkatkan menggunakan petunjuk RTT dan Downlink.

Simpan-Data

Save-Data bukanlah petunjuk yang menjelaskan kondisi jaringan karena merupakan pengguna preferensi yang menyatakan bahwa laman harus mengirim lebih sedikit data.

Saya lebih suka mengklasifikasikan Save-Data sebagai petunjuk jaringan karena banyak hal yang akan Anda lakukan dengan cara itu mirip dengan petunjuk jaringan lainnya. Pengguna mungkin juga mungkin mengaktifkannya di lingkungan latensi tinggi/bandwidth rendah. Petunjuk ini, kapan ada, selalu terlihat seperti ini:

Save-Data: on

Di Google, kami telah membahas apa yang dapat Anda lakukan dengan Save-Data. Dampaknya terhadap performa bisa sangat besar. Ini adalah sinyal di mana pengguna meminta Anda untuk mengirimkan lebih sedikit hal kepada mereka! Jika Anda mendengarkan dan menindaklanjutinya sinyal ini, pengguna akan menghargainya.

Memadukan semuanya sekaligus

Tindakan yang Anda lakukan dengan client hints bergantung pada Anda. Karena mereka menawarkan begitu banyak tambahan, Anda memiliki banyak pilihan. Agar ide dapat mengalir, mari kita lihat petunjuk klien dapat dilakukan untuk Sconnie Kayu, kayu fiktif perusahaan yang berlokasi di pedesaan Upper Midwest. Seperti yang sering terjadi pada remote area, koneksi jaringan bisa saja rapuh. Di sinilah teknologi seperti client hints benar-benar dapat membuat perbedaan bagi pengguna.

Gambar Responsif

Semua kecuali kasus penggunaan gambar responsif yang paling sederhana bisa menjadi rumit. Bagaimana jika Anda memiliki beberapa perlakuan dan varian dari gambar yang sama untuk layar yang berbeda ukuran—dan format yang berbeda? Markup tersebut menjadi sangat rumit sangat dengan cepat. Sangat mudah untuk keliru, dan mudah dilupakan atau salah memahami hal penting (seperti sizes).

Meskipun <picture> dan srcset merupakan alat yang sangat luar biasa, keduanya dapat memakan waktu lama untuk mengembangkan dan memelihara kasus penggunaan yang kompleks. Kita dapat mengotomatiskan pembuatan markup, tetapi melakukannya juga sulit karena fungsionalitas yang disediakan <picture> dan srcset cukup kompleks sehingga diperlukan otomatisasinya dilakukan dengan cara yang mempertahankan fleksibilitas.

Petunjuk klien dapat menyederhanakannya. Menegosiasikan respons gambar dengan klien petunjuk akan terlihat seperti ini:

1. Jika berlaku untuk alur kerja Anda, pertama-tama pilih perlakuan gambar (yaitu, gambar yang ditujukan untuk seni) dengan memeriksa petunjuk Viewport-Width.
2. Pilih resolusi gambar dengan memeriksa petunjuk Width dan petunjuk DPR, lalu memilih sumber yang cocok dengan ukuran tata letak dan kepadatan layar gambar (mirip cara kerja deskripsi x dan w di srcset).
3. Pilih format file paling optimal yang didukung browser (seperti Accept membantu kita melakukan di sebagian besar browser).

Ketika klien perusahaan kayu fiktif saya merasa khawatir, saya mengembangkan rutinitas pemilihan gambar responsif di PHP yang menggunakan client hints. Ini berarti bukan mengirim markup ini ke semua pengguna:

<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>

Saya dapat menguranginya menjadi berikut berdasarkan dukungan masing-masing browser:

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

Dalam contoh ini, URL /image adalah skrip PHP yang diikuti dengan parameter ditulis ulang oleh mod_rewrite. Ini mengambil nama file gambar dan parameter tambahan untuk membantu skrip {i>back-end<i} memilih gambar terbaik dalam kondisi tertentu.

Saya merasa “Namun, bukankah ini hanya mengimplementasikan kembali <picture> dan srcset pada back-end?” adalah pertanyaan pertama Anda.

Ya—tapi dengan perbedaan penting: saat aplikasi menggunakan petunjuk klien untuk membuat respons media, sebagian besar (atau bahkan tidak semua) pekerjaan lebih mudah diotomatiskan, yang dapat mencakup layanan (seperti CDN) yang dapat melakukannya atas nama Anda. Sedangkan dengan solusi HTML, markup baru perlu ditulis menjadi sediakan untuk setiap kasus penggunaan. Tentu saja, Anda dapat mengotomatiskan pembuatan markup. Jika atau perubahan persyaratan, ada kemungkinan besar Anda harus meninjau kembali strategi otomatisasi Anda di masa mendatang.

Petunjuk klien memungkinkan untuk memulai dengan resolusi tinggi dan lossless gambar yang nantinya dapat diubah ukurannya secara dinamis agar optimal untuk kombinasi apa pun dari layar dan tata letak. Tidak seperti srcset, yang mengharuskan Anda menghitung nilai daftar kandidat gambar yang dapat dipilih oleh browser, pendekatan ini bisa lebih fleksibel. Sementara srcset memaksa Anda untuk menawarkan kumpulan umum ke browser varian—misalnya, 256w, 512w, 768w, dan 1024w—petunjuk klien solusi yang didukung dapat melayani berbagai jenis lebar, tanpa tumpukan markup yang besar.

Tentu saja, Anda tidak perlu menulis logika pemilihan gambar sendiri. Cloudinary menggunakan client hints untuk membuat respons gambar saat Anda menggunakan w_auto parameter, dan mengamati bahwa median pengguna mendownload 42% lebih sedikit byte saat menggunakan browser petunjuk klien pendukung.

Tapi berhati-hatilah! Perubahan pada Chrome 67 versi desktop telah menghapus dukungan untuk klien lintas origin petunjuk. Untungnya, pembatasan ini tidak memengaruhi versi seluler Chrome, dan fitur tersebut akan dicabut untuk semua platform saat mengerjakan Fitur Kebijakan selesai.

Membantu pengguna dengan jaringan yang lambat

Performa adaptif adalah ide bahwa kita dapat menyesuaikan cara kita menghasilkan resource berdasarkan informasi yang disediakan petunjuk klien kepada kita; secara spesifik informasi seputar status koneksi jaringan pengguna saat ini.

Apabila situs Sconnie Timber bermasalah, kami mengambil langkah untuk meringankan beban saat jaringan lambat, dengan header Save-Data, ECT, RTT, dan Downlink diperiksa dalam kode {i>back-end<i}. Setelah selesai, kita akan menghasilkan kualitas jaringan skor yang dapat digunakan untuk menentukan apakah kita harus melakukan intervensi demi meningkatkan pengalaman yang lancar bagi developer. Skor jaringan ini antara 0 dan 1, dengan 0 adalah yang terburuk jaringan yang memungkinkan, dan 1 adalah yang terbaik.

Awalnya, kami memeriksa apakah Save-Data ada. Jika ya, skor akan ditetapkan ke 0, karena kita berasumsi bahwa pengguna ingin kita melakukan tindakan yang diperlukan untuk membuat pengalaman yang lebih ringan dan lebih cepat.

Namun, jika Save-Data tidak ada, kita akan melanjutkan dan menimbang nilai ECT, RTT, dan Downlink petunjuk untuk menghitung skor yang mendeskripsikan jaringan kualitas koneksi. Sumber pembuatan skor jaringan kode yang tersedia di GitHub. Kesimpulannya adalah, jika kita menggunakan petunjuk terkait jaringan di beberapa mode, kami bisa membuat pengalaman lebih baik bagi pengguna yang lambat jaringan.

Saat situs beradaptasi dengan informasi yang diberikan oleh petunjuk klien, kita tidak harus mengadopsi pendekatan "semua atau tidak sama sekali". Kita dapat dengan cerdas memutuskan sumber daya mana yang akan kirim. Kita dapat mengubah logika pemilihan gambar responsif untuk mengirim kualitas yang lebih rendah gambar untuk tampilan tertentu guna mempercepat pemuatan performa saat kualitas jaringan buruk.

Dalam contoh ini, kita dapat melihat dampak petunjuk klien dalam hal meningkatkan kinerja situs pada jaringan yang lebih lambat. Di bawah ini adalah WebPagetest waterfall situs di jaringan lambat yang tidak beradaptasi dengan petunjuk klien:

Dan sekarang, waterfall untuk situs yang sama di koneksi lambat yang sama, hanya saja waktu, situs menggunakan petunjuk klien untuk menghilangkan sumber daya halaman yang tidak penting:

Client hints mengurangi waktu muat halaman dari lebih dari 45 detik menjadi kurang dari kesepuluh dari waktu tersebut. Manfaat {i>client hints<i} dalam skenario ini tidak dapat cukup ditekankan dan dapat menjadi keuntungan yang signifikan bagi pengguna yang mencari informasi melalui jaringan yang lambat.

Selain itu, Anda dapat menggunakan client hints tanpa merusak pengalaman untuk browser yang tidak mendukungnya. Misalnya, jika kita ingin menyesuaikan resource pengiriman sesuai nilai petunjuk ECT sambil tetap memberikan respons penuh untuk browser yang tidak mendukung, kita dapat menetapkan kembali ke nilai default seperti ini:

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

Di sini, "4g" merepresentasikan koneksi jaringan berkualitas tertinggi dari header ECT menjelaskan. Jika kita menginisialisasi $ect ke "4g", browser yang tidak mendukung klien petunjuk tidak akan terpengaruh. Ikut serta dalam FTW!

Abaikan {i>cache<i} itu!

Setiap kali Anda mengubah respons berdasarkan {i>header<i} HTTP, Anda perlu mengetahui bagaimana cache akan menangani pengambilan resource tersebut di masa mendatang. Vary header adalah sangat diperlukan di sini, karena akan mengunci entri cache ke nilai header permintaan yang disediakan. Sederhananya, jika Anda memodifikasi respons apa pun berdasarkan header permintaan, Anda harus hampir selalu menyertakan header permintaan tersebut di Vary seperti ini:

Vary: DPR, Width

Namun, ada peringatan besar untuk hal ini: Anda tidak ingin Vary dapat di-cache respons pada header yang sering berubah (seperti Cookie) karena secara efektif tidak dapat di-cache. Mengetahui hal ini, Anda mungkin ingin menghindari Vary di header petunjuk klien, seperti RTT atau Downlink, karena keduanya yang bisa berubah cukup sering. Jika Anda ingin memodifikasi respons header tersebut, pertimbangkan untuk hanya memasukkan header ECT, yang akan meminimalkan cache tidak ditemukan.

Tentu saja, ini hanya berlaku jika Anda menyimpan respons dalam cache sejak awal. Misalnya, Anda tidak akan menyimpan aset HTML dalam cache jika kontennya dinamis, karena yang dapat merusak pengalaman pengguna pada kunjungan berulang. Dalam kasus seperti ini, bebas untuk mengubah tanggapan tersebut atas dasar apa pun yang dirasa perlu dan tidak masalahkan diri Anda dengan Vary.

Petunjuk klien dalam pekerja layanan

Negosiasi konten bukan hanya untuk server! Karena pekerja layanan bertindak sebagai {i>proxy<i} antara klien dan server, Anda memiliki kendali atas bagaimana sumber daya ditayangkan melalui JavaScript. Ini termasuk client hints. Di pekerja layanan fetch, Anda dapat menggunakan objek event request.headers.get untuk membaca header permintaan resource seperti berikut:

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!
    })(),
  );
});

Header petunjuk klien apa pun yang Anda pilih dapat dibaca dengan cara ini. Meskipun itu bukan satu-satunya cara Anda bisa mendapatkan beberapa informasi ini. Petunjuk khusus jaringan dapat dibaca di properti JavaScript yang setara ini dalam objek navigator:

Plugin imagemin untuk jenis file.

Petunjuk klien	Setara dengan JS
`ECT`	`navigator.connection.effectiveType`
`RTT`	`navigator.connection.rtt`
`Simpan-Data`	`navigator.connection.saveData`
`Downlink`	`navigator.connection.downlink`
`Memori Perangkat`	`navigator.deviceMemory`

Karena API ini tidak tersedia di mana pun Anda memerlukan pemeriksaan fitur dengan in operator:

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

Dari sini, Anda dapat menggunakan logika yang mirip dengan yang Anda gunakan di server, kecuali Anda tidak memerlukan server untuk menegosiasikan konten dengan client hints. Layanan pekerja saja memiliki kekuatan untuk membuat pengalaman lebih cepat dan lebih tangguh karena dengan kemampuan tambahan yang mereka miliki untuk menyajikan konten saat pengguna sedang offline.

Menyelesaikan

Dengan client hints, kita memiliki kemampuan untuk membuat pengalaman pengguna lebih cepat progresif. Kami dapat menyajikan media berdasarkan perangkat pengguna dengan cara yang membuat penayangan gambar responsif lebih mudah daripada mengandalkan di <picture> dan srcset, terutama untuk kasus penggunaan yang kompleks. Hal ini memungkinkan kita untuk tidak hanya mengurangi waktu dan upaya pada sisi pengembangan, tetapi juga untuk mengoptimalkan sumber daya—terutama gambar—dengan cara yang menargetkan layar pengguna lebih halus daripada dan srcset dapat.

Mungkin yang lebih penting, kita dapat mendeteksi koneksi jaringan yang buruk dan kesenjangan bagi pengguna dengan memodifikasi apa yang kita kirim dan bagaimana kita mengirimkannya. Hal ini dapat lakukan panjang untuk membuat situs lebih mudah diakses bagi pengguna di jaringan yang rentan. Dikombinasikan dengan pekerja layanan, kita dapat membuat situs yang sangat cepat yang tersedia secara offline.

Meskipun client hints hanya tersedia di Chrome—dan berbasis Chromium {i>browser<i}—dapat digunakan sedemikian rupa sehingga tidak membebani browser yang tidak mendukungnya. Pertimbangkan untuk menggunakan client hints untuk membuat pengalaman inklusif dan adaptif yang memperhatikan setiap perangkat pengguna kemampuan mereka, dan jaringan yang terhubung dengan mereka. Semoga, vendor {i>browser<i} lainnya akan melihat nilainya dan menunjukkan maksud yang akan diimplementasikan.

Resource

• Gambar Responsif Otomatis dengan Klien Petunjuk
• Petunjuk Klien dan Gambar Responsif—Yang Berubah di Chrome 67
• Ambil Petunjuk (Klien). (Slide)
• Menghadirkan Aplikasi yang Cepat dan Ringan dengan Save-Data

Terima kasih kepada Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss, dan Estelle Weyl atas masukan dan hasil edit yang berharga terkait artikel ini.