Optimasi Gambar

TL;DR — Optimasi gambar berarti memperkecil ukuran file gambar agar halaman dimuat cepat tanpa membuat tampilannya buruk. Gunakan format modern seperti WebP, kompres filenya, dan jangan kirim gambar yang jauh lebih besar daripada ukuran tampilannya di layar. Aturan yang paling sering dilanggar: gambar besar di bagian paling atas halaman harus dimuat segera—jangan pernah menerapkan lazy loading pada gambar itu. Praktik ini tidak otomatis menaikkan peringkat dan juga tidak menjamin skor kecepatan yang lulus; praktik ini hanya mempercepat halaman, dan kecepatanlah yang berpengaruh. Karena itu, periksa hasil nyata sebelum dan sesudah perubahan.

Apa yang sebenarnya dilakukan optimasi gambar

Gambar hampir selalu menjadi bagian terberat di sebuah halaman web. Dokumentasi Google sendiri menyatakan bahwa gambar “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (terjemahan) “sering kali menjadi penyumbang terbesar terhadap ukuran halaman secara keseluruhan, sehingga halaman bisa lambat dan mahal untuk dimuat.” Jadi, inti optimasi gambar adalah satu hal: mengurangi byte yang harus diunduh pengunjung agar halaman Anda cepat muncul.

Bagian yang kerap mengejutkan orang: format itu sendiri tidak meningkatkan peringkat. Mengubah JPEG menjadi WebP tidak akan menaikkan posisi Anda dengan sendirinya. Perubahan itu menghasilkan file yang lebih kecil, lalu membuat halaman lebih cepat, dan kecepatan itulah yang membantu. Artikel ini adalah pendamping hub Image SEO yang lebih luas—hub tersebut membahas teks alt, nama file, dan penelusuran gambar; artikel ini adalah panduan praktis untuk membuat gambar dimuat cepat.

Beberapa hal yang benar-benar penting

• Gunakan format modern. WebP dan AVIF menghasilkan file yang jauh lebih kecil daripada JPEG dan PNG lama tanpa membuat tampilannya lebih buruk. Saat ini, WebP merupakan pilihan baku yang aman.
• Kompres filenya. Bahkan WebP bisa terlalu besar. Jalankan gambar melalui alat kompresi dan cari titik ketika ukuran file sudah kecil tetapi tampilannya masih bagus.
• Jangan kirim gambar raksasa ke ruang yang kecil. Jika gambar hanya tampil selebar 500 piksel, Anda tidak memerlukan file selebar 3 000 piksel—unduhan sebesar itu terbuang percuma.
• Terapkan lazy loading pada gambar di bagian bawah halaman. Menambahkan loading="lazy" meminta browser menunggu hingga pengguna menggulir mendekati gambar sebelum memuatnya. Ini cocok untuk gambar di bawah area layar awal.
• Jangan pernah menerapkan lazy loading pada gambar besar di bagian atas. Gambar terbesar yang terlihat saat halaman pertama kali dimuat biasanya menjadi acuan pengukuran kecepatan. Gambar itu harus segera dimuat.

Kesalahan yang dilakukan kebanyakan orang

Mereka menerapkan lazy loading pada semuanya—termasuk gambar hero di bagian atas. Kedengarannya cerdas (“muat lebih sedikit!”), tetapi justru terbalik: gambar teratas biasanya menjadi acuan skor kecepatan halaman, sehingga menundanya membuat skor Anda lebih buruk. Muat gambar itu dengan eager loading dan beri tahu browser bahwa gambar tersebut penting. Caranya dijelaskan secara tepat di tab Advanced.

Jika Anda menginginkan versi yang lebih presisi—kutipan Google yang tepat, perbandingan WebP dan AVIF, perhitungan ukuran, serta teknik fetchpriority—buka tab Advanced.

TL;DR — Optimasi gambar adalah disiplin kecepatan halaman/Core Web Vitals, bukan pengungkit peringkat langsung. Pemilihan format (WebP, AVIF) mengurangi byte, tetapi tidak memberi dorongan SEO—Mueller telah menyatakannya dalam tiga kesempatan berbeda. Pertimbangkan pula transparansi, animasi, dan dukungan browser saat ini, bukan hanya rasio kompresi. Aturan paling bernilai: jangan pernah menerapkan lazy loading pada gambar LCP (biasanya gambar hero), karena tindakan itu menunda metrik yang sedang Anda optimalkan. Gunakan loading="eager" + fetchpriority="high", tetapi petunjuk prioritas hanya membantu hambatan penemuan atau waktu pengambilan sumber daya, bukan setiap masalah LCP. loading="lazy" native ditujukan untuk gambar di luar viewport awal, bukan garis piksel “di bawah fold” yang tetap. Tidak ada kualitas kompresi yang berlaku universal—uji setiap jenis gambar. Dimensi yang benar = ukuran kontainer hasil render × device pixel ratio. Karena ukuran kontainer ikut berubah dalam tata letak responsif, sediakan rentang srcset/sizes (nilai sizes yang salah diam-diam mengunduh gambar terlalu besar) beserta fallback <picture>. Gambar merupakan elemen LCP yang paling umum di web; itulah sebabnya artikel ini juga masuk ke Web Performance. Namun, semua ini tidak menjamin skor Core Web Vitals yang lulus, perubahan peringkat, atau tambahan traffic; ukur sebelum dan sesudah.

