วิธีเพิ่มประสิทธิภาพภาพสำหรับเว็บไซต์: คู่มือใช้งานจริง

ภาพมักเป็นส่วนใหญ่ของการส่งหน้าและมีผลต่อการค้นพบ การถอดรหัส เลย์เอาต์ และ Largest Contentful Paint การปรับแต่งให้ผลดีได้ แต่ไม่มีการประหยัดตายตัวหรือผลอันดับที่ใช้กับทุกหน้า นี่คือกระบวนการที่วัดได้ทีละขั้น

ทำไมการปรับแต่งรูปจึงสำคัญกว่าที่เคย

รายงานน้ำหนักหน้าของ HTTP Archive แสดงว่าภาพยังสำคัญในหลายหน้าแม้ค่ากลางเปลี่ยน Largest Contentful Paint (LCP) วัดเวลาที่องค์ประกอบที่เข้าเกณฑ์ใหญ่ที่สุดใน viewport ถูกวาด ซึ่งมักเป็นภาพแต่ไม่เสมอ

เกณฑ์ LCP ของ Google ถือไม่เกิน 2.5 วินาทีว่าดีและเกิน 4 วินาทีว่าแย่ ที่เปอร์เซ็นไทล์ 75 ของการเข้าชม งานภาพอาจย้ายหน้าระหว่างเกณฑ์เมื่อทรัพยากร LCP เป็นคอขวด แต่เพียงอย่างเดียวไม่รับประกันผ่าน Core Web Vitals หรือตำแหน่งค้นหา

ขั้นตอนที่ 1: เลือกฟอร์แมตที่ถูกต้อง

การเลือกรูปแบบมีผลมากต่อขนาดและความสามารถ การเปรียบเทียบนี้เป็นเชิงคุณภาพเพราะ benchmark ขึ้นกับต้นทาง ตัวเข้ารหัส การตั้งค่า และเป้าคุณภาพ:

WebP เป็นตัวเลือกเริ่มต้นที่มีประโยชน์ ไม่ใช่คำตอบสากล หากกระบวนการและผู้ใช้รองรับ AVIF ให้ทดสอบเป็น <source> ก่อนพร้อม WebP หรือ JPEG สำรอง ใช้ Vizua แปลง JPG เป็น WebP หรือ เป็น AVIF ไฟล์ประมวลผลในเบราว์เซอร์และไม่ส่งไปเซิร์ฟเวอร์

อ่านเพิ่มในบทเปรียบเทียบ WebP กับ AVIF และคำอธิบายการบีบอัดสูญเสียกับไม่สูญเสีย

ขั้นตอนที่ 2: ย่อขนาดให้ตรงกับขนาดที่แสดงจริง

ภาพ 4000 × 3000 พิกเซลที่แสดง 800 × 600 มีพิกเซลต้นทางมากกว่าช่องต้องการมาก จอความหนาแน่นสูงแบบตอบสนองอาจต้องใช้ตัวเลือกใหญ่กว่า แต่การส่งต้นฉบับจากกล้องมักเพิ่มการส่งและถอดรหัสโดยไม่จำเป็น

หลักคือเสนอตัวเลือกใกล้ขนาดและความหนาแน่นที่วาด ใช้ srcset และ sizes ให้เบราว์เซอร์เลือก และคำนึงความกว้างเลย์เอาต์ ความหนาแน่นอุปกรณ์ คุณภาพ ซูม และ art direction แทนตัวคูณ “Retina” ตายตัว

ตัวอย่างขนาดเริ่มต้นเพื่อปรับตามเลย์เอาต์:

• Hero เต็มความกว้าง: เริ่มจากช่องวาดใหญ่สุด แล้วสร้างตัวเลือกสำหรับความหนาแน่นและ breakpoint ที่เกี่ยวข้อง
• ภาพเนื้อหา: ให้ตรงคอลัมน์และสถานะตอบสนองที่กว้างกว่า
• ภาพย่อ: สร้างตัวเลือกใกล้แต่ละขนาดการ์ด แทนใช้ hero ซ้ำ
• อวตาร: คำนึงวงกลมหรือสี่เหลี่ยม ความหนาแน่น และหน้ารายละเอียด

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

ขั้นตอนที่ 3: บีบอัดด้วยค่าคุณภาพที่เหมาะสม

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

