Sebuah playground Python berbasis browser yang menyertakan runtime sebesar 5,5 MB mulai mengalami kegagalan tanpa peringatan bagi pengguna dengan koneksi lambat. Penyebabnya adalah penyalahgunaan Network Information API dan dashboard pengelompokan error yang salah melabeli masalah tersebut. Bug ini tersembunyi selama berminggu-minggu, membuang waktu pengembang, dan membuat sebagian pengguna tidak dapat menjalankan kode.

Bagaimana masalah tersebut muncul

Pelacak error playground tersebut menampilkan satu pesan yang mencolok: “undefined is not an object.” Judul tersebut menyiratkan adanya kesalahan pengetikan JavaScript yang sederhana, sehingga tim mengejar jalur kode yang sebenarnya tidak ada. Ketika mereka memeriksa metadata mentah, mereka melihat bahwa 89% dari insiden tersebut sebenarnya adalah timeout jaringan. Dashboard tersebut mengambil error pertama yang masuk dan menggunakannya untuk menamai seluruh batch, sehingga menutupi jenis kegagalan yang sebenarnya.

Pelajaran 1 – Judul dashboard bisa menipu

Dashboard yang mengagregasi insiden hanya akan membantu jika logika agregasinya mencerminkan penyebab nyata dari setiap peristiwa. Dalam kasus ini, pengelompokan berdasarkan lokasi, alih-alih berdasarkan penyebab error, memberikan gambaran yang salah tentang bug di sisi klien. Pelajarannya: jangan pernah memperbaiki masalah hanya berdasarkan tajuk dashboard. Ambil sampel dari peristiwa yang mendasarinya dan verifikasi apa yang sebenarnya terjadi sebelum Anda mengalokasikan sumber daya.

Pelajaran 2 – Nilai placeholder bukanlah pengukuran

Untuk menghindari pemuatan runtime yang berat bagi pengguna dengan koneksi lambat, kode tersebut merujuk pada Network Information API dan membaca properti downlink, yang melaporkan megabit per detik. Pada kunjungan pertama, Chrome sering kali mengembalikan placeholder alih-alih pengukuran aktual. Logika tersebut menganggap placeholder itu sebagai koneksi cepat dan melewatkan optimasi, yang secara efektif justru menghalangi pengguna yang seharusnya dibantu.

Perlakukan nilai default atau sentinel apa pun sebagai "tidak ada data." Sebuah placeholder harus memicu strategi fallback, bukan diinterpretasikan sebagai pembacaan kecepatan yang nyata.

Pelajaran 3 – Kondisi jaringan berubah, jadi satu snapshot saja tidak dapat diandalkan

Setelah masalah downlink teratasi, tim beralih ke pemeriksaan effectiveType, yang mengategorikan koneksi sebagai “4g”, “3g”, dll. Uji coba lab singkat berhasil, tetapi uji coba yang sama saat dijalankan kembali beberapa saat kemudian gagal. Koneksi seluler berfluktuasi; seorang pengguna bisa saja berada di jaringan 4G yang cepat pada satu detik, lalu turun ke 3G yang lebih lambat di detik berikutnya. Memeriksa koneksi hanya pada saat pemuatan halaman adalah sebuah spekulasi.

Pendekatan yang tepat adalah dengan berlangganan (subscribe) ke event change pada objek Network Information dan bereaksi terhadap setiap perubahan bandwidth, alih-alih membuat keputusan sekali jalan.

Apa yang diubah oleh tim

  • Unduhan dua tahap – Runtime sekarang dimulai dengan file bootstrap yang sangat kecil. Jika koneksi teridentifikasi lambat, bootstrap akan mengambil sisa runtime dalam potongan-potongan kecil, sehingga mengurangi kemungkinan pembatalan unduhan secara keseluruhan.
  • Pemantauan langsung – Alih-alih hanya satu kali pembacaan downlink, kode sekarang mendengarkan event change dan menyesuaikan strategi unduhan secara langsung (on the fly).
  • Pemilihan sumber yang stabil – Sebelumnya, sistem berpindah CDN di tengah unduhan ketika endpoint yang lebih cepat muncul. Pada koneksi lambat, hal ini menyebabkan unduhan harus diulang dari nol, yang justru memperburuk masalah. Logika baru sekarang mengunci sumber selama durasi unduhan.
  • Penulisan cache yang ditunda – Operasi cache berat yang sebelumnya berjalan sebelum aplikasi dapat digunakan, kini ditunda hingga runtime dimulai, guna membebaskan bandwidth untuk unduhan yang kritis.

Dampak yang lebih luas

Bagi pengembang yang membangun alat berbasis web, variabilitas jaringan adalah perhatian utama. Kegagalan tanpa peringatan pada koneksi lambat membuat pengguna frustrasi dan mengacaukan telemetri, yang akhirnya menggiring tim ke jalur debugging yang salah. Dalam kasus ini, salah menafsirkan data menyebabkan investigasi yang sia-sia selama berminggu-minggu.

Apa yang perlu diperhatikan selanjutnya

Intisari: Ketika data terlihat terlalu bersih, kemungkinan itu adalah placeholder; ketika tajuk dashboard menunjukkan satu bug tunggal, gali lebih dalam; dan ketika Anda mendasarkan keputusan pada pembacaan jaringan satu kali, Anda sedang bertaruh pada target yang terus bergerak. Menyesuaikan diri dengan realitas ini akan mengubah kegagalan tanpa peringatan menjadi peristiwa yang dapat diprediksi dan dipulihkan.