AVIF vs WebP vs JPEG: Kompresi Terukur dan Kapan Memilihnya

Terakhir diperbarui: July 25, 2026

WebP adalah pilihan default untuk sebagian besar gambar web: 56–64% lebih kecil dari JPEG dalam pengujian saya dan dirender di setiap browser saat ini. AVIF mengompres lebih keras lagi — 81–89% lebih kecil dari JPEG — tetapi mengodekan kira-kira 2–3× lebih lambat. Pertahankan JPEG hanya untuk email dan sistem lama. Angka di bawah berasal dari benchmark empat gambar nyata yang saya jalankan, bukan klaim daur ulang "AVIF 50% lebih kecil" yang disalin satu sama lain oleh setiap panduan format.

Jawaban cepat: AVIF, WebP, atau JPEG?

Pilih format terkecil yang bisa ditampilkan oleh audiens Anda. Untuk sebagian besar situs, itu berarti AVIF lebih dulu, WebP sebagai fallback, JPEG terakhir. Saya mengukur ketiganya pada empat jenis gambar dengan kualitas yang setara, dan AVIF menang di setiap kategori untuk ukuran file — tetapi WebP mengodekan hanya sepertiga waktunya.

Jika Anda hanya menyajikan satu format, pilih WebP — berjalan di setiap browser saat ini dan menghemat lebih dari setengah byte. Jika Anda bisa menyajikan beberapa format melalui <picture>, mulailah dengan AVIF untuk foto. Image Converter dan Image Compressor mengekspor ketiganya dari satu gambar sumber.

Mengapa klaim umum "AVIF 50% lebih kecil" justru meremehkannya

Sebagian besar panduan format mengulangi tiga angka yang sama — "AVIF ~50% lebih kecil dari JPEG," "AVIF ~20% lebih kecil dari WebP," "WebP 25–34% lebih kecil dari JPEG" — dan semuanya bisa dilacak kembali ke satu atau dua studi vendor yang dikutip secara melingkar oleh semua orang. Benchmark saya menceritakan kisah berbeda: terhadap JPEG q80 pada kualitas yang setara, AVIF ternyata 81–89% lebih kecil, bukan 50%. WebP ternyata 56–64% lebih kecil, bukan 25–34%.

Celah ini penting karena penghematan nyata mendorong peningkatan Core Web Vitals nyata. Jika panduan mengatakan WebP menghemat "25–34%" dan Anda merencanakan bandwidth berdasarkan itu, Anda kurang menghitung setengahnya. Saya menjalankan benchmark empat gambar dengan encoder libaom (AVIF), libwebp, dan mozjpeg dari sharp pada effort 4, dan tabel di atas adalah output mentahnya — reproduksi pada gambar Anda sendiri sebelum mempercayai persentase mana pun, termasuk milik saya.

Apakah file AVIF yang lebih kecil benar-benar terlihat sama baiknya?

Ya, untuk foto, dalam rentang kualitas yang tepat. Alasan "AVIF lebih kecil" bukanlah seluruh cerita adalah bahwa setiap format rusak secara berbeda saat Anda mendorong kualitas terlalu rendah. Pada pengaturan yang masuk akal, perbedaannya hilang pada jarak pandang normal.

Mode kegagalan bersifat spesifik per format, dan memberi tahu Anda di mana setiap format hancur:

Pelajaran praktis: pertahankan AVIF dalam rentang kualitas 60–70 untuk foto. Di bawah kira-kira 30, AVIF menghaluskan detail dengan cara yang terbaca "salah" lebih cepat daripada ringing JPEG yang lebih besar — mata lebih toleran terhadap artefak JPEG daripada terhadap tekstur yang hilang.

Trade-off waktu encoding yang tidak pernah di-benchmark

Setiap panduan format menegaskan "AVIF lebih lambat dienkode" lalu beralih. Tidak satu pun yang saya temukan memetakan trade-off yang sebenarnya. Saya mengukur waktu encoding AVIF melintasi slider effort pada foto potret yang sama pada kualitas 65, dan kurvanya bukan seperti yang Anda asumsikan:

