Mulai dari Diagnosis, Bukan dari Tebakan #
Banyak pemilik website langsung memasang plugin cache atau mengganti hosting begitu website terasa lambat. Kadang berhasil, sering kali tidak, karena penyebab sebenarnya ada di tempat lain. Perbaikan yang efektif selalu dimulai dengan menjawab satu pertanyaan: bagian mana yang lambat, dan untuk siapa?
Google mengukur pengalaman halaman lewat tiga metrik Core Web Vitals. Ambang "baik" ditetapkan pada persentil ke-75 data pengguna nyata:
INP menggantikan FID sebagai metrik resmi pada Maret 2024. Satu metrik pendukung yang ikut menentukan LCP adalah TTFB, yaitu waktu hingga byte pertama dari server diterima.
Cara Mendiagnosis dengan Benar #
- PageSpeed Insights. Perhatikan dua bagian: data lapangan (dari pengguna nyata, bila tersedia) dan data lab (simulasi Lighthouse). Keputusan sebaiknya berdasar data lapangan.
- Laporan Core Web Vitals di Search Console. Menunjukkan kelompok URL yang bermasalah dan metrik mana yang gagal.
- Chrome DevTools, tab Network dan Performance. Untuk melihat file mana yang besar atau lambat dan skrip mana yang memblokir.
- Uji dari jaringan seluler. Sebagian besar pengunjung Indonesia mengakses dari ponsel dengan koneksi yang tidak selalu stabil.
Skor Lighthouse 100 bukan tujuan. Skor itu hasil simulasi di satu perangkat. Yang perlu dikejar adalah data lapangan yang hijau.
Dua Belas Penyebab Umum #
A. Server dan jaringan #
1. TTFB tinggi. Penyebabnya bisa hosting yang kelebihan beban, tidak ada cache halaman, atau kueri database yang berat. Gejalanya: bahkan halaman kosong pun lambat muncul. Perbaikannya: caching di sisi server, kueri yang dioptimalkan, atau memindahkan halaman publik menjadi statis.
2. Tidak memakai CDN. Pengunjung dari jauh harus menempuh jarak jaringan yang lebih panjang. CDN menyimpan salinan aset di lokasi yang lebih dekat dengan pengunjung.
3. Kompresi dan protokol usang. Pastikan Brotli atau gzip aktif dan server mendukung HTTP/2 atau HTTP/3.
B. Aset #
4. Gambar terlalu besar atau berformat lama. Ini penyebab nomor satu pada banyak website. Gunakan format modern (WebP atau AVIF), ukuran sesuai tampilan, dan atribut srcset agar ponsel tidak mengunduh gambar ukuran desktop.
5. Gambar utama dimuat terlambat. Jangan beri loading="lazy" pada gambar yang terlihat di layar pertama. Untuk gambar LCP, gunakan fetchpriority="high". Lazy-load hanya untuk gambar di bawah lipatan layar.
6. Font web yang menahan tampilan teks. Pakai font-display: swap, kurangi jumlah varian font, dan pertimbangkan subsetting. Memuat lima keluarga font demi tampilan berbeda tipis adalah pemborosan.
7. Video dan embed berat. Embed YouTube atau peta memuat ratusan kilobyte skrip sebelum pengunjung menekan apa pun. Tampilkan gambar pratinjau dulu, muat pemutar setelah diklik.
C. JavaScript dan CSS #
8. JavaScript berlebih. Setiap plugin, widget, dan pustaka menambah beban parsing dan eksekusi di ponsel. Efeknya terasa pada INP: tombol diketuk, tetapi respons tertunda. Hapus yang tidak dipakai dan pecah bundel besar.
9. Skrip pihak ketiga. Widget chat, pixel iklan, heatmap, dan tag manager yang menumpuk sering menjadi penyumbang terbesar kelambatan interaksi. Bahasan lengkapnya ada di audit kinerja JavaScript dan tag bloat.
10. CSS yang memblokir render atau tidak terpakai. Tema serbaguna sering memuat ratusan kilobyte CSS untuk fitur yang tidak dipakai di halaman tersebut.
D. Stabilitas dan arsitektur #
11. Layout bergeser. Gambar tanpa dimensi, banner yang muncul belakangan, dan font yang berganti membuat konten melompat. Selalu tentukan width dan height (atau aspect-ratio) dan sediakan ruang untuk elemen yang dimuat belakangan.
12. Arsitektur yang tidak sesuai kebutuhan. Situs yang merakit setiap halaman di database untuk setiap kunjungan, atau yang dirender sepenuhnya di browser, akan selalu berjuang. Pada titik tertentu, memindahkan halaman publik ke render statis atau sisi server lebih efektif daripada menambah plugin optimasi. Perbandingannya ada di Next.js vs WordPress dan arsitektur headless vs monolitik.
Ringkasan: Gejala, Metrik, dan Prioritas #
| Gejala | Metrik terdampak | Cek pertama |
|---|---|---|
| Halaman lama "kosong" sebelum apa pun tampil | TTFB, LCP | Waktu respons server, cache, CDN |
| Gambar utama muncul belakangan | LCP | Ukuran, format, dan prioritas pemuatan gambar |
| Tombol atau menu terasa lambat merespons | INP | Skrip pihak ketiga, ukuran bundel JavaScript |
| Konten melompat saat dimuat | CLS | Dimensi gambar, banner, font |
Urutan Memperbaiki #
- Cari elemen LCP di halaman terpenting (biasanya gambar hero atau judul besar) dan pastikan elemen itu dimuat paling awal.
- Kecilkan gambar dan ganti formatnya. Biasanya ini perbaikan dengan hasil terbesar per jam kerja.
- Audit skrip pihak ketiga. Tanyakan pada setiap skrip: siapa yang memakai datanya, dan apakah masih dibutuhkan?
- Perbaiki TTFB lewat cache dan CDN.
- Tutup celah CLS dengan dimensi yang eksplisit.
- Ukur ulang setelah setiap perubahan, lalu tunggu data lapangan diperbarui. Data lapangan Search Console bergerak lambat, biasanya perlu beberapa minggu untuk mencerminkan perbaikan.
Dampak Bisnis #
Kecepatan bukan hanya urusan teknis. Halaman yang lambat kehilangan pengunjung sebelum sempat menjelaskan apa pun, dan di mesin pencari kecepatan adalah salah satu sinyal pengalaman halaman. Untuk memperkirakan nilai uangnya, coba kalkulator ROI kecepatan, lalu jalankan audit kecepatan untuk melihat titik awal Anda. Panduan teknis yang lebih luas ada di pilar Technical SEO dan Web Performance.
Jika setelah semua perbaikan di atas website Anda masih terbatas oleh arsitekturnya, itu sinyal untuk mempertimbangkan pembangunan ulang yang terukur, bukan menambah plugin lagi.
