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:
- 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
Width
dan petunjukDPR
, lalu memilih sumber yang cocok dengan ukuran tata letak dan kepadatan layar gambar (mirip cara kerja deskripsix
danw
disrcset
). - 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
:
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
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.