Kita terbiasa mengukur performa web dari sisi kode. Bundle size. Lazy loading. Preconnect.
Lalu paket 100 Mbps di rumah terasa lambat membuka situs tertentu, dan tiba-tiba semua tuning frontend itu terasa seperti menambal atap sementara pipanya yang bocor.
Masalahnya sering bukan di kode. Melainkan di berapa banyak hop yang harus dilewati sebuah request sebelum byte pertama kembali. Laporan Opensignal tentang pengalaman fixed broadband Indonesia menunjukkan penetrasi broadband nasional masih di kisaran 25% dengan pergeseran cepat ke fiber — artinya kualitas jalur data, bukan sekadar angka bandwidth, yang makin menentukan. Dan di titik itulah cache hit ratio edge berhenti menjadi metrik infrastruktur dan mulai menjadi metrik pengalaman pengguna.
Ada landasan risetnya. Studi di Future Internet soal strategi edge caching dan ambang cache-hit ratio menemukan titik silang kuantitatif di sekitar 70% cache-hit ratio — di bawah itu, strategi proaktif kalah dibanding pendekatan reaktif; di atasnya, ketersediaan konten di edge jadi faktor kunci konektivitas mulus.
Angka itu menarik karena bisa langsung dipakai sebagai target operasional, bukan sekadar wacana akademik.
Kami mengangkat tema ini karena sebagai penyedia infrastruktur jaringan, kami melihat sisi yang jarang terlihat developer: request yang sama bisa punya nasib sangat berbeda tergantung apakah ia berhenti di edge atau harus menempuh perjalanan penuh ke origin. Developer melihat waterfall di DevTools. Operator jaringan melihat jalur fisiknya. Artikel ini menyambung dua sudut pandang itu.
"Optimasi aplikasi web pada dasarnya adalah soal caching dan penurunan latensi." — prinsip yang dipegang tim engineering DEV sendiri saat membangun platform ini di atas edge caching Fastly.
1. Anatomi Jalur Data: Dari ONU di Ruang Tamu sampai Origin
Sebelum bicara optimasi, kita perlu peta. Banyak diskusi performa web berhenti di "server saya di Singapura" padahal ada belasan titik sebelum dan sesudahnya. Berikut jalur yang sebenarnya dilewati sebuah HTTP request dari rumah pelanggan fiber di Indonesia.
Tahapan yang Benar-benar Terjadi
- Perangkat → ONU/ONT. Frame keluar dari laptop, lewat Wi-Fi atau UTP, masuk ke Optical Network Unit.
- ONU → OLT. Sinyal optik naik lewat splitter pasif menuju Optical Line Terminal di POP operator.
- OLT → Core/Edge Router ISP. Traffic diagregasi. Di sini CGNAT dan policy routing bekerja.
- ISP → IXP. Kalau tujuannya terhubung ke Internet Exchange lokal, perjalanan bisa berhenti pendek di sini.
- IXP → PoP CDN. Request menyentuh edge server terdekat.
- Edge → Origin. Hanya terjadi kalau cache miss.
Poin nomor enam itu yang mahal. Sisanya sudah dioptimasi habis-habisan oleh operator.
Kenapa Hop Terakhir Paling Menentukan
Bandwidth dan latensi adalah dua hal berbeda. Menambah bandwidth seperti melebarkan jalan tol — tidak membuat perjalanan Jakarta–Surabaya jadi lima menit.
Round-trip ke origin yang jauh menambah waktu tetap yang tidak bisa dinegosiasikan oleh kecepatan langganan.
Inilah kenapa pelanggan 300 Mbps dan 50 Mbps bisa merasakan TTFB yang mirip pada situs yang sama, selama kontennya sama-sama tidak ter-cache.
2. Membaca Cache-Hit Ratio Seperti Membaca Vital Sign
Cache-hit ratio adalah persentase request yang bisa dilayani edge tanpa menghubungi origin. Sederhana rumusnya, rumit implikasinya. Berikut cara membacanya secara operasional, lengkap dengan konsekuensi tiap rentang angka.
Tabel Referensi Rentang CHR
| Cache-Hit Ratio | Kondisi | Efek pada TTFB | Tindakan Prioritas |
|---|---|---|---|
| < 40% | Kritis | Fluktuatif, sering >800 ms | Audit Cache-Control, cek cookie yang membuat bypass |
| 40–70% | Belum optimal | Tidak konsisten antar wilayah | Naikkan TTL aset statis, aktifkan stale-while-revalidate
|
| 70–85% | Sehat | Stabil, mayoritas < 200 ms | Mulai pertimbangkan caching HTML anonim |
| > 85% | Sangat baik | Konsisten lintas region | Fokus pindah ke INP dan rendering |
Ambang 70% itu bukan angka karangan. Ia sejalan dengan temuan crossover pada riset edge caching yang dirujuk di atas.
Kesalahan Baca yang Sering Terjadi
- Menghitung CHR global, bukan per-region. Angka 90% nasional bisa menyembunyikan 45% di satu wilayah.
- Mengabaikan cache miss pada aset kecil. Font dan ikon SVG sering lolos audit karena ukurannya remeh, padahal tiap miss tetap menambah round-trip.
- Menganggap semua miss buruk. Konten personalisasi memang tidak seharusnya ter-cache di shared cache.
- Lupa cold cache setelah deploy. Purge total di jam sibuk sama dengan mengirim seluruh traffic ke origin sekaligus.
3. Edge Delivery di Konteks Jaringan Indonesia
Geografi kepulauan membuat pembahasan edge delivery di Indonesia punya karakter sendiri. Jarak fisik antar pulau nyata, dan tidak semua traffic berakhir di PoP yang sama. Bagian ini membahas implikasi praktisnya untuk developer yang penggunanya tersebar.
Peran Peering Lokal
Ketika ISP melakukan peering di IXP domestik, traffic ke edge server yang juga hadir di IXP tersebut tidak perlu keluar negeri. Selisihnya bisa puluhan milidetik.
Bagi aplikasi yang membuat 30–40 request per halaman, puluhan milidetik itu terakumulasi jadi pengalaman yang terasa berbeda.
Di sisi lain, konten yang hanya ada di PoP Singapura akan selalu membayar ongkos perjalanan tambahan, seberapapun cepatnya fiber di sisi pelanggan.
Apa yang Bisa Dikontrol Developer, Apa yang Tidak
| Aspek | Kendali Developer | Kendali ISP/Operator |
|---|---|---|
Header Cache-Control
|
✅ Penuh | ❌ |
| Pemilihan region origin | ✅ Penuh | ❌ |
| Rute ke IXP terdekat | ❌ | ✅ |
| Kualitas last-mile ke ONU | ❌ | ✅ |
| Cache key & variasi konten | ✅ Penuh | ❌ |
| Kapasitas uplink saat jam sibuk | ❌ | ✅ |
Kesadaran soal pembagian ini menghemat banyak waktu debugging. Kalau CHR sudah 88% dan TTFB masih buruk hanya di satu kota, masalahnya kemungkinan besar bukan di header Anda.
Untuk pemahaman konseptual yang lebih ringan soal pembagian peran CDN dan caching, tulisan komunitas CDNs vs Caching: The Key to Blazing Fast Web Performance di DEV menjelaskannya dengan baik.
4. Cara Mengaudit dan Menaikkan Cache Hit Ratio Edge
Bagian ini adalah prosedur yang bisa langsung dijalankan. Tidak butuh tooling mahal — sebagian besar cukup dengan curl, DevTools, dan dashboard CDN yang sudah Anda punya.
How-To: Audit Cache dalam 6 Langkah
Langkah 1 — Ambil baseline.
curl -sI https://contoh-situs.id/assets/app.css | grep -iE "cf-cache-status|x-cache|age|cache-control"
Catat statusnya: HIT, MISS, EXPIRED, atau DYNAMIC.
Langkah 2 — Inventarisasi aset yang MISS.
Buka DevTools → Network → tambahkan kolom kustom untuk response header cache. Urutkan berdasarkan status. Fokus ke aset yang muncul di setiap halaman.
Langkah 3 — Periksa penyebab bypass.
Tiga tersangka utama: cookie sesi yang dikirim ke aset statis, query string unik per request, dan header Vary yang terlalu longgar.
Langkah 4 — Perbaiki header.
Cache-Control: public, max-age=31536000, immutable
untuk aset ber-hash. Untuk HTML anonim:
Cache-Control: public, s-maxage=60, stale-while-revalidate=600
Langkah 5 — Ukur ulang per region.
Jangan puas dengan angka agregat. Bandingkan minimal tiga titik: Jakarta, luar Jawa, dan satu lokasi internasional.
Langkah 6 — Hangatkan cache setelah deploy.
Jadwalkan pemanggilan otomatis ke URL kritis segera setelah purge, sebelum traffic organik datang.
Checklist Cepat Sebelum Deploy
- [ ] Aset statis memakai hash pada nama file
- [ ] Tidak ada cookie yang ikut terkirim ke path
/assets/ - [ ]
Varyhanya berisi header yang benar-benar mengubah respons - [ ] TTL edge dan TTL browser dibedakan secara sadar
- [ ] Ada strategi warm-up pasca-purge
- [ ] Monitoring CHR dipecah per region, bukan hanya global
5. Ketika Optimasi Cache Sudah Mentok
Ada titik di mana menaikkan cache-hit ratio edge tidak lagi memberi perbaikan berarti. Mengenali titik itu sama pentingnya dengan melakukan optimasinya. Berikut sinyal-sinyalnya dan ke mana harus berpindah fokus.
Sinyal Anda Sudah Sampai Batas
CHR stabil di atas 85%, TTFB konsisten di bawah 200 ms untuk mayoritas pengguna, tetapi halaman masih terasa berat.
Kalau ini kondisinya, bottleneck sudah pindah.
Kemungkinan besar ke main thread — JavaScript yang memblokir, layout shift, atau hydration yang mahal. Metrik yang relevan berubah dari TTFB ke INP dan CLS.
Sisa Masalah yang Bukan Milik Anda
Sebagian keluhan lambat memang berasal dari sisi jaringan pelanggan: perangkat ONU lama, Wi-Fi yang penuh interferensi, atau kapasitas uplink yang padat saat jam sibuk.
Bagian ini di luar jangkauan header HTTP manapun.
Yang bisa dilakukan developer adalah membuat aplikasi tetap layak pakai pada koneksi buruk — progressive enhancement, skeleton yang jujur, dan ketahanan terhadap request yang gagal.
Sisanya adalah pekerjaan operator jaringan. Pengembangan infrastruktur fiber optic dan pengelolaan jalur konektivitas semacam ini adalah fokus kerja kami di PT Jaringan Lintas Artha, termasuk memastikan last-mile dan rute ke edge tetap sehat bagi pengguna rumahan maupun bisnis.
FAQ
Berapa cache-hit ratio yang ideal?
Di atas 85% untuk situs dengan mayoritas konten statis. Untuk aplikasi dengan banyak konten personal, 60–70% sudah wajar. Yang penting bukan angka absolutnya, melainkan konsistensinya antar region.
Apakah cache-hit ratio edge memengaruhi Core Web Vitals?
Terutama LCP, lewat jalur TTFB. Cache miss menambah round-trip ke origin, dan waktu itu terhitung penuh sebelum elemen terbesar bisa mulai dirender.
Kenapa CHR tinggi tapi pengguna masih mengeluh lambat?
Cek pemecahan per region dan per tipe aset. Bisa juga bottleneck sudah pindah ke rendering, bukan lagi ke jaringan.
Bandwidth besar bisa menutupi cache miss?
Tidak. Bandwidth mengurangi waktu transfer, bukan waktu round-trip. Cache miss menambah latensi tetap yang tidak terpengaruh besarnya pipa.
Apakah HTML boleh di-cache di edge?
Boleh, untuk pengunjung anonim, dengan s-maxage pendek plus stale-while-revalidate. Pastikan ada aturan bypass ketika cookie sesi terdeteksi.
Apa hubungan ONU dengan performa web?
ONU adalah titik konversi optik-elektrik di sisi pelanggan. Perangkat lama atau firmware usang bisa menambah latensi dan membatasi throughput, meskipun jalur fiber di belakangnya sehat.
Yang Tersisa Setelah Semua Header Diperbaiki
Mengakhiri pembahasan ini, ada satu pergeseran cara pandang yang layak dibawa pulang: performa web adalah properti sistem, bukan properti kode. Header yang sempurna tidak menolong kalau rutenya panjang. Jaringan yang cepat tidak menolong kalau setiap request dipaksa menyentuh origin.
Dua sisi ini harus dibaca bersamaan.
Ilya Grigorik, engineer yang lama memimpin kerja web performance di Google dan menulis High Performance Browser Networking, merangkumnya dalam satu kalimat yang sering dikutip komunitas:
"Latency is the new performance bottleneck."
Kalimatnya singkat tapi mengubah prioritas. Selama bertahun-tahun industri mengejar bandwidth sebagai ukuran kemajuan, padahal setelah titik tertentu, tambahan bandwidth memberi hasil yang makin kecil. Yang tersisa sebagai penghambat adalah waktu tempuh — dan waktu tempuh hanya bisa dipangkas dengan memindahkan data lebih dekat ke pengguna. Persis itulah yang dilakukan edge delivery. Grigorik relevan di sini karena kerjanya menjembatani dua dunia yang biasanya terpisah: protokol jaringan dan praktik frontend, dua hal yang bertemu tepat di titik cache-hit ratio edge.
Jadi lain kali angka Lighthouse tidak kunjung membaik, jangan langsung buka bundler.
Buka dulu response header-nya.
Sering kali jawabannya sudah ada di sana.
Top comments (0)