Chrome 155 รองรับภาพ JPEG XL แล้ว ใช้ตัวถอดรหัส jxl-rs ที่เขียนด้วย Rust
Chrome 155 แสดงภาพ JPEG XL (.jxl) ได้ตั้งแต่ 6 ต.ค. 2026 ด้วยตัวถอดรหัส jxl-rs ที่เขียนด้วย Rust แต่ Firefox รุ่นเสถียรยังไม่รองรับ เว็บจึงยังต้องมีไฟล์สำรอง
โดย กองบรรณาธิการ THAI DATA อ่าน 7 นาที ผู้เข้าชม 1
สรุปประเด็นสำคัญ
- Google ประกาศเมื่อ 6 ตุลาคม 2026 ว่า Chrome รองรับการถอดรหัสภาพ JPEG XL (.jxl) ตั้งแต่ Chrome 155 ซึ่งขึ้นรุ่นเสถียรสำหรับ Windows, Mac, Linux และ Android ในวันเดียวกัน และทยอยอัปเดตถึงผู้ใช้ภายในหลายวันถึงหลายสัปดาห์
- Chrome ใช้ jxl-rs ตัวถอดรหัสที่เขียนด้วยภาษา Rust ล้วน เพื่อตัดปัญหาช่องโหว่หน่วยความจำที่พบบ่อยในตัวถอดรหัสภาพภาษา C++ ทีมงานระบุว่าตรวจด้วย fuzzing และ AI แล้วไม่พบบั๊กด้านความปลอดภัยหน่วยความจำ
- Google ระบุว่า JPEG XL บีบอัดได้ดีกว่า JPEG 30–50% แต่แนะนำให้ลองทั้ง AVIF และ JPEG XL โดยคาดว่า JPEG XL จะเหมาะที่สุดกับภาพถ่ายคุณภาพสูงหรือภาพแบบไม่สูญเสียข้อมูล
- Safari รองรับ JPEG XL มาตั้งแต่ Safari 17.0 (18 กันยายน 2023) ส่วนงานเปิดใช้ใน Firefox บน Bugzilla ยังไม่ปิด ทีมเว็บจึงควรเสิร์ฟผ่าน
<picture>หรือ Accept header พร้อมไฟล์สำรองเสมอ
Google ประกาศเมื่อ 6 ตุลาคม 2026 ว่า Chrome รองรับการแสดงภาพ JPEG XL (ไฟล์ .jxl) ตั้งแต่ Chrome 155 ซึ่งขึ้นรุ่นเสถียรสำหรับ Windows, Mac, Linux และ Android ในวันเดียวกัน โดยใช้ตัวถอดรหัส jxl-rs ที่เขียนด้วยภาษา Rust ทั้งหมด ผลคือภาพ JPEG XL เปิดได้แล้วทั้งใน Chrome และ Safari แต่ Firefox รุ่นเสถียรยังเปิดไม่ได้ เว็บที่จะใช้จึงยังต้องมีไฟล์สำรอง
ประกาศนี้มาจากบทความในบล็อก Chrome for Developers ที่ Luca Versari, Moritz Firsching และ Philip Jägenstedt ร่วมเขียน ทีมงานอธิบายว่า JPEG XL เป็นรูปแบบภาพรุ่นใหม่ที่ออกแบบมาให้ตอบโจทย์ทั้งนักพัฒนาเว็บและช่างภาพ บีบอัดแบบไม่สูญเสียข้อมูล (lossless) ได้ มี HDR ในตัว และแปลงไฟล์ JPEG เดิมมาเป็น JPEG XL ได้โดยไม่เสียข้อมูล
Chrome 155 เปิด JPEG XL บนแพลตฟอร์มใดบ้าง
บล็อก Chrome Releases ระบุว่า Chrome 155.0.8059.39/.40 สำหรับ Windows และ Mac และ 155.0.8059.39 สำหรับ Linux ขึ้นช่อง Stable เมื่อ 6 ตุลาคม 2026 และจะทยอยส่งถึงผู้ใช้ในอีกหลายวันถึงหลายสัปดาห์ Chrome 155 สำหรับ Android และ iOS ออกในวันเดียวกัน ส่วนตัวฟีเจอร์อยู่ในรายการของ Chrome 155 Beta มาตั้งแต่ 16 กันยายน 2026
หน้า Chrome Platform Status ของฟีเจอร์นี้ระบุว่าเปิดใช้ใน Chrome 155 ทั้งบน Desktop, Android, iOS และ WebView และเปิดให้ผู้ใช้ทุกคน (Will ship enabled for all users) พร้อมสรุปความสามารถของรูปแบบนี้ว่า
- เป็นมาตรฐาน ISO/IEC 18181
- ถอดรหัสแบบ progressive ผู้ใช้จึงเห็นภาพก่อนดาวน์โหลดครบ
- รองรับขอบเขตสีกว้าง (wide color gamut), HDR และความลึกสีสูง (high bit depth)
- รองรับภาพเคลื่อนไหว
สถานะในเบราว์เซอร์หลัก ณ วันที่ 8 ตุลาคม 2026 ตามเอกสารของแต่ละค่าย
| เบราว์เซอร์ | สถานะ JPEG XL | ที่มา |
|---|---|---|
| Chrome | รองรับตั้งแต่ Chrome 155 (6 ต.ค. 2026) | Chrome for Developers, Chrome Platform Status |
| Safari | รองรับตั้งแต่ Safari 17.0 (18 ก.ย. 2023) บน iOS 17, iPadOS 17, watchOS 10, macOS Sonoma, Ventura และ Monterey | WebKit |
| Firefox | ยังไม่เปิดใช้ในรุ่นเสถียร งานหลักใน Bugzilla 1539075 ยังอยู่ในสถานะ ASSIGNED | Mozilla |
ประกาศของ Google พูดถึง Chrome เท่านั้น ไม่ได้กล่าวถึงเบราว์เซอร์อื่นที่สร้างบน Chromium เช่น Microsoft Edge ทีมเว็บจึงควรทดสอบแยกเอง
ทำไม Chrome เลือกตัวถอดรหัส JPEG XL ที่เขียนด้วย Rust
ทีม Chrome ให้เหตุผลว่าตัวถอดรหัสภาพเป็นจุดที่ถูกโจมตีมากที่สุดจุดหนึ่งของเบราว์เซอร์ เพราะต้องอ่านข้อมูลไบนารีซับซ้อนที่มาจากเครือข่ายโดยตรงและทำงานอยู่ใน renderer process ตัวถอดรหัสที่เขียนด้วยภาษาที่ไม่ปลอดภัยด้านหน่วยความจำอย่าง C++ มีประวัติช่องโหว่แบบ out-of-bounds read, heap overflow และ use-after-free แม้ Chrome จะมี sandbox อยู่แล้ว ทีมงานถือว่านั่นเป็นแนวป้องกันชั้นที่สอง จึงเลือกแก้ที่ต้นเหตุด้วย jxl-rs
โจทย์ต่อมาคือความเร็ว ทีมงานต้องผลักดันให้ฟีเจอร์ target_feature_11 ของ Rust เข้าสู่รุ่นเสถียร เพื่อใช้คำสั่ง SIMD ของซีพียูได้โดยไม่ต้องเขียนโค้ด unsafe แล้วสร้างชั้น jxl_simd โดยได้แนวคิดจากไลบรารี Highway ที่เดิมพัฒนาขึ้นเพื่อ libjxl โค้ด unsafe จึงเหลือเพียงไม่กี่จุดที่ผ่านการตรวจอย่างละเอียด ทีมงานระบุว่าตรวจ jxl-rs ด้วย fuzzing และการรีวิวโค้ดด้วย AI และไม่พบบั๊กด้านความปลอดภัยหน่วยความจำเลยตลอดประวัติการพัฒนา
หน้า GitHub ของ jxl-rs ระบุว่าโครงการใช้สัญญาอนุญาต BSD 3-Clause ประสิทธิภาพใกล้เคียงและบางกรณีเร็วกว่า libjxl ซึ่งเป็นซอฟต์แวร์อ้างอิงภาษา C++ ใช้หน่วยความจำน้อยกว่า และรองรับการแสดงผลแบบ progressive ได้ดีกว่า แต่ยังไม่ใช่ซอฟต์แวร์อ้างอิงอย่างเป็นทางการของมาตรฐาน
JPEG XL ต่างจาก JPEG และ AVIF อย่างไรตามที่ผู้พัฒนาระบุ
ตัวเลขด้านขนาดไฟล์ที่มีตอนนี้มาจากผู้พัฒนาเบราว์เซอร์และคณะกรรมการมาตรฐานเอง ไม่ใช่ผลทดสอบอิสระ
- Google ระบุว่าบีบอัดได้ดีกว่า JPEG 30–50%
- WebKit ระบุว่าการแปลง JPEG เดิมแบบไม่เสียข้อมูลได้ไฟล์เล็กลงเฉลี่ย 20% และถ้าบีบอัดจากไฟล์ต้นฉบับ ไฟล์จะเล็กกว่า JPEG ได้ถึง 60%
- คณะกรรมการ JPEG (jpeg.org) ระบุว่าไฟล์ที่แปลงจาก JPEG คืนกลับเป็นไฟล์ JPEG เดิมได้ทุกประการ เซิร์ฟเวอร์จึงเก็บไฟล์ JPEG XL ชุดเดียวแล้วเสิร์ฟได้ทั้งไคลเอนต์ที่รองรับและไม่รองรับ และระบุงานอีคอมเมิร์ซเป็นหนึ่งในกรณีใช้งาน
Google ไม่ได้บอกว่า JPEG XL ดีกว่า AVIF ทุกกรณี บทความแนะนำให้ลองทั้งสองรูปแบบเพื่อหาผลที่ดีที่สุด และคาดว่า JPEG XL จะช่วยได้มากที่สุดกับภาพคุณภาพสูงหรือภาพแบบ lossless โดยเฉพาะภาพถ่าย หรือเมื่อต้องการให้ภาพค่อย ๆ คมขึ้นระหว่างโหลดแบบละเอียด แหล่งข้อมูลที่อ้างในข่าวนี้ไม่มีตัวเลขเทียบกับ WebP
วิธีเสิร์ฟ JPEG XL โดยไม่ทำให้ภาพแตก
วิธีแรกคือให้เบราว์เซอร์เลือกเองด้วยแท็ก <picture> ตามที่ WebKit แนะนำไว้ตั้งแต่ Safari 17 เบราว์เซอร์ที่ไม่รู้จัก image/jxl จะข้ามไปใช้แหล่งถัดไปจนถึงแท็ก <img> ที่เป็นไฟล์สำรอง ตัวอย่างด้านล่างเป็นโครงที่ทีมเว็บนำไปปรับใช้ได้
<picture>
<source srcset="product-1200.jxl" type="image/jxl">
<source srcset="product-1200.avif" type="image/avif">
<img src="product-1200.jpg" alt="ชื่อสินค้า" width="1200" height="1200">
</picture>
ใน CSS ใช้ฟังก์ชัน image-set() คู่กับ type("image/jxl") ได้ในลักษณะเดียวกัน
วิธีที่สองคือให้เซิร์ฟเวอร์หรือ CDN เลือกไฟล์จาก Accept header ซอร์สโค้ดของ Chromium 155 เปิดฟีเจอร์ JPEG XL เป็นค่าเริ่มต้น และเมื่อเปิดอยู่ Chrome จะส่ง Accept: image/jxl,image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 เมื่อขอไฟล์ภาพ เช่น ภาพจากแท็ก <img> เซิร์ฟเวอร์ที่เห็น image/jxl ก็ส่งไฟล์ .jxl ให้ และส่งรูปแบบอื่นให้เบราว์เซอร์ที่เหลือ วิธีนี้ต้องตอบกลับพร้อม Vary: Accept ซึ่ง MDN อธิบายว่าทำให้แคชแยกเก็บคำตอบตามค่าของ header นั้น หากไม่ใส่ แคชอาจส่งไฟล์ .jxl ให้เบราว์เซอร์ที่เปิดไม่ได้
ทำไมเรื่องนี้สำคัญ
- กลับมาหลังเคยถูกถอด รายการเดิมของฟีเจอร์นี้ใน Chrome Platform Status ซึ่งสร้างเมื่อกุมภาพันธ์ 2021 บันทึกว่า Chromium เคยมีโค้ดทดลองรองรับ JPEG XL หลังแฟล็ก แต่ถูกถอดออกไป รอบนี้ทีม Chrome ระบุว่าตัดสินใจจากเสียงเรียกร้องของนักพัฒนาที่สม่ำเสมอ โดยเฉพาะใน Interop 2026 ที่ JPEG XL เป็นข้อเสนอยอดนิยม
- ทางสำหรับ Firefox Mozilla ระบุเมื่อกันยายน 2024 ว่าข้อกังวลหลักคือตัวถอดรหัสอ้างอิงที่เป็นโค้ด C++ แบบหลายเธรดมากกว่า 100,000 บรรทัด และหากทีม Google ส่งตัวถอดรหัส Rust ที่ผ่านเกณฑ์การใช้งานจริงให้ได้ Mozilla ก็จะนำไปใช้ jxl-rs คือคำตอบของเงื่อนไขนั้น แต่ ณ วันนี้งานใน Firefox ยังไม่ปิด
- ผู้ให้บริการภาพเริ่มสนใจ Chrome Platform Status ระบุว่า Cloudinary และ Shopify แสดงความสนใจจะใช้ภาพ JPEG XL และทีม Chrome ร่วมใน Interop 2026 JPEG XL Investigation เพื่อให้มีชุดทดสอบครบทุกความสามารถของรูปแบบนี้ในทุกเบราว์เซอร์
สิ่งที่ทีมเว็บและอีคอมเมิร์ซไทยควรทำ
- เพิ่ม ไม่ใช่แทนที่ ใส่ JPEG XL เป็นตัวเลือกแรกแล้วเก็บ AVIF, WebP หรือ JPEG ไว้สำรอง เพราะผู้ใช้ Firefox และ Chrome รุ่นก่อน 155 ยังเปิดไม่ได้ และ Chrome 155 เองก็ยังทยอยอัปเดตอยู่
- ทดสอบกับภาพของตัวเอง ตัวเลข 30–50% และ 20% เป็นตัวเลขของผู้พัฒนา ให้เลือกภาพสินค้า แบนเนอร์ และภาพซูมจำนวนหนึ่ง แล้วเทียบ JPEG XL กับ AVIF ที่คุณภาพเท่ากันทั้งขนาดไฟล์ เวลาเข้ารหัส และความคมชัด เครื่องมือ
cjxlของ libjxl กำหนดคุณภาพได้ด้วย--distance(0 คือ lossless ช่วงที่ใช้ได้ดีคือ 0.5–3.0) หรือ--quality(0–100 ใกล้เคียง libjpeg) - ลองกับคลังภาพ JPEG เดิม README ของ libjxl ระบุว่าเมื่อป้อนไฟล์ JPEG ค่าเริ่มต้นของ
cjxlคือบีบอัดใหม่แบบไม่เสียข้อมูล และdjxlสร้างไฟล์ JPEG เดิมกลับคืนได้ จึงเป็นทางลดพื้นที่จัดเก็บโดยยังคืนต้นฉบับได้ ควรทดลองกับชุดตัวอย่างก่อนแปลงทั้งคลัง - ตรวจ CDN และแคชก่อนเปิดใช้ ถ้าเลือกไฟล์จาก Accept header ต้องส่ง
Vary: Acceptและตรวจว่า CDN แยกแคชตามค่านี้ได้จริง ตั้ง MIME typeimage/jxlให้ไฟล์ .jxl แล้วทดสอบกับ Chrome 155, Safari และ Firefox ทุกครั้ง - อัปเดต libjxl ฝั่งเซิร์ฟเวอร์ ระบบที่แปลงภาพที่ผู้ใช้หรือร้านค้าอัปโหลดก็รับไฟล์จากภายนอกเหมือนเบราว์เซอร์ README ของ libjxl แนะนำให้อัปเดตเป็น v0.12 โดยเร็วเพราะมีการแก้ไขด้านความปลอดภัยจำนวนมาก (v0.12.0 เผยแพร่บน GitHub เมื่อ 1 กรกฎาคม 2026)
ติดตามข่าวภาษาโปรแกรม เบราว์เซอร์ และเครื่องมือนักพัฒนาเพิ่มเติมได้ที่หมวดซอฟต์แวร์
คำถามที่พบบ่อย
JPEG XL คืออะไร?
JPEG XL คือรูปแบบไฟล์ภาพนามสกุล .jxl ตามมาตรฐาน ISO/IEC 18181 รองรับทั้งการบีบอัดแบบสูญเสียและไม่สูญเสียข้อมูล การแสดงผลแบบ progressive, HDR, ขอบเขตสีกว้าง และภาพเคลื่อนไหว ทั้งยังแปลงไฟล์ JPEG เดิมแบบไม่เสียข้อมูลและคืนกลับเป็นไฟล์เดิมได้ Google ระบุว่าบีบอัดได้ดีกว่า JPEG 30–50%
Chrome รุ่นไหนเปิดภาพ JPEG XL ได้?
Chrome 155 เป็นต้นไป ซึ่งขึ้นรุ่นเสถียรเมื่อ 6 ตุลาคม 2026 สำหรับ Windows, Mac, Linux และ Android และทยอยส่งถึงผู้ใช้ภายในหลายวันถึงหลายสัปดาห์ หน้า Chrome Platform Status ระบุว่า JPEG XL เปิดใช้ให้ผู้ใช้ทุกคนบน Desktop, Android, iOS และ WebView
เบราว์เซอร์ไหนยังเปิดภาพ JPEG XL ไม่ได้?
Firefox รุ่นเสถียรยังไม่รองรับ JPEG XL งานหลักใน Bugzilla หมายเลข 1539075 ยังอยู่ในสถานะ ASSIGNED ส่วน Safari รองรับมาตั้งแต่ Safari 17.0 ในเดือนกันยายน 2023 ผู้ใช้ Chrome รุ่นก่อน 155 ก็ยังเปิดไม่ได้ เว็บจึงต้องมีไฟล์ JPEG, WebP หรือ AVIF สำรองไว้
ควรเปลี่ยนภาพทั้งเว็บเป็น JPEG XL เลยหรือไม่?
ยังไม่ควรเปลี่ยนทั้งหมด วิธีที่ปลอดภัยคือเพิ่ม JPEG XL เป็นตัวเลือกแรกในแท็ก picture หรือให้ CDN เลือกจาก Accept header แล้วเก็บไฟล์รูปแบบเดิมไว้สำรอง Google เองแนะนำให้ทดลองทั้ง AVIF และ JPEG XL กับภาพจริงก่อนเลือก
ทำไม Chrome ใช้ jxl-rs แทน libjxl?
ทีม Chrome ระบุว่าตัวถอดรหัสภาพเป็นจุดที่ถูกโจมตีบ่อยเพราะต้องอ่านข้อมูลจากเครือข่ายโดยตรง และตัวถอดรหัสภาษา C++ มีประวัติช่องโหว่หน่วยความจำ จึงเลือก jxl-rs ซึ่งเขียนด้วย Rust ล้วน และทำให้เร็วใกล้เคียงตัวอ้างอิง libjxl ด้วยการใช้คำสั่ง SIMD โดยไม่ต้องเขียนโค้ด unsafe
แหล่งอ้างอิง
- Shipping JPEG XL in Chrome — Chrome for Developers (Google)
- JPEG XL decoding support (image/jxl) in blink — Chrome Platform Status
- Stable Channel Update for Desktop — Chrome Releases (Google)
- WebKit Features in Safari 17.0 — WebKit
- Bug 1539075 - Implement support for JPEG XL (image/jxl) — Mozilla
- libjxl: JPEG XL reference implementation — JPEG XL Project (GitHub)
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