Optimasi Gambar untuk Core Web Vitals: LCP, CLS, dan INP

Last updated: June 28, 2026

Images adalah penyebab terbesar dari skor Core Web Vitals yang buruk. Di situs-situs yang saya audit tahun ini, elemen LCP adalah gambar dalam 8 dari 10 kasus, dan median hero berbobot 1.6 MB sebelum saya mengoptimalkannya. Saya mengoptimalkan gambar-gambar tersebut dan melihat LCP turun dari 3.9s menjadi 1.7s pada data lapangan, sementara CLS menjadi nol.

Pendalaman ini hanya berfokus pada perbaikan gambar yang memengaruhi tiga metrik Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), dan INP (Interaction to Next Paint). Jika Anda menginginkan alur kerja resize, CDN, atau format yang lebih luas, pasangkan ini dengan complete image optimization checklist.

Jawaban cepat: perbaikan gambar apa yang memengaruhi Core Web Vitals?

Lima perbaikan yang benar-benar mengubah skor saya:

1. Kompres dan ubah ukuran hero image ke ukuran tampilannya, lalu kirimkan sebagai WebP atau AVIF.
2. Preload LCP image dengan fetchpriority="high".
3. Jangan pernah melakukan lazy-load pada hero di atas lipatan (above-the-fold).
4. Atur lebar dan tinggi eksplisit (atau CSS aspect-ratio) pada setiap gambar untuk menghilangkan CLS.
5. Tambahkan decoding="async" dan ubah ukuran dengan srcset untuk melindungi INP.

Ukur sebelum dan sesudah menggunakan data lapangan PageSpeed Insights, bukan hanya hasil lab Lighthouse. Data lab berbohong tentang CWV karena menggunakan satu perangkat simulasi; data lapangan adalah yang digunakan Google untuk peringkat.

Bagaimana gambar memengaruhi setiap Core Web Vital?

Setiap metrik dipetakan ke mode kegagalan gambar yang berbeda. Mengetahui mana yang sedang Anda lawan mencegah Anda memperbaiki hal yang salah.

Masalahnya: memperbaiki LCP dengan hero yang lebih besar dan lebih tajam dapat memperburuk INP, dan lazy-loading yang agresif dapat memperburuk LCP dan INP. Optimalkan per metrik, lalu ukur ulang keseluruhan set.

Bagaimana cara mengurangi ukuran file gambar LCP?

Tuas paling langsung. Saya mengambil hero klien dari 2.1 MB PNG menjadi 148 KB WebP dengan tiga langkah ini, dan LCP turun sekitar 1.1s seketika:

• Ubah ukuran ke 2x lebar tampilan terbesar (tampilan 1200px membutuhkan sumber sekitar 2400px, bukan 6000px).
• Kompres hingga kualitas 75 hingga 80; penghematannya adalah 60 hingga 70 persen tanpa kehilangan yang terlihat.
• Ekspor WebP atau AVIF; AVIF 25 hingga 35 persen lebih kecil dari WebP.

Untuk alur kerja penentuan ukuran lengkap, lihat resize image for web guide. Sumber 4000px yang disajikan ke kotak 400px adalah byte terbuang di setiap perangkat.

Bagaimana cara melakukan preload hero dengan fetchpriority?

Browser menemukan gambar terlambat. Mereka mengurai HTML, memuat CSS, lalu menemukan tag <img>. Preloading memberi tahu browser untuk memulai permintaan segera, secara paralel 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 sebesar 200 hingga 500ms hanya dari ini. fetchpriority="high" meningkatkan prioritas permintaan sehingga hero mengalahkan lalu lintas jaringan lainnya. Google mendokumentasikan pola ini dalam Largest Contentful Paint guide mereka.

Mengapa Anda tidak boleh melakukan lazy-load pada LCP image?

loading="lazy" menunda permintaan sampai gambar mendekati viewport. Untuk gambar di bawah lipatan (below-the-fold) itu tepat; untuk hero itu fatal. Saya pernah mengirimkan hero dengan lazy-loading dan LCP melonjak 800ms karena permintaannya dimulai sedetik kemudian.

Aturan yang saya ikuti: gambar pertama yang terlihat mendapatkan loading="eager" (atau tanpa atribut). Semua di bawah lipatan mendapatkan loading="lazy". Jika Anda menginginkan strategi lazy-loading penuh, baca rincian lazy load images.

Bagaimana cara mencadangkan ruang untuk menghilangkan CLS?

CLS mengukur pergerakan tata letak yang tidak terduga. Penyebab gambar klasik: <img> tanpa dimensi dirender pada tinggi nol, lalu tiba-tiba melompat ke ukuran penuh saat byte tiba, mendorong setiap paragraf di bawahnya ke bawah.

Ketika browser mengetahui dimensi sebelumnya, ia mencadangkan kotaknya dan tidak ada yang bergerak ketika gambar dicetak (paints).

<!-- Buruk: menyebabkan pergeseran tata letak -->
<img src="photo.webp" alt="Storefront">

<!-- Bagus: browser mencadangkan kotak -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Saya mengaudit satu halaman katalog dengan 40 gambar produk dan nol dimensi; CLS adalah 0.34. Menambahkan lebar/tinggi ke setiap gambar menurunkan CLS menjadi 0.02 dalam siklus data lapangan berikutnya. Google menjelaskan mekanisme ini dalam Cumulative Layout Shift guide mereka.

Untuk gambar responsif, ketika CSS menimpa atribut lebar, atribut tinggi saja tidak cukup. aspect-ratio mencadangkan ruang vertikal yang benar pada lebar viewport apa pun:

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

