Responsive Image Breakpoints: Practical WebP Guide

Terakhir diperbarui: June 28, 2026

Breakpoint gambar responsif adalah lebar gambar yang Anda hasilkan sehingga ponsel, tablet, laptop, dan layar berdensitas tinggi dapat mengunduh file yang mendekati ukuran yang sebenarnya ditampilkan. Memilih terlalu sedikit akan membuat pengguna seluler menerima piksel desktop. Memilih terlalu banyak akan membuat build, cache, dan CDN Anda penuh dengan varian yang tidak ada yang membutuhkan.

Panduan ini membahas titik tengah praktis: ukur slot tata letak, hasilkan tangga WebP pendek, tulis srcset dan sizes, lalu verifikasi browser memilih file yang tepat dari CDN.

Jawaban cepat: breakpoint gambar responsif mana yang harus Anda gunakan?

Gunakan breakpoint yang sesuai dengan slot gambar yang benar-benar ditampilkan, kemudian tambahkan ruang kepala (headroom) densitas untuk layar retina. Untuk banyak gambar artikel, tangga WebP yang berguna adalah 480w, 720w, 960w, 1200w, dan 1440w. Untuk gambar hero lebar penuh, tambahkan 1920w jika desain benar-benar dapat menampilkan selebar itu.

Jangan menyalin breakpoint CSS secara membabi buta. Sebuah halaman mungkin memiliki breakpoint tata letak 1280px sementara gambarnya sendiri ditampilkan di dalam kolom artikel 720px. Dalam kasus itu, gambar 1440w mungkin sudah mencakup tampilan 2x, dan varian 1920w mungkin terbuang.

Metode yang andal sederhana: periksa lebar slot CSS terbesar, kalikan dengan densitas tertinggi yang ingin Anda dukung, bulatkan ke lebar yang masuk akal, dan hapus duplikat yang hampir sama. Kemudian pasangkan file-file tersebut dengan atribut sizes yang benar agar browser dapat memilih dengan tepat.

Apa itu breakpoint gambar responsif?

Breakpoint gambar responsif adalah lebar file yang dihasilkan, bukan harus breakpoint desain. Breakpoint CSS mengubah tata letak. Breakpoint gambar memberi tahu browser menu file, seperti 480w, 720w, 960w, dan 1440w.

[Panduan gambar responsif] MDN menjelaskan masalah inti: browser membutuhkan informasi yang cukup untuk memilih gambar dengan ukuran yang sesuai sebelum tata letak selesai. Atribut srcset mencantumkan kandidat, sementara sizes menjelaskan slot tempat gambar akan ditempati.

Pemisahan ini penting. Jika srcset benar tetapi sizes salah, browser mungkin masih mengunduh file yang lebih besar dari yang dibutuhkan. Jika sizes benar tetapi file yang dihasilkan melewatkan lebar yang berguna, browser tidak memiliki pilihan yang baik.

Untuk pilihan format, pasangkan breakpoint dengan format web modern. WebP adalah default aman untuk dukungan luas, dan AVIF dapat layak ditambahkan untuk perpustakaan fotografi besar. Pertukaran format dibahas di [Perbandingan AVIF vs WebP] (/blog/avif-vs-webp-comparison).

Bagaimana cara memilih lebar breakpoint?

Mulai dari slot yang ditampilkan, bukan dari file sumber. Foto produk 4000px tidak memerlukan varian web 4000px jika slot terbesar yang terlihat adalah 760px. Ia membutuhkan cukup piksel agar terlihat tajam di slot tersebut pada layar yang Anda pedulikan.

Gunakan urutan ini:

1. Buka halaman pada tata letak seluler paling sempit, lebar tablet umum, lebar laptop, dan lebar desktop lebar.
2. Ukur slot gambar yang ditampilkan dalam piksel CSS.
3. Kalikan setiap slot dengan 1x dan 2x jika Anda ingin dukungan densitas tinggi.
4. Bulatkan ke tangga kecil seperti 480, 720, 960, 1200, 1440, dan 1920.
5. Hapus lebar yang kurang dari sekitar 15 persen jaraknya.
6. Berhenti pada lebar terbesar yang dapat digunakan desain.

