Core Web Vitals untuk kedai dalam talian: LCP, INP dan CLS

Apa yang diukur oleh LCP, INP dan CLS, ambang pada persentil ke-75, data makmal lawan lapangan, serta pembaikan lazim untuk kedai Shopify dan WooCommerce.

Pasukan Editorial FixReportsBacaan 12 minit

Core Web Vitals ialah tiga metrik Google yang menggambarkan pengalaman pelawat sebenar terhadap sesebuah halaman: Largest Contentful Paint (LCP) untuk pemuatan, Interaction to Next Paint (INP) untuk responsif, dan Cumulative Layout Shift (CLS) untuk kestabilan visual. Halaman lulus apabila sekurang-kurangnya 75% lawatan berada dalam julat "baik": LCP dalam 2.5 saat, INP dalam 200 milisaat dan CLS 0.1 atau kurang, diukur secara berasingan untuk mudah alih dan desktop. Di kedai dalam talian, skor yang gagal biasanya berpunca daripada imej hero dan imej produk yang besar atau dimuatkan secara tertunda (lazy loading), skrip aplikasi dan penjejakan, fon web, serta sepanduk atau widget ulasan yang menolak kandungan ke bawah selepas halaman dipaparkan.

Perkara utama

Apakah ambang Core Web Vitals?

Halaman memenuhi Core Web Vitals apabila persentil ke-75 pemuatan halamannya berada dalam julat baik bagi ketiga-tiga metrik.

MetrikApa yang diukurBaikPerlu penambahbaikanLemah
LCPMasa sehingga imej, video atau blok teks terbesar dalam viewport dipaparkan2.5 s atau kurangMelebihi 2.5 s hingga 4.0 sMelebihi 4.0 s
INPMasa dari klik, ketikan atau tekanan kekunci sehingga bingkai seterusnya dilukis200 ms atau kurangMelebihi 200 ms hingga 500 msMelebihi 500 ms
CLSSejauh mana kandungan yang kelihatan beralih secara tidak dijangka0.1 atau kurangMelebihi 0.1 hingga 0.25Melebihi 0.25

Ambang ini diambil daripada panduan LCP (dibuka dalam tab baharu), INP (dibuka dalam tab baharu) dan CLS (dibuka dalam tab baharu) di web.dev, setakat Oktober 2026.

Persentil ke-75 bermaksud keputusan itu mencerminkan kebanyakan pelawat, bukan hanya yang terpantas, dan Google mengasingkan mudah alih dan desktop (dibuka dalam tab baharu). PageSpeed Insights meluluskan halaman apabila ketiga-tiga metrik baik; jika data INP tidak mencukupi, ia menilai LCP dan CLS sahaja (dokumentasi PageSpeed Insights (dibuka dalam tab baharu)). Google menyatakan bahawa Core Web Vitals yang stabil tidak akan berubah lebih daripada sekali setahun.

Di kedai dalam talian, elemen LCP selalunya sepanduk hero atau imej produk utama, sebab itulah pengendalian imej sangat penting.

Mengapakah INP menggantikan FID pada Mac 2024?

INP menggantikan FID kerana FID hanya mengukur interaksi pertama dan hanya sebahagian daripada kelewatannya, manakala INP melihat interaksi sepanjang lawatan.

Google mengumumkan pada Mei 2023 bahawa INP akan menjadi Core Web Vital, dan pertukaran itu berkuat kuasa pada 12 Mac 2024 (dibuka dalam tab baharu). FID hanya melaporkan interaksi pertama, dan hanya kelewatan inputnya, bukan masa yang digunakan untuk menjalankan pengendali peristiwa (event handler) atau melukis hasilnya. INP memerhati klik, ketikan dan tekanan kekunci sepanjang lawatan dan melaporkan yang paling lama, dengan mengabaikan nilai luar biasa; tatalan dan hover tidak dikira. Pengguna API CrUX dan PageSpeed Insights diberi masa sehingga 9 September 2024 untuk beralih (web.dev (dibuka dalam tab baharu)).

Setiap interaksi mempunyai tiga bahagian: kelewatan input (menunggu skrip yang sibuk), tempoh pemprosesan (menjalankan pengendali) dan kelewatan persembahan (melukis bingkai seterusnya) (web.dev (dibuka dalam tab baharu)).

Di kedai dalam talian, interaksi itu ialah pemilih varian, butang kuantiti, tambah ke troli, laci troli, penapis dan menu. Sesebuah halaman boleh lulus FID pada ketikan pertama yang pantas tetapi masih terasa perlahan apabila seseorang membuka penapis kemudiannya.

Apakah perbezaan antara data makmal dengan data lapangan?

