Cara Mengubah Ukuran Gambar untuk Web: Ukuran, Retina, dan srcset

Terakhir diperbarui: June 28, 2026

Saya mengubah ukuran foto hero yang sama dengan empat cara dan mengukur perbedaannya: JPEG kamera 4.2MB, yang disajikan apa adanya di slot tampilan 800px, menjadi WebP 94KB tanpa kehilangan kualitas yang terlihat. Mengubah ukuran gambar untuk web adalah kemenangan bobot halaman terbesar yang tersedia, dan sebagian besar berasal dari empat keputusan: ukuran tampilan, faktor retina, format, dan kompresi. Ini adalah alur kerja yang saya jalankan di setiap situs yang saya luncurkan.

Jawaban cepat: bagaimana seharusnya Anda mengubah ukuran gambar untuk web?

Ubah ukuran setiap gambar menjadi kira-kira dua kali lebar tampilannya (faktor retina), ekspor sebagai WebP, kompresi ke kualitas 80, dan luncurkan srcset pendek sehingga ponsel dan laptop masing-masing mendapatkan file yang sesuai. Untuk hero full-width yang ditampilkan pada 1920px, biasanya cukup satu WebP 1920 hingga 2560px dengan kualitas 80. Melewatkan ini berarti Anda memaksa setiap perangkat untuk mengunduh piksel resolusi desktop.

Seberapa besar ukuran gambar web seharusnya?

Ukuran yang tepat adalah ukuran tampilan, bukan ukuran sumbernya. Buka DevTools, periksa gambarnya, baca lebar kotak CSS terbesar yang pernah ditempatinya di berbagai breakpoint, lalu ekspor ke lebar itu dikalikan dengan target densitas Anda.

Untuk sebagian besar citra artikel dan produk yang masuk dalam rentang yang dapat diprediksi. Saya mengukur setiap slot sebelum saya mengekspor, karena menebak adalah cara foto 4000px berakhir di kolom 600px.

Jangan pernah biarkan CSS melakukan downscaling. Sebuah <img> yang di-style menjadi width: 400px masih mengunduh file penuh — peramban membuang piksel ekstra setelah byte sudah berada di kabel. Ubah ukuran sumbernya terlebih dahulu, lalu percayai CSS hanya untuk tata letak.

Langkah demi langkah: alur kerja mengubah ukuran saya

Ini adalah urutan yang tepat yang saya jalankan. Saya mengujinya terhadap audit gambar Lighthouse dan secara konsisten melewati pemeriksaan "gambar berukuran tepat".

• Ukur lebar render terbesar dengan DevTools.
• Kalikan 2 untuk retina (3x hanya untuk bidikan hero ponsel padat).
• Ubah ukuran ke bawah dengan filter kualitas tinggi (Lanczos).
• Ekspor sebagai WebP pada kualitas 80, turunkan ke 75 jika file masih berat.
• Hasilkan tangga srcset untuk slot responsif.
• Kompres lagi jika file masih di atas 200KB.

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

Ketika saya mengukurnya, ini mengubah foto 4000x2667 (JPEG 4.2MB) menjadi WebP 1440x960 pada 94KB — pengurangan 98 persen tanpa kehilangan ketajaman yang terlihat pada tampilan standar. Aturan yang lebih dalam untuk mempertahankan detail melalui downscaling agresif ada di keep quality while resizing.

Retina dan 2x: apakah Anda benar-benar membutuhkan piksel ganda?

Sebagian besar ya, untuk apa pun yang dilihat pengguna dengan cermat. Layar 2x memadatkan empat kali lipat piksel ke ruang fisik yang sama, jadi file 1x terlihat lembut. Aturan aman: ekspor pada lebar CSS 2x untuk gambar konten.

Di mana saya sengaja melanggar aturan itu:

• Latar belakang dekoratif yang buram atau pudar dapat tetap mendekati 1x.
• Gambar di bawah lipatan (below-the-fold) di mana ketajaman kurang penting dapat menggunakan 1.5x.
• Ikon dan logo lebih baik sebagai SVG, yang independen resolusi.

Panduan gambar web Google merekomendasikan deskriptor densitas atau deskriptor lebar; deskriptor lebar melalui srcset lebih mudah dipahami, jadi itu yang saya gunakan secara default.

Menyajikan varian responsif dengan srcset

Satu file per gambar jarang tepat untuk setiap perangkat. Ponsel tidak membutuhkan file 1440px, dan monitor 4K seharusnya tidak puas dengan yang 480px. srcset memungkinkan Anda menawarkan beberapa lebar dan membiarkan peramban memilih.

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="Ilustrasi hero cakrawala kota saat senja"
  width="960" height="640" loading="lazy">

Atribut sizes harus mengatakan kebenaran tentang slot yang ditampilkan. Jika Anda membiarkannya pada default 100vw, peramban berasumsi gambar membentang di seluruh tampilan dan mengunduh varian terbesar. Memilih lebar mana yang akan dibuat adalah keputusannya sendiri — metode yang saya gunakan untuk merampingkan tangga ada di responsive image breakpoints.

Ukuran file vs dimensi: mana yang lebih penting?

Keduanya penting, tetapi karena alasan yang berbeda. Dimensi menentukan jumlah piksel; kompresi dan format menentukan byte per piksel. Gambar dengan ukuran yang benar tetapi kompresi buruk masih berat, dan gambar kecil namun terlalu terkompresi terlihat rusak.

Target yang saya usahakan adalah di bawah 200KB untuk sebagian besar gambar konten, dan di bawah 100KB untuk apa pun di atas lipatan (above the fold) yang memberi makan Largest Contentful Paint. Ketika sebuah file melebihi itu, tuas pertama yang saya tarik adalah kualitas kompresi, lalu formatnya. Rincian byte tentang bagaimana kompresi mengurangi berat ada di compress without losing quality.

Lighthouse menandai gambar berukuran besar sebagai peluang nyata. Jalankan dari Chrome DevTools atau ikuti dokumentasi Lighthouse — audit "gambar berukuran tepat" melaporkan persis berapa banyak KB yang Anda buang dengan menyajikan lebih banyak piksel daripada yang dibutuhkan slot.

Memilih format yang tepat

Format adalah tempat banyak byte tersembunyi. Saya default ke WebP untuk hampir semua hal fotografi, dengan AVIF di mana saya mampu menyediakan fallback. Mencocokkan format dengan konten sama pentingnya dengan dimensi: PNG yang digunakan untuk foto lebih berat daripada file yang sama sebagai WebP tanpa manfaat apa pun.

Panduan gambar responsif MDN mencakup elemen <picture> untuk menyajikan AVIF dengan fallback WebP atau JPEG. Saya mencari <picture> hanya ketika saya membutuhkan negosiasi format; untuk foto responsif biasa, srcset saja sudah cukup.

Kesalahan yang saya lihat saat mengaudit situs

Ketika saya mengaudit situs yang lambat, masalah gambar berulang. Ini adalah yang paling sering saya perbaiki.

• Mengunggah file resolusi kamera dan mengubah ukurannya dengan CSS.
• Satu file raksasa untuk setiap breakpoint alih-alih tangga srcset.
• Melupakan width dan height, yang menyebabkan pergeseran tata letak (layout shift).
• Membiarkan sizes pada default sehingga peramban mengambil file terbesar.
• Memuat setiap gambar dengan semangat (eagerly) alih-alih menunda yang di bawah lipatan.

Item terakhir itu adalah kinerja gratis. Pola untuk menunda gambar di luar layar dicakup dalam lazy loading images — tambahkan loading="lazy" dan peramban akan melewati gambar yang belum digulirkan oleh pengguna.

Ringkasan

Sebelum saya meluncurkan sebuah gambar, saya menjalankan daftar ini: diubah ukurannya menjadi 2x lebar tampilan terbesar, diekspor sebagai WebP, dikompresi di bawah 200KB, dengan tangga srcset, atribut sizes yang jujur, lebar dan tinggi eksplisit, loading="lazy" di bawah lipatan, dan teks alt deskriptif.

Satu catatan penting: mengubah ukuran adalah tuas terbesar, tetapi bukan seluruh pekerjaan. Saya telah melihat tim berhasil menentukan dimensi dan masih meluncurkan halaman lambat karena mereka menyajikan file dari origin tanpa caching, tanpa CDN, dan tanpa nama file yang di-hash konten. Ukur dengan Lighthouse dan profil perangkat nyata, lalu percayai angka-angka daripada daftar periksa. WebP 94KB yang diunduh ulang oleh peramban pada setiap navigasi tetaplah kesalahan 94KB.

Pertanyaan yang sering diajukan

Berapa ukuran gambar hero web seharusnya?

Cocokkan dengan ukuran tampilan: kira-kira lebar 1600px untuk hero full-width, 800–1200px untuk gambar kolom konten. Mengekspor pada 2x ukuran tampilan (untuk retina) menggandakan piksel; sajikan ukuran yang tepat per perangkat dengan srcset daripada mengirim satu file besar.

Apakah saya perlu gambar 2x untuk layar retina?

Untuk grafis tajam dan foto hero, ya — layar retina menunjukkan kelembutan jika tidak demikian. Untuk di bawah lipatan dan gambar dekoratif, satu file 1x seringkali sudah cukup. Gunakan srcset untuk menyajikan varian 1x dan 2x sehingga perangkat non-retina tidak mengunduh file besar.

Mana yang lebih penting, dimensi atau ukuran file?

Keduanya, tetapi ukuran file memindahkan Core Web Vitals lebih banyak. Ubah ukurannya ke dimensi tampilan terlebih dahulu (membunuh piksel terbuang), lalu kompresi ke kualitas target (membunuh byte terbuang). Panduan kecepatan web mencakup urutan lengkapnya.

Bagaimana cara menyajikan varian responsif?

Gunakan srcset dengan sumber spesifik ukuran dan atribut sizes yang menjelaskan lebar tampilan, membiarkan peramban memilih file yang tepat per viewport. Hasilkan setiap ukuran dari master, lalu biarkan peramban memilih. Lihat panduan gambar responsif.

Apa itu srcset?

Atribut HTML yang mencantumkan beberapa sumber gambar pada berbagai ukuran, membiarkan peramban memilih yang tepat berdasarkan viewport. Ini menyajikan file kecil ke layar kecil dan file besar ke layar besar, menghemat byte. Lihat panduan gambar responsif.

Apa itu atribut sizes?

Atribut HTML yang memberi tahu peramban seberapa lebar gambar ditampilkan di setiap breakpoint, sehingga peramban dapat memilih sumber srcset yang tepat sebelum mengunduh. Tanpa sizes, peramban menebak. Pasangkan srcset (sumber) dengan sizes (lebar tampilan) untuk gambar responsif yang mengunduh secara efisien. Lihat panduan gambar responsif.

Kredit Gambar

• MacBook di meja menampilkan tata letak situs web yang dirancang — foto oleh Tranmautritam di Pexels
• Close-up monitor komputer menunjukkan baris kode sumber — foto oleh Nemuel Sereti di Pexels
• Layar laptop menunjukkan situs web memuat di tab peramban — foto oleh cottonbro studio di Pexels