Sasaran optimasi gambar (luruskan mitos sejak awal)

Mari singkirkan mitos terbesar lebih dahulu: format gambar adalah pengungkit kecepatan, bukan pengungkit peringkat. Mengonversi gambar ke WebP atau AVIF tidak memberi kenaikan peringkat. Hasilnya adalah file yang lebih kecil, yang menghasilkan halaman lebih cepat, lalu membantu Core Web Vitals—dan bagian itulah yang digunakan sistem penelusuran. Rantai sebab-akibatnya nyata tetapi tidak langsung; banyak panduan pesaing keliru ketika meringkasnya menjadi “format generasi baru mendapat peringkat lebih baik”.

Dokumentasi Google sangat lugas tentang mengapa gambar penting bagi kecepatan: gambar “often the largest contributor to overall page size, which can make pages slow and expensive to load,” (terjemahan) “sering kali menjadi penyumbang terbesar terhadap ukuran halaman secara keseluruhan, sehingga halaman bisa lambat dan mahal untuk dimuat,” dan sarannya adalah “apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience” (terjemahan) “terapkan teknik optimasi gambar dan gambar responsif terbaru untuk memberikan pengalaman pengguna yang cepat dan berkualitas tinggi” (Google Search Central — Gambar). Perhatikan bingkainya: pengalaman pengguna yang cepat, bukan hadiah peringkat untuk format file.

Untuk pembahasan apa dan mengapa Image SEO secara menyeluruh—teks alt, nama file, sitemap gambar, data terstruktur, dan peringkat penelusuran gambar—lihat hub utama Image SEO. Artikel ini adalah rujukan cara menerapkannya: format, kompresi, ukuran, dan strategi pemuatan.

Mulai dari aturan yang paling sering dilanggar: jangan pernah lazy-load gambar LCP

Jika Anda hanya mengingat satu hal dari halaman ini, ingatlah ini. Elemen Largest Contentful Paint (LCP)—elemen terbesar yang digambar di viewport saat pemuatan—adalah “either an image or a web font,” (terjemahan) “gambar atau font web,” menurut web.dev (Optimalkan LCP). Di sebagian besar halaman, elemen itu berupa gambar: hero, gambar unggulan, atau foto produk. web.dev menyampaikan aturannya dengan sangat tegas:

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (terjemahan) “Jangan pernah menerapkan lazy loading pada gambar LCP, karena hal itu akan selalu menimbulkan penundaan pemuatan sumber daya yang tidak perlu dan berdampak buruk pada LCP.”

Inilah nuansa yang hilang dari kebanyakan saran “cukup gunakan lazy loading”. Lazy loading memang sangat berguna—untuk gambar yang berada di bawah area layar awal. Jika diterapkan pada gambar LCP, Anda justru menunda metrik yang ingin diperbaiki. Panduan lazy loading web.dev menyampaikan hal yang sama dari arah sebaliknya: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (terjemahan) “Jangan menerapkan lazy loading pada gambar yang kemungkinan berada di dalam viewport saat halaman dimuat, terutama gambar LCP” (Lazy loading tingkat browser).

Saya mengemukakan argumen yang sama dalam artikel LCP saya di Ahrefs: elemen terbesar “is usually going to be a featured image or maybe the <h1> tag,” (terjemahan) “biasanya berupa gambar unggulan atau mungkin tag <h1>,” dan perbaikannya mengikuti fakta tersebut. “If you don’t need the image, the most impactful solution is to simply get rid of it. If you must have the image, I suggest optimizing the size and quality to keep it as small as possible.” (terjemahan) “Jika Anda tidak memerlukan gambar itu, solusi yang paling berdampak adalah menghapusnya. Jika gambar tersebut harus ada, saya menyarankan agar ukuran dan kualitasnya dioptimalkan supaya sekecil mungkin.” Anda sebaiknya “lazy load any images that you don’t need immediately” (terjemahan) “menerapkan lazy loading pada gambar yang tidak segera diperlukan”—tetapi sisi sebaliknya adalah aturan tegas yang sengaja saya tulis dengan huruf kapital: “Do not lazy load images above the fold!” (terjemahan) “Jangan menerapkan lazy loading pada gambar di atas fold!”

fetchpriority="high" pada gambar LCP

Tidak menerapkan lazy loading pada hero memang perlu, tetapi belum cukup. Agar gambar LCP dimuat sedini mungkin, beri browser petunjuk tentang prioritasnya. Menurut web.dev:

“You can hint to the browser as to which resources are most important using the fetchpriority attribute… It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (terjemahan) “Anda dapat memberi petunjuk kepada browser tentang sumber daya yang paling penting dengan atribut fetchpriority… Sebaiknya tetapkan fetchpriority="high" pada elemen <img> jika menurut Anda elemen itu kemungkinan menjadi elemen LCP halaman.”

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