Data makmal datang daripada satu ujian dalam keadaan tetap, manakala data lapangan dikumpul daripada pelawat sebenar dari semasa ke semasa, dan Google mengesyorkan penggunaan data lapangan untuk menentukan apa yang perlu dibaiki dahulu (web.dev (dibuka dalam tab baharu)).

Data makmalData lapangan
SumberSatu pemuatan halaman simulasi (Lighthouse, Chrome DevTools, bahagian makmal PageSpeed Insights)Pelawat Chrome sebenar (Chrome UX Report), atau pemantauan pengguna sebenar (RUM) anda sendiri
KeadaanPeranti dan rangkaian tetap. Ujian mudah alih lalai Lighthouse (dibuka dalam tab baharu) menggunakan "Slow 4G" (perjalanan pergi balik 150 ms, muat turun 1.6 Mbps) dan pelambatan CPU 4xApa sahaja peranti, rangkaian dan lokasi pelawat anda
INPTidak diukur pada pemuatan halaman biasa. Total Blocking Time (TBT) ialah anggaran kasarDiukur daripada interaksi sebenar
Paling sesuai untukPenyahpepijatan dan menyemak perubahan sebelum dikeluarkanMengetahui apa yang benar-benar dialami pelawat

TBT menjumlahkan bahagian setiap tugas pada utas utama (main thread) yang melebihi 50 ms; web.dev mencadangkan di bawah 200 ms pada perkakasan mudah alih biasa tetapi menyatakan bahawa ia bukan pengganti INP (web.dev (dibuka dalam tab baharu)).

Tiga butiran Chrome UX Report (CrUX) penting bagi kedai dalam talian:

  • Ia ialah purata bergulir 28 hari (dibuka dalam tab baharu), dikemas kini setiap hari.
  • Ia meliputi Chrome pada desktop dan Android bagi pengguna yang memenuhi syarat pelaporan Chrome. Chrome pada iOS dikecualikan, jadi kedai yang kebanyakan pembelinya menggunakan iPhone hanya melihat data lapangan daripada sebahagian khalayaknya (metodologi (dibuka dalam tab baharu)).
  • Halaman dan origin hanya muncul apabila ia boleh ditemui secara awam dan cukup popular, jadi kedai bertrafik rendah mungkin hanya mempunyai data peringkat origin, atau tiada langsung.

Papan pemuka prestasi web (dibuka dalam tab baharu) Shopify juga melaporkan LCP, INP dan CLS pengguna sebenar pada persentil ke-75, tetapi bagi tempoh 30 hari dan bukan 28 hari, jadi jangkakan sedikit perbezaan berbanding CrUX.

Apakah yang melambatkan LCP pada halaman kedai?

LCP biasanya perlahan di kedai dalam talian kerana imej utama terlalu berat, ditemui lewat, atau sengaja dilewatkan oleh lazy loading atau animasi.

  • Lazy loading pada imej LCP. web.dev menyatakan perkara ini tidak boleh dilakukan sama sekali (web.dev (dibuka dalam tab baharu)). Analisisnya terhadap halaman WordPress mendapati LCP persentil ke-75 lebih perlahan pada laman yang menggunakan lazy loading asli, dan tidak menggunakan lazy loading pada imej di bahagian atas skrin menghapuskan kemerosotan itu (web.dev (dibuka dalam tab baharu)).
  • Imej yang ditemui lewat. Hero yang ditetapkan sebagai background-image CSS, atau yang disuntik oleh skrip gelangsar (slider), tiada dalam HTML yang mula-mula diimbas oleh pelayar. Shopify menasihatkan agar tidak menggunakan latar belakang CSS untuk kandungan hero dan kesan fade-in pada imej LCP (Shopify (dibuka dalam tab baharu)).
  • Keutamaan rendah. Imej dimuatkan dengan keutamaan rendah sehingga susun atur selesai, jadi Shopify mengesyorkan fetchpriority="high" pada imej LCP (Shopify (dibuka dalam tab baharu)). web.dev menyatakan bahawa menetapkannya pada lebih daripada satu atau dua imej mengurangkan keberkesanannya (web.dev (dibuka dalam tab baharu)).
  • CSS dan skrip yang menyekat pemaparan. Helaian gaya yang besar dan skrip segerak dalam <head> melewatkan pemaparan walaupun selepas imej tiba (web.dev (dibuka dalam tab baharu)).
  • Saiz fail dan fon. Gunakan format moden, srcset dan sizes, serta CDN. Untuk fon web, gunakan nilai font-display selain auto atau block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Apakah yang menyebabkan INP perlahan pada halaman kedai?

INP yang perlahan di kedai dalam talian biasanya bermakna terlalu banyak JavaScript pada utas utama, kebanyakannya daripada aplikasi, tag penjejakan dan ciri tema, jadi ketikan terpaksa menunggu.

