Mengembangkan situs yang cepat di mana saja bisa menjadi hal yang sulit. Banyaknya kemampuan perangkat—dan kualitas jaringan yang terhubung dengannya—dapat membuat hal ini tampak seperti tugas yang tidak dapat diatasi. 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 keikutsertaan yang memberi kita insight tentang 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 kita menciptakan pengalaman pengguna yang lebih inklusif.
Semuanya tentang negosiasi konten
Petunjuk klien adalah metode negosiasi konten lainnya, 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
pengguna individu, seperti memutuskan apakah resource yang tidak penting harus disajikan 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
mudah diakses oleh pengguna.
Ikut serta
Tidak seperti header Accept, petunjuk klien tidak muncul begitu saja (kecuali
Save-Data, yang akan kita bahas nanti). Untuk menjaga
header permintaan tetap minimum, Anda harus memilih petunjuk klien yang ingin
Anda terima dengan mengirimkan header Accept-CH saat pengguna meminta
resource:
Accept-CH: Viewport-Width, Downlink
Nilai untuk Accept-CH adalah daftar petunjuk yang diminta dan dipisahkan koma yang akan digunakan situs dalam menentukan hasil untuk permintaan resource berikutnya. Saat
klien membaca header ini, klien akan 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 menetapkan 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.
Petunjuk klien 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 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 harus berfokus pada media.
Sebelum kita 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 intrinsiknya.
Ukuran intrinsik yang dikoreksi kepadatan: dimensi resource media setelah dikoreksi untuk kepadatan piksel. Ukuran 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."
/>
Misalnya, 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 dari
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 kepadatan sebesar 320x240, tetapi juga memiliki properti width dan height CSS
dengan nilai 256px dan 192px yang diterapkan ke elemen tersebut. 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 bahas daftar petunjuk klien khusus perangkat yang tersedia untuk Anda.
Viewport-Width
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 diaktifkan oleh tag <img> atau
<source> menggunakan atribut
sizes.
sizes memberi tahu browser 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 selebar 320 piksel CSS
dengan DPR 2. Perangkat memuat dokumen dengan elemen <img> yang berisi
nilai atribut sizes dari 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 untuk src <img>:
Width: 544
Dalam hal ini, klien memberi petunjuk kepada 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 efektif karena tidak hanya mempertimbangkan lebar layar yang dikoreksi kepadatan, tetapi juga menyesuaikan 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. Namun, 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 bukanlah header permintaan yang akan digunakan oleh
server, melainkan header respons 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.
Device-Memory
Secara teknis, 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 memerlukan banyak resource yang biasanya dimuat browser. Atau, Anda dapat mengirim gambar dengan DPR yang lebih rendah karena gambar tersebut menggunakan lebih sedikit memori untuk didekode.
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 Service Worker, kita memiliki kemampuan untuk menyesuaikan pengalaman bagi pengguna dengan mengubah cara kita mengirimkan resource ke klien pada koneksi yang lambat.
RTT
Petunjuk RTT memberikan perkiraan Waktu Perjalanan Pulang Pergi, dalam milidetik, pada
lapisan aplikasi. Petunjuk RTT, tidak seperti RTT lapisan transpor, 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 pengiriman 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), menunjukkan
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 dihitung, 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, API ini menganalisis latensi dan bandwidth koneksi saat ini dan
menentukan profil jaringan yang paling mirip. Misalnya, jika Anda terhubung
melalui Wi-Fi ke jaringan yang lambat, ECT mungkin 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
disempurnakan menggunakan petunjuk RTT dan Downlink.
Save-Data
Save-Data bukanlah petunjuk yang menjelaskan kondisi jaringan, melainkan preferensi pengguna yang menyatakan bahwa halaman harus mengirim lebih sedikit data.
Kami lebih suka mengklasifikasikan Save-Data sebagai petunjuk jaringan karena banyak hal yang akan Anda lakukan dengannya mirip dengan petunjuk jaringan lainnya. Pengguna juga mungkin
mengaktifkannya di lingkungan dengan latensi tinggi/bandwidth rendah. Petunjuk ini, jika ada, selalu terlihat seperti ini:
Save-Data: on
Di Google, kami telah membahas hal yang dapat Anda lakukan dengan
Save-Data.
Dampaknya terhadap performa bisa sangat besar. Ini adalah sinyal bahwa pengguna
benar-benar meminta Anda untuk mengirimkan lebih sedikit email kepada mereka. Jika Anda mendengarkan dan menindaklanjuti
sinyal tersebut, pengguna akan menghargainya.
Memadukan semuanya
Tindakan 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, perusahaan kayu fiktif yang berlokasi di pedesaan Upper Midwest. Seperti yang sering terjadi di area terpencil, koneksi jaringan bisa jadi tidak stabil. Di sinilah teknologi seperti petunjuk klien dapat benar-benar memberikan perbedaan bagi pengguna.
Gambar yang 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 menjadi sangat rumit dengan sangat cepat.
Sangat mudah untuk melakukan kesalahan, dan mudah untuk melupakan atau salah memahami konsep penting (seperti sizes).
Meskipun <picture> dan srcset tidak dapat disangkal merupakan alat yang luar biasa, alat ini dapat
memakan waktu untuk dikembangkan dan dikelola untuk kasus penggunaan yang kompleks. Kita dapat mengotomatiskan
pembuatan markup, tetapi hal ini juga sulit karena fungsi yang disediakan
<picture> dan srcset cukup kompleks sehingga otomatisasinya perlu
dilakukan dengan cara yang mempertahankan fleksibilitas yang disediakan.
Petunjuk klien dapat menyederhanakan hal ini. Negosiasi respons gambar dengan petunjuk klien mungkin terlihat seperti ini:
- Jika berlaku untuk alur kerja Anda, pilih perlakuan gambar terlebih dahulu (yaitu,
gambar yang diarahkan seni) dengan memeriksa petunjuk
Viewport-Width. - Pilih resolusi gambar dengan memeriksa petunjuk
Widthdan petunjukDPR, lalu pilih sumber yang sesuai dengan ukuran tata letak gambar dan kepadatan layar (mirip dengan cara kerja deskriptorxdanwdisrcset). - Pilih format file paling optimal yang didukung browser (sesuatu yang dapat dibantu oleh
Acceptdi sebagian besar browser).
Untuk klien perusahaan kayu fiktif saya, saya mengembangkan rutinitas pemilihan gambar responsif yang sederhana di PHP yang menggunakan petunjuk klien. Artinya, daripada 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 merasa “Tapi bukankah ini hanya menerapkan kembali <picture> dan srcset di
back-end?” adalah pertanyaan pertama Anda.
Bisa dibilang, ya—tetapi dengan perbedaan penting: saat aplikasi menggunakan petunjuk klien untuk membuat respons media, sebagian besar (jika tidak semua) pekerjaan jauh lebih mudah untuk diotomatiskan, yang dapat mencakup layanan (seperti CDN) yang dapat melakukannya atas nama Anda. Sedangkan dengan solusi HTML, markup baru perlu 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 di masa mendatang.
Petunjuk klien memungkinkan Anda memulai dengan gambar lossless beresolusi tinggi
yang kemudian dapat diubah ukurannya secara dinamis agar optimal untuk setiap kombinasi
layar dan tata letak. Tidak seperti srcset, yang mengharuskan Anda menghitung daftar tetap
kemungkinan kandidat gambar yang dapat dipilih browser, pendekatan ini
bisa lebih fleksibel. Meskipun srcset memaksa Anda menawarkan kumpulan varian yang kasar ke browser—misalnya, 256w, 512w, 768w, dan 1024w—solusi yang didukung petunjuk klien dapat menyajikan semua lebar, tanpa tumpukan markup yang besar.
Tentu saja, Anda tidak perlu menulis sendiri logika pemilihan gambar. Cloudinary
menggunakan petunjuk klien untuk membuat respons gambar saat Anda menggunakan parameter w_auto,
dan mengamati bahwa median pengguna 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 petunjuk klien lintas origin. Untungnya, batasan ini tidak memengaruhi Chrome versi seluler, dan batasan tersebut akan dicabut sepenuhnya untuk semua platform setelah pengerjaan Kebijakan Fitur selesai.
Membantu pengguna di jaringan yang lambat
Performa adaptif adalah gagasan bahwa kita dapat menyesuaikan cara kita mengirimkan resource berdasarkan informasi yang disediakan petunjuk klien; khususnya informasi seputar status koneksi jaringan pengguna saat ini.
Terkait situs Sconnie Timber, kami mengambil langkah-langkah untuk meringankan 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 demi pengalaman pengguna yang lebih baik. Skor jaringan ini berada di antara 0 dan 1, dengan 0 adalah kualitas jaringan
terburuk, dan 1 adalah yang terbaik.
Pertama-tama, kami akan memeriksa apakah Save-Data ada. Jika ya, skor akan ditetapkan ke
0, karena kami berasumsi bahwa pengguna ingin kami melakukan apa pun yang diperlukan untuk membuat
pengalaman lebih ringan dan lebih cepat.
Namun, jika Save-Data tidak ada, kita akan 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. Kesimpulannya, jika kita menggunakan petunjuk terkait jaringan dengan
beberapa cara, kita dapat meningkatkan pengalaman bagi pengguna yang menggunakan jaringan
lambat.
Saat situs beradaptasi dengan informasi yang diberikan petunjuk klien, kita tidak perlu menerapkan pendekatan “semua atau tidak sama sekali”. Kita 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 meningkatkan performa situs di jaringan yang lebih lambat. Berikut 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, tetapi kali ini, situs menggunakan petunjuk klien untuk menghilangkan resource halaman yang tidak penting:
Petunjuk klien mengurangi waktu pemuatan halaman dari lebih dari 45 detik menjadi kurang dari sepersepuluh waktu tersebut. Manfaat petunjuk klien dalam skenario ini sangatlah besar dan dapat menjadi keuntungan serius bagi pengguna yang mencari informasi penting melalui jaringan yang lambat.
Selain itu, Anda dapat menggunakan petunjuk klien tanpa mengganggu pengalaman
untuk 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 ini:
// 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 apa pun berdasarkan header permintaan HTTP tertentu, Anda hampir selalu harus menyertakan permintaan header 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 resource tersebut
menjadi tidak dapat di-cache secara efektif. Dengan mengetahui hal ini, Anda mungkin ingin menghindari
Vary pada header petunjuk klien seperti RTT atau Downlink, karena keduanya adalah
faktor koneksi yang dapat sering berubah. Jika Anda ingin mengubah respons pada header tersebut, pertimbangkan untuk hanya memasukkan header ECT, yang akan meminimalkan cache tidak ditemukan.
Tentu saja, hal ini hanya berlaku jika Anda meng-cache respons sejak awal.
Misalnya, Anda tidak akan meng-cache aset HTML jika kontennya dinamis, karena
hal itu dapat mengganggu pengalaman pengguna saat kunjungan berulang. Dalam kasus seperti ini, silakan
ubah respons tersebut berdasarkan apa pun yang Anda rasa perlu dan jangan
khawatirkan Vary.
Petunjuk klien di pekerja layanan
Negosiasi konten tidak lagi hanya untuk server. 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 ini:
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 dalam objek navigator:
| Petunjuk klien | Setara dengan 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 menegosiasikan konten dengan petunjuk klien. Service worker saja memiliki kemampuan untuk membuat pengalaman lebih cepat dan lebih tangguh karena kemampuan tambahan yang dimilikinya untuk menyajikan konten saat pengguna offline.
Menyelesaikan
Dengan petunjuk klien, kami memiliki kemampuan untuk membuat pengalaman lebih cepat bagi pengguna dengan
cara yang sepenuhnya progresif. Kita dapat menyajikan media berdasarkan kemampuan perangkat pengguna
dengan cara yang memudahkan penyajian 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 dapat dilakukan
Mungkin yang lebih penting, kita dapat mendeteksi koneksi jaringan yang buruk dan menjembatani kesenjangan bagi pengguna dengan mengubah apa yang kita kirim—dan cara kita mengirimnya. Hal ini dapat sangat membantu dalam membuat situs lebih mudah diakses oleh pengguna di jaringan yang tidak stabil. 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—petunjuk tersebut dapat digunakan dengan cara yang tidak membebani browser yang tidak mendukungnya. Pertimbangkan untuk menggunakan petunjuk klien guna menciptakan pengalaman yang benar-benar inklusif dan mudah beradaptasi yang mengetahui kemampuan perangkat setiap pengguna, dan jaringan yang mereka hubungkan. Semoga vendor browser lain akan melihat nilai dari fitur tersebut dan menunjukkan niat untuk menerapkannya.
Resource
- Automatic Responsive Images with Client Hints
- Petunjuk Klien dan Gambar Responsif—Yang Berubah di Chrome 67
- Memanfaatkan 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 pengeditan yang berharga pada artikel ini.