Untuk dokumen publik yang dapat diedit, pilih validasi ulang agar pembaca mendapatkan konten terkini sementara halaman yang tidak berubah tetap dapat digunakan kembali. Pilih no-store jika persyaratan publikasi Anda secara khusus melarang penyimpanan cache HTTP.

Panduan ini ditujukan bagi orang yang mengelola dokumen publik dari desktop Mac. Tugasnya adalah memilih kebijakan respons, lalu memeriksanya di Terminal menggunakan halaman sintetis yang hanya berisi teks netral, seperti “Panduan bentuk, versi satu.” Anda memerlukan halaman uji dan akses ke konfigurasi hosting-nya, atau penyedia yang dapat mengonfigurasi header responsnya.

Kebijakan caching mana yang sesuai untuk dokumen ini?

Mulailah dari persyaratan publikasi. Apakah halaman perlu diperiksa sebelum setiap kali digunakan kembali, apakah salinan yang ada boleh tetap digunakan untuk waktu singkat, atau apakah cache HTTP harus menghindari penyimpanan respons? Ini adalah persyaratan berbeda menurut RFC 9111: HTTP Caching.

Persyaratan publikasi Header respons yang dapat dipilih Makna bagi cache HTTP
Periksa sebelum setiap kali digunakan kembali Cache-Control: no-cache Penyimpanan diizinkan; penggunaan kembali memerlukan validasi yang berhasil.
Izinkan jangka waktu singkat untuk konten tetap segar Cache-Control: max-age=300, must-revalidate Penggunaan kembali diizinkan selama konten masih segar; setelah kedaluwarsa, validasi yang berhasil diperlukan.
Larang penyimpanan respons Cache-Control: no-store Cache tidak boleh menyimpan respons atau menggunakannya untuk permintaan lain.

Jangka waktu lima menit hanyalah contoh, bukan nilai bawaan yang direkomendasikan. Pilih nilai itu hanya jika dokumen Anda dapat menoleransi interval penggunaan kembali tersebut. must-revalidate saja tidak mewajibkan pemeriksaan selama respons masih segar. Perbedaan ini mengikuti direktif respons RFC 9111.

Untuk panduan bentuk sintetis, misalkan koreksi dari “tiga contoh” menjadi “empat contoh” harus diperiksa pada pengambilan berikutnya. Mulailah dengan no-cache dan validator yang berfungsi. Jika persyaratan Anda menyatakan bahwa cache HTTP tidak boleh menyimpan respons dokumen ini, pilih no-store. Seringnya pengeditan saja tidak berarti penyimpanan harus dilarang.

Tuliskan persyaratannya sebelum mengubah pengaturan, misalnya: “Periksa dokumen sebelum digunakan kembali.” Dengan begitu, Anda memiliki kriteria penerimaan yang konkret dan nama suatu pengaturan tidak menentukan kebijakannya.

Apa yang membuat validasi ulang berfungsi?

Validator mengidentifikasi versi yang sudah diterima klien. ETag menyediakan tag entitas; Last-Modified menyediakan stempel waktu perubahan. RFC 9110 menyarankan pengiriman validator yang tersedia untuk pengambilan dokumen yang berhasil, dengan mengutamakan tag entitas yang kuat sekaligus tanggal perubahan. Lihat HTTP Semantics, validators dan 200 OK.

Berikut adalah contoh field header respons, bukan kode konfigurasi server. Contoh ini mengasumsikan isi responsnya adalah panduan bentuk sintetis:

Cache-Control: no-cache
ETag: "shape-guide-v1"

Pada permintaan berikutnya, klien dapat mengirim If-None-Match: \"shape-guide-v1\". Jika tag tersebut masih cocok dengan representasi yang dipilih, permintaan kondisional GET menerima 304 Not Modified, tanpa isi respons. Jika tag tidak lagi cocok, pemrosesan normal dapat mengembalikan dokumen yang telah berubah. Aturan ini tercantum di bagian permintaan kondisional RFC 9110.

