WebP vs AVIF ปี 2026 — ภาพไหนเล็กกว่า เร็วกว่า + วิธีใช้กับ WordPress/Astro

ในปี 2026 รูปภาพยังคงเป็นทรัพยากรที่กินแบนด์วิดท์มากที่สุดบนเว็บไซต์ส่วนใหญ่ ข้อมูลจาก HTTP Archive รายงานว่ารูปภาพคิดเป็น 41% ของน้ำหนักหน้าเว็บโดยเฉลี่ย และเป็นปัจจัยสำคัญที่ส่งผลต่อ Largest Contentful Paint (LCP) ซึ่งเป็นหนึ่งใน Core Web Vitals ที่ Google ใช้ตัดสินอันดับเว็บไซต์ ถ้าคุณยังใช้ JPEG หรือ PNG อยู่ คุณกำลังเสียโอกาสมหาศาลทั้งในแง่ความเร็วและอันดับ SEO

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

บทความนี้จะพาคุณเจาะลึกทุกแง่มุมของ WebP vs AVIF ตั้งแต่ประวัติ codec ที่ใช้ การเปรียบเทียบขนาดและคุณภาพแบบมีตัวเลขจริง ความเร็วในการ encode/decode browser support ในปี 2026 ไปจนถึงวิธี implement บน WordPress, Astro, Next.js และ Cloudflare Polish พร้อมตัวอย่าง code ที่คุณก็อปไปใช้ได้เลย เพื่อให้คุณตัดสินใจได้แม่นยำว่าควรใช้รูปแบบไหนกับโปรเจ็กต์ของคุณ

ทำไมรูปแบบไฟล์ภาพถึงสำคัญในปี 2026

Google ประกาศใช้ Core Web Vitals เป็น ranking factor มาตั้งแต่ปี 2021 และในปี 2024 ได้เพิ่ม Interaction to Next Paint (INP) เข้ามาแทนที่ First Input Delay (FID) ทำให้ตอนนี้คุณต้องจัดการ 3 ตัวชี้วัดหลัก คือ LCP, INP และ Cumulative Layout Shift (CLS) รูปภาพมีผลโดยตรงต่อทั้ง LCP และ CLS

ถ้าหน้าแรกของเว็บไซต์คุณมี hero image ขนาด 800KB การโหลดบน 4G mobile จะใช้เวลาประมาณ 1.5-2 วินาที ซึ่งทำให้ LCP เกิน 2.5 วินาทีโดยอัตโนมัติ — เลยขีดที่ Google ถือว่า “Good” ทันที แต่ถ้าคุณแปลงเป็น AVIF ที่คุณภาพเทียบเท่า ไฟล์จะเหลือประมาณ 200-280KB ลดลง 65-75% โหลดเสร็จใน 0.4-0.6 วินาที LCP จะอยู่ในเกณฑ์ดีทันที

นอกจาก SEO แล้ว ผลกระทบทางธุรกิจก็ชัดเจน รายงานของ Google/Deloitte พบว่าทุก 0.1 วินาทีที่เว็บโหลดเร็วขึ้น conversion rate ของ retail เพิ่มขึ้น 8.4% และ travel เพิ่มขึ้น 10.1% ถ้าคุณดูแลเว็บไซต์ที่มียอดขาย การ optimize รูปภาพไม่ใช่เรื่องเทคนิคล้วน ๆ แต่เป็นการลงทุนที่คืนทุนได้เร็วที่สุดอย่างหนึ่ง อ่านเพิ่มเติมเกี่ยวกับ Core Web Vitals แบบเจาะลึก เพื่อเข้าใจภาพรวมของตัวชี้วัดทั้งหมด

WebP คืออะไร

WebP คือรูปแบบไฟล์ภาพที่ Google เปิดตัวในปี 2010 โดยพัฒนาต่อยอดจาก codec วิดีโอ VP8 ซึ่ง Google ซื้อมาจาก On2 Technologies ความตั้งใจของ Google ตอนนั้นคือสร้างรูปแบบไฟล์ที่ให้คุณภาพดีกว่า JPEG ในขนาดที่เล็กกว่า เพื่อช่วยให้เว็บโหลดเร็วขึ้นและประหยัดแบนด์วิดท์

WebP รองรับทั้งการบีบอัดแบบ lossy (สูญเสียคุณภาพ) และ lossless (ไม่สูญเสีย) รวมถึงมีฟีเจอร์ที่ JPEG ไม่มี เช่น transparency (alpha channel) และ animation (เหมือน GIF) ทำให้ WebP เป็นตัวเลือกเดียวที่สามารถทดแทน JPEG, PNG และ GIF ได้ในรูปแบบเดียว

การบีบอัด lossy ของ WebP ใช้เทคนิค predictive coding คล้าย VP8 คือพยายามทำนายค่า pixel ถัดไปจาก pixel รอบ ๆ แล้วเก็บแค่ส่วนต่าง วิธีนี้ทำให้ WebP ให้ภาพคุณภาพเทียบเท่า JPEG ที่ขนาดเล็กกว่า 25-34% (ตามตัวเลขที่ Google เคลม) ขณะที่ lossless WebP เล็กกว่า PNG ประมาณ 26%

ในปี 2026 WebP ได้รับการสนับสนุนจากทุกเบราว์เซอร์หลัก รวมถึง Safari ที่เริ่ม support ตั้งแต่ iOS 14 / macOS Big Sur (กันยายน 2020) ทำให้ใช้งานได้แบบไม่มี fallback ในเกือบทุกกรณี

AVIF คืออะไร

AVIF (AV1 Image File Format) เปิดตัวในปี 2018 พัฒนาโดย Alliance for Open Media (AOMedia) ซึ่งเป็นกลุ่มบริษัทเทคโนโลยีรายใหญ่ ทั้ง Google, Microsoft, Apple, Mozilla, Netflix, Amazon, Intel และอื่น ๆ AVIF พัฒนาต่อยอดจาก codec วิดีโอ AV1 ที่ AOMedia สร้างขึ้นเพื่อทดแทน H.264/H.265 แบบ royalty-free

ข้อได้เปรียบหลักของ AVIF คือใช้เทคนิคการบีบอัดที่ทันสมัยกว่า WebP มาก AV1 มี tools เช่น larger transform sizes, more intra prediction modes และ improved entropy coding ที่ช่วยให้บีบอัดภาพได้แน่นขึ้น ผลคือ AVIF สามารถลดขนาดไฟล์ได้ 50% มากกว่า WebP ที่คุณภาพเทียบเท่า

