ปรับภาพสำหรับความเร็วเว็บ: ลดการโหลดหน้าโดยไม่สูญเสียคุณภาพ

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

โดยปกติแล้ว รูปภาพมักจะเป็นส่วนที่หนักที่สุดของหน้าเว็บ ดังนั้นการปรับให้เหมาะสมจึงเป็นการเปลี่ยนแปลงที่มีผลกระทบสูงสุดที่คุณสามารถทำได้สำหรับความเร็วของหน้า (page speed) วิธีการนี้ตรงไปตรงมา: คือการให้บริการขนาดที่ถูกต้อง รูปแบบที่ถูกต้อง และการบีบอัดที่เหมาะสม จากนั้นจึงเลื่อนการโหลดสำหรับรูปภาพที่ผู้ใช้ไม่ได้เห็นในทันที คู่มือนี้จะครอบคลุมขั้นตอนที่เป็นรูปธรรมที่จะลดน้ำหนักของรูปภาพและเวลาในการโหลดโดยที่คุณภาพยังคงมองเห็นได้ และแสดงให้เห็นว่าการปรับปรุงเหล่านี้ปรากฏใน Core Web Vitals ได้อย่างไร

คำตอบสั้นๆ: จะปรับปรุงรูปภาพให้เร็วสำหรับเว็บได้อย่างไร?

Resize รูปภาพแต่ละรูปให้มีมิติเท่ากับที่แสดงผลจริง, แปลงเป็น WebP (หรือใช้ AVIF พร้อมการสำรองข้อมูล), compress ที่คุณภาพ 80, และให้บริการรูปแบบที่ตอบสนองด้วย srcset เพื่อให้แต่ละอุปกรณ์โหลดขนาดที่ถูกต้อง ใช้การ Lazy-load สำหรับรูปภาพส่วนล่างหน้า และส่งมอบจาก CDN ลำดับขั้นตอนเหล่านี้สามารถลดน้ำหนักของรูปภาพได้ถึง 70 เปอร์เซ็นต์หรือมากกว่าโดยไม่มีการสูญเสียคุณภาพที่มองเห็นได้ ซึ่งช่วยปรับปรุง Largest Contentful Paint metric และประสิทธิภาพการโหลดหน้าเว็บโดยรวมได้อย่างมาก

ทำไมรูปภาพจึงมีน้ำหนักมากที่สุดของหน้าเว็บ?

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

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

ขั้นตอนที่ 1: ปรับขนาดให้ตรงกับมิติการแสดงผล

ห้ามส่งจำนวนพิกเซลเกินกว่าที่ภาพจะแสดงได้เด็ดขาด Resize ให้มีขนาดความกว้างการแสดงผลที่ใหญ่ที่สุด โดยคูณด้วย 2 เพื่อความคมชัดระดับ Retina

• วัดช่องแสดงผล ไม่ใช่ความละเอียดต้นฉบับ
• คูณด้วย 2 สำหรับหน้าจอ Retina (คูณ 3 สำหรับโทรศัพท์ที่หนาแน่น)
• ปรับขนาดก่อนบีบอัด — พิกเซลน้อยลงจะทำให้ไฟล์เล็กลง
• คู่มือการปรับขนาด ครอบคลุมวิธีการทำสิ่งนี้อย่างสะอาดตา

ขั้นตอนที่ 2: แปลงเป็นรูปแบบสมัยใหม่

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

• AVIF — มีขนาดเล็กที่สุด รองรับเพิ่มขึ้น ให้ใช้ WebP หรือ JPEG เป็นตัวสำรอง
• WebP — ค่าเริ่มต้นที่ใช้งานได้จริง รองรับอย่างกว้างขวาง และมีขนาดเล็กกว่า JPEG มาก
• JPEG — ตัวสำรองสากลสำหรับเบราว์เซอร์ที่ไม่รองรับ
• SVG — สำหรับโลโก้และไอคอน สามารถปรับขนาดได้ไม่จำกัดและมีขนาดเล็กมาก

บทความ format comparison และ AVIF vs WebP guide ได้กล่าวถึงข้อดีข้อเสียต่างๆ ใช้องค์ประกอบ <picture> เพื่อให้บริการ AVIF เป็นอันดับแรก พร้อมด้วยตัวสำรอง WebP และ JPEG

ขั้นตอนที่ 3: บีบอัดให้ได้คุณภาพเป้าหมาย

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

