DNS, CDN, dan Cache Browser: Kenapa Website Terasa Lambat Padahal Server Normal?

Website bisa terasa lambat walau server terlihat normal. CPU rendah, RAM aman, database cepat, tetapi user tetap mengeluh halaman lama terbuka. Kondisi ini sering terjadi karena perjalanan request dari browser ke server lebih panjang daripada yang terlihat di dashboard server.

Untuk memahami masalah seperti ini, kita perlu melihat jalur lengkap: DNS lookup, koneksi TCP, TLS handshake, CDN, cache browser, request API, sampai rendering frontend. Satu bagian kecil yang lambat bisa membuat seluruh halaman terasa berat.

DNS lookup: langkah pertama yang sering dilupakan

Sebelum browser menghubungi server, domain harus diterjemahkan menjadi alamat IP. Jika resolver DNS lambat, user merasakan delay bahkan sebelum request sampai ke server. TTL yang terlalu pendek bisa membuat lookup lebih sering. Konfigurasi DNS yang berantakan bisa menyebabkan user dari region tertentu diarahkan ke jalur yang kurang optimal.

Untuk debugging, cek waktu DNS dari beberapa jaringan. Bandingkan resolver ISP, Google DNS, Cloudflare DNS, dan jaringan mobile. Jika masalah hanya muncul di provider tertentu, sumbernya mungkin bukan aplikasi.

CDN: mempercepat sekaligus menambah lapisan

CDN membantu menyajikan asset statis dari lokasi yang lebih dekat ke user. Namun CDN juga bisa membuat debugging membingungkan. Cache yang belum purge, rule yang salah, atau edge server yang bermasalah bisa membuat user melihat file lama sementara developer merasa sudah deploy versi baru.

Gunakan versioning pada file CSS dan JavaScript. Untuk asset yang sering berubah, jangan hanya mengandalkan nama file yang sama. Tambahkan query version atau hash filename agar browser dan CDN tahu kapan harus mengambil file baru.

Browser cache dan service worker

Browser cache bisa membuat halaman sangat cepat, tetapi juga bisa menahan file lama. Service worker lebih kuat lagi karena bisa mengontrol request dari origin. Jika service worker tidak dirancang dengan strategi update yang jelas, user bisa terjebak memakai JavaScript lama walau server sudah punya versi baru.

Untuk aplikasi dashboard, hati-hati saat cache shell aplikasi. Jangan sampai user melihat UI lama yang memanggil API baru dengan kontrak berbeda. Pastikan ada mekanisme refresh atau update prompt ketika versi aplikasi berubah.

TLS dan koneksi awal

HTTPS membutuhkan handshake. Biasanya cepat, tetapi bisa terasa lambat jika jaringan buruk, sertifikat bermasalah, atau server tidak mendukung protokol modern dengan baik. HTTP/2 dan HTTP/3 bisa membantu, tapi konfigurasi yang salah tetap bisa membuat performa buruk.

API cepat, frontend tetap lambat

Kadang API merespons dalam 100 ms, tetapi halaman tetap terasa lambat karena frontend melakukan terlalu banyak request berurutan. Misalnya request profil selesai, baru request notifikasi, baru request order, baru request riwayat. Jika data tidak saling bergantung, jalankan paralel. Jika tidak semua data dibutuhkan di layar pertama, tunda sebagian.

Gunakan DevTools waterfall. Lihat request mana yang blocking, file mana yang besar, dan apakah JavaScript menunda rendering. Jangan menebak dari perasaan.

Debugging dari sisi user

Saat ada laporan lambat, minta informasi konkret: lokasi user, jaringan yang dipakai, device, browser, waktu kejadian, dan screenshot waterfall jika memungkinkan. Untuk aplikasi seperti OTPZap, informasi ini penting karena user bisa memakai web, Telegram, atau API. Masalah lambat di satu platform belum tentu terjadi di platform lain.

Checklist diagnosis

• Cek DNS timing dari beberapa resolver.
• Cek CDN cache status dan purge rule.
• Pastikan asset punya versioning.
• Audit service worker jika ada.
• Lihat waterfall browser, bukan hanya CPU server.
• Pisahkan lambat karena network dari lambat karena backend.