# AVIF, WebP หรือ JPEG XL: เทียบฟอร์แมตภาพสำหรับเว็บ หลัง Chrome 155 เปิดใช้ JPEG XL

> เทียบ AVIF, WebP, JPEG XL และ JPEG ณ ต.ค. 2026 ทั้งเบราว์เซอร์ที่รองรับ ความสามารถ และวิธีเสิร์ฟ หลัง Chrome 155 เปิด JPEG XL และ Firefox 158 เตรียมตาม

- ประเภท: เปรียบเทียบ · หมวด: Software & DevOps
- เผยแพร่: 2026-10-08T11:59:00.000Z · อัปเดต: 2026-10-08T11:59:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/software/jpeg-xl-vs-avif-vs-webp-image-format-comparison/

## สรุปประเด็นสำคัญ

- ณ 8 ตุลาคม 2026 caniuse.com ระบุว่าเบราว์เซอร์ที่เปิด **AVIF** ได้ครอบคลุมผู้ใช้ทั่วโลก 96.35% และ **WebP** 97.18% ส่วน **JPEG XL** อยู่ที่ 16.95% ซึ่งเกือบทั้งหมดเป็นการรองรับบางส่วนใน Safari
- Chrome 155 เปิดใช้ JPEG XL เมื่อ **6 ตุลาคม 2026** และบันทึกรุ่น Firefox 158 Beta ระบุว่ารองรับ JPEG XL โดยรุ่นเสถียรมีกำหนดออก **13 ตุลาคม 2026** แต่ Mozilla เตือนว่าฟีเจอร์ในรุ่น Beta อาจไม่อยู่ในรุ่นจริง
- ตัวเลขขนาดไฟล์มาจากฝ่ายที่พัฒนาฟอร์แมตเอง: Google ระบุว่า WebP แบบ lossy เล็กกว่า JPEG 25–34% AOMedia ระบุว่า AVIF ประหยัดกว่า JPEG มากกว่า 50% และ Google ระบุว่า JPEG XL บีบอัดดีกว่า JPEG 30–50%
- MDN ระบุว่า AVIF ต้องโหลดครบก่อนจึงแสดงภาพ ส่วน JPEG XL แสดงแบบ progressive และแปลงไฟล์ JPEG เดิมแบบไม่เสียข้อมูลได้ ขณะที่ Cloudflare ระบุว่าการเข้ารหัส AVIF อาจช้ากว่าฟอร์แมตอื่นในระดับ **10 เท่า**
- ฟอร์แมตใหม่ทุกตัวยังต้องมีไฟล์สำรอง เสิร์ฟด้วยแท็ก `<picture>` ที่ระบุ `type` หรือเลือกไฟล์จาก Accept header แล้วตอบ `Vary: Accept` โดยเก็บ JPEG หรือ PNG ไว้เป็นตัวสุดท้าย

ณ วันที่ 8 ตุลาคม 2026 ฟอร์แมตที่ใช้เป็นไฟล์ภาพหลักของเว็บได้กว้างที่สุดคือ AVIF และ WebP ซึ่ง caniuse.com ระบุว่าเปิดได้ในเบราว์เซอร์ที่ครอบคลุมผู้ใช้ราว 96% และ 97% ตามลำดับ ส่วน JPEG XL เพิ่งเปิดใช้ใน Chrome 155 เมื่อ 6 ตุลาคม และ Firefox 158 มีกำหนดตามมา 13 ตุลาคม จึงควรใช้เป็นตัวเลือกแรกที่มีไฟล์สำรองเสมอ โดย JPEG ยังเป็นไฟล์สำรองสุดท้ายที่เบราว์เซอร์หลักทุกตัวเปิดได้

บทความนี้เทียบสี่ฟอร์แมตจากเอกสารของผู้ผลิตเบราว์เซอร์และผู้กำหนดมาตรฐานโดยตรง ได้แก่ MDN ของ Mozilla, Chrome for Developers, WebKit, Alliance for Open Media (AOMedia) ผู้ดูแล AVIF, คณะกรรมการ JPEG และหน้า WebP ของ Google โดยใช้ caniuse.com เป็นตารางอ้างอิงการรองรับ ข้อควรรู้คือเอกสารเหล่านี้อัปเดตไม่พร้อมกัน เช่น คู่มือฟอร์แมตภาพของ MDN ที่แก้ไขล่าสุด 22 กันยายน 2026 ยังเขียนว่า Chrome เปิด JPEG XL ได้เฉพาะผ่าน flag เพราะแก้ก่อน Chrome 155 ออก รายละเอียดฝั่ง Chrome อ่านได้ใน[ข่าว Chrome 155 รองรับ JPEG XL](/software/chrome-155-jpeg-xl-support-jxl-rs/)

