AVIF เทียบกับ WebP และ JPEG: บีบอัดที่วัดจริงและเลือกเมื่อไร

ปรับปรุงล่าสุด: July 25, 2026

WebP คือค่าเริ่มต้นสำหรับรูปภาพเว็บส่วนใหญ่: เล็กกว่า JPEG 56–64% ในการทดสอบของฉันและแสดงผลในทุกเบราว์เซอร์ปัจจุบัน AVIF บีบอัดแรงกว่านั้น — เล็กกว่า JPEG 81–89% — แต่เข้ารหัสช้ากว่าประมาณ 2–3× เก็บ JPEG ไว้สำหรับอีเมลและระบบเก่าเท่านั้น ตัวเลขด้านล่างมาจากเกณฑ์มาตรฐานภาพจริงสี่ภาพที่ฉันทำ ไม่ใช่คำกล่าวอ้าง "AVIF เล็กกว่า 50%" ที่ใช้ซ้ำกันซึ่งคู่มือรูปแบบทุกฉบับทำสำเนียงกัน

คำตอบโดยสรุป: AVIF, WebP หรือ JPEG?

เลือกรูปแบบที่เล็กที่สุดที่ผู้ชมของคุณสามารถแสดงผลได้ สำหรับเว็บไซต์ส่วนใหญ่นั่นหมายถึง AVIF ก่อน, WebP เป็นตัวสำรอง, JPEG สุดท้าย ฉันวัดรูปแบบทั้งสามบนภาพสี่ประเภทที่คุณภาพเท่ากัน และ AVIF ชนะทุกหมวดในด้านขนาดไฟล์ — แต่ WebP เข้ารหัสในเวลาเพียงหนึ่งในสาม

หากคุณให้บริการรูปแบบเดียวเท่านั้น ให้เลือก WebP — ทำงานในทุกเบราว์เซอร์ปัจจุบันและประหยัดไบต์ไปกว่าครึ่ง หากคุณให้บริการหลายรูปแบบผ่าน <picture> ได้ ให้เริ่มด้วย AVIF สำหรับภาพถ่าย Image Converter และ Image Compressor ส่งออกทั้งสามรูปแบบจากภาพต้นฉบับเดียว

ทำไมคำกล่าวอ้างทั่วไป "AVIF เล็กกว่า 50%" จึงด้อยความสำคัญไป

คู่มือรูปแบบส่วนใหญ่ทำซ้ำตัวเลขเดียวกันสามตัว — "AVIF เล็กกว่า JPEG ~50%", "AVIF เล็กกว่า WebP ~20%", "WebP เล็กกว่า JPEG 25–34%" — และทั้งหมดสืบย้อนได้ถึงหนึ่งหรือสองการศึกษาของผู้จำหน่ายที่ทุกคนอ้างถึงเป็นวงกลม เกณฑ์มาตรฐานของฉันเล่าเรื่องต่างออกไป: เทียบกับ JPEG q80 ที่คุณภาพเท่ากัน AVIF ออกมา เล็กกว่า 81–89% ไม่ใช่ 50% WebP ออกมา เล็กกว่า 56–64% ไม่ใช่ 25–34%

ช่องว่างนี้สำคัญเพราะการประหยัดจริงขับเคลื่อนการปรับปรุง Core Web Vitals จริง หากคู่มือบอกว่า WebP ประหยัด "25–34%" และคุณวางแผนแบนด์วิดท์ตามนั้น คุณจะนับต่ำไปครึ่งหนึ่ง ฉันรันเกณฑ์มาตรฐานสี่ภาพด้วยตัวเข้ารหัส libaom (AVIF), libwebp และ mozjpeg ของ sharp ที่ effort 4 และตารางด้านบนคือผลลัพธ์ดิบ — ทำซ้ำบนภาพของคุณเองก่อนเชื่อเปอร์เซ็นต์ใด ๆ รวมถึงของฉัน

ไฟล์ AVIF ที่เล็กลงดูดีเท่ากันจริงหรือ?