Saya mengkodekan keempat grafis dalam artikel ini secara lokal pada 1400 oleh 788 sebagai WebP. Setiap file yang diukur kurang dari 35 KB karena asetnya adalah grafis instruksional datar. Foto kamera dengan dimensi yang sama biasanya akan jauh lebih besar, jadi ukur output Anda sendiri sebelum menetapkan anggaran.

Jika seluruh folder membutuhkan lebar ini, gunakan langkah resize berulang. [Panduan Resize Batch] (/blog/batch-resize-guide) membahas pola baris perintah untuk menghasilkan gambar turunan tanpa menimpa file master.

Seperti apa tampilan srcset dan sizes?

Untuk sebagian besar gambar konten responsif, gunakan deskriptor lebar dengan sizes. Deskriptor lebar memberi tahu browser lebar piksel sebenarnya dari setiap kandidat. Nilai sizes memberi tahu browser seberapa lebar gambar akan ditampilkan dalam tata letak.

<img
  src="https://cdn.example.com/blog/photo-960.webp"
  srcset="
    https://cdn.example.com/blog/photo-480.webp 480w,
    https://cdn.example.com/blog/photo-720.webp 720w,
    https://cdn.example.com/blog/photo-960.webp 960w,
    https://cdn.example.com/blog/photo-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  width="1440"
  height="810"
  alt="Foto produk ditampilkan dalam tata letak artikel responsif">

Contoh sizes mengatakan: setelah viewport setidaknya selebar 900px, slot gambar adalah 720px; jika tidak, slotnya adalah 92 persen dari viewport. Ponsel yang lebarnya 390px dapat memilih file mendekati 720w untuk tampilan 2x alih-alih mengunduh file 1440w.

