AVIF vs WebP vs JPG: Adu Format Gambar Modern
Mengapa Perbandingan Ini Sebenarnya Penting
Jangan salah, format gambar itu bukan pilihan kosmetik. Sama sekali bukan. Satu format yang salah pilih di halaman produk dengan traffic tinggi bisa menambah 200–400 KB per gambar. Ini akan menumpuk menjadi detik-detik tambahan waktu muat dan penurunan konversi yang terukur. Core Web Vitals dari Google secara langsung menghukum skor Largest Contentful Paint yang lambat, dan gambar adalah biang keladinya. Memilih antara AVIF, WebP, dan JPG punya konsekuensi nyata bagi SEO, tagihan bandwidth, dan apakah pengguna akan tetap tinggal. JPG telah mendominasi fotografi sejak pertengahan 90-an. Format ini berfungsi di mana saja, proses encode-nya cepat, dan setiap developer tahu cara menanganinya. WebP dari Google hadir pada tahun 2010 sebagai penggantinya, menjanjikan kompresi yang lebih baik untuk kualitas yang sama. Pendatang barunya adalah AVIF, yang distandarisasi pada tahun 2019 oleh Alliance for Open Media. Format ini mendorong kompresi lebih jauh lagi dengan meminjam teknologi dari codec video AV1. Tujuan di sini bukan untuk menyatakan satu format sebagai pemenang. Itu sia-sia. Tujuannya adalah untuk memahami untung-rugi spesifiknya sehingga kamu bisa membuat keputusan yang tepat untuk proyek *kamu*, bukan hanya mengikuti saran usang dari tahun 2021. Kita akan mengupas tuntas kompresi di dunia nyata, dukungan browser, dan biaya tersembunyi seperti kecepatan encoding, memberimu konteks untuk menggunakan setiap format secara efektif—dan tahu kapan waktunya untuk melakukan convert.
Performa Kompresi: Angka di Balik Hype
Ya, format modern memang jauh lebih kecil dari JPG. Bagian hype yang itu benar. Tapi seberapa jauh lebih kecilnya tergantung pada gambar, encoder, dan kualitas yang kamu tuju. Untuk foto pada umumnya, WebP biasanya 25–35% lebih kecil dari JPG dengan kualitas visual yang setara. AVIF melangkah lebih jauh, sering kali mencapai 40–55% lebih kecil dari JPG, yang berarti sekitar 15–25% lebih kecil dari WebP. Artinya, foto produk 180 KB (JPG, kualitas 85) mungkin bisa menjadi 120 KB WebP atau 90 KB AVIF. Penghematannya nyata. Tapi kamu tidak bisa begitu saja membandingkan angka kualitas antar format. Angkanya tidak setara. JPG "kualitas 85" tidak sama dengan WebP "kualitas 85". Menurunkan JPG dari 85 ke 75 di ImageMagick mungkin akan memangkas ukuran file, tapi juga akan menimbulkan artefak kotak-kotak pada gradien dan langit. WebP menggunakan skala 0–100 di mana 80 adalah titik awal yang baik, kira-kira setara dengan JPG 85. AVIF menggunakan skala Constant Rate Factor (CRF), biasanya 0–63, di mana lebih rendah lebih baik. Untuk foto web, CRF 30–40 sering kali menjadi pilihan yang pas. Ceritanya berbeda untuk grafis seperti screenshot UI, logo, atau infografis. PNG telah menjadi andalan karena kualitasnya yang lossless, tetapi mode lossless WebP secara konsisten menghasilkan file 20–30% lebih kecil. Mode lossless AVIF kurang matang dan terkadang bisa menghasilkan file yang *lebih besar* dari WebP lossless untuk jenis konten ini. Jangan berasumsi AVIF menang di semua lini. Tim Squoosh di Google melakukan tes yang mengonfirmasi keunggulan umum AVIF dalam hal kompresi, tetapi mereka juga menemukan bahwa keunggulan itu menyusut saat kamu bekerja dengan gambar sumber yang sudah sangat terkompresi. Jika kamu mengonversi ulang tumpukan JPG lama alih-alih bekerja dari file asli berkualitas tinggi, kamu akan melihat hasil yang tidak maksimal. Inputnya sampah, outputnya ya sampah yang sedikit lebih kecil.
Dukungan Browser dan Platform: Di Sinilah Segalanya Jadi Rumit
Biar jelas: dukungan JPG itu universal. Setiap browser, OS, penampil gambar, CMS, CDN, dan klien email bisa menanganinya. Jangan remehkan keunggulan itu; ini adalah tingkat ubiquity yang belum bisa ditandingi oleh format-format baru. Untuk penggunaan web, dukungan WebP sekarang sudah sangat baik. Per tahun 2024, setiap browser utama—Chrome, Firefox, Safari (sejak versi 14), Edge, Opera—sudah mendukungnya. Dukungan globalnya lebih dari 97% di caniuse.com. Satu-satunya yang tertinggal adalah versi Safari kuno di iOS 13 ke bawah, yang mungkin bukan masalah bagi audiens kamu. Dukungan AVIF bagus, tapi kamu harus lebih hati-hati. Chrome sudah mendukungnya sejak versi 85 (2020), Firefox sejak 93 (2021), dan Safari akhirnya bergabung dengan versi 16 (2022). Ini sudah mencakup sebagian besar pengguna, tetapi kamu masih bisa menemukan kendala dengan Edge pada build Windows 10 yang lebih lama atau WebView Android tertentu. Dukungan globalnya berkisar 93-95%. Kedengarannya bagus, tetapi untuk situs dengan traffic tinggi, 5-7% pengguna yang mendapatkan gambar rusak adalah masalah yang sangat nyata. Di luar browser, situasinya jadi rumit. Untuk aplikasi desktop, aplikasi mobile, atau email, dukungannya tambal sulam. macOS telah mendukung AVIF sejak Ventura (13.0). Windows 11 mendukungnya, tetapi Windows 10 memerlukan codec dari Microsoft Store. Android memiliki dukungan sejak versi 12, dan iOS sejak 16. Semua ini tidak relevan jika kamu menggunakan elemen HTML `<picture>` dengan fallback yang tepat, tetapi ini menjadi masalah besar jika kamu berharap pengguna mengunduh dan membuka file-file ini sendiri. Satu-satunya strategi yang waras untuk situs web produksi adalah menyajikan gambar secara berjenjang: AVIF dulu, lalu WebP sebagai fallback, dan terakhir JPG untuk sisanya. Kamu bisa menerapkan ini menggunakan tag `source` dari elemen `<picture>` dengan atribut `type`, atau dengan memeriksa header `Accept` di server kamu. Jangan hanya menyajikan AVIF dan berharap yang terbaik.
Kecepatan Encoding dan Tooling: Biaya Tersembunyi
Ada biaya tersembunyi di balik kompresi AVIF yang luar biasa: waktu. Encoding AVIF itu lambatnya bukan main dibandingkan dengan JPG atau WebP, dan itu punya konsekuensi nyata bagi alur kerja kamu. Mari kita lihat angkanya. Melakukan encoding foto 2000×1500 ke JPG (kualitas 85, libjpeg-turbo) mungkin memakan waktu 50-80 milidetik di mesin modern. Gambar yang sama ke WebP (kualitas 80, libwebp) memakan waktu 200-400 milidetik. Tapi encoding ke AVIF (CRF 32, speed 6) bisa memakan waktu antara 2 hingga 8 *detik*. Dan jika kamu menyetel encoder ke pengaturan paling lambat dan berkualitas tertinggi, kamu bisa menunggu 30 detik atau lebih untuk satu gambar. Untuk satu batch berisi 500 gambar produk, itu adalah perbedaan antara rehat kopi 5 menit dan menunggu 4 jam. Jika kamu menghasilkan gambar secara on-the-fly, seperti yang dilakukan beberapa CDN, overhead encoding semacam itu dapat menambah latensi yang tidak dapat diterima kecuali sistem caching kamu sempurna. Encoder libavif memiliki pengaturan kecepatan dari 0 (paling lambat, kompresi terbaik) hingga 10 (paling cepat, terburuk). Kecepatan 6 adalah rekomendasi standar, kompromi yang baik antara ukuran file dan kewarasan kamu. Kecepatan 10 hampir secepat WebP, tetapi kamu mengorbankan banyak keunggulan kompresi AVIF. CocoConvert menangani kerumitan ini untukmu di server, tetapi hukum fisika tetap berlaku: batch konversi AVIF dalam jumlah besar akan memakan waktu jauh lebih lama daripada pekerjaan WebP atau JPG. Jika kamu terburu-buru, WebP sering kali menjadi pilihan yang lebih praktis, bahkan jika AVIF bisa memangkas beberapa kilobyte lagi. Tooling untuk WebP sudah matang dan stabil; cwebp, Squoosh, ImageMagick, dan library Sharp di Node.js semuanya memiliki dukungan yang kuat. Tooling AVIF sedang menuju ke sana—Sharp menambahkan dukungan di v0.27.0 dan ImageMagick menggunakan libheif—tetapi siapa pun yang pernah berurusan dengan masalah dependensi library tahu bahwa "mengejar ketertinggalan" bisa berarti menghadapi bug aneh dan konflik versi yang sama sekali tidak ada di dunia JPG dan WebP.
Kualitas Gambar pada Bitrate Rendah: Saat Perbedaan Format Paling Terlihat
Pada pengaturan kualitas tinggi, sebagian besar gambar terkompresi terlihat bagus. Ujian sesungguhnya datang pada bitrate rendah, saat kamu secara agresif memeras setiap byte terakhir dari sebuah file. Di sinilah format-format tersebut benar-benar menunjukkan warnanya, dan perbedaannya sangat jelas. Kompresi JPG yang berat terkenal dengan artefak kotak-kotaknya. Pada kualitas 40-50, gradien halus di langit biru pecah menjadi petak-petak persegi. Teks mendapatkan efek halo yang buram dan berdering. Kita semua pernah melihatnya, dan itu jelek. WebP, pada ukuran file rendah yang sama, cenderung menjadi buram daripada kotak-kotak. Format ini menghaluskan detail-detail kecil. Ini bisa menjadi artefak yang lebih enak dipandang untuk potret, di mana blur terlihat lebih alami daripada blok-blok kasar JPG. Namun, untuk gambar dengan garis tajam atau teks, blur yang sama bisa menjadi kelemahan besar. Di sinilah AVIF benar-benar bersinar. Pada bitrate rendah, ia mengalahkan dua format lainnya. Encoding berbasis AV1-nya просто lebih baik dalam mempertahankan detail dan menangani gradien dengan apik. Gambar AVIF berukuran 50 KB terlihat lebih bersih daripada WebP atau JPG dengan ukuran yang sama. Keunggulan sejati AVIF bukan pada kualitas 90, di mana semuanya baik-baik saja; melainkan pada kualitas 50-60, di mana kamu mendorong batas kemampuan. Metrik perseptual mendukung hal ini. Lanskap 1200×800 yang dikompres menjadi 50 KB mungkin mendapatkan skor DSSIM 0.008 untuk JPG, 0.005 untuk WebP, dan 0.003 untuk AVIF (lebih rendah lebih baik). Itu bukan sekadar angka; itu mewakili perbaikan yang terlihat. Jika kamu memiliki budget ukuran file yang ketat, AVIF akan secara konsisten memberimu gambar dengan tampilan terbaik. Ada satu pengecualian: grain film yang halus atau tekstur alami. Encoder AVIF bisa terlalu bersemangat dalam menghaluskan detail-detail ini, menghasilkan tampilan yang agak artifisial seperti plastik pada beberapa foto ISO tinggi. Selalu uji pada gambarmu sendiri; jangan anggap AVIF sebagai solusi ajaib untuk setiap jenis konten.
Kasus Penggunaan Praktis: Mencocokkan Format dengan Tujuan
Teori memang bagus, tapi di mana sebaiknya kamu benar-benar menggunakan setiap format? Berikut adalah panduan pragmatis untuk skenario umum. **Foto Hero & Produk Situs Web:** Gunakan AVIF, dengan fallback ke WebP, lalu JPG. Kamu mengontrol lingkungannya, jadi kamu bisa menggunakan elemen `<picture>` untuk menyajikan format terbaik. Penghematan bandwidth-nya sangat besar. Alat seperti CocoConvert dapat mengonversi file JPG asli kamu secara massal ke AVIF dan WebP untuk mempermudah ini. **Gambar Email:** JPG. Titik. Klien email adalah ladang ranjau rendering yang tidak konsisten. Baik AVIF maupun WebP tidak memiliki dukungan yang andal di Outlook, Apple Mail, atau Gmail. Mengirim WebP hanya akan menampilkan gambar rusak ke sebagian besar audiens kamu. **Unggahan Media Sosial:** Tetap gunakan JPG berkualitas tinggi. Setiap platform (Instagram, Twitter/X, Facebook) akan meng-encode ulang gambarmu tidak peduli apa yang kamu unggah. Beri encoder mereka materi sumber terbaik untuk diolah; mengunggah AVIF yang sudah terkompresi tidak memberimu keuntungan apa pun. **Cetak atau Arsip:** Bukan keduanya. Gunakan format lossless seperti TIFF atau PNG untuk file aslimu. Jika kamu harus mengirim pratinjau terkompresi, JPG berkualitas tinggi (90-95) adalah standar universal yang dapat dibuka oleh percetakan atau editor mana pun. **Aset Aplikasi Mobile:** Tergantung pada target OS minimum kamu. Jika kamu membangun untuk Android 12+ dan iOS 16+, AVIF adalah pilihan yang bagus. Untuk dukungan yang lebih luas, WebP adalah pilihan yang lebih aman, berfungsi hingga Android 4.0 dan iOS 14. **Konten CMS:** Hati-hati dengan AVIF. Ketika pengguna non-teknis mengunggah gambar, kamu menginginkan alur kerja yang paling andal. Banyak pustaka media dan generator thumbnail CMS masih belum menangani AVIF dengan benar. JPG dan WebP jauh lebih praktis dan lebih kecil kemungkinannya menyebabkan tiket dukungan tentang pratinjau gambar yang rusak.
Cara Mengonversi Antar Format Ini (dan Hal yang Perlu Diwaspadai)
Mengonversi antar format ini mudah dengan alat yang tepat, tetapi ada beberapa ranjau darat yang bisa merusak pekerjaan batch kamu jika tidak hati-hati. Aturan utama konversi: selalu mulai dari sumber berkualitas tertinggi. Mengonversi JPG ke AVIF tidak secara ajaib mengembalikan detail yang sudah dihancurkan oleh kompresi JPG. Itu hanya membungkus data yang sudah terdegradasi dalam format baru. Jika kamu punya file asli RAW atau TIFF, gunakan itu. Jika yang kamu punya hanya JPG, mengonversinya ke AVIF akan membuat file lebih kecil, tetapi tidak akan membuat gambar terlihat lebih baik. Menggunakan alat seperti CocoConvert menyederhanakan prosesnya: unggah, pilih format, dan unduh. Pengaturan kualitas default untuk JPG-ke-WebP disetel untuk mempertahankan kualitas visual. Untuk JPG-ke-AVIF, pengaturan defaultnya menyeimbangkan antara ukuran file dan kualitas, tetapi kamu harus mempertimbangkan untuk meminta kualitas yang lebih tinggi untuk gambar yang akan ditampilkan besar dan dicermati oleh pengguna. Biar kami terus terang soal keterbatasannya: CocoConvert tidak menangani format animasi. Mengonversi WebP animasi ke AVIF animasi adalah hal yang sama sekali berbeda, melibatkan pengaturan waktu frame dan palet warna. Untuk itu, kamu perlu menggunakan alat baris perintah seperti FFmpeg. Hati-hati dengan transparansi. JPG tidak mendukungnya, titik. Jika kamu mengonversi PNG atau WebP transparan ke JPG, latar belakangnya akan diisi dengan warna solid, biasanya putih atau hitam. Baik AVIF maupun WebP menangani transparansi (alpha channel) dengan baik, jadi mengonversi di antara keduanya akan mempertahankannya. Pastikan saja kamu tidak sengaja melewatkan gambar transparan melalui langkah konversi JPG di pipeline kamu. Terakhir, sedikit pragmatisme. Sebelum kamu membuat versi AVIF dan WebP untuk setiap gambar, tanyakan pada diri sendiri apakah kamu benar-benar membutuhkan keduanya. Menghasilkan dua format akan menggandakan waktu pemrosesan dan penyimpananmu. Untuk banyak situs, cukup melakukan standarisasi pada WebP sudah merupakan peningkatan besar dari JPG dan mencakup 97%+ pengguna dengan kompleksitas yang jauh lebih sedikit. AVIF memang kuat, tetapi tambahkan hanya jika tagihan bandwidth kamu benar-benar sepadan dengan kerja ekstra.