Mobile Image Optimization Guide for Faster Pages

Terakhir diperbarui: June 28, 2026

Optimasi gambar mobile dimulai dengan satu batasan: ponsel tidak boleh mengunduh piksel yang tidak dapat ditampilkan. Ubah ukuran sumbernya, sajikan varian responsif, jaga agar gambar terbesar di atas lipatan (above-the-fold) dikeluarkan dari lazy loading, dan publikasikan file WebP atau AVIF yang dapat dirayapi melalui CDN.

Jawaban cepat: bagaimana cara mengoptimalkan gambar untuk mobile?

Gunakan urutan ini: ubah ukuran terlebih dahulu, enkode kedua, kirimkan ketiga, ukur terakhir. Foto produk 4000 px yang ditampilkan pada lebar 390 px adalah pemborosan bahkan jika dikompresi. Browser masih harus mengambil, mendekode, dan menskalakannya sebelum halaman terasa siap.

Untuk sebagian besar halaman mobile, kirimkan set sumber WebP atau AVIF dengan lebar sekitar 400, 800, dan 1200 px. Pertahankan fallback JPEG jika audiens Anda mencakup browser lama, klien email, atau feed mitra. Untuk keputusan format yang lebih mendalam, gunakan perbandingan AVIF vs WebP.

Panduan LCP Google mengatakan bahwa halaman harus menargetkan Largest Contentful Paint pada 2,5 detik atau kurang pada persentil ke-75, dipisahkan berdasarkan mobile dan desktop. Gambar sering kali merupakan elemen LCP, jadi gambar hero layak mendapatkan penanganan khusus: preload atau prioritaskan, atur dimensi nyata, dan jangan lazy-load.

Apa yang sebenarnya berubah di ponsel?

Ponsel mengubah tiga hal sekaligus: lebar viewport, kualitas jaringan, dan kepadatan tata letak (layout density). Gambar desktop sering kali gagal di mobile karena halaman mempertahankan aset 1600 px yang sama, memotong subjek dengan buruk, atau menunda hero di belakang JavaScript.

Saya membuat satu grafik sumber 1600 x 1000 dan mengenkodenya sebagai WebP q82 pada tiga lebar. Hasilnya menunjukkan mengapa mengubah ukuran lebih unggul daripada menyempurnakan kualitas:

Angka-angka ini bersifat ilustratif, bukan universal. Foto detail akan lebih besar dari grafik bersih ini, dan logo datar akan lebih kecil. Aturan yang berguna adalah stabil: minta browser memilih dari kandidat lebar nyata alih-alih satu file berukuran terlalu besar.

Ukuran gambar mobile mana yang harus Anda buat?

Mulai dari slot render, bukan dari file kamera. Periksa template Anda pada breakpoint umum dan catat lebar CSS maksimum untuk setiap jenis gambar.

Gunakan deskriptor lebar ketika lebar tata letak berubah:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Botol air yang dapat digunakan kembali di meja dapur"
>

[Panduan gambar responsif] MDN menjelaskan model pemilihan srcset dan sizes. Versi singkatnya: srcset mencantumkan kandidat, dan sizes memberi tahu browser seberapa lebar slot render akan berada sebelum tata letak selesai.

Untuk alur kerja batch, buat lebar dari file master yang sama. [Panduan ubah ukuran batch] mencakup pola baris perintah, dan [pendalaman kompresi gambar] menjelaskan mengapa mengubah ukuran harus terjadi sebelum kompresi akhir.

Kapan Anda harus menggunakan picture untuk pemotongan mobile?

Gunakan <picture> ketika gambar mobile memerlukan potongan (crop) yang berbeda, bukan hanya file yang lebih kecil. Hero desktop lebar bisa menjadi tidak berguna di ponsel jika subjek berada di sisi jauh atau area teks menutupi produk.

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Sepatu lari jalur dengan tapak sol yang terlihat"
  >
</picture>

Gunakan art direction untuk:

1. Gambar hero produk di mana produk menjadi sangat kecil di mobile.
2. Spanduk editorial di mana wajah atau objek harus tetap berada di tengah.
3. Daftar pasar (marketplace) yang membutuhkan thumbnail persegi dan gambar detail lebar.
4. Gambar sebelum/sesudah di mana kedua sisi harus tetap dapat dibaca.
5. Tangkapan layar dengan teks kecil yang memerlukan pemotongan lebih ketat.

Jangan menggunakan <picture> sebagai pengganti lebar responsif normal. Jika komposisinya sama, srcset ditambah sizes lebih sederhana.

Bagaimana WebP, AVIF, dan JPEG cocok dengan performa mobile?

Gunakan WebP sebagai format mobile dasar ketika Anda membutuhkan satu file modern yang berfungsi secara luas. Gunakan AVIF ketika pipeline Anda dapat membuatnya dan Anda dapat mempertahankan fallback WebP atau JPEG. Simpan JPEG untuk email, sistem mitra lama, dan arsip sumber yang perlu dibuka oleh alat lain.

[Daftar periksa optimasi gambar lengkap] mencakup urutan publikasi yang lebih luas. Jika Anda perlu membandingkan alat yang menghasilkan WebP dan AVIF, lihat alternatif TinyPNG.

Gunakan tumpukan <picture> ketika Anda dapat:

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Mug keramik biru di samping buku catatan">
</picture>

Bagaimana lazy loading harus bekerja di mobile?

Lazy-load gambar yang dimulai di bawah viewport pertama. Jangan lakukan lazy-load pada gambar LCP. Lazy loading tingkat browser berguna, tetapi itu bukan rencana performa dengan sendirinya.

[Panduan lazy loading tingkat browser] Google merekomendasikan loading="lazy" asli untuk gambar di luar layar. Panduan yang sama memperingatkan terhadap lazy-loading gambar yang langsung terlihat karena dapat menunda konten yang ditunggu pengguna.

Gunakan daftar periksa ini:

1. Beri gambar hero loading="eager" atau hilangkan loading.
2. Tambahkan fetchpriority="high" ke gambar LCP yang paling mungkin.
3. Tambahkan loading="lazy" ke gambar setelah layar pertama.
4. Atur width dan height pada setiap gambar.
5. Gunakan CSS aspect-ratio ketika rasio render berubah berdasarkan breakpoint.
6. Hindari injeksi gambar hanya dengan JavaScript untuk hero.
7. Periksa bahwa URL gambar CDN menyertakan header cache yang panjang.
8. Uji pada profil mobile yang di-throttle, tidak hanya Wi-Fi desktop.
9. Amati elemen LCP di PageSpeed Insights.
10. Jalankan ulang setelah perubahan desain, karena elemen LCP dapat berubah.

[Dokumentasi LCP] Google mencantumkan elemen gambar, poster video, dan gambar latar belakang di antara kandidat LCP yang mungkin. Itulah mengapa hero latar belakang masih dapat merusak LCP bahkan jika itu bukan <img>.

Apa yang harus dilakukan CDN gambar untuk mobile?

CDN gambar harus menghilangkan pekerjaan manual berulang: ubah ukuran di edge, negosiasikan format, cache varian, dan menjaga URL publik tetap stabil. CDN tidak menggantikan kebersihan sumber (source hygiene). Mengunggah foto produk 900 px yang buram ke CDN gambar tidak akan menciptakan detail 1600 px yang nyata.

Cari kontrol ini:

• Transformasi lebar untuk slot mobile dan desktop umum.
• Output WebP dan AVIF dengan Content-Type yang benar.
• Kunci cache yang menyertakan lebar, kualitas, dan format.
• Cara untuk mempertahankan unggahan asli secara terpisah dari turunan publik.
• URL publik stabil yang dapat dirayapi oleh Google Images.
• Pemantauan 404 setelah deploy dan migrasi.

Untuk pencarian, [praktik terbaik SEO gambar] Google menekankan gambar yang berguna dan terlihat di dekat teks yang relevan, nama file dan alt text deskriptif, serta URL gambar yang dapat dirayapi. URL CDN baik ketika dapat diindeks, stabil, dan direferensikan dari halaman.

Apa yang harus Anda uji sebelum publikasi?

Uji halaman seperti cara pengunjung mobile menerimanya. Satu kali menjalankan Lighthouse bersih itu membantu, tetapi dapat menyembunyikan kehilangan CDN, kandidat responsif berukuran terlalu besar, dan pergeseran tata letak (layout shifts) yang hanya muncul di template nyata.

Satu perintah praktis untuk audit lokal:

curl -I https://cdn.example.com/images/product-card-480.webp

Kemudian periksa halaman yang dirender pada viewport sempit. Jika tabel atau gambar meluap dari layar, perbaiki tata letak sebelum merayakan penghematan byte.

Daftar periksa SEO dan GEO gambar mobile

Mesin pencari dan mesin jawaban membutuhkan hal yang sama dengan yang dibutuhkan seseorang: konteks langsung. Jangan mengubur gambar dalam carousel tanpa penjelasan terdekat dan mengharapkan aset tersebut membawa makna dengan sendirinya.

Sebelum publikasi, konfirmasi:

1. Halaman memiliki satu jawaban jelas di dekat bagian atas.
2. Setiap gambar penting memiliki alt text deskriptif.
3. Nama file menjelaskan subjek yang terlihat, bukan IMG_9021.
4. URL gambar dapat dirayapi tanpa cookie.
5. Paragraf di sekitarnya menjelaskan mengapa gambar itu ada.
6. Hero mobile tidak lebih besar dari slot render yang dibutuhkan.
7. Gambar badan menggunakan loading="lazy" hanya ketika di bawah viewport pertama.
8. Tabel merangkum keputusan yang dapat digunakan kembali oleh pembaca.
9. Klaim eksternal menautkan ke sumber otoritatif.
10. Tautan internal mengarah ke alur kerja nyata berikutnya, bukan halaman cluster acak.

Untuk lulus spesifik SEO setelah kompresi, gunakan daftar periksa optimasi SEO gambar. Untuk pekerjaan file satu kali, [Image Compressor] (/tools/image-compressor), [Image Converter] (/tools/image-converter), dan [Image Resizer] (/tools/image-resizer) mencakup langkah-langkah manual umum.

Kredit gambar

• Cover, bagan lebar responsif, potong art-direction, dan bagan prioritas pemuatan dibuat untuk artikel ini dengan ImageMagick dan diekspor sebagai WebP. Bagan lebar responsif menggunakan output WebP q82 terukur dari grafik sumber 1600 x 1000 yang sama.