Pengguna yang memuat situs Anda untuk kedua kalinya akan menggunakan cache HTTP mereka, jadi pastikan ia akan bekerja dengan baik.
Postingan ini adalah pengiring untuk video Love your cache, bagian dari Diperluas Konten di Chrome Dev Summit 2020. Pastikan untuk menonton video:
Saat pengguna memuat situs Anda untuk kedua kalinya, {i>browser<i} mereka akan menggunakan sumber daya di dalam cache HTTP-nya untuk membantu mempercepat pemuatan. Tetapi standar untuk {i>caching<i} pada dimulai pada tahun 1999, dan istilah itu didefinisikan secara luas—menentukan baik file, seperti CSS atau gambar, mungkin diambil lagi dari jaringan dibandingkan dengan yang dimuat dari {i>cache<i} adalah sedikit pengetahuan yang tidak tepat.
Dalam posting ini, saya akan membahas {i>default<i} yang masuk akal dan modern untuk {i>caching<i}—yang tidak menyimpan cache sama sekali. Tapi itu hanya default, dan itu lebih bernuansa dari sekedar "menonaktifkan". Baca selengkapnya.
Sasaran
Saat situs dimuat untuk kedua kalinya, Anda memiliki dua sasaran:
- Pastikan pengguna mendapatkan versi terbaru yang tersedia, jika Anda telah mengubah sesuatu, hal itu harus segera terlihat
- Lakukan #1 saat mengambil sesedikit mungkin dari jaringan
Dalam arti luas, Anda hanya ingin mengirim perubahan terkecil ke klien Anda saat situs Anda dimuat lagi. Dan menyusun situs Anda untuk memastikan distribusi perubahan yang efisien itu sulit (tentang hal itu di bawah, dan di video).
Karena itu, Anda juga memiliki tombol lain saat mempertimbangkan {i>caching<i}—mungkin Anda memutuskan untuk membiarkan cache HTTP browser pengguna menyimpan situs Anda dalam waktu yang lama sehingga tidak ada permintaan jaringan yang diperlukan untuk melayaninya sama sekali. Atau Anda sudah membuat pekerja layanan yang akan melayani situs yang sepenuhnya offline sebelum memeriksa apakah sudah terkini. Ini adalah opsi ekstrem, yang valid—dan digunakan untuk banyak pengalaman web seperti aplikasi offline-first—tetapi web tidak harus pada cache yang ekstrem saja, atau bahkan ekstrem yang hanya terbatas pada jaringan.
Latar belakang
Sebagai developer web, kita semua terbiasa dengan gagasan memiliki "cache yang sudah tidak berlaku". Tapi kita tahu, hampir secara naluriah, alat yang tersedia untuk menyelesaikan hal ini: lakukan "uji coba" refresh", atau membuka jendela samaran, atau menggunakan beberapa kombinasi browser {i>developer tools<i} untuk menghapus data situs.
Pengguna biasa di internet tidak memiliki kemewahan yang sama. Jadi, meski kita memiliki beberapa tujuan inti untuk memastikan pengguna kami menikmati waktu sebaiknya pastikan juga bahwa mereka tidak mengalami waktu yang buruk atau mereka masih tertahan. (Lihat videonya jika Anda ingin mendengar saya membahas tentang bagaimana situs web.dev/live hampir bermasalah!)
Dengan sedikit latar belakang, alasan yang sangat umum untuk "cache sudah tidak berlaku" sebenarnya
{i>default<i} era 1999 untuk {i>caching<i}. Teknik ini bergantung pada header Last-Modified:
Setiap file yang Anda muat akan disimpan selama 10% tambahan masa pakainya saat ini,
browser Anda melihatnya. Misalnya, jika index.html dibuat sebulan yang lalu,
itu akan disimpan dalam cache oleh {i>browser<i} Anda
selama tiga hari ke depan.
Ide ini dulunya dimaksudkan dengan baik, tetapi mengingat pada situs web masa kini, perilaku {i>default<i} ini berarti memungkinkan untuk mendapatkan keadaan di mana pengguna memiliki file yang dirancang untuk rilis situs web Anda (mis., JS dari rilis hari Selasa, dan CSS dari rilis), semua karena file tersebut tidak diperbarui secara persis sama.
Jalur yang cukup terang
{i>Default<i} modern untuk {i>caching<i} adalah benar-benar tidak melakukan {i>caching<i} sama sekali, dan menggunakan CDN untuk menarik konten Anda untuk pengguna Anda. Setiap kali pengguna memuat situs Anda, mereka akan masuk ke jaringan untuk lihat apakah datanya sudah yang terbaru. Permintaan ini akan memiliki latensi rendah, karena yang disediakan oleh CDN secara geografis dekat dengan setiap pengguna akhir.
Anda dapat mengonfigurasi host web untuk merespons permintaan web dengan header ini:
Cache-Control: max-age=0,must-revalidate,public
Formula pada dasarnya menyatakan; file tersebut tidak berlaku sama sekali, dan Anda harus memvalidasi dari jaringan sebelum Anda dapat menggunakannya lagi (jika tidak, itu hanya "disarankan").
Proses validasi ini relatif murah dalam hal jumlah byte yang ditransfer—jika file gambar besar tidak berubah, browser Anda akan menerima 304 kecil — tetapi memerlukan latensi karena pengguna tetap harus masuk ke jaringan untuk posisi-posisi ini. Dan inilah kelemahan utama dari pendekatan ini. Dapat berfungsi dengan sangat baik untuk orang-orang yang memiliki koneksi cepat di dunia pertama, dan di mana CDN pilihan Anda memiliki cakupan yang bagus, tetapi tidak untuk orang-orang yang mungkin menggunakan seluler lebih lambat koneksi atau menggunakan infrastruktur yang buruk.
Bagaimanapun, ini adalah pendekatan modern yang adalah setelan default di CDN populer, Netlify, tetapi dapat dikonfigurasi di hampir semua CDN. Untuk Firebase Hosting, Anda dapat menyertakan {i>header<i} ini di bagian hosting file firebase.json Anda:
"headers": [
// Be sure to put this last, to not override other headers
{
"source": "**",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=0,must-revalidate,public"
}
}
]
Jadi, meskipun saya tetap menyarankan ini sebagai default yang masuk akal, hanya saja—default-nya. Baca terus untuk mengetahui cara memasuki dan mengupgrade versi default.
URL dengan sidik jari
Dengan menyertakan hash konten file dalam nama aset, gambar, dan sebagainya
disajikan di situs Anda, Anda dapat memastikan
bahwa file ini akan selalu memiliki
konten—ini akan menghasilkan file dengan nama sitecode.af12de.js, misalnya. Kapan
server Anda menanggapi permintaan untuk file ini, Anda dapat dengan aman memerintahkan
browser pengguna akhir untuk menyimpannya dalam cache
dalam waktu yang lama dengan mengkonfigurasinya
{i>header<i}:
Cache-Control: max-age=31536000,immutable
Nilai ini adalah tahun, dalam detik. Dan menurut spesifikasinya, cara ini sama dengan "selamanya".
Yang penting, jangan buat hash ini secara manual karena itu terlalu banyak pekerjaan manual. Anda dapat menggunakan alat seperti Webpack, Rollup, dan sebagainya untuk membantu Anda dengan hal ini. Pastikan untuk membaca selengkapnya di Laporan Alat.
Ingatlah bahwa bukan hanya JavaScript yang bisa mendapatkan manfaat dari URL yang dilacak sidik jari; aset seperti ikon, CSS, dan file data yang tidak dapat diubah lainnya juga dapat diberi nama ini sebelumnya. (Dan pastikan untuk menonton video di atas untuk mempelajari kode lebih lanjut pemisahan, yang memungkinkan Anda mengirimkan lebih sedikit kode setiap kali situs Anda berubah.)
Terlepas dari cara situs Anda melakukan pendekatan {i>caching<i}, proses pelacakan sidik jari semacam ini file sangat berharga untuk situs apa pun yang mungkin Anda bangun. Kebanyakan situs hanya tidak berubah di setiap rilis.
Tentu saja, kami tidak dapat mengganti nama laman yang 'ramah' pengguna dengan cara ini: mengganti nama
file index.html Anda ke index.abcd12.html—itu tidak mungkin, Anda tidak dapat membedakan
pengguna membuka URL baru setiap kali mereka memuat situs Anda! Grup 'ramah' ini URL
tidak dapat diganti namanya dan di-cache dengan cara ini, yang membawa saya ke kemungkinan
bawah tanah.
Jalan tengah
Tentu saja ada ruang tengah dalam hal penyimpanan data ke cache. Saya sudah disajikan dua opsi ekstrem; cache tidak pernah, atau cache selamanya. Dan akan ada sejumlah file yang mungkin ingin Anda simpan di {i>cache<i} untuk sementara waktu, seperti "ramah" URL yang saya sebutkan di atas.
Jika Anda ingin meng-cache "friendly" ini URL dan HTML-nya, sangat penting mempertimbangkan dependensi apa yang disertakan, cara dependensi tersebut dapat di-cache, dan bagaimana menyimpan URL ke dalam cache untuk sementara waktu, dapat memengaruhi Anda. Mari kita lihat pada laman HTML yang menyertakan gambar seperti ini:
<img src="/images/foo.jpeg" loading="lazy" />
Jika Anda memperbarui atau mengubah situs dengan menghapus atau mengubah pemuatan lambat ini
pengguna yang melihat versi HTML yang di-cache mungkin mendapatkan informasi
gambar yang hilang—karena mereka masih menyimpan cache /images/foo.jpeg yang asli saat
mereka mengunjungi kembali situs Anda.
Jika Anda berhati-hati, ini mungkin tidak akan memengaruhi Anda. Secara umum, penting untuk ingat bahwa situs Anda—ketika di-cache oleh pengguna akhir—tidak lagi ada di server Anda. Namun, parameter tersebut mungkin ada di bagian di dalam cache milik pengguna akhir browser.
Secara umum, sebagian besar panduan di luar sana tentang {i>caching<i} akan berbicara tentang ingin menyimpan di cache selama satu jam, beberapa jam, dan seterusnya. Untuk menyetelnya {i>cache<i}, gunakan {i>header<i} seperti ini (yang disimpan dalam cache selama 3600 detik, jam):
Cache-Control: max-age=3600,immutable,public
Satu poin terakhir. Jika Anda membuat konten yang biasanya hanya dapat dilakukan diakses oleh pengguna sekali—seperti artikel berita!—pendapat saya adalah bahwa hal ini tidak boleh di-cache, dan Anda harus menggunakan pengaturan {i>default<i} kami di atas. Saya pikir kita sering melebih-lebihkan nilai penyimpanan dalam cache terhadap keinginan pengguna untuk selalu melihat dan konten terbaik, seperti pembaruan penting tentang berita atau peristiwa.
Opsi non-HTML
Selain HTML, beberapa opsi lain untuk file yang berada di jalan tengah termasuk:
Secara umum, cari aset yang tidak memengaruhi aset lain
- Misalnya: hindari CSS, karena akan menyebabkan perubahan pada cara HTML Anda dirender
Gambar besar yang digunakan sebagai bagian dari artikel aktual
- Pengguna Anda mungkin tidak akan mengunjungi satu artikel lagi beberapa kali, jadi jangan menyimpan foto atau gambar utama di {i>cache<i} selamanya dan penyimpanan limbah
Aset yang mewakili sesuatu yang memiliki masa aktif
- Data JSON tentang cuaca mungkin hanya dipublikasikan setiap jam, jadi Anda bisa menyimpan hasil sebelumnya ke cache selama satu jam—hasil itu tidak akan berubah di jendela Anda
- Build project open source mungkin dibatasi kapasitasnya, jadi simpan cache membangun image status hingga status mungkin berubah
Ringkasan
Saat pengguna memuat situs Anda untuk kedua kalinya, Anda telah memiliki suara percaya diri—mereka ingin kembali dan mendapatkan lebih banyak dari yang Anda tawarkan. Di ini tidak selalu hanya mengurangi waktu muat, dan Anda memiliki banyak opsi yang tersedia untuk memastikan bahwa {i>browser<i} Anda hanya berfungsi aplikasi harus memberikan pengalaman yang cepat dan terbaru.
Menyimpan data ke cache bukanlah konsep baru di web, tetapi mungkin memerlukan pemahaman yang logis default—pertimbangkan untuk menggunakan salah satu dan pilih ikut serta dalam strategi penyimpanan dalam cache yang lebih baik saat Anda membutuhkannya. Terima kasih sudah membaca!
Lihat juga
Untuk panduan umum tentang {i> cache HTTP<i}, lihat Cegah permintaan jaringan yang tidak perlu dengan Cache HTTP.