Effort 4 adalah titik manis — file terkecil (9.8 KB) pada 209 ms yang dapat ditoleransi. Mendorong ke effort 6 membuat file lebih besar (11.7 KB) sementara melipatgandakan waktu encoding menjadi 536 ms. Encoder menghabiskan 2.5× lebih lama mencari dan mendarat pada hasil yang lebih buruk. Sebagai pembanding, WebP pada kualitas yang sama dienkode dalam sekitar 70 ms terlepas dari effort, dan JPEG dalam sekitar 45 ms.

Kesimpulannya: jika Anda mengodekan sekali saat unggah, 200 ms AVIF tidak relevan. Jika Anda mengodekan pada setiap permintaan, jarak 3× dari WebP bertambah, dan effort 4 (bukan maksimum) adalah pengaturan yang harus dikirim.

Format mana untuk jenis gambar mana?

Ini pertanyaan yang paling sering diajukan ke mesin jawaban AI, dan jawabannya bergantung pada konten gambar. Berdasarkan benchmark empat jenis saya:

Jika pipeline build Anda belum bisa menghasilkan AVIF, beralihlah ke WebP dulu. Itu adalah kemenangan tunggal tercepat — lebih dari setengah byte dihemat, dukungan universal — dan Anda bisa menambahkan AVIF di atasnya nanti tanpa mengubah markup <img>.

Bagaimana menyajikan ketiganya tanpa merusak browser lama?

Gunakan elemen <picture> dengan sumber bertipe. Browser memilih tipe pertama yang didukungnya dan mengabaikan sisanya:

<picture>
  <source srcset="/img/product.avif" type="image/avif">
  <source srcset="/img/product.webp" type="image/webp">
  <img src="/img/product.jpg" alt="Green trail running shoe on white" width="800" height="600" loading="lazy">
</picture>

• Selalu pertahankan <img> nyata dengan src JPEG sebagai fallback akhir.
• Set width dan height pada <img> untuk mencegah layout shift.
• Lazy-load gambar di bawah lipatan; jangan tidak lazy-load hero LCP.

Bagaimana pilihan format memengaruhi Core Web Vitals?

Gambar paling sering mengontrol Largest Contentful Paint (LCP) pada halaman padat gambar. Byte lebih kecil berarti hero tiba dan tergambar lebih cepat. Rasio ukuran file saya diterjemahkan kira-kira ke rasio LCP:

Cumulative Layout Shift (CLS) tidak bergantung pada format — bergantung pada apakah Anda mencadangkan ruang dengan width/height, bukan pada format byte. Baca panduan Google tentang gambar dan Core Web Vitals serta referensi format gambar untuk dukungan dekoder terkini.

Kapan Anda masih harus memilih JPEG?

JPEG tidak usang — itu adalah fallback universal. Pertahankan untuk email HTML (kebanyakan klien menghapus WebP dan AVIF), feed mitra dan marketplace yang hanya menerima JPEG, browser embedded lama yang mendahului WebP, dan thumbnail kecil di mana re-encoding menghemat hanya satu digit kilobyte.

Panduan terkait

• Mengompres Gambar Tanpa Kehilangan Kualitas
• Cara Mengompres Gambar di Bawah 100KB
• Cara Kerja Kompresi Gambar
• Daftar Periksa Optimasi Gambar Lengkap

Kesalahan umum

• Menyajikan satu AVIF raksasa dan melewati resize. Format tidak menyelamatkan Anda dari gambar 4000px yang ditampilkan pada 400px. Resize dulu, lalu encode.
• Membandingkan format pada nomor kualitas yang sama. AVIF q70, WebP q85, dan JPEG q90 terlihat kira-kira sama. Bandingkan pada kualitas visual yang setara.
• Mendorong kualitas AVIF di bawah 30. Penghalusan terlihat lebih buruk daripada JPEG yang lebih besar.
• Lupa fallback <img>. <picture> dengan hanya tag <source> tidak merender apa pun pada klien yang tidak didukung.
• Lazy-loading hero. Gambar LCP harus dimuat dengan eager dengan fetchpriority="high".