Persyaratan implementasinya adalah validator harus mengikuti versi dokumen. Jangan menyalin tag contoh ini ke konfigurasi permanen dan membiarkannya tidak berubah setelah dokumen diedit. Minta sistem hosting Anda membuat validator secara konsisten dan mengevaluasi kondisi yang masuk.

Berapa banyak transfer yang dapat dihindari untuk respons yang tidak berubah?

Pertimbangkan perhitungan ilustratif berikut: isi dokumen berukuran 80.000 byte, dan klien mengambilnya 100 kali tanpa ada pengeditan. Satu respons penuh diikuti 99 validasi yang berhasil mentransfer 80.000 byte isi, bukan 8.000.000 byte isi—selisih 7.920.000 byte.

Perhitungan itu tidak mencakup header, kompresi, overhead koneksi, atau pekerjaan aplikasi. Perhitungan tersebut hanya menjelaskan transfer isi. Penjelasan caching HTTP dari Google menggambarkan pertukaran yang sama: validator yang cocok mengizinkan 304 tanpa isi, dan klien menggunakan konten yang sudah diterimanya. Penghematan sebenarnya bergantung pada seberapa sering dokumen berubah dan bagaimana klien mengirim permintaan.

Di mana kebijakan ini harus dikonfigurasi?

Konfigurasikan respons HTTP yang dihasilkan oleh layanan hosting, server, atau lapisan distribusi konten Anda. Contoh header di atas menjelaskan hasil yang diperlukan; contoh tersebut bukan perintah universal untuk platform publikasi.

Jika editor Anda hanya memungkinkan perubahan teks dokumen, cara mengakalinya dengan markup tidak memberikan kendali yang setara. Standar HTML WHATWG tidak menetapkan Cache-Control sebagai pragma http-equiv yang didukung, dan menjelaskan bahwa pragma ini sebagian besar terpisah dari header HTTP. Lihat HTML Standard: Pragma directives.

Cara yang didukung adalah menggunakan konfigurasi header respons yang didokumentasikan oleh host Anda atau meminta penyedia menerapkannya. Ikhtisar crawler dari Google juga mengarahkan penerbit untuk meminta penyedia hosting atau sistem pengelolaan konten menerapkan caching HTTP. Permintaan yang jelas menyebutkan dokumen, kebijakan yang dipilih, perilaku validator, lalu menanyakan cara memverifikasi respons yang dikirim.

Mengubah opsi permintaan JavaScript cakupannya lebih sempit. WHATWG menetapkan mode cache Fetch no-store yang berperilaku seolah-olah tidak ada cache HTTP, sementara no-cache membuat permintaan kondisional jika terdapat respons cache yang sesuai. Mode ini mengatur permintaan tersebut; menetapkan salah satunya dalam skrip tidak mengonfigurasi kebijakan respons server dokumen. Lihat mode cache Fetch Standard.

Bagaimana cara menguji validasi ulang dari Mac?

Gunakan dokumen uji publik sintetis yang dapat Anda edit. Sebelum memulai, atur kontennya menjadi “Panduan bentuk, versi satu” dan pastikan header respons yang dipilih dikirimkan. Pisahkan pengujian ini dari konten dokumen sungguhan agar Anda dapat membuat perubahan yang jelas dan mudah dibatalkan.

Buka Terminal dan jalankan perintah berikut dalam sesi yang sama. Perintah ini akan meminta URL uji Anda yang sebenarnya dan validator yang dikembalikan oleh halaman tersebut; tidak ada alamat contoh yang diasumsikan. Hentikan setelah permintaan pertama jika gagal, dialihkan, atau mengembalikan sesuatu selain respons dokumen yang dimaksud.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

Perintah ini mengirim permintaan GET, menampilkan header yang diterima, dan sengaja membuang isi respons. Batas waktu membatasi durasi koneksi dan transfer; pesan kesalahan tetap ditampilkan. Opsi ini didokumentasikan di manual curl. Permintaan pertama seharusnya menampilkan nilai Cache-Control yang Anda pilih dan sebuah ETag. Jika tidak ada tag, jangan masukkan nilai palsu: pastikan dukungan validator terlebih dahulu.

