Google Score: Panduan Lengkap PageSpeed, Lighthouse, dan Core Web Vitals

Google score adalah skor performa website yang dihasilkan oleh tools resmi Google seperti PageSpeed Insights dan Lighthouse, dengan rentang nilai 0-100. Skor ini menjadi salah satu sinyal yang dipertimbangkan Google untuk menentukan ranking, meskipun bukan satu-satunya. Skor di atas 90 dikategorikan “bagus” (hijau), 50-89 “perlu perbaikan” (oranye), dan di bawah 50 “buruk” (merah).

Banyak pemilik website mengejar skor 100 sebagai target, padahal yang lebih penting adalah Core Web Vitals (LCP, INP, CLS) yang lulus threshold “Good” untuk minimal 75% pengunjung. Dari pengalaman kami menangani audit teknis untuk klien SEO seperti ByBamms (bybamms.com) dengan deadline pembenahan 22 Oktober 2026, fokus pada Core Web Vitals memberikan dampak ranking yang lebih konsisten dibanding sekadar mengejar skor sintetis Lighthouse.

Google score memberikan empat kategori penilaian utama: Performa, Aksesibilitas, Praktik Terbaik, dan SEO

Apa Itu Google Score dan Mengapa Banyak Orang Salah Memahaminya

Google score sebenarnya bukan satu metrik tunggal. Istilah ini sering dipakai untuk merujuk pada beberapa hal: skor PageSpeed Insights (lab + field data), skor Lighthouse (lab data), atau skor Core Web Vitals (field data dari Chrome User Experience Report). Tiga sumber ini sering memberikan angka berbeda untuk halaman yang sama, dan ini menjadi sumber kebingungan terbesar bagi pemilik website.

Menurut dokumentasi resmi Google Search Central, yang menjadi sinyal ranking adalah Core Web Vitals dari field data, bukan skor sintetis Lighthouse. Jadi kalau skor Lighthouse Anda 95 tapi field data CrUX menunjukkan 60% pengunjung mengalami LCP buruk, ranking Anda tetap terdampak negatif.

Yang jarang dibahas: skor Lighthouse bisa berbeda 10-20 poin antar pengetesan karena variabilitas jaringan dan CPU throttling. Kami pernah mengukur halaman yang sama lima kali berturut-turut dan mendapat skor 78, 85, 91, 82, 88. Ini normal. Yang penting adalah trend, bukan angka tunggal.

Cara Kerja Skor Lighthouse: Bobot dan Perhitungan

Lighthouse menghitung skor performa berdasarkan lima metrik utama dengan bobot berbeda. Memahami bobot ini penting karena banyak developer membuang waktu mengoptimasi metrik berbobot kecil sementara metrik besar diabaikan.

Bobot tertinggi ada di Total Blocking Time (30%) dan LCP (25%). Artinya, kalau Anda punya banyak JavaScript pihak ketiga yang berat (Google Tag Manager, Facebook Pixel, chat widget, heatmap), TBT Anda akan terjun bebas dan menyeret skor keseluruhan. Dari pengalaman kami menangani audit teknis di Cuztoom dan beberapa klien e-commerce, plugin chat widget seperti Tawk.to atau Crisp sering menambah TBT 300-500ms tanpa disadari.

Lighthouse menilai empat kategori utama, tetapi yang paling sering dijadikan “Google Score” adalah skor Performa

Lighthouse menggunakan distribusi log-normal berdasarkan data dari HTTPArchive untuk mengkonversi nilai metrik menjadi skor. Ini sebabnya kenaikan dari skor 50 ke 60 jauh lebih mudah dibanding kenaikan dari 90 ke 95. Marginal cost optimasi naik eksponensial saat mendekati 100.

Core Web Vitals: Tiga Metrik yang Benar-Benar Mempengaruhi Ranking

Core Web Vitals adalah subset dari metrik Lighthouse yang dipakai Google sebagai sinyal ranking sejak 2021. Sejak Maret 2024, INP (Interaction to Next Paint) menggantikan FID (First Input Delay) sebagai metrik responsivitas resmi. Tiga metrik wajib diperhatikan adalah LCP, INP, dan CLS.