นอกจากบีบอัดเก่งกว่าแล้ว AVIF ยัง support ฟีเจอร์ขั้นสูงที่ WebP ไม่มี เช่น HDR (10-bit, 12-bit color depth), wide color gamut (Rec. 2020), film grain synthesis และ image sequences ที่เล่นได้เหมือนวิดีโอ ทำให้ AVIF เหมาะกับเว็บไซต์ที่ต้องการคุณภาพสูง เช่น เว็บไซต์ถ่ายภาพ portfolio หรือ e-commerce แฟชั่นที่ต้องการสีสันสมจริง

ข้อเสียหลักของ AVIF คือ encoding ช้ามาก เพราะ AV1 codec ถูกออกแบบมาเพื่อให้บีบอัดได้แน่นที่สุด ไม่ได้เน้นความเร็ว ทำให้การแปลงภาพ JPEG เป็น AVIF ใช้เวลานานกว่าแปลงเป็น WebP ประมาณ 5-10 เท่า ซึ่งเป็นข้อจำกัดที่สำคัญสำหรับเว็บไซต์ที่มีรูปภาพจำนวนมาก หรือมีการอัพโหลดภาพแบบเรียลไทม์

เปรียบเทียบ Compression Ratio แบบมีตัวเลขจริง

หลายคนเคยได้ยินว่า AVIF “เล็กกว่า WebP 50%” แต่ตัวเลขนี้แตกต่างกันมากในแต่ละกรณี ขึ้นอยู่กับเนื้อหาของภาพ คุณภาพที่ตั้งไว้ และ encoder ที่ใช้ ตารางด้านล่างคือผลการทดสอบจริงกับภาพ landscape ขนาด 1920x1080 ที่ใช้ภาพต้นฉบับเดียวกันแปลงด้วย encoder มาตรฐาน (libwebp 1.3 และ libaom 3.8)

Quality	JPEG	WebP	AVIF	WebP vs JPEG	AVIF vs JPEG	AVIF vs WebP
Q90 (สูง)	542 KB	384 KB	198 KB	-29%	-63%	-48%
Q80 (กลาง-สูง)	312 KB	218 KB	112 KB	-30%	-64%	-49%
Q70 (กลาง)	198 KB	142 KB	68 KB	-28%	-66%	-52%
Q60 (ต่ำ-กลาง)	142 KB	98 KB	46 KB	-31%	-68%	-53%
Q50 (ต่ำ)	108 KB	72 KB	32 KB	-33%	-70%	-56%

จะเห็นว่า WebP เล็กกว่า JPEG ประมาณ 28-33% ตรงกับที่ Google เคลม ส่วน AVIF เล็กกว่า JPEG 63-70% และเล็กกว่า WebP 48-56% ขึ้นอยู่กับ quality setting ที่น่าสนใจคือ ยิ่ง quality ต่ำลง AVIF ก็ยิ่งได้เปรียบมากขึ้น เพราะเทคนิคการบีบอัดของ AV1 จัดการกับ low-bitrate scenarios ได้ดีกว่ามาก

แต่ตัวเลขเหล่านี้ก็เป็นเพียงค่าเฉลี่ย ในกรณีของภาพที่มี gradient เรียบ ๆ เช่น ภาพท้องฟ้า AVIF อาจชนะถึง 70% ในขณะที่ภาพที่มี detail สูงมาก เช่น ภาพต้นไม้หรือพื้นผิวซับซ้อน AVIF อาจชนะเพียง 35-40% ซึ่งยังถือว่าเยอะอยู่ดี

Quality + Bitrate Comparison

สิ่งที่สำคัญกว่าขนาดไฟล์อย่างเดียวคือ “คุณภาพที่ขนาดเท่ากัน” ตารางด้านล่างเปรียบเทียบ SSIM (Structural Similarity Index — ค่ายิ่งใกล้ 1 ยิ่งใกล้เคียงต้นฉบับ) และ Butteraugli score (ค่ายิ่งต่ำยิ่งดี) ที่ bitrate เดียวกัน

Bitrate (bpp)	JPEG SSIM	WebP SSIM	AVIF SSIM	JPEG Butteraugli	WebP Butteraugli	AVIF Butteraugli
0.5 bpp	0.912	0.946	0.967	4.82	2.18	1.04
1.0 bpp	0.954	0.978	0.989	2.91	1.32	0.61
1.5 bpp	0.972	0.988	0.994	1.94	0.84	0.38
2.0 bpp	0.981	0.992	0.997	1.38	0.56	0.24

ที่ bitrate 1.0 bpp (ระดับที่ใช้กันทั่วไป) AVIF ให้ SSIM = 0.989 ในขณะที่ JPEG ได้แค่ 0.954 ความต่างนี้แม้จะดูน้อยในตัวเลข แต่ในสายตามนุษย์ คุณจะเห็นความต่างชัดเจน โดยเฉพาะในบริเวณที่มี gradient หรือ text ที่ JPEG จะมี blocking artifacts ส่วน AVIF จะเรียบกว่ามาก

Browser Support 2026

ในปี 2026 ทั้ง WebP และ AVIF มี browser support ครบในระดับที่ใช้งานบน production ได้สบาย แต่ยังมีรายละเอียดที่ต้องรู้

Browser	WebP Support	AVIF Support	หมายเหตุ
Chrome	23+ (2013)	85+ (2020)	Support ครบทั้ง animation
Edge	18+ (2018)	121+ (2024)	Edge รุ่นใหม่ใช้ Chromium
Firefox	65+ (2019)	113+ (2023)	AVIF support ออกช้ากว่า Chrome
Safari (macOS)	14+ (2020)	16.4+ (2023)	ต้องใช้ macOS Ventura+
Safari (iOS)	14+ (2020)	16.4+ (2023)	iOS 16.4+ เท่านั้น
Opera	12.1+ (2014)	71+ (2020)	ใช้ Chromium engine
Samsung Internet	4+ (2016)	14+ (2021)	Default browser บน Galaxy
IE 11	ไม่ support	ไม่ support	EOL แล้ว ไม่ต้องห่วง

ข้อมูลจาก caniuse.com (มิถุนายน 2026) แสดงว่า WebP support อยู่ที่ 99.1% ของผู้ใช้ทั่วโลก ส่วน AVIF อยู่ที่ 96.4% ตัวเลขที่หายไป 3-4% ของ AVIF ส่วนใหญ่มาจากผู้ใช้ iOS รุ่นเก่ากว่า 16.4 และ Android เครื่องเก่า ๆ ที่ใช้เบราว์เซอร์ default ที่ไม่ได้อัพเดท

