Pengoptimuman Imej untuk Core Web Vitals: LCP, CLS dan INP

Dikemaskini kali terakhir: June 28, 2026

Imej adalah punca terbesar bagi skor Core Web Vitals yang buruk. Pada laman web yang saya audit tahun ini, elemen LCP ialah imej 8 daripada 10, dan hero mediannya seberat 1.6 MB sebelum saya menyentuhnya. Saya mengoptimumkan imej-imej itu dan melihat LCP turun dari 3.9s kepada 1.7s pada data lapangan, manakala CLS menjadi sifar.

Analisis mendalam ini hanya memfokuskan pada pembaikan imej yang mempengaruhi tiga metrik Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), dan INP (Interaction to Next Paint). Jika anda mahukan aliran kerja saiz, CDN, atau format yang lebih luas, gabungkan ini dengan senarai semak pengoptimuman imej lengkap.

Jawapan Ringkas: Pembaikan imej mana yang mengubah Core Web Vitals?

Lima pembaikan yang benar-benar mengubah skor saya:

1. Mampatkan dan ubah saiz imej hero kepada saiz paparannya, kemudian hantarkannya sebagai WebP atau AVIF.
2. Pra-muatkan imej LCP dengan fetchpriority="high".
3. Jangan pernah menggunakan lazy-load untuk imej hero di atas lipatan.
4. Tetapkan lebar dan tinggi (atau CSS aspect-ratio) secara eksplisit pada setiap imej untuk mengelakkan CLS.
5. Tambah decoding="async" dan saizkan dengan betul menggunakan srcset untuk melindungi INP.

Ukur sebelum dan selepas menggunakan data lapangan PageSpeed Insights, bukan hanya ujian makmal Lighthouse. Data makmal menipu tentang CWV kerana ia menggunakan peranti simulasi tunggal; data lapangan adalah apa yang Google gunakan untuk ranking.

Bagaimana imej mempengaruhi setiap Core Web Vital?

Setiap metrik dipetakan kepada mod kegagalan imej yang berbeza. Mengetahui mana yang anda lawan menghalang anda daripada membaiki perkara yang salah.

Masalahnya ialah: membaiki LCP dengan hero yang lebih besar dan tajam boleh merosakkan INP, dan lazy-loading yang agresif boleh merosakkan LCP dan INP. Optimumkan mengikut metrik, kemudian ukur semula keseluruhan set tersebut.

Bagaimana Mengurangkan Saiz Fail Imej LCP?

Tuas yang paling langsung. Saya mengambil satu imej hero klien dari 2.1 MB PNG kepada 148 KB WebP dengan tiga langkah ini, dan LCP jatuh kira-kira 1.1s serta-merta:

• Saiz semula kepada 2x lebar paparan terbesar (paparan 1200px memerlukan sumber kira-kira 2400px, bukan 6000px).
• Mampatkan kepada kualiti 75 hingga 80; penjimatan adalah 60 hingga 70 peratus tanpa kehilangan yang kelihatan.
• Eksport WebP atau AVIF; AVIF adalah 25 hingga 35 peratus lebih kecil daripada WebP.

Untuk aliran kerja saiz penuh, lihat panduan saiz semula imej untuk web. Sumber 4000px yang disajikan kepada kotak 400px adalah bait terbuang pada setiap peranti.

Bagaimana cara pra-muatkan hero dengan fetchpriority?

Pelayar menemui imej lewat. Mereka mengurai HTML, memuatkan CSS, kemudian mencari tag <img>. Pra-muat (Preloading) memberitahu pelayar untuk memulakan permintaan dengan serta-merta, secara selari dengan CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Saya mengukur kemenangan LCP 200 hingga 500ms hanya daripada ini. fetchpriority="high" meningkatkan keutamaan permintaan supaya hero mengatasi trafik rangkaian lain. Google mendokumentasikan corak ini dalam panduan Largest Contentful Paint mereka.

Mengapa anda tidak boleh melakukan lazy-load pada imej LCP?

