แนวทางปฏิบัติสำหรับ Responsive Image Breakpoints ด้วย WebP

อัปเดตล่าสุด: June 28, 2026

Responsive image breakpoints คือความกว้างของภาพที่คุณสร้างขึ้นเพื่อให้โทรศัพท์ แท็บเล็ต แล็ปท็อป และหน้าจอที่มีความหนาแน่นสูงสามารถดาวน์โหลดไฟล์ที่มีขนาดใกล้เคียงกับที่แสดงผลจริงได้ หากเลือกน้อยเกินไป ผู้ใช้มือถือจะได้รับพิกเซลระดับเดสก์ท็อป หากเลือกมากเกินไป build, cache, และ CDN ของคุณจะเต็มไปด้วยรูปแบบ (variants) ที่ไม่มีใครต้องการ

คู่มือนี้จะครอบคลุมจุดที่เหมาะสมในทางปฏิบัติ: วัดพื้นที่จัดวาง (layout slot), สร้าง WebP ladder สั้นๆ, เขียน srcset และ sizes, จากนั้นตรวจสอบว่าเบราว์เซอร์เลือกไฟล์ที่ถูกต้องจาก CDN

คำตอบสั้นๆ: ควรใช้ responsive image breakpoints ตัวไหนดี?

ให้ใช้ breakpoints ที่ตรงกับพื้นที่แสดงผลของรูปภาพจริง จากนั้นเพิ่ม headroom สำหรับความหนาแน่น (density) ของจอ Retina สำหรับรูปภาพบทความหลายประเภท การมี WebP ladder ที่เป็นประโยชน์คือ 480w, 720w, 960w, 1200w, และ 1440w ส่วนสำหรับรูปภาพ hero แบบเต็มความกว้าง ให้เพิ่ม 1920w หากดีไซน์สามารถแสดงผลได้กว้างขนาดนั้นจริง

อย่าคัดลอก CSS breakpoints แบบสุ่ม A page อาจมี layout breakpoint ที่ 1280px ในขณะที่รูปภาพจริงแสดงผลอยู่ในคอลัมน์บทความขนาด 720px ในกรณีนี้ รูปภาพ 1440w อาจครอบคลุมจอ 2x อยู่แล้ว และการใช้ variant ขนาด 1920w อาจเป็นการสูญเปล่า

วิธีที่เชื่อถือได้นั้นง่ายมาก: ตรวจสอบความกว้างของ CSS slot ที่ใหญ่ที่สุด คูณด้วยค่าความหนาแน่นสูงสุดที่คุณต้องการรองรับ ปัดเศษให้เป็นความกว้างที่สมเหตุสมผล และลบไฟล์ที่ซ้ำกันเกือบทั้งหมด จากนั้นจับคู่ไฟล์เหล่านั้นกับ attribute sizes ที่ถูกต้อง เพื่อให้เบราว์เซอร์สามารถเลือกได้อย่างเหมาะสม

อะไรคือ Responsive Image Breakpoints?

Responsive image breakpoints คือความกว้างของไฟล์ที่ถูกสร้างขึ้น ไม่ใช่จุดหักเหของการออกแบบ (design breakpoints) โดยจำเป็น CSS breakpoints จะเปลี่ยนเลย์เอาต์ Image breakpoints ให้เมนูไฟล์แก่เบราว์เซอร์ เช่น 480w, 720w, 960w, และ 1440w

[responsive images guide] ของ MDN (https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images) อธิบายปัญหาหลัก: เบราว์เซอร์ต้องการข้อมูลเพียงพอเพื่อเลือกรูปภาพที่มีขนาดเหมาะสมก่อนที่เลย์เอาต์จะเสร็จสมบูรณ์ แอตทริบิวต์ srcset จะแสดงรายการตัวเลือก ในขณะที่ sizes อธิบายช่องว่างที่รูปภาพนั้นจะครอบครอง

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

สำหรับการเลือกรูปแบบ ให้จับคู่ breakpoints กับรูปแบบเว็บที่ทันสมัย WebP เป็นค่าเริ่มต้นที่ปลอดภัยสำหรับการรองรับในวงกว้าง และ AVIF อาจคุ้มค่าที่จะเพิ่มสำหรับคลังภาพถ่ายขนาดใหญ่ การแลกเปลี่ยนระหว่างรูปแบบได้กล่าวไว้ใน AVIF vs WebP Comparison

จะเลือกความกว้างของ Breakpoint ได้อย่างไร?

