เพิ่มประสิทธิภาพรูปภาพ AVIF WebP คู่มือ 2026

ทำไมการเพิ่มประสิทธิภาพรูปภาพถึงสำคัญที่สุดในปี 2026

รูปภาพคิดเป็นกว่า 51% ของขนาดหน้าเว็บเฉลี่ยทั่วโลก ซึ่งทำให้มันกลายเป็นปัจจัยอันดับหนึ่งที่ส่งผลต่อความเร็วในการโหลดเว็บไซต์ แล้วในปี 2026 ที่ Google ให้น้ำหนัก Core Web Vitals มากขึ้นกว่าเดิมในการจัดอันดับ — โดยเฉพาะ Largest Contentful Paint (LCP) ที่วัดเวลาการโหลดเนื้อหาหลักของหน้า — การเพิ่มประสิทธิภาพรูปภาพจึงไม่ใช่แค่ "ทำก็ดี" อีกต่อไป แต่เป็นสิ่งที่ ต้องทำ จริง ๆ

ข้อมูลจาก HTTP Archive ชี้ว่าเว็บไซต์ที่มี LCP ต่ำกว่า 2.5 วินาทีมี อัตราการตีกลับต่ำกว่า 24% เมื่อเทียบกับเว็บไซต์ที่ช้า แล้วการลดเวลาโหลดเพียงแค่ 1 วินาทีสามารถเพิ่ม Conversion ได้ถึง 20% เลย ตัวเลขพวกนี้บอกชัดเจนว่า: รูปภาพที่เร็วขึ้น = รายได้ที่มากขึ้น

เอาล่ะ มาเริ่มกันเลย — บทความนี้จะพาไปดูทุกเทคนิคที่จำเป็นสำหรับการเพิ่มประสิทธิภาพรูปภาพในปี 2026 ตั้งแต่การเลือกฟอร์แมตที่ถูกต้อง ไปจนถึง fetchpriority, preload, Responsive Images และอื่น ๆ พร้อมตัวอย่างโค้ดที่ใช้งานได้จริงทุกตัว

AVIF vs WebP vs JPEG: เลือกฟอร์แมตไหนดีในปี 2026

WebP — ตัวเลือกที่ปลอดภัยและครอบคลุม

WebP พัฒนาโดย Google รองรับทั้งการบีบอัดแบบ Lossy และ Lossless พร้อมรองรับ Transparency (Alpha Channel) และ Animation ได้ในฟอร์แมตเดียว จุดเด่นหลัก ๆ ก็คือ:

ไฟล์เล็กกว่า JPEG 25–35% ที่คุณภาพเทียบเท่า
รองรับเบราว์เซอร์สมัยใหม่ ทุกตัว ในปี 2026 แล้ว
ความเร็ว Encode/Decode สูงกว่า AVIF อย่างเห็นได้ชัด
เหมาะสำหรับเว็บไซต์ที่ต้องการความเข้ากันได้สูงสุด

AVIF — แชมป์การบีบอัดแห่งปี 2026

AVIF พัฒนามาจาก AV1 Video Codec และพูดตรง ๆ ว่ามันให้การบีบอัดดีที่สุดเท่าที่เราจะหาได้ในตอนนี้:

ไฟล์เล็กกว่า JPEG ถึง 50% และเล็กกว่า WebP อีก ~20%
รองรับ HDR, Wide Color Gamut และ Bit Depth สูง (10/12 บิต)
รองรับ Chrome, Edge, Firefox, Safari (iOS 16+) ครอบคลุมผู้ใช้กว่า 93%
ข้อด้อย: ใช้เวลา Encode นานกว่า WebP พอสมควร (ตรงนี้ต้องยอมรับ)

JPEG — ยังไม่ตาย แต่ควรเป็น Fallback