Tiga metrik Core Web Vitals dengan threshold “Good” yang harus dilewati minimal 75% pengunjung

LCP (Largest Contentful Paint)

LCP mengukur kapan elemen terbesar di viewport (biasanya hero image atau heading utama) selesai dimuat. Threshold “Good” adalah 2.5 detik atau lebih cepat. Penyebab utama LCP buruk: hero image tidak dikompresi, server response lambat (TTFB tinggi), JavaScript yang memblokir render, atau lazy-loading yang salah diterapkan ke hero image.

Trik yang sering kami pakai: tambahkan fetchpriority="high" pada hero image dan preload font yang dipakai untuk LCP element. Cara ini menurunkan LCP 0.3-0.8 detik di banyak kasus tanpa perlu refactor besar.

INP (Interaction to Next Paint)

INP mengukur seberapa cepat halaman merespons interaksi pengguna (klik, tap, keypress). Threshold “Good” adalah 200 milidetik atau kurang. Metrik ini lebih ketat dari pendahulunya FID karena mengukur 98 persentil interaksi, bukan hanya interaksi pertama.

Penyebab INP buruk hampir selalu JavaScript: event handler yang berat, third-party scripts yang block main thread, atau React/Vue rendering yang tidak di-defer. Banyak developer mengejar skor Lighthouse 100 tapi mengabaikan INP. Lebih baik skor 85 dengan INP bagus daripada skor 100 tapi INP buruk, karena INP yang dihitung untuk ranking, bukan skor lab.

CLS (Cumulative Layout Shift)

CLS mengukur seberapa “jumpy” halaman saat di-load (elemen yang tiba-tiba bergeser). Threshold “Good” adalah 0.1 atau kurang. Penyebab utama: gambar tanpa atribut width dan height, font swap (FOIT/FOUT), iklan yang inject di tengah konten, atau widget yang load asinkron.

Cara Cek Google Score dengan Tools Resmi

Ada tiga tools utama untuk cek google score yang masing-masing punya kelebihan dan keterbatasan. Pilih sesuai kebutuhan: cek cepat, debugging mendalam, atau monitoring berkelanjutan.

1. PageSpeed Insights (PSI)

Tool gratis di pagespeed.web.dev yang menggabungkan lab data (Lighthouse) dan field data (CrUX). Cukup masukkan URL, klik Analyze, dapat skor mobile dan desktop dalam 30-60 detik. Tampilkan field data 28 hari terakhir kalau halaman punya cukup traffic.

2. Lighthouse di Chrome DevTools

Buka Chrome, tekan F12, pilih tab Lighthouse, pilih kategori (Performance, Accessibility, dll), klik Analyze page load. Berbeda dengan PSI, ini hanya lab data dan dijalankan dari mesin Anda sendiri (bukan server Google). Berguna untuk debugging karena bisa pakai DevTools network conditions, CPU throttling kustom, atau emulate device tertentu.

3. Search Console (Core Web Vitals Report)

Untuk monitoring jangka panjang, gunakan laporan Core Web Vitals di Google Search Console. Tampilkan grouping URL dengan masalah CWV serupa (e.g., 200 URL dengan LCP buruk semua dari template product page). Ini cara paling efisien untuk identifikasi pattern masalah di skala besar.

Yang sering terlewat: kalau halaman Anda baru dipublish atau traffic-nya rendah, PSI akan menampilkan pesan “The Chrome User Experience Report does not have sufficient real-world speed data”. Ini bukan error, hanya tanda butuh waktu (atau traffic) sampai data CrUX terkumpul. Untuk halaman seperti ini, andalkan lab data Lighthouse sebagai proxy.

Untuk panduan lengkap mengukur kecepatan website, baca cara cek speed website yang akurat dan tools cek performa website terbaik yang sudah kami review berdasarkan pengalaman audit puluhan klien.

Berapa Skor yang Dianggap Bagus?

Pertanyaan ini sering ditanyakan klien dan jawabannya kontroversial. Secara teknis, Google membagi rentang skor menjadi tiga: 0-49 (buruk, merah), 50-89 (perlu perbaikan, oranye), 90-100 (bagus, hijau). Tapi target realistis tergantung jenis website Anda.

