AVIF vs WebP vs JPEG: Mampatan Terukur dan Bila Pilih Setiap Satu

Dikemas kini terakhir: July 25, 2026

WebP ialah piawai untuk kebanyakan imej web: 56–64% lebih kecil daripada JPEG dalam ujian saya dan dipaparkan dalam setiap pelayar semasa. AVIF memampatkan lebih kuat lagi — 81–89% lebih kecil daripada JPEG — tetapi mengekod kira-kira 2–3× lebih perlahan. Simpan JPEG untuk e-mel dan sistem lama sahaja. Angka di bawah datang daripada penanda aras empat imej sebenar yang saya jalankan, bukan dakwaan kitar semula "AVIF 50% lebih kecil" yang disalin antara satu sama lain oleh setiap panduan format.

Jawapan pantas: AVIF, WebP, atau JPEG?

Pilih format terkecil yang audiens anda boleh paparkan. Untuk kebanyakan laman web itu bermakna AVIF dahulu, WebP sebagai sandaran, JPEG terakhir. Saya mengukur ketiga-tiganya pada empat jenis imej dengan kualiti sepadan, dan AVIF memenangi setiap kategori pada saiz fail — tetapi WebP mengekod dalam sepertiga masa.

Jika anda berkhidmat satu format sahaja, pilih WebP — ia berjalan dalam setiap pelayar semasa dan menjimatkan lebih separuh bait. Jika anda boleh berkhidmat berbilang format melalui <picture>, mulakan dengan AVIF untuk foto. Image Converter dan Image Compressor mengeksport ketiga-tiganya daripada satu imej sumber.

Mengapa dakwaan biasa "AVIF 50% lebih kecil" menundanya

Kebanyakan panduan format mengulangi tiga angka yang sama — "AVIF ~50% lebih kecil daripada JPEG," "AVIF ~20% lebih kecil daripada WebP," "WebP 25–34% lebih kecil daripada JPEG" — dan kesemuanya boleh dijejak kembali kepada satu atau dua kajian vendor yang dikutip secara membulat oleh semua orang. Penanda aras saya menceritakan kisah berbeza: berbanding JPEG q80 pada kualiti sepadan, AVIF menghasilkan 81–89% lebih kecil, bukan 50%. WebP menghasilkan 56–64% lebih kecil, bukan 25–34%.

Jurang ini penting kerana penjimatan sebenar memacu peningkatan Core Web Vitals sebenar. Jika panduan memberitahu anda WebP menjimatkan "25–34%" dan anda merancang lebar jalur berdasarkan itu, anda kurang kira separuh. Saya menjalankan penanda aras empat imej dengan pengekod libaom (AVIF), libwebp, dan mozjpeg daripada sharp pada effort 4, dan jadual di atas ialah output mentahnya — reprodukkan pada imej anda sendiri sebelum mempercayai sebarang peratus, termasuk milik saya.

Adakah fail AVIF yang lebih kecil benar-benar kelihatan sama baik?

Ya, untuk foto, dalam julat kualiti yang betul. Sebab "AVIF lebih kecil" bukan keseluruhan cerita ialah setiap format rosak secara berbeza apabila anda menolak kualiti terlalu rendah. Pada tetapan yang wajar, perbezaannya hilang pada jarak tontonan biasa.

Mod kegagalan adalah khusus format, dan ia memberitahu anda di mana setiap format runtuh:

Pelajaran praktikal: kekalkan AVIF dalam julat kualiti 60–70 untuk foto. Di bawah kira-kira 30, AVIF melincirkan detail dengan cara yang dibaca sebagai "salah" lebih cepat daripada ringing JPEG yang lebih besar — mata bertolak ansur dengan artifak JPEG lebih baik daripada bertolak ansur dengan tekstur yang hilang.

Pertukaran masa pengekodan yang tidak pernah ditanda aras