ใช่ สำหรับภาพถ่าย ในช่วงคุณภาพที่เหมาะสม เหตุผลที่ "AVIF เล็กกว่า" ไม่ใช่เรื่องทั้งหมด คือทุกรูปแบบพังต่างกันเมื่อคุณดันคุณภาพต่ำเกินไป ที่การตั้งค่าที่สมเหตุสมผล ความแตกต่างจะหายไปที่ระยะการมองปกติ

รูปแบบความล้มเหลวขึ้นกับรูปแบบไฟล์ และบอกคุณว่าแต่ละรูปแบบล้มเหลวที่ไหน:

บทเรียนเชิงปฏิบัติ: เก็บ AVIF ในช่วงคุณภาพ 60–70 สำหรับภาพถ่าย ต่ำกว่าประมาณ 30, AVIF เรียบรายละเอียดในทางที่อ่านได้ว่า "ผิด" เร็วกว่า ringing ของ JPEG ที่ใหญ่กว่า — ตาทน artifacts ของ JPEG ได้ดีกว่าทนพื้นผิวที่หายไป

การแลกเปลี่ยนเวลาเข้ารหัสที่ไม่มีใครทำเกณฑ์มาตรฐาน

คู่มือรูปแบบทุกฉบับยืนยันว่า "AVIF เข้ารหัสช้ากว่า" แล้วเลื่อนต่อ ไม่มีฉบับใดที่ฉันพบวางการแลกเปลี่ยนจริง ฉันวัดเวลาเข้ารหัส AVIF ตามตัวเลื่อน effort บนภาพถ่ายบุคคลเดียวกันที่คุณภาพ 65 และเส้นโค้งไม่ใช่สิ่งที่คุณคาด:

Effort 4 คือจุดที่ดีที่สุด — ไฟล์เล็กที่สุด (9.8 KB) ที่ 209 ms ที่ทนได้ การดันไป effort 6 ทำให้ไฟล์ ใหญ่ขึ้น (11.7 KB) ขณะที่เวลาเข้ารหัสเพิ่มสามเท่าเป็น 536 ms ตัวเข้ารหัสใช้เวลานาน 2.5× ในการค้นหาและลงเอยด้วยผลลัพธ์ที่แย่กว่า เปรียบเทียบแล้ว WebP ที่คุณภาพเดียวกันเข้ารหัสในประมาณ 70 ms โดยไม่ขึ้นกับ effort และ JPEG ประมาณ 45 ms

ข้อสรุป: หากคุณเข้ารหัสครั้งเดียวตอนอัปโหลด 200 ms ของ AVIF ไม่สำคัญ หากคุณเข้ารหัสทุกคำขอ ช่องว่าง 3× เหนือ WebP จะสะสมขึ้น และ effort 4 (ไม่ใช่ค่าสูงสุด) คือการตั้งค่าที่ควรจัดส่ง

รูปแบบใดสำหรับประเภทภาพใด?

นี่คือคำถามที่ถูกถามบ่อยที่สุดกับเครื่องมือตอบ AI และคำตอบขึ้นกับเนื้อหาของภาพ จากเกณฑ์มาตรฐานสี่ประเภทของฉัน:

หากไปป์ไลน์บิลด์ของคุณยังไม่สามารถสร้าง AVIF ให้สลับไป WebP ก่อน นั่นคือชัยชนะเดี่ยวที่เร็วที่สุด — ประหยัดไบต์ไปกว่าครึ่ง, รองรับเป็นสากล — และคุณสามารถวาง AVIF ทับด้านบนในภายหลังโดยไม่เปลี่ยนมาร์กอัป <img>

คุณให้บริการทั้งสามรูปแบบได้อย่างไรโดยไม่ทำลายเบราว์เซอร์เก่า?

ใช้องค์ประกอบ <picture> กับแหล่งที่มีประเภทกำกับ เบราว์เซอร์จะเลือกประเภทแรกที่รองรับและละเว้นส่วนที่เหลือ:

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