Jika pembeli mengetik "Tambah ke troli" ketika skrip ulasan, sembang dan analitik masih berjalan, ketikan itu terpaksa menunggu. Pemilih varian yang memaparkan semula keseluruhan borang produk menambah masa pemprosesan. Mega menu yang besar dan grid koleksi dengan banyak swatch warna menambah kelewatan persembahan.

web.dev mengesyorkan memecahkan tugas panjang dan memberi laluan kepada utas utama, mengemas kini skrin dahulu dan menangguhkan selebihnya, serta mengekalkan DOM yang lebih kecil (web.dev (dibuka dalam tab baharu)). Shopify menambah langkah khusus untuk kedai: audit setiap aplikasi, piksel dan skrip tema, tangguhkan apa yang tidak kritikal, muatkan ciri apabila berlaku interaksi, dan matikan snippet anti-flicker ujian A/B apabila tiada ujian sedang dijalankan (Shopify (dibuka dalam tab baharu)).

Apakah punca anjakan susun atur pada halaman produk dan koleksi?

Anjakan susun atur di kedai dalam talian kebanyakannya datang daripada kandungan yang muncul atau berubah saiz selepas pemaparan pertama: imej tanpa dimensi, bar pengumuman dan kuki, widget ulasan, blok aplikasi dan pertukaran fon.

web.dev menyenaraikan punca lazim sebagai media tanpa dimensi yang diketahui, kandungan yang ditambah di atas kandungan sedia ada, widget pihak ketiga yang mengubah saiz sendiri, dan fon web yang saiznya berbeza daripada fon sandaran (web.dev (dibuka dalam tab baharu)). Di kedai dalam talian, ini bermakna bar penghantaran percuma yang disisipkan di bahagian atas, penarafan bintang yang dimuatkan selepas tajuk, mesej bayaran ansuran di bawah harga, dan karusel cadangan produk. Shopify menyatakan bahawa kandungan pop timbul juga boleh menyebabkan anjakan (Shopify (dibuka dalam tab baharu)).

Anjakan dalam tempoh 500 ms selepas input pengguna tidak dikira, tetapi anjakan semasa menatal dikira, dan alat makmal sering terlepas pandang (web.dev (dibuka dalam tab baharu)). Berikan width dan height atau aspect-ratio CSS kepada imej, simpan ruang untuk widget, paparkan sepanduk sebagai lapisan di atas kandungan, kurangkan anjakan akibat pertukaran fon dengan size-adjust, dan buat animasi dengan transform dan bukan top atau left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Bagaimanakah cara meningkatkan Core Web Vitals di Shopify?

Di Shopify, kebanyakan peningkatan datang daripada memuatkan imej pertama secara serta-merta dengan keutamaan tinggi, mengurangkan skrip aplikasi, dan menyemak hasilnya dalam laporan prestasi web di panel pentadbir.

Semak data dalam panel pentadbir anda

Ringkasan dipaparkan pada halaman Kedai Dalam Talian > Tema (Online Store > Themes), dan laporan penuh LCP, INP dan CLS terdapat di bawah Analitis > Laporan (Analytics > Reports). Data boleh lewat sehingga 36 jam, dan mod peribadi mesti dimatikan (Shopify Help Center (dibuka dalam tab baharu)).

Kawal pemuatan imej dalam Liquid

Penapis image_tag memuatkan imej secara tertunda dalam bahagian yang lebih ke bawah halaman melainkan anda menetapkan preload (rujukan image_tag (dibuka dalam tab baharu)): serta-merta untuk bahagian 1 hingga 3, tertunda mulai bahagian 4. Oleh sebab section.index bernilai nil dalam editor tema, uji dengan > 3 dan bukan <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

Dalam grid produk, Shopify mencadangkan pemuatan serta-merta hanya untuk beberapa kad pertama (contohnya forloop.index <= 4) (Shopify (dibuka dalam tab baharu)). Gunakan preload: true dengan berhemat; Shopify mengesyorkan pramuat hanya untuk satu atau dua sumber yang ditemui lewat.

Buang sisa yang ditinggalkan aplikasi

Matikan app embed yang tidak digunakan di bawah Kedai Dalam Talian > Edit tema > App embeds (Online Store > Edit theme > App embeds) (Shopify Help Center (dibuka dalam tab baharu)). Menyahpasang aplikasi akan membuang blok aplikasinya, tetapi aplikasi yang menyunting fail tema secara langsung boleh meninggalkan "kod hantu" (ghost code) yang menurut Shopify boleh menyebabkan masalah kualiti dan prestasi (Shopify (dibuka dalam tab baharu)). Shopify juga menyatakan bahawa tag skrip (script tags) akan berhenti berjalan pada 1 Mac 2027. Untuk fon, Shopify mengesyorkan CDN miliknya sendiri atau fon sistem berbanding perkhidmatan fon luar (Shopify (dibuka dalam tab baharu)).