Panduan web.dev tentang [gambar responsif] (https://web.dev/learn/images/responsive-images) menunjukkan prinsip pemilihan browser yang sama: berikan kandidat dan informasi tata letak yang akurat sehingga ia dapat memilih sebelum permintaan gambar dibuat.

Gunakan elemen <picture> ketika pemotongan atau format berubah, bukan untuk setiap perubahan ukuran normal. Misalnya, gambar hero yang diarahkan secara artistik mungkin membutuhkan pemotongan seluler persegi dan pemotongan desktop lebar. Perubahan lebar polos biasanya lebih sederhana dengan satu img dan srcset yang bagus.

Berapa banyak breakpoint gambar yang terlalu banyak?

Lebih banyak varian tidak otomatis lebih baik. Setiap lebar tambahan menambah waktu build, penyimpanan, entri cache, permukaan invalidasi CDN, dan pekerjaan peninjauan. Jika dua kandidat sangat dekat, penghematan byte browser mungkin terlalu kecil untuk membenarkan file lain.

Gunakan set yang ringkas kecuali lalu lintas dan volume gambar Anda membenarkan penyetelan yang lebih halus. Lima lebar per gambar seringkali cukup untuk halaman artikel dan pemasaran. Situs produk dengan zoom, grid, dan banyak pemotongan mungkin membutuhkan lebih banyak, tetapi harus dihasilkan oleh pipeline daripada secara manual.

Perhatikan tanda-tanda ini bahwa tangga terlalu padat:

• 640w, 700w, dan 760w semuanya ada untuk gambar yang sama.
• Log CDN menunjukkan beberapa varian hampir tidak pernah diminta.
• Waktu build bertambah karena setiap unggahan menghasilkan sepuluh atau lebih turunan.
• Editor tidak dapat mengatakan file mana yang termasuk dalam frontmatter, Open Graph, dan konten badan.
• QA visual mulai memeriksa nama file alih-alih halaman yang ditampilkan.

Perhatikan tanda-tanda ini bahwa tangga terlalu jarang:

• Ponsel mengunduh file 1440w atau 1920w untuk gambar badan biasa.
• Layar retina desktop terlihat lembut karena kandidat terbesar terlalu kecil.
• Browser selalu memilih src fallback yang sama.
• PageSpeed atau Lighthouse menandai gambar berukuran besar di seluler.

[Praktik terbaik SEO gambar] Google merekomendasikan URL gambar yang dapat dirayapi, teks pendukung yang berguna, dan alt text deskriptif. Pengiriman responsif harus mempertahankan dasar-dasar tersebut. Jangan menyembunyikan gambar penting dalam latar belakang CSS jika mereka perlu diindeks atau dipahami sebagai konten halaman.

Bagaimana breakpoint memengaruhi Core Web Vitals?

Breakpoint responsif memengaruhi kinerja karena byte gambar sering mendominasi layar pertama. Jika gambar hero juga merupakan elemen Largest Contentful Paint, breakpoint yang salah dapat membuat paint terpenting menunggu pada file yang dua kali lebih besar dari yang dibutuhkan.

Panduan web.dev tentang [mengoptimalkan Largest Contentful Paint] merekomendasikan membuat gambar LCP yang mungkin ditemukan sejak awal dan memprioritaskannya jika sesuai. Breakpoint tidak menggantikan pekerjaan itu. Mereka memastikan file yang diprioritaskan berukuran tepat.

Untuk gambar di atas lipatan (above-the-fold):

1. Atur width dan height eksplisit untuk mencadangkan ruang.
2. Hindari lazy loading gambar LCP yang mungkin.
3. Gunakan fetchpriority="high" hanya untuk gambar yang benar-benar membutuhkannya.
4. Jaga sizes akurat untuk tata letak awal.
5. Verifikasi currentSrc yang dipilih di DevTools.

Untuk gambar di bawah lipatan (below-the-fold):

1. Lazy load gambar galeri dan artikel normal.
2. Gunakan tangga breakpoint yang sama kecuali pemotongan yang lebih kecil sudah cukup.
3. Kompres setelah resize, bukan sebelumnya.
4. Jaga alt text spesifik untuk gambar yang terlihat.
5. Periksa air terjun jaringan seluler, tidak hanya desktop.

Jika masalah Anda sebagian besar adalah penemuan aset hero yang tertunda, baca [Ekstraksi Gambar Kritis] (/blog/critical-image-extraction). Jika file-file tersebut terlalu berat, jalankan melalui [Panduan Rasio Kompresi Gambar] (/blog/image-compression-ratio) sebelum mengubah markup.

Pemeriksaan CDN apa yang harus Anda lakukan sebelum menerbitkan?

Breakpoint hanya selesai ketika URL akhir berfungsi. Draf Markdown bersih masih dapat gagal jika jalur CDN salah, objek memiliki tipe konten yang salah, atau halaman secara tidak sengaja mereferensikan file lokal /blog/....

Jalankan pemeriksaan pra-publikasi ini:

Di Chrome DevTools, periksa gambar yang ditampilkan dan periksa currentSrc. Kemudian ubah viewport dan rasio piksel perangkat. URL yang dipilih harus bergerak melalui tangga. Jika tidak pernah berubah, markup atau komponen gambar framework mungkin menimpa kandidat Anda.

Untuk pemeriksaan publikasi yang lebih luas, gunakan [Daftar Periksa Optimasi Gambar Lengkap] (/blog/complete-image-optimization-checklist). Untuk anggaran spesifik seluler, pasangkan ini dengan [Panduan Optimasi Gambar Seluler] (/blog/mobile-image-optimization-guide). Keputusan lazy loading dibahas secara terpisah di [Lazy Load Images] (/blog/lazy-load-images).

Daftar periksa breakpoint gambar responsif

Gunakan versi singkat ini saat meninjau permintaan tarik (pull request):

• Gambar master lebih besar dari varian yang dihasilkan terbesar.
• Lebar yang dihasilkan cocok dengan slot yang ditampilkan sebenarnya.
• Lebar tidak dikemas menjadi peningkatan nilai kecil.
• File WebP dikompres setelah resize.
• srcset menggunakan deskriptor lebar yang benar.
• sizes cocok dengan tata letak, bukan 100vw tebakan.
• Gambar LCP yang mungkin tidak di-lazy load.
• Gambar di bawah lipatan di-lazy load.
• Lebar dan tinggi ada untuk menghindari pergeseran tata letak.
• URL CDN mengembalikan HTTP 200 sebelum publikasi.
• Tautan internal mengarahkan pembaca ke langkah selanjutnya kompresi, seluler, dan lazy loading.

Set breakpoint yang berguna adalah set terkecil yang menjaga gambar tetap tajam tanpa membuat ponsel mengunduh file desktop. Ukur slotnya, hasilkan tangganya, publikasikan file WebP, dan konfirmasi browser memilih file yang Anda harapkan.