Dalam tulisan saya tentang LCP, fetchpriority="high" dijelaskan dengan cara yang sama—atribut ini “can be used on <img> or <link> tags and tells browsers to get the image early” (terjemahan) “dapat digunakan pada tag <img> atau <link> dan meminta browser mengambil gambar lebih awal”—dan saya memasangkannya dengan Early Hints (respons 103) sebagai cara pelengkap untuk memulai pengambilan sebelum HTML utama tiba. Jadi, resep LCP adalah: eager loading + fetchpriority="high" (+ Early Hints jika stack Anda mendukungnya). Semua gambar lain di halaman dapat menggunakan lazy loading.

Perlakukan fetchpriority dan preload sebagai alat untuk hambatan tertentu, bukan perbaikan yang terjamin. Keduanya membantu ketika gambar LCP terlambat ditemukan atau diambil; keduanya tidak mengatasi respons server yang lambat, sumber daya pemblokir render yang berada sebelum gambar, atau file yang benar-benar terlalu besar. Pastikan hambatan yang sebenarnya Anda hadapi (PageSpeed Insights atau Lighthouse memecah LCP menjadi beberapa subbagian) sebelum menganggap petunjuk prioritas saja akan mengubah angkanya.

loading="lazy" native—gratis, sederhana, dan tepat untuk gambar di bawah area awal

Untuk setiap gambar yang tidak berada di viewport awal, lazy loading native adalah peningkatan performa yang paling mudah. web.dev menyatakan: “You can use the loading attribute to lazy-load images without the need to write custom lazy-loading code or use a separate JavaScript library.” (terjemahan) “Anda dapat menggunakan atribut loading untuk menerapkan lazy loading pada gambar tanpa perlu menulis kode lazy loading khusus atau memakai pustaka JavaScript terpisah.”

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

Dua hal menjaga penerapan ini tetap aman:

• Dasarkan keputusan pada viewport awal, bukan garis “di bawah fold” yang tetap. “Fold” bukan jumlah piksel yang tetap; posisinya berubah mengikuti ukuran viewport dan tata letak. Uji yang sebenarnya adalah apakah gambar kemungkinan terlihat saat halaman pertama kali digambar. Semua gambar yang terlihat—terutama gambar LCP—menggunakan loading="eager" (nilai baku), bukan lazy.
• Utamakan atribut native daripada trik JavaScript. Lazy loader JavaScript yang menyembunyikan URL sebenarnya di data-src dan tidak pernah mengekspos src berisiko membuat gambar sama sekali tidak diindeks. loading="lazy" native (atau IntersectionObserver yang bersih) menjaga src tetap terlihat oleh crawler. Hub utama Image SEO membahas peringatan pengindeksan ini secara lengkap.

Format modern: WebP vs. AVIF vs. JPEG/PNG

Mitos paling perlu diluruskan ketika membahas format. Karena itu, mari kita nyatakan dengan tepat apa manfaat setiap format: byte yang lebih sedikit, bukan peringkat yang lebih tinggi.

• WebP — “often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression” (terjemahan) “sering memiliki kompresi yang lebih baik daripada JPEG, PNG, atau GIF, serta menawarkan kompresi lossy dan lossless” (web.dev—Performa gambar). Ukurannya kira-kira 25–35% lebih kecil daripada JPEG dengan dukungan browser yang hampir universal. Ini adalah pilihan baku yang aman untuk foto saat ini.
• AVIF — “supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (terjemahan) “mendukung kompresi lossy dan lossless, dan pengujian menunjukkan penghematan lebih dari 50% dibandingkan JPEG dalam beberapa kasus.” Kompresinya termasuk yang terbaik, tetapi dukungannya sedikit kurang universal; pasangkan dengan fallback WebP atau JPEG.
• JPEG — fallback universal untuk foto.
• PNG — gunakan saat Anda memerlukan transparansi atau grafis dengan tepi yang tajam.
• SVG — untuk logo dan ikon: berbasis vektor, dapat diskalakan tanpa batas, dan berukuran kecil.

Format yang dipilih juga bergantung pada kebutuhan gambar, bukan sekadar format mana yang paling kuat mengompresi. Transparansi, animasi, serta konsistensi dukungan browser atau alat terhadap kombinasi fitur tertentu ikut menentukan pilihan di samping penghematan ukuran mentah di atas. Periksa dukungan terkini untuk fitur yang benar-benar Anda perlukan—terutama animasi—sebelum menetapkan satu format sebagai pilihan baku.

Google Penelusuran mendukung “BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (terjemahan) “BMP, GIF, JPEG, PNG, WebP, SVG, dan AVIF” yang dirujuk melalui src pada <img>. Sajikan format modern dengan fallback yang anggun menggunakan <picture>:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

<img src> di bagian paling bawah adalah jaring pengaman Anda—browser lama dan crawler akan menggunakan fallback tersebut, dan URL itulah yang sebenarnya diindeks Google.

Apakah format memengaruhi peringkat? (Tidak—Mueller telah menyatakannya dalam tiga cara)

Inilah satu benang pelurusan mitos yang perlu dibawa sepanjang topik ini. Tiga pernyataan John Mueller pada waktu yang berbeda menghasilkan kesimpulan yang sama: format memengaruhi mekanisme crawling/pengindeksan dan bobot halaman, tetapi tidak pernah memengaruhi peringkat secara langsung:

