Panduan membaca laporan PageSpeed Insights dari atas ke bawah: penilaian Core Web Vitals dari pengguna nyata, skor performa dari Lighthouse, bobot tiap metrik, penyebab skor naik turun, dan cara memilih saran perbaikan yang benar-benar berdampak.
PageSpeed Insights adalah alat gratis dari Google untuk mengukur pengalaman pengguna sebuah halaman di seluler dan desktop. Anda memasukkan URL, lalu alat ini menampilkan dua hal: penilaian Core Web Vitals dari pengguna Chrome sungguhan, dan skor performa 0 sampai 100 dari simulasi Lighthouse, lengkap dengan saran perbaikannya. Cara membacanya yang benar dimulai dari bagian atas (data pengguna nyata), bukan dari angka skor yang paling mencolok.
Banyak pemilik situs membuka PageSpeed Insights, melihat angka oranye atau merah, lalu panik. Artikel ini menjelaskan apa arti setiap bagian laporan, kenapa skornya bisa berubah tanpa ada perubahan di situs, dan bagaimana memilih saran perbaikan yang benar-benar berdampak. Semua angka ambang dan bobot di sini diambil dari dokumentasi resmi Google dan Chrome, yang tautannya ada di bagian sumber.
Buka pagespeed.web.dev, tempel URL halaman yang ingin diuji, lalu jalankan analisis. Alat ini menguji halaman versi seluler dan desktop, dan Anda bisa berpindah di antara keduanya lewat tab di bagian atas laporan. Mulailah dari tab seluler, karena di sanalah masalah kecepatan paling sering muncul.
Beberapa kebiasaan kecil membuat hasilnya lebih berguna:
Kalau Anda perlu menguji banyak URL secara rutin, Google juga menyediakan PageSpeed Insights API dengan endpoint runPagespeed. Hasilnya sama dengan versi web, tetapi bisa dipanggil dari skrip. Untuk pemakaian rutin, dokumentasi Google menyarankan memakai kunci API.
Ini bagian yang paling sering disalahpahami. PageSpeed Insights menampilkan dua jenis data yang asalnya berbeda, dan keduanya menjawab pertanyaan yang berbeda.
Data lapangan (di laporan disebut pengalaman pengguna nyata) berasal dari Chrome User Experience Report, yaitu kumpulan data pengalaman pengguna Chrome sungguhan. Data ini mencakup periode 28 hari terakhir dan diperbarui setiap hari. Data lapangan menjawab pertanyaan: apa yang benar-benar dialami pengunjung saya?
Data lab berasal dari Lighthouse, yang memuat halaman dalam kondisi terkendali. Untuk seluler, Lighthouse mensimulasikan perangkat kelas menengah di jaringan seluler, sedangkan untuk desktop memakai emulasi desktop dengan koneksi kabel. Data lab menjawab pertanyaan: di bagian mana halaman ini lambat, dan kenapa?
| Aspek | Data lapangan | Data lab |
|---|---|---|
| Sumber | Pengguna Chrome sungguhan (Chrome User Experience Report) | Simulasi Lighthouse dalam kondisi terkendali |
| Periode | 28 hari terakhir, diperbarui harian | Satu kali pemuatan saat Anda menekan tombol analisis |
| Cara melapor | Persentil ke-75 dan sebaran baik, perlu perbaikan, buruk | Skor performa 0 sampai 100 dan nilai tiap metrik |
| Paling berguna untuk | Menilai pengalaman pengunjung dan hasil Core Web Vitals | Mencari penyebab masalah dan menguji perbaikan |
| Keterbatasan | Butuh cukup data, sering kosong di situs baru | Tidak menangkap semua kondisi nyata pengunjung |
Kalau keduanya tampak bertentangan, misalnya data lapangan lolos tetapi skor lab oranye, itu wajar. Pengunjung Anda mungkin memakai perangkat yang lebih cepat dari simulasi Lighthouse, atau sebaliknya. Untuk menilai pengalaman pengunjung, data lapangan yang menjadi patokan.
Bagian paling atas laporan menampilkan penilaian Core Web Vitals: lolos atau tidak lolos. Core Web Vitals terdiri dari tiga metrik yang masing-masing mewakili satu aspek pengalaman pengguna:
PageSpeed Insights memakai ambang yang sama dengan inisiatif Web Vitals:
| Metrik | Baik | Perlu perbaikan | Buruk |
|---|---|---|---|
| Largest Contentful Paint (LCP) | sampai 2,5 detik | di atas 2,5 sampai 4 detik | di atas 4 detik |
| Interaction to Next Paint (INP) | sampai 200 ms | di atas 200 sampai 500 ms | di atas 500 ms |
| Cumulative Layout Shift (CLS) | sampai 0,1 | di atas 0,1 sampai 0,25 | di atas 0,25 |
| First Contentful Paint (FCP) | sampai 1,8 detik | di atas 1,8 sampai 3 detik | di atas 3 detik |
Semua metrik lapangan dilaporkan pada persentil ke-75. Artinya, angka yang tampil adalah nilai yang dicapai atau dilampaui oleh 75 persen kunjungan. Google memilih persentil ini supaya halaman dinilai baik hanya bila sebagian besar pengunjung, termasuk yang memakai perangkat dan jaringan lebih lambat, mendapat pengalaman yang baik.
Sebuah halaman atau domain lolos penilaian bila persentil ke-75 dari ketiga metrik berada di kategori baik. Kalau data INP belum cukup, penilaian lolos bila LCP dan CLS sama-sama baik. Kalau data LCP atau CLS belum cukup, penilaian tidak bisa dilakukan sama sekali.
Di bawah data lapangan ada skor performa dari Lighthouse. Skor inilah yang biasanya dijadikan patokan orang, padahal ia hanya ringkasan dari data lab. Lighthouse menghitungnya dari lima metrik dengan bobot berbeda. Pada Lighthouse 10, bobotnya adalah:
| Metrik lab | Bobot |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
Tabel itu menjelaskan kenapa dua halaman yang terasa sama cepatnya bisa punya skor jauh berbeda. Total Blocking Time memegang bobot terbesar, dan metrik ini sangat dipengaruhi oleh JavaScript yang berat, termasuk skrip pihak ketiga seperti chat, analitik, dan iklan. Halaman yang gambarnya cepat tampil tetapi memuat banyak skrip bisa tetap mendapat skor rendah.
Warna skor mengikuti rentang yang tetap: 0 sampai 49 merah (buruk), 50 sampai 89 oranye (perlu perbaikan), dan 90 sampai 100 hijau (baik). Dokumentasi Lighthouse menyarankan situs mengejar rentang 90 sampai 100, tetapi juga menyebut skor 100 sangat sulit dicapai dan tidak diharapkan. Menaikkan skor dari 99 ke 100 butuh perbaikan metrik yang kira-kira sama dengan menaikkan dari 90 ke 94.
Pertanyaan yang paling sering kami terima dari pemilik situs: kenapa skornya berubah padahal tidak ada yang diubah? Jawabannya ada di cara data lab dikumpulkan. Google menyebut sumber variasi seperti ketersediaan jaringan, ketersediaan perangkat keras, dan perebutan sumber daya. PageSpeed Insights juga berjalan di pusat data Google yang lokasinya bisa berbeda, yang dilaporkan di salah satu dari Amerika Utara, Eropa, atau Asia.
Dokumentasi Lighthouse menambahkan penyebab lain yang sering luput:
Karena itu, Lighthouse menyarankan memandang performa sebagai sebaran skor, bukan satu angka. Dalam praktik kami, satu pengujian tidak pernah dijadikan dasar keputusan. Kami menjalankan beberapa kali, mencatat kisarannya, dan hanya menganggap sebuah perbaikan berhasil bila kisarannya bergeser, bukan bila satu pengujian kebetulan lebih tinggi.
Di bawah skor ada daftar temuan yang dikelompokkan sebagai peluang dan diagnostik. Setiap temuan menjelaskan masalah, elemen yang terkena, dan kadang perkiraan penghematan waktu. Daftar ini sangat berguna, tetapi mudah membuat Anda sibuk dengan hal kecil.
Cara memilahnya sederhana. Mulailah dari metrik yang gagal di data lapangan, lalu cari temuan lab yang berhubungan dengan metrik itu. Kalau LCP yang bermasalah, fokus pada temuan soal gambar besar, waktu respons server, dan sumber daya yang menghambat render. Kalau CLS yang bermasalah, cari gambar tanpa ukuran, iklan atau banner yang muncul belakangan, dan font yang menggeser teks. Kalau INP yang bermasalah, cari JavaScript berat dan tugas panjang di thread utama.
| Metrik bermasalah | Penyebab yang sering kami temui | Perbaikan pertama yang layak dicoba |
|---|---|---|
| LCP lambat | Gambar utama berukuran besar, server lambat merespons, CSS atau font yang menghambat render | Kompres dan ubah ukuran gambar utama, jangan lazy load gambar di atas layar, kurangi sumber daya yang menghambat render |
| CLS tinggi | Gambar dan video tanpa atribut ukuran, banner yang disisipkan belakangan, pergantian font | Beri lebar dan tinggi pada media, siapkan ruang untuk elemen yang muncul belakangan |
| INP lambat | JavaScript berat, skrip pihak ketiga, tugas panjang di thread utama | Tunda atau hapus skrip yang tidak perlu, pecah tugas JavaScript yang panjang |
| TBT tinggi di lab | Banyak skrip dimuat di awal | Muat skrip pihak ketiga setelah interaksi atau setelah halaman selesai dimuat |
Setelah memperbaiki, ingat bahwa data lapangan mencakup 28 hari terakhir. Perbaikan yang sudah tayang butuh waktu untuk tercermin di penilaian Core Web Vitals, sementara data lab langsung berubah. Jangan menyimpulkan perbaikan gagal hanya karena data lapangan belum bergerak dalam beberapa hari.
Google menyatakan sangat menyarankan pemilik situs mencapai Core Web Vitals yang baik, dan menyebut hal ini, bersama aspek pengalaman halaman lain, selaras dengan apa yang ingin dihargai sistem peringkat intinya. Yang perlu dicatat, yang dimaksud adalah Core Web Vitals dari pengalaman pengguna nyata, bukan skor lab 0 sampai 100.
Dalam konteks SEO, kecepatan adalah satu bagian dari technical SEO, bukan pengganti konten yang relevan. Halaman yang sangat cepat tetapi tidak menjawab pencarian tetap sulit tampil. Sebaliknya, halaman yang sangat membantu tetapi lambat berisiko kehilangan pengunjung yang tidak sabar menunggu. Cara Google memilih halaman untuk ditampilkan kami jelaskan di artikel cara kerja SEO, dan dasar-dasar SEO secara umum ada di apa itu SEO.
Search Console juga punya laporan Core Web Vitals yang mengelompokkan URL situs berdasarkan status baik, perlu perbaikan, atau buruk. Laporan ini lebih praktis daripada menguji URL satu per satu, karena langsung menunjukkan kelompok halaman yang bermasalah. Cara membuka dan membaca laporannya ada di panduan Google Search Console.
Beberapa kebiasaan membuat pemilik situs membuang waktu, bahkan memperburuk situsnya:
Kalau Anda sedang membangun pemahaman SEO dari awal, kecepatan halaman termasuk tahap technical SEO di panduan belajar SEO kami. Alat lain yang melengkapi PageSpeed Insights, seperti crawler dan alat riset kata kunci, kami ulas di artikel SEO tools.
Sebelum menyentuh apa pun, simpan kondisi awal. Setelah memperbaiki, bandingkan dengan cara yang sama. Checklist berikut kami pakai di setiap audit:
Kecepatan halaman termasuk bagian yang kami periksa saat melakukan audit SEO. Kalau Anda ingin tahu apakah kecepatan memang menjadi masalah utama situs Anda, atau ada hal lain yang lebih mendesak, gambaran biaya pemeriksaannya ada di halaman harga.
PageSpeed Insights adalah alat gratis dari Google yang melaporkan pengalaman pengguna sebuah halaman di perangkat seluler dan desktop, lalu memberi saran perbaikan. Laporannya memuat dua jenis data: data lapangan dari pengguna Chrome sungguhan (Chrome User Experience Report) dan data lab dari Lighthouse yang mensimulasikan pemuatan halaman.
Lighthouse mewarnai skor 90 sampai 100 sebagai baik (hijau), 50 sampai 89 perlu perbaikan (oranye), dan 0 sampai 49 buruk (merah). Dokumentasinya menyarankan situs mengejar rentang 90 sampai 100, dan menyebut skor sempurna 100 sangat sulit dicapai dan tidak diharapkan. Yang lebih penting dari skor adalah hasil penilaian Core Web Vitals dari data lapangan.
Karena kondisi pengukurannya berubah. Google menyebut sumber variasi seperti ketersediaan jaringan, perangkat keras, dan perebutan sumber daya. Dokumentasi Lighthouse menambahkan iklan atau uji A/B yang berganti, perubahan rute internet, ekstensi browser, dan antivirus. Jalankan uji beberapa kali dan lihat kisarannya, bukan satu angka.
Data lapangan berasal dari pengalaman pengguna Chrome sungguhan selama 28 hari terakhir dan dilaporkan pada persentil ke-75. Data lab berasal dari satu kali simulasi Lighthouse dalam kondisi terkendali. Data lab berguna untuk mencari penyebab masalah, sedangkan data lapangan menunjukkan apa yang benar-benar dialami pengunjung.
Data lapangan hanya tampil bila Chrome User Experience Report punya cukup data untuk halaman atau domain itu. Situs baru atau halaman dengan sedikit pengunjung sering belum punya data yang cukup, sehingga PageSpeed Insights hanya menampilkan data lab. Untuk situs seperti itu, pakai data lab sebagai panduan sambil menunggu data pengguna terkumpul.
Google menyatakan Core Web Vitals, bersama aspek pengalaman halaman lain, selaras dengan apa yang ingin dihargai sistem peringkat intinya, dan sangat menyarankan pemilik situs mencapai Core Web Vitals yang baik. Yang dinilai adalah pengalaman pengguna nyata, bukan skor lab 0 sampai 100. Relevansi dan kualitas konten tetap menjadi dasar utama peringkat.
Menurut PageSpeed Insights dan web.dev, sebuah halaman dianggap baik bila Largest Contentful Paint paling lama 2,5 detik, Interaction to Next Paint paling lama 200 milidetik, dan Cumulative Layout Shift paling tinggi 0,1. Ketiganya diukur pada persentil ke-75 kunjungan, jadi sebagian besar pengunjung harus mendapat pengalaman baik, bukan hanya rata-rata.
Ceritakan situs Anda lewat WhatsApp, lalu kami jadwalkan sesi diagnosis gratis 60 sampai 90 menit untuk menentukan bagian mana yang paling layak dibenahi lebih dulu.