การปรับแต่งภาพสำหรับเว็บไซต์: ฟอร์แมต ขนาด และ lazy loading

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

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

สรุปสั้นๆ การปรับแต่งภาพ

• เลือกฟอร์แมตตามเนื้อหา ภาพถ่ายใช้ WebP หรือ AVIF โลโก้และไอคอนใช้ SVG ใช้ PNG สำหรับกราฟิกแบบไม่สูญเสียคุณภาพ และ JPEG เป็นตัวสำรอง
• Export ที่ขนาดที่ภาพแสดงจริง และไม่เกินสองเท่าของความกว้างนั้นสำหรับหน้าจอความละเอียดสูง อย่าอัปโหลดไฟล์ต้นฉบับจากกล้อง
• ใช้ srcset และ sizes เพื่อให้มือถือดาวน์โหลดไฟล์ที่เล็กกว่าเดสก์ท็อป
• ใส่ width และ height เสมอ เพื่อไม่ให้เลย์เอาต์กระโดด
• ใช้ lazy load กับภาพที่อยู่ใต้หน้าจอแรก แต่ห้ามใช้กับภาพหลัก (LCP) ให้ใส่ fetchpriority="high" กับภาพนั้นแทน
• ให้ระบบทำงานแทน ด้วยการปรับขนาดและแปลงฟอร์แมตอัตโนมัติ

เลือกฟอร์แมต: JPEG, PNG, WebP, AVIF หรือ SVG

เลือกฟอร์แมตตามสิ่งที่อยู่ในภาพ ไม่ใช่ตามความเคยชิน

WebP กับ AVIF

ณ เวลาที่เขียน (กรกฎาคม 2026) Chrome, Edge, Firefox และ Safari เวอร์ชันปัจจุบัน รองรับทั้งสองฟอร์แมต และทั้งสองมักให้ไฟล์เล็กกว่า JPEG ที่คุณภาพใกล้เคียงกัน AVIF มักได้ไฟล์เล็กกว่า WebP แต่ไม่ใช่ทุกครั้ง มันเข้ารหัสช้ากว่า และที่การตั้งค่าบีบอัดแรงๆ อาจทำให้พื้นผิวละเอียดอย่างผ้าหรือเส้นผมเบลอ ส่วน WebP เร็วกว่าและคาดเดาผลได้ง่ายกว่า

คำตอบในทางปฏิบัติคือสร้างทั้งสองแบบ แล้วให้เบราว์เซอร์เลือกเอง โดยใช้ <picture> ที่มี <source> หนึ่งตัวต่อหนึ่งฟอร์แมต ใส่ AVIF ไว้ก่อน (เบราว์เซอร์จะใช้ฟอร์แมตแรกที่รองรับ) และมี <img> เป็นตัวสำรอง ถ้าทำได้แค่แบบเดียว WebP คือตัวเลือกที่ปลอดภัย

บีบอัดด้วยตา ไม่ใช่ด้วยตัวเลข

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

SVG ภาพเคลื่อนไหว และตัวหนังสือในภาพ

• โลโก้และไอคอน ควรเป็น SVG ซึ่งมักเป็นไฟล์เล็กมาก และคมชัดทุกขนาด ไฟล์ SVG มีสคริปต์อยู่ข้างในได้ WordPress จึงไม่รับอัปโหลด SVG เป็นค่าเริ่มต้น ถ้าคุณเปิดใช้ ต้อง sanitise ทุกไฟล์
• GIF เคลื่อนไหว มีขนาดใหญ่มากเมื่อเทียบกับสิ่งที่แสดง web.dev แนะนำให้แทนด้วยวิดีโอสั้นๆ แบบปิดเสียงและเล่นวนซ้ำ ซึ่งมักมีขนาดเพียงเศษเสี้ยว
• ตัวหนังสือที่ฝังในภาพ จะเบลอเมื่อซูม เลือกหรือแปลไม่ได้ โปรแกรมอ่านหน้าจอได้แค่สิ่งที่ alt text พูดซ้ำ และเว็บไซต์หลายภาษาต้องมีภาพหนึ่งชุดต่อทุกภาษา ให้ใส่ข้อความเหล่านั้นไว้ในหน้าเว็บแทน

ปรับขนาดภาพให้พอดีกับพื้นที่

ปัญหาที่ใหญ่กว่ามักเป็นเรื่องขนาด ไม่ใช่ฟอร์แมต เช่น ภาพกว้าง 4,000 พิกเซลที่แสดงในการ์ดกว้าง 400 พิกเซล เบราว์เซอร์ดาวน์โหลดทุกพิกเซล แล้วทิ้งเกือบทั้งหมด