1. AVIF tidak memberi dorongan SEO. Setelah Google menambahkan dukungan AVIF native, Mueller mengonfirmasi bahwa penggunaan AVIF dibandingkan format lain yang didukung tidak memberi “SEO boost” (terjemahan) “dorongan SEO” (liputan SE Roundtable).
2. WebP “baik-baik saja”. “WebP images are fine for Image Search” (terjemahan) “Gambar WebP baik-baik saja untuk Penelusuran Gambar”—perhatikan bahwa ia mengatakan “baik-baik saja”, bukan “lebih baik” (liputan SE Roundtable).
3. Keanehan pengindeksan WebP tidak khusus untuk format itu. Ketika file WebP muncul sebagai “Crawled – currently not indexed” (terjemahan) “Di-crawl—saat ini tidak diindeks” di GSC, poin Mueller adalah file gambar tidak diindeks sebagai halaman HTML, dan menurutnya fenomena tersebut sama sekali tidak terbatas pada WebP (liputan SEJ).

Kompresi dan kualitas: tidak ada pengaturan “tepat” yang universal

Saran buruk yang paling umum dalam panduan gambar adalah satu butir “kompres hingga 80%”. web.dev menegaskan bahwa angka ajaib semacam itu tidak ada:

“When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (terjemahan) “Saat mengompresi, tidak ada satu pengaturan universal yang cocok untuk semua kasus. Pendekatan yang disarankan adalah bereksperimen dengan berbagai tingkat kompresi hingga Anda menemukan kompromi yang baik antara kualitas gambar dan ukuran file.”

Secara praktis: uji setiap jenis gambar. Foto dapat menerima kompresi lossy agresif dengan baik; grafis, logo, dan tangkapan layar berisi teks cepat memperlihatkan artefak dan sering memerlukan kompresi lossless atau pengaturan kualitas lebih tinggi. Alih-alih memercayai satu slider, ekspor gambar yang sama pada dua atau tiga tingkat kualitas lalu bandingkan pada ukuran tampilannya. Pilih file terkecil yang secara visual tidak dapat Anda bedakan dari gambar asli. Itu adalah alur kerja nyata, bukan sekadar “masukkan ke TinyPNG lalu berharap”.

Dimensi yang benar: ukuran kontainer × device pixel ratio

Aturannya bukan “buat saja lebih kecil”, melainkan cocokkan ukuran hasil render × device pixel ratio (DPR). Menurut web.dev:

“An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (terjemahan) “Gambar yang ditampilkan dalam kontainer 500 × 500 piksel akan memiliki ukuran optimal 500 × 500 piksel.”

“If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (terjemahan) “Jika perangkat memiliki DPR 2 dan gambar ditampilkan dalam kontainer 500 × 500 piksel, gambar persegi 1 000 piksel… kini menjadi ukuran yang optimal.”

Jadi, kontainer 500×500 pada layar 2× (kelas Retina) membutuhkan sumber 1 000×1 000. Jika lebih besar, Anda membuang byte tanpa peningkatan yang terlihat; jika lebih kecil, gambar tampak kurang tajam pada layar ber-DPR tinggi. Karena itu, sajikan rentang ukuran dan biarkan browser memilih dengan srcset + sizes:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

Browser membaca lebar kontainer (sizes) dan DPR perangkatnya, lalu memilih kandidat yang tepat dari srcset—versi pengiriman responsif dari perhitungan DPR di atas. Google menyarankan <picture> atau srcset untuk gambar responsif dan meminta Anda “always specify a fallback URL using the src attribute.” (terjemahan) “selalu tentukan URL fallback dengan atribut src.”

Jika sizes salah, tidak ada peringatan. Ketika nilai yang Anda deklarasikan tidak sesuai dengan lebar hasil render gambar—bug yang umum setelah perubahan tata letak atau CSS—browser tidak dapat mengetahuinya dan hanya memilih kandidat berdasarkan angka yang tidak akurat itu. Akibatnya, browser sering mengunduh file yang lebih besar daripada kebutuhan tata letak. Hal ini diam-diam membatalkan hasil optimasi format dan kompresi. Satu-satunya cara andal untuk menemukannya: buka panel Network di DevTools, cari permintaan gambar, lalu bandingkan dimensi file yang dikirim dengan lebar kontainer yang sebenarnya dirender.

Contoh 500×500 di atas hanya ilustrasi, bukan angka untuk di-hard-code di seluruh situs. Gambar hero yang sama dapat dirender dengan lebar berbeda di perangkat seluler dan desktop, sehingga “ukuran kontainer” berubah mengikuti tata letak responsif. Itulah alasan Anda menyediakan rentang srcset, bukan mengekspor satu ukuran “optimal” lalu menganggap pekerjaan selesai.

Mengapa semua ini kembali pada Core Web Vitals