## AVIF, WebP, JPEG XL และ JPEG ต่างกันอย่างไร

ตารางนี้สรุปความสามารถตามเอกสารต้นทาง ได้แก่ MDN, คำถามที่พบบ่อยของ WebP, สเปก AVIF และ jpeg.org

| ความสามารถ | JPEG | WebP | AVIF | JPEG XL |
| --- | --- | --- | --- | --- |
| การบีบอัด | lossy เท่านั้น | lossy และ lossless | lossy และ lossless | lossy, lossless และแปลง JPEG เดิมแบบไม่เสียข้อมูล |
| ภาพโปร่งใส (alpha) | ไม่มี | มี | มี | มี |
| ภาพเคลื่อนไหว | ไม่มี | มี | มี | มี (Safari ยังไม่แสดง) |
| ความลึกสี / HDR | 8 บิตต่อสี | 8 บิต | 8/10/12 บิต, HDR, ขอบเขตสีกว้าง | ความลึกสีสูง, HDR, ขอบเขตสีกว้าง |
| แสดงภาพระหว่างโหลด | progressive JPEG | ไม่มี progressive แต่มี incremental decoding | ต้องโหลดครบก่อน (ตาม MDN) | progressive (Safari แสดงเมื่อโหลดครบ) |
| ขนาดภาพสูงสุด | 65,535×65,535 | 16,383×16,383 | ภาพเดี่ยว 8,192×4,352 (Baseline) หรือ 16,384×8,704 (Advanced) ใหญ่กว่านั้นใช้ grid | 1,073,741,823×1,073,741,823 |
| สิทธิบัตร | สิทธิบัตรในสหรัฐฯ หมดอายุ 27 ต.ค. 2006 | ไม่ต้องขออนุญาต | royalty-free | royalty-free |