loading="lazy" menangguhkan permintaan sehingga imej menghampiri viewport. Untuk imej di bawah lipatan (below-the-fold) itu tepat; tetapi untuk hero, ia adalah fatal. Saya pernah melancarkan sebuah hero dengan lazy-loading dan LCP melonjak 800ms kerana permintaan itu bermula satu saat kemudian.

Peraturan yang saya ikut: imej pertama yang kelihatan mendapat loading="eager" (atau tiada atribut). Semuanya di bawah lipatan mendapat loading="lazy". Jika anda mahukan strategi lazy-loading penuh, baca pecahan lazy load images.

Bagaimana cara memperuntukkan ruang untuk mengelakkan CLS?

CLS mengukur pergerakan susun atur yang tidak dijangka. Punca klasik imej: <img> tanpa dimensi akan dipaparkan pada ketinggian sifar, kemudian tiba-tiba membesar ke saiz penuh apabila bait sampai, menolak setiap perenggan di bawahnya ke bawah.

Apabila pelayar mengetahui dimensi terlebih dahulu, ia akan memperuntukkan kotak tersebut dan tiada apa-apa bergerak apabila imej dipaparkan.

<!-- Bad: causes layout shift -->
<img src="photo.webp" alt="Storefront">

<!-- Good: browser reserves the box -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Saya mengaudit satu halaman katalog dengan 40 imej produk dan sifar dimensi; CLS ialah 0.34. Menambah lebar/tinggi kepada setiap imej menurunkan CLS kepada 0.02 dalam kitaran data medan seterusnya. Google menerangkan mekanisme ini dalam panduan Cumulative Layout Shift mereka.

Untuk imej responsif, apabila CSS menimpa atribut lebar, atribut tinggi sahaja tidak mencukupi. aspect-ratio memperuntukkan ruang menegak yang betul pada sebarang lebar paparan:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Bagaimana anda mengekalkan pengekodan imej di luar main thread (INP)?

INP menggantikan FID sebagai metrik responsif. Pengekodan imej yang besar boleh menyekat main thread selama 50 hingga 100ms, menyebabkan sentuhan pengguna pada menu atau butang "Add to cart" terasa beku.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" memberi petunjuk kepada pelayar untuk mengekod di luar main thread. Ini adalah kemenangan satu atribut tanpa kelemahan; aplikasikannya pada setiap imej, bukan hanya hero.

Saizkan dengan betul menggunakan srcset juga: imej 4000x3000 yang dipaparkan pada 400x300 memaksa peranti untuk mengekod kira-kira 100x lebih banyak piksel daripada yang dipaparkannya. Sediakan saiz yang sesuai bagi setiap viewport dengan srcset dan sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

Pada telefon bimbit, ini kini memuat turun dan mengekod fail 400w, iaitu sebahagian kecil daripada kerja. Digabungkan dengan CDN yang menyulitkan semula dan menyimpan setiap derivatif, ini adalah penyelesaian INP paling berkesan. Lihat panduan CDN imej untuk penetapan saiz semula on-the-fly.

Format mana yang patut anda guna?

Pemilihan format ini semakin penting dengan setiap pembaikan di atas, kerana fail yang lebih kecil bermaksud LCP yang lebih pantas, kurang dekaod, dan INP yang lebih baik.

Saya menggunakan AVIF dengan sandaran WebP melalui elemen <picture>. Untuk kebanyakan laman web, WebP sudah memadai dan mengelakkan kerumitan pengekodan AVIF.

Pengukuran Saya Sebelum dan Selepas

Untuk menunjukkan ini bukan teori, di sini adalah satu halaman sebenar yang saya optimumkan bulan lepas (data lapangan mudah alih, jendela 28 hari):

• LCP: 3.9s to 1.7s (hero resized 2.1MB to 148KB WebP, preloaded).
• CLS: 0.34 to 0.02 (width/height on all images).
• INP: 230ms to 140ms (decoding="async" plus srcset right-sizing).