Benang merah yang menghubungkan semua teknik di atas adalah LCP. Gambar merupakan elemen LCP yang paling umum di web, dan LCP adalah satu dari tiga Core Web Vitals. Target Google: “LCP should occur within 2.5 seconds” (terjemahan) “LCP harus terjadi dalam 2,5 detik” pada persentil ke-75 pemuatan halaman di perangkat seluler dan desktop (web.dev—Vitals). Core Web Vitals “apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (terjemahan) “berlaku untuk semua halaman web, harus diukur oleh semua pemilik situs, dan akan ditampilkan di seluruh alat Google.”

Jadi, optimasi gambar bukan faktor peringkat tersendiri; optimasi ini adalah kontributor terhadap sinyal pengalaman halaman (Core Web Vitals) yang memang digunakan sistem peringkat. Pembingkaian inilah yang akurat dan menjadi alasan artikel ini berada di cluster Image SEO sekaligus Web Performance. Untuk pembahasan mendalam tentang metriknya, lihat Core Web Vitals dan LCP di Web Performance.

Satu peringatan lain perlu dinyatakan dengan jelas: tidak satu pun perbaikan di halaman ini menjamin hasil. Byte gambar hanyalah salah satu kemungkinan komponen LCP—uraian subbagian LCP dari web.dev juga mencakup waktu respons server dan sumber daya pemblokir render yang mendahului gambar, yang tidak disentuh oleh perubahan format atau kompresi. Dimensi gambar pun hanya satu dari beberapa masukan ke CLS, bukan jaminan skor tertentu. Memperkecil gambar hero dapat menghasilkan peningkatan terukur, tidak berpengaruh, atau nyaris tidak mengubah angka jika hambatan sebenarnya terletak di tempat lain. Optimasi gambar juga tidak menjamin penilaian Core Web Vitals yang lulus, perubahan peringkat, tambahan traffic, peningkatan konversi, atau kutipan dalam penelusuran AI—semuanya bergantung pada jauh lebih banyak hal daripada byte gambar. Perlakukan setiap perbaikan sebagai hipotesis, bukan hasil final: ukur LCP dan CLS sebelum dan sesudah, di lab dan di lapangan, lalu biarkan data tersebut—bukan asumsi bahwa optimasi “berhasil”—menunjukkan apakah ada perubahan.

Kesalahan penerapan yang umum

• Gambar latar CSS tidak diindeks. Developer terkadang mengganti <img> dengan background-image demi kemudahan tata letak. Google “can find images in the src attribute of <img> element (even when it’s a child of other elements, such as the <picture> element)” (terjemahan) “dapat menemukan gambar dalam atribut src elemen <img> (bahkan ketika elemen itu merupakan turunan elemen lain, seperti elemen <picture>)”, tetapi “doesn’t index CSS images.” (terjemahan) “tidak mengindeks gambar CSS.” Jika ingin gambar muncul di penelusuran gambar, pertahankan dalam <img>. (Masalah ini berdekatan dengan performa, tetapi cukup umum untuk disorot.)
• Jangan mengganti nama file lama secara massal demi “penyegaran” performa/SEO. Mueller mengatakan sistem Google memerlukan “a lot of time” (terjemahan) “banyak waktu” untuk memproses ulang gambar yang namanya diubah, dan pengaruhnya kecil jika konteks Anda sudah baik—hub utama Image SEO membahasnya secara lengkap.
• width/height tidak ada. Selalu tetapkan width dan height intrinsik (atau aspect-ratio CSS) agar browser dapat memesan ruang sebelum gambar dimuat. Tindakan ini mengurangi pergeseran tata letak akibat gambar, tetapi hanya satu dari beberapa masukan ke CLS dan bukan jaminan skor tertentu.

Resep singkat

• Gambar hero/LCP: format modern, ukuran tepat, loading="eager", fetchpriority="high".
• Semua gambar di bawah area layar awal: loading="lazy".
• Sajikan WebP/AVIF dengan fallback src pada <picture>.
• Sesuaikan ukuran dengan kontainer × DPR; kirim rentang srcset beserta sizes.
• Kompres sesuai jenis gambar—uji 2–3 tingkat kualitas, jangan memercayai satu slider.
• Selalu tetapkan width/height.

Untuk aspek Image SEO lainnya—teks alt, nama file, sitemap gambar, data terstruktur, dan peringkat penelusuran gambar—kembali ke hub Image SEO.

Ringkasan AI

Versi ringkas dari pembahasan Advanced:

