Mengembangkan situs yang cepat di mana pun bisa menjadi prospek yang sulit. Banyaknya kemampuan perangkat—dan kualitas jaringan yang terhubung ke perangkat tersebut—dapat membuat tugas ini tampak mustahil. Meskipun kita dapat memanfaatkan fitur browser untuk meningkatkan performa pemuatan, bagaimana kita mengetahui kemampuan perangkat pengguna atau kualitas koneksi jaringannya? Solusinya adalah petunjuk klien.
Petunjuk klien adalah serangkaian header permintaan HTTP yang bersifat keikutsertaan yang memberi kami insight tentang aspek-aspek perangkat pengguna dan jaringan yang terhubung dengannya. Dengan memanfaatkan informasi ini di sisi server, kita dapat mengubah cara kita mengirimkan konten berdasarkan kondisi perangkat dan/atau jaringan. Hal ini dapat membantu kami menciptakan pengalaman pengguna yang lebih inklusif.
Semua Tentang Negosiasi Konten
Petunjuk klien adalah metode lain untuk negosiasi konten, yang berarti mengubah respons konten berdasarkan header permintaan browser.
Salah satu contoh negosiasi konten melibatkan header permintaan
Accept. Header 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 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, petunjuk klien adalah cara lain untuk menegosiasikan konten, tetapi dalam konteks kemampuan perangkat dan kondisi jaringan. Dengan petunjuk klien, kita
dapat membuat keputusan performa sisi server berdasarkan pengalaman
individu pengguna, seperti memutuskan apakah resource non-kritis harus ditayangkan kepada
pengguna dengan kondisi jaringan yang buruk. Dalam panduan ini, kami akan menjelaskan semua petunjuk yang tersedia dan beberapa cara Anda dapat menggunakannya untuk membuat penayangan konten lebih mengakomodasi pengguna.
Ikut serta
Tidak seperti header Accept, petunjuk klien tidak muncul begitu saja (kecuali Save-Data, yang akan kita bahas nanti). Untuk menjaga agar header permintaan tetap minimum, Anda harus memilih untuk menerima petunjuk klien yang diinginkan dengan mengirim header Accept-CH saat pengguna meminta resource:
Accept-CH: Viewport-Width, Downlink
Nilai untuk Accept-CH adalah daftar petunjuk yang dipisahkan koma yang akan digunakan situs dalam menentukan hasil untuk permintaan resource berikutnya. Saat membaca header ini, klien diberi tahu bahwa “situs ini menginginkan petunjuk klien Viewport-Width dan Downlink”. Jangan khawatir tentang petunjuk spesifiknya.
Kita akan membahasnya sebentar lagi.
Anda dapat menyetel header keikutsertaan ini dalam bahasa backend apa pun. Misalnya, fungsi header PHP dapat digunakan.
Anda bahkan dapat menyetel header keikutsertaan ini dengan atribut http-equiv
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 Anda, dan jaringan yang mereka gunakan untuk mengakses situs Anda. Mari kita bahas secara singkat semua petunjuk yang tersedia.
Petunjuk perangkat
Beberapa petunjuk klien menjelaskan karakteristik perangkat pengguna, biasanya karakteristik layar. Beberapa di antaranya dapat membantu Anda memilih resource media yang optimal untuk layar pengguna tertentu, tetapi tidak semuanya berpusat pada media.
Sebelum membahas daftar ini, sebaiknya pelajari beberapa istilah penting yang digunakan untuk mendeskripsikan layar dan resolusi media:
Ukuran intrinsik: dimensi sebenarnya dari resource media. Misalnya, jika Anda membuka gambar di Photoshop, dimensi yang ditampilkan dalam dialog ukuran gambar menjelaskan ukuran intrinsik gambar tersebut.
Ukuran intrinsik yang dikoreksi kepadatan: dimensi resource media setelah dikoreksi untuk kepadatan piksel. Ini adalah ukuran intrinsik gambar dibagi dengan rasio piksel perangkat. 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."
/>
Misalkan ukuran intrinsik gambar 1x dalam kasus 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), gambar 2x akan diminta. Ukuran intrinsik yang dikoreksi kepadatan gambar 2x adalah 320x240, karena 640x480 dibagi 2 adalah 320x240.
Ukuran ekstrinsik: ukuran aset media setelah CSS dan faktor tata letak lainnya (seperti atribut width dan height) diterapkan padanya. Misalkan Anda memiliki elemen <img> yang memuat gambar dengan ukuran intrinsik yang dikoreksi kepadatan 320x240, tetapi juga memiliki properti CSS width dan height dengan nilai 256px dan 192px yang diterapkan padanya. Dalam contoh ini,
ukuran ekstrinsik elemen <img> tersebut menjadi 256x192.
width: 256px;
dan height: 192px; mengubah gambar berukuran intrinsik 320x240
menjadi gambar berukuran ekstrinsik 256x192.Setelah memahami beberapa terminologi, mari kita bahas daftar petunjuk klien khusus perangkat yang tersedia untuk Anda.
Lebar Area Tampilan
Viewport-Width adalah lebar area pandang pengguna dalam piksel CSS:
Viewport-Width: 320
Petunjuk ini dapat digunakan dengan petunjuk khusus layar lainnya untuk memberikan perlakuan yang berbeda (yaitu, pemangkasan) pada gambar yang optimal untuk ukuran layar tertentu (yaitu, arah seni), atau untuk menghilangkan resource yang tidak diperlukan untuk lebar layar saat ini.
DPR
DPR, 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 deskriptor x dalam atribut srcset).
Lebar
Petunjuk Width muncul pada permintaan untuk resource gambar yang dipicu 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 320 piksel CSS dengan DPR 2. Perangkat memuat dokumen dengan elemen <img> yang berisi
nilai atribut sizes 85vw (yaitu, 85% lebar area pandang untuk semua ukuran layar). Jika petunjuk Width telah diaktifkan, klien akan mengirimkan petunjuk Width ini ke server dengan permintaan src <img>:
Width: 544
Dalam hal ini, klien memberi petunjuk kepada server bahwa lebar intrinsik optimal untuk gambar yang diminta adalah 85% dari lebar viewport (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 menyelaraskan 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.
Content-DPR
Meskipun Anda sudah tahu 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 dapat sama. Tapi! Jika header
DPR dan Width digunakan, ukuran ekstrinsik resource dapat
menghasilkan skenario yang membuat keduanya berbeda. Di sinilah petunjuk Content-DPR
berperan.
Tidak seperti petunjuk klien lainnya, Content-DPR bukan header request yang akan digunakan oleh
server, melainkan header response yang harus dikirim server setiap kali petunjuk DPR dan
Width digunakan untuk memilih resource. Nilai Content-DPR harus
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. Tanpa itu, gambar mungkin tidak diskalakan dengan benar.
Memori Perangkat
Secara teknis merupakan bagian dari Device Memory API, Device-Memory mengungkapkan perkiraan jumlah memori yang dimiliki perangkat saat ini dalam GiB:
Device-Memory: 2
Kemungkinan kasus penggunaan untuk petunjuk ini adalah mengurangi jumlah JavaScript yang dikirim ke browser di perangkat dengan memori terbatas, karena JavaScript adalah jenis konten yang paling banyak menggunakan resource yang biasanya dimuat browser. Atau, Anda dapat mengirim gambar DPR yang lebih rendah karena menggunakan lebih sedikit memori untuk mendekode.
Petunjuk jaringan
Network Information API menyediakan kategori petunjuk klien lain yang menjelaskan performa koneksi jaringan pengguna. Menurut saya, ini adalah kumpulan petunjuk yang paling berguna. Dengan demikian, kita dapat menyesuaikan pengalaman pengguna dengan mengubah cara kita mengirimkan resource ke klien pada koneksi yang lambat.
RTT
Petunjuk RTT memberikan perkiraan Round Trip Time, dalam milidetik, di
lapisan aplikasi. Petunjuk RTT, tidak seperti RTT lapisan transport, mencakup waktu pemrosesan server.
RTT: 125
Petunjuk ini berguna karena peran latensi dalam performa pemuatan.
Dengan menggunakan petunjuk RTT, kita dapat membuat keputusan berdasarkan responsivitas jaringan,
yang dapat membantu mempercepat penyampaian 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
perkiraan kecepatan downstream 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 dari
daftar jenis koneksi yang di-enum, yang masing-masing menjelaskan koneksi
dalam rentang nilai RTT dan Downlink yang ditentukan.
Header ini tidak menjelaskan jenis koneksi sebenarnya—misalnya, header ini tidak melaporkan apakah gateway Anda adalah menara BTS atau titik akses Wi-Fi. Sebaliknya, fitur ini 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 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 selanjutnya
diperbaiki menggunakan petunjuk RTT dan Downlink.
Save-Data
Save-Data bukan sekadar petunjuk yang menjelaskan kondisi jaringan, melainkan preferensi pengguna yang menyatakan bahwa halaman harus mengirim lebih sedikit data.
Saya lebih suka mengklasifikasikan Save-Data sebagai petunjuk jaringan karena banyak hal yang dapat Anda lakukan dengan Save-Data serupa dengan petunjuk jaringan lainnya. Pengguna juga cenderung mengaktifkannya di lingkungan dengan latensi tinggi/bandwidth rendah. Petunjuk ini, jika ada, akan selalu terlihat seperti ini:
Save-Data: on
Di Google, kami telah membahas apa yang dapat Anda lakukan dengan
Save-Data.
Dampak yang dapat ditimbulkannya pada performa bisa sangat besar. Ini adalah sinyal saat pengguna benar-benar meminta Anda untuk mengirimkan lebih sedikit konten kepada mereka. Jika Anda mendengarkan dan menindaklanjuti sinyal tersebut, pengguna akan menghargainya.
Memadukan semuanya
Apa yang Anda lakukan dengan petunjuk klien bergantung pada Anda. Karena menawarkan begitu banyak informasi, Anda memiliki banyak opsi. Untuk mendapatkan beberapa ide, mari kita lihat apa yang dapat dilakukan petunjuk klien untuk Sconnie Timber, sebuah perusahaan kayu fiktif yang berlokasi di Upper Midwest pedesaan. Seperti yang sering terjadi di area terpencil, koneksi jaringan bisa tidak stabil. Di sinilah teknologi seperti petunjuk klien dapat membuat perbedaan nyata 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 akan sangat rumit sangat
cepat.
Konsep ini mudah salah, dan mudah dilupakan atau disalahpahami (seperti sizes).
Meskipun <picture> dan srcset adalah alat yang luar biasa, keduanya dapat memakan waktu untuk dikembangkan dan dipelihara untuk kasus penggunaan yang kompleks. Kita dapat mengotomatiskan pembuatan markup, tetapi melakukannya juga sulit karena fungsi yang disediakan oleh <picture> dan srcset cukup kompleks sehingga otomatisasinya perlu dilakukan dengan cara yang mempertahankan fleksibilitas yang mereka berikan.
Petunjuk klien dapat menyederhanakan hal ini. Negosiasi respons gambar dengan petunjuk klien dapat terlihat seperti ini:
- Jika berlaku untuk alur kerja Anda, pilih terlebih dahulu perlakuan gambar (yaitu, gambar yang diarahkan secara artistik) dengan mencentang petunjuk
Viewport-Width. - Pilih resolusi gambar dengan memeriksa petunjuk
Widthdan petunjukDPR, lalu memilih sumber yang sesuai dengan ukuran tata letak dan kepadatan layar gambar (mirip dengan cara kerja deskriptorxdanwdisrcset). - Pilih format file yang paling optimal yang didukung browser (sesuatu yang
Acceptmembantu kami melakukannya di sebagian besar browser).
Untuk klien perusahaan kayu fiktif saya, saya mengembangkan rutin pemilihan gambar responsif yang sederhana di PHP yang menggunakan petunjuk klien. Artinya, alih-alih 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 browser individual:
<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. Fungsi ini
mengambil nama file gambar dan parameter tambahan untuk membantu skrip backend
memilih gambar terbaik dalam kondisi tertentu.
Saya menduga “Tapi bukankah ini hanya mengimplementasikan ulang <picture> dan srcset di backend?” adalah pertanyaan pertama Anda.
Ya, tetapi dengan perbedaan 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 melakukan hal ini atas nama Anda. Sedangkan dengan solusi HTML, markup baru harus ditulis untuk menyediakan setiap kasus penggunaan. Tentu, Anda dapat mengotomatiskan pembuatan markup. Namun, jika desain atau persyaratan Anda berubah, kemungkinan besar Anda perlu meninjau kembali strategi otomatisasi Anda di masa mendatang.
Petunjuk klien memungkinkan untuk memulai dengan gambar beresolusi tinggi tanpa kehilangan kualitas yang kemudian dapat diubah ukurannya secara dinamis agar optimal untuk kombinasi layar dan tata letak. Tidak seperti srcset, yang mengharuskan Anda mencantumkan daftar tetap kemungkinan kandidat gambar untuk dipilih oleh browser, pendekatan ini bisa lebih fleksibel. Meskipun srcset memaksa Anda menawarkan serangkaian varian kasar kepada browser—misalnya, 256w, 512w, 768w, dan 1024w—solusi yang didukung petunjuk klien
dapat menayangkan 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.
Namun, berhati-hatilah. Perubahan pada Chrome 67 versi desktop telah menghapus dukungan untuk hint klien lintas origin. Untungnya, batasan ini tidak memengaruhi Chrome versi seluler, dan batasan ini akan dicabut sepenuhnya untuk semua platform setelah pekerjaan terkait Feature Policy selesai.
Membantu pengguna di jaringan yang lambat
Performa adaptif adalah gagasan bahwa kita dapat menyesuaikan cara kita mengirimkan resource berdasarkan informasi yang tersedia melalui petunjuk klien; khususnya informasi seputar status koneksi jaringan pengguna saat ini.
Untuk situs Sconnie Timber, kami mengambil langkah-langkah untuk mengurangi beban saat
jaringan lambat, dengan header Save-Data, ECT, RTT, dan Downlink yang
diperiksa dalam kode backend kami. Setelah selesai, kami akan membuat skor kualitas jaringan yang dapat kami gunakan untuk menentukan apakah kami harus melakukan intervensi untuk memberikan pengalaman pengguna yang lebih baik. Skor jaringan ini berada di antara 0 dan 1, dengan 0 adalah kualitas jaringan terburuk dan 1 adalah kualitas jaringan terbaik.
Pertama-tama, kita akan memeriksa apakah Save-Data ada. Jika ya, skor akan ditetapkan ke
0, karena kita mengasumsikan bahwa pengguna ingin kita melakukan apa pun yang diperlukan untuk membuat
pengalaman menjadi lebih ringan dan cepat.
Namun, jika Save-Data tidak ada, kami akan melanjutkan dan menimbang nilai petunjuk ECT,
RTT, dan Downlink untuk menghitung skor yang menjelaskan kualitas koneksi jaringan. Kode sumber pembuatan skor jaringan
tersedia di GitHub. Kesimpulannya, jika kita menggunakan petunjuk terkait jaringan dengan cara
tertentu, kita dapat meningkatkan kualitas pengalaman bagi pengguna yang menggunakan jaringan
lambat.
Saat situs menyesuaikan diri dengan informasi yang diberikan petunjuk klien, kita tidak perlu menerapkan pendekatan “semua atau tidak sama sekali”. Kami dapat memutuskan secara cerdas resource mana yang akan dikirim. Kita dapat mengubah logika pemilihan gambar responsif untuk mengirim gambar berkualitas lebih rendah untuk tampilan tertentu guna mempercepat performa pemuatan saat kualitas jaringan buruk.
Dalam contoh ini, kita dapat melihat dampak petunjuk klien dalam hal meningkatkan performa situs di jaringan yang lebih lambat. Di bawah ini adalah waterfall WebPagetest dari situs di jaringan lambat yang tidak beradaptasi dengan petunjuk klien:
Sekarang, waterfall untuk situs yang sama pada koneksi lambat yang sama, kecuali kali ini, situs menggunakan petunjuk klien 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 petunjuk klien dalam skenario ini tidak dapat ditekankan secara cukup dan dapat menjadi keuntungan serius bagi pengguna yang mencari informasi penting melalui jaringan yang lambat.
Selain itu, Anda dapat menggunakan petunjuk klien tanpa merusak pengalaman browser yang tidak mendukungnya. Misalnya, jika kita ingin menyesuaikan pengiriman resource menggunakan nilai petunjuk ECT sambil tetap memberikan pengalaman penuh untuk browser yang tidak mendukung, kita dapat menetapkan penggantian ke nilai default seperti berikut:
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
Di sini, "4g" mewakili koneksi jaringan berkualitas tertinggi yang dijelaskan oleh header ECT. Jika kita menginisialisasi $ect ke "4g", browser yang tidak mendukung petunjuk klien tidak akan terpengaruh. Ikut serta FTW!
Perhatikan cache tersebut.
Setiap kali Anda mengubah respons berdasarkan header HTTP, Anda harus mengetahui cara cache akan menangani pengambilan resource tersebut di masa mendatang. Header Vary sangat diperlukan di sini, karena header ini mengaitkan entri cache ke nilai header permintaan yang diberikan kepadanya. Sederhananya, jika Anda mengubah respons berdasarkan header permintaan HTTP tertentu, Anda hampir selalu harus menyertakan header permintaan tersebut di Vary seperti ini:
Vary: DPR, Width
Namun, ada peringatan besar untuk hal ini: Anda tidak boleh Vary respons
yang dapat di-cache pada header yang sering berubah (seperti Cookie) karena
sumber daya tersebut menjadi tidak dapat di-cache secara efektif. Dengan mengetahui hal ini, sebaiknya hindari
Varybergantung pada header petunjuk klien seperti RTT atau Downlink, karena header tersebut merupakan
faktor koneksi yang dapat berubah cukup sering. Jika Anda ingin mengubah
respons pada header tersebut, pertimbangkan untuk hanya memasukkan header ECT, yang akan
meminimalkan cache miss.
Tentu saja, hal ini hanya berlaku jika Anda menyimpan respons ke dalam cache.
Misalnya, Anda tidak akan menyimpan aset HTML dalam cache jika kontennya dinamis, karena
hal itu dapat merusak pengalaman pengguna pada kunjungan berulang. Dalam kasus seperti ini, jangan ragu untuk mengubah respons tersebut berdasarkan apa pun yang Anda rasa perlu dan tidak perlu mengkhawatirkan Vary.
Petunjuk klien di pekerja layanan
Negosiasi konten tidak hanya untuk server lagi. Karena pekerja layanan bertindak
sebagai proxy antara klien dan server, Anda memiliki kontrol atas cara resource
dikirimkan melalui JavaScript. Hal ini mencakup petunjuk klien. Dalam peristiwa fetch service worker, 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 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:
| Petunjuk klien | Setara JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Karena API ini tidak tersedia di semua tempat, 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, kecuali Anda tidak memerlukan server untuk melakukan negosiasi konten dengan petunjuk klien. Service worker saja memiliki kemampuan untuk membuat pengalaman lebih cepat dan lebih tangguh karena kemampuan tambahan yang mereka miliki untuk menayangkan konten saat pengguna offline.
Menyelesaikan
Dengan petunjuk klien, kita dapat membuat pengalaman yang lebih cepat bagi pengguna dengan cara yang sepenuhnya progresif. Kita dapat menayangkan media berdasarkan kemampuan perangkat pengguna dengan cara yang membuat penayangan gambar responsif lebih mudah 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
lebih baik daripada
Yang lebih penting, kita dapat mendeteksi koneksi jaringan yang buruk dan menjembatani kesenjangan bagi pengguna dengan mengubah apa yang kita kirim—dan cara kita mengirimkannya. Hal ini dapat sangat membantu pengguna di jaringan yang tidak stabil dalam mengakses situs dengan lebih mudah. Jika digabungkan dengan pekerja layanan, kita dapat membuat situs yang sangat cepat dan tersedia secara offline.
Meskipun petunjuk klien hanya tersedia di Chrome—dan browser berbasis Chromium—Anda dapat menggunakannya dengan cara yang tidak membebani browser yang tidak mendukungnya. Pertimbangkan untuk menggunakan petunjuk klien guna menciptakan pengalaman yang benar-benar inklusif dan mudah disesuaikan yang mengetahui kemampuan perangkat setiap pengguna dan jaringan yang terhubung. Semoga vendor browser lain akan melihat manfaatnya dan menunjukkan niat untuk menerapkannya.
Resource
- Gambar Responsif Otomatis dengan Petunjuk Klien
- Petunjuk Klien dan Gambar Responsif—Apa yang Berubah di Chrome 67
- Dapatkan Petunjuk (Klien)! (Slide)
- Menyediakan 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 berharga mereka terhadap artikel ini.