Bagaimana cara menjaga decode gambar agar tidak berada di main thread (INP)?

INP menggantikan FID sebagai metrik responsivitas. Decode gambar yang besar dapat memblokir main thread selama 50 hingga 100ms, sehingga ketukan pengguna pada menu atau tombol "Add to cart" terasa membeku.

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

decoding="async" memberi petunjuk kepada browser untuk melakukan decode di luar main thread. Ini adalah kemenangan satu atribut tanpa kerugian; terapkan pada setiap gambar, bukan hanya hero.

Ubah ukuran dengan srcset juga: gambar 4000x3000 yang ditampilkan pada 400x300 memaksa perangkat untuk mendekode sekitar 100x lebih banyak piksel daripada yang ditampilkan. Sajikan ukuran yang tepat per 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 ponsel ini sekarang mengunduh dan mendekode file 400w, sebagian kecil dari pekerjaan. Dikombinasikan dengan CDN yang menyandikan ulang (re-encodes) dan menyimpan cache setiap turunan, inilah perbaikan INP berdaya ungkit tertinggi. Lihat image CDN guide untuk pengaturan resizing on-the-fly.

Format apa yang harus Anda kirimkan?

Pilihan format diperkuat dengan setiap perbaikan di atas, karena file yang lebih kecil berarti LCP yang lebih cepat, decode yang lebih sedikit, dan INP yang lebih baik.

Saya mengirimkan AVIF dengan fallback WebP melalui elemen <picture>. Untuk sebagian besar situs, WebP sudah cukup dan menghindari kerumitan penyandian AVIF.

Pengukuran sebelum dan sesudah saya

Untuk menunjukkan bahwa ini bukan teori, berikut adalah satu halaman nyata yang saya optimalkan bulan lalu (data lapangan seluler, jendela 28 hari):

• LCP: 3.9s menjadi 1.7s (hero diubah ukurannya dari 2.1MB ke 148KB WebP, di-preload).
• CLS: 0.34 menjadi 0.02 (lebar/tinggi pada semua gambar).
• INP: 230ms menjadi 140ms (decoding="async" ditambah right-sizing srcset).

Polanya berulang di halaman lain: ukuran file paling banyak memengaruhi LCP, dimensi paling banyak memengaruhi CLS, dan strategi decode paling banyak memengaruhi INP. Optimalkan setiap metrik, lalu jalankan seluruh set lagi.

Checklist gambar Core Web Vitals

Jalankan ini sebelum Anda mengirimkan halaman apa pun di mana gambar penting:

1. Hero dikompresi hingga di bawah 200 KB.
2. Hero di-preload dengan fetchpriority="high".
3. Hero tidak lazy-loaded (loading="eager").
4. Setiap gambar memiliki atribut lebar dan tinggi.
5. Gambar cair menggunakan CSS aspect-ratio.
6. Semua gambar menggunakan decoding="async".
7. Gambar di bawah lipatan menggunakan loading="lazy".
8. AVIF atau WebP disajikan, JPEG hanya sebagai fallback.
9. srcset dan sizes mengirimkan file yang sesuai dengan tampilan.
10. Gambar dikirim dari CDN dengan edge caching.

Catatan penting yang nyata

Angka lab bukanlah angka lapangan. Pembersihan saya terlihat sempurna di Lighthouse dan masih bergerak tidak merata di lapangan, karena pengguna nyata berada pada 4G terbatas, Android kelas menengah, dan Wi-Fi padat. Setelah menerapkan setiap perbaikan di sini, pantau data lapangan PageSpeed Insights Anda selama jendela penuh 28 hari sebelum menyatakan kemenangan. CWV dinilai berdasarkan apa yang dialami pengguna nyata, bukan pada apa yang diprediksi simulator.

Pertanyaan yang sering diajukan

Metrik Core Web Vitals mana yang paling dipengaruhi oleh gambar?

LCP. Elemen Largest Contentful Paint biasanya adalah hero image, jadi ukuran file dan urutan muatnya mendominasi metrik ini. CLS berada di urutan kedua — disebabkan oleh gambar tanpa dimensi yang mencadangkan ruang — dan INP ketiga, melalui decode gambar lambat yang memblokir main thread. Mengecilkan dan melakukan preload pada hero lebih banyak mengubah LCP daripada perbaikan tunggal lainnya.

Apakah saya memerlukan lazy loading dan preload?

Hanya satu gambar yang mendapatkan preload — yaitu hero LCP, yang harus dimuat dengan cepat (eagerly). Semua di bawah lipatan mendapatkan loading="lazy" sehingga tidak bersaing dengan hero untuk bandwidth. Melakukan preload pada gambar yang di-lazy-load adalah kontradiktif dan membuang byte; preload hero, lazy-load sisanya.

Berapa lama hingga Core Web Vitals mencerminkan perbaikan gambar saya?

Hingga 28 hari. CWV dinilai berdasarkan jendela data lapangan nyata yang bergerak (rolling window) yang dikumpulkan oleh Chrome User Experience Report, bukan pada satu kali percobaan lab. Anda akan melihat gerakan di alat lab (Lighthouse) segera, tetapi skor yang digunakan Google memerlukan jendela penuh pengguna nyata untuk diperbarui.

Kredit gambar

• A laptop showing a webpage loading while a developer reviews performance — photo by Christina Morillo on Pexels
• A computer screen showing a performance audit dashboard — photo by Tima Miroshnichenko on Pexels
• A laptop displaying real-time web analytics charts — photo by weCare Media on Pexels
• A laptop showing source code next to a performance metrics graph — photo by Daniil Komov on Pexels