คำนวณขนาดที่ต้องใช้จริง

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

จุดเริ่มต้นสำหรับตำแหน่งภาพที่ใช้บ่อย

ภาพแบบ responsive: srcset และ sizes

แอตทริบิวต์ srcset ระบุภาพเดียวกันไว้หลายความกว้าง (เช่น 800, 1,600 และ 2,400 พิกเซล) และ sizes บอกเบราว์เซอร์ว่าภาพจะแสดงกว้างเท่าไร เช่น ครึ่งหน้าจอบนจอใหญ่ และเต็มความกว้างเมื่อจอเล็กกว่านั้น เบราว์เซอร์จะคิดรวมความหนาแน่นพิกเซล แล้วดาวน์โหลดไฟล์ที่เล็กที่สุดที่ยังดูคมชัด

ข้อผิดพลาดที่พบบ่อย คือใส่ srcset แต่ไม่มี sizes ที่ถูกต้อง เมื่อไม่มี เบราว์เซอร์จะถือว่าภาพกว้างเต็มหน้าต่างเบราว์เซอร์ ภาพการ์ดเล็กๆ จึงอาจดึงไฟล์ที่ใหญ่กว่าที่ต้องการหลายเท่า CMS สร้าง srcset ได้ แต่ไม่ได้รู้จักเลย์เอาต์ของคุณเสมอไป WordPress ตั้งค่า sizes เริ่มต้นตามความกว้างของตัวภาพเอง ไม่ใช่ตามคอลัมน์ที่ภาพอยู่ ตั้งแต่เวอร์ชัน 6.7 WordPress เพิ่ม sizes="auto" ให้ภาพที่ใช้ lazy load ซึ่งทำให้เบราว์เซอร์ที่รองรับใช้ความกว้างจริงของเลย์เอาต์ได้ ตรวจเทมเพลตที่มีกริดและแถบข้าง (sidebar) ด้วย

การครอปตามหน้าจอ (art direction) เป็นอีกเรื่องหนึ่ง เมื่อภาพ hero แนวนอนกว้างๆ กลายเป็นแถบบางๆ บนมือถือ ให้ใช้ <picture> พร้อมเงื่อนไข media เพื่อส่งภาพที่ครอปต่างกัน ไม่ใช่แค่ไฟล์ที่เล็กลง

ใส่ width และ height กันหน้ากระโดด

ใส่แอตทริบิวต์ width และ height ที่ตรงกับสัดส่วนของไฟล์ให้ทุกภาพ เบราว์เซอร์ใช้ค่าเหล่านี้จองพื้นที่ไว้ก่อนภาพมาถึง ขณะที่ CSS (max-width: 100%; height: auto) ทำให้ภาพยังปรับตามหน้าจอได้ ถ้าไม่มี ทุกอย่างที่อยู่ใต้ภาพจะกระโดดเมื่อภาพโหลด ซึ่งเป็นสาเหตุคลาสสิกของ Cumulative Layout Shift หรือ CLS ที่ Google ให้คะแนนว่าดีเมื่อไม่เกิน 0.1 สำหรับพื้นหลังด้วย CSS และสิ่งที่ฝังในหน้า ให้ใช้ property aspect-ratio บทความ อธิบาย Core Web Vitals พูดถึงสาเหตุอื่นของเลย์เอาต์ที่ขยับ

Lazy loading: ใช้ใต้หน้าจอแรก ห้ามใช้กับ hero

แอตทริบิวต์ loading="lazy" ซึ่งเบราว์เซอร์หลักทุกตัวรองรับในตัว จะชะลอการโหลดภาพไว้จนกว่าผู้เข้าชมจะเลื่อนมาใกล้ ช่วยประหยัดดาต้า และเปิดทางให้เครือข่ายโหลดสิ่งที่อยู่บนหน้าจอ

แต่ถ้าใช้ผิดภาพก็ให้ผลตรงข้าม เบราว์เซอร์จะดึงภาพแบบ lazy ก็ต่อเมื่อเลย์เอาต์ยืนยันแล้วว่าภาพอยู่ใกล้พื้นที่มองเห็น ภาพ hero ที่ใช้ lazy load จึงเริ่มดาวน์โหลดช้า และ LCP ก็แย่ลง web.dev แนะนำว่าอย่าใช้ lazy load กับอะไรก็ตามที่มองเห็นตั้งแต่หน้าโหลดครั้งแรก

ให้ภาพหลักได้สิทธิ์ก่อน

