PageSpeed Insight: Cara Membaca Skor dan Memperbaiki Kecepatan Web

PageSpeed Insight (nama resminya PageSpeed Insights) adalah alat gratis dari Google untuk mengukur seberapa cepat dan stabil sebuah halaman terasa bagi pengunjung, di ponsel maupun desktop. Kamu cukup memasukkan URL di pagespeed.web.dev, lalu alat ini menampilkan dua jenis data: pengalaman pengguna nyata selama 28 hari terakhir dan hasil simulasi lab dengan skor 0 sampai 100, lengkap dengan saran perbaikan.

Artikel ini membahas cara memakai PageSpeed Insights, cara membaca setiap bagian laporannya, beda data lapangan dan data lab, ambang Core Web Vitals, serta urutan perbaikan yang masuk akal untuk situs berita, blog, atau toko online. Kalau kamu sedang menyiapkan halaman tujuan untuk artikel SEO atau kampanye backlink, halaman yang cepat membuat setiap kunjungan dari tautan itu lebih bernilai.

Apa itu PageSpeed Insight dan kenapa penting

Menurut dokumentasi resmi Google, PageSpeed Insights (PSI) melaporkan pengalaman pengguna sebuah halaman di perangkat mobile dan desktop, lalu memberi saran cara memperbaikinya. Alat ini tidak hanya menghitung "seberapa cepat", tetapi juga seberapa cepat halaman merespons klik dan seberapa stabil tata letaknya saat dimuat.

Kecepatan penting karena dua alasan. Pertama, pengunjung yang menunggu terlalu lama cenderung pergi sebelum membaca. Kedua, Google menyebut pengalaman halaman, termasuk Core Web Vitals, sebagai salah satu hal yang dipertimbangkan sistem peringkatnya. Namun dokumen yang sama menegaskan bahwa konten yang relevan dan bermutu tetap jauh lebih menentukan. Jadi anggap kecepatan sebagai syarat dasar, bukan jalan pintas ke halaman pertama.

Bagi pemilik media dan blog yang menjual artikel bersponsor atau penempatan tautan, kecepatan juga soal kepercayaan. Pengiklan yang memeriksa situsmu akan melihat apakah halaman artikelnya nyaman dibaca. Halaman yang lambat dan melompat-lompat saat dimuat memberi kesan situs kurang terawat, walaupun isinya bagus.

Cara memakai PageSpeed Insights langkah demi langkah

Pemakaiannya sederhana dan tidak perlu login:

1. Buka pagespeed.web.dev.
2. Tempel URL lengkap halaman yang ingin diuji, termasuk https://. Uji URL yang sebenarnya dikunjungi orang, misalnya satu artikel populer, bukan hanya beranda.
3. Klik Analisis dan tunggu sekitar setengah sampai satu menit sampai laporan selesai.
4. Pilih tab Seluler atau Desktop. Laporan mobile tampil lebih dulu dan biasanya lebih ketat.
5. Baca bagian atas (data pengguna nyata) lebih dulu, lalu turun ke skor dan diagnosis lab.
6. Salin tautan laporan dengan tombol berbagi bila ingin mengirimnya ke developer.

Untuk pengujian rutin banyak URL, Google menyediakan PageSpeed Insights API. API ini cocok untuk tim teknis yang ingin mencatat hasil secara otomatis. Pemakaian rutin memerlukan kunci API dan dibatasi kuota harian, jadi untuk pengecekan sesekali antarmuka web sudah cukup.

Cara membaca laporan PageSpeed Insights

Laporan PSI terdiri dari dua lapis. Lapis atas berisi data pengguna nyata, lapis bawah berisi data lab dan diagnosis. Keduanya menjawab pertanyaan yang berbeda, jadi jangan hanya melihat angka skor besar di tengah halaman.

Data pengguna nyata (data lapangan)

Data ini berasal dari Chrome User Experience Report (CrUX), yaitu kumpulan pengalaman pengguna Chrome sungguhan. PSI menampilkan metrik FCP, LCP, INP, dan CLS selama periode 28 hari terakhir, ditambah TTFB sebagai metrik eksperimental. Nilai yang ditampilkan adalah persentil ke-75, artinya tiga perempat kunjungan mengalami hasil yang sama atau lebih baik.

