Blog
Format
เปรียบเทียบ: WebP, AVIF, JPEG XL - รูปภาพยุคใหม่เพื่อเว็บไซต์ที่เร็วขึ้น
🔥 แค่ 5 นาที เปลี่ยนมุมมองได้เลย

เปรียบเทียบ: WebP, AVIF, JPEG XL - รูปภาพยุคใหม่เพื่อเว็บไซต์ที่เร็วขึ้น

By Tanakit Chaithip
July 1, 2025
ยาวไป อยากเลือกอ่าน?
Format

สำหรับเว็บไซต์ในปี 2026 แนะนำใช้ AVIF เป็นฟอร์แมตหลัก (ขนาดเล็กกว่า JPEG 50-70% คุณภาพสูง) และ WebP เป็น fallback (รองรับเบราว์เซอร์กว้างกว่า ขนาดเล็กกว่า JPEG 25-35%) ส่วน JPEG XL มีศักยภาพสูงมาก (lossless recompression, progressive decode, 10/12-bit) แต่การรองรับเบราว์เซอร์ยังจำกัด โครงสร้างที่แนะนำคือ <picture> element ลำดับ AVIF --> WebP --> JPEG เพื่อครอบคลุมทุกเบราว์เซอร์และลดขนาดไฟล์สูงสุด

ทำไมฟอร์แมตภาพจึงสำคัญต่อความเร็วเว็บไซต์และอันดับ SEO

ภาพเป็นสาเหตุอันดับ 1 ของน้ำหนักหน้าเว็บ ข้อมูลจาก HTTP Archive ระบุว่าภาพคิดเป็น 40-60% ของ Total Page Weight เฉลี่ย นั่นหมายความว่าการเลือกฟอร์แมตภาพที่ถูกต้องคือวิธีที่เร็วที่สุดในการลดน้ำหนักหน้าเว็บโดยไม่ต้องแตะโค้ดแม้แต่บรรทัดเดียว

ผลกระทบตรงต่อ Core Web Vitals โดยเฉพาะ LCP (Largest Contentful Paint) ซึ่ง Google ใช้เป็นสัญญาณจัดอันดับ ภาพ Hero หรือภาพหลักมักเป็น LCP Element ถ้าภาพใหญ่เกินไป LCP ช้า อันดับลด ถ้าภาพเล็กลงโดยคุณภาพเท่าเดิม LCP เร็วขึ้น อันดับดีขึ้น Conversion ดีขึ้น

ตัวเลขจริง: การเปลี่ยนจาก JPEG เป็น AVIF สามารถลดขนาดภาพ Hero จาก 300KB เหลือ 80-100KB โดยคุณภาพที่ดวงตามนุษย์แทบแยกไม่ออก ลด LCP ได้ 0.5-1.5 วินาที ซึ่งตาม Portent ทุก 1 วินาทีที่เร็วขึ้น Conversion Rate เพิ่ม 5.7%

ฟอร์แมตภาพยุคใหม่: AVIF, WebP, JPEG XL คืออะไร

AVIF (AV1 Image File Format)

AVIF พัฒนามาจาก AV1 Video Codec โดย Alliance for Open Media (AOMedia) ซึ่งมีสมาชิก ได้แก่ Google, Apple, Mozilla, Netflix, Amazon และอื่น เปิดตัวในปี 2019 และเริ่มรองรับใน Chrome 85 (2020) ปัจจุบัน (2026) รองรับใน Chrome, Firefox, Safari 16.4+, Edge และ Opera

จุดเด่น:

  • อัตราส่วนการบีบอัดดีที่สุดในฟอร์แมตที่รองรับเบราว์เซอร์กว้าง: เล็กกว่า JPEG 50-70% ที่ SSIM เท่ากัน
  • รองรับ 10-bit color depth (HDR), Alpha Channel (ความโปร่งใส), Wide Color Gamut
  • รองรับ Animated AVIF (ทดแทน GIF/Animated WebP)
  • Royalty-free ไม่มีค่าลิขสิทธิ์

ข้อจำกัด:

  • เวลาเข้ารหัสช้ากว่า WebP/JPEG โดยเฉพาะที่ Quality สูง (Speed 0-2) อาจใช้เวลา 5-20 วินาทีต่อภาพ
  • ขนาดภาพสูงสุดจำกัดที่ 8193x4320px ใน Baseline Profile (แก้ได้ด้วย Grid/Tiling)
  • เครื่องมือแก้ไขภาพบางตัวยังไม่รองรับเต็มที่ (แม้จะดีขึ้นมากในปี 2025-2026)

