Core Web Vitals: kesan pada SEO dan pengalaman halaman

Apa yang diukur oleh Core Web Vitals

Core Web Vitals adalah satu set kecil metrik prestasi berpusatkan pengguna yang menerangkan tiga aspek bagaimana sesuatu halaman dirasakan dalam penggunaan sebenar: pemuatan, interaktiviti, dan kestabilan visual. Dalam praktik, anda menggunakannya untuk menjawab: berapa cepat kandungan utama muncul, sejauh mana halaman responsif terhadap input pengguna, dan sama ada pergeseran susun atur mengganggu pengalaman.

Largest Contentful Paint (LCP)

LCP mengukur bila elemen terbesar yang boleh dilihat dalam viewport selesai dirender semasa pemuatan halaman. Elemen itu selalunya imej hero, blok teks di atas lipatan, atau bingkai poster video yang besar. LCP berkaitan dengan kelajuan yang dirasakan: jika bahagian kandungan yang paling bermakna muncul dengan cepat, pengguna biasanya merasakan halaman itu pantas.

Interaction to Next Paint (INP)

INP adalah metrik medan yang menangkap keteransangan dengan mengukur latensi interaksi pengguna. Berbeza dengan metrik FID yang lama, yang mengukur kelewatan interaksi pertama, INP merumuskan keteransangan merentasi banyak interaksi untuk mencerminkan interaktiviti keseluruhan. INP menonjolkan tugas main-thread yang panjang dan pengendal acara yang perlahan yang menjadikan halaman terasa lembap.

Cumulative Layout Shift (CLS)

CLS mengukur pergerakan susun atur yang tidak dijangka yang berlaku sepanjang kitar hayat halaman. Ia mengagregat peristiwa layout-shift individu ke dalam satu skor yang mencerminkan berapa banyak kandungan yang kelihatan telah bergerak dan betapa mengganggunya pergeseran itu. Susun atur yang stabil yang memperuntukkan ruang untuk imej, iklan dan embed mengekalkan CLS rendah dan mengurangkan reflow yang menjengkelkan.

How Core Web Vitals relate to SEO

Core Web Vitals adalah sebahagian daripada isyarat pengalaman halaman Google. Mereka ialah salah satu set daripada banyak isyarat yangenjin cariangunakan untuk menyusun dan memaparkan kandungan. Memperbaikinya boleh mengurangkan rintangan untuk pengguna dan meningkatkan keterlibatan, yang membantu nilai keseluruhan halaman, tetapi Core Web Vitals yang baik sahaja tidak menjamin kedudukan lebih tinggi. Sebaliknya, Core Web Vitals yang sangat buruk boleh mengurangkan daya saing halaman dalam kes di mana isyarat relevan lain adalah serupa.

Jelas bezakan tiga perkara: crawling (penemuan dan fetch bot), indexing (apa yang disimpan Google), dan ranking (cara keputusan disusun). Core Web Vitals menjejaskan pengalaman halaman dan seterusnya ranking; ia tidak menentukan sama ada URL akan dicrawl atau diindeks. Juga ambil perhatian fakta operasi yang mempengaruhi pengukuran dan pembetulan: sejak July 2024, Google melakukan crawl tapak untuk Search menggunakan Googlebot Smartphone secara lalai, dan pada awal 2024 Google mengalih keluar halaman cache tradisional — kedua-duanya bermakna paparan mudah alih dan kandungan langsung semasa adalah teras bagaimana isyarat pengalaman dikira dan dipaparkan.

Field vs. lab measurement — what to use and when

Anda memerlukan kedua-dua data medan (pengguna sebenar) dan makmal (sintetik) untuk mendiagnosis dan mengesahkan pembaikan. Data medan menunjukkan bagaimana pengguna sebenar pada peranti dan rangkaian yang pelbagai mengalami halaman anda; data makmal memberikan snapshot boleh ulang dan boleh debug di bawah keadaan terkawal.

Field tools

