Minggu lalu penulis situs statis menambahkan CDN cache di depan situsnya, berharap halaman-halaman HTML bisa lebih cepat diakses. Hasilnya justru berkebalikan: crawler independen yang sebelumnya menyoroti 38 halaman lambat, setelah perubahan jumlahnya melonjak menjadi 75 halaman. Ia langsung membatalkan perubahan dalam hari yang sama.<\/p>\n
Akarnya karena dua asumsi yang salah. Pertama, cache MISS tidak gratis<\/em>: saat respons tidak ada di edge (MISS), CDN tidak hanya meneruskan traffic ke origin, tapi juga harus menyimpan objek itu Sainstitus sementara streaming berlangsung. Pengukuran menunjukkan MISS membutuhkan waktu ~85 ms lebih lama dibanding tidak pakai cache sama sekali \u2014 jadi setiap request yang MISS justru lebih buruk daripada baseline tanpa cache.<\/p>\n Kedua, crawler selalu dalam keadaan dingin<\/em>. Crawler mengambil setiap URL hanya sekali, jadi selama proses crawl hit rate bisa saja 0%. Penulis menghitung titik impas-nya: dengan angka TTFB MISS 0.366 s, baseline origin 0.281 s, dan HIT 0.239 s, dibutuhkan hit rate 67% hanya untuk sekadar membatalkan kerugian. Dengan 77 halaman, 9 pengunjung per hari, dan cache yang dibersihkan tiap deploy, hit rate realistisnya mendekati nol \u2014 jauh di bawah angka yang dibutuhkan.<\/p>\n Pesan utamanya: sebelum mengaktifkan cache HTML di edge, hitung dulu break-even hit rate-nya dengan rumus h > (M \u2212 B) \/ (M \u2212 H)<\/code>, di mana M adalah waktu MISS, B baseline tanpa cache, dan H waktu HIT. Jika hit rate realistisnya tidak tercapai, berhenti di situ. Verifikasi performa selalu dari metrik yang menunjukkan masalah asli (bukan dari mesin yang berada di negara yang sama dengan origin server). Dan pada situs dengan traffic rendah yang tersebar di banyak lokasi, jawaban yang jujur bisa jadi bukan cache, melainkan memindahkan origin server lebih dekat ke audiens.<\/p>\n