Salin seluruh nilai tag, termasuk tanda kutip yang mengapitnya dan awalan W/ jika ada. Jika representasi tidak berubah dan tag cocok, permintaan kondisional seharusnya mengembalikan 304. 304 tidak dapat memuat konten dan harus menyertakan metadata yang ditentukan untuk respons 200 yang setara, termasuk ETag dan Cache-Control jika berlaku. Lihat RFC 9110: 304 Not Modified.

Uji pengeditan dengan tetap menggunakan validator lama

Ubah dokumen sintetis menjadi “Panduan bentuk, versi dua: empat contoh.” Setelah pembaruan diterapkan ke halaman uji, pertahankan tag lama di sesi Terminal yang sama dan jalankan perintah lanjutan berikut:

check_page

Untuk dokumen yang sengaja diubah ini, isi baru seharusnya tersedia melalui respons sukses normal beserta validator yang diperbarui. Berikutnya, ulangi perintah awal dengan tag baru dan periksa kembali versi yang tidak berubah. Ini menguji kedua kondisi: mengenali perubahan dan mengenali bahwa tidak ada perubahan.

Pengamatan Langkah diagnosis berikutnya
Permintaan awal mengembalikan pengalihan Gunakan URL akhir dokumen dan mulai ulang pengujian.
Permintaan kondisional untuk konten yang tidak berubah mengembalikan 200 Periksa apakah Anda menyalin tag dengan benar dan apakah penanganan kondisional telah diaktifkan.
Pengeditan konten yang disengaja tetap menghasilkan 304 dengan tag lama Selidiki penerapan pembaruan dan pembuatan validator sebelum mengandalkan validasi ulang.
Kebijakan yang dikirim berbeda dari konfigurasi Anda Periksa pengaturan hosting dan distribusi yang bertanggung jawab atas respons akhir.
Permintaan kehabisan waktu atau gagal Atasi kegagalan pengambilan sebelum menafsirkan perilaku cache.

Ini adalah petunjuk diagnosis, bukan bukti penyebab tertentu. Prosedur ini menguji respons dan pertukaran kondisional; prosedur ini tidak memastikan perilaku setiap browser. Saat mengevaluasi no-store, periksa direktif respons tersebut secara langsung. Permintaan kondisional yang Anda buat secara manual bukanlah pengujian untuk mengetahui apakah browser menyimpan respons.

Apa artinya ini bagi Google Search?

Dokumentasi crawler Google saat ini mendukung ETag dengan If-None-Match serta Last-Modified dengan If-Modified-Since. Dokumentasi itu merekomendasikan ETag untuk crawler Google dan menyebutkan bahwa setiap crawler dapat menggunakan caching dengan cara berbeda. Lihat Ikhtisar crawler dan pengambil Google.

Halaman itu juga menyebutkan bahwa direktif caching HTTP lainnya tidak didukung, sekaligus menyarankan max-age sebagai kemungkinan petunjuk perayapan ulang bersama Last-Modified. Berdasarkan batasan yang didokumentasikan itu, jangan berasumsi kebijakan no-store atau no-cache Anda yang berorientasi pada browser menentukan jadwal pengambilan oleh Googlebot. Terapkan dan uji validator sebagai jalur pengambilan kondisional yang didokumentasikan.

Google menjelaskan bahwa 304 memberi sinyal kepada sistem pemrosesnya bahwa konten tidak berubah; untuk Search, selain itu, status tersebut tidak berdampak pada pengindeksan. Respons 200 yang berhasil juga tidak menjamin pengindeksan. Hal ini didokumentasikan di Dampak kode status HTTP pada crawler Google.

Pilih kebijakan yang sesuai dengan persyaratan dokumen Anda, lalu simpan bukti pengujiannya: respons awal, respons kondisional untuk konten yang tidak berubah, dan respons setelah pengeditan yang disengaja. Untuk dokumen publik yang perlu diperiksa sebelum digunakan kembali, validasi ulang adalah titik awal yang praktis. Pilih no-store jika pelarangan penyimpanan cache HTTP memang menjadi persyaratannya.

Sumber