WebP

WebP พัฒนาโดย Google เปิดตัวในปี 2010 ปัจจุบันรองรับในเบราว์เซอร์สมัยใหม่เกือบทั้งหมด รวมถึง Safari 14+ (macOS Big Sur, iOS 14+)

จุดเด่น:

  • รองรับเบราว์เซอร์กว้างที่สุดในฟอร์แมตสมัยใหม่: 97%+ ของผู้ใช้ทั่วโลก (Can I Use 2026)
  • เข้ารหัสเร็วมาก เหมาะกับการแปลงจำนวนมาก (Batch Conversion)
  • รองรับ Lossy, Lossless, Alpha Channel, Animation
  • เล็กกว่า JPEG 25-35% ที่คุณภาพเทียบเท่า
  • เครื่องมือรองรับทั่วถึง: Photoshop, Figma, Sharp, Squoosh, CDN ทุกเจ้า

ข้อจำกัด:

  • บีบอัดได้น้อยกว่า AVIF โดยเฉพาะที่ Bitrate ต่ำ (Low Quality) ภาพจะมี Artifacts มากกว่า AVIF
  • จำกัดที่ 8-bit color ไม่รองรับ HDR/Wide Gamut
  • ขนาดภาพสูงสุด 16383x16383px

JPEG XL (JXL)

JPEG XL พัฒนาโดย JPEG Committee เปิดตัว Spec Final ในปี 2022 ออกแบบมาเป็น "ตัวตายตัวแทน" ของ JPEG ดั้งเดิม มีความทะเยอทะยานสูง

จุดเด่น:

  • Lossless JPEG Recompression: แปลง JPEG เดิมให้เล็กลง 20% โดยไม่สูญเสียคุณภาพแม้แต่ 1 bit สามารถแปลงกลับเป็น JPEG ตัวเดิมได้ (bit-exact)
  • Progressive Decode: แสดงภาพจากหยาบไปละเอียด เหมาะกับภาพใหญ่/การเชื่อมต่อช้า
  • รองรับ 10/12-bit, HDR, Wide Gamut, Alpha, Animation, CMYK
  • เข้ารหัสเร็วกว่า AVIF มากที่คุณภาพเทียบเท่า
  • ขนาดภาพสูงสุดเกือบไม่จำกัด (1,073,741,823 x 1,073,741,823 px)

ข้อจำกัด:

  • การรองรับเบราว์เซอร์ยังจำกัดมาก: Safari 17+ รองรับ, Chrome เคยทดลองแล้วถอด (ปี 2022), Firefox เปิดเป็น Flag แต่ยังไม่เปิดเป็น Default ข้อมูล ณ ต้นปี 2026
  • ใช้ในงาน Production สำหรับเว็บทั่วไปยังไม่แนะนำ เว้นแต่จะ Serve เฉพาะ Safari
  • Ecosystem ยังเล็กเมื่อเทียบกับ AVIF และ WebP

ตารางเปรียบเทียบ AVIF vs WebP vs JPEG XL ฉบับสมบูรณ์

คุณสมบัติ AVIF WebP JPEG XL JPEG (ดั้งเดิม)
ปีเปิดตัว 2019 2010 2022 (Final Spec) 1992
ผู้พัฒนา AOMedia (Google, Apple, Mozilla, Netflix ฯลฯ) Google JPEG Committee JPEG Committee
Lossy Compression ดีมาก (SSIM สูงที่ Bitrate ต่ำ) ดี (เล็กกว่า JPEG 25-35%) ดีมาก (ใกล้เคียง/ดีกว่า AVIF ที่ Bitrate บาง Range) ปานกลาง (พื้นฐาน)
Lossless Compression ดี ดี ดีมาก (ดีกว่า PNG 30-50%) ไม่รองรับ
ขนาดเทียบ JPEG (Lossy) เล็กกว่า 50-70% เล็กกว่า 25-35% เล็กกว่า 40-60% 100% (Baseline)
Color Depth 8/10/12-bit 8-bit 8/10/12/16/32-bit 8-bit
HDR Support รองรับ (PQ, HLG) ไม่รองรับ รองรับ (PQ, HLG, Linear) ไม่รองรับ
Alpha Channel รองรับ รองรับ รองรับ ไม่รองรับ
Animation รองรับ รองรับ (ใช้กว้าง) รองรับ ไม่รองรับ
Progressive Decode จำกัด ไม่รองรับ รองรับ (เด่นมาก) รองรับ (Progressive JPEG)
Lossless JPEG Recompression ไม่รองรับ ไม่รองรับ รองรับ (ลด 20% bit-exact) ไม่มี
ความเร็วเข้ารหัส ช้า (5-20 วินาที/ภาพ ที่ High Quality) เร็ว (< 1 วินาที/ภาพ) เร็ว-กลาง (1-5 วินาที/ภาพ) เร็วมาก
ความเร็วถอดรหัส กลาง เร็ว เร็ว เร็วมาก
Browser Support (2026) Chrome, Firefox, Safari 16.4+, Edge, Opera (~93%) ทุกเบราว์เซอร์สมัยใหม่ (~97%) Safari 17+ (~20-25%) ทุกเบราว์เซอร์ (100%)
Royalty Free Free Free Free
Max Dimension 8193x4320 (Baseline), Tiling ได้ 16383x16383 ~1 พันล้าน px 65535x65535

