Optimalkan PageSpeed Insights untuk SEO Website: “Kemauan Dia” Itu Apa Aja Sih?

Kalau PageSpeed Insights (PSI) itu orang, dia tipe yang cerewet tapi bener: dia nggak peduli kamu “udah niat”, dia cuma lihat pengalaman pengguna beneran. PSI ngasih skor dan daftar tugas yang ujung-ujungnya satu: bikin halaman cepat, responsif, dan stabil. Itu juga nyambung ke SEO karena Google pakai sinyal pengalaman halaman (termasuk Core Web Vitals) buat membantu menentukan kualitas pengalaman pengguna. PSI sendiri menjelaskan kalau dia melaporkan pengalaman pengguna di mobile & desktop dan ngasih saran perbaikan.

Di artikel ini kita bedah:

• Apa yang sebenarnya PSI “mau” (biar kamu nggak ngikutin checklist secara buta).
• Bedanya data lapangan vs data lab (yang sering bikin orang debat di grup).
• Checklist teknis paling berdampak untuk Performance + SEO.
• Strategi aman buat skrip pihak ketiga (iklan, analytics, widget).
• FAQ yang bisa kamu tempel untuk rich result.

1) PSI Itu Ngejar Apa? (Bukan Sekadar Skor Hijau)

PSI pada dasarnya ngejar 2 hal:

1. Pengalaman pengguna nyata (Field Data) dari Chrome User Experience Report (kalau tersedia).
2. Simulasi terkontrol (Lab Data) yang dihitung Lighthouse.

Kenapa penting? Karena Field Data itu “kenyataan di lapangan”: pengguna pakai HP kentang, sinyal naik-turun, sambil buka 10 tab. Sedangkan Lab Data itu “uji coba di ruangan steril”: kondisi jaringan & device disimulasikan. PSI menggabungkan keduanya, tapi keputusan prioritas kamu sebaiknya mulai dari Field Data kalau ada. PSI sendiri mendokumentasikan konsep ini: dia menampilkan pengalaman pengguna dan rekomendasi perbaikan.

Intinya: skor 95 tapi pengguna tetap ngelag = tetap salah. Skor 85 tapi Field Data “Good” = kadang lebih sehat daripada ngejar 100 tapi nyiksa maintainability.

2) Core Web Vitals: Tiga Raja yang Harus Kamu Jinakkan

“Kemauan dia” yang paling utama adalah lulus Core Web Vitals:

• LCP (Largest Contentful Paint) = seberapa cepat konten utama muncul.
• INP (Interaction to Next Paint) = seberapa responsif halaman saat orang klik, tap, ketik.
• CLS (Cumulative Layout Shift) = seberapa stabil layout (nggak loncat-loncat).

Catatan penting: INP menggantikan FID sebagai bagian Core Web Vitals sejak Maret 2024. Jadi kalau checklist kamu masih ngomongin FID, itu checklist nostalgia.

Google juga menjelaskan bahwa CWV yang dipakai adalah LCP, INP, CLS dan bisa dipantau lewat Search Console.

3) Field Data vs Lab Data: Kenapa Angkanya Sering “Nggak Nyambung”

Field Data biasanya muncul di PSI kalau URL kamu punya traffic cukup. Ini yang paling relevan buat SEO karena menggambarkan pengalaman real user.

Lab Data (Lighthouse) berguna buat:

• Debugging masalah spesifik (misalnya “unused CSS”, “render-blocking resources”).
• Uji perubahan sebelum deploy.
• Ngejar penyebab teknis, bukan sekadar angka.

Chrome Lighthouse sendiri dijelaskan sebagai tool audit otomatis untuk performance, SEO, accessibility, dan lainnya.

4) Cara Baca PSI Biar Nggak Salah Kaprah

Biasanya PSI kasih kamu bagian-bagian ini:

• Performance Score (hasil Lighthouse).
• Metrics: FCP, LCP, Speed Index, TBT (lab), CLS, INP (field/lab tergantung context).
• Opportunities: peluang hemat waktu/ukuran.
• Diagnostics: akar masalah (DOM terlalu besar, JS berat, dll).
• SEO: cek hal dasar (meta, robots, canonical, mobile-friendly, dsb).

PSI juga ngasih kategori audit (Performance, Accessibility, Best Practices, SEO) karena basisnya Lighthouse.

Prioritas cepat:

1. Pastikan LCP bagus (biasanya hero image/heading/cover).
2. Tekan INP (JS berat, event handler kebanyakan, plugin/ads yang nahan main thread).
3. Hilangkan CLS (gambar tanpa ukuran, font swap yang bikin loncat, slot iklan tanpa tinggi tetap).

5) Checklist “Kemauan PSI” yang Paling Berdampak (Praktis & Realistis)

5.1 Optimasi LCP (yang paling sering jadi biang kerok)

Target: konten utama muncul cepat. Biasanya masalahnya ada di:

• Gambar hero terlalu besar dan tidak di-compress.
• CSS/JS nge-block render (render-blocking).
• Server lambat (TTFB tinggi).

Action cepat:

• Gunakan gambar modern (WebP/AVIF) + ukuran responsif (srcset).
• Pastikan elemen LCP tidak lazy-load kalau itu hero paling atas (lazy-load cocoknya untuk konten bawah).
• Preload aset penting: font utama, hero image (secukupnya, jangan preload semua).
• Kurangi CSS kritikal: pisahkan critical CSS untuk above-the-fold.

5.2 Optimasi INP (halaman cepat tapi pas diklik ngadat itu dosa besar)

INP menilai responsivitas interaksi. Sejak INP jadi CWV (gantikan FID), fokusnya bukan cuma klik pertama, tapi pengalaman interaksi selama pengguna ada di halaman.

Penyebab umum INP jelek:

• Bundle JS kebesaran, parsing lama.
• Event listener kebanyakan (scroll/resize tanpa throttle).
• Script pihak ketiga (ads, tracker) nahan main thread.
• Komponen UI berat (carousel, modal, editor) yang dipanggil di awal padahal belum dipakai.

Action cepat:

• Code-splitting: load JS sesuai kebutuhan (route-based / component-based).
• Defer/async script non-kritis, terutama third-party.
• Hindari kerja berat di main thread: pecah tugas, pakai requestIdleCallback / web worker (kalau relevan).
• Rapikan DOM: makin besar DOM, makin mahal layout & style recalculation.

5.3 Optimasi CLS (jangan bikin layout loncat kayak kaget liat tagihan hosting)

CLS jelek biasanya karena:

• Gambar tanpa width/height atau aspect-ratio.
• Slot iklan/banner muncul belakangan tanpa space cadangan.
• Font loading bikin teks “geser” (FOIT/FOUT parah).

Action cepat:

• Tetapkan ukuran media (width/height) atau CSS aspect-ratio.
• Untuk iklan, buat container dengan tinggi minimal (placeholder) agar layout stabil.
• Gunakan font-display: swap dan cocokkan fallback font metrics bila perlu.

6) Masalah “Klasik PSI” dan Cara Menjawabnya

6.1 “Gunakan durasi cache yang efisien”

PSI pengen aset statis (CSS/JS/img/font) punya cache panjang supaya kunjungan ulang makin cepat.

• Set Cache-Control untuk aset versi-hash (misal app.9c1a.css) ke 30 hari–1 tahun.
• Untuk file yang sering berubah tapi namanya sama, jangan kasih cache kelewat panjang tanpa strategi versioning.

6.2 “Kurangi CSS yang tidak digunakan”

Ini biasanya karena:

• Pakai framework besar tapi halaman cuma pakai 20% class.
• CSS gabungan untuk semua halaman disuntik ke semua route.

Solusi:

• Purge/treeshake CSS (Tailwind purge, PurgeCSS, atau build pipeline setara).
• Pecah CSS per halaman (atau minimal per grup halaman).

6.3 “Optimalkan ukuran DOM”

DOM kebesaran bikin browser ngos-ngosan saat layouting. Gejalanya:

• Halaman berat di HP.
• Scroll patah-patah.
• INP/TBT jelek.

Solusi:

• Kurangi wrapper yang nggak penting.
• Paginate/list virtualization untuk daftar panjang.
• Jangan render 200 kartu produk sekaligus kalau bisa “load more”.

7) Third-Party Script (Iklan, Analytics, Widget): Musuh Dalam Selimut

PSI sering “teriak” karena script pihak ketiga bikin:

• Request tambahan (DNS, TLS, download).
• JS berat mengunci main thread.
• CLS karena slot iklan muncul telat.

Aturan main yang aman:

• Load script non-kritis dengan defer atau async sesuai kebutuhan.
• Tunda render iklan di atas fold jika mengorbankan LCP (tapi tetap patuh kebijakan platform iklan).
• Siapkan container placeholder untuk iklan agar layout tidak shifting.
• Batasi vendor: satu analytics cukup, jangan semua dipasang.

PSI juga secara umum menilai pengalaman pengguna dan memberi saran, jadi menata third-party script itu bagian penting dari strategi.

8) SEO di PSI: “Biar Mesin Paham, Bukan Cuma Cepat”

Bagian SEO di Lighthouse/PSI biasanya mengaudit hal dasar, misalnya:

• Title & meta description ada dan masuk akal.
• Robots meta tidak memblokir indexing.
• Viewport mobile benar.
• Link punya teks yang jelas.
• Structured data valid (kalau ada).

Tips: jangan cuma lulus checklist. SEO yang kuat butuh struktur konten yang rapi:

• H1 satu, jelas topiknya.
• H2/H3 logis, bukan buat gaya-gayaan.
• Internal link ke halaman relevan (cluster/pillar).
• Gambar pakai alt yang deskriptif.

9) Workflow Praktis: Benerin PSI Tanpa Drama

1. Mulai dari halaman paling penting: homepage, halaman produk/layanan utama, artikel pillar.
2. Cek Field Data (kalau ada) untuk lihat masalah yang benar-benar dialami user.
3. Debug dengan Lighthouse di local/staging untuk cari penyebab teknis.
4. Perbaiki dari yang paling berdampak: LCP → INP → CLS → caching/unused CSS → DOM.
5. Deploy, lalu cek ulang PSI dan monitor Search Console Core Web Vitals report.

Search Console mengelompokkan URL berdasarkan status “Good / Needs improvement / Poor” untuk metrik LCP, INP, CLS berdasarkan data pengguna nyata. Jadi jangan lupa monitor di sana juga.

10) Contoh Gambar: “PageSpeed Checklist Hijau”

Silakan gunakan gambar di atas sebagai referensi visual “skor hijau”. Untuk dipasang di artikel kamu, biasanya kamu akan upload gambar sendiri ke media manager (TinyMCE) lalu sisipkan seperti ini:

FAQ: Optimasi PageSpeed Insights untuk SEO

Apakah skor 100 wajib untuk SEO?

Tidak wajib. Yang paling penting adalah Core Web Vitals lulus dan pengalaman pengguna nyata membaik. Skor 100 kadang bikin kamu over-optimizing sampai mengorbankan fitur.

Kenapa PSI mobile sering lebih jelek daripada desktop?

Karena mobile mensimulasikan device lebih lambat dan jaringan lebih terbatas. Selain itu, layout mobile sering lebih berat (sticky CTA, modal, slider, iklan).

Mana yang harus dipercaya: Lighthouse atau Field Data?

Untuk keputusan “pengalaman nyata”, utamakan Field Data. Untuk “nyari penyebab teknis”, pakai Lighthouse/Lab Data. PSI sendiri memang memadukan perspektif itu.

INP jelek biasanya karena apa?

Sering karena JavaScript berat dan third-party script. INP menggantikan FID sejak Maret 2024, jadi fokusnya respons interaksi selama sesi.

Apakah iklan (Adsense) bisa bikin PSI turun?

Bisa. Iklan adalah third-party script yang dapat menambah request dan kerja main thread. Solusinya bukan “hapus iklan”, tapi atur loading, placeholder layout, dan batasi vendor yang nggak perlu.