ให้เริ่มจากพื้นที่ที่แสดงผล (rendered slot) ไม่ใช่ไฟล์ต้นฉบับ รูปภาพสินค้าขนาด 4000px ไม่จำเป็นต้องมีเวอร์ชันเว็บขนาด 4000px หากช่องที่ใหญ่ที่สุดที่มองเห็นได้คือ 760px มันต้องการพิกเซลเพียงพอที่จะดูคมชัดในพื้นที่นั้นบนหน้าจอที่คุณสนใจ

ใช้ลำดับนี้:

1. เปิดหน้าเว็บที่เลย์เอาต์มือถือแคบที่สุด ความกว้างแท็บเล็ตทั่วไป ความกว้างแล็ปท็อป และความกว้างเดสก์ท็อปแบบกว้าง
2. วัดพื้นที่ภาพที่แสดงผลเป็นหน่วย CSS pixels
3. คูณแต่ละช่องด้วย 1x และ 2x หากคุณต้องการรองรับความหนาแน่นสูง (high-density)
4. ปัดเศษให้เป็นขั้นบันไดเล็กๆ เช่น 480, 720, 960, 1200, 1440, และ 1920
5. ลบความกว้างที่ห่างกันน้อยกว่าประมาณ 15 เปอร์เซ็นต์
6. หยุดที่ความกว้างที่ใหญ่ที่สุดที่การออกแบบสามารถใช้ได้

ฉันได้เข้ารหัสกราฟิกทั้งสี่ในบทความนี้ในเครื่องที่ขนาด 1400 by 788 เป็น WebP แต่ละไฟล์มีขนาดต่ำกว่า 35 KB เนื่องจากสินทรัพย์เหล่านี้เป็นกราฟิกคำแนะนำแบบแบน (flat instructional graphics) ภาพถ่ายจากกล้องที่มีขนาดเท่ากันมักจะมีขนาดใหญ่กว่ามาก ดังนั้นให้วัดผลลัพธ์ของคุณเองก่อนกำหนดงบประมาณ

หากโฟลเดอร์ทั้งหมดต้องการความกว้างเหล่านี้ ให้ใช้ขั้นตอนการปรับขนาดที่ทำซ้ำได้ Batch Resize Guide ครอบคลุมรูปแบบคำสั่งแบบ command-line สำหรับสร้างรูปภาพที่มาจากไฟล์โดยไม่เขียนทับ master files

ต้องให้ srcset และ sizes มีลักษณะอย่างไร?

สำหรับรูปภาพเนื้อหาที่ตอบสนอง (responsive) ส่วนใหญ่ ให้ใช้ตัวอธิบายความกว้าง (width descriptors) ร่วมกับ sizes ตัวอธิบายความกว้างจะบอกเบราว์เซอร์ถึงความกว้างพิกเซลจริงของแต่ละตัวเลือก ค่า sizes จะบอกเบราว์เซอร์ว่ารูปภาพจะแสดงผลในเลย์เอาต์ด้วยความกว้างเท่าใด

<img
  src="https://cdn.example.com/blog/photo-960.webp"
  srcset="
    https://cdn.example.com/blog/photo-480.webp 480w,
    https://cdn.example.com/blog/photo-720.webp 720w,
    https://cdn.example.com/blog/photo-960.webp 960w,
    https://cdn.example.com/blog/photo-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  width="1440"
  height="810"
  alt="Product photo displayed in a responsive article layout">

ตัวอย่าง sizes กล่าวว่า: เมื่อ view-port มีความกว้างอย่างน้อย 900px ช่องว่างของรูปภาพคือ 720px; มิฉะนั้น ช่องว่างจะเป็น 92 เปอร์เซ็นต์ของ view-port โทรศัพท์ที่มีความกว้าง 390px สามารถเลือกไฟล์ที่ใกล้เคียง 720w สำหรับการแสดงผลแบบ 2x แทนที่จะดาวน์โหลดไฟล์ 1440w

คู่มือของ web.dev เกี่ยวกับ รูปภาพที่ตอบสนอง (responsive images) แสดงหลักการเลือกเบราว์เซอร์เดียวกัน: คือการให้ข้อมูลผู้สมัครและเลย์เอาต์ที่แม่นยำแก่เบราว์เซอร์ เพื่อให้สามารถเลือกได้ก่อนที่จะมีการร้องขอรูปภาพ

ให้ใช้องค์ประกอบ <picture> เมื่อมีการเปลี่ยนแปลงการครอปหรือรูปแบบ ไม่ใช่สำหรับการเปลี่ยนขนาดปกติทุกครั้ง ตัวอย่างเช่น รูปภาพ hero ที่จัดทิศทางด้วยศิลปะ (art-directed) อาจต้องการการครอปสำหรับมือถือแบบสี่เหลี่ยมจัตุรัสและการครอปสำหรับเดสก์ท็อปที่กว้าง การเปลี่ยนความกว้างธรรมดามักจะง่ายกว่าโดยใช้ img เพียงตัวเดียวและ srcset ที่ดี