fetchpriority="high" บอกเบราว์เซอร์ว่าภาพนี้สำคัญกว่าไฟล์อื่นที่กำลังแย่งแบนด์วิดท์ ใช้กับภาพเดียวต่อหน้า คือภาพที่น่าจะเป็นองค์ประกอบ LCP การใส่หลายภาพจะทำให้ผลเจือจาง เบราว์เซอร์หลักเวอร์ชันปัจจุบันรองรับ ส่วนเวอร์ชันเก่าจะมองข้ามไป

ถ้าภาพ hero เป็นพื้นหลังด้วย CSS เบราว์เซอร์จะเจอมันหลังจากสไตล์ชีตโหลดและถูกนำไปใช้แล้วเท่านั้น ให้เปลี่ยนเป็น <img> จริง หรือ preload ด้วย <link rel="preload" as="image" fetchpriority="high"> สไลด์ hero แบบหมุน (carousel) ยังเพิ่มอีกปัญหาหนึ่ง คือภาพใหญ่หลายภาพแย่งกันโหลด และสไลด์แรกมักมาถึงช้า ถ้ายังจะใช้ ให้ใส่ fetchpriority="low" กับสไลด์ที่ซ่อนอยู่

สร้างระบบป้องกันไม่ให้ภาพเดียวทำเว็บช้า

คนถัดไปที่อัปโหลดภาพ อาจไม่เคยอ่านแนวทางของคุณเลย จึงควรทำให้ผลลัพธ์ที่ถูกต้องเกิดขึ้นเองโดยอัตโนมัติ

• ปรับขนาดอัตโนมัติ WordPress สร้างสำเนาขนาดเล็กของทุกภาพที่อัปโหลด และสร้าง srcset ให้ภาพที่วางผ่าน editor ตั้งแต่เวอร์ชัน 5.3 ยังย่อภาพที่อัปโหลดซึ่งด้านยาวเกิน 2,560 พิกเซลลงเป็นค่าเริ่มต้นด้วย
• คำใบ้การโหลดอัตโนมัติ WordPress ใช้ lazy load กับภาพ พยายามข้ามภาพแรกๆ และตั้งแต่เวอร์ชัน 6.3 ให้ลำดับความสำคัญสูงกับภาพที่น่าจะเป็น hero แต่ page builder และสไลเดอร์อาจทำให้การเดานี้ผิด จึงต้องตรวจสอบ บทความ วิธีทำให้เว็บไซต์ WordPress เร็วขึ้น พูดเรื่องนี้ควบคู่กับปลั๊กอินและแคช
• แปลงฟอร์แมต WordPress รับอัปโหลดไฟล์ WebP (ตั้งแต่ 5.8) และ AVIF (ตั้งแต่ 6.5) เมื่อเซิร์ฟเวอร์รองรับ การแปลงไฟล์ JPEG ที่อัปโหลดโดยอัตโนมัติ มักต้องใช้ปลั๊กอิน เครื่องมือจัดการภาพของผู้ให้บริการโฮสติ้ง หรือ image CDN
• Image CDN ปรับขนาด แปลง และบีบอัดภาพตามคำขอ ส่ง AVIF หรือ WebP ให้เบราว์เซอร์ที่รองรับ และแคชผลลัพธ์ไว้ใกล้ผู้เข้าชม บทความ อธิบายการแคชเว็บไซต์และ CDN แสดงว่าส่วนนี้อยู่ตรงไหน
• ตำแหน่งภาพที่เทมเพลตควบคุม กำหนดสัดส่วนภาพตายตัวให้แต่ละตำแหน่ง และให้เทมเพลตตัดสินขนาดและการครอป โดยมีจุดโฟกัสที่ผู้ดูแลเนื้อหาตั้งได้ เขาเลือกภาพ ส่วนระบบจัดการที่เหลือ
• จำกัดการอัปโหลดและมีข้อความเตือน จำกัดขนาดไฟล์ และทำให้ alt text เป็นช่องที่ระบบถามทุกครั้ง แทนที่จะเป็นช่องเสริมที่ไม่บังคับ

แกลเลอรีสินค้า: กรณีพิเศษ

หน้าสินค้ามักมีภาพมากกว่าเทมเพลตอื่นใด และผู้ซื้อก็อยากเห็นรายละเอียด บทความ การออกแบบหน้าสินค้าอีคอมเมิร์ซ อธิบายว่าแกลเลอรีควรแสดงอะไร ส่วนตรงนี้คือวิธีโหลด