• Optimasi gambar = kecepatan, bukan pengungkit peringkat. Pemilihan format (WebP/AVIF) mengurangi byte → mempercepat halaman → memperbaiki Core Web Vitals. Format itu sendiri tidak memberi kenaikan peringkat langsung—Mueller mengonfirmasinya dalam tiga cara berbeda (AVIF “tanpa dorongan SEO”, WebP “baik-baik saja”, dan keanehan pengindeksan WebP tidak khusus untuk format itu).
• Aturan nomor satu: jangan pernah lazy-load gambar LCP. Gambar yang kemungkinan terlihat ketika halaman pertama kali digambar (biasanya hero) menentukan LCP; lazy loading menunda metrik yang sedang Anda perbaiki. Gunakan loading="eager" + fetchpriority="high" (opsional: Early Hints). Namun, petunjuk prioritas hanya mengatasi hambatan penemuan/waktu pengambilan, bukan semua masalah LCP; periksa subbagian LCP sebelum menganggap petunjuk itu saja akan membantu.
• loading="lazy" native gratis dan tepat—untuk gambar di luar viewport awal, bukan garis piksel “di bawah fold” yang tetap. Hindari lazy loader JS yang menyembunyikan URL di data-src.
• Format: WebP adalah pilihan baku yang aman (sekitar 25–35% lebih kecil daripada JPEG); AVIF dapat mengompresi lebih jauh (lebih dari 50% dalam beberapa pengujian) dengan fallback. Pilihan juga bergantung pada transparansi, animasi, dan dukungan browser/alat terkini, bukan hanya rasio kompresi. Sajikan melalui <picture> dengan fallback <img src> yang dapat diindeks Google.
• Kompresi: tidak ada kualitas “tepat” yang universal—uji per jenis gambar (foto tahan terhadap kompresi kuat; teks/grafis cepat menunjukkan artefak).
• Ukuran: ukuran yang benar = ukuran kontainer hasil render × device pixel ratio (kontainer 500px pada DPR 2× = sumber 1,000px). Karena ukuran kontainer berubah mengikuti tata letak responsif, sediakan rentang melalui srcset + sizes, bukan satu ekspor tetap. Nilai sizes yang salah diam-diam membuat browser mengunduh kandidat yang terlalu besar.
• Mengapa penting: gambar merupakan elemen LCP yang paling umum; target LCP adalah 2,5 detik pada persentil ke-75. Itulah sebabnya artikel ini juga masuk ke Web Performance. Namun, LCP memiliki subbagian lain (waktu respons server, sumber daya pemblokir render) yang tidak dapat diperbaiki hanya dengan mengurangi byte gambar.
• Tidak ada jaminan: optimasi gambar tidak dengan sendirinya menjamin skor Core Web Vitals yang lulus, perubahan peringkat, tambahan traffic, lebih banyak konversi, atau kutipan penelusuran AI. Ukur LCP/CLS sebelum dan sesudah, di lab dan di lapangan.
• Kesalahan umum: background-image CSS tidak diindeks; jangan mengganti nama file secara massal; selalu tetapkan width/height—atribut ini dapat mengurangi pergeseran tata letak, tetapi tidak menjamin skor CLS tertentu.

Dokumentasi resmi

Dokumentasi sumber primer dari mesin pencari dan tim Chrome.

Google / web.dev

• Performa gambar (web.dev “Learn Performance”) — format, ketiadaan “pengaturan kompresi universal”, dan perhitungan ukuran DPR.
• Lazy loading gambar tingkat browser (web.dev) — cara kerja loading="lazy" native dan pengecualian “jangan lazy-load gambar di viewport/LCP”.
• Optimalkan LCP (web.dev) — fetchpriority, sumber daya LCP berupa gambar atau font, dan “jangan pernah lazy-load gambar LCP”.
• Fetch Priority API (web.dev) — penjelasan lengkap fetchpriority="high" untuk gambar LCP.
• Web Vitals (web.dev) — definisi Core Web Vitals dan ambang LCP ≤ 2,5 detik/persentil ke-75.
• Praktik terbaik Google Gambar — format yang didukung, pengindeksan <img>/<picture> (bukan latar CSS), gambar responsif, dan rekomendasi fallback src.

Bing / Microsoft

• Bing tidak menerbitkan panduan teknis khusus optimasi gambar yang sedetail panduan Google. Panduan yang relevan berada dalam Pedoman Webmaster Bing umum, yang memperlakukan kecepatan halaman (termasuk bobot gambar) sebagai pertimbangan. Hal ini dinyatakan apa adanya, bukan dengan mengarang “kutipan” Bing yang tidak ada.
• Bing Visual Search — penelusuran visual pada tingkat objek; relevan bagi penemuan gambar, terpisah dari pengaruh format/kompresi terhadap kecepatan halaman.

Kutipan dari sumber

Pernyataan resmi dari tim Chrome Google dan Search Advocates. Jika halaman menyediakan teksnya, tautan berikut mengarah langsung ke bagian yang dikutip.

web.dev (tim Google Chrome)—aturan LCP

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (terjemahan) “Jangan pernah menerapkan lazy loading pada gambar LCP, karena hal itu akan selalu menimbulkan penundaan pemuatan sumber daya yang tidak perlu dan berdampak buruk pada LCP.” Buka kutipan
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (terjemahan) “Jangan menerapkan lazy loading pada gambar yang kemungkinan berada di dalam viewport saat halaman dimuat, terutama gambar LCP.” Buka kutipan
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (terjemahan) “Sebaiknya tetapkan fetchpriority=“high” pada elemen <img> jika menurut Anda elemen itu kemungkinan menjadi elemen LCP halaman.” — web.dev, Optimize LCP.