การมีจุดตัดภาพมากเกินไปนั้นมากแค่ไหนถึงจะมากเกินไป?

การมีเวอร์ชันที่หลากหลายมากขึ้นไม่ได้หมายความว่าจะดีกว่าเสมอไป ทุกความกว้างที่เพิ่มเข้ามาจะเพิ่มเวลาในการ build, พื้นที่จัดเก็บข้อมูล, รายการแคช, พื้นผิวของการ invalidation ของ CDN, และงานตรวจสอบ หากตัวเลือกสองตัวใกล้เคียงกันมาก การประหยัดไบต์ของเบราว์เซอร์อาจน้อยเกินไปจนไม่คุ้มค่ากับการสร้างไฟล์เพิ่มเติม

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

โปรดระวังสัญญาณเหล่านี้ที่บ่งชี้ว่าจุดตัด (breakpoints) นั้นหนาแน่นเกินไป:

• มี 640w, 700w, และ 760w สำหรับรูปภาพเดียวกันทั้งหมด
• บันทึกของ CDN แสดงให้เห็นว่ามีบางเวอร์ชันที่ไม่เคยถูกเรียกใช้เลย
• เวลาในการ build เพิ่มขึ้นเนื่องจากการอัปโหลดแต่ละครั้งสร้างอนุพันธ์ (derivatives) สิบรายการหรือมากกว่า
• บรรณาธิการไม่สามารถระบุได้ว่าไฟล์ใดควรอยู่ใน frontmatter, Open Graph, และเนื้อหาหลัก
• การตรวจสอบคุณภาพด้วยสายตาเริ่มตรวจสอบชื่อไฟล์แทนหน้าเว็บที่แสดงผล

โปรดระวังสัญญาณเหล่านี้ที่บ่งชี้ว่าจุดตัดนั้นเบาบางเกินไป:

• โทรศัพท์ดาวน์โหลดไฟล์ 1440w หรือ 1920w สำหรับรูปภาพเนื้อหาทั่วไป
• หน้าจอ retina ของเดสก์ท็อปดูนุ่มนวลเพราะตัวเลือกที่ใหญ่ที่สุดมีขนาดเล็กเกินไป
• เบราว์เซอร์เลือก src fallback เดิมเสมอ
• PageSpeed หรือ Lighthouse แจ้งเตือนว่ามีรูปภาพขนาดใหญ่เกินไปบนอุปกรณ์เคลื่อนที่

แนวทางปฏิบัติที่ดีที่สุดด้าน image SEO ของ Google แนะนำให้ใช้ URL รูปภาพที่สามารถถูก crawl ได้, ข้อความรอบข้างที่มีประโยชน์, และ alt text ที่สื่อความหมาย การส่งมอบแบบ Responsive ควรคงไว้ซึ่งพื้นฐานเหล่านี้ อย่าซ่อนรูปภาพสำคัญใน CSS backgrounds หากจำเป็นต้องมีการทำ index หรือเข้าใจว่าเป็นเนื้อหาของหน้า

Breakpoints ส่งผลต่อ Core Web Vitals อย่างไร?

Responsive breakpoints ส่งผลต่อประสิทธิภาพเนื่องจากไบต์ของรูปภาพมักจะครองพื้นที่หน้าจอแรก หากรูปภาพฮีโร่เป็นองค์ประกอบ Largest Contentful Paint ด้วย Breakpoint ที่ไม่ถูกต้องอาจทำให้การแสดงผลที่สำคัญที่สุดต้องรอไฟล์ที่มีขนาดใหญ่กว่าที่จำเป็นถึงสองเท่า

แนวทางของ web.dev สำหรับ การปรับปรุง Largest Contentful Paint แนะนำให้ทำให้รูปภาพ LCP ที่น่าจะเป็นไปได้สามารถค้นพบได้ตั้งแต่เนิ่น ๆ และจัดลำดับความสำคัญเมื่อเหมาะสม Breakpoints ไม่ได้มาแทนที่งานนั้น พวกมันช่วยให้แน่ใจว่าไฟล์ที่ถูกจัดลำดับความสำคัญมีขนาดที่ถูกต้อง

สำหรับรูปภาพส่วนบนหน้าจอ:

1. กำหนด width และ height อย่างชัดเจนเพื่อสำรองพื้นที่
2. หลีกเลี่ยงการ lazy load รูปภาพ LCP ที่น่าจะเป็นไปได้
3. ใช้ fetchpriority="high" เฉพาะกับรูปภาพที่ต้องการจริง ๆ เท่านั้น
4. รักษาความแม่นยำของ sizes สำหรับ layout เริ่มต้น
5. ตรวจสอบ currentSrc ที่เลือกใน DevTools

สำหรับรูปภาพส่วนล่างหน้าจอ:

1. lazy load รูปภาพแกลเลอรีและบทความทั่วไป
2. ใช้ breakpoint ladder เดียวกัน เว้นแต่ว่าการครอปให้เล็กกว่าจะเพียงพอ
3. บีบอัดหลังจากปรับขนาด ไม่ใช่ก่อนหน้านั้น
4. รักษา alt text ให้เฉพาะเจาะจงกับรูปภาพที่มองเห็นได้
5. ตรวจสอบ mobile network waterfalls ไม่ใช่แค่ desktop

หากปัญหาของคุณส่วนใหญ่คือการค้นพบฮีโร่อะเซทที่ล่าช้า ให้อ่าน Critical Image Extraction ถ้าไฟล์มีขนาดใหญ่เกินไป ก็ให้ทำตาม Image Compression Ratio Guide ก่อนที่จะเปลี่ยน markup

คุณควรตรวจสอบ CDN อะไรบ้างก่อนเผยแพร่?

Breakpoint จะเสร็จสมบูรณ์ก็ต่อเมื่อ URL สุดท้ายใช้งานได้แล้ว ร่าง Markdown ที่ดูสะอาดตาอาจยังคงล้มเหลวได้ หากพาธของ CDN ผิดพลาด อ็อบเจกต์มี content type ผิด หรือหน้าเว็บอ้างถึงไฟล์ภายในเครื่อง /blog/... โดยไม่ได้ตั้งใจ

เรียกใช้การตรวจสอบก่อนเผยแพร่ดังนี้:

ใน Chrome DevTools ให้ตรวจสอบรูปภาพที่เรนเดอร์และตรวจสอบ currentSrc จากนั้นเปลี่ยน viewport และ device pixel ratio URL ที่เลือกควรจะเลื่อนผ่านบันได หากมันไม่เปลี่ยนแปลงเลย อาจเป็นเพราะ markup หรือส่วนประกอบรูปภาพของ framework กำลังเขียนทับตัวเลือกของคุณ

สำหรับการตรวจสอบการเผยแพร่ที่ครอบคลุมยิ่งขึ้น ให้ใช้ Complete Image Optimization Checklist สำหรับงบประมาณเฉพาะสำหรับมือถือ ให้จับคู่สิ่งนี้กับ Mobile Image Optimization Guide การตัดสินใจเกี่ยวกับการโหลดแบบ Lazy load จะถูกกล่าวถึงแยกต่างหากใน Lazy Load Images

รายการตรวจสอบจุดหักเหของรูปภาพแบบตอบสนอง

ใช้เวอร์ชันย่อนี้เมื่อทบทวน pull request:

• รูปภาพหลักมีขนาดใหญ่กว่าตัวแปรที่สร้างขึ้นมาที่สุด
• ความกว้างที่สร้างขึ้นตรงกับช่องแสดงผลจริง
• ความกว้างไม่ได้ถูกบีบอัดอยู่ในหน่วยเพิ่มค่าต่ำๆ ที่เล็กมาก
• ไฟล์ WebP ถูกบีบอัดหลังจากปรับขนาดแล้ว
• srcset ใช้คำระบุความกว้างที่ถูกต้อง
• sizes ตรงกับเลย์เอาต์ ไม่ใช่การเดาเป็น 100vw
• รูปภาพ LCP ที่น่าจะเป็นไม่ได้ถูก lazy-load
• รูปภาพใต้ขอบ (Below-fold) ถูก lazy-load
• มีค่าความกว้างและความสูงเพื่อหลีกเลี่ยง layout shift
• CDN URLs ส่งคืน HTTP 200 ก่อนเผยแพร่
• ลิงก์ภายในชี้ให้ผู้อ่านไปยังขั้นตอนต่อไปของการบีบอัด, มือถือ, และการโหลดแบบ lazy

ชุดจุดหักเหที่มีประโยชน์คือชุดที่เล็กที่สุดที่ยังคงทำให้รูปภาพคมชัดโดยไม่บังคับให้โทรศัพท์ดาวน์โหลดไฟล์เดสก์ท็อป วัดขนาดช่อง, สร้างบันได, เผยแพร่ไฟล์ WebP, และยืนยันว่าเบราว์เซอร์เลือกไฟล์ที่คุณคาดหวัง