• ภาพสินค้าหลักมักเป็นองค์ประกอบ LCP โหลดแบบ eager ด้วยลำดับความสำคัญสูง และ srcset ที่กำหนดขนาดตามความกว้างจริงของแกลเลอรี
• ภาพย่อได้ไฟล์เล็กๆ ของตัวเอง ไม่ใช่ภาพขนาดเต็มที่เบราว์เซอร์ย่อลง
• ภาพอื่นในแกลเลอรีรอไว้ก่อน จนกว่าผู้เข้าชมจะปัด และภาพความละเอียดสูงสำหรับซูม รอจนกว่าจะมีคนซูมจริง
• ใช้สัดส่วนภาพเดียวกันทั้งแคตตาล็อก เช่น สี่เหลี่ยมจัตุรัส หรือ 4:5 เพื่อให้กริดเป็นระเบียบ และการสลับสีของสินค้าไม่ทำให้หน้าขยับ
• ในกริดรายการสินค้า ใช้ lazy load กับทุกภาพยกเว้นแถวแรก ซึ่งมองเห็นตั้งแต่เข้ามา

ตรวจสิ่งที่ขึ้นเว็บไปแล้ว

เครื่องมือฟรีจะหาตัวการที่แย่ที่สุดให้

1. ทดสอบหน้าสำคัญด้วย PageSpeed Insights บนมือถือ มันจะบอกว่าองค์ประกอบ LCP คืออะไร และชี้ภาพที่ใหญ่เกิน บีบอัดไม่ดี ใช้ฟอร์แมตเก่า หรือไม่ได้ระบุขนาด บทความ วิธีอ่านรายงาน PageSpeed Insights อธิบายส่วนที่เหลือ
2. เปิด Chrome DevTools กรองแผง Network ด้วย Img แล้วโหลดหน้าใหม่ และเรียงตามขนาด
3. เทียบขนาดที่แสดงกับขนาดจริง ในแผง Elements ให้เอาเมาส์ชี้ที่แหล่งที่มาของภาพ เพื่อดูขนาดที่แสดงผล (rendered) และขนาดจริงของไฟล์ (intrinsic) ไฟล์กว้าง 3,000 พิกเซลที่แสดงที่ 350 พิกเซล คือจุดที่แก้ได้เร็ว
4. ตรวจภาพ hero ยืนยันว่าไม่ได้ใช้ lazy load มีลำดับความสำคัญสูง และไม่ใช่พื้นหลังด้วย CSS ที่ถูกเจอช้า
5. เฝ้าดูรายงาน Core Web Vitals ใน Search Console รายงานนี้ใช้ข้อมูลจากผู้ใช้ Chrome จริงในช่วง 28 วันที่ผ่านมา (เมื่อเว็บไซต์มีทราฟฟิกพอ) ผลของการแก้ไขจึงใช้เวลาหลายสัปดาห์กว่าจะปรากฏ

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

เช็กลิสต์ก่อนอัปโหลด

วางไว้ข้างๆ คนที่อัปโหลดภาพ

• ฟอร์แมตเหมาะกับเนื้อหา WebP หรือ AVIF สำหรับภาพถ่าย (หรือ JPEG ถ้าเว็บไซต์แปลงให้อัตโนมัติ) SVG สำหรับโลโก้ PNG หรือ WebP สำหรับภาพหน้าจอ
• Export ที่ความกว้างไม่เกินสองเท่าของความกว้างที่แสดง
• บีบอัดแล้ว ลบเมทาดาทาจากกล้องแล้ว และยังดูดีที่การซูม 100%
• ชื่อไฟล์บอกว่าเป็นภาพอะไร เช่น stainless-steel-tank.webp ไม่ใช่ IMG_4821.jpg
• มี alt text ที่อธิบายสิ่งที่สำคัญ หรือ alt text ว่างถ้าเป็นภาพตกแต่งล้วนๆ
• ข้อความที่เคยอยู่ในภาพ ถูกย้ายไปไว้ในหน้าเว็บแทน
• สัดส่วนตรงกับตำแหน่งภาพ ไม่มีส่วนสำคัญถูกครอปทิ้ง

alt text ยังช่วยให้ Google เข้าใจภาพ แต่เขียนขึ้นเพื่อผู้ใช้โปรแกรมอ่านหน้าจอเป็นอันดับแรก คู่มือการเข้าถึงเว็บไซต์ ของเรา อธิบายวิธีเขียน

ขั้นตอนต่อไป

เว็บไซต์ช้าลงทีละการอัปโหลด การปรับแต่งภาพจึงได้ผลดีที่สุดเมื่อเป็นระบบ ไม่ใช่การเก็บกวาดเป็นครั้งคราว

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