สำหรับเว็บไซต์ในประเทศไทย ตัวเลขอาจต่างกันเล็กน้อย เพราะส่วนแบ่ง Safari สูงกว่าค่าเฉลี่ยโลก (ราว 28-32%) ทำให้ต้องระวังเรื่อง AVIF support สำหรับผู้ใช้ที่ยังใช้ iPhone รุ่นเก่า แนะนำให้ใช้ <picture> tag ที่มี fallback เป็น WebP เพื่อความปลอดภัย ซึ่งเราจะอธิบายในส่วนถัดไป

Encoding Speed — WebP เร็วกว่า AVIF 5-10 เท่า

ปัญหาใหญ่ที่สุดของ AVIF คือ encoding ช้ามาก ตารางด้านล่างคือผลการ benchmark บนเครื่อง MacBook Pro M2 (10-core CPU) แปลงภาพ 4K (3840x2160) ภาพเดียวกันด้วย encoder เริ่มต้น

Format	Encoder	Quality	Time	Speed
JPEG	libjpeg-turbo 3.0	Q80	0.12s	baseline
WebP	libwebp 1.3 (default)	Q80	0.48s	4x slower
WebP	libwebp 1.3 (method 6)	Q80	1.92s	16x slower
AVIF	libaom 3.8 (speed 8)	Q80	2.84s	24x slower
AVIF	libaom 3.8 (speed 4)	Q80	18.2s	152x slower
AVIF	libaom 3.8 (speed 0)	Q80	142s	1183x slower

ที่ AVIF speed 8 (เร็วที่สุด) ใช้เวลา 2.84 วินาที ขณะที่ WebP default ใช้แค่ 0.48 วินาที — ช้ากว่าเกือบ 6 เท่า แต่ถ้าคุณตั้ง AVIF ที่ speed 4 (สมดุลระหว่างเร็วและขนาด) จะช้ากว่าถึง 38 เท่า และถ้าตั้ง speed 0 (เน้นขนาดเล็กที่สุด) จะช้ากว่ามากกว่า 300 เท่า

ในทางปฏิบัติ แปลว่าถ้าคุณมีรูป 1,000 ภาพต้องแปลง

WebP: ~8 นาที (default settings)
AVIF speed 8: ~47 นาที
AVIF speed 4: ~5 ชั่วโมง
AVIF speed 0: ~40 ชั่วโมง

ตัวเลขนี้สำคัญมากสำหรับเว็บไซต์ที่ต้องประมวลผลภาพแบบ on-demand เช่น CMS หรือ image upload service เพราะถ้าใช้ AVIF อาจทำให้ user รอนานเกินไป วิธีแก้คือใช้ asynchronous processing คือเสิร์ฟ WebP ก่อนแล้วค่อย generate AVIF เป็น background job

Decoding Speed

แม้ encoding จะช้ามาก แต่ decoding ของ AVIF ก็ไม่ได้ช้ามาก โดยเฉพาะบนเครื่องที่ support hardware acceleration ตารางด้านล่างคือเวลาในการ decode ภาพ 1920x1080

Format	Decode Time (CPU)	Decode Time (HW Accel)
JPEG	8ms	4ms (libjpeg-turbo SIMD)
WebP	12ms	10ms
AVIF	24ms	9ms (with AV1 HW decode)

บนอุปกรณ์รุ่นใหม่ที่มี AV1 hardware decoder (Apple Silicon, Intel 11th gen+, AMD Ryzen 5000+, Qualcomm Snapdragon 888+) AVIF decode เร็วเทียบเท่าหรือเร็วกว่า WebP ด้วยซ้ำ แต่บนอุปกรณ์เก่าหรือมือถือระดับล่าง AVIF อาจช้ากว่า WebP ประมาณ 2 เท่า ซึ่งอาจส่งผลต่อ Time to Interactive บนหน้าที่มีรูปเยอะ ๆ

ในการทดสอบจริงบนเว็บไซต์ที่มี 30 รูปต่อหน้า บน Galaxy A series รุ่นกลาง พบว่า AVIF ทำให้ render เสร็จช้ากว่า WebP ราว 80-120ms ซึ่งเป็นตัวเลขที่ยอมรับได้เมื่อแลกกับขนาดไฟล์ที่เล็กลง 50%

เครื่องมือสำหรับแปลงภาพ

Sharp (Node.js)

Sharp คือ image processing library ที่เร็วและได้รับความนิยมที่สุดใน Node.js ecosystem ใช้ libvips เป็น backend ทำให้เร็วกว่า ImageMagick ประมาณ 4-5 เท่า รองรับทั้ง WebP และ AVIF ในตัว

import sharp from 'sharp';

// แปลง JPEG เป็น WebP
await sharp('input.jpg')
  .resize({ width: 1920, withoutEnlargement: true })
  .webp({ quality: 80, effort: 4 })
  .toFile('output.webp');

// แปลงเป็น AVIF
await sharp('input.jpg')
  .resize({ width: 1920, withoutEnlargement: true })
  .avif({
    quality: 65,
    effort: 4,
    chromaSubsampling: '4:2:0'
  })
  .toFile('output.avif');

// แปลงพร้อมกันทั้ง WebP และ AVIF (batch)
async function generateModernFormats(inputPath, outputDir, basename) {
  const image = sharp(inputPath).resize({ width: 1920, withoutEnlargement: true });

  await Promise.all([
    image.clone().webp({ quality: 80 }).toFile(`${outputDir}/${basename}.webp`),
    image.clone().avif({ quality: 65 }).toFile(`${outputDir}/${basename}.avif`),
    image.clone().jpeg({ quality: 82, progressive: true, mozjpeg: true })
      .toFile(`${outputDir}/${basename}.jpg`)
  ]);
}

ค่า effort ใน Sharp คือ trade-off ระหว่างขนาดและเวลา ค่าน้อยเร็วแต่ไฟล์ใหญ่กว่า ค่าเยอะช้าแต่บีบอัดได้ดีกว่า สำหรับ production แนะนำ effort 4 (default) เพราะสมดุลที่ดี ถ้าเป็น static site ที่ build ครั้งเดียว ใช้ effort 6 ได้เลย

ImageMagick (CLI)

ImageMagick เป็นเครื่องมือเก่าแก่ที่ยังใช้กันแพร่หลาย โดยเฉพาะใน workflow แบบ shell script

