Kenapa Situs Kecil pun Bisa Terasa Berat dari Luar Negeri

Pesan itu masuk lewat formulir kontak: halaman blog terasa lambat, katalog butuh waktu sebelum bisa diklik. Saya buka alamat yang sama dari sini, di Indonesia, dan halamannya muncul hampir seketika. Server tidak sedang sibuk, tidak ada lonjakan trafik, log bersih. Kalau hanya melihat dari kursi sendiri, tidak ada yang perlu diperbaiki.

Yang berbeda bukan situsnya, melainkan jarak antara pengunjung dan mesin yang menjawab. Pengunjung itu membuka dari Eropa, sementara servernya ada di Singapura. Setiap byte yang dikirim harus menempuh perjalanan panjang, bolak-balik, sebelum halaman bisa tampil. Untuk situs yang isinya sedikit, perjalanan itulah yang paling terasa — bukan beratnya isi.

Situs yang sama, jarak yang berbeda

Membuka satu halaman bukan satu permintaan, melainkan beberapa percakapan. Browser harus mencari alamat IP server lewat DNS, menyepakati koneksi, menyiapkan enkripsi, baru meminta isi halaman. Setiap langkah menunggu jawaban dari seberang. Istilahnya round trip: satu perjalanan bolak-balik yang tidak bisa dihapus, hanya bisa diperpendek.

Di jaringan, jarak bukan hanya soal kilometer. Yang dihitung juga berapa banyak titik yang dilewati dan berapa lama setiap titik menimbang paket. Rute yang jauh cenderung punya lebih banyak kesempatan untuk antre. Hasilnya bukan “situs rusak”, melainkan jeda kecil yang menumpuk: satu untuk DNS, satu untuk koneksi, satu untuk enkripsi, satu untuk dokumen halaman, lalu beberapa lagi untuk gambar, font, dan skrip. Bagi pengunjung dekat, tumpukan itu tidak terasa. Bagi yang jauh, tumpukan yang sama terasa seperti halaman yang berat.

Ini juga menjelaskan kenapa laporan lambat sering terdengar tidak masuk akal. “Di tempat saya cepat.” “Di tempat saya lambat.” Keduanya bisa benar, dan yang membuat perbedaan biasanya bukan kode aplikasi, melainkan jalur antara pengunjung dan server.

Pertanyaan berikutnya wajar: kalau masalahnya jarak, kenapa tidak menaruh server saja di dekat pengunjung? Jawabannya karena satu server bukan hanya berkas. Di dalamnya ada aplikasi, basis data, sesi login, dan data yang harus tetap satu sumber kebenaran. Menduplikasi semua itu ke banyak lokasi jauh lebih rumit daripada menduplikasi berkas yang isinya sama untuk semua orang. Di celah itulah CDN bekerja: menyebarkan bagian yang mudah disalin, tanpa memindahkan bagian yang sulit.

Perjalanan satu permintaan halaman: tanpa edge, setiap langkah menempuh jarak penuh.

Apa yang sebenarnya dikerjakan CDN

CDN adalah kumpulan server yang disebar di banyak lokasi dan disiapkan untuk menjawab permintaan atas nama server utama. Server Anda sendiri — tempat aplikasi, basis data, dan log berjalan — disebut origin. Server-server tersebar itu disebut edge, karena posisinya di tepi jaringan, sedekat mungkin dengan pengunjung.

Idenya sederhana: kalau isi halaman sudah ada di dekat pengunjung, tidak perlu menempuh perjalanan penuh ke origin untuk mendapatkannya. Edge menyimpan salinan — itulah cache — dan menyajikannya langsung. Salinan tidak disimpan selamanya; ada batas waktu bernama TTL, yaitu berapa lama salinan dianggap masih layak dipakai sebelum edge memeriksa apakah ada versi baru di origin.

Yang ikut “pindah dekat” sebenarnya lebih dari sekadar file. Koneksi terenkripsi bisa diselesaikan di edge, jadi pengunjung tidak perlu berjabat tangan kriptografis dengan server yang jauh. Berkas yang sama untuk semua orang — gambar, stylesheet, font — paling mudah disimpan dan disajikan dari sana. Yang memilih edge bukan DNS yang memberi alamat berbeda per pengunjung: record yang di-proxy menjawab dengan alamat anycast Cloudflare, satu alamat yang sama untuk semua orang, dan perutean jaringan di belakangnya yang mengantar permintaan ke pusat data terdekat. Itu sebabnya pengunjung dari kota berbeda bisa dilayani pusat data berbeda tanpa DNS ikut menentukan.

Untuk halaman yang isinya berbeda per pengunjung, keuntungan cache menyusut cepat, karena hampir tidak ada yang bisa dibagi. Cloudflare cenderung memilih berkas yang layak disimpan dari ekstensinya, bukan dari tipe konten yang dikirim origin, dan HTML tidak termasuk yang di-cache bawaan; untuk halaman seperti itu cache harus dinyalakan sendiri. Satu hal lagi yang sering terlewat: ketika permintaan sampai di origin, yang terlihat biasanya alamat IP Cloudflare, bukan pengunjung. Alamat asli pengunjung ikut terkirim di header CF-Connecting-IP, dan X-Forwarded-For memuat rantai proxy beserta alamat itu — tapi keduanya baru berguna kalau origin memang membaca headernya. Tanpa itu, log hanya mencatat alamat edge: di server saya, semua baris access.log yang ada masih berisi 127.0.0.1.