Corak ini berulang di halaman lain: saiz fail paling banyak mempengaruhi LCP, dimensi paling banyak mempengaruhi CLS, dan strategi decode paling banyak mempengaruhi INP. Optimumkan setiap metrik, kemudian jalankan semula keseluruhan set.

Senarai Semak Imej Core Web Vitals

Jalankan senarai semak ini sebelum anda menerbitkan sebarang halaman yang melibatkan imej:

1. Hero dimampatkan kepada kurang daripada 200 KB.
2. Hero dimuat awal (preloaded) dengan fetchpriority="high".
3. Hero tidak menggunakan pemuatan malas (lazy-loaded) (loading="eager").
4. Setiap imej mempunyai atribut lebar (width) dan tinggi (height).
5. Imej fleksibel menggunakan CSS aspect-ratio.
6. Semua imej menggunakan decoding="async".
7. Imej di bawah lipatan menggunakan loading="lazy".
8. AVIF atau WebP disajikan, dengan JPEG hanya sebagai sandaran.
9. srcset dan sizes menyediakan fail yang sesuai untuk paparan.
10. Imej disalurkan dari CDN dengan penimbalan tepi (edge caching).

Peringatan Sebenar

Nombor makmal tidak sama dengan nombor lapangan. Pembersihan saya kelihatan sempurna dalam Lighthouse dan masih menunjukkan pergerakan yang tidak sekata di lapangan, kerana pengguna sebenar berada pada sambungan 4G yang dihadkan (throttled), peranti Android kelas pertengahan, dan Wi-Fi yang sesak. Setelah melaksanakan setiap pembaikan di sini, perhatikan data lapangan PageSpeed Insights anda sepanjang jendela 28 hari penuh sebelum mengumumkan kejayaan. CWV dinilai berdasarkan pengalaman pengguna sebenar, bukan ramalan simulasi.

Soalan Lazim

Metrik Core Web Vitals manakah yang paling terjejas oleh imej?

LCP. Elemen Largest Contentful Paint biasanya adalah imej hero, jadi saiz fail dan urutan muatnya mendominasi metrik ini. CLS datang kedua — disebabkan oleh imej tanpa dimensi yang menempah ruang — dan INP ketiga, melalui pengekodan imej yang perlahan menghalang thread utama. Mengecilkan dan pra-memuat (preloading) hero akan menggerakkan LCP lebih daripada sebarang pembaikan tunggal lain.

Adakah saya memerlukan lazy loading dan preload?

Hanya satu imej yang mendapat preload — iaitu hero LCP, yang mesti dimuat secara segera (eagerly). Semua kandungan di bawah lipatan (below the fold) akan mendapat loading="lazy" supaya ia tidak bersaing dengan hero untuk jalur lebar (bandwidth). Pra-memuat imej yang dimuatkan secara lazy adalah bercanggah dan membazir bytes; pra-muatkan hero, muatkan baki secara lazy.

Berapa lama sehingga Core Web Vitals mencerminkan pembaikan imej saya?

Sehingga 28 hari. CWV dinilai berdasarkan tetingkap bergulir (rolling window) data lapangan sebenar yang dikumpul oleh Chrome User Experience Report, bukan pada satu ujian makmal sahaja. Anda akan melihat pergerakan dalam alat makmal (Lighthouse) dengan serta-merta, tetapi skor yang digunakan Google memerlukan tempoh penuh pengguna sebenar untuk dikemas kini.

Kredit Imej

• Laptop yang menunjukkan laman web sedang dimuatkan semasa seorang pembangun menyemak prestasi — foto oleh Christina Morillo di Pexels
• Skrin komputer yang menunjukkan papan pemuka audit prestasi — foto oleh Tima Miroshnichenko di Pexels
• Laptop yang memaparkan carta analitik web masa nyata — foto oleh weCare Media di Pexels
• Laptop yang menunjukkan kod sumber bersebelahan graf metrik prestasi — foto oleh Daniil Komov di Pexels