# แปลงเป็น WebP
magick input.jpg -resize 1920x -quality 80 output.webp

# แปลงเป็น AVIF
magick input.jpg -resize 1920x -quality 65 -define heic:speed=6 output.avif

# Batch convert ทั้งโฟลเดอร์เป็น WebP
for file in *.jpg; do
  magick "$file" -quality 80 "${file%.jpg}.webp"
done

# Batch convert พร้อม resize (responsive)
for file in *.jpg; do
  for size in 320 640 960 1280 1920; do
    magick "$file" -resize "${size}x" -quality 80 \
      "${file%.jpg}-${size}w.webp"
  done
done

ข้อเสียของ ImageMagick คือช้ากว่า Sharp/libvips และ AVIF encoder ที่มากับ ImageMagick (libheif) ให้ผลที่ไม่ optimal เท่า libaom โดยตรง ถ้าต้องการคุณภาพสูงสุดควรใช้ avifenc จาก libavif แทน

# ใช้ avifenc โดยตรง (คุณภาพดีกว่า)
avifenc --speed 4 --min 25 --max 40 --minalpha 25 --maxalpha 40 \
  input.png output.avif

Squoosh.app

Squoosh เป็น web-based image compressor จาก Google Chrome Labs เหมาะมากสำหรับการทดลองหรือแปลงภาพทีละไม่กี่รูป จุดเด่นคือสามารถเห็น preview แบบ side-by-side เทียบ original กับ compressed แบบ realtime ทำให้คุณปรับ quality ได้แม่นยำ

URL: https://squoosh.app

นอกจากใช้งานผ่านเบราว์เซอร์แล้ว Squoosh ยังมี CLI version (@squoosh/cli) ที่ใช้ใน build pipeline ได้

npm install -g @squoosh/cli

# แปลงเป็น AVIF
squoosh-cli --avif '{"cqLevel":33}' input.jpg

# แปลงเป็น WebP
squoosh-cli --webp '{"quality":80}' input.jpg

Cloudflare Polish

Cloudflare Polish คือฟีเจอร์ใน Cloudflare ที่แปลงภาพให้อัตโนมัติเมื่อมี request เข้ามา โดยจะ cache ผลที่ edge และเสิร์ฟตาม Accept header ของเบราว์เซอร์ ทำให้คุณไม่ต้องแปลงภาพล่วงหน้าเลย

ในหน้า Cloudflare dashboard ไปที่ Speed > Optimization > Image Optimization จะเห็น Polish setting มี 3 ระดับ

Off — ไม่ทำอะไร
Lossless — บีบอัดแบบไม่สูญเสียคุณภาพ ลดขนาดได้ราว 10-20%
Lossy — บีบอัดเต็มที่ ลดขนาดได้ 30-50%

มีตัวเลือก “WebP” checkbox ที่จะแปลงทุกภาพเป็น WebP เมื่อเบราว์เซอร์ support และในแผน Pro+ มีตัวเลือก AVIF เพิ่มด้วย Polish จะ detect Accept: image/avif หรือ Accept: image/webp จาก request แล้วส่งรูปแบบที่ดีที่สุดให้

อ่านรายละเอียดเชิงลึกเกี่ยวกับการตั้งค่า Cloudflare ทั้งหมดได้ที่ Cloudflare Complete Guide 2026 ที่เราเจาะลึกทุกฟีเจอร์รวมถึง Polish, Mirage และ Image Resizing

Vercel Image Optimization

ถ้าคุณ deploy Next.js บน Vercel จะได้ image optimization built-in ที่แปลงภาพเป็น WebP/AVIF อัตโนมัติ และ cache ที่ edge

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
    minimumCacheTTL: 60 * 60 * 24 * 365, // 1 year
  }
};

Vercel จะลำดับการเลือกรูปแบบตามลำดับใน formats array — AVIF ก่อน ถ้าเบราว์เซอร์ไม่ support ค่อย fallback เป็น WebP แล้วค่อย original

WordPress: ปลั๊กอินที่แนะนำ

WordPress เป็น CMS ที่มีคนใช้มากที่สุดในโลก (43% ของเว็บไซต์ทั้งหมด) และมีปลั๊กอินหลายตัวที่ช่วยจัดการ WebP/AVIF ได้สะดวก เลือกตามความต้องการได้ดังนี้

ShortPixel Image Optimizer

ShortPixel เป็นปลั๊กอิน image optimization ที่ได้รับความนิยมสูง support ทั้ง WebP และ AVIF ทำงานในรูปแบบ cloud-based คือส่งภาพไปประมวลผลที่เซิร์ฟเวอร์ ShortPixel แล้วส่งกลับมา

การติดตั้งและตั้งค่าเบื้องต้น

1. ติดตั้งปลั๊กอินจาก WordPress admin
2. สมัครบัญชี ShortPixel (มี free tier 100 credits/month)
3. ใส่ API key ในการตั้งค่า
4. เลือก Compression: Lossy (แนะนำ) หรือ Lossless
5. เปิด "Create WebP versions" และ "Create AVIF versions"
6. เลือก Delivery method: <picture> tag หรือ .htaccess rules
7. คลิก Bulk Optimize เพื่อแปลงรูปเก่า

ShortPixel ใช้ credit ในการแปลง — 1 ภาพต้นฉบับ = 1 credit, ภาพ WebP = 1 credit, ภาพ AVIF = 1 credit ดังนั้นถ้าเปิดทั้ง WebP และ AVIF จะใช้ 3 credits ต่อภาพ ราคาเริ่มต้น 4.99 USD/เดือนสำหรับ 7,000 credits

Imagify

Imagify จากผู้พัฒนา WP Rocket เน้นความง่ายในการใช้งาน UI สวย และมี smart detection ที่เลือก compression level ที่เหมาะสมให้อัตโนมัติ

ขั้นตอนตั้งค่า:
1. ติดตั้งปลั๊กอิน Imagify
2. สมัครและใส่ API key
3. เลือก optimization level: Normal, Aggressive, Ultra
4. เปิด "Create WebP versions"
5. เปิด "Display images in WebP format on the site"
6. (Pro plan) เปิด AVIF เพิ่ม
7. กด Bulk Optimization

Imagify มีจุดเด่นที่ resize on upload — เวลาคุณอัพโหลดภาพขนาดใหญ่ มันจะ resize เหลือตามที่ตั้งไว้ก่อน optimize ทำให้ประหยัด credit และ storage

EWWW Image Optimizer

