Apa Itu CDN dan Edge Network

CDN — content delivery network — adalah jaringan server yang tersebar di banyak lokasi, yang menyimpan salinan situsmu dan menyajikannya dari titik terdekat dengan pengunjung.

Alasan keberadaannya sederhana: data tidak bisa bergerak lebih cepat dari cahaya, dan jarak fisik ternyata memperlambat situs lebih banyak daripada yang orang duga.

Kenapa jarak itu penting

Cahaya menempuh sekitar 300.000 kilometer per detik, dan sinyal di kabel serat optik agak lebih lambat dari itu. Jakarta ke Virginia sekitar 16.000 kilometer, jadi perjalanan bolak-balik satu sinyal saja sudah sekitar 160 milidetik — dalam kondisi ideal, tanpa hambatan apa pun.

Masalahnya, memuat halaman tidak cuma butuh satu perjalanan bolak-balik. Ada pencarian DNS, ada pembentukan koneksi, ada jabat tangan TLS, baru permintaan halamannya. Masing-masing perlu perjalanan sendiri.

Empat kali bolak-balik ke Virginia sudah lebih dari setengah detik, sebelum byte pertama halamanmu terkirim. Dan itu belum menghitung waktu server memproses permintaan.

Kalau situsmu disajikan dari Singapura, jarak itu menyusut jadi sekitar 900 kilometer. Perjalanan bolak-baliknya sekitar 10 milidetik. Selisihnya bukan hal yang perlu diukur dengan alat — pengunjung merasakannya langsung.

Cara kerjanya

Saat kamu men-deploy situs statis ke Netlify, Vercel, atau Cloudflare, berkasmu tidak diletakkan di satu server. Ia disalin ke lokasi-lokasi di seluruh dunia yang biasa disebut PoP — point of presence.

Lalu:

1. Pengunjung dari Surabaya membuka situsmu.
2. DNS mengarahkannya ke PoP terdekat — mungkin Jakarta atau Singapura.
3. PoP itu punya salinan situsmu, dan langsung mengirimkannya.
4. Tidak ada permintaan yang menyeberangi samudra.

Untuk situs statis, semua berkasmu ada di semua lokasi. Inilah sebabnya situs statis terasa instan di mana pun — dan kenapa arsitektur ini jadi dasar Jamstack.

Origin dan edge

Dua istilah yang perlu kamu kenal.

Origin adalah sumber aslinya — server tempat isi situsmu sebenarnya berada.

Edge adalah lokasi-lokasi CDN yang menyimpan salinannya, dekat dengan pengunjung.

Untuk situs statis murni, seluruh situsmu ada di edge dan origin praktis tidak pernah disentuh setelah deploy.

Untuk situs dengan kode server, sebagian permintaan harus kembali ke origin — dan di situlah kecepatannya turun. Semakin banyak yang bisa dilayani dari edge, semakin cepat situsmu.

Cache: siapa menyimpan apa

Ada tiga lapisan cache, dan memahami perbedaannya menghindarkan banyak kebingungan.

Baris pertama itu yang paling sering menimbulkan masalah. Kalau kamu menyuruh browser menyimpan sebuah berkas selama setahun, kamu tidak punya cara membatalkannya. Pengunjung yang sudah menyimpannya akan tetap memakai versi lama sampai kedaluwarsa atau mereka membersihkan cache sendiri.

Mengatur cache dengan benar

Ini bagian praktisnya, dan aturannya cuma dua.

Aset dengan hash: cache selamanya

Build tool modern menyisipkan hash ke nama berkas — index-a1b2c3.js. Kalau isinya berubah, hash-nya berubah, jadi namanya berubah.

Karena nama itu unik untuk isi tertentu, berkasnya aman di-cache selamanya:

Cache-Control: public, max-age=31536000, immutable

Kata immutable memberi tahu browser bahwa berkas ini tidak akan pernah berubah, jadi tidak perlu repot memeriksanya lagi.

HTML: jangan pernah cache lama

Berkas index.html namanya tidak pernah berubah. Kalau kamu menyimpannya lama di cache browser, pengunjung akan tersangkut di versi lama situsmu — dan versi lama itu merujuk ke nama berkas JavaScript yang mungkin sudah tidak ada.

Cache-Control: public, max-age=0, must-revalidate

Ini menyuruh browser memeriksa ke server tiap kali. Kalau tidak ada perubahan, server menjawab singkat dan tidak mengirim ulang isinya — jadi biayanya kecil.

Contoh konfigurasi

Netlify — di netlify.toml:

[[headers]]
  for = "/assets/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

[[headers]]
  for = "/*.html"
  [headers.values]
    Cache-Control = "public, max-age=0, must-revalidate"

Vercel — di vercel.json:

{
  "headers": [
    {
      "source": "/assets/(.*)",
      "headers": [
        { "key": "Cache-Control",
          "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

Kabar baiknya: semua platform ini sudah menyetel default yang benar. Kamu baru perlu mengaturnya sendiri kalau punya kebutuhan khusus.

Memeriksa apakah cache-nya bekerja

Lihat header responsnya:

curl -sSI https://situsku.com/ | grep -i "cache\|age"

Yang perlu diperhatikan:

• cf-cache-status: HIT di Cloudflare — berarti disajikan dari cache edge.
• x-vercel-cache: HIT di Vercel — sama artinya.
• age — sudah berapa lama versi itu ada di cache.

Status MISS pada permintaan pertama itu normal. Kalau permintaan kedua juga MISS, ada yang salah dengan konfigurasi cache-mu.

Edge bukan cuma untuk berkas

Dulu CDN hanya menyimpan dan mengirim berkas. Sekarang lokasi edge juga bisa menjalankan kode.

Ini yang disebut edge function: kode ringan yang berjalan di titik CDN terdekat, bukan di satu server pusat. Berguna untuk redirect berdasarkan lokasi, A/B testing, atau pemeriksaan cookie sebelum meneruskan permintaan.

Tapi ada jebakannya, dan cukup sering terjadi: kalau kode edge-mu memanggil database yang ada di satu tempat, keuntungan kedekatannya hilang. Penjelasan lengkapnya di serverless vs edge functions.

Apakah kamu perlu mengatur CDN sendiri?

Untuk situs statis di platform modern: tidak. CDN sudah termasuk dan aktif secara bawaan di Netlify, Vercel, Cloudflare, dan GitHub Pages. Kamu tidak perlu mendaftar atau menyetel apa pun.

Kamu baru perlu memasang CDN terpisah kalau situsmu berjalan di server sendiri atau shared hosting tradisional. Dalam kasus itu, Cloudflare bisa dipasang di depan hosting yang sudah ada dan menyalin aset statismu ke edge.

Ringkasan

CDN menyalin situsmu ke banyak lokasi supaya pengunjung dilayani dari titik terdekat. Untuk situs statis, ini menghilangkan sebagian besar waktu tunggu yang disebabkan jarak — dan jadi alasan utama kenapa situs statis terasa instan di mana pun.

Dua aturan cache yang perlu kamu ingat: aset dengan hash boleh di-cache selamanya, HTML tidak boleh. Selebihnya sudah diurus platformmu.

Untuk melihat dampaknya pada metrik yang diukur Google, lihat optimasi Core Web Vitals di situs statis.