Cara membaca laporan Lighthouse tanpa panik

Peraturan pertama: skor anda bukan laman anda

Buka laporan Lighthouse buat kali pertama dan anda akan berdepan dengan deretan nombor, kotak berkod warna, dan amaran tentang perkara yang mungkin belum pernah anda dengar. Reaksi semula jadi ialah panik. Skornya merah. Ada tujuh belas audit yang gagal. Tentulah laman ini rosak?

Kemungkinan besar tidak. Lighthouse ialah alat diagnostik, bukan kad laporan. Skor itu ialah penanda aras sintetik yang dijalankan dalam keadaan makmal—selalunya pada sambungan yang diperlahan, mensimulasikan telefon kelas pertengahan dari tahun 2017. Ia memberitahu anda cara laman anda berprestasi dalam senario khusus itu, bukan cara pengguna sebenar mengalaminya di dunia nyata.

Ini penting kerana kebanyakan pasukan terlalu tertumpu pada skor dan terlepas konteks. Skor 65 mungkin memadai untuk aplikasi web kompleks dengan data masa nyata. Skor 95 masih boleh memberikan pengalaman yang lemah jika perkara yang salah dioptimumkan. Skor ialah titik permulaan untuk penyiasatan, bukan metrik kejayaan.

Perkara pertama yang perlu dibaca: Core Web Vitals

Langkau skor prestasi keseluruhan. Tatal ke bahagian Metrics dan lihat tiga nombor: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), dan Interaction to Next Paint (INP). Ini ialah Core Web Vitals, dan inilah satu-satunya metrik prestasi yang digunakan oleh Google sebagai isyarat pemeringkatan.

• LCP mengukur berapa lama masa yang diperlukan untuk elemen terbesar yang kelihatan dirender. Sasaran: kurang daripada 2.5 saat. Jika anda melebihi 4 saat, pengguna menunggu terlalu lama untuk melihat kandungan yang bermakna.
• CLS mengukur kestabilan visual—sejauh mana halaman melompat-lompat semasa dimuatkan. Sasaran: kurang daripada 0.1. Jika anda melebihi 0.25, pengguna mungkin tersalah klik kerana butang bergerak.
• INP mengukur keresponsifan—seberapa cepat halaman bertindak balas terhadap klik, ketikan, dan input papan kekunci. Sasaran: kurang daripada 200ms. Jika anda melebihi 500ms, laman terasa lembap.

Tiga metrik ini berkorelasi dengan kekecewaan pengguna sebenar. Baiki perkara ini sebelum anda risau tentang perkara lain.

Opportunities berbanding Diagnostics: ketahui perbezaannya

Lighthouse membahagikan dapatan kepada dua kategori: Opportunities dan Diagnostics. Opportunities disusun mengikut anggaran penjimatan masa. Diagnostics ialah konteks tambahan—perkara yang mungkin menjadi masalah, atau mungkin tidak.

Mulakan dengan Opportunities. Jika Lighthouse mengatakan "Eliminate render-blocking resources" boleh menjimatkan 1.2 saat, itu kemenangan yang konkrit. Jika ia mengatakan "Reduce unused JavaScript" boleh menjimatkan 0.1 saat, kemungkinan besar ia tidak berbaloi untuk direfaktor.

Diagnostics lebih sukar. "Avoid an excessive DOM size" kedengaran buruk, tetapi jika CLS anda baik dan INP anda pantas, DOM yang besar mungkin tidak menyusahkan sesiapa. Diagnostics ialah petunjuk, bukan mandat. Siasat perkara yang selari dengan metrik sebenar anda.

Audit yang biasanya boleh anda abaikan

Sesetengah amaran Lighthouse bersifat tinggalan atau terlalu agresif. Berikut ialah amaran yang paling kerap menyebabkan panik yang tidak perlu:

• "Does not use passive listeners to improve scrolling performance" — Ini ialah pengoptimuman mikro yang jarang memberi kesan besar. Melainkan anda mempunyai bukti penatalan yang tersekat-sekat, langkau sahaja.
• "Image elements do not have explicit width and height" — Ini penting untuk CLS, tetapi hanya jika imej menyebabkan anjakan reka letak. Jika CLS anda sudah baik, jangan refaktor semata-mata demi audit.
• "Serve images in next-gen formats" — Ya, WebP dan AVIF lebih kecil. Tetapi jika imej anda sudah dioptimumkan dan LCP anda pantas, ini sekadar perkara yang bagus untuk ada, bukan krisis.
• "Avoid enormous network payloads" — Lighthouse menandakan apa-apa sahaja yang melebihi 1.6 MB. Tetapi halaman 2 MB yang dimuatkan dengan pantas lebih baik daripada halaman 500 KB yang menyekat rendering. Fokus pada cara bait dihantar, bukan hanya jumlah keseluruhan.

Apa yang perlu dilakukan apabila semuanya merah

Jika skor Lighthouse anda di bawah 50 dan kebanyakan audit gagal, anda mungkin berdepan dengan satu daripada tiga punca utama:

1. Fon yang tidak dioptimumkan. Fon web masih merupakan kemenangan prestasi paling mudah di kebanyakan laman. Semak sama ada anda memuatkan enam ketebalan fon sedangkan anda hanya menggunakan dua, atau menghantar fail WOFF dan bukannya WOFF2.
2. CSS dan JavaScript yang menyekat rendering. Jika First Contentful Paint (FCP) anda melebihi 3 saat, ada sesuatu yang menghalang pelayar daripada melukis halaman. Cari fail CSS yang besar atau skrip segerak dalam <head>.
3. Imej yang terlalu besar. Jika elemen LCP anda ialah imej dan saiznya 4 MB, itulah masalah anda. Mampatkannya, lazy-load imej di bawah lipatan, dan gunakan sintaks imej responsif.

Baiki salah satu daripadanya dan jalankan semula Lighthouse. Anda sering akan melihat lonjakan 20-30 mata. Kemudian tangani yang seterusnya.

Data makmal berbanding data lapangan: semakan realiti

Lighthouse berjalan dalam makmal. Ia mensimulasikan sambungan perlahan dan peranti perlahan, tetapi ia tidak dapat mensimulasikan tingkah laku pengguna sebenar—cara orang menatal, perkara yang mereka klik, sama ada mereka menggunakan Wi-Fi yang tidak stabil.

Untuk semakan realiti, bandingkan hasil Lighthouse anda dengan data lapangan daripada Chrome User Experience Report (CrUX). CrUX menunjukkan cara pengguna Chrome sebenar mengalami laman anda sepanjang 28 hari yang lalu. Jika Lighthouse mengatakan LCP anda 4 saat tetapi CrUX menunjukkan 2 saat, percayai CrUX. Jika kedua-duanya buruk, anda memang mempunyai masalah sebenar.

Anda boleh menemukan data CrUX dalam PageSpeed Insights (versi web Lighthouse) atau dalam Google Search Console di bawah "Core Web Vitals." Jika ada ketidakpadanan, siasat sebabnya. Mungkin pengguna sebenar anda berada pada rangkaian yang lebih pantas. Mungkin Lighthouse sedang menguji binaan pembangunan yang belum dioptimumkan.

Bila perlu menjalankan semula Lighthouse

Lighthouse mempunyai variasi. Jalankannya tiga kali berturut-turut dan anda akan mendapat tiga skor berbeza, walaupun pada halaman yang sama. Ini kerana prestasi berubah-ubah—proses latar belakang, jitter rangkaian, dan heuristik pelayar semuanya mempengaruhi hasil.

Untuk mendapatkan garis dasar yang stabil, jalankan Lighthouse dalam mod incognito dengan semua sambungan dilumpuhkan, atau gunakan CLI dengan bendera --preset=desktop untuk hasil yang lebih konsisten. Jalankannya tiga kali dan puratakan skor. Jika anda melihat ayunan besar (lebih daripada 10 mata), ada perkara lain yang tidak kena—mungkin pelayan perlahan, atau halaman memuatkan sumber yang berbeza setiap kali.

Jalankan semula Lighthouse selepas setiap perubahan yang signifikan. Melaksanakan strategi fon baharu? Semak LCP. Lazy-load imej? Semak CLS. Menambah skrip pihak ketiga? Semak INP. Prestasi bukan pembaikan sekali sahaja; ia ialah bajet yang perlu anda pertahankan.