Yang tidak diperbaiki CDN

CDN memindahkan jawaban, bukan pekerjaan. Kalau halaman lambat karena kueri basis data yang berat, proses render di server, atau skrip yang terlalu banyak dijalankan di browser pengunjung, CDN tidak menyentuh bagian itu sama sekali. Yang berubah hanya waktu tunggu sebelum byte pertama tiba; setelah halaman sampai, sisanya tetap urusan kode.

Hal yang sama berlaku untuk halaman yang isinya selalu baru: keranjang belanja, dasbor, hasil pencarian. Untuk halaman seperti itu, cache hampir tidak berperan, dan sisa manfaatnya cuma jalur yang lebih pendek. Itu tetap berguna, tapi biasanya bukan bagian yang paling lambat.

CDN juga bisa menambah masalah baru kalau dipasang tanpa dipikirkan: halaman basi yang terus disajikan, perubahan yang tidak langsung terlihat, dan satu lapisan tambahan yang harus diperiksa setiap kali ada yang aneh. Untuk tim yang hanya satu orang, biaya menjaga lapisan itu nyata, meski tidak terlihat di tagihan.

Ada satu kategori lain yang sering salah alamat: aset dari domain orang lain. Font, skrip analitik, widget komentar, dan tombol berbagi tetap harus diambil dari server penyedianya, betapa pun cepat situs Anda sendiri. Kalau halaman tetap terasa tersendat setelah semuanya dipindahkan dekat, biasanya yang menjawab lambat adalah pihak ketiga, bukan origin Anda. Menambah CDN untuk aset itu tidak otomatis memperbaikinya.

Kriteria memilih yang ringan

Bukan soal mana yang paling banyak fiturnya, melainkan seberapa kecil perubahan yang dibutuhkan untuk mendapat manfaatnya. Beberapa hal yang saya nilai lebih dulu:

• Ada titik yang dekat dengan pembaca Anda. Bukan jumlah lokasi global, tapi apakah ada lokasi di wilayah tempat pembaca benar-benar berada.
• Alur kerja tidak berubah banyak. Idealnya cukup satu perubahan di DNS, tanpa memindahkan aplikasi atau mengubah cara deploy.
• Kontrol cache jelas. Bisa menentukan apa yang disimpan dan berapa lama, tanpa harus membaca dokumentasi berjam-jam. TTL dan header bisa diatur di dua tempat sekaligus — di origin dan di edge — jadi yang perlu dipastikan adalah mana yang benar-benar berlaku.
• Masih bisa diamati. Log permintaan, status cache kena atau tidak, dan asal pengunjung tetap terbaca saat ada keluhan.
• Batas dan biaya bisa diperkirakan. Tahu apa yang terjadi kalau trafik naik, bukan hanya tahu harga paket awal.
• Mudah dilepas. Kalau ternyata tidak cocok, situs bisa kembali langsung ke origin tanpa dibongkar.

Kriteria terakhir sering terlupakan, padahal paling menenangkan: keputusan yang mudah dibatalkan lebih layak dicoba daripada keputusan yang mengikat.

Kapan CDN tidak diperlukan

Ada kondisi di mana menambah CDN hanya menambah lapisan tanpa memperbaiki apa pun:

• Pembaca hampir semuanya di satu wilayah, dan server berada di wilayah yang sama. Jarak yang ingin dipotong memang tidak ada.
• Situsnya statis dan sudah ringan. Kalau satu halaman hanya beberapa berkas kecil dan waktu muatnya sudah wajar, lapisan tambahan lebih banyak biaya perawatannya daripada manfaatnya.
• Halamannya hampir seluruhnya personal. Kalau tidak ada yang bisa dibagi antar pengunjung, cache tidak punya bahan.
• Situs internal di balik VPN. Pengunjung sudah dekat dengan server, dan membuka jalur publik justru menambah permukaan yang harus dijaga.
• Penyebab lambatnya belum diketahui. Kalau belum jelas bagian mana yang lambat, CDN bisa menutupi gejala, bukan menyembuhkan sebabnya. Ukur dulu.

Menimbang sebelum memutuskan

Saya tidak menyarankan CDN untuk semua situs, dan juga tidak menyarankannya sebagai jawaban otomatis atas setiap keluhan “lambat”. Yang lebih berguna adalah tiga pertanyaan sederhana sebelum memutuskan.

Pertama, dari mana keluhan itu datang — satu wilayah yang berulang, atau tersebar? Kalau berulang dari satu wilayah jauh, jarak hampir pasti ikut berperan. Kedua, apakah isi halaman sebagian besar sama untuk semua pengunjung? Kalau ya, ada banyak yang bisa disimpan di dekat mereka. Ketiga, bagian yang lambat itu waktu tunggu sebelum halaman muncul, atau setelah halaman tampil? Kalau yang kedua, masalahnya ada di browser dan kode, bukan di jalur.

Kalau jawabannya mengarah ke jarak dan isi yang bisa dibagi, CDN masuk akal. Kalau mengarah ke origin atau ke browser, uang dan waktu lebih baik dipakai di sana dulu.

Situs kecil tidak terasa berat karena kodenya banyak. Kadang ia hanya jauh.