Benchmark จริง: ขนาดไฟล์เมื่อบีบอัดจากต้นฉบับเดียวกัน

ทดสอบด้วยภาพ 4 ประเภทที่พบบ่อยในเว็บไซต์ ใช้คุณภาพที่ SSIM (Structural Similarity Index) ใกล้เคียงกันทุกฟอร์แมต เพื่อเปรียบเทียบขนาดไฟล์ที่ "ดูเหมือนกัน" สำหรับตามนุษย์:

ประเภทภาพ ต้นฉบับ (PNG) JPEG (Q80) WebP (Q80) AVIF (Q60) JPEG XL (Q75)
ภาพ Hero (1920x1080 ภาพถ่าย) 5.2 MB 320 KB 215 KB (-33%) 105 KB (-67%) 135 KB (-58%)
ภาพสินค้า (800x800 พื้นขาว) 1.8 MB 85 KB 58 KB (-32%) 32 KB (-62%) 40 KB (-53%)
UI Screenshot (1440x900) 2.1 MB 180 KB 120 KB (-33%) 65 KB (-64%) 78 KB (-57%)
Illustration/Graphic (1200x630) 950 KB 110 KB 75 KB (-32%) 48 KB (-56%) 55 KB (-50%)

หมายเหตุ: ตัวเลขเป็นค่าประมาณจากการทดสอบด้วย libavif, cwebp และ libjxl โดยปรับ Quality ให้ SSIM ใกล้เคียงกัน (~0.95) ผลลัพธ์จริงแตกต่างตามเนื้อหาภาพ

สรุปจาก Benchmark:

  • AVIF ให้ขนาดเล็กที่สุดในทุกประเภทภาพ ประหยัดเฉลี่ย 55-67% เทียบ JPEG
  • JPEG XL อยู่อันดับ 2 ประหยัดเฉลี่ย 50-58% เทียบ JPEG
  • WebP อยู่อันดับ 3 แต่ยังประหยัดได้ 30-35% เทียบ JPEG
  • สำหรับภาพ Hero ขนาด 1920x1080 การเปลี่ยนจาก JPEG เป็น AVIF ลดขนาดจาก 320KB เหลือ 105KB ลด LCP ได้อย่างมีนัยสำคัญ

ตารางตัดสินใจ: เลือกฟอร์แมตตาม Use Case

Use Case ฟอร์แมตหลัก Fallback เหตุผล
Hero Image / Above the Fold AVIF WebP --> JPEG ขนาดเล็กที่สุด = LCP เร็วที่สุด สำคัญต่อ SEO โดยตรง (ดู Above the Fold สำหรับ B2B)
ภาพบทความ/บล็อก AVIF หรือ WebP JPEG AVIF ถ้า CDN/CMS รองรับ Auto-convert ไม่งั้น WebP ก็เพียงพอ
ภาพสินค้า E-commerce AVIF WebP --> JPEG ภาพสินค้ามีจำนวนมาก การลด 50-60% ต่อภาพ ลดน้ำหนักรวมมหาศาล
Logo / Icon (โปร่งใส) SVG (ถ้า Vector ได้) WebP/AVIF --> PNG SVG ขนาดเล็กที่สุด, Scale ได้ไม่สูญเสียคุณภาพ
Animated Banner/Sticker WebP (Animated) GIF Animated WebP มีเครื่องมือรองรับมากที่สุด ขนาดเล็กกว่า GIF 50-80%
ภาพ HDR / Wide Gamut AVIF JPEG XL (Safari) --> JPEG AVIF รองรับ 10-bit + HDR ในเบราว์เซอร์ที่กว้างกว่า JXL
ภาพ Archive / Lossless Storage JPEG XL (Lossless Recompression) WebP Lossless / PNG JXL ลดขนาด JPEG เดิม 20% โดยไม่สูญเสียอะไรเลย แปลงกลับได้
Thumbnail (< 200px) WebP JPEG ที่ขนาดเล็กมาก ส่วนต่างระหว่าง AVIF กับ WebP น้อย WebP เข้ารหัสเร็วกว่า