web.dev (tim Google Chrome)—format, kompresi, ukuran

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (terjemahan) “WebP sering memiliki kompresi yang lebih baik daripada JPEG, PNG, atau GIF, serta menawarkan kompresi lossy dan lossless.” Buka kutipan
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (terjemahan) “AVIF mendukung kompresi lossy dan lossless, dan pengujian menunjukkan penghematan lebih dari 50% dibandingkan JPEG dalam beberapa kasus.” — web.dev, Image performance.
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (terjemahan) “Saat mengompresi, tidak ada satu pengaturan universal yang cocok untuk semua kasus. Pendekatan yang disarankan adalah bereksperimen dengan berbagai tingkat kompresi hingga Anda menemukan kompromi yang baik antara kualitas gambar dan ukuran file.” — web.dev, Image performance.
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (terjemahan) “Untuk gambar di dalam wadah berukuran 500 × 500 piksel, dimensi optimal gambarnya juga 500 × 500 piksel.” … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” (terjemahan) “Jika perangkat memiliki DPR 2 … gambar persegi 1 000 piksel … kini menjadi ukuran yang optimal.” — web.dev, Image performance.

Google Search Central—mengapa gambar penting bagi kecepatan

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (terjemahan) “Gambar sering kali menjadi penyumbang terbesar terhadap ukuran halaman secara keseluruhan, sehingga halaman bisa lambat dan mahal untuk dimuat.” Buka kutipan

web.dev—Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (terjemahan) “Core Web Vitals adalah bagian dari Web Vitals yang berlaku untuk semua halaman web, harus diukur oleh semua pemilik situs, dan akan ditampilkan di seluruh alat Google.” Buka kutipan

John Mueller, Google—format bukan pengungkit peringkat

• Tentang AVIF: penggunaan file AVIF tidak memberi “SEO boost” (terjemahan) “dorongan SEO”. Liputan
• Tentang WebP: “WebP images are fine for Image Search.” (terjemahan) “Gambar WebP baik-baik saja untuk Penelusuran Gambar.” Liputan

Checklist optimasi gambar

Jalankan pemeriksaan ini pada setiap halaman yang sensitif terhadap performa:

• Sudah mengidentifikasi gambar LCP (biasanya hero/gambar unggulan/foto produk pertama).
• Gambar LCP tidak menggunakan lazy loading—gambar memakai loading="eager" (nilai baku).
• Gambar LCP memiliki fetchpriority="high" (pertimbangkan Early Hints jika stack mendukungnya).
• Setiap gambar di luar viewport awal memiliki loading="lazy".
• Format modern disajikan (WebP sebagai baku, AVIF jika didukung) dengan fallback src pada <picture>.
• Setiap gambar disesuaikan dengan ukuran kontainer × device pixel ratio—tidak ada file 3,000px dalam slot 500px.
• Pengiriman responsif memakai srcset + sizes ketika gambar dirender dengan lebar berbeda.
• Kompresi diuji per jenis gambar (2–3 tingkat kualitas dibandingkan pada ukuran tampilan), bukan satu pengaturan menyeluruh.
• width dan height intrinsik (atau aspect-ratio CSS) ditetapkan pada setiap gambar untuk mengurangi pergeseran tata letak (CLS)—bukan jaminan skor tertentu.
• Tidak ada gambar konten yang hanya berada dalam background-image CSS (gambar semacam itu tidak diindeks).
• Lazy loading memakai atribut native (atau IntersectionObserver yang bersih), bukan trik JS yang menyembunyikan URL di data-src.
• LCP sudah diverifikasi di lapangan (CrUX/PageSpeed Insights), dengan sasaran ≤ 2,5 detik pada persentil ke-75.

Lembar ringkas optimasi gambar

Pengungkit—fungsi dan praktik terbaiknya

Fakta singkat

• Format adalah pengungkit kecepatan, bukan peringkat—Mueller: AVIF tidak memberi “dorongan SEO”; WebP “baik-baik saja”.
• WebP sekitar 25–35% lebih kecil daripada JPEG; AVIF sering kali lebih dari 50% lebih kecil dalam pengujian.
• Aturan paling bernilai: jangan pernah lazy-load gambar LCP.
• Target LCP: ≤ 2,5 detik pada persentil ke-75 (seluler + desktop).
• Format yang didukung: BMP, GIF, JPEG, PNG, WebP, SVG, AVIF.
• Ukuran yang benar = ukuran kontainer hasil render × device pixel ratio.

Kesalahan yang merusak skor LCP

Menerapkan lazy loading pada gambar hero adalah kesalahan paling mahal yang dibahas dalam artikel ini, sehingga layak disorot tersendiri sebelum kesalahan lainnya.

• Salah: menerapkan loading="lazy" (atau lazy loader JS) pada gambar terbesar di atas fold—biasanya hero, gambar unggulan, atau foto produk pertama. Mengapa salah: gambar itu hampir selalu menjadi elemen LCP, dan web.dev menegaskan bahwa lazy loading “will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (terjemahan) “akan selalu menimbulkan penundaan pemuatan sumber daya yang tidak perlu dan berdampak buruk pada LCP.” Akhirnya, Anda menunda metrik yang sebenarnya ingin diperbaiki. Lakukan ini: gunakan loading="eager" (nilai baku) plus fetchpriority="high" pada gambar LCP, dan batasi loading="lazy" untuk gambar di luar viewport awal.

Memercayai satu pengaturan kompresi untuk semua gambar