Gunakan laporan Core Web Vitals dalamGoogle Search Consoleuntuk tren peringkat tapak (memerlukan pemilikan tapak), PageSpeed Insights untuk ringkasan medan per-URL, dan Chrome UX Report (CrUX) untuk data pengguna sebenar yang diagregat. Untuk pengumpulan tersuai, pasangkan instrumentasi pada halaman dengan perpustakaan web-vitals dan hantar ukuran ke analytics anda atau koleksi APM untuk segmentasi mengikut peranti, negara dan jenis sambungan.

Lab tools

Gunakan Lighthouse (dalam DevTools atau CLI) dan panel Performance dalam Chrome DevTools untuk debugging berasaskan trace. Larian makmal membolehkan anda menghasilkan semula tugas panjang, memeriksa main thread, dan menangkap timing waterfall untuk mengenal pasti sumber yang menghalang render.

Common causes and practical fixes

LCP: causes and fixes

Punca tipikal: masa respons server yang perlahan, CSS/JavaScript yang menghalang render, imej besar yang tidak dioptimumkan, client-side rendering yang melambatkan meaningful paint, dan pengutamaan sumber yang menunda elemen yang paling besar kelihatan.

Pembaikan praktikal: tingkatkan TTFB server melalui caching dan penempatan CDN; hidangkan CSS kritikal secara inline untuk kandungan di atas lipatan dan tangguhkan CSS tidak kritikal; utamakan sumber LCP dengan rel=preload dan keutamaan sumber yang betul; mampatkan dan ubah saiz imej, gunakan format moden dan responsive srcset; pertimbangkan server-side rendering atau hybrid rendering untuk halaman di mana client-side rendering melambatkan kandungan utama.

INP: causes and fixes

Punca tipikal: tugas panjangJavaScriptyang menyekat main thread, kerja segerak berat semasa interaksi pengguna, bundler besar yang menjalankan kod inisialisasi, dan pengendali acara yang tidak dioptimumkan.

Pembaikan praktikal: pecahkan kod kepada kepingan lebih kecil dan tangguhkan skrip yang tidak penting, keluarkan kerja dari main thread menggunakan web workers, keluarkan atau tunda tugas inisialisasi besar sehingga selepas input pertama, buat pengendali acara pantas (lakukan kerja minimum, jadualkan kerja berat menggunakan requestIdleCallback atau setTimeout), dan elakkan corak yang menyebabkan layout-thrashing (baca–tulis–baca).

CLS: causes and fixes

Punca tipikal: imej atau iframe tanpa atribut width/height, iklan atau embed yang disuntik tanpa ruang yang diperuntukkan, fon web yang menyebabkan pertukaran susun atur, dan sisipan DOM di atas kandungan sedia ada.

Pembaikan praktikal: sentiasa sertakan atribut width dan height (atau CSS aspect-ratio) untuk imej dan iframe; peruntukkan ruang untuk iklan dan kandungan dinamik dengan kontena CSS; gunakan font-display swap atau optional untuk mengelakkan fasa teks tak kelihatan; elakkan menyisipkan kandungan di atas kandungan sedia ada melainkan ruang telah diperuntukkan; utamakan animasi berasaskan transform daripada menganimasikan sifat yang menjejaskan susun atur.

Prioritizing work and implementing fixes

Mulakan dengan mentriage halaman di mana Core Web Vitals yang lemah dan trafik tinggi bersilang. Gunakan data peringkat tapak dalam Search Console untuk mencari kumpulan URL yang menunjukkan metrik medan lemah, kemudian debug URL perwakilan dalam alat makmal. Untuk setiap halaman sasaran, buat pelan pembaikan ringkas yang menyenaraikan kemenangan cepat (mampatan imej, rel=preload LCP, tangguh JS tidak kritikal), kerja pertengahan (code-splitting, server-side rendering), dan pelaburan lebih besar (perubahan seni bina atau reka bentuk semula UX).

Apabila anda mengeluarkan pembaikan, kumpulkan metrik pengguna sebenar (RUM) untuk tetingkap pengesahan yang ditetapkan dan bandingkan peratusan dan segmen peranti. Kerana pengalaman halaman hanyalah salah satu daripada banyak isyarat ranking, anggap peningkatan Core Web Vitals sebagai sebahagian daripada program iteratif: ukur, baiki item yang memberi impak terbesar dulu, pantau tingkah laku pengguna dan ranking, ulang.

Verification and troubleshooting checklist

Ikuti senarai semak ini apabila anda perlu mengesahkan isu Core Web Vitals dan mengesahkan pembaikan:

1. Site-level trends: semak laporan Core Web Vitals dalam Google Search Console untuk kumpulan URL yang menunjukkan status 'poor' atau 'needs improvement' (memerlukan pemilikan).

2. Per-URL field snapshot: jalankan PageSpeed Insights untuk melihat data medan dan makmal bagi URL tertentu; semak data CrUX dan cadangan diagnostik.

3. Reproduce in lab: jalankan Lighthouse dalam sesi incognito DevTools dan periksa trace Performance. Gunakan panel Performance untuk melihat tugas panjang dan aktiviti main-thread.

4. Collect targeted RUM: pasangkan instrumentasi pada halaman dengan perpustakaan web-vitals dan hantar ukuran ke analytics anda. Contoh potongan modul untuk tangkapan cepat:

<script type="module">import {getCLS, getLCP, getINP} from 'https://unpkg.com/web-vitals?module';getCLS(r => console.log('CLS', r));getLCP(r => console.log('LCP', r));getINP(r => console.log('INP', r));</script>

5. Semak keseragaman peranti: kerana Google menggunakan paparan mudah alih sebagai asas utama untuk pengindeksan dan pengalaman halaman, sahkan HTML mudah alih anda menghidangkan kandungan yang setara atau serupa dan bahawa imej responsif, CSS dan sumber kritikal dioptimumkan untuk saiz viewport smartphone.

6. Mengasingkan impak pihak ketiga: muatkan halaman dengan dan tanpa skrip pihak ketiga (iklan, analytics, widget) dalam larian makmal untuk mengukur impaknya terhadap LCP, INP dan CLS. Gantikan atau lazy-load penyedia yang menyebabkan tugas panjang berlebihan atau pergeseran susun atur yang tidak dijangka.

Common mistakes and diagnostic traps

• Menganggap skor makmal sebagai realiti medan. Larian makmal penting untuk debugging, tetapi ia mensimulasikan satu profil peranti/rangkaian sahaja dan mungkin tidak mewakili asas pengguna anda. Sentiasa sahkan dengan RUM medan.

• Membetulkan hanya desktop. Kerana Google menilai pengalaman halaman terutamanya berdasarkan rendering mudah alih, pembaikan mesti menumpu pengalaman mudah alih dahulu melainkan analytics anda menunjukkan campuran peranti yang berbeza untuk perjalanan pengguna penting.

• Terlalu mengoptimumkan satu metrik. Peningkatan harus menghormati keperluan pengguna: menangguhkan fon secara agresif untuk menurunkan CLS boleh menjejaskan keterbacaan; membuang skrip penting untuk menurunkan INP boleh memecahkan fungsi. Gunakan eksperimen dan ukur metrik pengguna di luar Core Web Vitals, seperti keterlibatan dan penukaran.

• Mengabaikan variabiliti rawak. Data medan mengandungi bunyi: variasi geografi, pembawa dan peranti boleh mengubah peratusan. Segmentasikan RUM mengikut kohort bermakna untuk mengenal pasti regresi sebenar.

When to accept trade-offs

Sesetengah halaman menyediakan pengalaman interaktif kompleks yang sememangnya memerlukan belanjawan CPU atau rangkaian. Jika ciri itu teras kepada produk anda dan memberikan nilai pengguna yang boleh diukur, dokumentasikan pertukaran itu, optimumkan segala yang lain yang anda boleh, dan pantau tingkah laku pengguna. Utamakan pembaikan yang mengurangkan kos ciri itu (contohnya, incremental hydration, partial hydration, atau mengasingkan kod berat dalam bundle yang ditangguhkan) daripada membuang fungsi sepenuhnya.

FAQ