วิธี Implement ฟอร์แมตภาพยุคใหม่บนเว็บไซต์

วิธีที่ 1: HTML <picture> Element (แนะนำ)

วิธีนี้ให้เบราว์เซอร์เลือกฟอร์แมตที่ดีที่สุดที่รองรับ โดยเรียงจากฟอร์แมตที่มีประสิทธิภาพสูงสุดไปต่ำสุด:

<picture>
  <!-- AVIF: เบราว์เซอร์ที่รองรับจะใช้ตัวนี้ -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: Fallback สำหรับเบราว์เซอร์ที่ไม่รองรับ AVIF -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: Fallback สุดท้าย -->
  <img src="hero.jpg" alt="Hero Image" width="1920" height="1080"
       loading="lazy" decoding="async">
</picture>

สำหรับ LCP Image (Hero/Above the Fold): อย่าใช้ loading="lazy" ให้ใช้ fetchpriority="high" แทน และ Preload ด้วย:

<!-- Preload LCP Image -->
<link rel="preload" as="image" type="image/avif" href="hero.avif"
      imagesrcset="hero.avif" fetchpriority="high">

<!-- ใน HTML -->
<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero Image" width="1920" height="1080"
       fetchpriority="high" decoding="async">
</picture>

วิธีที่ 2: Content Negotiation (Server-side)

เซิร์ฟเวอร์ตรวจ Accept Header ของเบราว์เซอร์ แล้ว Serve ฟอร์แมตที่ดีที่สุด โดยใช้ URL เดียว:

# Nginx Configuration
map $http_accept $webp_suffix {
  default "";
  "~*avif" ".avif";
  "~*webp" ".webp";
}

location ~* \.(jpg|jpeg|png)$ {
  try_files $uri$webp_suffix $uri =404;
  add_header Vary Accept;
}

ข้อสำคัญ: ต้องเพิ่ม Vary: Accept Header เพื่อให้ CDN Cache แยกตามฟอร์แมต ไม่งั้น CDN อาจ Serve AVIF ให้เบราว์เซอร์ที่ไม่รองรับ

วิธีที่ 3: CDN Auto-conversion (ง่ายที่สุด)

CDN หลายเจ้ารองรับการแปลงฟอร์แมตภาพอัตโนมัติ:

CDN / Service ฟีเจอร์ AVIF WebP JPEG XL หมายเหตุ
Cloudflare (Polish) Auto WebP/AVIF รองรับ (Pro+) รองรับ ไม่ เปิด Polish + WebP/AVIF ใน Dashboard
Cloudflare Images Image Transformation API รองรับ รองรับ ไม่ Resize/Crop/Format ผ่าน URL Parameters
Imgix Real-time Processing รองรับ รองรับ ไม่ auto=format ให้ Serve ฟอร์แมตที่ดีที่สุดอัตโนมัติ
Cloudinary Auto Format รองรับ รองรับ รองรับ (Beta) f_auto ให้เลือกอัตโนมัติ
Vercel (next/image) Built-in Optimization รองรับ รองรับ ไม่ ใช้ Sharp ภายใน Serve AVIF/WebP อัตโนมัติ
AWS CloudFront + Lambda@Edge Custom Logic รองรับ (Custom) รองรับ (Custom) รองรับ (Custom) ต้องเขียน Lambda Function เอง

คำแนะนำ: ถ้าใช้ CDN ที่มี Auto Format ใช้วิธีนี้เป็นทางเลือกแรก ง่ายที่สุด ไม่ต้องแก้ HTML ไม่ต้องเก็บไฟล์หลายฟอร์แมต

เครื่องมือแปลงฟอร์แมตภาพ

เครื่องมือ ประเภท AVIF WebP JPEG XL เหมาะกับ
Squoosh (squoosh.app) เว็บ GUI รองรับ รองรับ รองรับ ทดสอบ/เปรียบเทียบทีละภาพ ดู Quality vs Size แบบ Real-time
Sharp (Node.js) Library รองรับ รองรับ ไม่ (ยัง) Build Pipeline, CI/CD, Next.js Image Optimization
libavif / cavif CLI รองรับ -- -- Batch Convert AVIF ด้วย Script
cwebp / dwebp CLI (Google) -- รองรับ -- Batch Convert WebP ด้วย Script
libjxl / cjxl CLI -- -- รองรับ แปลง JPEG XL, ทดสอบ Lossless Recompression
ImageMagick 7 CLI รองรับ รองรับ รองรับ (Build with JXL) Universal Tool สำหรับ Batch Processing
FFmpeg CLI รองรับ รองรับ ไม่ แปลง Frame จาก Video เป็น AVIF/WebP

