Website mobile friendly adalah situs yang benar-benar enak dipakai dari layar ponsel: teksnya terbaca tanpa perlu dicubit, tombolnya gampang ditekan pakai satu jempol, dan yang paling sering dilupakan, halamannya muncul cepat walau sinyalnya cuma dua bar. Poin terakhir itu yang biasanya jadi masalah. Banyak pemilik usaha sudah punya situs yang rapi menyusut mengikuti layar HP, tapi calon pembelinya tetap pergi sebelum sempat melihat harga.
Sebelum masuk lebih jauh, satu hal perlu diluruskan karena sering dicampur aduk. Ada dua "kecepatan" yang berbeda dalam urusan website. Pertama, kecepatan membuatnya, yaitu berapa lama dari ide sampai situs tayang. Kedua, kecepatan situs itu terbuka di HP pengunjung. Yang menentukan berapa banyak orang bertahan dan akhirnya menghubungimu adalah yang kedua, dan itulah yang dibahas di halaman ini.
Artikel ini juga bukan panduan SEO umum. Kalau itu yang kamu cari, kami sudah membahasnya terpisah di dasar-dasar SEO website dan cara website muncul di Google. Di sini fokusnya satu: kenapa kecepatan dan pengalaman mobile menentukan jumlah calon pembeli yang bertahan, bagaimana mengukurnya sendiri tanpa bayar siapa pun, dan bagian mana yang benar-benar layak diperbaiki.
Website mobile friendly itu apa, dan kenapa "muat di layar HP" belum cukup
Kebanyakan orang mengira mobile friendly berarti tampilannya tidak berantakan di HP. Itu baru syarat masuk, bukan garis finis.
Standar yang lebih jujur terdiri dari empat hal:
- Terbaca. Ukuran huruf isi minimal setara 16 piksel. Kalau pengunjung harus zoom untuk membaca harga, kamu sudah kehilangan sebagian dari mereka.
- Bisa disentuh. Tombol dan tautan cukup besar dan cukup renggang, sehingga jempol tidak salah tekan. Tombol pesan yang menempel di navigasi kecil adalah kesalahan mahal.
- Tidak meleber. Tidak ada tabel, gambar, atau kotak yang memaksa halaman digeser ke samping. Geser horizontal di HP terasa seperti situs rusak.
- Cepat muncul. Isi utama halaman, biasanya judul dan foto besar di bagian atas, sudah tampil sebelum kesabaran pengunjung habis.
Tiga syarat pertama urusan tata letak dan biasanya sudah ditangani oleh platform modern mana pun. Syarat keempat yang membuat perbedaan besar dan justru paling sering luput, karena pemilik situs mengeceknya dari laptop kantor dengan wifi kencang.
Google sendiri memakai versi mobile sebagai acuan utama. Dalam dokumentasi resminya, Search Central menyatakan bahwa Google menggunakan versi mobile dari konten sebuah situs, yang dirayapi dengan agen smartphone, untuk pengindeksan dan peringkat. Ini yang disebut mobile-first indexing. Artinya versi HP situsmu bukan versi cadangan, melainkan versi yang dilihat Google.
Kondisi Indonesia membuat taruhannya lebih besar
Di banyak pasar, mobile hanya sebagian dari trafik. Di sini situasinya lebih ekstrem.
Menurut laporan Digital 2025: Indonesia dari DataReportal, ada 356 juta koneksi seluler aktif di Indonesia pada awal 2025, setara 125 persen dari total populasi. Angka itu tidak berarti semua orang punya HP, karena satu orang bisa memegang beberapa nomor. Tapi arahnya jelas: internet di Indonesia hidup di genggaman, bukan di meja.
Tiga konsekuensi praktis untuk pemilik usaha:
Kualitas jaringan tidak merata. Pengunjungmu tidak semuanya duduk di kafe dengan wifi. Sebagian membuka linkmu di angkot, di gudang, atau di daerah yang sinyalnya naik turun. Situs yang perlu memuat 4 MB aset akan terasa mati di kondisi itu.
Kuota masih dihitung. Halaman berat bukan cuma lambat, tapi juga memakan kuota. Pengunjung yang pernah kecewa jarang mencoba dua kali.
HP kelas menengah mendominasi. Prosesor ponsel sejuta dua juta jauh lebih lemah daripada laptop kerjamu. Skrip yang terasa ringan di perangkatmu bisa membuat halaman membeku beberapa detik di perangkat mereka.
Efek gabungannya sederhana. Pembeli yang situsnya lambat biasanya tidak pindah ke kompetitor, karena mereka belum tahu ada kompetitor. Mereka kembali ke Instagram atau WhatsApp, tempat mereka datang tadi, dan momen belinya lewat begitu saja.
Tiga angka yang dipakai Google untuk menilai pengalaman pengunjung
Google merangkum pengalaman ini dalam tiga metrik bernama Core Web Vitals. Kamu tidak perlu jadi programmer untuk memahaminya, cukup tahu apa yang diukur masing-masing.
| Metrik | Mengukur apa | Ambang "baik" |
|---|---|---|
| LCP (Largest Contentful Paint) | Kapan isi utama halaman selesai tampil | 2,5 detik atau kurang |
| INP (Interaction to Next Paint) | Seberapa cepat halaman merespons sentuhan | 200 milidetik atau kurang |
| CLS (Cumulative Layout Shift) | Seberapa stabil tata letak saat halaman dimuat | 0,1 atau kurang |
Ketiga ambang itu tertulis di halaman Core Web Vitals web.dev milik Google. Satu detail penting yang sering dilewat: angka itu diukur pada persentil ke-75 dari seluruh kunjungan, dipisah antara mobile dan desktop. Jadi bukan rata-rata. Tiga dari empat pengunjungmu harus mendapat pengalaman sebaik itu, termasuk yang sinyalnya jelek.
Terjemahan sehari-harinya begini:
LCP adalah jawaban atas pertanyaan "berapa lama sampai saya melihat sesuatu yang berguna?" Kalau pengunjung menatap layar kosong tiga detik, sebagian dari mereka sudah menekan tombol kembali. Menurut panduan optimasi LCP web.dev, waktu itu terbagi menjadi empat bagian: waktu tunggu respons server, jeda sebelum aset utama mulai dimuat, durasi memuat aset itu, dan jeda sampai elemennya benar-benar tergambar. Buat kebanyakan situs UMKM, biang keroknya ada di bagian ketiga, yaitu foto besar yang belum dikompres.
INP adalah rasa "nyantol" saat kamu menekan tombol dan tidak ada yang terjadi. Dokumentasi INP web.dev menyebut nilai di atas 200 milidetik sampai 500 milidetik sudah masuk kategori perlu diperbaiki. Di HP kelas menengah, penyebab tersering adalah tumpukan skrip pelacak dan widget chat yang dipasang sekaligus.
CLS adalah momen menyebalkan saat kamu hendak menekan "Pesan sekarang" lalu tiba-tiba muncul banner promo dan jarimu mendarat di tempat lain. Panduan CLS web.dev menetapkan nilai di atas 0,25 sebagai buruk. Ini metrik yang paling murah diperbaiki dan paling sering diabaikan.
Cara cek website mobile friendly dan kecepatannya sendiri, gratis
Tidak perlu menyewa siapa pun untuk tahu posisimu. Lakukan tiga langkah ini, urut.
Langkah 1: jalankan PageSpeed Insights. Buka pagespeed.web.dev, tempel alamat halaman yang paling penting (biasanya beranda dan satu halaman produk atau layanan), lalu tekan Analisis. Setelah hasilnya keluar, pastikan kamu berada di tab Mobile, bukan Desktop. Ini kesalahan paling umum: orang membaca angka desktop lalu merasa aman.
Langkah 2: baca bagian atas dulu, bukan skornya. Kalau situsmu punya cukup pengunjung, di bagian paling atas akan muncul blok berjudul "Discover what your real users are experiencing". Itu data lapangan dari Chrome User Experience Report, kumpulan data pengguna Chrome sungguhan selama 28 hari terakhir. Angka inilah yang mewakili pengalaman pembelimu. Kalau ketiga metriknya hijau, situsmu sehat, apa pun skor besar di bawahnya.
Kalau blok itu tidak muncul, artinya trafikmu belum cukup untuk masuk dataset. Itu normal untuk situs baru dan bukan pertanda buruk. Dalam kasus ini, pakai bagian bawah sebagai perkiraan kasar.
Langkah 3: tes manual dari HP orang lain. Pinjam HP karyawan atau keluarga, matikan wifi, buka situsmu lewat data seluler, dan hitung dalam hati sampai kontennya tampil. Coba juga tekan setiap tombol order. Tes lima menit ini sering menemukan hal yang tidak terlihat di laporan mana pun: nomor WhatsApp salah, tombol tertutup elemen lain, atau formulir yang tidak bisa di-scroll. Kalau situsmu memang dikelola dari ponsel, panduan bikin website lewat HP membahas alurnya lebih detail.
Skor mana yang layak dikejar, mana yang cuma bikin cemas
Ini bagian yang jarang dibilang orang, dan mungkin berbeda dari saran yang biasa kamu dengar: jangan kejar skor 100.
Angka besar berwarna di PageSpeed Insights itu hasil simulasi laboratorium, dijalankan pada perangkat dan jaringan tiruan. Berguna sebagai alat diagnosis, tapi ia bukan rapor pengunjung nyatamu. Situs berskor 72 yang lulus tiga ambang data lapangan lebih sehat daripada situs berskor 96 yang gagal di data lapangan.
Yang layak dikejar:
- Ketiga metrik di blok data pengguna nyata berstatus hijau, khususnya di tab Mobile.
- LCP di bawah 2,5 detik pada halaman yang paling sering jadi pintu masuk pengunjung.
- CLS mendekati nol, karena ini murah diperbaiki dan langsung terasa.
Yang tidak perlu bikin cemas:
- Selisih beberapa poin di skor lab antara satu tes dan tes berikutnya. Angka itu memang bergoyang.
- Peringatan teknis yang menghemat 0,05 detik tapi butuh dua hari kerja.
- Skor halaman yang hampir tidak pernah dikunjungi siapa pun.
Perlu perspektif juga soal dampaknya. Google menyebut Core Web Vitals sebagai salah satu aspek page experience yang dinilai sistem peringkatnya, dan mendorong pemilik situs untuk tidak fokus pada satu atau dua aspek saja. Konten yang benar-benar menjawab kebutuhan pencari tetap faktor terbesar. Nilai sesungguhnya dari kecepatan lebih terasa di konversi. Studi kasus yang dipublikasikan Google memberi gambaran skalanya: Vodafone mencatat perbaikan LCP 31 persen yang diikuti kenaikan penjualan 8 persen, sementara Rakuten 24 melaporkan kenaikan pendapatan per pengunjung 53,37 persen dan tingkat konversi 33,13 persen setelah membenahi Core Web Vitals. Skalanya jelas berbeda dengan toko kue rumahan, tapi arah hubungannya sama: halaman yang cepat membuat lebih banyak orang sampai ke tombol pesan.
Tujuh penyebab website UMKM lambat di HP, diurutkan dari yang paling berdampak
Dari pola yang berulang, ini urutan yang biasanya paling menguntungkan untuk dibereskan.
- Foto mentah dari kamera HP. Satu foto produk 4 MB yang diunggah apa adanya bisa sendirian menghancurkan LCP. Kompres ke bawah 200 KB dan pakai format modern seperti WebP. Ini perbaikan dengan rasio hasil terhadap usaha paling tinggi.
- Gambar tanpa ukuran. Panduan CLS web.dev menempatkan gambar tanpa dimensi sebagai penyebab paling umum tata letak melompat. Solusinya sepele: cantumkan atribut lebar dan tinggi.
- Iklan, embed, dan iframe tanpa dimensi. Peta Google, video, dan widget yang disisipkan tanpa ruang cadangan akan mendorong konten di bawahnya saat selesai dimuat.
- Konten yang disuntikkan belakangan. Banner promo, pengumuman ongkir, dan popup yang muncul setelah halaman tergambar termasuk penyebab CLS yang disebut eksplisit di dokumentasi yang sama.
- Terlalu banyak skrip pihak ketiga. Pixel iklan, dua alat analitik, widget chat, dan pop-up langganan yang dipasang bersamaan adalah resep INP buruk. Copot yang tidak kamu baca datanya.
- Server yang lambat merespons. Waktu tunggu respons pertama adalah komponen awal LCP. Hosting murah yang berbagi terlalu banyak pengguna sering terasa di sini.
- Web font yang berat. Memuat empat ketebalan dari dua keluarga huruf demi estetika jarang sepadan. Web font juga termasuk penyebab CLS yang disebutkan web.dev.
Perhatikan bahwa lima dari tujuh penyebab di atas bukan urusan koding. Itu urusan disiplin isi: gambar yang dikompres, widget yang diseleksi, dan halaman yang tidak dijejali.
Benahi atau bangun ulang?
Jawabannya tergantung dari mana situsmu berasal.
Kalau situsmu relatif sederhana dan cuma butuh pembenahan aset, benahi saja. Kompres semua gambar, cantumkan dimensinya, copot skrip yang tidak terpakai, lalu tes ulang. Tiga langkah itu sering sudah cukup untuk memindahkan situs dari merah ke hijau, dan biayanya nol.
Kalau situsmu dibangun bertahun-tahun lalu di atas tema dan tumpukan plugin yang saling menimpa, matematikanya berubah. Setiap perbaikan memicu masalah baru, dan kamu berakhir membayar orang untuk menambal sesuatu yang fondasinya memang berat. Dalam kondisi itu, membangun ulang halaman inti biasanya lebih hemat waktu daripada terus menambal.
Di sinilah cara membuat website ikut menentukan hasilnya. Situs yang dibuat dengan Forgelo sudah responsif secara default dan membawa SEO bawaan sejak halaman pertama terbentuk, jadi kamu tidak memulai dari lubang teknis. Kamu cukup mendeskripsikan bisnismu dalam satu kalimat, dan dalam beberapa menit draf situsnya terbentuk lengkap dengan struktur halaman dan teksnya. Perlu ditegaskan lagi supaya tidak tertukar dengan topik artikel ini: yang selesai dalam hitungan menit adalah proses pembuatannya, bukan janji atas angka Core Web Vitals situsmu nanti. Angka itu tetap dipengaruhi keputusanmu sendiri, terutama seberapa berat foto yang kamu unggah dan seberapa banyak widget yang kamu tempel.
Merapikan detailnya juga tidak perlu tim. Kamu mengetik perubahan yang kamu mau, misalnya "ganti foto hero dengan versi yang lebih ringan" atau "hapus banner promo di bawah judul", lalu bagian itu saja yang dibangun ulang. Alur edit per bagian ini membuat perbaikan kecil tidak lagi terasa seperti proyek. Paket gratisnya cukup untuk satu situs kalau kamu ingin mencoba dulu, dan pilihan berbayarnya bisa kamu lihat di halaman harga.
Terakhir, jangan berhenti di angka. Website cepat yang tidak punya jalur order yang jelas tetap sepi. Setelah situsmu ringan, pastikan pengunjung tahu harus ke mana: tombol WhatsApp yang terlihat tanpa perlu scroll jauh, harga yang tidak disembunyikan, dan halaman yang menjawab pertanyaan yang biasa masuk ke chat. Cara menyusunnya kami bahas di mengubah pengunjung jadi lead WhatsApp dan cara buat website jualan. Kalau kamu masih di tahap paling awal dan belum punya situs sama sekali, mulai dari panduan bikin website untuk bisnis.
Kecepatan bukan tujuan akhir. Ia cuma memastikan pembelimu bertahan cukup lama untuk melihat apa yang kamu jual.