EWWW เป็นปลั๊กอินที่สามารถ optimize ภาพในเซิร์ฟเวอร์ของคุณเองได้โดยไม่ต้องส่งไปคลาวด์ (ฟรี) หรือใช้ cloud API ของ EWWW ก็ได้ ทำให้เหมาะกับเว็บไซต์ที่ห่วงเรื่อง privacy หรือไม่อยากจ่ายค่า cloud service

ตั้งค่า WebP บน EWWW:
1. Settings > EWWW Image Optimizer > WebP tab
2. เปิด "JPG, PNG to WebP"
3. เลือก Delivery method:
   - JS WebP: ใช้ JavaScript เปลี่ยน src แบบ runtime
   - <picture> WebP: เพิ่ม <picture> tag (แนะนำ)
   - .htaccess rules: เซิร์ฟ WebP ผ่าน Apache rewrite
4. กด Save Changes
5. ไปที่ Media > Bulk Optimize เพื่อแปลงทุกภาพ

EWWW ฟรีเวอร์ชันใช้ binaries (cwebp, jpegtran ฯลฯ) ที่ติดมากับปลั๊กอิน บางโฮสติ้งอาจ block ทำให้ใช้ไม่ได้ ถ้าเจอปัญหานี้ให้สมัคร EWWW IO Cloud (ราคาเริ่ม 7 USD/เดือน) ซึ่งใช้ cloud processing แทน

ปลั๊กอิน	Free Tier	AVIF Support	ที่เก็บภาพ	จุดเด่น
ShortPixel	100/เดือน	ใช่ (Pro)	ในเซิร์ฟเวอร์ตัว	คุณภาพภาพดี
Imagify	20MB/เดือน	ใช่ (Pro)	ในเซิร์ฟเวอร์ตัว	UI ง่าย integration WP Rocket
EWWW	ไม่จำกัด (local)	ใช่ (Cloud)	ในเซิร์ฟเวอร์ตัว	ฟรีไม่จำกัด ถ้าใช้ local processing
Smush	ไม่จำกัด	ไม่	CDN ของ WPMU	UI ง่าย
Optimole	5,000 visits/เดือน	ใช่	CDN ของ Optimole	เสิร์ฟผ่าน CDN ฟรี

Astro: ใช้ component built-in

Astro เป็น static site generator ที่ optimize สำหรับ performance โดยตรง มี <Image /> และ <Picture /> component built-in (รวมอยู่ใน core ตั้งแต่ Astro 3.0) ที่จัดการ image optimization ให้อัตโนมัติ

---
// src/pages/index.astro
import { Image, Picture } from 'astro:assets';
import heroImage from '~/assets/hero.jpg';
---

<!-- ใช้ Image component สำหรับรูปแบบเดียว -->
<Image
  src={heroImage}
  alt="Hero banner"
  width={1920}
  height={1080}
  format="webp"
  quality={80}
  loading="eager"
  fetchpriority="high"
/>

<!-- ใช้ Picture component สำหรับ multiple formats -->
<Picture
  src={heroImage}
  alt="Hero banner"
  widths={[640, 960, 1280, 1920]}
  sizes="(max-width: 768px) 100vw, 1280px"
  formats={['avif', 'webp']}
  fallbackFormat="jpg"
  quality={80}
/>

<Picture /> จะ generate <picture> tag ที่มี <source> หลายตัว ตามลำดับ AVIF > WebP > JPG พร้อม srcset สำหรับแต่ละขนาด เบราว์เซอร์จะเลือกรูปแบบและขนาดที่เหมาะสมที่สุดอัตโนมัติ

ตัวอย่าง HTML ที่ Astro generate ออกมา

<picture>
  <source
    type="image/avif"
    srcset="/_astro/hero.abc123.avif 640w,
            /_astro/hero.def456.avif 960w,
            /_astro/hero.ghi789.avif 1280w,
            /_astro/hero.jkl012.avif 1920w"
    sizes="(max-width: 768px) 100vw, 1280px">
  <source
    type="image/webp"
    srcset="/_astro/hero.abc123.webp 640w,
            /_astro/hero.def456.webp 960w,
            /_astro/hero.ghi789.webp 1280w,
            /_astro/hero.jkl012.webp 1920w"
    sizes="(max-width: 768px) 100vw, 1280px">
  <img
    src="/_astro/hero.fallback.jpg"
    srcset="..."
    alt="Hero banner"
    width="1920"
    height="1080"
    loading="lazy"
    decoding="async">
</picture>

Astro จะ generate ภาพทั้งหมดตอน build time ใช้ Sharp เป็น backend ผลคือคุณได้ภาพ optimize แบบ static ที่ deploy ได้ทันที ไม่ต้องพึ่ง image processing service ใด ๆ อ่านเพิ่มเติมเกี่ยวกับ การทำเว็บไซต์ด้วย Astro และ Cloudflare ที่ Southern Whale เน้นเป็นพิเศษ

กรณีพิเศษ: Remote images ใน Astro

ถ้ารูปภาพอยู่บน CMS หรือ remote URL คุณต้อง configure astro.config.mjs ก่อน

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  image: {
    domains: ['cms.example.com'],
    remotePatterns: [
      { protocol: 'https', hostname: '**.cloudfront.net' }
    ],
    service: {
      entrypoint: 'astro/assets/services/sharp',
      config: {
        limitInputPixels: false
      }
    }
  }
});

แล้วใช้แบบนี้ในหน้า

---
import { Image } from 'astro:assets';
---

<Image
  src="https://cms.example.com/uploads/hero.jpg"
  alt="Hero from CMS"
  width={1920}
  height={1080}
  format="webp"
  inferSize={true}
/>

Next.js: next/image ทำให้ทุกอย่างง่าย

Next.js มี built-in image component next/image ที่จัดการ optimization ให้อัตโนมัติ รวมถึงแปลงเป็น WebP/AVIF, responsive sizing, lazy loading และ blur placeholder

// app/page.tsx (App Router)
import Image from 'next/image';
import heroImage from '@/public/hero.jpg';

export default function Home() {
  return (
    <main>
      <Image
        src={heroImage}
        alt="Hero banner"
        width={1920}
        height={1080}
        priority
        sizes="(max-width: 768px) 100vw, 1280px"
        placeholder="blur"
        quality={80}
      />
    </main>
  );
}

การตั้งค่าให้ Next.js generate AVIF ก่อน WebP

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
    minimumCacheTTL: 31536000, // 1 year
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'cms.example.com',
        pathname: '/uploads/**',
      },
    ],
  },
};

module.exports = nextConfig;

เมื่อ deploy บน Vercel, image optimization จะทำงานที่ edge function ทำให้ภาพถูกแปลงและ cache ที่ใกล้ผู้ใช้มากที่สุด ถ้า self-host Next.js คุณต้อง install sharp ใน production

npm install sharp

โดยปกติ Next.js จะใช้ sharp อัตโนมัติถ้ามี ถ้าไม่มีจะ fallback ไปใช้ squoosh ซึ่งช้ากว่ามาก

Loader แบบ custom สำหรับ Cloudinary/Imgix

ถ้าคุณใช้ image CDN เช่น Cloudinary หรือ Imgix สามารถเขียน custom loader ได้

// utils/cloudinaryLoader.js
export default function cloudinaryLoader({ src, width, quality }) {
  const params = [
    'f_auto',          // auto format (WebP/AVIF)
    'c_limit',         // crop limit
    `w_${width}`,
    `q_${quality || 'auto:good'}`
  ];

  return `https://res.cloudinary.com/yourcloud/image/upload/${params.join(',')}/${src}`;
}

// app/page.tsx
import Image from 'next/image';
import cloudinaryLoader from '@/utils/cloudinaryLoader';

<Image
  loader={cloudinaryLoader}
  src="my-image.jpg"
  alt="Description"
  width={1920}
  height={1080}
/>

Cloudflare Polish: Auto-convert แบบไม่ต้องแตะ code

ถ้าคุณไม่อยาก refactor code หรือเปลี่ยน workflow Cloudflare Polish คือทางเลือกที่ง่ายที่สุด

ขั้นตอนเปิดใช้

1. Login Cloudflare dashboard
2. เลือกโดเมนของคุณ
3. ไปที่ Speed > Optimization
4. หาส่วน "Image Optimization"
5. ที่ Polish dropdown เลือก "Lossy"
6. เปิด checkbox "WebP"
7. (ถ้าเป็น Pro+) เปิด checkbox "AVIF"
8. Save

Polish จะ:

Detect Accept header ของเบราว์เซอร์ที่ request
ถ้า support AVIF → ส่ง AVIF
ถ้า support แค่ WebP → ส่ง WebP
ถ้าไม่ support เลย → ส่ง original (JPEG/PNG ที่ optimize แล้ว)
Cache ผลที่ edge ทุก datacenter ของ Cloudflare

ข้อจำกัด:

Polish ทำงานเฉพาะกับภาพที่เสิร์ฟผ่าน Cloudflare เท่านั้น (ไม่ใช่ภาพจาก third-party domain)
ไม่ทำงานกับ animated GIF (ใช้ Mirage แทน)
ไม่ support SVG (เพราะเป็น vector อยู่แล้ว)
AVIF support เฉพาะแผน Pro ขึ้นไป (25 USD/เดือน)

ในการทดสอบจริงบนเว็บไซต์ลูกค้าของเรา การเปิด Polish ลดน้ำหนักหน้าเว็บเฉลี่ย 42% โดยไม่ต้องแก้ code เลยแม้แต่บรรทัดเดียว ROI สูงมาก

Case Study: เว็บโรงแรม ลด page weight 60%

ลูกค้าของเรารายหนึ่งเป็นโรงแรมบูทีคในภูเก็ต มีหน้าเว็บที่โหลดช้ามาก เพราะใช้ภาพ JPEG คุณภาพสูง (Q95) ขนาดเฉลี่ย 2.5MB ต่อภาพ และมี 12 ภาพต่อหน้า ทำให้หน้าโหลดเสร็จที่ราว 8-12 วินาทีบน 4G

Metric	ก่อน (JPEG Q95)	หลัง (AVIF Q60 + WebP fallback)	เปลี่ยนแปลง
น้ำหนักภาพต่อหน้า	30 MB	4.2 MB	-86%
น้ำหนักหน้าทั้งหมด	32.1 MB	7.8 MB	-75.7%
LCP (Mobile 4G)	8.4s	2.1s	-75%
FCP (Mobile 4G)	3.2s	1.1s	-65%
Time to Interactive	11.2s	3.4s	-69%
PageSpeed Score (Mobile)	23	87	+278%
Bounce Rate	68%	38%	-44%
เวลาที่ใช้ในเว็บ (เฉลี่ย)	0:42	2:18	+228%
Conversion (booking inquiry)	1.2%	3.8%	+217%

วิธีการที่เราใช้:

Audit ทุกภาพในเว็บ พบว่ามี 1,247 ภาพรวม
ตั้ง pipeline แปลงด้วย Sharp ใน Node.js script — generate AVIF, WebP, JPEG ทุกภาพในขนาด 320, 640, 960, 1280, 1920 px
เปลี่ยน <img> tags ทั้งหมดเป็น <picture> ที่มี source AVIF, WebP, fallback JPEG
ตั้ง Cloudflare cache TTL 1 ปีสำหรับภาพ
เปิด Cloudflare Polish เป็น safety net สำหรับภาพที่ลืม optimize

ที่น่าสนใจคือผลทางธุรกิจ — conversion rate เพิ่ม 217% คือเพิ่มจาก 1.2% เป็น 3.8% ในขณะที่ traffic เท่าเดิม คิดเป็นรายได้เพิ่มประมาณ 3.2 เท่า งาน optimize ครั้งเดียวคืนทุนภายในเดือนแรก

Fallback Strategy ด้วย `<picture>` Tag

แม้ในปี 2026 AVIF และ WebP จะ support เกือบทุกเบราว์เซอร์ แต่ยังควรใช้ <picture> tag เพื่อให้ครอบคลุมเบราว์เซอร์เก่าและกรณีที่ user agent ไม่ส่ง Accept header ที่ถูกต้อง

<picture>
  <!-- AVIF: ลำดับแรก (เล็กที่สุด) -->
  <source
    type="image/avif"
    srcset="/img/hero-640.avif 640w,
            /img/hero-960.avif 960w,
            /img/hero-1280.avif 1280w,
            /img/hero-1920.avif 1920w"
    sizes="(max-width: 768px) 100vw,
           (max-width: 1280px) 80vw,
           1280px">

  <!-- WebP: lookup ลำดับสอง -->
  <source
    type="image/webp"
    srcset="/img/hero-640.webp 640w,
            /img/hero-960.webp 960w,
            /img/hero-1280.webp 1280w,
            /img/hero-1920.webp 1920w"
    sizes="(max-width: 768px) 100vw,
           (max-width: 1280px) 80vw,
           1280px">

  <!-- JPEG fallback: เบราว์เซอร์เก่ามาก หรือ no-AVIF/WebP -->
  <img
    src="/img/hero-1280.jpg"
    srcset="/img/hero-640.jpg 640w,
            /img/hero-960.jpg 960w,
            /img/hero-1280.jpg 1280w,
            /img/hero-1920.jpg 1920w"
    sizes="(max-width: 768px) 100vw,
           (max-width: 1280px) 80vw,
           1280px"
    alt="Hero banner"
    width="1920"
    height="1080"
    loading="lazy"
    decoding="async"
    fetchpriority="auto">
