Website Lambat Cuma dari IndiHome atau Telkomsel? Pertanyaan Pertama ke Pelanggan

Laporan 'website saya lambat' hampir selalu datang tanpa konteks. Setelah ditanya sedikit, sering muncul detail yang jauh lebih berguna: lambatnya cuma kalau dibuka dari IndiHome, atau cuma dari paket data Telkomsel, sementara dari WiFi kantor atau provider lain normal. Detail ini petunjuk paling berharga, karena server yang sama tidak mungkin sengaja lambat untuk satu ISP saja. Yang berbeda adalah jalur yang ditempuh request sebelum sampai ke server. Artikel ini membahas apa saja yang terjadi di jalur itu, lalu pertanyaan mana yang paling cepat mempersempit penyebabnya.

Apa saja yang terjadi sebelum halaman pertama muncul

Satu kali buka halaman sebenarnya terdiri dari beberapa tahap, dan tiap tahap bergantung pada hal yang berbeda. Pertama, DNS. Browser bertanya ke resolver (biasanya resolver milik ISP, kecuali pelanggan pakai resolver publik) untuk menerjemahkan nama domain jadi alamat IP. Kalau website pakai CDN, IP yang dikembalikan bisa berbeda tergantung siapa yang bertanya. CDN memakai informasi seperti lokasi resolver untuk memilih edge (server CDN terdekat) yang dianggap paling dekat. Artinya, pelanggan IndiHome dan pelanggan provider lain di kota yang sama bisa diarahkan ke edge yang berbeda. Kedua, TCP handshake. Klien kirim paket SYN, server membalas SYN-ACK, klien membalas ACK. Butuh satu kali bolak-balik (round trip) penuh sebelum data apa pun boleh dikirim. Kalau jalurnya jauh atau padat, tahap ini langsung terasa. Ketiga, TLS handshake untuk HTTPS. Klien dan server bertukar sertifikat dan menyepakati kunci enkripsi. Tergantung versi TLS, ini menambah satu atau dua round trip lagi. Keempat, request HTTP. Di sini ada percabangan penting. Kalau request mendarat di edge CDN dan kontennya ada di cache, edge langsung menjawab. Kalau tidak ada (cache MISS), edge membuka koneksi sendiri ke origin, yaitu server asli tempat website di-hosting, mengambil kontennya, lalu meneruskannya ke klien. Yang sering terlewat: koneksi edge ke origin adalah jalur kedua yang terpisah, dengan routing dan kondisi jaringannya sendiri. Pelanggan cuma melihat satu angka 'lambat', padahal penyebabnya bisa di salah satu dari dua jalur ini.

Kenapa satu ISP bisa punya jalur sendiri

Internet terdiri dari banyak jaringan independen yang disebut Autonomous System (AS). ISP, penyedia hosting, dan CDN masing-masing punya AS sendiri. Antar-AS saling mengumumkan rute lewat protokol BGP, dan tiap AS memilih jalur keluar berdasarkan kebijakan bisnisnya, bukan semata jarak fisik terdekat. Ada dua cara umum dua jaringan terhubung. Peering berarti dua jaringan terhubung langsung, sering lewat internet exchange (titik pertukaran trafik bersama). Transit berarti satu jaringan membayar jaringan lain untuk membawa trafiknya ke tujuan. Kalau ISP pelanggan dan penyedia hosting punya peering di exchange domestik, trafik bisa tetap di dalam negeri. Kalau tidak, trafik bisa keluar lewat transit, kadang berputar ke luar negeri dulu sebelum kembali ke server yang lokasinya sebenarnya di Indonesia. Operator besar di Indonesia biasanya membangun interkoneksi domestik semacam ini. Contohnya, Telkom disebut menghubungkan jaringannya langsung dengan content provider lewat ekosistem pertukaran internet domestik seperti IIX untuk memangkas jumlah hop. Tapi dari sisi kita sebagai pengelola server, detail peering itu tidak terlihat dan bisa berubah kapan saja. Yang bisa kita lihat hanya efeknya di traceroute. Dua pola yang sering jadi penyebab lambat per ISP:

Link interkoneksi antara ISP dan jaringan tujuan penuh di jam sibuk. Gejalanya: lambat malam hari, normal pagi.
Routing asimetris. Paket pergi lewat satu jalur, balasannya pulang lewat jalur lain. Traceroute dari sisi pelanggan hanya menunjukkan jalur pergi, jadi bisa terlihat bersih padahal masalahnya di jalur pulang.

Soal DNS, resolver ISP juga menyimpan cache jawaban sesuai TTL. Kalau baru ganti IP atau CDN, pelanggan ISP tertentu bisa masih diarahkan ke tujuan lama. Mekanismenya dibahas di Kenapa Website Masih ke Server Lama Padahal TTL Sudah Diturunkan.

Cache HIT di satu edge belum tentu HIT di edge lain

Cache CDN biasanya disimpan per edge atau per PoP (Point of Presence, lokasi fisik tempat server CDN berada). Halaman yang sudah HIT di edge Jakarta belum tentu ada di edge lain. Kalau pelanggan ISP tertentu dipetakan ke edge yang jarang dikunjungi, mereka lebih sering kena MISS, dan setiap MISS berarti edge harus mengambil ke origin dulu. Kombinasi yang sering membingungkan: pelanggan dipetakan ke edge yang jaraknya dekat, tapi edge itu punya jalur yang buruk ke origin. Dari sisi pelanggan, ping ke domain terlihat cepat karena ping hanya sampai edge. Tapi halaman tetap lambat karena HTML diambil dari origin lewat jalur yang padat. Perlu diingat juga, banyak konfigurasi CDN tidak meng-cache HTML dinamis, terutama halaman dengan cookie login atau keranjang belanja. Untuk request seperti ini statusnya BYPASS atau sejenisnya, dan setiap request selalu sampai ke origin. Jadi 'sudah pakai CDN' tidak otomatis berarti semua request dilayani dari cache.