ตัวอย่าง Script สำหรับ Batch Convert

# แปลง JPEG ทั้งหมดใน Folder เป็น AVIF + WebP
for file in *.jpg; do
  # AVIF (Quality 60, Speed 4)
  avifenc "$file" -q 60 -s 4 "${file%.jpg}.avif"
  # WebP (Quality 80)
  cwebp -q 80 "$file" -o "${file%.jpg}.webp"
done
# Node.js ด้วย Sharp
const sharp = require('sharp');
const fs = require('fs');
const path = require('path');

const inputDir = './images';
const files = fs.readdirSync(inputDir).filter(f => /\.jpe?g$/i.test(f));

for (const file of files) {
  const input = path.join(inputDir, file);
  const base = path.parse(file).name;

  // AVIF
  await sharp(input).avif({ quality: 60 }).toFile(`${base}.avif`);
  // WebP
  await sharp(input).webp({ quality: 80 }).toFile(`${base}.webp`);
}

ผลกระทบต่อ Core Web Vitals โดยเฉพาะ LCP

LCP (Largest Contentful Paint) คือเมตริกที่วัดเวลาที่เนื้อหาหลักปรากฏบนหน้าจอ ภาพ Hero มักเป็น LCP Element ดังนั้นฟอร์แมตภาพมีผลโดยตรง (ดูรายละเอียดเพิ่มใน Core Web Vitals สำหรับ B2B)

สถานการณ์ JPEG Hero (320KB) WebP Hero (215KB) AVIF Hero (105KB)
3G Network (1.5 Mbps) LCP ~3.7s LCP ~3.1s (-0.6s) LCP ~2.3s (-1.4s)
4G Network (10 Mbps) LCP ~2.0s LCP ~1.8s (-0.2s) LCP ~1.5s (-0.5s)
Broadband (50 Mbps) LCP ~1.5s LCP ~1.4s (-0.1s) LCP ~1.3s (-0.2s)

ค่า LCP เป็นการประมาณ รวมเวลา Server Response + Resource Download + Render ความแตกต่างชัดเจนที่สุดบน Network ช้า ซึ่งคือ Real-world Condition ของผู้ใช้ส่วนใหญ่บนมือถือ

ข้อสรุป: บน 3G การเปลี่ยนจาก JPEG เป็น AVIF ลด LCP ได้ 1.4 วินาที ซึ่งเพียงพอที่จะเปลี่ยนจาก "Needs Improvement" (2.5-4.0s) เป็น "Good" (< 2.5s) ในสายตาของ Google

CLS (Cumulative Layout Shift): ป้องกันหน้ากระตุกจากภาพ

ฟอร์แมตภาพไม่มีผลต่อ CLS โดยตรง แต่วิธีการใส่ภาพใน HTML มีผล ไม่ว่าจะใช้ AVIF, WebP หรือ JPEG ต้อง:

  • กำหนด width และ height attribute ให้ทุก <img>
  • หรือใช้ CSS aspect-ratio
  • ตั้ง display: block หรือ max-width: 100%; height: auto;

ถ้าไม่กำหนดขนาด เบราว์เซอร์จะ Layout หน้าเว็บก่อนโดยไม่เว้นที่ให้ภาพ พอภาพโหลดเสร็จก็ดันเนื้อหาอื่นลง สร้าง CLS สูง ส่งผลเสียต่อทั้ง UX และ SEO

Fallback Strategy: ทำให้ทุกเบราว์เซอร์เห็นภาพ

ลำดับ Fallback ที่แนะนำ:

  1. AVIF -- ฟอร์แมตหลัก ขนาดเล็กที่สุด (~93% ของผู้ใช้)
  2. WebP -- Fallback แรก สำหรับเบราว์เซอร์เก่าที่ไม่รองรับ AVIF (~97% ของผู้ใช้)
  3. JPEG/PNG -- Fallback สุดท้าย สำหรับเบราว์เซอร์เก่ามาก (100%)

เมื่อใช้ <picture> element เบราว์เซอร์จะอ่านจากบนลงล่าง เลือก <source> แรกที่รองรับ ถ้าไม่รองรับทั้งหมดจะใช้ <img> ตัวสุดท้าย ไม่มีเบราว์เซอร์ไหนถูกทิ้งไว้ข้างหลัง