Banyak konsultan SEO menjual janji “skor 100 dalam 7 hari” yang sebenarnya menyesatkan. Halaman dengan banyak fitur (kalkulator, filter dinamis, video embed, chat widget, A/B testing) hampir mustahil mendapat skor 100, dan kalaupun bisa, biasanya dengan trade-off fungsionalitas yang tidak sepadan.

Menurut kami, target yang sehat: pastikan Core Web Vitals lulus “Good” untuk minimal 75% pengunjung (sesuai standar Google), dan skor Performa Lighthouse di atas 70 untuk halaman kunci (homepage, landing page, product page top-seller). Sisanya tidak perlu dipaksakan.

Optimasi LCP: Quick Wins yang Berdampak Besar

LCP biasanya jadi metrik termudah untuk diperbaiki dengan dampak signifikan terhadap google score. Berikut quick wins yang sudah kami pakai berulang di puluhan klien.

1. Kompres dan convert hero image ke WebP/AVIF. Format WebP rata-rata 25-35% lebih kecil dari JPEG dengan kualitas visual setara. AVIF lebih kecil lagi tapi browser support belum 100%. Untuk hero image, kombinasikan: serve AVIF ke browser yang support, fallback ke WebP, lalu JPEG.

2. Preload font yang dipakai untuk LCP element. Kalau LCP element-nya heading dengan custom font (misal Poppins, Rubik), browser akan menunda render sampai font dimuat. Tambahkan <link rel="preload" href="/fonts/rubik.woff2" as="font" type="font/woff2" crossorigin> di head untuk mempercepat ini 200-500ms.

3. Hilangkan render-blocking resources. CSS dan JS di head yang tidak critical akan menunda render. Solusi: inline critical CSS (above-the-fold) di head, sisanya defer atau load async. Tools seperti Critical (Addy Osmani) bisa otomatisasi proses ini.

4. Improve TTFB di server. Time to First Byte yang lambat (>600ms) langsung mempengaruhi LCP. Solusi: gunakan caching plugin (W3 Total Cache, WP Rocket untuk WordPress), upgrade hosting kalau pakai shared hosting murah, atau pakai CDN seperti Cloudflare untuk cache statis.

Optimasi performa website melibatkan beberapa lapisan: gambar, kode, caching, dan infrastruktur

Salah satu klien kami di niche tech (ByBamms – bybamms.com) sedang menjalankan proses optimasi performa berkelanjutan dengan target deadline pembenahan teknis pada 22 Oktober 2026. Pendekatan kami tidak mengejar angka 100, tapi memastikan field data CrUX masuk kategori “Good” untuk semua halaman utama. Hasil pendekatan ini biasanya lebih sustainable karena tidak mengorbankan fitur dan tetap maintainable jangka panjang.

Mengatasi Total Blocking Time dan INP yang Buruk

TBT dan INP keduanya berkaitan dengan JavaScript yang memblokir main thread. Kalau metrik ini buruk, hampir pasti penyebabnya ada di kategori berikut: third-party scripts, framework overhead, atau event handler yang berat.

Audit third-party scripts dulu. Buka Chrome DevTools, tab Performance, record loading sekitar 5 detik. Cek bagian “Bottom-Up” untuk lihat script mana yang paling banyak makan main thread time. Pengalaman kami: Google Tag Manager + Facebook Pixel + chat widget kombinasi ini sering menyumbang 40-60% TBT total.

Defer atau lazyload script tidak critical. Bukan semua script perlu load di awal. Chat widget, heatmap (Hotjar/Microsoft Clarity), pixel tracking bisa di-defer 2-3 detik tanpa mempengaruhi tracking accuracy. Untuk WordPress, plugin Flying Scripts atau Perfmatters bisa otomatisasi ini.

Pecah long tasks menjadi chunks. Task JavaScript di atas 50ms blocking. Kalau punya processing berat (parsing JSON besar, rendering list panjang), pakai requestIdleCallback atau Web Workers untuk offload ke background thread. React 18+ punya useTransition hook yang membantu untuk hal ini.