Urutan rollout sederhana

1. Ukur byte gambar dan LCP dengan PageSpeed Insights.
2. Tambahkan WebP sebagai fallback di belakang JPEG — kemenangan cepat, tanpa risiko kompatibilitas.
3. Tambahkan sumber AVIF di atas WebP dalam <picture> untuk foto.
4. Kompres dan resize setiap gambar ke ukuran tampilannya sebelum mengodekan.
5. Cadangkan dimensi (width/height) pada setiap gambar untuk mengunci CLS.
6. Ukur ulang untuk mengonfirmasi LCP turun dan tidak ada permintaan 404.

Pertanyaan yang sering diajukan

Apakah AVIF selalu lebih kecil dari WebP?

Dalam benchmark empat gambar saya, ya — AVIF 60–73% lebih kecil dari WebP pada kualitas yang setara di semua empat jenis. Grafik datar dan screenshot bisa mempersempit celah, tetapi AVIF menang di setiap kategori yang saya uji.

Berapa lebih kecil AVIF dari JPEG dalam pengujian Anda?

Melalui empat jenis gambar pada kualitas yang setara, AVIF 81–89% lebih kecil dari JPEG q80. Foto potret turun dari 90 KB (JPEG) ke 9.8 KB (AVIF).

Apakah semua browser mendukung AVIF?

Browser besar saat ini mendekode AVIF, tetapi Safari lama di bawah versi 16 dan beberapa WebView embedded tidak, sehingga fallback <picture> ke WebP atau JPEG diperlukan.

Apakah WebP aman digunakan sebagai satu-satunya format?

Ya; WebP memiliki dukungan native di browser besar saat ini dan mengalahkan JPEG sebesar 56–64% dalam benchmark saya, menjadikannya pilihan format tunggal yang solid jika Anda belum bisa menambahkan AVIF.

Berapa lebih lambat AVIF dienkode dibanding WebP?

Pada effort 4, AVIF butuh sekitar 210 ms vs 70 ms WebP pada potret — kira-kira 3× lebih lambat. Encode sekali saat unggah dan celah tidak relevan; encode pada setiap permintaan dan kecepatan WebP penting.

Pengaturan effort AVIF apa yang harus saya gunakan?

Effort 4 adalah titik manis dalam pengujian saya — file terkecil pada waktu encoding yang dapat ditoleransi. Effort 6 membuat file lebih besar dan butuh 2.5× lebih lama, jadi jangan asumsikan effort maksimum adalah yang terbaik.

Format mana yang harus saya pilih untuk hero image?

Pilih AVIF dengan fallback WebP dan basis <img> JPEG. Byte hero langsung mengontrol LCP, dan penghematan AVIF 80%+ dari JPEG paling cepat terlihat di sana.

Kapan saya masih harus menggunakan JPEG alih-alih AVIF atau WebP?

Pertahankan JPEG untuk email HTML, feed mitra dan marketplace, pipeline cetak, dan browser embedded lama yang mendahului dukungan WebP dan AVIF.

Kredit gambar

• Sampul — Photographer editing photos on a laptop with a DSLR and tablet, foto oleh cottonbro studio di Pexels (dikonversi ke WebP).
• Perbandingan format, grafik ukuran file, dan zoom artefak — dihasilkan oleh penulis dari foto bulu macaw (Pexels #36720663, foto oleh Kaca Skok). Benchmark kompresi empat jenis dan sapuan effort AVIF dihasilkan dengan encoder libaom, libwebp, dan mozjpeg dari sharp pada gambar uji sintetis yang dikalibrasi ke kompresibilitas foto nyata.