Anda memuat situs web Anda — cepat. Tim Anda di kota yang sama mengonfirmasi — dengan cepat. Kemudian pengguna di Jerman mengirimkan email: "Situs Anda memerlukan waktu 12 detik untuk dimuat." Seorang pelanggan di Singapura men-tweet: "Checkout terus-menerus kehabisan waktu."
Situs web Anda tidak lambat di semua tempat. Lambat di suatu tempat — dan Anda tidak tahu di mana atau mengapa.
Anda telah menghabiskan waktu berbulan-bulan untuk mengoptimalkan situs web Anda. Skor Lighthouse tinggi. Data Web Inti berwarna hijau. CDN Anda sudah dikonfigurasi. SSL sudah diatur dengan benar.
Kemudian Anda mulai mendapat keluhan. Tidak dari semua orang — hanya dari wilayah tertentu. Pengguna di Brasil melaporkan waktu muat 8 detik. Pengguna di India tidak dapat menyelesaikan pembayaran. Pengguna di Australia mengatakan situs tersebut "terasa rusak".
Anda menguji dari laptop Anda — semuanya berfungsi. Anda menjalankan tes kecepatan — hasilnya terlihat bagus. APM Anda menunjukkan waktu respons yang sehat. Dasbor CDN Anda menunjukkan semua edge beroperasi.
Namun keluhan terus berdatangan. Dan Anda tidak memiliki cara untuk melihat apa yang sebenarnya dialami para pengguna tersebut.
Inilah realitas menjalankan situs web dengan pengguna internasional. Situs web Anda mungkin lambat di beberapa negara namun cepat di negara lain — dan kecuali Anda memantau dari negara-negara tersebut, Anda tidak akan pernah tahu sampai hal tersebut merugikan pendapatan Anda.
Internet bukanlah sebuah jaringan tunggal — ini merupakan gabungan dari ribuan sistem otonom, yang masing-masing memiliki kekhasan, perjanjian peering, dan mode kegagalannya sendiri.
Sebelum browser dapat terhubung ke server Anda, browser perlu menentukan nama domain Anda. Jika penyedia DNS Anda tidak memiliki node siaran apa pun di dekat lokasi pengguna, resolusi DNS saja dapat menambah 200–500 md untuk setiap pemuatan halaman.
Contoh: Seorang pengguna di Afrika Selatan yang menanyakan server DNS di Eropa menambahkan waktu pulang pergi 150 md+ — bahkan sebelum permintaan HTTP pertama dimulai.
BGP (Border Gateway Protocol) menentukan bagaimana paket melintasi internet. Perutean yang kurang optimal dapat mengirimkan lalu lintas dengan jalur memutar yang aneh — paket dari Brasil mungkin melewati Miami, lalu Amsterdam, sebelum mencapai server London Anda.
Contoh: Pengguna di São Paulo yang terhubung ke server Singapura Anda mungkin melihat latensi 400 ms karena perutean melalui Pantai Barat AS, bukan kabel bawah laut langsung.
CDN Anda mungkin memiliki 200 lokasi edge, namun tidak semuanya sama. Beberapa sisi kelebihan beban. Beberapa memiliki cache yang basi. Beberapa memiliki masalah konektivitas ke asal Anda. Halaman status CDN menyatakan "operasional" — tetapi pengguna Anda di Jakarta mengalami TTFB 5 detik.
Contoh: CDN edge di Manila menyajikan konten cache secara instan. Edge di Kota Ho Chi Minh memiliki cache yang hilang dan membuat pengambilan asal menjadi lambat setiap saat.
Beberapa ISP membatasi lalu lintas ke rentang IP atau penyedia hosting tertentu. Yang lain mempunyai titik pengamatan yang padat selama jam sibuk. Pengguna di satu ISP memuat situs Anda dalam 1 detik; pengguna di ISP lain di kota yang sama menunggu 10 detik.
Contoh: Pengguna Reliance Jio di India mengalami waktu muat 8 detik. Pengguna Airtel di kota yang sama mengalami 1,2 detik. Website sama, kota sama, ISP berbeda.
Kenyataan yang membuat frustrasi: Semua masalah ini tidak terlihat dari lokasi Anda. Server Anda cepat. Kode Anda dioptimalkan. CDN Anda dikonfigurasi dengan benar. Namun antara infrastruktur Anda dan pengguna tertentu, ada sesuatu yang menambah hitungan detik pada setiap permintaan — dan Anda hanya dapat mendeteksinya dengan memantau dari mana sebenarnya pengguna tersebut berada.
Alat pemantauan standar dirancang untuk mendeteksi pemadaman listrik — bukan penurunan kinerja regional.
Sebagian besar alat pemantau kecepatan situs web memeriksa dari 3–10 lokasi, yang sebagian besar terkonsentrasi di AS dan Eropa Barat. Jika pengguna Anda berada di Asia Tenggara, Amerika Latin, Timur Tengah, atau Afrika — Anda tidak tahu apa-apa.
Menjalankan pemeriksaan sintetis dari wilayah AWS atau GCP tidak mewakili hal tersebut. Konektivitas cloud-to-cloud seringkali lebih baik dibandingkan jalur jaringan perumahan atau perusahaan. Pemantauan Anda menunjukkan 200 ms; pengalaman pengguna nyata 2.000ms.
Mengetahui suatu halaman "lambat" tidaklah cukup. Apakah itu DNS? koneksi TCP? jabat tangan TLS? Waktunya ke byte pertama? Pengunduhan konten? Tanpa rincian latensi, Anda tidak dapat mendiagnosis apakah masalahnya ada pada server Anda, CDN Anda, atau jalur jaringan.
Ketika ada masalah perutean atau kehilangan paket di jalur, Anda memerlukan data traceroute dan MTR untuk mengidentifikasi di mana paket tertunda atau dijatuhkan. Sebagian besar alat pemantauan tidak menawarkan hal ini — jadi Anda tidak dapat membuktikan kepada CDN atau penyedia hosting Anda di mana letak masalahnya.
Jika Anda hanya memantau dari 10 lokasi, Anda melihat kurang dari 10% pengalaman pengguna. 90% lainnya mungkin mengalami kenyataan yang sama sekali berbeda.
Situs web yang lambat di beberapa negara bukan hanya masalah kecil — namun merupakan masalah bisnis.
Pengguna yang mengalami waktu muat lambat tidak mengeluh — mereka pergi. Penundaan 3 detik meningkatkan rasio pentalan sebesar 32%. Penundaan 5 detik meningkatkannya sebesar 90%. Pengguna ini tidak pernah muncul di analisis Anda karena mereka tidak pernah selesai memuat kode pelacakan Anda.
Jika laman checkout Anda membutuhkan waktu 10 detik untuk dimuat di Jerman, Anda kehilangan pelanggan di Jerman. Jika formulir pendaftaran Anda habis di India, Anda kehilangan populasi internet terbesar kedua di dunia. Ini bukanlah kasus yang sulit – ini adalah keseluruhan pasar yang secara tidak sengaja Anda abaikan.
Google merayapi dari beberapa lokasi global. Jika Googlebot mengalami waktu muat yang lambat di wilayah tertentu, Data Web Inti Anda akan terganggu, anggaran perayapan menurun, dan peringkat turun — tidak secara global, namun di pasar tertentu. Anda melihat lalu lintas menurun dan tidak tahu alasannya.
Berita menyebar. “Layanan itu tidak dapat digunakan di Asia.” "Jangan repot-repot, itu tidak pernah berhasil dari Eropa." Postingan forum, tweet, dan komentar situs ulasan menciptakan persepsi yang sulit untuk diubah — terutama ketika Anda bahkan tidak mengetahui adanya masalah.
Mendiagnosis masalah kinerja regional memerlukan tiga hal: cakupan global, kedalaman diagnostik, dan konteks historis.
Jangan hanya memantau dari "Asia" — monitor dari Tokyo, Singapura, Mumbai, Jakarta, Sydney. Jangan hanya memantau dari "Eropa" — monitor dari Frankfurt, London, Amsterdam, Warsawa, Stockholm. Setiap lokasi menunjukkan jalur jaringan yang berbeda dan potensi hambatan.
Cocokkan lokasi pemantauan Anda dengan lokasi sebenarnya pengguna Anda.
Ukur setiap fase: pencarian DNS, jabat tangan TCP, negosiasi TLS, waktu hingga byte pertama, transfer konten. Ketika suatu halaman lambat, Anda akan tahu persis fase mana yang menjadi penyebabnya — dan apakah itu sesuatu yang dapat Anda perbaiki atau masalah jaringan upstream.
"Lambat" tidak jelas. "DNS 500 md + TTFB 200 md" dapat ditindaklanjuti.
Ketika suatu wilayah lambat, traceroute menunjukkan dengan tepat hop jaringan mana yang menambahkan latensi. Perbandingan historis memberi tahu Anda apakah ini merupakan perilaku baru atau selalu seperti ini. Bersama-sama, keduanya membantu Anda menentukan apakah ini masalah sementara atau masalah perutean permanen.
Data Traceroute adalah bukti Anda saat melakukan eskalasi ke penyedia.
Pendekatan langkah demi langkah untuk mengidentifikasi mengapa situs web Anda lambat di beberapa negara namun cepat di negara lain.
Ambil data dari Google Analytics, Cloudflare, atau log server Anda. Identifikasi 10 negara dan kota teratas asal pengguna Anda. Ini adalah lokasi yang harus Anda pantau.
Gunakan layanan pemantauan yang memeriksa dari 50+ lokasi dan menyediakan waktu per fase (DNS, TCP, TLS, TTFB). Tanpa perincian ini, Anda akan mengetahui ada sesuatu yang lambat tetapi tidak tahu apa atau mengapa.
Saat Anda mengidentifikasi wilayah yang lambat, jalankan traceroute dan MTR untuk melihat jalur jaringan. Carilah lompatan latensi tinggi, kehilangan paket, atau perutean yang tidak biasa. Data ini memberi tahu Anda apakah masalahnya ada pada CDN Anda, asal Anda, atau tulang punggung internet.
Verifikasi bahwa CDN Anda benar-benar menyajikan konten dari edge terdekat. Periksa rasio cache hit per wilayah. Hilangnya cache berarti pengambilan asal yang lambat. Beberapa sisi mungkin salah dikonfigurasi atau kelebihan beban.
Jika resolusi DNS lambat di wilayah tertentu, penyedia DNS Anda mungkin tidak memiliki node siaran mana pun di dekatnya. Pertimbangkan penyedia DNS dengan cakupan global yang lebih baik, atau tambahkan penyedia sekunder untuk redundansi.
Saat menghubungi CDN, penyedia hosting, atau layanan DNS Anda tentang masalah regional, bawalah data traceroute, rincian waktu, dan grafik historis. "Di Singapura lambat" diabaikan. "Inilah traceroute selama 30 hari yang menunjukkan lompatan 400ms di tepi Anda" mendapat tindakan.
Konfigurasikan peringatan untuk wilayah tertentu yang memberi tahu Anda ketika latensi melebihi ambang batas atau ketersediaan menurun. Anda tidak memerlukan peringatan downtime global — Anda memerlukan peringatan degradasi spesifik wilayah.
Luangkan 10 menit setiap minggu untuk meninjau tren kinerja regional. Degradasi yang lambat tidak terlihat secara real-time namun terlihat jelas dalam grafik historis. Catch problems before they compound.
Latency Global dibuat khusus untuk memecahkan masalah "lambat di beberapa negara, cepat di negara lain". Kami memantau dari 70+ lokasi nyata di 6 benua — bukan hanya wilayah cloud, namun titik pandang jaringan sebenarnya yang mencerminkan pengalaman pengguna sebenarnya.
Setiap pemeriksaan mencakup perincian latensi penuh: DNS, TCP, TLS, TTFB. Anda dapat menjalankan traceroute dan MTR sesuai permintaan dari lokasi mana pun. Data historis memungkinkan Anda membandingkan kinerja saat ini dengan data dasar. Dan biayanya $5/bulan — bukan $200–$500 yang biasanya dijalankan oleh pemantauan global perusahaan.
Pemantauan global memerlukan biaya yang mahal untuk dioperasikan — itulah sebabnya sebagian besar alat membatasi lokasi. Kami menjaga harga tetap rendah dengan melayani pelanggan yang membayar, bukan mempertahankan tingkatan gratis.
Penyebab paling umum adalah: latensi resolusi DNS (penyedia DNS Anda tidak memiliki server di dekat pengguna tersebut), perutean BGP yang kurang optimal (paket mengambil jalur yang tidak efisien), masalah kinerja edge CDN (cache hilang atau edge kelebihan beban), dan pembatasan atau kemacetan ISP regional. Satu-satunya cara untuk mengidentifikasi penyebab masalah spesifik Anda adalah dengan memantau dari lokasi tersebut dengan rincian latensi penuh dan data traceroute.
Tes satu kali memberi Anda gambaran singkat, namun kinerja bervariasi sepanjang hari. Anda memerlukan pemantauan berkelanjutan untuk mengetahui permasalahan yang terjadi secara berkala, mengidentifikasi pola (misalnya, perlambatan selama jam sibuk di wilayah tertentu), dan membangun data dasar historis. Tes kecepatan gratis juga tidak akan memberi Anda rincian latensi atau data traceroute untuk mendiagnosis penyebab utama.
"Operasional" tidak berarti "optimal". Edge dapat beroperasi tetapi: memiliki rasio cache hit yang rendah (memaksa pengambilan asal), kelebihan beban selama jam sibuk, memiliki konten yang basi atau salah dikonfigurasi, atau memiliki konektivitas yang buruk ke ISP tertentu. Pemantauan independen dari luar CDN Anda memberi Anda kebenaran dasar yang tidak ditampilkan oleh dasbor CDN.
Lihatlah rincian latensi. Jika TTFB (Time to First Byte) tinggi tetapi DNS/TCP/TLS normal, masalahnya ada di server asal Anda. Jika jabat tangan DNS atau TCP tinggi, masalahnya ada di server Anda. Traceroute menunjukkan dengan tepat hop jaringan mana yang menambahkan latensi — apakah itu penyedia hosting Anda, jaringan transit, atau ISP.
Anda mungkin tidak dapat memperbaiki masalah tingkat ISP secara langsung, namun Anda dapat: (1) memverifikasi bahwa itu bukan infrastruktur Anda, (2) mendokumentasikan masalah untuk pelanggan yang terpengaruh, (3) menjelajahi tepi CDN alternatif yang rutenya berbeda, (4) menambahkan server asal di wilayah dengan masalah yang terus-menerus, atau (5) menghubungi tim jaringan penyedia hosting Anda dengan bukti traceroute untuk mengeksplorasi perubahan peering.
Untuk situs web produksi dengan pengguna internasional, interval pemeriksaan 1 menit adalah waktu yang ideal. Ini menangkap masalah yang terputus-putus dan memberi Anda poin data yang cukup untuk analisis tren yang bermakna. Interval 5 menit dapat diterima untuk halaman yang kurang kritis, namun Anda akan melewatkan masalah berdurasi pendek.
Berhentilah menebak mengapa situs web Anda lambat di beberapa negara. Tambahkan URL Anda, pilih lokasi pemantauan Anda, dan dapatkan visibilitas tentang apa yang sebenarnya dialami oleh pengguna global Anda — sebelum mereka mengirimkan email tentang hal tersebut kepada Anda.
$5/bulan • Tanpa kontrak • Batalkan kapan saja