Hindari layout thrashing. Membaca dan menulis ke DOM secara bergantian (e.g., baca offsetHeight lalu set style.height, lalu baca lagi) akan memaksa browser melakukan multiple reflow. Group semua read operations dulu, baru write operations. Pattern ini sering dipakai library seperti FastDOM.

Mencegah CLS: Aturan Praktis untuk Stabilitas Visual

CLS biasanya jadi metrik termudah untuk diperbaiki kalau Anda tahu polanya. Empat aturan emas yang kami terapkan di setiap audit teknis:

1. Set dimensi eksplisit untuk semua elemen yang load asinkron. Image, iframe, video, embed wajib ada width dan height attribute (atau aspect-ratio CSS). Browser akan reserve space sehingga konten lain tidak shift saat elemen tersebut dimuat.
2. Hindari inject konten di atas konten existing. Banner cookie, notifikasi push, atau iklan yang muncul di top of page dan dorong konten ke bawah = CLS killer. Solusi: gunakan fixed positioning dengan padding-top di body, atau tampilkan sebagai modal overlay.
3. Preload custom fonts dan pakai font-display: optional. FOIT (Flash of Invisible Text) atau FOUT (Flash of Unstyled Text) saat font swap = layout shift. Preload font WOFF2 dan set font-display: optional mengurangi shift drastis.
4. Animate dengan transform, bukan top/left/width/height. Properti transform tidak trigger reflow, sedangkan top/left bisa. Kalau perlu animasi (slider, accordion), pakai transform: translateX() atau scaleY().

Kami pernah audit website portfolio yang punya CLS 0.42 (sangat buruk) hanya karena testimonial slider memakai animasi height. Setelah diganti dengan transform: scaleY, CLS turun ke 0.05. Perubahan satu baris kode dampaknya besar.

Kesalahan Umum yang Membuat Google Score Susah Naik

Setelah menangani audit teknis untuk lebih dari 30 klien, kami melihat pola kesalahan yang sama berulang. Berikut daftar yang paling sering ditemukan:

1. Lazy-loading hero image. Banyak developer pakai loading="lazy" di SEMUA gambar, termasuk hero. Padahal hero image-lah yang biasanya jadi LCP element. Kalau di-lazy-load, browser akan menunda fetch sampai dekat viewport, padahal sudah di viewport pertama kali. Solusi: lazy-load hanya gambar di bawah fold, hero image pakai fetchpriority="high".

2. Plugin chat dan tracking yang overkill. Memasang Google Tag Manager + GA4 + Facebook Pixel + LinkedIn Insight + Microsoft Clarity + Hotjar + Tawk.to di satu halaman. Tidak heran TBT 800ms+. Pertanyaan tajam: data dari semua tracker itu benar-benar dipakai untuk decision making, atau hanya untuk “siapa tahu nanti perlu”?

3. Mengejar skor 100 dengan trick ngakal. Beberapa developer disable JavaScript tertentu hanya saat user-agent Lighthouse terdeteksi, atau pakai service worker yang serve cached version untuk Lighthouse. Skor di Lighthouse jadi 100, tapi field data CrUX tetap buruk karena pengguna real tetap mengalami slow site. Cheating dan akhirnya merugikan diri sendiri.

4. Tidak compress dan resize gambar. Upload foto produk 4MB resolusi 4000×3000 padahal di halaman hanya ditampilkan 600×450. Browser tetap download file utuh. Solusi: pakai srcset + WebP, atau pakai image CDN seperti Cloudinary, ImageKit, atau Cloudflare Images yang otomatis serve sesuai device.

5. Render-blocking CSS yang besar. File CSS 200KB+ di head akan blocking render sampai selesai parse. Solusi: split CSS menjadi critical (inline) dan non-critical (lazy load). Tools seperti PurgeCSS atau UnusedCSS bisa hapus CSS yang tidak terpakai.

Untuk audit menyeluruh masalah teknis SEO yang sering bikin website lambat, baca panduan mengatasi masalah teknis SEO dan trik technical SEO untuk pemula.

Apakah Google Score Benar-Benar Mempengaruhi Ranking?