• ควรเก็บ <img> จริงที่มี src JPEG เป็นตัวสำรองสุดท้ายเสมอ
• ตั้ง width และ height บน <img> เพื่อป้องกันการเลื่อนเลย์เอาต์
• โหลดแบบ lazy สำหรับภาพที่อยู่ล่างกระดาษ; อย่า ไม่ โหลด lazy สำหรับ hero LCP

การเลือกรูปแบบส่งผลต่อ Core Web Vitals อย่างไร?

รูปภาพมักควบคุม Largest Contentful Paint (LCP) บนหน้าที่มีภาพเยอะ ไบต์ที่เล็กลงหมายถึง hero มาถึงและแสดงผลเร็วขึ้น อัตราส่วนขนาดไฟล์ของฉันแปลคร่าว ๆ เป็นอัตราส่วน LCP:

Cumulative Layout Shift (CLS) ไม่ขึ้นกับรูปแบบ — ขึ้นกับว่าคุณจองพื้นที่ด้วย width/height หรือไม่ ไม่ใช่รูปแบบไบต์ อ่านคำแนะนำของ Google เรื่อง รูปภาพและ Core Web Vitals และ อ้างอิงรูปแบบภาพ สำหรับการรองรับตัวถอดรหัสปัจจุบัน

เมื่อไรคุณควรยังเลือก JPEG?

JPEG ไม่ล้าสมัย — เป็นตัวสำรองสากล เก็บไว้สำหรับอีเมล HTML (ไคลเอนต์ส่วนใหญ่ถอด WebP และ AVIF ออก), ฟีดพันธมิตรและมาร์เก็ตเพลซที่รับ JPEG เท่านั้น, เบราว์เซอร์ฝังตัวเก่าที่เกิดก่อน WebP, และรูปย่อขนาดเล็กที่การเข้ารหัสใหม่ประหยัดเพียงหลักกิโลไบต์เดียว

คู่มือที่เกี่ยวข้อง

• บีบอัดรูปภาพโดยไม่สูญเสียคุณภาพ
• วิธีบีบอัดรูปภาพให้ต่ำกว่า 100KB
• การบีบอัดรูปภาพทำงานอย่างไร
• รายการตรวจสอบการเพิ่มประสิทธิภาพรูปภาพฉบับสมบูรณ์

ข้อผิดพลาดทั่วไป

• ให้บริการ AVIF ขนาดใหญ่ไฟล์เดียวและข้ามการปรับขนาด รูปแบบไม่ช่วยคุณจากภาพ 4000px ที่แสดงที่ 400px ปรับขนาดก่อน แล้วค่อยเข้ารหัส
• เปรียบเทียบรูปแบบที่ตัวเลขคุณภาพเดียวกัน AVIF q70, WebP q85 และ JPEG q90 ดูคร่าว ๆ เหมือนกัน เปรียบเทียบที่คุณภาพภาพเท่ากัน
• ดันคุณภาพ AVIF ต่ำกว่า 30 การเรียบเนียนดูแย่กว่า JPEG ที่ใหญ่กว่า
• ลืมตัวสำรอง <img> <picture> ที่มีแท็ก <source> อย่างเดียวจะไม่แสดงผลบนไคลเอนต์ที่ไม่รองรับ
• โหลด lazy สำหรับ hero ภาพ LCP ควรโหลดแบบ eager ด้วย fetchpriority="high"

ลำดับการเปิดตัวแบบง่าย

1. วัดไบต์ของรูปภาพและ LCP ด้วย PageSpeed Insights
2. เพิ่ม WebP เป็นตัวสำรองหลัง JPEG — ชัยชนะเร็ว, ไม่มีความเสี่ยงความเข้ากันได้
3. เพิ่มแหล่ง AVIF เหนือ WebP ใน <picture> สำหรับภาพถ่าย
4. บีบอัดและปรับขนาดทุกภาพให้เท่าขนาดที่แสดงก่อนเข้ารหัส
5. จองมิติ (width/height) บนทุกภาพเพื่อล็อก CLS
6. วัดซ้ำเพื่อยืนยันว่า LCP ลดลงและไม่มีคำขอ 404

คำถามที่ถามบ่อย

AVIF เล็กกว่า WebP เสมอหรือ?