Halaman baru atau yang pengunjungnya sedikit sering belum punya data. Dalam kondisi itu PSI beralih ke data tingkat origin, yaitu gabungan pengalaman di semua halaman situs. Kalau origin juga kurang data, bagian ini kosong dan kamu hanya bisa berpegang pada data lab.

Di bagian ini juga ada penilaian Core Web Vitals: lulus atau gagal. Dokumentasi PSI menjelaskan bahwa halaman lulus bila persentil ke-75 dari LCP, INP, dan CLS semuanya berada di kategori Baik.

Data lab dan skor Performa

Data lab dihasilkan oleh Lighthouse yang memuat halaman dalam lingkungan simulasi. Untuk mobile, dokumentasi PSI menyebut Lighthouse mensimulasikan perangkat kelas menengah (Moto G4) di jaringan seluler, sedangkan desktop memakai emulasi koneksi kabel. Hasilnya berupa skor untuk empat kategori: Performa, Aksesibilitas, Praktik Terbaik, dan SEO.

Skor Performa dibaca dengan rentang berikut: 90 ke atas baik, 50 sampai 89 perlu perbaikan, dan di bawah 50 buruk. Halaman Lighthouse performance scoring menambahkan bahwa skor 100 sangat sulit dicapai dan tidak diharapkan.

Beda data lapangan dan data lab

Dua jenis data ini sering terlihat bertentangan. Halaman bisa mendapat skor lab 60 tetapi lulus Core Web Vitals, atau sebaliknya. Itu wajar karena cara pengambilannya berbeda.

Patokannya sederhana. Kalau data lapangan tersedia, jadikan itu tujuan utama karena itulah pengalaman pengunjungmu. Gunakan data lab untuk menemukan penyebab dan untuk menguji apakah perbaikan bekerja, karena data lapangan baru bergerak setelah beberapa minggu.

Ambang Core Web Vitals yang perlu kamu hafal

Core Web Vitals terdiri dari tiga metrik. Ambang di bawah ini diambil dari web.dev dan tabel ambang di dokumentasi PSI.

Di luar ketiganya, PSI juga menampilkan First Contentful Paint (baik bila 1,8 detik atau kurang) dan Time to First Byte (baik bila 800 ms atau kurang) sebagai petunjuk tambahan. TTFB yang tinggi biasanya menandakan server atau hosting yang lambat merespons, sebelum browser sempat menggambar apa pun.

Dari mana skor 0 sampai 100 berasal

Skor Performa bukan angka misterius. Menurut dokumentasi Lighthouse, skor itu adalah rata-rata berbobot dari lima metrik lab. Di Lighthouse 10 bobotnya: Total Blocking Time 30 persen, Largest Contentful Paint 25 persen, Cumulative Layout Shift 25 persen, First Contentful Paint 10 persen, dan Speed Index 10 persen.

Artinya, tiga metrik pertama menyumbang 80 persen skor. Kalau skormu rendah, lihat dulu nilai TBT (biasanya akibat JavaScript yang berat), LCP (biasanya gambar utama yang besar atau server lambat), dan CLS (biasanya gambar, iklan, atau embed tanpa ukuran tetap). Memperbaiki Speed Index saja jarang mengubah skor secara berarti.

Skor juga bisa naik turun antarpengujian walaupun halaman tidak diubah. Dokumentasi PSI menyebut pengujian berjalan di pusat data Google yang kondisi jaringannya bisa berbeda. Iklan, widget, dan skrip pihak ketiga yang berubah setiap muat halaman ikut menambah variasi. Karena itu, uji beberapa kali sebelum menyimpulkan.

Urutan perbaikan yang masuk akal

Daftar saran di bagian bawah laporan bisa terasa panjang. Urutkan berdasarkan metrik yang gagal, lalu kerjakan dari yang dampaknya paling besar.

