Dampak kecepatan website terhadap bisnis muncul di laporan keuangan, entah ada yang mengukurnya atau tidak. Halaman checkout yang butuh enam detik untuk terbuka bukan sekadar gangguan teknis, itu adalah persentase pelanggan yang menutup tab sebelum sempat membayar. Tools pemesanan internal yang butuh empat detik per layar bukan gangguan kecil, itu satu jam sehari per karyawan yang habis menatap ikon loading. Kecepatan bukan urusan preferensi developer. Itu adalah item di laporan laba rugi.
Saya pernah melihat pemilik bisnis menyetujui budget marketing enam digit untuk mendatangkan traffic ke website yang belum pernah diuji bebannya, lalu bertanya-tanya kenapa konversi tidak bergerak. Traffic-nya datang. Cuma tidak betah menunggu.
Kecepatan yang dilihat pelanggan: setiap detik adalah titik keputusan
Hubungan antara waktu loading dan konversi bukan linear, tapi seperti jurang. Studi dari Google dan berbagai platform ecommerce selama bertahun-tahun menunjukkan pola yang sama: bounce rate melonjak tajam begitu waktu loading halaman melewati sekitar tiga detik, dan terus naik setelahnya. Di bawah tiga detik, pengguna nyaris tidak menyadari. Di atasnya, setiap detik tambahan menggerus jumlah pengunjung yang benar-benar terukur, yang begitu saja pergi.
Untuk bisnis ecommerce atau jasa di Indonesia, ini lebih krusial dibanding pasar dengan koneksi internet yang serba cepat. Porsi signifikan traffic Anda ada di data seluler, kadang 4G dengan sinyal lemah, kadang throttled setelah kuota habis. Situs yang terasa cukup cepat saat dites di wifi kantor bisa jadi tidak terpakai di koneksi yang dipakai pelanggan Anda yang sebenarnya, jam 9 malam dari rumah.
Coba dua tes ini sendiri, hari ini, tanpa perlu developer:
- Buka situs Anda pakai data seluler, bukan wifi. Matikan wifi di HP, buka halaman utama dan halaman checkout. Hitung waktunya pakai stopwatch. Kalau butuh lebih dari empat atau lima detik, Anda kehilangan pengunjung.
- Pakai Google PageSpeed Insights. Tempel URL Anda, tools gratis, tanpa perlu akun. Hasilnya berupa skor mobile dan penyebab spesifiknya, biasanya gambar yang kebesaran atau terlalu banyak script pihak ketiga.
Kecepatan tools internal menumpuk diam-diam
Kecepatan yang dilihat pelanggan menggagalkan penjualan yang setidaknya bisa Anda perkirakan. Kecepatan tools internal menghabiskan waktu yang jarang sekali dihitung, dan justru karena itu biayanya lebih besar dalam setahun.
Ambil contoh staf gudang atau admin yang memakai sistem internal lima puluh kali sehari, tiap layar butuh tiga detik ekstra dibanding seharusnya. Itu dua setengah menit sehari, per orang, cuma untuk menunggu. Kalikan dengan dua puluh staf dan jumlah hari kerja setahun, hasilnya kira-kira 180 jam waktu tunggu murni, mendekati satu bulan penuh waktu kerja satu orang, habis menatap ikon loading. Tidak ada yang memasukkan angka ini ke budget, tapi itu nyata, dan sepenuhnya bisa diperbaiki oleh perusahaan.
Biaya lainnya bersifat perilaku, bukan cuma waktu. Tools internal yang lambat melatih staf untuk mencari jalan pintas, menyimpan data di spreadsheet pribadi karena sistemnya terlalu lambat untuk dicek ulang, melewati langkah validasi karena menunggu terasa tidak tertahankan saat tekanan akhir hari. Ini sering jadi akar masalah sesungguhnya di balik bisnis yang sudah kelewat besar untuk spreadsheet: sistem resminya terlalu lambat untuk dipercaya, jadi orang diam-diam membangun sistem bayangan yang lebih cepat di sampingnya.
Di mana kecepatan sebenarnya hilang
Masalah performa berkumpul di segelintir titik, dari pengalaman saya menangani bisnis ritel, keuangan, dan jasa:
- Gambar yang tidak dioptimalkan. Foto produk langsung dari kamera HP bisa mencapai 8MB. Dikompres dan diubah ukurannya dengan benar, gambar yang sama terlihat identik di 150KB. Perbaikan tunggal ini sering menjadi penyebab utama halaman yang lambat.
- Terlalu banyak script pihak ketiga. Pixel marketing, widget chat, tools analitik, masing-masing menambah satu request jaringan sebelum halaman bisa dipakai. Audit apa saja yang benar-benar terpasang, kebanyakan situs menumpuk script yang tidak ada yang ingat pernah memasangnya.
- Query database tanpa indexing. Untuk tools internal, layar laporan yang memindai seluruh tabel alih-alih memakai index bisa jadi perbedaan antara setengah detik dan delapan detik, dan makin parah seiring data Anda bertambah, artinya tools yang terasa baik-baik saja saat diluncurkan jadi tak tertahankan setahun kemudian.
- Tidak ada caching untuk konten yang dilihat berulang. Dashboard yang dibangun ulang dari nol setiap kali dibuka, padahal data dasarnya baru berubah satu jam lalu, adalah komputasi yang terbuang di setiap klik.
Mobile lebih penting dari yang ditunjukkan dashboard Anda
Dashboard analitik sering meremehkan masalah mobile, karena sesi yang paling lambat justru yang paling mungkin bounce sebelum script analitiknya sendiri selesai dimuat. Pengunjung dengan koneksi lemah yang menyerah setelah empat detik mungkin tidak pernah tercatat sebagai sesi penuh sama sekali, artinya metrik rata-rata waktu loading Anda secara diam-diam bias ke pengunjung yang bertahan, bukan yang hilang. Kalau mau data yang jujur, tes manual di koneksi yang di-throttle, jangan percaya begitu saja angka agregat di dashboard.
Kecepatan sebagai item budget, bukan renungan belakangan
Langkah praktisnya adalah memperlakukan performa sebagai metrik yang dicek tiap kuartal, sama seperti Anda mengecek revenue atau churn. Tetapkan angkanya: waktu loading mobile saat ini, rata-rata waktu layar tools internal saat ini. Lalu mintai pertanggungjawaban siapa pun yang mengelola sistem untuk menjaga angka itu tetap stabil atau membaik, terutama sebelum peluncuran fitur apa pun, karena fitur justru yang diam-diam membuat sistem yang tadinya cepat jadi lambat lagi. Kalau tim engineering atau vendor Anda tidak bisa memberi tahu angka kecepatan halaman Anda saat ini, itu sendiri sudah menjadi temuan, dan layak diangkat sebelum proyek berikutnya dimulai.