JPEG XL ใน Fallback Chain?

ถ้าต้องการเพิ่ม JPEG XL (สำหรับผู้ใช้ Safari 17+):

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero Image" width="1920" height="1080">
</picture>

แต่ในทางปฏิบัติ การเพิ่ม JXL ใน Chain อาจไม่คุ้มค่ากับ Effort ในการสร้าง/เก็บไฟล์เพิ่ม เพราะ AVIF ก็ทำงานได้ดีบน Safari 16.4+ แล้ว แนะนำเพิ่ม JXL เฉพาะเมื่อ Chrome เริ่มรองรับ

Responsive Images + Modern Formats

รวม <picture> กับ srcset เพื่อ Serve ทั้งฟอร์แมตและขนาดที่เหมาะสมกับอุปกรณ์:

<picture>
  <!-- AVIF: 3 ขนาด -->
  <source
    type="image/avif"
    srcset="hero-480.avif 480w,
            hero-960.avif 960w,
            hero-1920.avif 1920w"
    sizes="100vw">
  <!-- WebP: 3 ขนาด -->
  <source
    type="image/webp"
    srcset="hero-480.webp 480w,
            hero-960.webp 960w,
            hero-1920.webp 1920w"
    sizes="100vw">
  <!-- JPEG Fallback -->
  <img
    src="hero-960.jpg"
    srcset="hero-480.jpg 480w,
            hero-960.jpg 960w,
            hero-1920.jpg 1920w"
    sizes="100vw"
    alt="Hero Image"
    width="1920" height="1080"
    loading="lazy" decoding="async">
</picture>

วิธีนี้เบราว์เซอร์จะเลือกทั้งฟอร์แมตที่ดีที่สุดและขนาดที่เหมาะสมกับหน้าจอ เช่น ผู้ใช้ Chrome บน iPhone จะได้ hero-480.avif (ขนาดเล็กที่สุด ประหยัด Data ที่สุด)

Quality Settings ที่แนะนำสำหรับแต่ละฟอร์แมต

ฟอร์แมต Quality ต่ำ (Fast/Small) Quality กลาง (แนะนำ) Quality สูง (Premium) Lossless
AVIF Q30-40 (Thumbnail, BG) Q50-65 (บทความ, บล็อก) Q70-80 (สินค้า, Hero) Q100 (Archive)
WebP Q50-60 Q70-80 Q85-92 -lossless flag
JPEG XL Q40-50 Q60-75 Q80-90 -q 100 หรือ -d 0
JPEG Q50-60 Q75-82 Q85-92 ไม่รองรับ

Q ของ AVIF ต่ำกว่า Q ของ WebP/JPEG ที่คุณภาพเท่ากัน เพราะ AVIF บีบอัดได้ดีกว่า Q60 ของ AVIF ให้คุณภาพใกล้เคียงกับ Q80 ของ JPEG

เคล็ดลับ: ใช้ Squoosh เปรียบเทียบ Quality แบบ Side-by-side ก่อนตั้งค่าสำหรับ Production หาจุดที่ "ขนาดลดลงมาก แต่ตาแยกไม่ออก" นั่นคือ Sweet Spot ของ Quality Setting

SEO สำหรับภาพ: ฟอร์แมตเดียวไม่พอ

นอกจากฟอร์แมตที่ถูกต้อง ยังมีปัจจัยอื่นที่ส่งผลต่อ SEO ของภาพ:

ปัจจัย วิธีปฏิบัติ ผลต่อ SEO
Alt Text อธิบายภาพด้วย Keyword อย่างเป็นธรรมชาติ (ไม่ Keyword Stuffing) ช่วยให้ Google เข้าใจภาพ, ติดอันดับใน Image Search
Filename ใช้ชื่อที่สื่อความหมาย เช่น hero-b2b-dashboard.avif ไม่ใช่ IMG_1234.avif สัญญาณเล็กน้อยแต่ช่วย
Image Sitemap เพิ่มภาพสำคัญใน Sitemap หรือใช้ <image:image> tag ช่วย Googlebot ค้นพบภาพเร็วขึ้น
Structured Data ใช้ ImageObject Schema สำหรับภาพสำคัญ เพิ่มโอกาส Rich Result
Lazy Loading ใช้ loading="lazy" เฉพาะภาพ Below the Fold อย่าใช้กับ LCP Image ลด Initial Load Time, ปรับปรุง LCP
width/height กำหนดทุกภาพเพื่อป้องกัน CLS ลด CLS ซึ่งเป็น Core Web Vital