Jujur saja: pengaruh google score terhadap ranking lebih kecil dari yang banyak orang pikirkan. Google sendiri menyatakan Core Web Vitals adalah “tiebreaker”, artinya hanya berpengaruh signifikan kalau dua halaman punya kualitas konten setara. Konten tetap raja, performa adalah pelengkap.

Yang sering kami lihat: website dengan skor Lighthouse 60 tapi konten sangat relevan dan otoritatif tetap bisa ranking 1, sementara website dengan skor 95 tapi konten dangkal tidak bisa lewat halaman 5. Ini sejalan dengan guideline Helpful Content Google yang menekankan kualitas konten sebagai faktor utama.

Tapi bukan berarti performa tidak penting. Dampak nyata yang kami ukur dari klien:

• Bounce rate turun 10-25% setelah LCP membaik dari 4s ke 2s
• Conversion rate naik 5-15% di halaman product e-commerce setelah CWV pass
• Mobile traffic naik karena Google lebih sering menampilkan halaman cepat di mobile SERP
• AdSense revenue naik karena pageviews per session meningkat

Jadi optimasi google score bukan untuk ranking semata, tapi untuk user experience yang akhirnya berdampak ke business metrics. Kerangka berpikir ini lebih sehat daripada mengejar angka di Lighthouse.

Tools Monitoring Performa Website Secara Berkelanjutan

Optimasi sekali tidak cukup. Performa website cenderung mengalami regression seiring waktu (developer tambah fitur baru, content team upload gambar besar, dll). Wajib ada monitoring berkelanjutan.

Untuk mayoritas klien Creativism, kami biasanya merekomendasikan kombinasi PSI (manual check ad-hoc) + Search Console CWV (monitoring otomatis) + DebugBear atau Treo untuk tracking historis dengan budget di bawah $50/bulan. Kombinasi ini cukup untuk 95% kebutuhan SEO agency atau in-house team.

Dari pengalaman kami menangani SEO untuk klien seperti yang ada di layanan SEO Jogja, monitoring CWV jadi salah satu deliverable bulanan yang dihargai klien karena memberikan visibilitas masalah teknis sebelum berdampak ke ranking.

Hubungan Google Score dengan Strategi SEO Modern

Google score dan optimasi performa adalah bagian dari technical SEO, tapi bukan keseluruhan SEO. Banyak praktisi yang terlalu fokus di sini sampai mengabaikan content dan link building yang dampaknya jauh lebih besar.

Pendekatan kami di Creativism untuk klien SEO: alokasikan 60% effort untuk content quality dan strategi keyword, 25% untuk technical SEO termasuk performa, 15% untuk off-page (backlinks, brand mentions). Kerangka 60-25-15 ini hasil iterasi dari menangani 27+ project SEO selama bertahun-tahun.

Untuk yang masih bingung soal kapan harus prioritas content vs technical, baca panduan audit SEO website lengkap dan panduan EEAT untuk meningkatkan kepercayaan website yang sudah kami susun berdasarkan studi kasus klien-klien SEO Creativism.

Kesimpulan: Pakai Google Score sebagai Compass, Bukan Tujuan

Google score adalah indikator berguna untuk mengukur kesehatan teknis website, tapi bukan target final. Yang seharusnya jadi target adalah Core Web Vitals dari field data yang lulus “Good” untuk minimal 75% pengunjung Anda. Ini standar yang dipakai Google untuk ranking, bukan skor sintetis Lighthouse.

Tiga prinsip yang kami pegang saat optimasi: pertama, kejar field data bukan lab data. Kedua, prioritaskan LCP dan INP karena dampak terbesar ke user experience dan ranking. Ketiga, jangan korbankan fungsionalitas hanya untuk angka di Lighthouse, karena akhirnya yang penting adalah konversi dan retention pengguna.

Kalau Anda butuh bantuan audit teknis dan optimasi performa website yang berdampak ke SEO ranking, tim Creativism punya pengalaman menangani audit untuk berbagai jenis website (e-commerce, blog, SaaS, landing page). Hubungi kami untuk konsultasi jasa SEO komprehensif atau jasa perbaikan website yang sudah membantu puluhan bisnis Indonesia memperbaiki performa digitalnya.

Pertanyaan Umum (FAQ)