JPEG ยังคงจำเป็นอยู่ในฐานะ Fallback สำหรับเบราว์เซอร์เก่าที่ไม่รองรับ WebP หรือ AVIF แต่ไม่ควรเป็นฟอร์แมตหลักอีกต่อไปแล้ว เพราะประสิทธิภาพการบีบอัดมันด้อยกว่ามากจริง ๆ

ตารางเปรียบเทียบ

คุณสมบัติ	JPEG	WebP	AVIF
การบีบอัดเทียบกับ JPEG	—	ดีกว่า 25–35%	ดีกว่า 50%
รองรับ Transparency	ไม่รองรับ	รองรับ	รองรับ
รองรับ HDR	ไม่รองรับ	ไม่รองรับ	รองรับ
ความเร็ว Decode	เร็ว	เร็ว	ช้ากว่า
Browser Support (2026)	ทั้งหมด	ทั้งหมด	93%+

กลยุทธ์ที่แนะนำ: AVIF First, WebP Fallback

ใช้ <picture> element เพื่อ Serve AVIF ก่อน ตามด้วย WebP และ JPEG เป็น Fallback สุดท้าย — วิธีนี้เป็น Best Practice ที่ได้ผลดีจริง ๆ:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="คำอธิบายภาพ" width="1200" height="630">
</picture>

เบราว์เซอร์จะเลือกฟอร์แมตที่ดีที่สุดที่ตัวเองรองรับได้โดยอัตโนมัติ ผู้ใช้ Chrome จะได้ AVIF ที่เล็กที่สุด ส่วนเบราว์เซอร์เก่าก็ Fallback ไปที่ JPEG แบบไม่มีปัญหา

การบีบอัดรูปภาพ: คุณภาพ vs ขนาดไฟล์

หลักการสำคัญที่ต้องจำไว้: ตาของมนุษย์แทบไม่สามารถแยกความแตกต่างระหว่าง Lossy Compression ที่คุณภาพ 80–85% ดังนั้นไม่จำเป็นต้องใช้คุณภาพ 100% ซึ่งจะทำให้ไฟล์ใหญ่โดยไม่ได้ประโยชน์อะไรเลย

แนวทางการตั้งค่าคุณภาพที่ลองแล้วได้ผล:

AVIF: คุณภาพ 60–70% (ให้ผลลัพธ์ดีเยี่ยมเลย เพราะ Codec มีประสิทธิภาพสูงมาก)
WebP: คุณภาพ 75–85%
JPEG: คุณภาพ 80–85%

เป้าหมายสำหรับ Hero Image: ขนาดไฟล์ ไม่เกิน 200 KB สำหรับรูปเต็มหน้าจอ ถ้าทำได้ต่ำกว่านี้ยิ่งดี

fetchpriority: อาวุธลับสำหรับปรับปรุง LCP

ปัญหา: เบราว์เซอร์ไม่รู้ว่ารูปไหนสำคัญ

ตามค่าเริ่มต้น เบราว์เซอร์จะโหลดรูปภาพด้วย Priority ต่ำ เพราะมันสันนิษฐานว่ารูปส่วนใหญ่อยู่นอก Viewport แต่ Hero Image หรือรูปภาพหลักที่เป็น LCP Element ของหน้าควรได้รับ Priority สูง นี่แหละคือจุดที่ fetchpriority เข้ามาช่วย

วิธีใช้ fetchpriority

ง่ายมาก แค่เพิ่ม Attribute fetchpriority="high" ลงใน <img> tag ของ LCP Image:

<img src="hero.webp"
     alt="Hero Image"
     width="1200"
     height="630"
     fetchpriority="high">

ผลลัพธ์จริงในการใช้งาน

ตัวอย่างที่น่าสนใจ (และน่าประทับใจ):

Google Flights: LCP ดีขึ้นจาก 2.6 วินาทีเหลือ 1.9 วินาที — ลดลง 700 มิลลิวินาที จากการเปลี่ยนแค่ Attribute เดียว
Etsy: LCP ดีขึ้น 4% จากการใช้ fetchpriority
หลายเว็บไซต์รายงานว่า LCP ดีขึ้น 20–30% ในการทดสอบ

พูดตรง ๆ ว่า ROI ของการเพิ่ม Attribute ตัวเดียวนี้ดีมาก ๆ ไม่ค่อยเจอการปรับแต่งไหนที่ใช้แรงน้อยแต่ได้ผลมากขนาดนี้

ใช้กับ picture element

เมื่อใช้ร่วมกับ <picture> ให้เพิ่ม fetchpriority ที่ <img> ข้างใน ไม่ใช่ที่ <picture> หรือ <source> นะ — จุดนี้คนผิดกันเยอะ:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg"
       alt="Hero Image"
       width="1200"
       height="630"
       fetchpriority="high">
</picture>

ข้อควรระวัง: อย่าใช้ fetchpriority="high" มากเกินไป

ถ้าทุกรูปเป็น High Priority ก็เท่ากับไม่มีรูปไหนเป็น High Priority จริง ๆ ใช่ไหม? ให้ใช้เฉพาะกับ LCP Image เท่านั้น และใช้ fetchpriority="low" กับรูปที่อยู่นอก Viewport เพื่อลดการแย่ง Bandwidth:

<!-- รูป Hero — High Priority -->
<img src="hero.webp" fetchpriority="high" alt="Hero">

<!-- รูปที่ไม่สำคัญ — Low Priority -->
<img src="thumbnail.webp" fetchpriority="low" loading="lazy" alt="Thumbnail">

Preload: บอกเบราว์เซอร์ล่วงหน้าว่ารูปไหนสำคัญ

ทำไมต้อง Preload

preload ช่วยให้เบราว์เซอร์ ค้นพบ (Discover) รูปภาพเร็วขึ้น ก่อนที่จะต้องรอ Parse HTML หรือ CSS เสร็จ นี่สำคัญมากสำหรับกรณีเหล่านี้:

รูปภาพที่โหลดผ่าน CSS background-image (เบราว์เซอร์มองไม่เห็นจนกว่าจะ Parse CSS เสร็จ)
รูปภาพที่โหลดผ่าน JavaScript
รูปภาพที่อยู่ลึกใน DOM จนไม่ถูก Preload Scanner ค้นพบเร็วพอ

Preload + fetchpriority: คู่หูสุดทรงพลัง

ตรงนี้สำคัญมาก: preload คือ Mandatory Fetch (สั่งให้โหลด) ส่วน fetchpriority คือ Hint (บอก Priority) — ทั้งสองทำงานคนละหน้าที่และ ควรใช้ร่วมกัน เพื่อผลลัพธ์ที่ดีที่สุด:

<head>
  <!-- Preload เพื่อให้ค้นพบเร็ว + fetchpriority เพื่อให้ Priority สูง -->
  <link rel="preload"
        as="image"
        href="/img/hero.webp"
        fetchpriority="high">
</head>

Preload สำหรับ CSS Background Images

รูปภาพที่โหลดผ่าน CSS background-image เป็น "มองไม่เห็น" สำหรับ Preload Scanner ของเบราว์เซอร์ เลยต้อง Preload ระบุเอาเองอย่างชัดเจน:

<!-- CSS -->
<style>
  .hero { background-image: url('/img/hero-bg.webp'); }
</style>

<!-- Preload ใน head -->
<link rel="preload"
      as="image"
      href="/img/hero-bg.webp"
      fetchpriority="high">

Lazy Loading: โหลดเฉพาะสิ่งที่จำเป็น

หลักการ

Lazy Loading คือการเลื่อนการโหลดรูปภาพที่อยู่นอก Viewport ออกไปจนกว่าผู้ใช้จะ Scroll เข้าใกล้ ช่วยประหยัด Bandwidth และลดเวลาโหลดเริ่มต้นได้เยอะมาก

วิธีที่ง่ายที่สุดคือ Native Lazy Loading ด้วย Attribute loading="lazy":

<img src="product.webp"
     alt="สินค้า"
     width="400"
     height="300"
     loading="lazy">

กฎเหล็ก: ห้าม Lazy Load รูป LCP เด็ดขาด

นี่คือ ข้อผิดพลาดที่พบบ่อยที่สุด ในการเพิ่มประสิทธิภาพรูปภาพเลย และเจอเว็บที่ทำผิดตรงนี้บ่อยมาก — การใส่ loading="lazy" ให้ Hero Image หรือรูปภาพ Above-the-fold

ข้อมูลจาก Chrome UX Report พบว่าเว็บไซต์ที่ Lazy Load รูป LCP มี LCP ช้ากว่าถึง 35% แล้วทีมพัฒนา WordPress Core เองก็พบว่าการ Lazy Load รูปแรกในหน้าทำให้ LCP แย่ลง 7% อีกด้วย

กฎง่าย ๆ ที่ต้องจำ:

รูป Above-the-fold (ภายใน Viewport แรก): ใช้ loading="eager" หรือไม่ต้องใส่เลย (ค่าเริ่มต้นคือ eager อยู่แล้ว)
รูป Below-the-fold (ต้อง Scroll ถึง): ใช้ loading="lazy"

Lazy Loading ขั้นสูงด้วย Intersection Observer

สำหรับกรณีที่ต้องการควบคุมมากขึ้น เช่น โหลดรูปก่อนที่จะ Scroll ถึงจริง ๆ สักหน่อย ให้ใช้ Intersection Observer API แบบนี้:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      img.removeAttribute('data-src');
      observer.unobserve(img);
    }
  });
}, {
  rootMargin: '200px 0px' // โหลดล่วงหน้า 200px ก่อน Scroll ถึง
});

document.querySelectorAll('img[data-src]').forEach(img => {
  observer.observe(img);
});

Responsive Images: ส่งรูปที่ใช่ให้อุปกรณ์ที่ถูกต้อง

ทำไม Responsive Images ถึงสำคัญ

ลองคิดดู — การส่งรูปขนาด 2560px ให้โทรศัพท์มือถือที่แสดงผลแค่ 375px กว้าง มันคือการ สิ้นเปลือง Bandwidth ไปเปล่า ๆ ล้วน ๆ Responsive Images ช่วยให้เบราว์เซอร์เลือกโหลดรูปขนาดที่เหมาะสมกับอุปกรณ์ได้เอง

srcset กับ sizes: Resolution Switching

srcset บอกเบราว์เซอร์ว่ามีรูปขนาดไหนบ้างให้เลือก ส่วน sizes บอกว่ารูปจะแสดงผลกว้างเท่าไหร่ที่แต่ละ Breakpoint:

<img srcset="hero-640.webp 640w,
             hero-1024.webp 1024w,
             hero-1920.webp 1920w,
             hero-2560.webp 2560w"
     sizes="(max-width: 640px) 100vw,
            (max-width: 1024px) 100vw,
            1920px"
     src="hero-1920.webp"
     alt="Hero Image"
     width="1920"
     height="1080"
     fetchpriority="high">

ขนาดรูปที่แนะนำให้เตรียมไว้ (ครอบคลุมอุปกรณ์ส่วนใหญ่):

มือถือ: 640px – 768px
แท็บเล็ต: 1024px – 1280px
เดสก์ท็อป: 1920px – 2560px (สูงสุด ไม่จำเป็นต้องมากกว่านี้)

picture element: Art Direction

ใช้ <picture> เมื่อต้องการ Serve รูปที่แตกต่างกันจริง ๆ ตาม Breakpoint เช่น รูป Landscape สำหรับ Desktop และ Portrait สำหรับมือถือ:

<picture>
  <!-- มือถือ: รูป Portrait ที่ Crop แน่นขึ้น -->
  <source media="(max-width: 768px)"
          srcset="hero-mobile.avif"
          type="image/avif">
  <source media="(max-width: 768px)"
          srcset="hero-mobile.webp"
          type="image/webp">

  <!-- เดสก์ท็อป: รูป Landscape แบบเต็ม -->
  <source srcset="hero-desktop.avif"
          type="image/avif">
  <source srcset="hero-desktop.webp"
          type="image/webp">

  <img src="hero-desktop.jpg"
       alt="Hero Image"
       width="1920"
       height="1080"
       fetchpriority="high">
</picture>

Preload Responsive Images

เมื่อต้องการ Preload รูปที่เป็น Responsive ให้ใช้ imagesrcset และ imagesizes บน <link> tag:

<link rel="preload"
      as="image"
      imagesrcset="hero-640.webp 640w,
                   hero-1024.webp 1024w,
                   hero-1920.webp 1920w"
      imagesizes="(max-width: 640px) 100vw,
                  (max-width: 1024px) 100vw,
                  1920px"
      fetchpriority="high">

อย่าลืม: ใส่ fetchpriority="high" ด้วยนะ เพราะ Preload สำหรับรูปภาพจะได้ Priority ต่ำตามค่าเริ่มต้น ตรงนี้หลายคนมักพลาดไป

ป้องกัน Layout Shift: กำหนด width และ height เสมอ

การไม่กำหนด width และ height ให้รูปภาพทำให้เบราว์เซอร์ไม่สามารถจอง Space ล่วงหน้าได้ พอรูปโหลดเสร็จก็เกิดการ "กระโดด" ของเนื้อหา ส่งผลให้คะแนน Cumulative Layout Shift (CLS) แย่ลง ซึ่งผู้ใช้เกลียดมาก

แนวทางป้องกัน:

<!-- ดี: กำหนด width/height ให้เบราว์เซอร์คำนวณ aspect ratio -->
<img src="photo.webp"
     width="800"
     height="600"
     alt="รูปภาพ"
     loading="lazy">

<!-- ดีกว่า: ใช้ CSS aspect-ratio ร่วมด้วย -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 4 / 3;
  }
</style>
<img src="photo.webp"
     class="responsive-img"
     alt="รูปภาพ"
     loading="lazy">

Image CDN: ระบบอัตโนมัติสำหรับเว็บไซต์ขนาดใหญ่

สำหรับเว็บไซต์ที่มีรูปภาพจำนวนมาก (เช่น E-commerce ที่มีสินค้าเป็นพัน ๆ รายการ) การแปลงฟอร์แมตและ Resize ด้วยมือแทบเป็นไปไม่ได้ นี่คือจุดที่ Image CDN อย่าง Cloudinary, imgix, Cloudflare Images หรือ Bunny CDN เข้ามาช่วยได้:

แปลงฟอร์แมตอัตโนมัติ: ตรวจสอบ Accept Header แล้ว Serve AVIF หรือ WebP ตามที่เบราว์เซอร์รองรับ
Resize ตาม URL Parameter: เปลี่ยนขนาดรูปผ่าน Query String เช่น ?w=640&q=80
Cache ที่ Edge: ลด Latency โดย Serve รูปจากเซิร์ฟเวอร์ที่ใกล้ผู้ใช้ที่สุด
บีบอัดอัตโนมัติ: ปรับคุณภาพให้เหมาะสมโดยไม่สูญเสียคุณภาพที่มองเห็นได้

<!-- ตัวอย่าง: ใช้ Image CDN เพื่อ Serve รูปที่เพิ่มประสิทธิภาพแล้ว -->
<img srcset="https://cdn.example.com/hero.jpg?w=640&f=auto 640w,
             https://cdn.example.com/hero.jpg?w=1024&f=auto 1024w,
             https://cdn.example.com/hero.jpg?w=1920&f=auto 1920w"
     sizes="(max-width: 640px) 100vw, (max-width: 1024px) 100vw, 1920px"
     src="https://cdn.example.com/hero.jpg?w=1920&f=auto"
     alt="สินค้า"
     fetchpriority="high">

พารามิเตอร์ f=auto บอกให้ CDN เลือกฟอร์แมตที่ดีที่สุดตาม Accept Header ของเบราว์เซอร์โดยอัตโนมัติ สะดวกมากเพราะไม่ต้องจัดการ <picture> element เอง

Checklist รวม: เพิ่มประสิทธิภาพรูปภาพเว็บไซต์ปี 2026

เทคนิค	สิ่งที่ต้องทำ	ผลกระทบ
ฟอร์แมต	Serve AVIF > WebP > JPEG ด้วย picture element	สูงมาก
การบีบอัด	Lossy คุณภาพ 80–85% (AVIF: 60–70%)	สูง
fetchpriority	ใส่ fetchpriority="high" ที่ LCP Image เท่านั้น	สูง
Preload	Preload LCP Image ใน head พร้อม fetchpriority	สูง
Lazy Loading	ใส่ loading="lazy" เฉพาะรูป Below-the-fold	สูง
Responsive Images	ใช้ srcset/sizes หรือ picture สำหรับทุก Breakpoint	สูง
width/height	กำหนดขนาดทุกรูปเพื่อป้องกัน CLS	ปานกลาง
Image CDN	ใช้ CDN แปลงฟอร์แมตและ Resize อัตโนมัติ	สูง

คำถามที่พบบ่อย (FAQ)

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

AVIF ให้การบีบอัดที่ดีกว่า WebP ประมาณ 20% และรองรับ HDR กับ Wide Color Gamut ด้วย แต่ข้อเสียคือใช้เวลา Encode นานกว่า ในปี 2026 ทั้งสองฟอร์แมตรองรับเบราว์เซอร์สมัยใหม่ทุกตัวแล้ว กลยุทธ์ที่ดีที่สุดคือใช้ <picture> element เพื่อ Serve AVIF ก่อน แล้วให้ WebP เป็น Fallback

fetchpriority="high" ต่างจาก rel="preload" อย่างไร?

preload ทำให้เบราว์เซอร์ ค้นพบ รูปภาพเร็วขึ้น (Mandatory Fetch) แต่ไม่ได้เปลี่ยน Priority ส่วน fetchpriority="high" เป็น Hint ที่บอกเบราว์เซอร์ให้ จัดลำดับความสำคัญ ของรูปภาพสูงขึ้น ทั้งสองทำงานคนละหน้าที่ ใช้ร่วมกันได้ผลดีที่สุด

ทำไมไม่ควร Lazy Load รูป Hero Image?

Hero Image มักเป็น LCP Element ของหน้า การใส่ loading="lazy" จะทำให้เบราว์เซอร์ชะลอการโหลดออกไป ส่งผลให้ LCP ช้าลงถึง 35% ตามข้อมูลจาก Chrome UX Report รูป Above-the-fold ควรใช้ loading="eager" (หรือไม่ต้องใส่เลย) แล้วเสริมด้วย fetchpriority="high"

ควรบีบอัดรูปภาพที่คุณภาพเท่าไหร่?

สำหรับ Lossy Compression ตาของมนุษย์แทบไม่แยกความแตกต่างที่คุณภาพ 80–85% สำหรับ WebP และ JPEG ส่วน AVIF สามารถลงไปถึง 60–70% ได้เลย เพราะ Codec มีประสิทธิภาพสูงกว่ามาก เป้าหมายสำหรับ Hero Image คือขนาดไฟล์ไม่เกิน 200 KB

srcset กับ picture element ใช้ต่างกันอย่างไร?

srcset กับ sizes ใช้สำหรับ Resolution Switching — ให้เบราว์เซอร์เลือกขนาดรูปที่เหมาะสมกับ Viewport และ DPR ส่วน <picture> ใช้สำหรับ Art Direction — เมื่อต้องการ Serve รูปที่แตกต่างกันจริง ๆ ตาม Breakpoint เช่น Landscape บน Desktop และ Portrait บนมือถือ หรือเพื่อ Serve ฟอร์แมตต่าง ๆ พร้อม Fallback