ช่องที่ควรอ่านให้ละเอียดคือการแสดงภาพระหว่างโหลด สเปก AVIF เขียนว่ารองรับการถอดรหัสแบบ progressive ผ่านภาพหลายชั้น (layered images) แต่ MDN ระบุว่าในทางปฏิบัติไฟล์ AVIF ต้องดาวน์โหลดครบก่อนจึงแสดงได้ ส่วน [คำถามที่พบบ่อยของ WebP](https://developers.google.com/speed/webp/faq) ระบุว่า WebP ไม่มี progressive แบบ JPEG แต่มี incremental decoding ที่วาดแถวภาพเท่าที่ได้รับข้อมูลแล้ว ขนาดสูงสุดของ AVIF ในตารางเป็นเพดานต่อภาพที่เข้ารหัสหนึ่งภาพตามโปรไฟล์ใน[สเปก AVIF](https://aomediacodec.github.io/av1-avif/)

## AVIF กับ JPEG XL ต่างกันตรงไหนเมื่อใช้งานจริง

ทั้งสองฟอร์แมตรองรับ lossy, lossless, ภาพโปร่งใส, ภาพเคลื่อนไหว, HDR และขอบเขตสีกว้างเหมือนกัน ความต่างที่มีผลกับเว็บจริงอยู่ที่สามเรื่อง

- **การแสดงภาพก่อนโหลดครบ** MDN ระบุว่า AVIF ไม่รองรับ progressive rendering ซึ่งมักไม่เป็นปัญหาเพราะไฟล์เล็ก แต่กับไฟล์ขนาดใหญ่ผลกระทบอาจชัดเจน และควรพิจารณาฟอร์แมตที่แสดงแบบ progressive ได้ ทีม Chrome คาดว่า JPEG XL จะช่วยได้มากที่สุดกับภาพคุณภาพสูงหรือ lossless โดยเฉพาะภาพถ่าย หรือเมื่อต้องการ progressive แบบละเอียด
- **คลังไฟล์ JPEG เดิม** [คณะกรรมการ JPEG](https://jpeg.org/jpegxl/) ระบุว่าแปลง JPEG เป็น JPEG XL แบบไม่เสียข้อมูลและคืนกลับเป็นไฟล์เดิมได้ทุกประการ เซิร์ฟเวอร์จึงเก็บไฟล์ชุดเดียวแล้วเสิร์ฟได้ทั้งไคลเอนต์ JPEG และ JPEG XL ส่วน README ของ libjxl ระบุว่าเมื่อป้อนไฟล์ JPEG คำสั่ง cjxl จะบีบอัดใหม่แบบไม่เสียข้อมูลเป็นค่าเริ่มต้น เอกสาร AVIF ที่อ้างในบทความนี้ไม่ได้ระบุความสามารถลักษณะนี้
- **ความพร้อมในแต่ละเบราว์เซอร์** AVIF เปิดได้ครบใน Chrome, Edge, Firefox และ Safari แล้ว ส่วน JPEG XL ใน Safari ยังเป็นการรองรับบางส่วน caniuse ระบุว่าไม่มีภาพเคลื่อนไหวและไม่ถอดรหัสแบบ progressive และ Chrome Platform Status ระบุว่า WebKit ยังใช้ตัวถอดรหัส C++ ขณะที่ Chrome ใช้ jxl-rs ที่เขียนด้วย Rust

caniuse เองเขียนสรุปสองหน้าไว้คนละมุม หน้า AVIF ระบุว่า JPEG XL มีคุณภาพการบีบอัดใกล้เคียงกันและถูกมองว่ามีฟีเจอร์มากกว่า ส่วนหน้า JPEG XL ระบุว่า AVIF มีคุณภาพการบีบอัดใกล้เคียงกันแต่ฟีเจอร์น้อยกว่า ข้อสรุปจึงตรงกับคำแนะนำของ Google คือให้ลองทั้งสองฟอร์แมตกับภาพจริงของตัวเอง

## การเข้ารหัส AVIF ช้ากว่า WebP และ JPEG XL จริงหรือไม่

เวลาเข้ารหัส (encode) ไม่ค่อยอยู่ในตารางเปรียบเทียบ แต่สำคัญกับระบบที่แปลงภาพทันทีที่ร้านค้าหรือกองบรรณาธิการอัปโหลด

- **Cloudflare** [เอกสาร Cloudflare Images](https://developers.cloudflare.com/images/optimization/features/) เขียนว่าการเข้ารหัส AVIF อาจช้ากว่าฟอร์แมตอื่นในระดับสิบเท่า (an order of magnitude) และถ้าภาพใหญ่เกินกว่าจะเข้ารหัส AVIF ได้ทัน ระบบจะส่ง WebP หรือ JPEG แทน
- **คณะกรรมการ JPEG** ระบุว่า JPEG XL ออกแบบให้เข้ารหัสและถอดรหัสด้วยซอฟต์แวร์ได้อย่างมีประสิทธิภาพโดยไม่ต้องพึ่งฮาร์ดแวร์เร่งความเร็ว แม้บนอุปกรณ์มือถือ และให้ผู้ใช้เลือกสมดุลระหว่างความเที่ยงตรงของภาพ ความเร็ว และอัตราการบีบอัด ซึ่งโดยทั่วไปอยู่ที่ 20:1 ถึง 50:1
- **ตัวเข้ารหัสอ้างอิง** ทุกตัวมีค่าที่แลกความเร็วกับขนาดไฟล์ [cwebp](https://developers.google.com/speed/webp/docs/cwebp) ใช้ `-m` 0–6 (ค่าเริ่มต้น 4) [avifenc](https://github.com/AOMediaCodec/libavif/blob/main/doc/avifenc.1.md) ใช้ `--speed` 0–10 โดย 0 ช้าที่สุดและค่าเริ่มต้นคือ 6 ส่วน cjxl ใช้ `--effort` ซึ่ง[เอกสาร libjxl](https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md) ระบุว่าปกติอยู่ระหว่าง 1–10 และค่ายิ่งสูงยิ่งเข้ารหัสช้า

ในทางปฏิบัติ ภาพที่แปลงล่วงหน้าครั้งเดียว เช่น แคตาล็อกสินค้า รับเวลาเข้ารหัสนานได้ แต่ภาพที่ต้องแปลงสดตอนมีผู้ขอครั้งแรก (cache miss) ควรวัดเวลาเข้ารหัสด้วย ไม่ใช่ดูเพียงขนาดไฟล์ที่ได้

## เบราว์เซอร์ไหนรองรับ AVIF, WebP และ JPEG XL ณ 8 ตุลาคม 2026

ตัวเลขรุ่นมาจาก caniuse.com ประกอบกับประกาศของ Chrome, WebKit และ Mozilla

| เบราว์เซอร์ | WebP | AVIF | JPEG XL |
| --- | --- | --- | --- |
| Chrome | 32 ขึ้นไป | 85 ขึ้นไป | 155 ขึ้นไป (6 ต.ค. 2026) |
| Edge | 18 ขึ้นไป | 121 ขึ้นไป | ยังไม่รองรับ (ข้อมูลถึงรุ่น 154) |
| Firefox | 65 ขึ้นไป | 93 ขึ้นไป (ภาพเคลื่อนไหวตั้งแต่ 113) | รุ่น 158 ตามกำหนด 13 ต.ค. 2026 |
| Safari | 14 ขึ้นไป (macOS ต้องเป็น Big Sur ขึ้นไป) | iOS 16 ขึ้นไป, macOS เต็มรูปแบบตั้งแต่ 16.4 | 17.0 ขึ้นไป แบบบางส่วน |
| Samsung Internet | 4 ขึ้นไป | 14.0 ขึ้นไป | ยังไม่รองรับ (ถึงรุ่น 30) |
| ผู้ใช้ทั่วโลกที่เปิดได้ | 97.18% | 96.35% | 16.95% |

![หน้า caniuse.com ของ JPEG XL ณ 8 ตุลาคม 2026: Chrome 155–157 และ Firefox 158–160 เป็นสีเขียว Safari เป็นการรองรับบางส่วน ส่วน Edge และ Samsung Internet ยังไม่รองรับ](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/jpeg-xl-vs-avif-vs-webp-image-format-comparison/caniuse-jpeg-xl-support-table.webp?v=575ee405) _(ภาพ: Can I use (ภาพหน้าจอ))_

ตัวเลข 16.95% ของ JPEG XL มาจากการรองรับเต็มรูปแบบ 0.02% บวกการรองรับบางส่วน 16.93% ซึ่งมาจาก Safari บน macOS และ iOS ส่วนแถว Chrome 155–157 ในหน้าเดียวกันยังนับผู้ใช้ได้เพียง 0.02% เพราะ Chrome 155 เพิ่งเริ่มทยอยอัปเดต [บล็อก Chrome Releases](https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html) ระบุว่ารุ่นเดสก์ท็อปจะถึงผู้ใช้ภายในหลายวันถึงหลายสัปดาห์ และรุ่น Android จะขึ้น Google Play ในอีกไม่กี่วัน ตัวเลขนี้จึงยังไม่สะท้อนผู้ใช้ Chrome 155

## Firefox 158 จะเปิดใช้ JPEG XL เมื่อไร

บันทึกรุ่น Firefox 158 Beta ซึ่งเริ่มส่งให้ผู้ใช้ช่อง Beta เมื่อ 28 กันยายน 2026 ระบุว่า Firefox รองรับฟอร์แมต JPEG XL แล้ว ใน Bugzilla [งาน 2065096](https://bugzilla.mozilla.org/show_bug.cgi?id=2065096) ที่เปิดค่า `image.jxl.enabled` เป็นค่าเริ่มต้นอยู่ในสถานะ FIXED โดยกำหนดไว้ที่ Firefox 158 และผู้พัฒนาระบุว่ามีผลกับ Firefox for Android ด้วย ส่วนเว็บไซต์ [Firefox Trains](https://whattrainisitnow.com/release/?version=158) ที่ Mozilla ใช้ติดตามรอบออกรุ่นระบุวันออกรุ่นเสถียรของ Firefox 158 ไว้ที่ 13 ตุลาคม 2026

![บันทึกรุ่น Firefox 158.0beta ในหัวข้อ New มีข้อความว่า Firefox รองรับฟอร์แมต JPEG XL แล้ว พร้อมคำเตือนว่าฟีเจอร์ในรุ่น Beta อาจไม่อยู่ในรุ่นจริง](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/jpeg-xl-vs-avif-vs-webp-image-format-comparison/firefox-158-beta-jpeg-xl-release-note.webp?v=c485e8ad) _(ภาพ: Mozilla Firefox (ภาพหน้าจอ))_

ยังมีสองเรื่องที่ต้องระวัง เรื่องแรก หน้าบันทึกรุ่น Beta มีคำเตือนว่าฟีเจอร์ที่ระบุอาจไม่ได้อยู่ในรุ่นจริง เรื่องที่สอง งานหลักของ JPEG XL ใน Bugzilla (หมายเลข 1539075) ยังอยู่ในสถานะ ASSIGNED และมีงานย่อยค้างอยู่ เช่น การรองรับ HDR ของ JPEG XL (หมายเลข 1709857) ส่วน Firefox 157 ที่เป็นรุ่นเสถียรอยู่ตอนนี้ caniuse ระบุว่ายังปิดฟีเจอร์นี้เป็นค่าเริ่มต้น ทีมเว็บจึงควรทดสอบกับ Firefox 158 รุ่นจริงอีกครั้งหลังวันที่ 13 ตุลาคม

## ตัวเลขขนาดไฟล์ของ AVIF, WebP และ JPEG XL มาจากใคร

ตัวเลขด้านล่างมาจากผู้พัฒนาหรือผู้ดูแลฟอร์แมตนั้นเอง วัดด้วยชุดภาพและตัวชี้วัดต่างกัน จึงไม่ควรนำแถวหนึ่งไปเทียบกับอีกแถวโดยตรง

| ฟอร์แมต | ตัวเลขที่อ้าง | ผู้อ้าง |
| --- | --- | --- |
| WebP | lossy เล็กกว่า JPEG 25–34% ที่ค่า SSIM เท่ากัน, lossless เล็กกว่า PNG 26% | Google |
| WebP | lossy เล็กกว่า JPEG โดยเฉลี่ย 25–35% | MDN |
| AVIF | ไฟล์เล็กกว่า JPEG มากกว่า 50% และเล็กกว่า WebP มากกว่า 30% | AOMedia |
| AVIF | lossy เล็กกว่า JPEG ราว 50% โดยอ้างผลของ CTRL Blog ที่ได้ค่ามัธยฐาน 50% เทียบกับ 30% ของ WebP | MDN |
| JPEG XL | บีบอัดดีกว่า JPEG 30–50% | Google (ทีม Chrome) |
| JPEG XL | แปลง JPEG เดิมแบบไม่เสียข้อมูลเล็กลงเฉลี่ย 20% บีบจากไฟล์ต้นฉบับได้ไฟล์เล็กกว่า JPEG ถึง 60% | [WebKit](https://webkit.org/blog/14445/webkit-features-in-safari-17-0/) |

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

## ภาพตัวอย่างของ Cloudinary บอกอะไรเรื่องขนาดไฟล์

[เอกสาร Optimize Images ของ Cloudinary](https://cloudinary.com/documentation/image_optimization) ยกตัวอย่างภาพย่อขนาดภาพหนึ่งที่ส่งผ่านโหมดเลือกฟอร์แมตอัตโนมัติ (f_auto) ไฟล์ JPEG ต้นฉบับ 33.5 KB เมื่อส่งเป็น AVIF เหลือ 14.6 KB เป็น WebP 16.1 KB และเป็น JPEG XL 21.4 KB

![กราฟขนาดไฟล์จากภาพตัวอย่างเดียวในเอกสาร Cloudinary: AVIF 14.6 KB เล็กที่สุด ตามด้วย WebP 16.1 KB, JPEG XL 21.4 KB และ JPEG ต้นฉบับ 33.5 KB](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/jpeg-xl-vs-avif-vs-webp-image-format-comparison/cloudinary-format-size-example.webp?v=777cb610) _(ภาพ: THAI DATA (ข้อมูล: Cloudinary))_

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

## วิธีเสิร์ฟ AVIF และ JPEG XL ด้วยแท็ก picture

วิธีที่ไม่ต้องแก้เซิร์ฟเวอร์คือให้เบราว์เซอร์เลือกเอง [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture) อธิบายว่าเบราว์เซอร์จะข้าม `<source>` ที่ระบุ `type` ซึ่งตัวเองไม่รองรับ และถ้าไม่มีตัวใดใช้ได้จะใช้ไฟล์ใน `<img>` แทน ส่วน[มาตรฐาน HTML](https://html.spec.whatwg.org/multipage/images.html) ระบุว่าเบราว์เซอร์เลือก `<source>` ตัวแรกที่มี MIME type ที่รองรับ จึงต้องเรียงฟอร์แมตที่อยากให้ใช้ไว้ก่อน

```html
<picture>
  <source srcset="product-800.jxl" type="image/jxl">
  <source srcset="product-800.avif" type="image/avif">
  <source srcset="product-800.webp" type="image/webp">
  <img src="product-800.jpg" alt="ชื่อสินค้า" width="800" height="800" fetchpriority="high">
</picture>
```

- **ใส่ width และ height ทุกภาพ** [web.dev](https://web.dev/articles/optimize-cls) แนะนำให้ใส่ขนาดไว้เสมอ เพื่อให้เบราว์เซอร์จองพื้นที่ได้ถูกต้องระหว่างโหลด ลดการขยับของหน้า (CLS)
- **ภาพที่น่าจะเป็น LCP** [web.dev](https://web.dev/articles/optimize-lcp) แนะนำให้ใส่ `fetchpriority="high"` กับภาพหลักเพียงหนึ่งถึงสองภาพ และเตือนว่าห้ามใส่ `loading="lazy"` ให้ภาพ LCP เพราะจะเริ่มโหลดช้าโดยไม่จำเป็น
- **ภาพเคลื่อนไหวไม่ควรมี source เป็น JPEG XL** Safari รู้จัก `image/jxl` จึงจะเลือก source นี้ แต่ caniuse ระบุว่า Safari ยังไม่รองรับภาพเคลื่อนไหวของ JPEG XL ภาพเคลื่อนไหวจึงควรใช้ AVIF หรือ WebP
- **ต้นทุนที่ต้องรับ** ทุกภาพต้องมีไฟล์หลายฟอร์แมตเก็บไว้ล่วงหน้า และ HTML ยาวขึ้น

## เสิร์ฟ AVIF ผ่าน Accept header ต้องตั้ง Vary อย่างไร

อีกวิธีคือใช้ URL เดียวแล้วให้เซิร์ฟเวอร์หรือ CDN เลือกไฟล์จาก Accept header ที่เบราว์เซอร์ส่งมาตอนขอภาพ ซอร์สโค้ดของทั้งสามเอนจินประกาศ `image/jxl` เมื่อเปิดรองรับ JPEG XL

| เอนจิน | Accept เมื่อขอภาพ (ตามซอร์สโค้ด) |
| --- | --- |
| [Chromium 155](https://chromium.googlesource.com/chromium/src/+/refs/tags/155.0.8059.39/third_party/blink/common/loader/network_utils.cc) | `image/jxl,image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8` |
| [Firefox](https://github.com/mozilla-firefox/firefox/blob/main/netwerk/protocol/http/nsHttpHandler.cpp) เมื่อเปิด image.jxl.enabled | `image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5` |
| [WebKit](https://github.com/WebKit/WebKit/blob/main/Source/WebCore/loader/cache/CachedResourceRequest.cpp) | `image/webp` ตามด้วย `image/avif`, `image/jxl` และ HEIC เมื่อ build รองรับ |

ซอร์สโค้ด WebKit ยังระบุว่าเมื่อผู้ใช้เปิด Lockdown Mode และเชื่อมต่อแบบปลอดภัย Safari จะประกาศเพียง `image/webp` เซิร์ฟเวอร์จึงต้องส่ง WebP หรือ JPEG ให้ผู้ใช้กลุ่มนี้ [ตารางค่า Accept ใน MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Content_negotiation/List_of_default_Accept_values) ที่แก้ไขล่าสุดเดือนสิงหาคม 2025 ยังไม่มีค่าเหล่านี้ ควรตรวจจาก log ของเว็บจริง

คำตอบทุกครั้งต้องมี `Vary: Accept` ซึ่ง [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Vary) อธิบายว่าทำให้แคชเก็บคำตอบแยกตามค่าของ header ที่ระบุ และควรใช้ค่า Vary เดียวกันกับทุกคำตอบของ URL นั้น รวมถึงคำตอบ 304 หากลืม แคชกลางทางอาจส่งไฟล์ .jxl ให้เบราว์เซอร์ที่เปิดไม่ได้

## CDN และบริการแปลงภาพรองรับ AVIF และ JPEG XL แค่ไหน

เอกสารของผู้ให้บริการสามรายที่เปิดอ่าน ณ 8 ตุลาคม 2026 ระบุต่างกันดังนี้

- **Cloudflare Images** (เอกสารแก้ไขล่าสุด 16 มิถุนายน 2026) ค่า `format=auto` ส่งฟอร์แมตที่มีประสิทธิภาพที่สุดที่เบราว์เซอร์รองรับ ฟอร์แมตปลายทางที่ระบุไว้คือ AVIF, WebP และ JPEG ทั้งแบบ progressive และ baseline โดยไม่มี JPEG XL ในรายการ ถ้าเขียน Worker เองต้องอ่าน Accept header เอง
- **Fastly Image Optimizer** [เอกสาร format](https://www.fastly.com/documentation/reference/io/format/) มีค่า `jxl` และ `pjxl` (JPEG XL แบบ progressive) และค่า `auto` เลือกตามลำดับ JPEG XL, AVIF, WebP แล้วจึงเป็นฟอร์แมตต้นฉบับหรือ JPEG แต่การส่ง AVIF และ JPEG XL ต้องซื้อแพ็กเกจ Image Optimizer Professional
- **Cloudinary** ค่า `f_auto` อาจส่ง AVIF, JPEG XL หรือ WebP ตามเบราว์เซอร์ แต่บัญชีที่คิดตามแบนด์วิดท์ไม่ได้เปิด AVIF และ JPEG XL เป็นค่าเริ่มต้น ภาพเล็กกว่า 5,000 พิกเซลจะส่งเป็น WebP เพราะส่วนเกิน (overhead) ของโครงสร้างไฟล์ AVIF มากกว่าส่วนที่ประหยัดได้ และ Cloudinary เตือนว่า f_auto อาจเพิ่มจำนวนการแปลงภาพและพื้นที่จัดเก็บ

![เอกสาร Fastly Image Optimizer หัวข้อ About the auto value ระบุว่า format=auto เลือก JPEGXL, AVIF, WebP แล้วจึงเป็นฟอร์แมตต้นฉบับหรือ JPEG](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/jpeg-xl-vs-avif-vs-webp-image-format-comparison/fastly-image-optimizer-auto-format.webp?v=1fd2dce7) _(ภาพ: Fastly (ภาพหน้าจอ))_

web.dev ระบุว่า image CDN ช่วยทั้งลดระยะทางและลดขนาดไฟล์ แต่ถ้าใช้โดเมนของบุคคลที่สามจะมีต้นทุนการเชื่อมต่อเพิ่ม ทางที่ดีกว่าคือเสิร์ฟภาพจาก origin เดียวกับหน้าเว็บผ่านการ proxy ซึ่ง CDN หลายรายทำได้

## ควรใช้ AVIF, WebP, JPEG XL หรือ JPEG เมื่อไร

| ใช้ | เมื่อ | เหตุผลจากแหล่งข้อมูล |
| --- | --- | --- |
| AVIF + WebP/JPEG สำรอง | ภาพสินค้าและภาพข่าวทั่วไปที่ต้องการไฟล์เล็กและเปิดได้กว้าง | caniuse ระบุ 96.35% และ AOMedia อ้างว่าเล็กกว่า JPEG มากกว่า 50% |
| JPEG XL เป็น source แรก | ภาพถ่ายใหญ่ ภาพ hero หรือภาพคุณภาพสูงที่อยากให้เห็นก่อนโหลดครบ | Google คาดว่าเหมาะกับภาพคุณภาพสูง และ MDN แนะนำให้พิจารณากับภาพใหญ่ความละเอียดสูง |
| JPEG XL ในคลังภาพ | มีไฟล์ JPEG เดิมจำนวนมากที่ต้องเก็บต้นฉบับไว้ | jpeg.org ระบุว่าคืนกลับเป็นไฟล์ JPEG เดิมได้ |
| WebP | ภาพเล็ก ภาพที่ต้องแปลงสดเร็ว หรือภาพเคลื่อนไหวแทน GIF | Cloudinary ส่ง WebP แทน AVIF เมื่อภาพเล็กกว่า 5,000 พิกเซล และ MDN แนะนำ WebP/AVIF แทน GIF |
| SVG | โลโก้ ไอคอน และแผนภาพ | MDN แนะนำให้ใช้ SVG ก่อนเมื่อมีไฟล์เวกเตอร์ |
| JPEG / PNG | ไฟล์สำรองสุดท้าย JPEG สำหรับภาพถ่าย PNG สำหรับภาพโปร่งใสหรือภาพหน้าจอ | MDN |

## เว็บอีคอมเมิร์ซและเว็บข่าวไทยควรเริ่มอย่างไร

เว็บขายของและเว็บข่าวมีภาพจำนวนมากในหน้าแรก ภาพสินค้าหรือภาพประกอบข่าวขนาดใหญ่จึงมีโอกาสเป็นองค์ประกอบ LCP เพราะ [web.dev](https://web.dev/articles/lcp) นับแท็ก `<img>` เป็นหนึ่งในองค์ประกอบที่ใช้วัด เป้าหมายคือ LCP ไม่เกิน 2.5 วินาทีที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้า โดยวัดแยกมือถือกับเดสก์ท็อป ไฟล์ภาพที่เล็กลงยังช่วยผู้อ่านที่ใช้อินเทอร์เน็ตมือถือแบบจำกัดปริมาณข้อมูลด้วย แต่ web.dev เตือนว่าช่วงเวลาโหลดไฟล์มักไม่ใช่คอขวดหลักของเว็บส่วนใหญ่ จึงควรดูข้อมูลผู้ใช้จริงก่อน

1. **วัดก่อนเปลี่ยน** หาภาพ LCP ของหน้าที่มีผู้เข้าชมมากที่สุด แล้วดูว่า LCP ช้าที่ช่วงโหลดไฟล์หรือช่วงรอแสดงผล
2. **ใช้ AVIF เป็นตัวหลักก่อน** เพิ่ม AVIF และ WebP ผ่านแท็ก picture หรือ CDN โดยเก็บ JPEG ไว้สำรอง
3. **ทดลอง JPEG XL เป็นชุดเล็ก** เลือกภาพสินค้าความละเอียดสูงและภาพข่าวขนาดใหญ่ เทียบกับ AVIF ที่คุณภาพเท่ากัน ทั้งขนาดไฟล์และเวลาเข้ารหัส
4. **ตรวจแคชและเบราว์เซอร์** ส่ง `Vary: Accept` และทดสอบกับ Chrome 155, Firefox 158 หลัง 13 ตุลาคม, Safari, Edge และ Samsung Internet
5. **คิดต้นทุนให้ครบ** การเก็บหลายฟอร์แมตเพิ่มพื้นที่จัดเก็บ และ CDN บางรายคิดค่า AVIF หรือ JPEG XL เพิ่ม จึงควรตรวจแพ็กเกจก่อนเปิดใช้

ติดตามเรื่องเบราว์เซอร์และเครื่องมือนักพัฒนาเพิ่มเติมได้ที่[หมวดซอฟต์แวร์](/software/)

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

### AVIF กับ WebP ต่างกันอย่างไร ควรเลือกแบบไหน?

ทั้งสองรองรับ lossy, lossless, ภาพโปร่งใส และภาพเคลื่อนไหว AVIF รองรับความลึกสี 10–12 บิตและ HDR และ AOMedia ระบุว่าไฟล์เล็กกว่า WebP มากกว่า 30% ส่วน WebP เป็นภาพ 8 บิต แต่เปิดได้กว้างกว่าเล็กน้อย (97.18% เทียบกับ 96.35% ตาม caniuse ณ 8 ต.ค. 2026) เว็บทั่วไปจึงใช้ AVIF เป็นตัวหลักได้ โดยเก็บ WebP หรือ JPEG ไว้สำรอง

### JPEG XL ดีกว่า AVIF หรือไม่?

แหล่งข้อมูลหลักไม่ได้ระบุว่าฟอร์แมตใดดีกว่าทุกกรณี Google แนะนำให้ลองทั้ง AVIF และ JPEG XL กับภาพจริง และคาดว่า JPEG XL จะเหมาะที่สุดกับภาพถ่ายคุณภาพสูง ภาพ lossless และภาพที่ต้องแสดงแบบ progressive ส่วน AVIF ได้เปรียบเรื่องการรองรับ เพราะเปิดได้ครบทั้ง Chrome, Edge, Firefox และ Safari แล้ว

### เบราว์เซอร์ไหนเปิดภาพ JPEG XL ได้บ้าง ณ ตุลาคม 2026?

Chrome 155 ขึ้นไปซึ่งออกเมื่อ 6 ตุลาคม 2026 และ Safari 17.0 ขึ้นไป แต่ Safari ยังไม่แสดงภาพเคลื่อนไหวและไม่ถอดรหัสแบบ progressive ส่วน Firefox 158 ที่มีกำหนดออก 13 ตุลาคม 2026 ระบุในบันทึกรุ่น Beta ว่ารองรับแล้ว ขณะที่ Edge ถึงรุ่น 154 และ Samsung Internet ยังไม่รองรับ

### ใช้ AVIF แล้วยังต้องมีไฟล์ JPEG สำรองหรือไม่?

ควรมี MDN แนะนำให้ใช้แท็ก picture ใส่ไฟล์สำรองที่เบราว์เซอร์รองรับกว้างกว่าเมื่อใช้ AVIF เพราะเบราว์เซอร์รุ่นเก่ายังเปิดไม่ได้ โดยใช้ JPEG สำหรับภาพถ่าย และ PNG สำหรับภาพที่ต้องโปร่งใส ไฟล์สำรองจึงเป็นตัวสุดท้ายใน picture หรือเป็นคำตอบเมื่อ Accept header ไม่มีฟอร์แมตใหม่

### เปลี่ยนภาพเป็น AVIF แล้วคะแนน LCP ดีขึ้นแน่หรือไม่?

ไม่แน่เสมอไป web.dev อธิบายว่าการลดขนาดไฟล์ด้วยฟอร์แมตอย่าง AVIF หรือ WebP ลดเวลาโหลดภาพได้ แต่ถ้าภาพถูกซ่อนไว้จนสคริปต์ทำงานเสร็จ เวลาที่ประหยัดจะย้ายไปเป็นช่วงรอแสดงผลแทน ควรดูข้อมูลผู้ใช้จริงก่อนว่า LCP ช้าที่ช่วงไหน เป้าหมายคือ 2.5 วินาทีหรือน้อยกว่า


## แหล่งอ้างอิง

- [Image file type and format guide](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types) — MDN Web Docs (Mozilla)
- [Shipping JPEG XL in Chrome](https://developer.chrome.com/blog/jpeg-xl-in-chrome) — Chrome for Developers (Google)
- [Firefox Beta 158.0beta release notes](https://www.firefox.com/en-US/firefox/158.0beta/releasenotes/) — Mozilla
- [What is AVIF?](https://aomedia.org/specifications/avif/) — Alliance for Open Media
- [An image format for the Web (WebP)](https://developers.google.com/speed/webp) — Google for Developers
- [JPEG XL (JXL) image format](https://caniuse.com/jpegxl) — Can I use