ทดสอบที่การซูม 100% เพื่อยืนยันว่าไม่มีสิ่งผิดปกติที่มองเห็นได้ compression guide ได้รวบรวมเทคนิคต่างๆ ไว้

ขั้นตอนที่ 4: การให้บริการรูปภาพแบบ Responsive และการโหลดแบบ Lazy-load

หน้าจอที่แตกต่างกันต้องการขนาดที่ต่างกัน และรูปภาพที่อยู่ใต้ขอบเขตการมองเห็น (below-the-fold) ไม่จำเป็นต้องโหลดทันที ควรจัดการทั้งสองอย่างนี้ด้วย Markup.

• ใช้ srcset พร้อมกับตัวระบุความกว้าง (width descriptors) เพื่อให้แต่ละอุปกรณ์ได้รับไฟล์ที่ถูกต้อง.
• เพิ่ม loading="lazy" ให้กับรูปภาพที่อยู่ใต้ขอบเขตการมองเห็น เพื่อเลื่อนการโหลดออกไป.
• เก็บรูปภาพ Hero Image ให้เป็นแบบ eager-loaded เพื่อให้องค์ประกอบ LCP โหลดได้อย่างรวดเร็ว.
• กำหนดแอตทริบิวต์ width และ height เสมอ เพื่อป้องกันการเลื่อนของเค้าโครง (layout shift).

คู่มือรูปภาพแบบ responsive และ คู่มือการโหลดแบบ lazy loading จะครอบคลุมรายละเอียดของการนำไปใช้งาน.

ความเร็วของรูปภาพส่งผลต่อ Core Web Vitals อย่างไร?

การปรับปรุงรูปภาพให้เหมาะสมส่งผลกระทบโดยตรงต่อเมตริก Largest Contentful Paint (LCP) ซึ่งมักจะใช้วัดความเร็วในการโหลดรูปภาพหลัก (hero image). รูปภาพหลักที่มีขนาดใหญ่และโหลดช้าจะทำให้ค่า LCP เกินเกณฑ์ 2.5 วินาทีที่ Google ถือว่า "ดี" ซึ่งส่งผลเสียต่อทั้งประสบการณ์ผู้ใช้และการจัดอันดับการค้นหา (search ranking). Core Web Vitals guide และ image SEO guide เชื่อมโยงผลลัพธ์เหล่านี้กับการจัดอันดับ และ web.dev LCP documentation อธิบายเมตริกนี้ ส่วน Mozilla performance guide ครอบคลุมภาพรวมของการวัดผลที่กว้างขึ้น — ให้รัน PageSpeed Insights หลังจากปรับปรุงเพื่อยืนยันว่า LCP ดีขึ้น.

ตัวอย่างการทำงานจริง: การปรับปรุงภาพฮีโร่เพียงภาพเดียว

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

1. ปรับขนาด จาก 5000px เป็น 2400px (แสดงผล 1200 × 2 สำหรับจอเรตินา) ไฟล์จะเล็กลงทันทีเนื่องจากจำนวนพิกเซลลดลงกว่า 75 เปอร์เซ็นต์
2. แปลง จาก JPEG เป็น WebP การเปลี่ยนรูปแบบเพียงอย่างเดียวมักจะลดขนาดลงอีก 25-35 เปอร์เซ็นต์ที่คุณภาพเท่ากัน
3. บีบอัด เป็นคุณภาพ 80 การสูญเสียที่มองเห็นได้นั้นน้อยมาก แต่ขนาดไบต์จะลดลงอีก
4. ให้บริการ ด้วย srcset ที่มีตัวเลือก 1200w และ 2400w เพื่อให้โทรศัพท์มือถือได้รับไฟล์ที่เล็กกว่า
5. โหลดแบบขี้เกียจ (Lazy-load) หากไม่ใช่องค์ประกอบ LCP หรือคงการโหลดทันทีหากเป็นส่วนฮีโร่

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

การทำให้การปรับปรุงประสิทธิภาพทั่วทั้งเว็บไซต์เป็นแบบอัตโนมัติ

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

