Gambar selebar 1920 piksel di halaman ikut diunduh penuh oleh pengguna ponsel, lalu diperkecil menjadi 390 piksel di layar — bandwidth lima kali lipat dan pemuatan lebih lambat tanpa guna. srcset memungkinkan browser memilih versi yang pas dengan layar, asalkan versi-versi itu sudah kamu buat.
Mengapa satu gambar tidak cukup
Angka LCP di Core Web Vitals biasanya berasal dari gambar besar di atas lipatan. Kirim file selebar 1920 dan 400KB ke ponsel, dan LCP jarang sampai 2,5 detik; versi selebar 480 dan 40KB pada koneksi yang sama lebih cepat satu orde besaran. Sinyal pengalaman halaman Google membaca angka itu secara langsung.
Sebaliknya, gambar selebar 768 di desktop besar tampak lembek. Karena itu perlu beberapa ukuran, dan browser yang memilihnya.
Tabel breakpoint yang praktis
Breakpoint mengikuti lebar gambar yang dirender di halaman, bukan viewport. Untuk dua kasus umum, gambar selebar penuh dan gambar dalam artikel:
- Gambar selebar penuh (hero, banner): 480, 768, 1200, 1920. Ponsel, tablet, laptop, layar besar.
- Gambar dalam artikel (kolom konten hingga sekitar 800): 400, 800, 1200; ukuran 1200 melayani layar 1,5x–2x.
- Thumbnail dan kartu (dirender sekitar 300): 300 dan 600.
Lebih banyak tingkat bukan berarti lebih baik. Setiap tingkat berarti satu ekspor lagi dan satu file lagi untuk disimpan, dan browser menoleransi ketidakcocokan, jadi jarak 1,5–2x antartingkat adalah titik terbaik. Empat tingkat mencakup lebih dari sembilan dari sepuluh kombinasi perangkat.
Perlukah versi 2x?
Layar Retina dan sebagian besar ponsel berkepadatan 2x–3x; gambar yang dirender selebar 400 butuh 800 piksel agar tampak tajam di sana. Tingkat yang lebih besar dalam tabel sudah berfungsi sebagai versi 2x untuk yang lebih kecil — 768 adalah 2x untuk ponsel selebar 390, 1200 adalah 2x untuk kolom selebar 600.
Jadi tidak perlu set “@2x” terpisah. Jaga jarak kira-kira 2x antartingkat dan browser akan memilih yang lebih tinggi berdasarkan kepadatan layar.
Format: WebP dulu, JPG sebagai cadangan
Pada kualitas setara, WebP 25–35 persen lebih kecil daripada JPG dan semua browser modern mendukungnya. Ekspor WebP di setiap ukuran dan simpan cadangan JPG lewat elemen picture untuk browser lama; kalau browser sebelum 2020 sudah tidak relevan bagi audiensmu, WebP saja sudah cukup.
AVIF masih lebih kecil, tetapi proses encode di browser jauh lebih lambat, yang merugikan pada batch besar. AVIF vs WebP vs JPEG membahas pertimbangannya secara rinci.
Ekspor massal seluruh set
Masukkan gambar sumber ke Pemrosesan Gambar Massal dan jalankan sekali per tingkat, mengganti lebar dan akhiran setiap kali:
- Ukuran: lebar 480, Izinkan pembesaran nonaktif, output WebP 80 persen, akhiran -480.
- Pengaturan sama pada 768 dengan akhiran -768; lalu 1200; lalu 1920.
- Untuk cadangan JPG, ubah output ke JPG, pertahankan akhiran, jalankan lagi.
Tiap proses memakan beberapa detik dan ZIP-nya sudah berisi hero-480.webp, hero-768.webp, dan seterusnya, siap masuk ke folder gambar. Biarkan Izinkan pembesaran nonaktif agar gambar asli 1000 piksel tidak pernah diregangkan ke 1920.
Untuk melihat selisih ukuran tiap tingkat pada satu gambar, coba Ubah Ukuran Gambar pada satu file.
Menulis HTML-nya
Untuk gambar selebar penuh:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Untuk gambar dalam artikel, setel sizes sesuai lebar sebenarnya, misalnya sizes="(max-width: 840px) 100vw, 800px". Selalu sertakan width dan height agar browser menyisihkan ruang dan halaman tidak melompat.
Setelah itu, tambahkan saran lazy-loading dan kompresi di cara membuat gambar dimuat lebih cepat, dan porsi gambar dalam skor performamu praktis sudah maksimal.