Core Web Vitals dijelaskan: LCP, INP dan CLS dalam bahasa mudah

Core Web Vitals bukan ujian personaliti untuk laman web anda

Core Web Vitals sering dianggap seperti kad skor yang penuh misteri. Sesuatu halaman mendapat nombor merah, seseorang menyiarkan tangkapan skrin dalam Slack, dan pasukan mula berdebat tentang kerangka kerja JavaScript.

Itu tidak begitu berguna.

Cara yang lebih baik untuk memahami Core Web Vitals adalah lebih mudah: ia ialah tiga ukuran sama ada sesuatu halaman terasa boleh digunakan oleh orang sebenar pada peranti sebenar. Ia tidak menangkap setiap aspek prestasi, kebolehcapaian atau kualiti. Namun ia memang mengesan tiga sumber kekecewaan yang lazim:

• Kandungan utama mengambil masa terlalu lama untuk muncul.
• Halaman bertindak balas dengan perlahan apabila pengguna cuba melakukan sesuatu.
• Reka letak melompat-lompat semasa pengguna sedang membaca atau mengetik.

Itulah tiga Core Web Vitals: LCP, INP dan CLS.

Google menggunakannya sebagai sebahagian daripada isyarat pengalaman halamannya, tetapi sudut SEO bukan sebab terbaik untuk mengambil berat. Sebab yang lebih baik ialah halaman yang perlahan, melompat-lompat dan tidak responsif membazir masa pengguna. Halaman seperti itu juga cenderung menukar pengunjung dengan lebih teruk, lebih sukar disokong, dan cepat kelihatan usang.

Tiga metrik dalam satu ayat setiap satu

Sebelum pergi kepada butiran, inilah versi bahasa mudah:

• LCP, atau Largest Contentful Paint, mengukur berapa lama masa yang diambil untuk kandungan utama yang kelihatan dimuatkan.
• INP, atau Interaction to Next Paint, mengukur seberapa cepat halaman bertindak balas terhadap interaksi pengguna sepanjang lawatan.
• CLS, atau Cumulative Layout Shift, mengukur sejauh mana halaman bergerak secara tidak dijangka.

Ambang lazim ialah:

| Metrik | Baik | Perlu penambahbaikan | Lemah | |---|---:|---:|---:| | LCP | 2.5s atau lebih cepat | 2.5s–4.0s | Melebihi 4.0s | | INP | 200ms atau lebih cepat | 200ms–500ms | Melebihi 500ms | | CLS | 0.1 atau lebih rendah | 0.1–0.25 | Melebihi 0.25 |

Nombor-nombor ini biasanya dinilai pada persentil ke-75 bagi lawatan pengguna sebenar. Itu penting. Anda bukan cuba menghasilkan satu larian makmal yang sempurna. Anda cuba menjadikan pengalaman baik untuk kebanyakan pengguna, termasuk orang yang menggunakan telefon lebih perlahan dan rangkaian yang lebih tidak menentu.

Jika anda sedang menatap laporan automatik dan tidak pasti dari mana hendak bermula, elok asingkan diagnosis daripada panik. Kami mempunyai panduan berasingan tentang cara membaca laporan Lighthouse tanpa panik yang menerangkan aliran kerja itu dengan lebih terperinci.

LCP: bilakah halaman terasa sudah dimuatkan?

Largest Contentful Paint mengukur masa pemaparan elemen kandungan kelihatan yang terbesar dalam viewport. Dalam praktiknya, itu sering kali:

• imej hero,
• tajuk besar,
• imej artikel pilihan,
• imej produk,
• blok teks yang besar.

LCP tidak bertanya bila setiap skrip, piksel penjejakan dan imej di bawah lipatan selesai dimuatkan. Ia bertanya: bilakah perkara utama yang pengguna datang untuk lihat menjadi kelihatan?

Itu menjadikan LCP metrik yang lebih manusiawi berbanding “masa muat halaman” gaya lama. Sesuatu halaman secara teknikal boleh selesai dimuatkan lewat tetapi masih terasa pantas jika kandungan utama muncul dengan cepat. Sebaliknya juga benar: sesuatu halaman boleh mencetuskan peristiwa load sementara kawasan hero masih kosong, kabur atau tersekat oleh kelewatan pemaparan.