Migration Strategy: เปลี่ยนจาก JPEG/PNG เป็นฟอร์แมตใหม่

สำหรับเว็บที่มีภาพจำนวนมากอยู่แล้ว การเปลี่ยนฟอร์แมตทั้งหมดพร้อมกันอาจไม่เป็นจริง วางแผนเป็นขั้นตอน:

Phase 1: Quick Wins (สัปดาห์ที่ 1-2)

  • เปิด CDN Auto-conversion ถ้ามี (Cloudflare Polish, Imgix auto=format)
  • ไม่ต้องแก้ HTML เลย CDN จะ Serve AVIF/WebP อัตโนมัติ
  • ผลทันที: ลดขนาดภาพทั้งเว็บ 30-60%

Phase 2: LCP Optimization (สัปดาห์ที่ 2-4)

  • ระบุ LCP Element ของ 10 หน้าสำคัญที่สุด (ใช้ PageSpeed Insights หรือ Web Vitals Extension)
  • แปลงภาพ LCP เป็น AVIF + WebP Fallback ด้วย <picture>
  • เพิ่ม <link rel="preload"> สำหรับ LCP Image
  • ผลใน 2-4 สัปดาห์: LCP ลดลง 0.5-1.5s สำหรับหน้าสำคัญ

Phase 3: Full Migration (เดือนที่ 2-3)

  • ตั้ง Build Pipeline ที่แปลง AVIF + WebP อัตโนมัติเมื่อ Upload ภาพใหม่
  • Batch Convert ภาพเก่าทั้งหมด (ใช้ Script ด้านบน)
  • อัปเดต HTML Template ให้ใช้ <picture> ทุกจุด
  • ลบภาพ JPEG/PNG เก่าจาก CDN Cache

Phase 4: Monitor & Optimize (ต่อเนื่อง)

  • ตรวจ Core Web Vitals ทุกสัปดาห์ผ่าน CrUX Dashboard หรือ GSC
  • ทดสอบ Quality Settings ใหม่เมื่อ Codec Update (libavif อัปเดตบ่อย คุณภาพดีขึ้นเรื่อย)
  • ติดตาม Browser Support ของ JPEG XL พร้อมเพิ่มเข้า Chain เมื่อรองรับกว้างพอ

ข้อผิดพลาดที่พบบ่อยในการใช้ฟอร์แมตภาพสมัยใหม่

  1. ใช้ AVIF โดยไม่มี Fallback -- AVIF รองรับ ~93% แต่อีก 7% ของผู้ใช้จะเห็นภาพเสีย ต้องมี WebP + JPEG Fallback เสมอ
  2. Lazy-load LCP Image -- ทำให้ LCP ช้ามหาศาล ภาพ Hero/Above the Fold ต้องโหลดทันที ใช้ fetchpriority="high" แทน
  3. ไม่กำหนด width/height -- สร้าง CLS สูง ไม่ว่าจะใช้ฟอร์แมตอะไร
  4. Over-compress -- ตั้ง AVIF Q20-30 แล้วภาพมี Artifacts ชัดเจน ลดขนาดได้แต่ทำลาย Brand Image
  5. ไม่ตั้ง Vary: Accept -- เมื่อใช้ Content Negotiation CDN อาจ Cache AVIF แล้ว Serve ให้เบราว์เซอร์ที่ไม่รองรับ
  6. แปลง PNG ที่เป็น Vector/Graphic เป็น AVIF -- ภาพที่เป็น Logo/Icon/Illustration เรียบ SVG ให้ขนาดเล็กกว่าและ Scale ได้ดีกว่า
  7. ไม่ใช้ Responsive Images -- Serve ภาพ 1920px ให้มือถือ 375px สิ้นเปลือง Data 80%+ ใช้ srcset + sizes

อนาคตของฟอร์แมตภาพสำหรับเว็บ

แนวโน้ม สถานะ (ต้นปี 2026) ผลกระทบ
JPEG XL ใน Chrome? ยังไม่มีแผนชัดเจน แต่ Community ยังผลักดันต่อเนื่อง ถ้า Chrome รองรับ JXL จะเปลี่ยน Landscape ทันที เพราะ Lossless Recompression มีค่ามหาศาล
AV2 (AVIF v2) อยู่ในขั้น Development บีบอัดดีกว่า AV1/AVIF อีก 20-30% เข้ารหัสเร็วขึ้น
CDN Auto-format มาตรฐานแล้วสำหรับ CDN หลัก ผู้ใช้ไม่ต้องจัดการ Format เอง CDN ทำให้ ลดภาระ Dev Team
AI Image Compression เริ่มมี (เช่น Google MUSE, Meta CAE) อาจบีบอัดได้ดีกว่า AVIF ในอนาคต แต่ยังห่างจาก Production