Setiap panduan format menegaskan "AVIF lebih perlahan untuk diekod" dan teruskan. Tiada satu pun yang saya temui memetakan pertukaran sebenar. Saya mengukur masa pengekodan AVIF merentas slider effort pada foto potret yang sama pada kualiti 65, dan lengkungnya bukan yang anda anggap:

Effort 4 ialah titik manis — fail terkecil (9.8 KB) pada 209 ms yang boleh ditoleransi. Menolak ke effort 6 menjadikan fail lebih besar (11.7 KB) sambil melipatgandakan masa pengekodan kepada 536 ms. Pengekod menghabiskan 2.5× lebih lama mencari dan mendarat pada hasil yang lebih buruk. Sebagai perbandingan, WebP pada kualiti yang sama diekod dalam kira-kira 70 ms tanpa mengira effort, dan JPEG dalam kira-kira 45 ms.

Kesimpulannya: jika anda mengekod sekali semasa muat naik, 200 ms AVIF tidak relevan. Jika anda mengekod pada setiap permintaan, jurang 3× berbanding WebP bertambah, dan effort 4 (bukan maksimum) ialah tetapan untuk dilancarkan.

Format mana untuk jenis imej mana?

Ini soalan yang paling kerap ditanya kepada enjin jawapan AI, dan jawapannya bergantung pada kandungan imej. Berdasarkan penanda aras empat jenis saya:

Jika saluran binaan anda belum boleh mengeluarkan AVIF, tukar ke WebP dahulu. Ia kemenangan tunggal terpantas — lebih separuh bait dijimatkan, sokongan sejagat — dan anda boleh menimbus AVIF di atasnya kemudian tanpa mengubah markup <img>.

Bagaimana anda berkhidmat ketiga-tiga tanpa merosakkan pelayar lama?

Gunakan elemen <picture> dengan sumber berjenis. Pelayar memilih jenis pertama yang disokongnya dan mengabaikan yang selebihnya:

<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>

• Sentiasa kekalkan <img> sebenar dengan src JPEG sebagai sandaran akhir.
• Tetapkan width dan height pada <img> untuk menghalang anjakan susun atur.
• Muat malas imej di bawah lipatan; jangan tidak muat malas hero LCP.

Bagaimana pilihan format menjejaskan Core Web Vitals?

Imej paling kerap mengawal Largest Contentful Paint (LCP) pada halaman padat imej. Bait lebih kecil bermakna hero tiba dan dicat lebih awal. Nisbah saiz fail saya diterjemahkan kasarnya kepada nisbah LCP:

Cumulative Layout Shift (CLS) tidak bersandar format — ia bergantung pada sama ada anda menempah ruang dengan width/height, bukan pada format bait. Baca panduan Google tentang imej dan Core Web Vitals serta rujukan format imej untuk sokongan penyahkod semasa.

Bila anda masih perlu pilih JPEG?

JPEG tidak usang — ia sandaran sejagat. Simpan untuk e-mel HTML (kebanyakan klien menanggalkan WebP dan AVIF), suapan rakan kongsi dan pasaraya yang hanya menerima JPEG, pelayar terbenam lama yang mendahului WebP, dan lakaran kecil di mana pengekodan semula menjimatkan bait kilobait satu digit.

Panduan berkaitan

• Mampatkan Imej Tanpa Hilang Kualiti
• Cara Mampatkan Imej di Bawah 100KB
• Cara Mampatan Imej Berfungsi
• Senarai Semak Pengoptimuman Imej Lengkap

Kesilapan biasa

• Berkhidmat satu AVIF gergasi dan melangkau saiz semula. Format tidak menyelamatkan anda daripada imej 4000px yang ditunjukkan pada 400px. Saiz semula dahulu, kemudian enkod.
• Membandingkan format pada nombor kualiti yang sama. AVIF q70, WebP q85, dan JPEG q90 kelihatan kasarnya serupa. Bandingkan pada kualiti visual sepadan.
• Menolak kualiti AVIF di bawah 30. Pelinciran kelihatan lebih teruk daripada JPEG yang lebih besar.
• Terlupa sandaran <img>. <picture> dengan hanya teg <source> memapar tiada apa pada klien tidak disokong.
• Muat malas hero. Imej LCP perlu dimuatkan dengan gelojoh dengan fetchpriority="high".