ค่าคุณภาพที่แนะนำ:

• JPEG: 75–85 เป็นช่วงเริ่มต้นแบบระวังสำหรับภาพถ่าย มาตราส่วนต่างกัน ควรตรวจผล
• WebP: 75–80 เป็นช่วงเริ่มต้น ไม่รับประกันว่าเท่าค่า JPEG
• AVIF: 60–75 อาจเป็นจุดเริ่มในบางเครื่องมือ มาตราส่วนและตัวเข้ารหัสต่างกัน
• PNG: ลองบีบอัดไม่สูญเสียแรงขึ้นก่อน ลดพาเลตสูงสุด 256 รายการอาจประหยัดเพิ่ม แต่เป็นการลดสีแบบสูญเสียและต้องตรวจ

ตัวบีบอัด JPEG ของ Vizua ให้ปรับคุณภาพและตรวจผล วิธีละเอียดอยู่ในการบีบอัดโดยไม่เสียคุณภาพ

ขั้นตอนที่ 4: ส่งรูปอย่างมีประสิทธิภาพ

การบีบอัดเป็นแค่ครึ่งเดียวของงาน วิธีที่คุณส่งรูปไปยังเบราว์เซอร์สำคัญพอๆ กัน

ตั้งขนาดให้ชัดเจน

ให้แต่ละ <img> มี width และ height ภายในที่แม่นยำ หรือจองช่องด้วยกฎเลย์เอาต์ เบราว์เซอร์ตั้งอัตราส่วนเร็วและลดการเลื่อนจากภาพ แต่ฟอนต์ เนื้อหาแทรก แอนิเมชัน และสไตล์ผิดยังมีผลต่อ Cumulative Layout Shift (CLS)

Lazy-load รูปที่อยู่ต่ำกว่า Fold

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

ให้ความสำคัญกับรูป Hero

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

ใช้ Responsive Images

srcset และ sizes ให้ตัวเลือกและอธิบายช่อง เบราว์เซอร์คำนึง viewport ความหนาแน่น แคช และการทำงาน ให้ sizes ตรงเลย์เอาต์ มิฉะนั้นอาจเลือกภาพใหญ่หรือเล็กเกิน

ขั้นที่ 5: ตรวจและวัดสม่ำเสมอ

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

• PageSpeed Insights: ใช้ PageSpeed Insights กับหน้าตัวแทน แยกดู LCP ภาคสนามและห้องทดสอบ แล้วตรวจคำวินิจฉัยปัจจุบัน ไม่ยึดป้าย audit ที่เปลี่ยนได้
• Network ใน DevTools: เรียงคำขอตามขนาดและดูภาพใหญ่ในบริบท ตรวจว่ามิติ รูปแบบ การบีบอัด แคช และลำดับตรงบทบาท แทนกำหนด KB เดียว
• ทำอัตโนมัติ: เพิ่มการปรับภาพใน build เพื่อพบภาพใหญ่เกินก่อนเผยแพร่

Checklist สรุปฉบับย่อ

• สร้างและเปรียบเทียบ JPEG, WebP, AVIF, PNG หรือ SVG ที่เหมาะสม
• ปรับตามขนาดแสดงจริง ไม่กว้างเกินจำเป็น
• เริ่มจากการตั้งค่าแบบระวัง เปรียบเทียบไบต์และภาพ ไม่เทียบตัวเลขคุณภาพข้ามรูปแบบ
• จองช่องแม่นยำให้ทุก <img> โดยทั่วไปใช้ width และ height ภายใน
• พิจารณา fetchpriority="high" สำหรับภาพ LCP แล้ววัด
• เลื่อนภาพนอกหน้าจอที่เหมาะสม ทดสอบการเลื่อนและเลย์เอาต์
• ใช้ srcset/sizes สำหรับ Responsive Delivery
• กำหนดงบประสิทธิภาพจากหน้า ผู้ใช้ และข้อมูลจริง
• ลบข้อมูลกำกับส่วนตัวที่ไม่จำเป็น แต่เก็บโปรไฟล์สีหรือข้อมูลที่กระบวนการต้องใช้ — ดู EXIF และความเป็นส่วนตัว
• ตรวจสอบเป็นระยะด้วย PageSpeed Insights

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