Mengembangkan situs yang cepat di mana saja bisa menjadi prospek yang rumit. Banyaknya kemampuan perangkat—dan kualitas jaringan yang terhubung dengannya—dapat membuatnya tampak seperti tugas yang tidak dapat diatasi. Meskipun kita dapat memanfaatkan fitur browser untuk meningkatkan performa pemuatan, bagaimana cara mengetahui kemampuan perangkat pengguna, atau kualitas koneksi jaringannya? Solusinya adalah petunjuk klien.
Client hints adalah sekumpulan header permintaan HTTP keikutsertaan yang memberi kami insight tentang aspek-aspek perangkat pengguna dan jaringan yang terhubung dengannya. Dengan memanfaatkan sisi server informasi ini, kita dapat mengubah cara kami mengirimkan konten berdasarkan perangkat dan/atau kondisi jaringan. Hal ini dapat membantu kita menciptakan pengalaman pengguna yang lebih inklusif.
Intinya adalah Negosiasi Konten
Petunjuk klien adalah metode negosiasi konten lain, yang berarti mengubah respons konten berdasarkan header permintaan browser.
Salah satu contoh negosiasi konten melibatkan
header
permintaan Accept. File ini menjelaskan jenis konten yang dipahami browser, yang
dapat digunakan server untuk menegosiasikan respons. Untuk permintaan gambar, konten
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 akan memberi tahu dalam hal ini bahwa browser juga mendukung WebP dan APNG. Dengan 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 client hints, kita
dapat membuat keputusan performa sisi server berdasarkan pengalaman individual
pengguna, seperti memutuskan apakah resource yang tidak penting harus ditayangkan kepada
pengguna dengan kondisi jaringan yang buruk. Dalam panduan ini, kami akan menjelaskan semua
petunjuk yang tersedia dan beberapa cara yang dapat Anda gunakan untuk membuat pengiriman konten lebih
akomodasi bagi pengguna.
Ikut serta
Tidak seperti header Accept, petunjuk klien tidak hanya muncul secara ajaib (dengan
pengecualian Save-Data, yang akan kita bahas nanti). Untuk meminimalkan
header permintaan, Anda harus memilih petunjuk klien mana yang ingin
Anda terima dengan mengirim header Accept-CH saat pengguna meminta
resource:
Accept-CH: Viewport-Width, Downlink
Nilai untuk Accept-CH adalah daftar petunjuk yang diminta yang dipisahkan koma, yang akan digunakan situs
dalam menentukan hasil untuk permintaan resource berikutnya. Saat
klien membaca header ini, diberi tahu “situs ini menginginkan petunjuk klien Viewport-Width
dan Downlink”. Jangan khawatir tentang petunjuk spesifik itu sendiri.
Kita akan membahasnya sebentar lagi.
Anda dapat menyetel header keikutsertaan ini dalam bahasa back-end apa pun. Misalnya, fungsi header PHP dapat digunakan.
Anda bahkan dapat menetapkan header keikutsertaan ini dengan atribut http-equiv pada tag <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Semua petunjuk klien.
Client hints menjelaskan salah satu dari dua hal: perangkat yang digunakan pengguna, dan jaringan yang mereka gunakan untuk mengakses situs Anda. Mari kita bahas secara singkat semua petunjuk yang tersedia.
Petunjuk perangkat
Beberapa client hints menjelaskan karakteristik perangkat pengguna, biasanya karakteristik layar. Beberapa referensi tersebut dapat membantu Anda memilih resource media yang optimal untuk layar pengguna tertentu, tetapi tidak semuanya selalu berpusat pada media.
Sebelum masuk ke daftar ini, sebaiknya pelajari beberapa istilah utama yang digunakan untuk menjelaskan layar dan resolusi media:
Ukuran intrinsik: dimensi resource media sebenarnya. Misalnya, jika Anda membuka gambar di Photoshop, dimensi yang ditampilkan dalam dialog ukuran gambar menjelaskan ukuran intrinsiknya.
Ukuran intrinsik yang dikoreksi kepadatan: dimensi resource media setelah kepadatan piksel dikoreksi. Ini adalah ukuran intrinsik gambar yang dibagi dengan rasio piksel perangkat. Sebagai contoh, 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
yang diinstal di perangkat dengan rasio piksel perangkat layar 2 (misalnya, layar Retina), image 2x akan diminta. Ukuran intrinsik yang dikoreksi kepadatan untuk
gambar 2x adalah 320x240, karena 640x480 dibagi 2 adalah 320x240.
Ukuran ekstrinsik: ukuran resource media setelah CSS dan faktor tata letak
lainnya (seperti atribut width dan height) diterapkan ke resource tersebut. Misalnya,
Anda memiliki elemen <img> yang memuat gambar dengan ukuran intrinsik
yang dikoreksi kepadatannya, yakni 320x240, tetapi elemen tersebut juga memiliki properti width dan height CSS
dengan nilai 256px dan 192px yang diterapkan padanya. Dalam contoh ini,
ukuran ekstrinsik elemen <img> tersebut menjadi 256x192.
width: 256px;
dan height: 192px; akan mengubah gambar berukuran intrinsik 320x240
menjadi gambar berukuran ekstrinsik 256x192.Setelah memahami beberapa terminologi, mari kita masuk ke daftar petunjuk klien khusus perangkat yang tersedia untuk Anda.
Lebar Area Pandang
Viewport-Width adalah lebar area pandang pengguna dalam piksel CSS:
Viewport-Width: 320
Petunjuk ini dapat digunakan bersama petunjuk khusus layar lainnya untuk memberikan penanganan yang berbeda (yaitu pemangkasan) gambar yang optimal untuk ukuran layar tertentu (yaitu, arah art), atau untuk menghilangkan resource yang tidak diperlukan untuk lebar layar saat ini.
DPR
DPR, yang merupakan singkatan dari rasio piksel perangkat, melaporkan rasio piksel fisik terhadap piksel
CSS layar pengguna:
DPR: 2
Petunjuk ini berguna saat memilih sumber gambar yang sesuai dengan kepadatan piksel
layar (seperti yang dilakukan deskripsi x dalam atribut
srcset).
Lebar
Petunjuk Width muncul pada permintaan resource gambar yang diaktifkan oleh tag <img> atau
<source> menggunakan atribut
sizes.
sizes memberi tahu browser tentang ukuran ekstrinsik resource;
Width menggunakan ukuran ekstrinsik tersebut untuk meminta gambar dengan ukuran intrinsik
yang optimal untuk tata letak saat ini.
Misalnya, pengguna meminta halaman dengan layar lebar piksel CSS 320
dengan DPR 2. Perangkat memuat dokumen dengan elemen <img> yang berisi
nilai atribut sizes 85vw (yaitu, 85% dari lebar area pandang untuk semua
ukuran layar). Jika petunjuk Width telah disertakan, klien akan mengirimkan
petunjuk Width ini ke server dengan permintaan untuk src <img>:
Width: 544
Dalam hal ini, klien mengisyaratkan server bahwa lebar intrinsik yang optimal untuk gambar yang diminta adalah 85% dari lebar area pandang (272 piksel) dikalikan dengan DPR layar (2), yang sama dengan 544 piksel.
Petunjuk ini sangat berguna karena tidak hanya memperhitungkan lebar layar yang dikoreksi kepadatan, tetapi juga merekonsiliasi bagian informasi penting ini dengan ukuran ekstrinsik gambar dalam tata letak. Hal ini memberi server kesempatan untuk menegosiasikan respons gambar yang optimal untuk layar dan tata letak.
DPR-Konten
Meskipun Anda sudah mengetahui bahwa layar memiliki rasio piksel perangkat, resource juga
memiliki rasio pikselnya sendiri. Dalam kasus penggunaan pemilihan resource yang paling sederhana, rasio piksel
antara perangkat dan resource bisa sama. Tapi! Jika
header DPR dan Width sama-sama berfungsi, ukuran ekstrinsik resource dapat
menghasilkan skenario yang membedakan keduanya. Di sinilah petunjuk Content-DPR
berperan.
Tidak seperti client hints lainnya, Content-DPR bukanlah header request yang akan digunakan oleh
server, melainkan sebagai server header response harus dikirim setiap kali petunjuk DPR dan
Width digunakan untuk memilih resource. Nilai Content-DPR akan
merupakan hasil dari persamaan ini:
Content-DPR = [Ukuran resource gambar yang dipilih] / ([Width] / [DPR])
Saat header permintaan Content-DPR dikirim, browser akan mengetahui cara menskalakan
gambar yang diberikan untuk rasio piksel perangkat layar dan tata letak. Tanpanya,
gambar mungkin tidak diskalakan dengan benar.
Memori Perangkat
Secara teknis, bagian dari Device Memory
API, Device-Memory mengungkapkan perkiraan jumlah
memori
yang dimiliki perangkat saat ini dalam GiB:
Device-Memory: 2
Kasus penggunaan yang memungkinkan untuk petunjuk ini adalah mengurangi jumlah JavaScript yang dikirim ke browser pada perangkat dengan memori terbatas, karena JavaScript adalah jenis konten yang menggunakan resource secara intensif dan biasanya dimuat. Atau, Anda dapat mengirim gambar DPR yang lebih rendah karena menggunakan lebih sedikit memori untuk didekode.
Petunjuk jaringan
Network Information API menyediakan kategori klien petunjuk lain yang menjelaskan performa koneksi jaringan pengguna. Menurut saya, ini adalah kumpulan petunjuk yang paling berguna. Dengan model tersebut, kami memiliki kemampuan untuk menyesuaikan pengalaman bagi pengguna dengan mengubah cara kami memberikan resource kepada klien dengan koneksi yang lambat.
RTT
Petunjuk RTT memberikan perkiraan Waktu Round Trip, dalam milidetik, pada
lapisan aplikasi. Petunjuk RTT, tidak seperti lapisan transpor RTT, mencakup 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 penayangan seluruh pengalaman (misalnya, dengan
menghilangkan beberapa permintaan).
Downlink
Meskipun latensi penting dalam performa pemuatan, bandwidth juga
berpengaruh. Petunjuk Downlink, yang dinyatakan dalam megabit per detik (Mbps), mengungkapkan
kecepatan downstream perkiraan koneksi pengguna:
Downlink: 2.5
Bersama dengan RTT, Downlink dapat berguna dalam mengubah cara konten
dikirimkan kepada 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 dari nilai RTT dan
Downlink.
Header ini tidak menjelaskan jenis koneksi sebenarnya. Misalnya, header ini tidak melaporkan apakah gateway Anda adalah menara BTS atau titik akses Wi-Fi. Namun, Cloud Firestore menganalisis latensi dan bandwidth koneksi saat ini, serta menentukan profil jaringan yang paling mirip. Misalnya, jika Anda terhubung
melalui Wi-Fi ke jaringan yang lambat, ECT dapat diisi dengan nilai 2g,
yang merupakan perkiraan terdekat dari koneksi yang efektif:
ECT: 2g
Nilai yang valid untuk ECT adalah 4g, 3g, 2g, dan slow-2g. Petunjuk ini dapat
digunakan sebagai titik awal untuk menilai kualitas koneksi, dan kemudian
disaring menggunakan petunjuk RTT dan Downlink.
Simpan-Data
Save-Data bukanlah petunjuk yang menjelaskan kondisi jaringan karena merupakan preferensi
pengguna yang menyatakan bahwa halaman harus mengirim lebih sedikit data.
Saya lebih suka mengklasifikasikan Save-Data sebagai petunjuk jaringan karena banyak hal
yang akan Anda lakukan dengannya mirip dengan petunjuk jaringan lainnya. Pengguna mungkin juga mengaktifkannya di lingkungan latensi tinggi/bandwidth rendah. Petunjuk ini, jika ada, selalu terlihat seperti ini:
Save-Data: on
Di Google, kami telah membahas apa yang dapat Anda lakukan dengan
Save-Data.
Dampaknya terhadap performa dapat sangat besar. Itu adalah sinyal di mana pengguna benar-benar
meminta Anda untuk mengirim lebih sedikit barang! Jika Anda mendengarkan dan menindaklanjuti
sinyal itu, pengguna akan menghargainya.
Memadukan semuanya sekaligus
Tindakan yang dilakukan dengan petunjuk klien bergantung pada Anda. Karena mereka menawarkan begitu banyak informasi, Anda memiliki banyak pilihan. Supaya mengalirkan ide, mari kita lihat apa yang dapat dilakukan petunjuk klien untuk Sconnie Timber, sebuah perusahaan kayu fiktif yang terletak di pedesaan Upper Midwest. Seperti yang sering terjadi di area jarak jauh, koneksi jaringan bisa saja rapuh. Di sinilah teknologi seperti petunjuk klien benar-benar dapat membuat perbedaan bagi pengguna.
Gambar Responsif
Semua kasus penggunaan gambar responsif, kecuali yang paling sederhana, bisa menjadi rumit. Bagaimana jika Anda memiliki beberapa perlakuan dan varian gambar yang sama untuk ukuran layar yang berbeda, dan format yang berbeda? Markup tersebut menjadi sangat rumit dengan sangat
cepat.
Masalah ini mudah terjadi, dan mudah dilupakan atau salah memahami konsep
penting (seperti sizes).
Meskipun <picture> dan srcset adalah alat yang luar biasa, pengembangan dan pemeliharaan untuk kasus penggunaan yang kompleks dapat
memakan waktu lama. Kami dapat mengotomatiskan
pembuatan markup, tetapi melakukannya juga sulit karena fungsi
yang disediakan <picture> dan srcset cukup kompleks sehingga otomatisasinya harus
dilakukan dengan cara yang mempertahankan fleksibilitas yang diberikannya.
Client hints dapat menyederhanakan ini. Menegosiasikan respons gambar dengan petunjuk klien dapat terlihat seperti ini:
- Jika berlaku untuk alur kerja Anda, pertama-tama pilih perlakuan gambar (yaitu,
gambar yang ditujukan untuk seni) dengan memeriksa petunjuk
Viewport-Width. - Pilih resolusi gambar dengan memeriksa petunjuk
Widthdan petunjukDPR, serta pilih sumber yang sesuai dengan ukuran tata letak dan kepadatan layar gambar (serupa dengan cara kerja deskripsixdanwdisrcset). - Pilih format file paling optimal yang didukung browser (fitur
Acceptmembantu kami melakukannya di sebagian besar browser).
Bagi klien perusahaan kayu fiktif, saya mengembangkan rutinitas pemilihan gambar responsif yang naif 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 hal berikut berdasarkan dukungan browser masing-masing:
<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 yang ditulis ulang oleh mod_rewrite. Diperlukan nama file gambar dan parameter tambahan untuk membantu skrip back-end memilih gambar terbaik dalam kondisi tertentu.
Saya merasa “Tapi bukankah ini hanya menerapkan kembali <picture> dan srcset di
back-end?” adalah pertanyaan pertama Anda.
Tentu saja, tetapi dengan perbedaan yang penting: saat aplikasi menggunakan petunjuk klien untuk membuat respons media, sebagian besar (jika tidak semua) pekerjaan akan jauh lebih mudah diotomatiskan, yang dapat mencakup layanan (seperti CDN) yang dapat melakukannya atas nama Anda. Sedangkan dengan solusi HTML, markup baru harus ditulis untuk memenuhi setiap kasus penggunaan. Tentu, Anda dapat mengotomatiskan pembuatan markup. Namun, jika desain atau persyaratan Anda berubah, kemungkinan besar Anda perlu meninjau kembali strategi otomatisasi di masa mendatang.
Petunjuk klien memungkinkan untuk memulai dengan gambar lossless beresolusi tinggi
yang kemudian dapat diubah ukurannya secara dinamis agar optimal untuk kombinasi
layar dan tata letak apa pun. Tidak seperti srcset, yang mengharuskan Anda menghitung
daftar tetap kemungkinan kandidat gambar untuk dipilih browser, pendekatan ini
dapat lebih fleksibel. Sementara srcset memaksa Anda untuk menawarkan serangkaian varian sementara ke browser—misalnya, 256w, 512w, 768w, dan 1024w—solusi yang didukung petunjuk klien dapat melayani semua lebar, tanpa tumpukan markup yang besar.
Tentu saja, Anda tidak perlu menulis logika pemilihan gambar sendiri. Cloudinary menggunakan petunjuk klien untuk membuat respons gambar saat Anda menggunakan parameter w_auto, dan mengamati bahwa pengguna median mendownload byte 42% lebih sedikit saat menggunakan browser yang mendukung petunjuk klien.
Tapi hati-hati! Perubahan pada Chrome 67 versi desktop telah menghapus dukungan untuk petunjuk klien lintas origin. Untungnya, pembatasan ini tidak memengaruhi Chrome versi seluler, dan akan dicabut sama sekali untuk semua platform saat mengerjakan Kebijakan Fitur selesai.
Membantu pengguna di jaringan lambat
Performa adaptif adalah gagasan bahwa kita dapat menyesuaikan cara mengirimkan resource berdasarkan informasi yang disediakan petunjuk klien untuk kita; khususnya informasi seputar status koneksi jaringan pengguna saat ini.
Jika terkait dengan situs Sconnie Timber, kami mengambil langkah untuk meringankan beban saat jaringan lambat, dengan header Save-Data, ECT, RTT, dan Downlink sedang diperiksa dalam kode back-end kami. Ketika ini dilakukan, kita menghasilkan skor kualitas jaringan yang dapat digunakan untuk menentukan apakah kita harus melakukan intervensi demi pengalaman pengguna yang lebih baik. Skor jaringan ini antara 0 dan 1, dengan 0 sebagai kualitas jaringan terburuk yang mungkin, dan 1 adalah yang terbaik.
Awalnya, kita akan memeriksa apakah Save-Data ada. Jika ya, skor akan ditetapkan ke
0, karena kita berasumsi bahwa pengguna ingin kita melakukan apa pun yang diperlukan untuk membuat
pengalaman lebih ringan dan lebih cepat.
Namun, jika Save-Data tidak ada, kami melanjutkan dan mempertimbangkan nilai petunjuk ECT,
RTT, dan Downlink untuk menghitung skor yang menjelaskan kualitas
koneksi jaringan. Kode sumber
pembuatan skor jaringan
tersedia di GitHub. Intinya adalah, jika kita menggunakan petunjuk terkait jaringan dalam
beberapa cara, kita dapat membuat pengalaman lebih baik bagi pengguna yang menggunakan jaringan
lambat.
Saat situs beradaptasi dengan informasi yang diberikan petunjuk klien, kita tidak perlu menggunakan pendekatan "semua atau tidak sama sekali". Kita bisa secara cerdas memutuskan sumber daya mana yang akan dikirim. Kita dapat mengubah logika pemilihan gambar responsif untuk mengirim gambar berkualitas yang lebih rendah untuk tampilan tertentu guna mempercepat performa pemuatan saat kualitas jaringan rendah.
Dalam contoh ini, kita dapat melihat dampak client hints untuk meningkatkan performa situs di jaringan yang lebih lambat. Berikut adalah waterfall WebPagetest dari situs di jaringan lambat yang tidak beradaptasi dengan client hints:
Sekarang, waterfall untuk situs yang sama pada koneksi lambat yang sama, kecuali kali ini, situs menggunakan client hints untuk menghilangkan resource halaman yang tidak penting:
Petunjuk klien mengurangi waktu muat halaman dari lebih dari 45 detik menjadi kurang dari sepersepuluh waktu tersebut. Manfaat client hints dalam skenario ini tidak cukup ditekankan dan dapat menjadi keuntungan serius bagi pengguna yang mencari informasi penting di jaringan yang lambat.
Selain itu, Anda dapat menggunakan client hints tanpa mengganggu pengalaman
untuk browser yang tidak mendukungnya. Misalnya, jika kita ingin menyesuaikan pengiriman resource yang meminta nilai petunjuk ECT sambil tetap memberikan pengalaman 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 yang dijelaskan
header ECT. Jika kami menginisialisasi $ect ke "4g", browser yang tidak mendukung petunjuk
klien tidak akan terpengaruh. Ikut serta dalam FTW!
Pikirkan cache-nya!
Setiap kali mengubah respons berdasarkan header HTTP, Anda harus mengetahui cara cache menangani pengambilan selanjutnya untuk resource tersebut. Header
Vary
sangat diperlukan di sini, karena kunci meng-cache entri ke nilai header permintaan
yang diberikan. Sederhananya, jika Anda mengubah respons apa pun berdasarkan header permintaan HTTP yang diberikan, hampir selalu Anda harus menyertakan permintaan header tersebut di Vary seperti berikut:
Vary: DPR, Width
Namun, ada peringatan besar terkait hal ini: Anda sebaiknya tidak perlu melakukan Vary respons
yang dapat di-cache pada header yang sering berubah (seperti Cookie) karena
resource tersebut secara efektif tidak dapat disimpan dalam cache. Dengan mengetahui hal ini, sebaiknya hindari
Vary pada header petunjuk klien seperti RTT atau Downlink, karena hal tersebut
adalah faktor koneksi yang dapat sering berubah. Jika Anda ingin mengubah respons pada header tersebut, pertimbangkan untuk hanya memasukkan header ECT saja, yang akan meminimalkan cache yang tidak ditemukan.
Tentu saja, hal ini hanya berlaku jika Anda meng-cache respons sejak awal.
Misalnya, Anda tidak akan menyimpan aset HTML dalam cache jika kontennya dinamis, karena hal tersebut dapat merusak pengalaman pengguna pada kunjungan berulang. Dalam kasus seperti ini, Anda dapat
mengubah respons tersebut atas dasar apa pun yang Anda rasa perlu dan tidak
mengkhawatirkan diri Anda dengan Vary.
Client hints dalam pekerja layanan
Negosiasi konten bukan lagi hanya untuk server. Karena pekerja layanan bertindak sebagai proxy antara klien dan server, Anda memiliki kontrol atas cara pengiriman resource melalui JavaScript. Ini termasuk client hints. Dalam peristiwa fetch pekerja layanan, Anda dapat menggunakan metode request.headers.get objek event 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 untuk mendapatkan beberapa informasi ini. Petunjuk khusus jaringan
dapat dibaca di properti JavaScript yang setara ini di objek navigator:
| Petunjuk klien | Padanan 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
operator
in:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Dari sini, Anda dapat menggunakan logika yang mirip dengan yang akan Anda gunakan di server, hanya saja Anda tidak memerlukan server untuk menegosiasikan konten dengan petunjuk klien. Pekerja layanan sendiri memiliki kemampuan untuk membuat pengalaman lebih cepat dan lebih tangguh karena memiliki kemampuan tambahan yang mereka miliki untuk menyajikan konten saat pengguna offline.
Menyelesaikan
Dengan client hints, kami dapat membuat pengalaman lebih cepat bagi pengguna dengan
cara yang sepenuhnya progresif. Kami dapat menayangkan media berdasarkan kemampuan perangkat
pengguna dengan cara yang mempermudah penayangan gambar responsif daripada mengandalkan
<picture> dan srcset, terutama untuk kasus penggunaan yang kompleks. Hal ini memungkinkan kami
tidak hanya mengurangi waktu dan upaya di sisi pengembangan, tetapi juga mengoptimalkan
resource—terutama gambar—dengan cara yang menargetkan layar pengguna
dengan lebih baik daripada yang dilakukan
Mungkin yang lebih penting, kita bisa mendeteksi koneksi jaringan yang buruk dan menjembatani kesenjangan bagi pengguna dengan mengubah apa yang kita kirim dan cara kita mengirimkannya. Cara ini bisa sangat membuat situs lebih mudah diakses bagi pengguna di jaringan yang rentan. Jika digabungkan dengan pekerja layanan, kita dapat membuat situs yang sangat cepat yang tersedia secara offline.
Meskipun client hints hanya tersedia di Chrome—dan browser berbasis Chromium—Anda dapat menggunakannya sedemikian rupa sehingga tidak membebani browser yang tidak mendukungnya. Pertimbangkan penggunaan client hints untuk menciptakan pengalaman yang benar-benar inklusif dan mudah disesuaikan yang mengetahui kemampuan setiap perangkat pengguna, serta jaringan yang terhubung dengannya. Semoga, vendor browser lain akan melihat nilainya dan menunjukkan niat untuk menerapkannya.
Referensi
- Gambar Responsif Otomatis dengan Petunjuk Klien
- Petunjuk Klien dan Gambar Responsif—Yang Berubah di Chrome 67
- Dapatkan Petunjuk (Klien). (Slide)
- Memberikan 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 pengeditan yang berharga atas artikel ini.