Punca lazim LCP yang lemah

Kebanyakan masalah LCP yang buruk datang daripada beberapa tempat yang boleh dijangka:

1. Respons pelayan yang perlahan

Jika dokumen HTML tiba lewat, semua perkara lain bermula lewat.

1. CSS atau JavaScript yang menyekat pemaparan

Pelayar mempunyai kandungan tetapi belum boleh melukisnya.

1. Imej hero yang tidak dioptimumkan

Elemen terbesar terlalu besar, dalam format yang salah, tidak diberi keutamaan, atau tersilap dimuatkan secara malas.

1. Fon web yang melambatkan pemaparan teks

Tajuk besar mungkin menjadi elemen LCP, dan pemuatan fon boleh melambatkan atau mengubahnya secara visual.

1. Kelewatan pemaparan di sisi klien

Jika halaman memerlukan himpunan JavaScript yang besar sebelum ia boleh memaparkan kandungan bermakna, LCP akan terjejas.

Cara menambah baik LCP

Mulakan dengan elemen LCP yang sebenar. Jangan optimumkan aset rawak sebelum anda tahu apa yang sedang diukur oleh pelayar.

Pembetulan praktikal termasuk:

• Hidangkan HTML dengan cepat: cache jika sesuai, kurangkan kerja backend, elakkan redirect yang perlahan.
• Optimumkan imej LCP: gunakan dimensi, pemampatan dan format yang betul.
• Jangan lazy-load imej hero di atas lipatan.
• Gunakan fetchpriority="high" dengan berhati-hati untuk imej utama apabila ia benar-benar keutamaan.
• Inline CSS kritikal hanya apabila ia benar-benar mengurangkan kelewatan pemaparan.
• Kurangkan JavaScript yang diperlukan sebelum pemaparan bermakna pertama.
• Gunakan font-display: swap atau strategi fon lain yang disengajakan.

Imej dan fon kerap menjadi puncanya. Untuk imej, pertimbangannya bukan sekadar “fail kecil itu baik”. Pilihan format, usaha pengekodan dan sokongan pelayar semuanya penting, sebab itulah kami menyimpan pokok keputusan praktikal untuk bila AVIF mengatasi WebP dan bila tidak. Untuk halaman yang berat dengan tipografi, fon web masih antara kemenangan prestasi yang paling mudah kerana banyak laman menghantar lebih banyak fail fon daripada yang digunakan.

INP: adakah halaman bertindak balas apabila disentuh?

Interaction to Next Paint mengukur keresponsifan. Secara lebih khusus, ia melihat kelewatan antara interaksi pengguna dan kemas kini visual seterusnya selepas pelayar memproses interaksi tersebut.

Interaksi termasuk perkara seperti:

• mengklik butang,
• mengetik menu,
• memilih checkbox,
• menaip ke dalam medan borang,
• membuka accordion.

INP menggantikan First Input Delay sebagai Core Web Vital pada tahun 2024. Itu perubahan yang baik. First Input Delay hanya melihat interaksi pertama. INP lebih luas: ia mempertimbangkan interaksi sepanjang lawatan halaman dan melaporkan interaksi berlengah tinggi sebagai skor keresponsifan halaman.

Dalam bahasa mudah: INP menangkap halaman yang kelihatan sudah dimuatkan tetapi terasa tersekat.

Anda mungkin pernah menggunakan halaman seperti ini. Ia kelihatan sedia. Anda mengetik menu. Tiada apa-apa berlaku selama setengah saat. Anda mengetik lagi. Kemudian dua perkara berlaku serentak. Itu masalah INP.

Punca lazim INP yang lemah

INP biasanya masalah main thread. Pelayar mahu bertindak balas, tetapi JavaScript, kerja pemaparan atau pengiraan reka letak sedang menghalang.

Punca biasa termasuk:

• himpunan JavaScript yang besar,
• event handler yang mahal,
• kerja hydration pada aplikasi yang dirender di klien,
• skrip pihak ketiga yang bersaing untuk main thread,
• tugas yang berjalan lama selepas halaman dimuatkan,
• kemas kini DOM yang kompleks akibat interaksi kecil,
• layout thrashing, apabila kod berulang kali membaca dan menulis nilai reka letak.

Tag pemasaran, analitik, widget sembang dan banner persetujuan semuanya boleh menyumbang. Ini tidak bermaksud “buang semuanya”. Maksudnya setiap skrip pada halaman mempunyai kos, dan kelengahan interaksi ialah tempat kos itu sering menjadi kelihatan.

Cara menambah baik INP

Menambah baik INP kurang berkaitan dengan satu atribut ajaib, dan lebih berkaitan dengan mengurangkan perebutan main thread.

Pendekatan berguna termasuk:

• Pecahkan tugas JavaScript yang panjang kepada bahagian yang lebih kecil.
• Tangguhkan kerja yang tidak penting sehingga selepas halaman boleh digunakan.
• Buang JavaScript yang tidak digunakan, bukan sekadar meminimumkannya.
• Pastikan event handler kecil dan boleh dijangka.
• Elakkan merender semula bahagian besar antara muka untuk perubahan state yang kecil.
• Gunakan CSS untuk keadaan visual yang mudah jika boleh.
• Audit skrip pihak ketiga dan muatkannya hanya di tempat yang diperlukan.

Lihat juga reka bentuk interaksi. Butang yang memberikan maklum balas visual segera boleh terasa lebih responsif, walaupun kerja susulan mengambil masa lebih lama. Itu bukan pengganti prestasi, tetapi ia sebahagian daripada kejuruteraan antara muka yang baik. Senarai semak kami untuk butang web yang boleh dicapai bertindih dengan perkara ini: keadaan yang jelas, semantik yang betul dan tingkah laku yang boleh dijangka membantu pengguna dan pelayar.

CLS: adakah halaman kekal di tempat yang dijangka pengguna?

Cumulative Layout Shift mengukur pergerakan tidak dijangka bagi elemen yang kelihatan. Jika pengguna mula membaca perenggan dan iklan, imej atau banner dimuatkan di atasnya lalu menolak teks ke bawah, itu menyumbang kepada CLS.

CLS tidak diukur dalam saat. Ia ialah skor berdasarkan berapa banyak kandungan bergerak dan sejauh mana ia bergerak. Lebih rendah lebih baik.

Kata kuncinya ialah tidak dijangka. Perubahan reka letak yang disebabkan oleh tindakan pengguna biasanya tidak dikira dengan cara yang sama. Jika seseorang mengetik “tunjukkan lagi” dan kandungan mengembang, itu dijangka. Jika banner surat berita muncul di bahagian atas selepas tiga saat dan menolak semuanya ke bawah, itu tidak dijangka.

Punca lazim CLS yang lemah

Kegagalan CLS sering kali perkara biasa:

• imej tanpa atribut width dan height,
• iklan atau embed tanpa ruang yang diperuntukkan,
• banner cookie yang disisipkan di atas kandungan,
• fon web yang bertukar masuk dengan metrik berbeza,
• bar promosi yang lambat dimuatkan,
• kandungan yang disuntik secara dinamik berhampiran bahagian atas halaman.

Pembetulannya biasanya ialah memperuntukkan ruang sebelum kandungan tiba. Pelayar sepatutnya mengetahui bentuk halaman seawal mungkin.

Cara menambah baik CLS

Mulakan dengan anjakan yang kelihatan. Tonton rakaman atau gunakan alat pelayar untuk mengenal pasti elemen mana yang bergerak.

Kemudian gunakan pembetulan yang membosankan:

• Tambahkan atribut width dan height yang jelas pada imej.
• Gunakan CSS aspect-ratio untuk bekas media responsif.
• Peruntukkan ruang tetap atau minimum untuk iklan, embed dan iframe.
• Elakkan menyuntik banner di atas kandungan sedia ada selepas muat.
• Pilih fallback fon dengan metrik yang serupa dengan fon akhir.
• Elakkan animasi yang mengubah sifat reka letak seperti top, left, width atau height; utamakan transform.

CLS ialah salah satu daripada sedikit metrik prestasi yang menunjukkan disiplin mengatasi kepintaran. Jika halaman mempunyai kotak yang stabil, ia cenderung mendapat skor yang baik.

Data medan dan data makmal kedua-duanya berguna, tetapi menjawab soalan berbeza

Sumber kekeliruan yang biasa ialah alat berbeza menunjukkan nombor berbeza. Itu normal.

Data medan datang daripada pengguna sebenar. Ia mencerminkan peranti, rangkaian, lokasi dan keadaan pelayar sebenar. Google’s Chrome User Experience Report ialah contoh data medan.

Data makmal datang daripada persekitaran ujian terkawal. Lighthouse ialah contoh yang biasa dikenali. Ia boleh diulang dan berguna untuk penyahpepijatan, tetapi ia tidak sama dengan pengalaman sebenar pengguna anda.

Gunakan data medan untuk memutuskan sama ada pengguna mempunyai masalah sebenar. Gunakan data makmal untuk menghasilkan semula dan menyahpepijat masalah itu.

Ingat juga bahawa Core Web Vitals biasanya dinilai mengikut URL atau kumpulan URL, bukan sebagai satu sifat abstrak jenama anda. Halaman utama, artikel blog, halaman harga dan checkout anda boleh mempunyai bottleneck yang sangat berbeza.

Urutan kerja yang munasabah

Jika ketiga-tiga metrik lemah, godaannya ialah bermula di semua tempat. Tahan keinginan itu.

Urutan praktikal ialah:

1. Betulkan CLS yang jelas dahulu

Dimensi imej yang hilang dan banner yang tidak stabil sering menjadi kemenangan cepat.

1. Tambah baik LCP untuk templat penting

Fokus pada halaman yang penting: halaman produk, landing page, artikel, aliran pendaftaran.

1. Siasat INP dengan interaksi sebenar

Klik perkara yang benar-benar diklik pengguna. Menu, penapis, borang dan kawalan checkout sering mendedahkan lebih banyak daripada jejak muatan awal.

1. Audit skrip pihak ketiga

Kekalkan skrip yang membenarkan kosnya. Buang atau lewatkan skrip yang tidak.

1. Tetapkan bajet prestasi

Tanpa bajet, penambahbaikan prestasi akan merosot. Skrip, imej dan komponen reka bentuk baharu akan senyap-senyap membatalkan kerja yang telah dibuat.

Perkara penting: jangan optimumkan untuk lencana. Optimumkan untuk perjalanan pengguna. Penambahbaikan skor yang kecil pada halaman trafik rendah mungkin kurang penting berbanding interaksi checkout yang sedikit tidak sempurna tetapi jauh lebih pantas.

<!-- tool-cta:start -->

💡 Cuba ini: Oleh sebab LCP biasanya masalah imej, kecilkan aset hero anda dengan Image Compressor sebagai kemenangan mudah pertama.

<!-- tool-cta:end -->

Perkara yang tidak diberitahu oleh Core Web Vitals

Core Web Vitals berguna, tetapi tidak lengkap.

Ia tidak memberitahu anda sama ada kandungan anda baik. Ia tidak memberitahu anda sama ada navigasi anda masuk akal. Ia tidak menjamin kebolehcapaian. Ia tidak mengukur privasi, keselamatan, kepercayaan, kebolehbacaan atau sama ada halaman menjawab soalan pengguna.

Ia juga tidak menggantikan pertimbangan. Sesuatu halaman boleh lulus Core Web Vitals dan masih tidak menyenangkan. Aplikasi yang kompleks boleh terlepas ambang tetapi masih direkayasa secara bertanggungjawab mengikut kekangannya.

Anggap LCP, INP dan CLS sebagai penggera asap. Apabila ia berbunyi, siasat. Apabila ia senyap, terus selenggara bangunan itu.