ในเกณฑ์มาตรฐานสี่ภาพของฉัน ใช่ — AVIF เล็กกว่า WebP 60–73% ที่คุณภาพเท่ากันทุกสี่ประเภท กราฟิกเรียบและภาพหน้าจออาจทำให้ช่องว่างแคบลง แต่ AVIF ชนะทุกหมวดที่ฉันทดสอบ

AVIF เล็กกว่า JPEG มากแค่ไหนในการทดสอบของคุณ?

ทั้งสี่ประเภทภาพที่คุณภาพเท่ากัน AVIF เล็กกว่า JPEG q80 81–89% ภาพถ่ายบุคคลลดจาก 90 KB (JPEG) เป็น 9.8 KB (AVIF)

เบราว์เซอร์ทุกตัวรองรับ AVIF หรือ?

เบราว์เซอร์หลักปัจจุบันถอดรหัส AVIF ได้ แต่ Safari เก่าต่ำกว่าเวอร์ชัน 16 และ WebView ฝังตัวบางตัวไม่ได้ จึงต้องมีตัวสำรอง <picture> ไปยัง WebP หรือ JPEG

WebP ปลอดภัยที่จะใช้เป็นรูปแบบเดียวหรือ?

ใช่; WebP มีการรองรับแบบ native ในเบราว์เซอร์หลักปัจจุบันและชนะ JPEG 56–64% ในเกณฑ์มาตรฐานของฉัน ทำให้เป็นตัวเลือกรูปแบบเดี่ยวที่มั่นคงหากคุณยังเพิ่ม AVIF ไม่ได้

AVIF เข้ารหัสช้ากว่า WebP แค่ไหน?

ที่ effort 4, AVIF ใช้ประมาณ 210 ms เทียบกับ 70 ms ของ WebP บนภาพบุคคล — ช้ากว่าประมาณ 3× เข้ารหัสครั้งเดียวตอนอัปโหลดและช่องว่างก็ไม่สำคัญ; เข้ารหัสทุกคำขอแล้วความเร็วของ WebP สำคัญ

ควรใช้ค่า effort AVIF เท่าไร?

Effort 4 คือจุดที่ดีที่สุดในการทดสอบของฉัน — ไฟล์เล็กสุดที่เวลาเข้ารหัสทนได้ Effort 6 ทำให้ไฟล์ใหญ่ขึ้นและใช้เวลา 2.5× นานกว่า ดังนั้นอย่าสันนิษฐานว่า effort สูงสุดคือดีที่สุด

ควรเลือกรูปแบบใดสำหรับ hero image?

เลือก AVIF พร้อมสำรอง WebP และฐาน <img> JPEG ไบต์ของ hero ควบคุม LCP โดยตรง และการประหยัด AVIF 80%+ เหนือ JPEG แสดงผลเร็วที่สุดที่นั่น

เมื่อไรฉันยังควรใช้ JPEG แทน AVIF หรือ WebP?

เก็บ JPEG สำหรับอีเมล HTML, ฟีดพันธมิตรและมาร์เก็ตเพลซ, ไปป์ไลน์การพิมพ์, และเบราว์เซอร์ฝังตัวเก่าที่เกิดก่อนการรองรับ WebP และ AVIF

เครดิตรูปภาพ

• ปก — Photographer editing photos on a laptop with a DSLR and tablet, ภาพถ่ายโดย cottonbro studio บน Pexels (แปลงเป็น WebP)
• เปรียบเทียบรูปแบบ, แผนภูมิขนาดไฟล์ และซูม artifact — สร้างโดยผู้เขียนจากภาพถ่ายขนมาคอว์ (Pexels #36720663, ภาพถ่ายโดย Kaca Skok) เกณฑ์มาตรฐานการบีบอัดสี่ประเภทและการกวาด effort AVIF สร้างด้วยตัวเข้ารหัส libaom, libwebp และ mozjpeg ของ sharp บนภาพทดสอบสังเคราะห์ที่ปรับเทียบกับความสามารถการบีบอัดของภาพถ่ายจริง