Halaman Cepat, Persetujuan Salah

Cache halaman adalah salah satu hal terbaik yang dapat Anda lakukan untuk kecepatan dan biaya hosting. Ini juga salah satu cara termudah merusak pengaturan persetujuan tanpa disadari. Cache melakukan persis apa yang diperintahkan: menyimpan respons sekali dan menyajikannya kepada semua yang cocok dengan kunci yang sama. Jika respons tersimpan itu mengandung sesuatu yang spesifik untuk pilihan persetujuan atau lokasi satu pengunjung, pengunjung berikutnya menerimanya juga.

Panduan ini membahas lapisan cache yang biasanya berada di depan situs penerbit — cache edge CDN, plugin cache halaman penuh, reverse proxy, service worker, dan browser itu sendiri — serta cara mencegah masing-masing menyajikan pengalaman persetujuan yang salah.

Aturan Inti: Jauhkan Persetujuan dari HTML yang Di-cache

Arsitektur teraman merender halaman HTML yang di-cache sebagai netral terhadap persetujuan. Halaman berisi loader CMP dan tag Anda dalam status terblokir atau menunggu, tetapi tanpa keputusan tentang pengunjung tertentu ini. CMP kemudian berjalan di browser, membaca pilihan yang tersimpan, memutuskan apakah akan menampilkan banner, dan melepaskan tag sesuai hasilnya.

Masalah dimulai ketika server membuat keputusan persetujuan saat render, misalnya:

• tema atau plugin yang hanya mencetak tag iklan atau analitik bila cookie persetujuan ada;
• kode sisi server yang menghilangkan markup banner untuk pengunjung yang sudah memilih;
• templat yang menyematkan status persetujuan pengunjung dalam variabel skrip inline.

Begitu halaman itu di-cache, status pengunjung pertama menjadi status semua orang. Pengunjung yang menolak pelacakan mungkin menerima halaman dengan tag yang sudah aktif, atau pengunjung baru mungkin tidak pernah melihat banner karena salinan cache berasal dari seseorang yang sudah menutupnya.

Mengapa “Vary: Cookie” Jarang Menjadi Jawabannya

Solusi buku teks untuk konten per pengunjung adalah memberi tahu cache untuk bervariasi berdasarkan header cookie. Dalam praktik, pengunjung membawa banyak cookie dengan nilai unik, sehingga bervariasi pada seluruh header cookie biasanya membuat tingkat cache hit mendekati nol. Beberapa CDN memungkinkan Anda membangun kunci cache dari satu nilai cookie saja, yang layak jika cookie persetujuan Anda hanya memiliki sedikit kemungkinan status, tetapi itu menambah kompleksitas dan tetap melipatgandakan jumlah salinan yang di-cache. Memindahkan keputusan ke browser lebih sederhana dan menjaga cache tetap efisien.

Geografi di Edge

Banyak penerbit menampilkan banner berbeda per wilayah: banner opt-in untuk UE dan Inggris, pemberitahuan opt-out untuk negara bagian AS, dan sesuatu yang lebih ringan di tempat lain. Jika server memilih varian dari alamat IP pengunjung dan halaman itu di-cache, pembaca Eropa dapat menerima halaman AS yang di-cache, atau sebaliknya.

Tiga pola menghindari hal ini:

1. Geolokasi sisi klien. Biarkan CMP menentukan wilayah di browser, sehingga HTML yang di-cache tetap sama untuk semua orang.
2. Negara dalam kunci cache. Jika harus memutuskan di edge, sertakan kode negara yang disediakan CDN Anda dalam kunci cache. Anda mendapat satu salinan cache per negara, yang dapat diprediksi.
3. Logika edge tanpa cache. Jalankan keputusan regional dalam fungsi edge yang menyisipkan nilai kecil tanpa cache ke halaman yang selebihnya di-cache.

Mana pun yang Anda pilih, dokumentasikan. Bug geo termasuk yang paling sulit direproduksi, karena hanya muncul bagi pengunjung di satu tempat yang kebetulan menerima halaman yang di-cache oleh seseorang di tempat lain.

Meng-cache Skrip CMP Itu Sendiri

Meng-cache loader CMP dalam waktu lama bagus untuk performa, tetapi ada biayanya saat konfigurasi berubah. Jika Anda memperbarui vendor, tujuan, atau teks banner dan skrip atau file konfigurasi di-cache selama setahun, sebagian pengunjung akan terus melihat versi lama. Periksa bagaimana CMP Anda memberi versi pada file-nya: nama file atau parameter versi yang berubah memungkinkan Anda melakukan cache agresif sambil tetap meluncurkan perubahan segera. Pastikan juga CDN Anda sendiri tidak menghapus query string dari URL skrip pihak ketiga jika CMP bergantung padanya.

Service Worker dan Cache Offline

Situs dengan lapisan progressive web app sering meng-cache HTML dalam service worker. Aturan yang sama berlaku: jangan pernah menyimpan halaman yang mencerminkan keputusan persetujuan tertentu. Kecualikan endpoint terkait persetujuan dan halaman pusat preferensi dari cache service worker, dan pastikan konfigurasi CMP terbaru selalu dapat diambil.

Back/Forward Cache

Browser modern menyimpan halaman yang baru dikunjungi di memori agar tombol kembali memulihkannya seketika. Jika pengunjung membuka pusat preferensi di satu halaman, menarik persetujuan, lalu menekan kembali, halaman yang dipulihkan mungkin masih menjalankan tag dari sebelumnya. Dengarkan event pageshow dan periksa properti persisted-nya: ketika halaman dipulihkan dari cache ini, baca ulang status persetujuan tersimpan dan hentikan atau mulai tag agar sesuai.

Rutinitas Pengujian

• Muat halaman dalam sesi bersih, tolak, lalu muat halaman kedua dan pastikan tidak ada tag pelacakan yang aktif.
• Ulangi dengan browser bersih kedua dan pastikan banner muncul, membuktikan bahwa ia tidak hilang akibat cache.
• Periksa header respons untuk melihat apakah halaman disajikan dari cache, dan bandingkan HTML dengan dan tanpa cookie persetujuan — seharusnya identik.
• Uji dari setidaknya dua wilayah setelah membersihkan cache, lalu lagi setelah cache menghangat.
• Tarik persetujuan, gunakan tombol kembali, dan verifikasi bahwa tag berhenti.

Poin Penting

• HTML yang di-cache harus netral terhadap persetujuan; biarkan CMP memutuskan di browser.
• Hindari bervariasi pada header cookie penuh; itu menghancurkan tingkat hit.
• Jika banner berbeda per wilayah, putuskan di sisi klien atau tambahkan negara ke kunci cache.
• Beri versi pada file CMP agar masa cache yang panjang tidak menunda perubahan konfigurasi.
• Tangani service worker dan back/forward cache, dan uji dengan cache hangat, bukan hanya setelah dibersihkan.