Urutan pertanyaan ke pelanggan

Tujuannya bukan mengumpulkan data sebanyak mungkin, tapi memotong kemungkinan secepat mungkin. Urutan yang biasanya paling efisien:

ISP apa dan jenis koneksinya (fixed broadband atau seluler)? Lalu minta satu pembanding: buka website yang sama lewat hotspot dari provider lain. Kalau dari provider lain normal, server dan aplikasi hampir pasti bukan penyebab utama.
Lambat di semua halaman atau hanya bagian tertentu (gambar, halaman checkout, wp-admin)? Dan jam berapa terasa paling lambat? Pola jam sibuk mengarah ke kepadatan jalur.
Domain di-resolve ke IP berapa dari koneksi itu? Di Windows bisa pakai nslookup, di Linux atau macOS pakai dig. Ini memberi tahu apakah pelanggan diarahkan ke edge CDN, ke origin langsung, atau ke IP lama.
Hasil traceroute atau mtr ke domain.
Header respons dan breakdown waktu request, kalau pelanggannya cukup teknis atau ada tim IT.

Untuk poin 5, perintah ini memecah waktu request per tahap:

BASH

curl -o /dev/null -s -w 'dns: %{time_namelookup}
connect: %{time_connect}
tls: %{time_appconnect}
ttfb: %{time_starttransfer}
total: %{time_total}
' https://example.com/

Semua angka adalah waktu kumulatif sejak request dimulai, dalam detik. Selisih connect dengan dns kira-kira sama dengan satu round trip ke server yang dituju. Selisih ttfb (time to first byte) dengan tls adalah waktu tunggu sampai byte pertama jawaban datang, termasuk proses di server dan, kalau MISS, perjalanan edge ke origin. Untuk melihat apakah request dilayani dari cache:

BASH

curl -sI https://example.com/ | grep -iE 'cache|age|server|via'

Nama header tergantung CDN. Ada yang memakai header khusus berisi HIT, MISS, atau BYPASS, ada yang memakai x-cache, dan header age menunjukkan sudah berapa lama objek tersimpan di cache. Jalankan dua sampai tiga kali berturut-turut. Kalau terus MISS untuk aset statis, cache tidak bekerja seperti yang diharapkan. Untuk jalur jaringan, mtr lebih informatif daripada traceroute biasa karena mengirim banyak probe dan merangkum loss serta latensi tiap hop:

BASH

mtr -rwzc 50 example.com

Flag -r untuk mode laporan, -w untuk nama host lengkap, -z untuk menampilkan nomor AS tiap hop, dan -c 50 untuk jumlah probe. Pengguna Windows bisa pakai tracert atau pathping sebagai gantinya. Kolom AS di sini membantu melihat di jaringan mana trafik berpindah tangan, misalnya dari AS milik ISP ke AS transit lalu ke AS penyedia hosting.

Membaca hasilnya tanpa salah tafsir

Beberapa jebakan yang sering bikin diagnosis melenceng. Packet loss di hop tengah belum tentu masalah. Router di tengah jalan sering memberi prioritas rendah untuk membalas probe traceroute karena itu dikerjakan oleh CPU router, bukan jalur forwarding. Loss baru bermakna kalau berlanjut sampai hop terakhir. Kalau hop 6 menunjukkan loss tinggi tapi hop 7 sampai tujuan bersih, hop 6 hanya malas membalas probe. Lonjakan latensi yang menetap mulai hop tertentu dan terbawa sampai tujuan biasanya menunjukkan titik masalah, misalnya saat trafik berpindah ke jaringan transit atau keluar negeri. Lompatan besar di perpindahan AS layak dicatat. Ping cepat tidak berarti website cepat. Ping ke domain ber-CDN hanya mengukur jarak ke edge. Gabungkan dengan breakdown curl: kalau connect kecil tapi ttfb besar dan status cache MISS, fokuskan ke jalur edge ke origin atau ke performa origin itu sendiri. Kalau connect sudah besar, masalahnya di jalur pelanggan ke edge. Kalau pelanggan langsung ke origin tanpa CDN dan hanya ISP tertentu yang lambat, kita bisa menjalankan mtr balik dari server ke IP publik pelanggan. Ini menunjukkan jalur pulang, yang sering berbeda dari jalur pergi. Perbandingan dua arah ini biasanya bukti paling kuat saat perlu eskalasi ke upstream hosting atau ke ISP. Di meja support, pola yang sering muncul adalah tim langsung memeriksa beban CPU, slow query, atau plugin WordPress, padahal pembanding sederhana lewat hotspot provider lain sudah cukup untuk menunjukkan bahwa server tidak sedang bermasalah. Memeriksa server tetap perlu, tapi setelah tahu di sisi mana masalahnya berada. Jadi, saat laporan lambat menyebut nama ISP, anggap itu petunjuk jalur, bukan detail sampingan. Minta pembanding dari provider lain, cek IP hasil resolve, lihat status cache di header, lalu pecah waktu request dengan curl. Dari empat hal itu biasanya sudah jelas apakah masalahnya di jalur pelanggan ke edge, di cache CDN, di jalur edge ke origin, atau memang di server kita sendiri.