• Salah: menjalankan setiap gambar melalui preset “kompres hingga 80%” yang sama tanpa mempertimbangkan kontennya. Mengapa salah: web.dev menyatakan dengan jelas bahwa “there isn’t a universal setting suitable for all cases” (terjemahan) “tidak ada satu pengaturan universal yang cocok untuk semua kasus”—preset yang disetel untuk foto akan mengompresi logo, tangkapan layar, dan grafis berisi teks secara berlebihan hingga menimbulkan artefak yang terlihat. Lakukan ini: ekspor gambar yang sama pada dua atau tiga tingkat kualitas dan bandingkan pada ukuran tampilan sebenarnya; untuk tiap jenis gambar, pilih file terkecil yang tidak dapat Anda bedakan dari gambar asli.

Menentukan ukuran dari file yang tersedia, bukan dari kontainer

• Salah: menyajikan resolusi apa pun yang kebetulan dimiliki file asli (atau satu ukuran tetap untuk setiap tata letak), alih-alih menyesuaikannya dengan tempat gambar dirender. Mengapa salah: menurut perhitungan web.dev, ukuran yang benar adalah ukuran kontainer hasil render × rasio piksel perangkat—kontainer 500×500 pada DPR 2× membutuhkan sumber 1 000×1 000, bukan 500×500 dan bukan 3 000×3 000. Ukuran yang lebih besar membuang byte tanpa peningkatan visual; ukuran yang lebih kecil tampak kurang tajam pada layar ber-DPR tinggi. Lakukan ini: kirim rentang srcset beserta sizes agar browser dapat memilih kandidat yang tepat untuk kontainer dan perangkat.

Menyembunyikan gambar konten sebenarnya di balik CSS

• Salah: mengganti <img> dengan background-image demi kemudahan tata letak. Mengapa salah: Google “doesn’t index CSS images” (terjemahan) “tidak mengindeks gambar CSS”—gambar konten yang hanya ada sebagai background-image tidak terlihat oleh penelusuran gambar meskipun aspek lain sudah dioptimalkan. Lakukan ini: pertahankan gambar konten dalam <img> (atau sebagai fallback <img> di dalam <picture>), dan gunakan latar CSS hanya untuk elemen yang murni dekoratif.

Menghilangkan width/height untuk “menghemat markup”

• Salah: tidak mencantumkan width dan height intrinsik (atau aspect-ratio CSS) pada tag <img>. Mengapa salah: browser tidak dapat memesan ruang tata letak sebelum gambar dimuat, sehingga halaman bergeser ketika setiap gambar tiba—dan memperburuk CLS, Core Web Vital yang berdampingan dengan LCP. Lakukan ini: selalu tetapkan width/height (atau aspect-ratio) pada setiap gambar, termasuk gambar yang juga Anda optimalkan format dan ukurannya.

Model mental

1. Jangan pernah lazy-load gambar LCP. Inilah aturan paling bernilai dalam seluruh topik. Elemen terbesar di atas fold—biasanya gambar—menjadi acuan waktu LCP. Lazy loading tidak menghemat apa pun; tindakan itu hanya menunda metrik yang sedang Anda optimalkan. Semua elemen lain di halaman dapat menjadi kandidat loading="lazy"; gambar LCP tidak pernah.

2. Tidak ada pengaturan kompresi universal. Perlakukan “pada kualitas berapa gambar harus dikompresi?” sebagai pertanyaan per gambar, bukan kebijakan seluruh situs. Foto dapat menerima kompresi lossy agresif; grafis berisi banyak teks dan tangkapan layar tidak. Alur kerjanya bersifat komparatif—ekspor pada dua atau tiga tingkat kualitas dan bandingkan pada ukuran tampilan—bukan menetapkan satu slider lalu melupakannya.

3. Ukuran yang benar = ukuran kontainer × device pixel ratio. “Lebih kecil lebih baik” bukan aturannya; yang penting adalah kecocokan. Dimensi sumber optimal adalah ukuran hasil render gambar dikalikan rasio piksel perangkat—kontainer 500×500 pada DPR 2× membutuhkan sumber 1 000×1 000. Rumus inilah yang seharusnya menentukan ukuran ekspor setiap gambar, sekaligus menjelaskan mengapa Anda menyediakan rentang melalui srcset, bukan satu file tetap.

4. Format adalah pengungkit kecepatan, bukan pengungkit peringkat. Susun rantai ini dengan benar: pilihan format → file lebih kecil → halaman lebih cepat → Core Web Vitals lebih baik → sinyal yang memang digunakan sistem peringkat. Langsung menyimpulkannya sebagai “format generasi baru mendapat peringkat lebih baik” adalah kekeliruan paling umum dalam panduan pesaing—Mueller telah menyatakan tiga kali bahwa format itu sendiri tidak memberi dorongan SEO langsung.

KPI tetap untuk kecepatan halaman yang dipengaruhi gambar

Angka-angka berkelanjutan berikut menunjukkan apakah pekerjaan optimasi gambar Anda benar-benar berdampak—terpisah dari satu gambar yang Anda ubah ukurannya atau konversi minggu ini.

Uji pemahaman Anda: Optimasi Gambar

Lima pertanyaan singkat tentang format, kompresi, ukuran, dan strategi pemuatan. Pilih jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan