Skor buruk di PageSpeed Insights tidak selalu berarti Anda wajib merombak website hari itu juga. Variasi pengukuran lab, perbedaan versi Lighthouse, throttling simulasi, dan laporan issue terbuka di repositori Google Chrome menunjukkan bahwa bug Lighthouse atau artefak runtime kadang ikut membentuk angka yang Anda lihat. Pertanyaan praktisnya bukan apakah alat audit sempurna. Yang penting: apakah satu run kontradiktif cukup kuat untuk mengubah preload, gambar hero, cache, atau hosting.
Artikel ini memberi urutan bukti untuk developer WordPress, technical SEO, dan tim QA. Anda akan melihat kapan angka masuk rentang variasi normal, kapan signature issue open layak dicurigai, dan kapan trace plus data field menunjukkan bottleneck di sisi situs. Lighthouse tetap berguna sebagai lab diagnostic, asalkan Anda tidak memperlakukan satu skor sebagai vonis final.
- Satu run PSI atau DevTools rentan variasi, jadi median beberapa run wajib sebelum keputusan besar.
- Kontradiksi internal (headline vs breakdown, filmstrip vs NO_LCP, observed vs simulated) lebih kuat sebagai sinyal curiga daripada skor rendah saja.
- Issue GitHub open ≠ konfirmasi resmi Google, kecuali maintainer, label, PR, atau changelog menyatakan fix.
- Lab CrUX field data sengaja berbeda window dan populasi, walau keduanya tetap dipakai untuk arah diagnosis.
- Ubah kode atau server hanya setelah waterfall, trace, atau RUM menunjukkan kausalitas, bukan karena satu angka anomali.
Empat Penyebab Skor PageSpeed Terlihat Salah
Sebelum mengejar optimasi, pisahkan empat kelompok penyebab. Pertama, variasi pengukuran normal: cache hangat atau dingin, beban server, iklan pihak ketiga, consent banner, atau CPU mesin uji berbeda antar-run. Dokumentasi variability Lighthouse menegaskan skor performance berubah meski Anda tidak menyentuh kode. Median lima run jauh lebih stabil daripada satu percobaan.
Kedua, perbedaan lingkungan: versi Lighthouse, HeadlessChrome, sumber alat (PSI, CLI, DevTools), dan mode throttling. Ketiga, masalah nyata di website: TTFB tinggi, LCP element terlambat, JavaScript blocking, atau font yang menunda paint. Keempat, bug atau limitasi di browser, mesin simulasi Lantern, gatherer insight, atau integrasi PSI. Keputusan optimasi masuk akal hanya setelah Anda membuang kelompok keempat dan variasi normal, bukan ketika skor pertama kali turun drastis.
Mengapa Satu Run Lighthouse Tidak Cukup
Page nondeterminism, contention CPU, dan browser nondeterminism tercatat sebagai sumber variabilitas tinggi di dokumentasi resmi. Jadi, run tunggal di laptop sambil membuka banyak tab bisa memberi skor tidak representatif. Satu tes PSI saat CDN sedang miss pun demikian, tanpa ada bug sama sekali.
Dokumentasi menyarankan mengulang audit dan memakai agregat seperti median. Alat seperti Lighthouse CI dapat menjalankan lima iterasi lalu memilih run representatif. Median stabil pun tidak menjamin hilangnya bias sistematis bila runtime memuat bug headless. Simpan distribusi run (min, max, cluster), bukan angka tengah saja.
Bila lima run menghasilkan spread wajar di sekitar median, dan waterfall selaras dengan bottleneck yang terlihat, Anda lebih aman lanjut ke optimasi server atau frontend. Panduan cara meningkatkan skor Google Lighthouse fokus ke pemisahan masalah server versus kode. Gunakan panduan itu setelah Anda yakin angka lab dapat dipercaya untuk keputusan itu.
Issue #17148: FCP/LCP Headless yang Dilaporkan
Issue terbuka #17148 (per 28 Oktober 2026) melaporkan observed FCP/LCP di run headless, termasuk infrastruktur PSI, kadang naik satu hingga dua detik penuh. Angka itu dibanding kapan halaman siap paint. Pelapor menyertakan ratusan run PSI, trace Lighthouse, pola bimodal, dan gejala observedLoad < observedFirstContentfulPaint dengan observedFCP == observedLCP sampai milidetik, plus filmstrip putih pada frame tertentu.
Status issue masih open tanpa label resmi maintainer pada snapshot riset. Itu berarti bukti reproduksi dari komunitas kuat, tetapi bukan pernyataan Google bahwa semua PSI salah satu hingga dua detik. Jangan menulis bahwa WordPress otomatis korban, atau bahwa fix sudah tersedia. Gunakan wording aman: dalam reproduksi yang dilaporkan, signature tersebut layak dicurigai sebelum Anda mengubah stack production.
Signature praktis yang bisa Anda cek di JSON report: load selesai sebelum first paint tercatat, FCP dan LCP identik, dan distribusi run membentuk cluster diskret alih-alih noise halus. Contoh band kosong ada di antara 500–1250 ms dan 1750–2250 ms. Bila pola itu muncul di PSI tetapi trace lokal headful konsisten cepat, dokumentasikan versi Chrome dan simpan artefak sebelum rollback optimasi yang sebenarnya membantu pengguna.
Lapisan Bug Lighthouse: Dari Browser Sampai PSI
Bug audit performa jarang satu tombol rusak; rantainya menelusuri beberapa titik. Compositor browser dapat memengaruhi kapan BeginFrame dikirim ke halaman, seperti yang dibahas reporter #17148 lewat trace kategori viz. Mesin simulasi Lantern memproyeksikan metrik throttled dari trace unthrottled, dan maintainer masih menyelidiki edge case di graf dependensi LCP.
Gatherer dan insight menentukan apakah rekomendasi seperti Improve image delivery cocok dengan resource yang browser benar-benar pilih. Integrasi PSI dan DevTools menambah variabel deployment: versi Lighthouse di server Google bisa berbeda timing dengan CLI lokal Anda. Maka bandingkan alat kedua plus baca runtime di report (versi Lighthouse, user agent) sebelum menyimpulkan situs Anda broken.
Dokumentasi throttling Lighthouse menjelaskan trade-off simulated versus DevTools throttling. Keduanya bukan replika jaringan nyata sempurna. Perbedaan observed versus simulated kadang expected, kecuali gap-nya ekstrem dan tidak selaras trace.
Tiga Kasus Pembanding: Lantern, Gambar, dan NO_LCP
Issue #17436 (open, label simulation/lantern) membuka investigasi maintainer tentang request cepat yang ikut masuk graf LCP saat simulasi memakai koneksi lambat. Contoh yang disebut: observed LCP sekitar 1,2 detik versus simulated LCP 5,2 detik pada trace yang sama. Ini menjelaskan mengapa kolom observed dan simulated bisa berjauhan tanpa membuktikan semua skor PSI berlebihan.
Issue #17080 melaporkan false positive Improve image delivery pada DPR > 1 dengan reproduksi instrumentasi Lighthouse/Chrome. Issue open tanpa konfirmasi maintainer penuh, dan pelapor mencatat bantuan AI saat menulis laporan. Nilai buktinya ada pada trace dan minimal repro, bukan otoritas penulis. Validasi Anda tetap: cocokkan srcset, sizes, dan resource aktual di Network panel. Jangan mengandalkan teks audit saja.
Issue #17179 berlabel bug untuk PSI yang mengembalikan NO_LCP meski screenshot final terlihat selesai. Laporan awal memakai WooCommerce, tetapi komentar lain menyebut stack WordPress/Cloudflare, jadi jangan menamai ini bug WooCommerce eksklusif. Sebelum vonis tool, periksa kandidat LCP, error console, visibility, animasi, dan trace lokal. NO_LCP total adalah failure mode, bukan alasan otomatis menghapus semua optimasi gambar.
Perbaikan yang Sudah Rilis dan Batas Versi 13.6.0
Tidak semua laporan berakhir open. Issue preloading/module graph (#16539, #17163) ditutup dengan perbaikan yang masuk Lighthouse 13.6.0 (27 Oktober 2026), termasuk upgrade trace engine via PR terkait. Changelog menyatakan rilis ini diharapkan masuk DevTools Chrome 159 dan PSI dalam kira-kira seminggu. Itu bukan bukti otomatis bahwa setiap report PSI pada 1 November 2026 sudah memakai 13.6.0.
Selalu baca environment report aktual. Issue closed juga tidak otomatis berarti fixed untuk kasus Anda: periksa state reason, komentar maintainer, dan apakah changelog menyebut bug spesifik yang Anda alami. Changelog 13.6.0 tidak menyatakan perbaikan untuk #17148, #17436, #17080, atau #17179 pada snapshot riset.
Contoh historis lain: cara browser menghitung metrik web-exposed ikut berubah antarversi. Changelog metrik Chrome memperbaiki LCP teks yang tercatat terlalu cepat di Chrome 140–142; perbaikan masuk Chrome 143. Efek tipikal sekitar satu interval vsync, bukan alasan menggeneralisasi seluruh CrUX rusak. Lab dan field memang tidak diharapkan identik, seperti FAQ performance Lighthouse dan alur alat di web.dev vitals-tools jelaskan.
Gejala Curiga Bug vs Variasi Normal
Variasi normal cenderung menghasilkan angka di sekitar rentang yang sama, median lima run stabil, dan waterfall selaras dengan bottleneck nyata (TTFB, asset besar, long task). Yang lebih layak dicurigai sebagai bug atau artefak runtime: headline metric tidak selaras subparts pada laporan yang sama, cluster bimodal tanpa band tengah, NO_LCP dengan screenshot selesai, atau insight kategoris PSI versus CLI berlawanan pada URL dan versi yang dikunci.
Menghapus preload/modulepreload lalu melihat simulated score naik pernah menjadi insentif optimasi terbalik sebelum fix 13.6.0. Jangan mengulangi kesalahan itu tanpa cek versi. Walau demikian, indikator di atas menghasilkan status suspect, bukan absolusi website. Eliminasi dulu page bug, consent, user-agent khusus, atau kontaminasi tes paralel.
| Gejala di report | Kemungkinan awal | Bukti berikutnya |
|---|---|---|
| Spread kecil, median stabil | Variasi normal lab | Ulangi run, bandingkan waterfall |
| observedLoad < observedFCP, FCP = LCP | Signature issue headless dilaporkan | Simpan JSON, cek issue #17148, bandingkan headful |
| Observed LCP rendah, simulated sangat tinggi | Simulasi Lantern / graf LCP | Trace, issue #17436, jangan hanya headline score |
| NO_LCP, screenshot tampak OK | Failure gatherer atau kandidat LCP | Debug elemen LCP, issue #17179, trace lokal |
| Field CrUX hijau, lab merah ekstrem | Lab artifact atau URL berbeda populasi | Selaraskan URL, RUM, jangan tuntut angka identik |
Checklist Sebelum Mengubah Kode atau Server
Bekukan kondisi uji: URL, hash build, device, state cache/CDN, dan catat versi Lighthouse serta sumber alat. Jalankan minimal beberapa run, simpan min–max, dan pisahkan skor dari metrik mentah (FCP, LCP, TBT, CLS, observed vs simulated, filmstrip, peringatan).
Cari kontradiksi internal, bandingkan PSI dengan Lighthouse CLI atau DevTools Performance pada konfigurasi yang dicatat. Bandingkan lab dengan field sebagai arah dampak pengguna, bukan sebagai tes kesamaan digit. Periksa issue dan changelog untuk versi exact sebelum mengubah preload, CDN, atau Nginx. Simpan JSON dan trace sebelum sentuh production.
Metodologi eksperimen yang konsisten membantu agar perbaikan tidak salah atribusi. Artikel cara menguji perubahan SEO di website bisnis relevan walau fokusnya SEO. Prinsip isolasi variabel dan window pengamatan sama saat Anda memvalidasi deploy performa atau mengevaluasi dugaan bug Lighthouse.
Jangan mempromosikan browser flag dari thread issue sebagai fix production. Flag dapat berguna sebagai kontrol diagnostik, tetapi mengubah kondisi default dan bisa menyembunyikan masalah lain.
Kapan Kembali Mendiagnosis Website Nyata
Setelah Anda eliminasi variasi normal dan signature bug runtime, kembali ke bukti kausal di sisi situs: waterfall menunjukkan resource LCP terlambat, long task JavaScript, TTFB server, atau font blocking. Data field yang lemah pada segmen mobile spesifik tetap bisa valid meski origin aggregate terlihat sehat.
Untuk stack WordPress, rantai delivery hero image, gzip Nginx, CDN, cache plugin, dan font sering menjadi bottleneck nyata setelah audit dipercaya. Panduan LCP WordPress lambat meskipun cache aktif membahas titik ukur di server dan frontend. Panduan itu tidak mengulangi tutorial optimasi skor dari nol.
Layanan audit performa yang sehat memisahkan masalah website dari limitasi alat, lalu memperbaiki hanya temuan yang trace dan field dukung. Tim yang butuh bantuan operasional pasca-diagnosis bisa mengevaluasi paket maintenance dan optimasi website setelah root cause terbukti, bukan karena satu skor PSI yang belum Anda validasi ulang.
Akhirnya, bug Lighthouse dan anomali PageSpeed Insights memang ada dan sebagian masih open. Keraguan berlebihan terhadap alat tidak menggantikan disiplin pengukuran. Curiga dulu bila bukti internal kontradiktif, dokumentasikan versi runtime, lalu baru putuskan apakah kode, server, atau CDN yang harus bergerak.