Bagaimanakah cara meningkatkan Core Web Vitals di WooCommerce?

Di WooCommerce, pastikan plugin tidak mengatasi keutamaan imej WordPress, cache semua halaman kecuali troli dan checkout, dan buang skrip yang dimuatkan di semua halaman tanpa keperluan.

  • Kekalkan pengendalian imej teras. Sejak WordPress 6.3 (dikeluarkan pada 8 Ogos 2023), teras WordPress menambah fetchpriority="high" pada imej yang berkemungkinan menjadi LCP (sekurang-kurangnya 50,000 piksel persegi secara lalai) dan tidak menggunakan lazy loading untuk tiga imej kandungan pertama (Make WordPress Core (dibuka dalam tab baharu)). Jika plugin pengoptimuman menambah lazy loading sendiri, pastikan ia mengecualikan imej hero dan imej produk utama.
  • Cache halaman, bukan troli. Panduan WooCommerce mengesyorkan cache halaman pada pelayan atau melalui plugin serta CDN, sambil memastikan halaman troli dan checkout tidak di-cache (dokumentasi pembangun WooCommerce (dibuka dalam tab baharu)).
  • Semak cart fragments. Sejak WooCommerce 7.8, skrip cart fragments hanya dimuatkan di tempat yang mempunyai widget Cart, tetapi sesetengah tema mengekodkan widget itu secara tetap. Blok Mini-Cart tidak menggunakan cart fragments (blog pembangun WooCommerce (dibuka dalam tab baharu)).
  • Cari plugin yang berat. WooCommerce mencadangkan Query Monitor untuk mencari plugin yang perlahan, dan menangguhkan JavaScript yang tidak kritikal.

Jika susun atur anda memaparkan lebih daripada tiga imej di bahagian atas skrin, anda boleh menaikkan ambang WordPress:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Berapa lamakah masa yang diambil untuk pembaikan kelihatan?

Ujian makmal menunjukkan kesan pembaikan dengan serta-merta, tetapi data lapangan memerlukan sehingga kira-kira empat minggu untuk mencerminkannya sepenuhnya, kerana CrUX mengambil purata 28 hari sebelumnya.

Jalankan ujian makmal beberapa kali sebelum dan selepas perubahan, kerana keputusan setiap larian berbeza-beza, kemudian pantau angka lapangan dalam PageSpeed Insights, laporan Core Web Vitals dalam Search Console atau laporan Shopify. Imbasan percuma memberikan bacaan awal dalam kira-kira seminit. Laporan Prestasi menjalankan ujian makmal mudah alih yang didikit (slow 4G, CPU 4x) dan menambah data lapangan Chrome UX Report, termasuk INP apabila Google mempunyai data yang mencukupi untuk kedai anda.

Soalan lazim

Adakah Core Web Vitals mempengaruhi kedudukan Google?

Google menyatakan bahawa Core Web Vitals digunakan oleh sistem kedudukannya, tetapi skor yang baik tidak menjamin kedudukan teratas dan Google tetap memaparkan kandungan yang paling relevan walaupun pengalaman halaman lemah (Google Search Central (dibuka dalam tab baharu)).

Mengapakah PageSpeed Insights tidak menunjukkan data lapangan untuk kedai saya?

CrUX hanya merangkumi halaman dan origin yang boleh ditemui secara awam dan mempunyai cukup pelawat Chrome yang layak. Kedai bertrafik rendah mungkin hanya mempunyai data peringkat origin, atau tiada langsung, jadi bergantunglah pada ujian makmal dan laporan platform anda sendiri.

Adakah saya memerlukan skor Lighthouse 90 atau lebih untuk lulus?

Tidak. Skor prestasi Lighthouse ialah keputusan makmal, manakala penilaian Core Web Vitals menggunakan data lapangan pada persentil ke-75, jadi halaman boleh lulus dengan skor Lighthouse yang sederhana dan gagal dengan skor yang tinggi.

Patutkah saya menggunakan lazy loading untuk semua imej produk?

Tidak. Gunakan lazy loading untuk imej di bawah skrin pertama, tetapi muatkan imej hero dan imej produk utama secara serta-merta, dengan fetchpriority="high" pada salah satu daripadanya.

Mengapakah keputusan mudah alih saya lebih teruk daripada desktop?

Google mengukur mudah alih dan desktop secara berasingan, dan telefon mempunyai pemproses dan rangkaian yang lebih perlahan. Ujian mudah alih Lighthouse mensimulasikan keadaan itu dengan profil Slow 4G dan pelambatan CPU 4x.

Sumber

Semua panduan