</picture>

เบราว์เซอร์จะอ่าน <source> ตามลำดับจากบนลงล่าง ถ้า support type ของ source ใด ก็เลือกใช้ source นั้น ถ้าไม่ support สักอัน จะ fallback มาที่ <img> ในที่สุด การกำหนด width, height, loading, decoding บน <img> ช่วยลด CLS และเพิ่ม performance

ข้อสำคัญ — เบราว์เซอร์เลือก source แบบ first-match-wins ดังนั้น ลำดับสำคัญมาก ต้องใส่ AVIF ก่อน WebP ก่อน JPEG เสมอ ไม่ใช่กลับลำดับ

Lazy Loading + Eager Loading

ภาพที่อยู่ใน viewport ตอนแรก (above the fold) ควรใช้ loading="eager" และ fetchpriority="high" ส่วนภาพที่อยู่ต่ำลงไป (below the fold) ใช้ loading="lazy" เพื่อชะลอการโหลด

<!-- Hero image (above the fold) -->
<img src="hero.webp" loading="eager" fetchpriority="high" decoding="async" />

<!-- ภาพในเนื้อหา (below the fold) -->
<img src="content.webp" loading="lazy" decoding="async" />

อ่านเพิ่มเติมเกี่ยวกับ การ optimize LCP และ INP เพื่อ Core Web Vitals เพื่อจัดการ above-the-fold images ได้แม่นยำขึ้น

5 ข้อผิดพลาดที่พบบ่อย

1. ใช้ AVIF กับภาพเล็ก ๆ ทุกภาพ

AVIF มี overhead ใน header ค่อนข้างใหญ่ ทำให้กับภาพที่เล็กกว่า 10KB อยู่แล้ว AVIF อาจจะใหญ่กว่า WebP หรือแม้แต่ original JPEG ด้วยซ้ำ ภาพ thumbnail เล็ก ๆ ภาพ icon หรือ avatar ขนาด 64x64 ใช้ WebP หรือ PNG ก็เพียงพอ

2. ตั้ง quality สูงเกินไป

หลายคนยังตั้ง AVIF/WebP ที่ Q90 หรือสูงกว่า ทั้ง ๆ ที่ AVIF Q60 ก็ดูดีกว่า JPEG Q90 อยู่แล้ว การตั้ง quality สูงเกินไปทำให้เสียประโยชน์ของ format ใหม่ไป

ค่า quality แนะนำ:

AVIF: Q55-65 สำหรับภาพทั่วไป, Q70-75 สำหรับภาพ portrait/portfolio
WebP: Q75-85 สำหรับภาพทั่วไป, Q85-90 สำหรับภาพคุณภาพสูง
JPEG fallback: Q80-85 ใช้ mozjpeg encoder

3. ไม่ตั้ง width/height บน `<img>`

การไม่ระบุ width และ height ทำให้เบราว์เซอร์ไม่รู้ aspect ratio ของภาพก่อนโหลด ทำให้เกิด Cumulative Layout Shift (CLS) ซึ่งเป็นหนึ่งใน Core Web Vitals ถึงคุณจะใช้ CSS aspect-ratio แทนก็ได้ แต่ทาง HTML attribute ยังเป็นวิธีที่ universal ที่สุด

<!-- ผิด: ไม่มี width/height -->
<img src="hero.webp" alt="Hero" />

<!-- ถูก: มี width/height -->
<img src="hero.webp" alt="Hero" width="1920" height="1080" />

4. เสิร์ฟ AVIF/WebP ด้วย Content-Type ผิด

บางเซิร์ฟเวอร์ไม่รู้จัก MIME type ของ AVIF/WebP ทำให้ส่งเป็น application/octet-stream ซึ่งเบราว์เซอร์จะมอง download ไม่ใช่ render เป็นรูป ตรวจสอบโดยใช้ DevTools > Network tab ดู Response Header Content-Type

แก้ไขใน .htaccess (Apache):

AddType image/webp .webp
AddType image/avif .avif

แก้ไขใน nginx.conf:

types {
    image/webp webp;
    image/avif avif;
}

5. ลืม cache headers

ภาพ optimize แล้วควรตั้ง cache TTL ยาว ๆ (1 ปี) เพราะ static ไม่เปลี่ยน ถ้าไม่ตั้ง cache header ที่ดี เบราว์เซอร์อาจ re-validate ทุกครั้งทำให้เสียประโยชน์ของ format ใหม่

Cache-Control: public, max-age=31536000, immutable

ถ้าใช้ filename hash (เช่น hero.abc123.webp) สามารถใช้ immutable directive ได้อย่างปลอดภัย เพราะถ้าภาพเปลี่ยน URL จะเปลี่ยนด้วย

FAQ

Q1: AVIF ดีกว่า WebP จริงหรือ ควรใช้แค่ AVIF เลย

A: AVIF บีบอัดได้ดีกว่า WebP ประมาณ 50% และคุณภาพภาพดีกว่าที่ bitrate เดียวกัน แต่ encode ช้ากว่า 5-10 เท่า และ browser support น้อยกว่าเล็กน้อย (96.4% vs 99.1%) วิธีที่ดีที่สุดคือใช้ทั้งคู่ใน <picture> tag — เสิร์ฟ AVIF ก่อน ถ้าเบราว์เซอร์ไม่ support ค่อย fallback เป็น WebP

Q2: ถ้าเว็บผมยังมีภาพ JPEG อยู่ ควรแปลงทันทีไหม

A: ถ้าเว็บไซต์คุณมียอด traffic หรือยอดขาย ควรแปลงเลย ROI สูงมาก โดยเฉพาะถ้าคุณใช้ Cloudflare อยู่แล้ว เปิด Polish ใช้เวลา 2 นาที ลด page weight ได้ 30-40% ทันที สำหรับเว็บไซต์ขนาดใหญ่ที่มีภาพเป็นพัน ๆ แนะนำ migrate แบบ progressive — แปลงและ deploy หน้าที่สำคัญที่สุดก่อน (homepage, landing pages) แล้วค่อยทำหน้าอื่นตามมา