เครื่องมือ build-step ที่รัน WebP conversion และ compression กับทุกรูปภาพระหว่างการ deploy จะช่วยให้มั่นใจได้ว่าไม่มีรูปภาพที่ไม่ได้ปรับปรุงประสิทธิภาพใด ๆ เข้าสู่ production สำหรับเว็บไซต์ที่ขับเคลื่อนด้วย CMS, ปลั๊กอินที่ปรับปรุงประสิทธิภาพขณะอัปโหลดจะดักจับรูปภาพตั้งแต่แหล่งกำเนิด และสำหรับเว็บไซต์ที่มี layout ที่คาดเดาไม่ได้, CDN ที่แปลงข้อมูลแบบ on the fly จะจัดการเรื่องขนาดโดยไม่ต้องสร้าง variants ด้วยตนเอง การทำให้เป็นอัตโนมัติที่เหมาะสมขึ้นอยู่กับ stack แต่หลักการยังคงเหมือนเดิม — คือการทำให้การปรับปรุงประสิทธิภาพกลายเป็นค่าเริ่มต้น เพื่อไม่ให้ต้องอาศัยความจำของบุคคลในการดำเนินการ

การวัดผลลัพธ์

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

1. รัน Google PageSpeed Insights และตรวจสอบคำแนะนำสำหรับรูปภาพ
2. ยืนยันว่า LCP อยู่ต่ำกว่า 2.5 seconds
3. ตรวจสอบแท็บ network เพื่อดูขนาดไฟล์ที่ถูกส่งมอบจริง
4. ทดสอบบนการเชื่อมต่อแบบ mobile ไม่ใช่แค่ broadband

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

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

อะไรคือวิธีเพิ่มความเร็วภาพถ่ายได้มากที่สุด?

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

ฉันควรทำ lazy-load กับภาพทุกภาพหรือไม่?

ทุกอย่างที่อยู่ใต้ส่วนพับ (below the fold) ใช่ ส่วนภาพหลักที่เป็น LCP ต้องโหลดแบบ eagerly (และควรมีการ preload); การทำ lazy-loading จะทำให้องค์ประกอบที่ใหญ่ที่สุดล่าช้าและส่งผลเสียต่อ Core Web Vitals ควรทำ lazy-load กับส่วนอื่น ๆ เพื่อไม่ให้แย่งแบนด์วิดท์กับภาพหลัก

ฉันจะวัดความเร็วของรูปภาพได้อย่างไร?

ข้อมูลภาคสนามจาก PageSpeed Insights ในช่วงเวลา 28 วัน ไม่ใช่การทดสอบในห้องปฏิบัติการเพียงครั้งเดียว เครื่องมือในห้องปฏิบัติการ (Lighthouse) แสดงศักยภาพ; ส่วนข้อมูลภาคสนามแสดงสิ่งที่ผู้ใช้จริงประสบพบเจอ CWV จะถูกให้คะแนนจากข้อมูลภาคสนาม

รูปแบบใดที่เร็วที่สุดสำหรับเว็บ?

WebP เป็นค่าเริ่มต้นที่ปลอดภัย (มีขนาดเล็กกว่า JPEG 25–35 เปอร์เซ็นต์ และรองรับทั่วไป) หรือใช้ AVIF สำหรับไฟล์ที่มีขนาดเล็กที่สุดบนเบราว์เซอร์สมัยใหม่ ควรให้บริการรูปแบบที่ทันสมัยพร้อมด้วยการสำรองข้อมูลเป็น JPEG ผ่านองค์ประกอบ <picture>

ฉันจะแสดงรูปภาพแบบ responsive ได้อย่างไร?

สร้างรูปภาพแต่ละภาพตามขนาดที่ breakpoint ของคุณต้องการ จากนั้นใช้ srcset พร้อมกับแอตทริบิวต์ sizes เพื่ออธิบายความกว้างในการแสดงผล ปล่อยให้เบราว์เซอร์เลือกไฟล์ที่เหมาะสมสำหรับ viewport นั้น ๆ เบราว์เซอร์จะดาวน์โหลดเฉพาะรูปแบบที่จำเป็น ซึ่งช่วยประหยัดไบต์บนหน้าจอขนาดเล็ก ดู responsive images guide สำหรับการตั้งค่าทั้งหมด

Lazy loading คืออะไร?

คุณสมบัติของเบราว์เซอร์ที่หน่วงการโหลดรูปภาพจนกว่าจะอยู่ใกล้ viewport ทำให้รูปภาพใต้ส่วนพับไม่แย่งแบนด์วิดท์กับภาพหลัก ควรเพิ่ม loading="lazy" ให้กับรูปภาพที่อยู่ใต้ส่วนพับ ภาพหลักที่เป็น LCP ต้องโหลดแบบ eagerly (ไม่ใช่ lazy) เพราะการทำ lazy-loading จะทำให้องค์ประกอบที่ใหญ่ที่สุดล่าช้าและส่งผลเสียต่อ Core Web Vitals