Checklist สรุป: เปลี่ยนฟอร์แมตภาพให้เว็บเร็วขึ้นทันที

รายการ สำคัญ เสร็จ?
เปิด CDN Auto-format (ถ้ามี) เป็นขั้นตอนแรก สูง
ระบุ LCP Element ของ 10 หน้าสำคัญที่สุด สูง
แปลง LCP Image เป็น AVIF + WebP + JPEG Fallback ด้วย <picture> สูง
เพิ่ม Preload + fetchpriority="high" สำหรับ LCP Image สูง
กำหนด width/height ทุกภาพ สูง
ใช้ loading="lazy" เฉพาะภาพ Below the Fold สูง
ตั้ง Build Pipeline สำหรับ Auto-convert ภาพใหม่ กลาง
Batch Convert ภาพเก่า กลาง
ใช้ Responsive Images (srcset + sizes) กลาง
ตรวจ Alt Text, Filename สื่อความหมาย กลาง
ตั้ง Vary: Accept Header (ถ้าใช้ Content Negotiation) กลาง
Monitor Core Web Vitals ทุกสัปดาห์ ต่อเนื่อง

สรุป: AVIF + WebP + JPEG คือ Stack ที่แนะนำสำหรับเว็บไซต์ในปี 2026

จากทั้งข้อมูลทางเทคนิค Benchmark จริง และ Browser Support ในปัจจุบัน คำแนะนำสำหรับทุกเว็บไซต์คือ:

  • AVIF เป็นฟอร์แมตหลัก ขนาดเล็กที่สุดที่คุณภาพเท่ากัน รองรับ ~93% ของผู้ใช้
  • WebP เป็น Fallback แรก สำหรับเบราว์เซอร์ที่ยังไม่รองรับ AVIF
  • JPEG เป็น Fallback สุดท้าย ครอบคลุม 100%
  • JPEG XL จับตาดู พร้อมเพิ่มเข้า Stack เมื่อ Chrome รองรับ

การลงทุนเปลี่ยนฟอร์แมตภาพให้ผลตอบแทนทันที: LCP เร็วขึ้น, Page Weight ลดลง, Bandwidth ประหยัด, อันดับ SEO ดีขึ้น และ Conversion Rate สูงขึ้น ไม่มีเหตุผลที่จะไม่ทำ

บทความแนะนำ

แชร์

Recent Blog

ทำไมการปรับปรุงเว็บไซต์ E-commerce ถึงช่วยเพิ่มยอดขายได้ทันที
ทำไมการปรับปรุงเว็บไซต์ E-commerce ถึงช่วยเพิ่มยอดขายได้ทันที

เว็บของคุณไม่สามารถสร้างยอดขาย? ปรับปรุงเว็บไซต์เพื่อแก้ปัญหานี้ และเรียนรู้วิธีที่ช่วยเพิ่มประสิทธิภาพทันที...

ดูเพิ่มเติม
5 เทคนิคการออกแบบเว็บไซต์สำหรับธุรกิจ Startups ที่ช่วยเพิ่มอัตราการแปลงลูกค้า
5 เทคนิคออกแบบเว็บไซต์ Startup ที่เพิ่มยอดขาย 2026

เคยรู้สึกไหมว่าเว็บไซต์ของคุณไม่สามารถดึงดูดลูกค้าได้? ลองศึกษา 5 เทคนิคที่ช่วยให้คุณสามารถปรับปรุงเว็บไซต์ให้ดียิ่งขึ้นและเพิ่มอัตราการแปลงลูกค้าได้อย่างแท้จริง อ่านต่อ...

ดูเพิ่มเติม
ทำไมเลือก Webflow Design Development เพื่อเว็บไซต์ที่ใช้งานง่าย?
ทำไมเลือก Webflow Design Development เพื่อเว็บไซต์ที่ใช้งานง่าย?

เคยรู้สึกหงุดหงิดเมื่อเว็บไซต์โหลดช้าใช่ไหม? ปัญหานี้สามารถแก้ไขได้ด้วยการออกแบบที่ถูกต้อง อ่านต่อเพื่อค้นหาวิธีที่คุณจะเปลี่ยนประสบการณ์ผู้ใช้!

ดูเพิ่มเติม