Q3: AVIF support บน iOS ตอนนี้เป็นยังไง

A: Safari บน iOS 16.4+ และ macOS Ventura+ รองรับ AVIF เต็มตัว (รวม animated AVIF ใน iOS 17+) ผู้ใช้ iOS ส่วนใหญ่อัพเดทเร็ว ตัวเลขล่าสุดของปี 2026 คือ 92% ของ iOS users ใช้ version 16+ ดังนั้นใช้ AVIF ใน production บน iOS ได้ปลอดภัย แต่ยังควรมี WebP fallback สำหรับผู้ใช้ที่ไม่อัพเดท

Q4: ใช้ WebP กับ animated GIF แทนได้ไหม

A: ได้ครับ animated WebP เล็กกว่า GIF ประมาณ 60-70% ที่คุณภาพดีกว่า เพราะ WebP support 24-bit color และ alpha channel ส่วน GIF ได้แค่ 8-bit color (256 สี) animated AVIF ก็มี แต่ encoding ช้ามาก ในกรณีของ animated content สมัยใหม่แนะนำใช้ MP4/WebM video tag ดีกว่าทั้ง animated WebP และ animated GIF เพราะบีบอัดได้ดีที่สุด

Q5: ทำไมไฟล์ AVIF บางครั้งใหญ่กว่า WebP

A: AVIF มี overhead ใน container header ค่อนข้างใหญ่ (ราว 500-1000 bytes) ดังนั้นกับภาพที่เล็กกว่า 5-10KB AVIF อาจไม่ได้เปรียบหรืออาจใหญ่กว่าด้วยซ้ำ นอกจากนี้ encoder setting ก็มีผล ถ้าใช้ libavif speed สูง (8-10) คุณภาพ-ขนาดอาจไม่ดี ลองใช้ speed 4-6 ดูจะได้ผลดีกว่า

Q6: Cloudflare Polish แปลงเป็น AVIF/WebP ฟรีหรือ

A: Polish พื้นฐาน (Lossy + WebP) มีในแผน Free ของ Cloudflare แต่ AVIF auto-conversion ต้องแผน Pro ขึ้นไป (25 USD/เดือน) ถ้าคุณยังอยู่ Free plan แนะนำ pre-generate ภาพ AVIF เก็บไว้ใน static hosting แล้วใช้ <picture> tag เลือก

Q7: Sharp กับ libvips กับ ImageMagick อันไหนดีกว่ากันสำหรับ Node.js

A: Sharp (ที่ใช้ libvips เป็น backend) เร็วที่สุด ประมาณ 4-5 เท่าของ ImageMagick และใช้ memory น้อยกว่ามาก เพราะ libvips ออกแบบมาเพื่อ streaming processing (process ทีละ chunk แทนที่จะโหลดทั้งภาพเข้า memory) สำหรับ production Node.js project แนะนำ Sharp 100% ImageMagick เหมาะกับ CLI scripts หรือกรณีที่ต้องใช้ feature เฉพาะที่ Sharp ไม่มี (เช่น complex compositing)

Q8: ภาพ photography portfolio ควรใช้ format ไหน

A: AVIF ครับ เพราะ photography ส่วนใหญ่ต้องการคุณภาพสูง สีสมจริง gradient เนียน — AVIF ทำได้ดีกว่า WebP มากในเรื่องนี้ โดยเฉพาะภาพ wide color gamut (Adobe RGB, Display P3) ที่ AVIF support 10-bit/12-bit color ส่วน WebP ได้แค่ 8-bit ทำให้สีอาจดู banding ในกรณีของภาพ sunset หรือภาพที่มี gradient เยอะ ใช้ AVIF Q70-75 จะได้คุณภาพระดับ professional ที่ขนาดไฟล์เล็กกว่า JPEG Q90 ถึง 70%

สรุป — ควรเลือก WebP หรือ AVIF

ถ้าจะให้คำตอบสั้น ๆ ในปี 2026: ใช้ทั้งคู่ — AVIF เป็นหลัก WebP เป็น fallback JPEG เป็น universal fallback สุดท้าย วิธีนี้ครอบคลุมเบราว์เซอร์ทุกตัว ทุกอุปกรณ์ และให้คุณภาพ-ขนาดที่ดีที่สุดในทุกกรณี

แต่ถ้าคุณต้องเลือกแค่อันเดียวเพราะข้อจำกัด:

เลือก WebP ถ้า: เว็บคุณมีรูปเยอะมาก ต้องประมวลผลภาพแบบเรียลไทม์ ใช้ shared hosting ที่ไม่มี AVIF encoder หรือต้องการ universal support สูงสุด
เลือก AVIF ถ้า: เว็บคุณมีรูปไม่เยอะ pre-generate ตอน build ได้ คุณภาพและขนาดสำคัญมาก (เช่น photography portfolio, e-commerce แฟชั่น, real estate)

ที่สำคัญที่สุด — อย่าใช้ JPEG/PNG อย่างเดียวอีกต่อไป มันคือการเสียโอกาสทั้ง user experience, SEO และ conversion rate ในยุคที่ Core Web Vitals กลายเป็น ranking factor หลัก ทุก KB ที่ลดได้จากภาพแปลว่าหน้าโหลดเร็วขึ้น ผู้ใช้พึงพอใจมากขึ้น และ Google จัดอันดับให้สูงขึ้น

ถ้าคุณยังไม่แน่ใจว่าจะเริ่มอย่างไร หรืออยากให้ทีมที่มีประสบการณ์ช่วย audit และ optimize เว็บไซต์ให้ ทีม Southern Whale ของเรา specialize ในการ optimize image, Core Web Vitals และ Performance ของเว็บไซต์มาแล้วมากกว่า 100 โปรเจ็กต์ ตั้งแต่เว็บโรงแรม ร้านอาหาร e-commerce ไปจนถึง enterprise dashboards

ปรึกษาเราเรื่อง Web Performance Optimization — เราจะทำ audit ฟรีให้คุณรอบแรก รวมถึงคำแนะนำที่นำไปทำเองได้ทันที ไม่ว่าคุณจะใช้ WordPress, Astro, Next.js หรือ stack อื่น ๆ เราพร้อมช่วยให้เว็บไซต์คุณเร็วขึ้น 2-3 เท่าภายในเดือนเดียว

อ่านบทความอื่นที่เกี่ยวข้องเพื่อต่อยอดความรู้: