WebP: Format Gambar Default untuk Website Modern

Aku konversi semua gambar di hibranwar.com ke WebP. Semua. Hero image, thumbnail, foto venture, cover buku, bahkan favicon. Total sekitar 60+ file. Hasilnya? Rata-rata file size turun 35% dari JPEG original. Beberapa gambar turun sampai 50%.

Proses konversinya? Ga sampai 20 menit. Satu command line, satu quality setting: 82%. Selesai.

Ini bukan teknologi baru. Google merilis WebP tahun 2010. Tapi sampai sekarang, banyak website Indonesia yang masih serve JPEG dan PNG tanpa alasan yang jelas. Padahal ini literally improvement paling mudah yang bisa kamu lakukan untuk performa website.

Kenapa 82%?

Pertanyaan pertama yang biasanya muncul: kenapa 82% dan bukan 80% atau 85%?

Jawabannya pragmatis. Aku test di beberapa batch gambar. Foto produk, screenshot, hero banner. Di quality 80%, beberapa gambar mulai menunjukkan artifak di area gradasi warna. Di quality 85%, penghematan file size ga signifikan dibanding 82%. Sweet spot-nya ada di 82%. Cukup kecil untuk hemat bandwidth, cukup tinggi untuk ga ada degradasi visual yang noticeable.

Ini bukan angka ajaib. Ini hasil trial and error. Website kamu mungkin punya sweet spot yang beda tergantung tipe konten visual yang dominan. Tapi 82% adalah starting point yang solid.

Apa Itu WebP

WebP adalah format gambar yang dikembangkan Google, pertama kali dirilis tahun 2010. Format ini mendukung lossy compression (seperti JPEG), lossless compression (seperti PNG), dan transparency (alpha channel, seperti PNG). Satu format, tiga kemampuan.

Menurut data Google sendiri, WebP lossy rata-rata 25-34% lebih kecil dari JPEG di quality index yang setara (SSIM). WebP lossless rata-rata 26% lebih kecil dari PNG [1]. Angka ini konsisten dengan pengalaman aku sendiri di hibranwar.com.

Browser support? Per 2026, WebP didukung oleh 98%+ browser modern [2]. Chrome, Firefox, Safari, Edge, Opera. Semua mobile browser utama. Internet Explorer? Sudah mati sejak 2022. Kalau kamu masih khawatir soal IE compatibility, kamu punya masalah yang lebih besar dari format gambar.

Perbandingan Format: JPEG vs PNG vs WebP vs AVIF

Sebelum masuk ke data, ini tabel ringkasan fitur masing-masing format.

Dari tabel ini, dua hal yang jelas. Pertama, WebP menang di hampir semua kategori dibanding JPEG dan PNG. Kedua, AVIF secara teknis lebih superior dari WebP, tapi encoding speed-nya lambat dan browser support-nya masih 92%. Untuk 2026, WebP adalah pilihan paling pragmatis. AVIF adalah masa depan, tapi belum hari ini.

Data ukuran file: angka nyata

Ini perbandingan ukuran file dari berbagai tipe gambar yang umum di website. Angka berdasarkan konversi di hibranwar.com dan benchmark dari beberapa sumber [2] [3].

Beberapa highlight dari data ini:

• Foto produk 1200px: WebP 158 KB vs JPEG 245 KB. Hemat 35%.
• Hero banner 1920px: WebP 340 KB vs JPEG 520 KB. Hemat 34%.
• Logo dengan teks: WebP 42 KB vs PNG 95 KB. Hemat 56%.
• Screenshot UI: WebP 195 KB vs PNG 420 KB. Hemat 54%.

Untuk website dengan 20-30 gambar per halaman (common di e-commerce atau portfolio), penghematan total bisa mencapai 2-5 MB per page load. Itu bukan angka kecil, terutama untuk user di koneksi mobile Indonesia yang rata-rata masih 4G.

Hubungannya dengan Page Speed dan AI Crawlability

Ini yang sering dilupakan. Gambar yang lebih kecil bukan cuma soal bandwidth. Ini soal visibilitas.

Seperti yang aku bahas di Page Speed and AI Crawlability, AI crawler punya toleransi waktu yang lebih rendah dari Googlebot. GPTBot, ClaudeBot, PerplexityBot. Mereka ga sabar menunggu page load yang lambat. Kalau halaman kamu lambat karena gambar yang besar, AI crawler pergi. Konten kamu ga masuk index mereka. Kamu invisible.

Konversi ke WebP adalah salah satu cara paling cepat untuk memperbaiki ini. Tanpa ubah server, tanpa ubah hosting, tanpa refactor kode. Cukup konversi gambar.

Dan ini bukan cuma soal AI. Core Web Vitals juga terpengaruh langsung. Largest Contentful Paint (LCP) hampir selalu melibatkan gambar. Gambar yang lebih kecil = LCP yang lebih cepat = skor yang lebih baik = ranking yang lebih tinggi.

Cara Konversi ke WebP

Ada beberapa cara. Dari yang paling sederhana sampai yang paling automated.

1. Command line dengan cwebp (rekomendasi)

Google menyediakan tool resmi: cwebp. Ini yang aku pakai untuk hibranwar.com.

Install dulu:

# macOS
brew install webp

# Ubuntu/Debian
sudo apt install webp

# Windows (download dari Google)
# https://developers.google.com/speed/webp/download

Konversi satu file:

cwebp -q 82 input.jpg -o output.webp

Batch konversi semua JPEG di folder:

# Bash (macOS/Linux)
for f in *.jpg; do cwebp -q 82 "$f" -o "${f%.jpg}.webp"; done

# Atau pakai find untuk recursive
find . -name "*.jpg" -exec sh -c 'cwebp -q 82 "$1" -o "${1%.jpg}.webp"' _ {} \;

Untuk PNG (lossless ke lossy WebP):

for f in *.png; do cwebp -q 82 "$f" -o "${f%.png}.webp"; done

Itu yang aku jalankan di hibranwar.com. Satu command. 60+ file dikonversi dalam hitungan detik.

2. ImageMagick

Kalau kamu sudah pakai ImageMagick untuk hal lain:

magick input.jpg -quality 82 output.webp

# Batch
magick mogrify -format webp -quality 82 *.jpg

3. FFmpeg (untuk yang sudah install)

ffmpeg -i input.png -quality 82 output.webp

4. Online tools

Squoosh (squoosh.app) dari Google Chrome team. Drag and drop, adjust quality slider, download. Bagus untuk satu-dua file. Ga practical untuk batch.

Implementasi di HTML: Element <picture>

Setelah konversi, cara terbaik serve WebP adalah pakai elemen <picture> dengan fallback:

<picture>
  <source srcset="/images/hero-banner.webp" type="image/webp">
  <source srcset="/images/hero-banner.jpg" type="image/jpeg">
  <img src="/images/hero-banner.jpg"
       alt="Deskripsi gambar yang jelas dan kontekstual"
       width="1920" height="1080"
       loading="lazy">
</picture>

Browser yang support WebP akan load file .webp. Browser lama fallback ke JPEG. Semua orang senang.

Tapi jujur? Di 2026 aku ga repot-repot pakai fallback. Browser support WebP sudah 98%+. Di hibranwar.com, aku langsung serve WebP di tag <img>:

<img src="/images/hero-banner.webp"
     alt="Deskripsi gambar yang jelas dan kontekstual"
     width="1920" height="1080"
     loading="lazy">

Lebih simpel. Ga ada overhead dari <picture> element. Dan 2% user yang pakai browser ancient? Mereka punya masalah yang lebih besar dari gambar ga muncul di website aku.

Soal alt text, itu topik tersendiri. Aku sudah tulis panduan lengkap di Cara Menulis Alt Text yang Benar. Intinya: alt text bukan hiasan. Itu sinyal SEO dan kebutuhan aksesibilitas sekaligus.

Jangan lupa: width dan height

Selalu set width dan height di tag img. Ini mencegah Cumulative Layout Shift (CLS). Browser bisa reserve space sebelum gambar selesai load. Tanpa ini, halaman kamu "loncat-loncat" saat gambar muncul satu per satu.

Loading lazy

loading="lazy" menunda loading gambar yang belum visible di viewport. Untuk gambar di bawah fold, ini mengurangi initial page weight secara signifikan. Tapi jangan pakai lazy loading untuk hero image atau gambar pertama di halaman. Itu justru memperlambat LCP.

Konfigurasi Server

Kalau kamu pakai Apache atau LiteSpeed (seperti hibranwar.com di Rumahweb), pastikan MIME type WebP sudah dikonfigurasi. Tambahkan di .htaccess:

AddType image/webp .webp

Kebanyakan hosting modern sudah include ini by default. Tapi ga ada salahnya memastikan. Kalau MIME type ga benar, browser bisa menolak render gambar meskipun file-nya valid.

Untuk Nginx:

types {
    image/webp webp;
}

Kenapa Bukan AVIF?

Pertanyaan yang valid. AVIF secara teknis lebih unggul dari WebP. Kompresi lebih efisien, support HDR, file size bisa 20% lebih kecil lagi dari WebP.

Tapi ada tiga alasan aku belum pindah ke AVIF:

1. Browser support belum universal. 92% per 2026 [4]. Itu berarti 1 dari 12 visitor ga bisa lihat gambar kamu. Untuk website personal, mungkin ga masalah. Untuk website bisnis yang targetnya enterprise client, itu risiko yang ga perlu.
2. Encoding speed lambat. AVIF butuh waktu encode yang signifikan lebih lama dari WebP. Untuk batch 60+ file, perbedaannya terasa. Ini bikin iterasi lebih lambat.
3. Diminishing returns. WebP sudah hemat 35% dari JPEG. AVIF hemat 45-50%. Perbedaan 10-15% tambahan itu ga worth the tradeoff di browser support dan encoding time. Belum.

Strategi aku: WebP sekarang, AVIF nanti ketika browser support mencapai 97%+. Mungkin 2027 atau 2028. Dan ketika saatnya tiba, konversi dari WebP ke AVIF juga cuma satu command line.

Hubungannya dengan Website Statis

Satu hal yang perlu aku highlight. Konversi ke WebP paling efektif di website statis. Kenapa? Karena di website statis, kamu punya kontrol penuh atas setiap file yang di-serve. Ga ada plugin yang re-encode gambar. Ga ada CMS yang generate thumbnail di 5 ukuran berbeda dengan quality setting yang ga bisa kamu kontrol.

Di hibranwar.com, setiap gambar WebP di-generate satu kali dengan quality 82%, lalu di-serve langsung oleh LiteSpeed. Ga ada processing di server. Ga ada on-the-fly conversion. File statis, serve statis. Sesimpel itu.

WordPress user? Kamu bisa pakai plugin seperti ShortPixel atau Imagify yang auto-convert ke WebP. Tapi kamu kehilangan kontrol atas quality setting per gambar, dan kamu menambah satu layer processing yang ga perlu.

Checklist Konversi WebP

Untuk yang mau langsung action, ini checklist yang aku pakai:

1. Audit semua gambar di website. Identifikasi format dan ukuran saat ini.
2. Install cwebp di local machine.
3. Batch convert semua JPEG dan PNG ke WebP di quality 82%.
4. Bandingkan visual quality. Adjust quality kalau perlu untuk gambar tertentu.
5. Update semua referensi di HTML/CSS dari .jpg/.png ke .webp.
6. Pastikan MIME type image/webp dikonfigurasi di server.
7. Set width, height, dan loading="lazy" di setiap <img> tag.
8. Test di PageSpeed Insights. Confirm improvement di LCP.
9. Hapus file JPEG/PNG original dari server (keep backup di local).
10. Monitor Core Web Vitals selama 1-2 minggu setelah deploy.

Total effort? Setengah hari untuk website kecil-menengah. Satu hari untuk website besar. ROI-nya? Permanen. Setiap visitor setelah itu mendapat page load yang lebih cepat tanpa kamu harus melakukan apa-apa lagi.