Coba buka website perusahaan Anda di HP Android seharga dua jutaan, pakai kuota, di food court yang sedang ramai jam makan siang. Begitulah sebagian besar pengunjung melihat website Anda. Di WiFi kantor dan MacBook, homepage terasa langsung muncul. Di HP tadi, judul utamanya sering baru tampil setelah enam atau tujuh detik, dan tombol kontak tiba-tiba turun persis saat mau ditekan. Website lambat yang kami audit biasanya punya masalah yang itu-itu saja, dan kebanyakan bisa dibereskan dalam beberapa minggu tanpa perlu redesign.
Website Lambat Itu Ada Ongkosnya
Studi Deloitte tahun 2020 yang dipesan Google menemukan bahwa mempercepat loading mobile sepersepuluh detik saja menaikkan konversi retail sekitar 8 persen. Angka di bisnis Anda pasti beda, tapi arahnya sama. Orang keburu pergi sebelum sempat membaca penawaran Anda. Kecepatan juga ikut dihitung Google lewat sinyal page experience. Pendapat kami, efeknya ke ranking tidak besar. Konten yang relevan tetap nomor satu, dan kecepatan jadi penentu di antara halaman yang kualitasnya mirip. Kerugian yang lebih besar justru pengunjung yang menyerah dan menutup tab.
Kondisi di Indonesia membuat ini lebih berat. Mayoritas kunjungan datang dari HP, dan banyak di antaranya HP kelas menengah yang menjalankan JavaScript tiga sampai lima kali lebih lambat dari laptop. Sinyal 4G memang sudah luas, tapi kecepatannya anjlok di tempat ramai dan di luar kota besar. Kalau server-nya ada di Amerika atau Eropa, setiap request masih ditambah latency yang lumayan.
Tiga Metrik Core Web Vitals
Google menilai halaman dari kunjungan sungguhan selama 28 hari terakhir, di persentil ke-75. Artinya, minimal tiga dari empat kunjungan harus memenuhi batasnya supaya halaman dinyatakan lolos. Largest Contentful Paint (LCP) mengukur kapan elemen terbesar di layar pertama muncul, biasanya gambar hero atau judul. Interaction to Next Paint (INP), yang menggantikan First Input Delay sejak Maret 2024, mengukur seberapa cepat halaman merespons tap dan klik. Cumulative Layout Shift (CLS) mengukur seberapa banyak tampilan bergeser selama loading. Time to First Byte (TTFB) tidak termasuk Core Web Vitals, tapi server yang lambat pasti ikut menyeret LCP.
| Metrik | Batas bagus | Penyebab umum | Cara memperbaiki |
|---|---|---|---|
| LCP | Maksimal 2,5 detik | Gambar hero terlalu besar, hero ikut di-lazy-load, CSS dan font yang memblokir render | Perkecil dan ubah ke AVIF atau WebP, pasang fetchpriority high, inline CSS penting |
| INP | Maksimal 200 ms | Widget chat, tracker, script page builder dan slider | Hapus tag yang tidak dipakai, defer script, muat chat hanya saat diklik, pecah task yang panjang |
| CLS | Maksimal 0,1 | Gambar tanpa ukuran, cookie bar dan banner yang muncul belakangan, font yang berganti | Isi width dan height, sediakan ruang untuk banner, pakai size-adjust di font cadangan |
| TTFB (pendukung) | Maksimal 0,8 detik | Shared hosting yang penuh sesak, tanpa page cache, server jauh dari pengguna | Page caching, CDN, hosting di Jakarta atau Singapura |
Data Lab dan Data Lapangan Itu Beda
Lighthouse, baik di Chrome DevTools maupun di PageSpeed Insights, memuat halaman satu kali di HP kelas menengah yang disimulasikan dengan koneksi 4G yang diperlambat. Ini data lab. Gunanya untuk debugging, karena bisa diulang dan terlihat file mana yang bikin lambat. Data lapangan berasal dari Chrome User Experience Report (CrUX), yang mengumpulkan waktu loading dari pengguna Chrome sungguhan. PageSpeed Insights menampilkannya di bagian atas kalau trafik website Anda cukup, dan laporan Core Web Vitals di Search Console mengelompokkan URL Anda jadi bagus, perlu peningkatan, dan buruk.
Yang dipakai untuk ranking adalah data lapangan. Website bisa dapat skor 60 di Lighthouse tapi lolos di lapangan, atau dapat 95 tapi gagal karena HP pengunjung aslinya lebih lambat dari simulasi. Jangan habiskan seminggu mengejar skor 100. Kalau website Anda terlalu kecil untuk punya data CrUX, pasang library open source web-vitals dan kirim angkanya ke Google Analytics 4, supaya Anda tahu apa yang dialami pengunjung Anda sendiri.
Penyebab Website Lambat yang Paling Sering
- Foto hero 3 sampai 5 MB langsung dari fotografer, atau slider berisi lima gambar ukuran penuh padahal pengunjung cuma melihat gambar pertama.
- Container Google Tag Manager yang penuh tag: Meta Pixel, TikTok Pixel, Hotjar, dua tool analytics, plus widget chat yang memuat setengah megabyte JavaScript di setiap halaman.
- Dua keluarga Google Fonts dengan masing-masing empat ketebalan, dimuat dengan cara yang memblokir render.
- Shared hosting murah dengan TTFB 1,5 sampai 3 detik, tanpa page cache, dan server-nya di benua lain.
- Page builder seperti Elementor atau WPBakery dengan empat puluh plugin, masing-masing menambahkan CSS dan JavaScript sendiri ke semua halaman, dipakai atau tidak.
Perbaikan yang Paling Terasa Hasilnya
Mulai dari gambar. Pakai AVIF atau WebP, gunakan srcset supaya HP dapat versi 800 piksel dan desktop dapat 1600 piksel, dan usahakan gambar hero di bawah sekitar 200 KB. Isi atribut width dan height di setiap gambar supaya browser bisa menyiapkan tempatnya. Gambar di bawah layar pertama boleh di-lazy-load, tapi jangan pernah gambar LCP. Gambar itu justru diberi fetchpriority high. Kami cukup sering menemukan plugin lazy load WordPress yang ikut menunda gambar hero, dan itu sendiri sudah memperlambat LCP satu detik atau lebih.
Lalu font. Host sendiri satu keluarga font dengan dua ketebalan dalam format WOFF2, preload file utamanya, dan set font-display ke swap atau optional. Font bawaan sistem juga pilihan yang wajar untuk teks isi. Untuk script, duduk bareng tim marketing dan periksa satu per satu tag di Tag Manager. Yang tidak dilihat siapa pun selama tiga bulan, hapus. Sisanya dimuat dengan defer atau setelah halaman bisa dipakai, dan ganti widget live chat dengan tombol sederhana yang baru memuat widget aslinya saat diklik.
Setelah itu server. Page cache, dari LiteSpeed Cache atau WP Rocket di WordPress atau langsung di level server, sering memangkas TTFB dari dua detik ke di bawah 300 ms. Pasang CDN seperti Cloudflare di depannya, aktifkan kompresi Brotli dan HTTP/3, dan pindahkan hosting ke data center di Jakarta atau Singapura. Kalau website-nya dibangun dengan page builder yang berat dan masih gagal setelah semua ini, membangun ulang lima atau enam template utama sering lebih murah daripada sebulan lagi mengutak-atik plugin.
Langkah Kerjanya
- 1Ukur kondisi awal: jalankan PageSpeed Insights mode mobile untuk homepage dan lima landing page dengan trafik terbanyak di GA4. Catat data lapangan dan data lab, lalu export laporan dari Search Console.
- 2Bereskan TTFB dulu. Kalau server butuh lebih dari 0,8 detik untuk menjawab, utak-atik front-end tidak akan banyak menolong. Tambahkan cache atau ganti hosting.
- 3Perbaiki elemen LCP di setiap template halaman: gambar dengan ukuran pas, format modern, tanpa lazy load, dengan fetchpriority high.
- 4Audit script pihak ketiga bersama orang yang dulu memintanya. Hapus yang tidak dipakai, tunda sisanya.
- 5Perbaiki pergeseran layout: ukuran gambar, ruang untuk cookie bar dan banner promo, dan ukuran font cadangan yang disamakan.
- 6Tes ulang di lab, tunggu periode data lapangan 28 hari berganti, lalu klik Validasi Perbaikan di Search Console.
- 7Tetapkan budget supaya tidak lambat lagi, misalnya hero di bawah 200 KB dan JavaScript di bawah 300 KB per halaman, dicek oleh Lighthouse CI di pipeline deployment.
Setiap script yang vendor minta untuk ditempel di head website Anda dibayar oleh setiap pengunjung, di setiap halaman.
Kecepatan paling gampang dijaga kalau ada yang bertanggung jawab. Saat kami membangun atau mengambil alih pengelolaan website, budget-nya kami tetapkan dari awal, data lapangannya kami cek tiap bulan, dan setiap script baru kami tanyakan dulu gunanya sebelum masuk production. Bersih-bersih belakangan selalu makan waktu lebih lama.
Poin penting
- Tes website di HP Android kelas menengah dengan kuota seluler, karena begitulah banyak pengunjung di Indonesia membukanya.
- Core Web Vitals lolos kalau 75 persen kunjungan sungguhan mencapai LCP 2,5 detik, INP 200 ms, dan CLS 0,1 atau lebih baik.
- Pakai Lighthouse untuk debugging, tapi nilai hasilnya dari data lapangan di CrUX dan Search Console.
- Hasil terbesar biasanya datang dari gambar hero yang lebih kecil, script pihak ketiga yang lebih sedikit, dan page cache dengan hosting yang dekat.
- Tetapkan budget performa dan cek di setiap deployment supaya website tetap cepat setelah diperbaiki.