Urutan pelancaran mudah

1. Ukur bait imej dan LCP dengan PageSpeed Insights.
2. Tambah WebP sebagai sandaran di belakang JPEG — kemenangan pantas, tiada risiko keserasian.
3. Tambah sumber AVIF di atas WebP dalam <picture> untuk foto.
4. Mampatkan dan saiz semula setiap imej ke saiz paparannya sebelum mengekod.
5. Tempah dimensi (width/height) pada setiap imej untuk mengunci CLS.
6. Ukur semula untuk mengesahkan LCP turun dan tiada permintaan 404.

Soalan kerap ditanya

Adakah AVIF sentiasa lebih kecil daripada WebP?

Dalam penanda aras empat imej saya, ya — AVIF 60–73% lebih kecil daripada WebP pada kualiti sepadan merentas keempat-empat jenis. Grafik rata dan tangkap layar boleh menyempitkan jurang, tetapi AVIF memenangi setiap kategori yang saya uji.

Berapa lebih kecil AVIF berbanding JPEG dalam ujian anda?

Merentas empat jenis imej pada kualiti sepadan, AVIF 81–89% lebih kecil daripada JPEG q80. Foto potret turun daripada 90 KB (JPEG) kepada 9.8 KB (AVIF).

Adakah semua pelayar menyokong AVIF?

Pelayar utama semasa menyahkod AVIF, tetapi Safari lama di bawah versi 16 dan sesetengah WebView terbenam tidak, jadi sandaran <picture> ke WebP atau JPEG diperlukan.

Adakah WebP selamat digunakan sebagai satu-satunya format?

Ya; WebP mempunyai sokongan asli dalam pelayar utama semasa dan mengalahkan JPEG sebanyak 56–64% dalam penanda aras saya, menjadikannya pilihan format tunggal yang kukuh jika anda belum boleh menambah AVIF.

Berapa lebih perlahan AVIF diekod berbanding WebP?

Pada effort 4, AVIF mengambil kira-kira 210 ms vs 70 ms WebP pada potret — kasarnya 3× lebih perlahan. Ekod sekali semasa muat naik dan jurang tidak relevan; ekod pada setiap permintaan dan kelajuan WebP penting.

Tetapan effort AVIF apa yang perlu saya guna?

Effort 4 ialah titik manis dalam ujian saya — fail terkecil pada masa pengekodan yang boleh ditoleransi. Effort 6 menjadikan fail lebih besar dan mengambil 2.5× lebih lama, jadi jangan anggap effort maksimum adalah yang terbaik.

Format mana yang perlu saya pilih untuk imej hero?

Pilih AVIF dengan sandaran WebP dan asas <img> JPEG. Bait hero terus mengawal LCP, dan penjimatan AVIF 80%+ berbanding JPEG paling pantas muncul di sana.

Bila saya masih perlu guna JPEG dan bukannya AVIF atau WebP?

Simpan JPEG untuk e-mel HTML, suapan rakan kongsi dan pasaraya, saluran cetak, serta pelayar terbenam lama yang mendahului sokongan WebP dan AVIF.

Kredit imej

• Kulit — Photographer editing photos on a laptop with a DSLR and tablet, foto oleh cottonbro studio di Pexels (ditukar ke WebP).
• Perbandingan format, carta saiz fail, dan zum artifak — dijana oleh penulis daripada foto bulu macaw (Pexels #36720663, foto oleh Kaca Skok). Penanda aras mampatan empat jenis dan sapuan effort AVIF dijana dengan pengekod libaom, libwebp, dan mozjpeg daripada sharp pada imej ujian sintetik yang dikalibrasi kepada kemampatan foto sebenar.