Alat yang membantu anda bertindak berdasarkan dapatan Lighthouse

Lighthouse memberitahu anda apa yang perlahan. Ia tidak selalu memberitahu anda cara membaikinya. Untuk itu, anda memerlukan alat tambahan:

• WebPageTest memberikan paparan filmstrip tentang cara halaman dimuatkan, bingkai demi bingkai. Penting untuk mendiagnosis isu LCP dan CLS.
• Panel Performance Chrome DevTools menunjukkan dengan tepat JavaScript mana yang menyekat thread utama. Gunakannya untuk mencari punca skor INP yang buruk.
• Alat pemampat imej membolehkan anda mengoptimumkan imej terus dalam pelayar, yang lebih pantas dan lebih peribadi berbanding memuat naik ke perkhidmatan pihak ketiga. Pemprosesan imej sisi klien ialah kemenangan privasi kerana imej anda tidak pernah meninggalkan mesin anda.

Lighthouse ialah titik permulaan. Alat-alat ini membantu anda menyelesaikan kerja.

Perkara utama

• Skor Lighthouse anda ialah penanda aras makmal, bukan ukuran pengalaman pengguna dunia sebenar. Bandingkan dengan data lapangan daripada CrUX sebelum anda panik.
• Fokus pada Core Web Vitals (LCP, CLS, INP) dahulu. Inilah metrik yang berkorelasi dengan kekecewaan pengguna dan impak SEO.
• Utamakan Opportunities mengikut anggaran penjimatan masa. Abaikan Diagnostics yang tidak selari dengan masalah prestasi sebenar anda.
• Sesetengah audit—seperti passive listeners atau format imej generasi baharu—ialah pengoptimuman mikro. Baiki perkara besar dahulu.
• Jalankan Lighthouse tiga kali dan puratakan hasilnya. Prestasi berubah-ubah, dan satu larian sahaja boleh mengelirukan.

FAQ

Q: Mengapa skor Lighthouse saya berubah setiap kali saya menjalankannya?
A: Lighthouse mengukur prestasi dalam keadaan yang berubah-ubah—kelajuan rangkaian, beban CPU, dan heuristik pelayar semuanya mempengaruhi hasil. Jalankannya tiga kali dalam mod incognito dan puratakan skor untuk garis dasar yang lebih stabil.

Q: Patutkah saya mengoptimumkan untuk mudah alih atau desktop dahulu?
A: Mudah alih. Lighthouse secara lalai menggunakan simulasi mudah alih kerana kebanyakan trafik web ialah mudah alih, dan peranti mudah alih lebih perlahan. Jika skor mudah alih anda baik, skor desktop anda biasanya akan baik juga.

Q: Skor Lighthouse saya 95, tetapi laman saya masih terasa perlahan. Apa yang tidak kena?
A: Lighthouse mengukur pemuatan halaman, bukan interaktiviti selepas pemuatan. Semak skor INP anda dan gunakan panel Performance Chrome DevTools untuk memprofilkan perkara yang berlaku apabila pengguna mengklik atau menatal. Anda mungkin mempunyai masalah JavaScript yang tidak dikesan oleh Lighthouse.

Q: Adakah saya memerlukan skor 100 yang sempurna?
A: Tidak. Skor 90+ adalah cemerlang. Mengejar 100 selalunya bermaksud mengoptimumkan perkara yang tidak penting kepada pengguna. Fokus pada metrik sebenar—LCP, CLS, INP—dan abaikan skor.

Q: Bolehkah saya mempercayai Lighthouse jika saya menggunakan banyak skrip pihak ketiga?
A: Lighthouse akan menandakan skrip pihak ketiga sebagai masalah, tetapi ia tidak selalu dapat membezakan antara yang perlu dan yang tidak perlu. Gunakan audit "Avoid enormous network payloads" dan "Reduce JavaScript execution time" untuk mengenal pasti punca terburuk, kemudian tentukan sama ada ia berbaloi untuk dikekalkan.

Sumber

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org