Mengapa Tiga Speed Test Memberi Tiga Angka yang Berbeda

Tiga jawaban, semuanya bisa dipertanggungjawabkan

Jalankan pengujian di tiga situs berbeda dalam satu menit dan Anda bisa melihat 300 Mbps, 180 Mbps, dan 90 Mbps. Godaannya adalah menganggap dua di antaranya rusak. Dalam praktiknya, masing-masing menjawab pertanyaan yang sedikit berbeda, dan sebaran di antara ketiganya membawa lebih banyak informasi daripada satu angka mana pun.

Satu mengukur seberapa besar kapasitas yang bisa dibawa jalur ketika sengaja dijenuhkan. Satu mengukur seberapa cepat sebuah unduhan di dunia nyata akan berjalan. Satu lagi mungkin mengukur jalur yang tidak pernah keluar dari jaringan penyedia Anda sendiri. Itu tiga besaran yang sah dengan tiga kegunaan yang sah.

Koneksi paralel mengubah plafonnya

Satu koneksi TCP butuh waktu untuk meningkat ke kapasitas penuh sebuah jalur. Buka delapan atau enam belas sekaligus dan masing-masing meningkat secara paralel, sehingga agregatnya mencapai plafon jauh lebih cepat — dan dalam pengujian yang singkat, perbedaan itu besar. Karena itu pengujian multi-thread biasanya melaporkan angka yang lebih tinggi, dan itulah alat yang tepat ketika pertanyaannya adalah “apakah saya mendapat kapasitas yang saya bayar.”

Pengujian single-thread melaporkan angka yang lebih rendah dan merupakan alat yang tepat ketika pertanyaannya adalah “seberapa cepat satu unduhan ini benar-benar akan berjalan.” Aliran video, unduhan game, file dari CDN, dan panggilan video semuanya praktis bersifat single-stream. Kesenjangan antara kedua metode bukanlah kesalahan pengukuran; itu adalah perbedaan antara angka kapasitas dan angka pengiriman.

Latency memperbesar efeknya. Semakin tinggi round-trip time, semakin lama sebuah koneksi menghabiskan waktu untuk meningkat, sehingga tautan berlatensi tinggi — satelit, sebagian fixed wireless, jalur internasional yang panjang — memperlihatkan sebaran terlebar antara hasil single-thread dan multi-thread.

Penempatan server menentukan jalur mana yang Anda ukur

Alat yang berbeda memakai jaringan server yang berbeda. Ada yang memilih endpoint terdekat yang tersedia, ada yang memakai content delivery network yang terikat ke layanan tertentu, dan ada yang memakai server yang di-host di dalam jaringan penyedia internet itu sendiri. Setiap pilihan mengukur jalur yang berbeda.

Pengujian ke server di dalam jaringan penyedia Anda tidak pernah melintasi interconnect, sehingga secara sah bisa melaporkan angka terbaik yang akan pernah Anda lihat — dan tidak mengatakan apa pun tentang bagaimana lalu lintas menjangkau layanan di luar jaringan itu. Pengujian terhadap CDN satu penyedia konten memberi tahu performa penyedia tersebut, bukan performa internet secara umum. Membandingkan dua alat dengan endpoint yang berbeda sama dengan membandingkan rute sekaligus koneksi.

Sumber kesalahan terbesar biasanya ada di lokal

Perbedaan metodologi paling menyita perhatian, tetapi dalam pengujian sehari-hari kesalahan terbesar datang dari lingkungan:

• Wi-Fi alih-alih Ethernet. Nirkabel menambah latency, jitter, dan variabilitas yang membesar seiring jarak, dinding, serta jumlah perangkat yang berbagi band. Pada paket yang cepat, pengujian berkabel dan nirkabel di ruang yang sama bisa berbeda jauh.
• Lalu lintas latar belakang. Sinkronisasi cloud, pembaruan sistem, patch game, atau aliran 4K milik orang lain menghabiskan kapasitas selama jendela pengujian.
• Ekstensi browser dan VPN. Keduanya berada di jalur dan bisa membatasi atau mengalihkan lalu lintas pengujian.
• Waktu. Pada koneksi dengan media bersama, pengujian yang sama pada pukul 10.00 dan 21.00 mengukur dua jaringan yang berbeda.

Membaca sebuah angka dengan konteks

Sebuah speed test mengukur satu jalur, ke satu server, pada satu momen, dengan satu metode transfer. Tes itu tidak membuktikan bahwa setiap situs akan memuat dengan cepat, bahwa sebuah server game akan terasa responsif, bahwa jaringan rumah dikonfigurasi dengan baik, atau bahwa kapasitas akan bertahan pada jam sibuk. Perlakukan sebuah hasil sebagai snapshot diagnostik dan anggap metodenya sebagai bagian dari hasil itu — sebuah angka tanpa kondisinya bukan sebuah pengukuran.

Perlu dipisahkan juga: throughput dan responsivitas itu independen. Sebuah jalur berkapasitas sangat tinggi dengan latency 200 ms ke CDN terdekat akan terasa lebih buruk untuk pekerjaan interaktif daripada jalur sederhana dengan 10 ms. Jika keluhannya adalah “rasanya lambat,” angka Mbps sering kali adalah angka yang paling tidak berguna di layar.

Rutinitas pengujian yang bisa diulang

Menstandardisasi kondisi lebih penting daripada alat mana yang Anda pilih.

1. Sambungkan lewat Ethernet bila memungkinkan. Jika harus memakai Wi-Fi, tetaplah di ruang yang sama dengan access point dan gunakan band 5 GHz atau 6 GHz.
2. Tutup semua yang memindahkan data — backup, klien sinkronisasi, pembaruan, streaming — baik di perangkat pengujian maupun di apa pun yang berbagi koneksi.
3. Uji dengan profil browser yang bersih, tanpa ekstensi, tanpa VPN.
4. Jalankan tiga pengujian dan ambil hasil yang ada di tengah, bukan yang terbaik.
5. Catat waktunya dalam sehari, lalu ulangi pada jam tersibuk yang biasa Anda pakai. Perbedaan keduanya adalah angka yang memprediksi pengalaman nyata Anda.
6. Jika dua layanan berbeda pendapat, uji keduanya terhadap server terdekat yang sama sebelum menyimpulkan bahwa jalurnya yang bermasalah.

Lakukan ini sekali pada menjelang siang dan sekali pada malam hari, dan Anda akan mendapat gambaran yang lebih akurat tentang koneksi Anda daripada yang bisa diberikan oleh satu angka utama mana pun.