Website lambat di HP perlu diperiksa berdasarkan gejalanya: konten utama terlambat muncul, tombol lambat merespons, atau tata letak bergeser ketika halaman dimuat. Penyebabnya dapat berbeda, sehingga mengganti hosting sebelum pemeriksaan belum tentu menyelesaikan keluhan pelanggan.
Mulai dari halaman yang digunakan untuk mendapat permintaan atau pesanan. Catat alamat halaman, perangkat, jaringan, dan langkah yang terasa lambat. Informasi ini membuat developer dapat mengulang masalah yang sama dan mengukur hasil perbaikannya.
Catat gejala yang benar-benar dialami
Contoh hipotetis: pengunjung membuka halaman jasa melalui ponsel. Judul muncul cukup cepat, tetapi gambar utama lama kosong. Setelah gambar tampil, tombol konsultasi berpindah ke bawah dan sulit ditekan. Ini memberi dua petunjuk berbeda, yaitu waktu tampil konten utama dan kestabilan tata letak.
Coba halaman yang sama melalui jaringan lain dan bandingkan dengan halaman lain di website Anda. Jika masalah hanya terlihat pada satu gambar atau satu templat, catat perbedaannya. Pengujian ini membantu mempersempit pemeriksaan, meski belum cukup untuk menetapkan penyebab teknis.
Baca PageSpeed Insights sebagai alat diagnosis
Masukkan URL ke PageSpeed Insights, lalu periksa hasil mobile. Menurut dokumentasi PageSpeed Insights, alat ini memakai data lapangan dan pengujian laboratorium. Data lapangan berasal dari pengalaman pengguna Chrome yang memenuhi syarat, sedangkan pengujian laboratorium berjalan dalam kondisi simulasi untuk membantu menemukan masalah.
Data lapangan merangkum periode 28 hari. Jika data URL belum mencukupi, PageSpeed Insights dapat menampilkan data origin, yaitu seluruh situs. Jika data origin juga belum mencukupi, data pengguna nyata tidak ditampilkan. Ketiadaan data tersebut tidak membuktikan website cepat maupun lambat. Gunakan hasil pengujian laboratorium bersama pengamatan perangkat nyata, lalu catat keterbatasan datanya.
Simpan laporan awal dan URL yang diuji. Setelah perbaikan, gunakan halaman serta kondisi pengujian yang sebanding. Hasil sekali tes dapat berubah, sehingga hindari menyimpulkan keberhasilan hanya dari satu kenaikan skor.
Pahami tiga ukuran pengalaman pengguna
Panduan Web Vitals menjelaskan ukuran berikut beserta ambang kategori baik. Penilaian lapangan menggunakan persentil ke-75, dengan pemisahan pengalaman mobile dan desktop.
| Ukuran | Yang diperiksa | Kategori baik |
|---|---|---|
| LCP | Waktu tampil elemen konten terbesar yang memenuhi kriteria LCP di area layar saat pemuatan. | 2,5 detik atau kurang. |
| INP | Respons halaman terhadap interaksi pengguna. | 200 milidetik atau kurang. |
| CLS | Pergeseran tata letak yang tidak diharapkan. | 0,1 atau kurang. |
Contoh membaca selisih dari ambang
Misalkan data contoh menunjukkan LCP 3,8 detik, INP 280 milidetik, dan CLS 0,18. Ini angka simulasi untuk menjelaskan pembacaan, bukan pengukuran aksarakarya.id atau situs klien. Ketiganya melewati ambang kategori baik pada ukuran masing-masing.
| Ukuran | Nilai hipotetis | Ambang baik | Selisih |
|---|---|---|---|
| LCP | 3,8 detik | 2,5 detik | 1,3 detik |
| INP | 280 milidetik | 200 milidetik | 80 milidetik |
| CLS | 0,18 | 0,1 | 0,08 |
Selisih dihitung dengan mengurangkan ambang dari nilai contoh: 3,8 − 2,5 = 1,3 detik; 280 − 200 = 80 milidetik; dan 0,18 − 0,1 = 0,08. CLS tidak memakai detik atau persen. Ketiga selisih tidak dijumlahkan menjadi satu skor karena satuan dan tujuan pengukurannya berbeda.
Nilai tunggal belum menentukan penyebab. Periksa apakah angka berasal dari data halaman atau origin, serta dari laporan lapangan atau pengujian laboratorium. INP membutuhkan interaksi; hasil Lighthouse saat memuat halaman saja tidak menggantikan penilaian INP lapangan.
Gunakan ukuran yang sesuai keluhan. Jika tombol terasa tertunda, periksa interaksi dan pekerjaan JavaScript. Jika gambar utama lambat muncul, periksa jalur pemuatan konten tersebut. Skor performa gabungan berguna sebagai petunjuk, tetapi belum menjelaskan bagian yang menghambat pelanggan.
Urutan pemeriksaan yang dapat dibahas dengan developer
Gambar utama dan waktu penemuannya
Minta developer mengidentifikasi elemen LCP pada halaman. Untuk gambar utama, periksa ukuran berkas, ukuran tampilan, format, serta kapan browser mulai mengunduhnya. Panduan optimasi LCP menjelaskan bahwa penundaan penemuan sumber daya dapat menambah waktu tampil. Gambar yang menjadi LCP sebaiknya tidak ditunda melalui lazy loading.
Mengompres gambar membantu ketika ukuran berkas menjadi masalah. Jika browser baru menemukan gambar setelah rangkaian JavaScript berjalan, ukuran berkas yang lebih kecil saja belum menyelesaikan seluruh penundaan. Minta penjelasan tentang bagian waktu yang paling besar pada laporan.
Respons server dan sumber daya halaman
Periksa waktu respons dokumen, pengalihan alamat, dan apakah server mengerjakan proses yang tidak diperlukan untuk setiap kunjungan. Hosting menjadi salah satu bagian pemeriksaan ini. Perubahan paket sebaiknya memiliki alasan yang terukur, misalnya batas sumber daya yang benar-benar tercapai.
Daftar pula skrip chat, pelacak, video, dan widget pihak ketiga yang dimuat. Tanyakan fungsi bisnis masing-masing. Uji dampak perubahan pada salinan atau lingkungan pengujian agar penghapusan satu skrip tidak merusak formulir, pembayaran, atau pengukuran yang masih dibutuhkan.
Interaksi dan tata letak
Coba membuka menu, mengisi formulir, dan menekan tombol utama ketika halaman masih memuat. Catat interaksi yang tersendat untuk diperiksa lebih lanjut. Untuk elemen yang bergeser, periksa apakah ruang gambar, banner, dan konten tambahan telah disiapkan sebelum elemen itu tampil.
Setelah perubahan, periksa halaman selain beranda yang memakai komponen sama. Pengurangan ukuran gambar beranda belum tentu memperbaiki halaman produk dengan galeri yang berbeda. Sertakan satu halaman layanan dan satu halaman dengan formulir dalam pemeriksaan agar dampak perbaikan dapat dinilai pada tugas yang digunakan pelanggan.
Tentukan satu prioritas dan periksa hasilnya
- Pilih halaman serta tugas pelanggan yang paling terdampak.
- Simpan bukti gejala dan hasil pengukuran awal.
- Sepakati satu perbaikan dengan alasan yang didukung laporan.
- Uji kembali fungsi kontak atau transaksi setelah perubahan.
- Bandingkan pengujian langsung, lalu pantau perubahan data lapangan ketika periodenya bergulir.
Catatan yang berguna berbentuk URL, gejala, ukuran awal, perubahan, dan hasil uji. Jika Anda membutuhkan pemeriksaan rutin, lihat layanan perawatan website. Ketika masalah juga melibatkan susunan halaman atau alur penggunaan yang perlu diubah, bahas cakupannya melalui layanan redesign website dengan membawa hasil diagnosis tersebut.
Dzaki Fauzaan