1. Gambar utama terlalu besar (LCP). Kompres dan ubah ke format modern seperti WebP atau AVIF, sajikan ukuran yang sesuai layar, dan jangan menunda pemuatan gambar yang tampil paling atas.
2. Server lambat merespons (TTFB, LCP). Aktifkan cache halaman, pakai CDN, dan cek apakah paket hosting masih memadai untuk jumlah pengunjungmu.
3. JavaScript berat (TBT, INP). Hapus plugin atau skrip yang tidak dipakai, tunda skrip yang tidak dibutuhkan saat awal muat, dan batasi widget pihak ketiga.
4. Tata letak bergeser (CLS). Beri ukuran lebar dan tinggi pada gambar, video, dan slot iklan, serta hindari menyisipkan banner di atas konten setelah halaman tampil.
5. Font dan CSS yang menghambat tampilan (FCP). Muat hanya font yang dipakai dan kurangi CSS yang memblokir render.
6. Uji ulang dan catat. Jalankan PSI lagi setelah setiap perubahan, simpan tautan laporannya, lalu pantau data lapangan beberapa minggu kemudian.

Kecepatan juga berkaitan dengan cara mesin pencari menemukan halaman. Halaman cepat yang tertaut rapi lewat internal link dan diumumkan lewat IndexNow lebih mudah dijangkau crawler. Sebaliknya, tautan mati yang menumpuk akibat link rot atau broken link membuang waktu crawler dan pengunjung.

Kesalahan umum saat memakai PageSpeed Insights

• Mengejar skor 100. Dokumentasi Lighthouse sendiri menyebut skor sempurna tidak diharapkan. Fokus pada kategori Baik untuk Core Web Vitals.
• Hanya menguji beranda. Pengunjung dari mesin pencari dan backlink lebih sering mendarat di halaman artikel. Uji template artikel, kategori, dan halaman produk.
• Menyimpulkan dari satu pengujian. Hasil lab bervariasi. Jalankan tiga sampai lima kali dan lihat kecenderungannya.
• Mengabaikan data lapangan. Skor lab yang naik belum tentu berarti pengunjung merasakan perbedaan. Pastikan data CrUX ikut membaik dalam beberapa minggu.
• Memasang plugin pengoptimal tanpa menguji ulang. Beberapa pengaturan agresif justru merusak tampilan atau fungsi. Uji tampilan halaman setelah setiap perubahan.
• Menganggap kecepatan sebagai faktor ranking utama. Halaman cepat yang isinya tipis tetap kalah dari halaman lengkap yang menjawab pertanyaan pembaca. Kecepatan melengkapi strategi SEO off page dan konten, bukan menggantikannya.

Kapan perlu developer, dan apa yang bisa kamu kerjakan sendiri

Sebagian perbaikan bisa dikerjakan pemilik situs tanpa menulis kode, terutama di WordPress: mengompres gambar sebelum diunggah, menghapus plugin yang tidak terpakai, mengaktifkan cache bawaan hosting, dan mengurangi widget di sidebar. Perubahan ini aman dan sering memberi hasil paling cepat.

Perbaikan yang menyentuh tema, urutan pemuatan skrip, konfigurasi server, atau CDN sebaiknya dikerjakan developer. Kirim tautan laporan PSI, sebutkan metrik mana yang gagal di data lapangan, dan minta mereka menguji ulang di halaman yang sama setelah perubahan. Dengan begitu, diskusinya berangkat dari data yang sama.

Kalau kamu publisher yang ingin menawarkan situs di marketplace, halaman yang cepat dan stabil membuat calon pengiklan lebih yakin. Lihat cara menjual backlink dan artikel bersponsor di Liputin, atau pelajari cara kerja pemesanan dan pemantauan tautannya. Untuk pengiklan, situs dengan metrik domain authority yang wajar dan halaman cepat biasanya lebih layak dipertimbangkan di katalog media.

Penutup

PageSpeed Insight memberi dua sudut pandang dalam satu laporan: apa yang dialami pengunjung nyata dan apa penyebabnya menurut simulasi. Baca data lapangan lebih dulu, pastikan LCP, INP, dan CLS masuk kategori Baik, lalu pakai skor dan diagnosis lab untuk menentukan urutan perbaikan. Uji beberapa kali, perbaiki template, dan pantau hasilnya beberapa minggu kemudian.