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

ปรับปรุงล่าสุด: June 28, 2026

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

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

รูปภาพมักจะมีน้ำหนักรวมของหน้าเว็บถึง 60 ถึง 80 เปอร์เซ็นต์ และในหน้าที่มีรูปภาพเยอะ พวกมันคือปัจจัยหลักที่สุดที่ส่งผลต่อเวลาโหลด การแก้ไขทั้งสี่อย่างที่จะสร้างความเปลี่ยนแปลงมากที่สุดคือการให้บริการด้วยรูปแบบสมัยใหม่ (modern format) ที่ขนาดแสดงผลที่แน่นอน, การบีบอัดให้มีคุณภาพที่เหมาะสม, การใช้ lazy-loading กับสื่อที่อยู่ below-the-fold และการวาง assets ไว้หลัง CDN

จากที่ฉันวัดบนบล็อกของลูกค้า การเปลี่ยนแปลงทั้งสี่อย่างนี้ได้ลดน้ำหนักหน้าเว็บจาก 3.4 MB เป็น 690 KB และลด Largest Contentful Paint จาก 4.8 seconds เหลือ 1.9 seconds เริ่มต้นด้วยรูปภาพที่มีขนาดใหญ่ที่สุดและทำการวัดผลก่อนและหลัง

ทำไมรูปภาพถึงทำให้เว็บไซต์ของคุณช้าลง?

รูปภาพทุกรูปคือการร้องขอเครือข่าย (network request) บวกกับไบต์ที่เบราว์เซอร์ต้องดาวน์โหลด ถอดรหัส และวาด เมื่อดูจากหน้าเว็บทั่วไป ไบต์เหล่านี้มีน้ำหนักมากกว่าองค์ประกอบอื่น ๆ อย่างมาก ผมได้แจกแจงน้ำหนักบนไซต์ลูกค้าเดียวกันนี้ โดยจัดเรียงตามหมวดหมู่:

รูปภาพมีขนาดใหญ่กว่าทุกหมวดหมู่รวมกัน ซึ่งเป็นเหตุผลที่ว่างานด้านรูปภาพจะให้ผลตอบแทนเร็วกว่าการเปลี่ยนแปลงใด ๆ อื่น ๆ ไบต์เดียวกันยังทำให้เกิดค่าใช้จ่ายในการถอดรหัส (decode time): ภาพถ่าย 4 MB สามารถบล็อก main thread ได้ในขณะที่เบราว์เซอร์กำลังคลายการบีบอัด แม้กระทั่งหลังจากดาวน์โหลดเสร็จสิ้นแล้วก็ตาม

กลไกสามอย่าง เรียงตามความถี่ที่ผมพบ สามารถอธิบายถึงการชะลอตัวได้ดังนี้:

• Excess bytes — การส่งภาพถ่าย 4000-pixel เข้าไปในช่องขนาด 400-pixel
• Wrong format — ใช้ PNG สีเต็มสำหรับรูปถ่าย แทนที่จะเป็น WebP
• Unoptimized delivery — ไม่มี CDN, ไม่มี caching, และไม่มี responsive variants

สองข้อแรกเกี่ยวกับสิ่งที่คุณส่งออก ส่วนข้อที่สามเกี่ยวกับการส่งออกมัน แต่ละข้อมีวิธีแก้ไขที่ชัดเจน ซึ่งจะกล่าวถึงด้านล่าง

น้ำหนักหน้าเว็บส่งผลให้เสียเวลาไปกี่วินาทีกันแน่?

น้ำหนักหน้าเว็บจะถูกแปลงเป็นวินาทีผ่านเครือข่าย กฎคร่าวๆ ที่มีประโยชน์คือ โทรศัพท์ระดับกลางที่เชื่อมต่อด้วย 4G จะดาวน์โหลดได้ประมาณ 1 ถึง 1.5 MB ต่อวินาทีในโลกความเป็นจริง ไม่ใช่ค่าสูงสุดทางทฤษฎี ดังนั้น หน้าเว็บขนาด 3.4 MB จึงใช้เวลาประมาณ 3 วินาทีในการดึงข้อมูล ก่อนที่เบราว์เซอร์จะทำงานใดๆ

ผมได้วัดค่านี้โดยตรงบนเว็บไซต์ลูกค้า โดยคงทุกอย่างให้เท่าเดิมและเปลี่ยนเฉพาะน้ำหนักของรูปภาพเท่านั้น:

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

ต้องเสิร์ฟรูปแบบและขนาดที่เหมาะสมได้อย่างไร?

ข้อได้เปรียบที่ยิ่งใหญ่ที่สุดคือการแปลงภาพถ่ายจาก JPG และ PNG ไปเป็นรูปแบบที่ทันสมัยและปรับขนาดให้เหมาะสมกับพื้นที่แสดงผล WebP มีขนาดเล็กกว่า JPG ประมาณ 25 ถึง 35 เปอร์เซ็นต์ ที่คุณภาพที่รับรู้เท่ากัน; AVIF ทำได้มากกว่านั้นแต่มีความเร็วในการเข้ารหัสที่ไม่สม่ำเสมอ ผมจึงเลือกใช้ WebP เป็นค่าเริ่มต้นเพราะมันถอดรหัสได้เร็วและใช้งานได้ทุกที่ในปี 2026

1. ปรับขนาดให้เหมาะสมกับพื้นที่แสดงผล ภาพถ่ายความละเอียด 4000-pixel ในช่องขนาด 400-pixel มีขนาดใหญ่กว่าที่จำเป็นถึงสิบเท่า ควรจำกัดภาพเนื้อหาไว้ที่ 1600 ถึง 1920 pixels ที่ด้านยาว

2. แปลงเป็น WebP ที่คุณภาพ 75 ถึง 82 ช่วงนี้แทบจะไม่แตกต่างจากต้นฉบับสำหรับภาพถ่ายและช่วยลดขนาดไฟล์ได้มากที่สุด หากลดต่ำกว่านี้ จะเกิดการไล่ระดับสี (banding) ในท้องฟ้าและบริเวณที่ไล่เฉดสี

3. เก็บรูปแบบ AVIF ไว้สำหรับส่วนฮีโร่เท่านั้น หากคุณรองรับ เพราะการเข้ารหัส AVIF นั้นช้า และคุ้มค่าเฉพาะกับภาพที่จะกลายเป็นองค์ประกอบ Largest Contentful Paint ของคุณ

สำหรับขนาดที่แน่นอนตามกรณีการใช้งาน คู่มือ resize image for web guide มีตัวเลขเหล่านั้น ส่วนขั้นตอนการทำงาน compress images without losing quality จะแนะนำการตั้งค่า WebP ที่ผมใช้เพื่อให้ได้คุณภาพโดยไม่มีสิ่งผิดปกติ

ต้องบีบอัดและแปลงไฟล์อย่างไรก่อนนำไปใช้งานจริง?

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

## Convert a hero to WebP at display size, quality 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

สำหรับทั้งไดเรกทอรี ผมใช้ลูปเล็กๆ ที่สร้างความกว้างหลายแบบ หลักการสำคัญคือห้ามคอมมิตภาพดิบขนาด 5 MB เด็ดขาด

• กำหนดระดับคุณภาพขั้นต่ำที่ 70 สำหรับเนื้อหา และ 75 สำหรับภาพสินค้า จากนั้นปรับจูนด้วยสายตาบนภาพจริง
• ลบเมทาดาต้า (EXIF, color profiles ที่ไม่จำเป็น) — สิ่งเหล่านี้สามารถเพิ่มขนาดได้หลายสิบกิโลไบต์โดยไม่มีประโยชน์ทางสายตาเลย
• สร้างรูปแบบที่ปรับให้เหมาะสมสำหรับแต่ละ breakpoint แทนที่จะเป็นภาพขนาดใหญ่เพียงภาพเดียวสำหรับทุกอุปกรณ์
• ทำให้เป็นระบบอัตโนมัติใน CI เพื่อให้มั่นใจว่าภาพที่ไม่ได้ปรับปรุงจะไม่สามารถไปถึง Production ได้

ข้อผิดพลาดทั่วไปคือการบีบอัดไฟล์ที่อัปโหลด แต่ลืม thumbnail และ responsive variant ทุกตัวที่ CMS สร้างขึ้น ให้รัน pipeline ครอบคลุมทุกขนาด ไม่ใช่แค่ต้นฉบับ นี่คือขั้นตอนที่ผมวัดได้ว่าน้ำหนักหน้าเว็บลดลงมากที่สุด — บ่อยครั้งถึง 70 ถึง 80 percent จากภาพต้นฉบับ

วิธีการทำ lazy-load สำหรับรูปภาพที่อยู่นอกขอบเขตการมองเห็น

รูปภาพที่อยู่ต่ำกว่าส่วนที่มองเห็น (below-the-fold) ไม่ควรขัดขวางการเรนเดอร์ครั้งแรก การทำ native lazy loading สามารถทำได้ด้วยแอตทริบิวต์เดียวโดยไม่จำเป็นต้องใช้ JavaScript

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="รูปถ่ายสินค้าในแสงธรรมชาติ">

มีแอตทริบิวต์สองตัวที่สำคัญกว่าที่หลายคนคิด:

1. loading="lazy" จะเลื่อนการดึงข้อมูล (defer the fetch) จนกว่ารูปภาพจะเข้าใกล้ viewport ทำให้ไม่แย่งชิงกับ first paint
2. width และ height ช่วยให้เบราว์เซอร์จองพื้นที่สำหรับกล่องก่อนที่รูปภาพจะมาถึง ซึ่งช่วยป้องกัน Cumulative Layout Shift

อย่าทำ lazy-load ให้กับรูปภาพ hero หรือ LCP เพราะนั่นจะทำให้องค์ประกอบที่สำคัญที่สุดบนหน้าเว็บล่าช้า กฎที่ฉันใช้คือ: ทำ lazy-load ทุกอย่างที่อยู่ต่ำกว่าส่วนที่มองเห็น และ eager-load รูปภาพเดียวที่ผู้ใช้เห็นเป็นอันดับแรก

CDN ช่วยเพิ่มความเร็วของรูปภาพได้อย่างไร?

CDN จะให้บริการรูปภาพจากเซิร์ฟเวอร์ที่อยู่ใกล้ผู้เยี่ยมชมแต่ละราย ซึ่งช่วยลดการเดินทางไปกลับของเครือข่าย (network round-trip) ที่เป็นตัวกำหนดค่า first paint บนอุปกรณ์มือถือและการรับส่งข้อมูลระหว่างประเทศ เมื่อมีการเพิ่ม CDN เข้ามาหน้ารูปภาพบน client site พบว่าทำให้ LCP ลดลงอีก 400 milliseconds สำหรับผู้เยี่ยมชมที่อยู่นอกภูมิภาคต้นทาง (origin region)

นอกจากนี้ CDN ยังให้คุณสามารถแปลงรูปภาพแบบ on-the-fly ได้ โดยการร้องขอความกว้างหรือรูปแบบใดๆ ผ่าน URL และ edge จะทำการสร้างและแคชข้อมูลนั้น ซึ่งช่วยขจัดความจำเป็นในการสร้างตัวแปร (variants) จำนวนมากล่วงหน้า คู่มือ image CDN guide ครอบคลุมรายละเอียดของ headers และ cache keys

ตั้งค่า Cache-Control: max-age=31536000, immutable ที่ยาวนานบน URL รูปภาพที่มีการทำ fingerprinted เพื่อให้ผู้เยี่ยมชมที่กลับมาใช้ซ้ำได้ ล้างแคชเมื่อมีการ deploy เมื่อ fingerprint เปลี่ยนแปลง

รูปภาพแบบ Responsive เข้ามาเกี่ยวข้องอย่างไร?

รูปภาพแบบ Responsive จะบอกให้เบราว์เซอร์รู้ว่าต้องดาวน์โหลด variant ใดสำหรับ viewport ปัจจุบัน เพื่อที่โทรศัพท์จะไม่ดึงรูป hero ของเดสก์ท็อปมาใช้เลย คุณสมบัติ srcset และ sizes เป็นวิธีแบบ native ที่ไม่ต้องพึ่งพา dependency ในการทำสิ่งนี้

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Hero image of a laptop browser loading a website">

เบราว์เซอร์จะเลือก variant ที่เล็กที่สุดที่ยังคงเติมเต็มช่องว่างตามอัตราส่วนพิกเซลของอุปกรณ์ สำหรับโทรศัพท์มือถือซึ่งมักจะเป็นไฟล์ 640w จะมีขนาดเพียงหนึ่งในสี่ไบต์ของไฟล์ 1920w ให้เพิ่ม fetchpriority="high" เข้าไปที่รูปภาพ LCP เพื่อให้เบราว์เซอร์จัดลำดับความสำคัญในการโหลดในช่วงต้น

ต้องวัดผลกระทบของรูปภาพอย่างไร?

คุณไม่สามารถปรับปรุงสิ่งที่คุณไม่ได้วัดได้ เครื่องมือสองตัวนี้ครอบคลุมงานที่เกี่ยวข้องกับรูปภาพเป็นอย่างดี

• PageSpeed Insights — รันที่ pagespeed.web.dev มันจะรายงานข้อมูลภาคสนามจากผู้ใช้จริง และแจ้งเตือนรูปภาพที่มีขนาดใหญ่เกินไปและรูปแบบ next-gen ที่ขาดหายไปโดยตรง
• Lighthouse — การตรวจสอบในห้องปฏิบัติการที่อยู่เบื้องหลัง PageSpeed Insights Chrome ได้บันทึกการตรวจสอบรูปภาพของตนไว้ใน คู่มือสำหรับนักพัฒนา Lighthouse มันจะระบุชื่อรูปภาพเฉพาะที่ทำให้เสียไบต์
• Chrome DevTools Network tab — กรองตาม Img เรียงตามขนาด และจดบันทึกรูปภาพที่กินทรัพยากรมากที่สุด นี่คือวิธีที่ฉันค้นหารูปภาพหนึ่งหรือสองรูปที่ควรแก้ไขเป็นอันดับแรก
• WebPageTest — แผนผังน้ำตกและฟิล์มสตรีปที่แสดงให้เห็นว่ารูปภาพแต่ละรูปดาวน์โหลดเมื่อใด และส่งผลกระทบต่อเลย์เอาต์อย่างไร

เมื่อผลลัพธ์ในห้องปฏิบัติการและภาคสนามไม่ตรงกัน ให้เชื่อข้อมูลภาคสนาม คะแนนในห้องปฏิบัติการที่ยอดเยี่ยมบนเครื่องที่เร็วผ่าน Wi-Fi นั้นแทบไม่มีความหมายเลย หากผู้ใช้มือถือจริงที่ 4G ยังคงต้องรอ เนื่องจากรูปภาพขับเคลื่อน Largest Contentful Paint บนหน้าส่วนใหญ่ งานด้านรูปภาพจึงเป็นงานของ Core Web Vitals ด้วยเช่นกัน — คู่มือ optimizing images for Core Web Vitals ได้เชื่อมโยงทั้งสองสิ่งเข้าด้วยกัน

สิ่งที่ควรหลีกเลี่ยงคืออะไร?

• การไล่ตามคะแนนที่สมบูรณ์แบบ ไม่ใช่ผู้ใช้จริง คะแนน 100 ในห้องแล็บก็ไร้ค่า หากค่า LCP ในภาคสนามยังอยู่ที่ 4 seconds
• การบีบอัดมากเกินไป การลดคุณภาพมากเกินไปช่วยประหยัด bytes ได้ แต่ทำลายภาพถ่ายสินค้า ควรทดสอบด้วยรูปภาพจริง ไม่ใช่แค่ตัวอย่าง
• การละเลยอุปกรณ์มือถือ การเข้าชมส่วนใหญ่และการโหลดที่ช้าส่วนใหญ่มาจาก mobile ควรปรับให้เหมาะสมกับโทรศัพท์ระดับกลางบน 4G ไม่ใช่ dev laptop ของคุณ
• การปรับปรุงเพียงครั้งเดียว ประสิทธิภาพจะลดลงเมื่อมีการเผยแพร่รูปภาพและ features ใหม่ๆ ควรทดสอบซ้ำหลังจากการ release ทุกครั้ง
• การใช้รูปภาพขนาดใหญ่เพียงรูปเดียวสำหรับทุกอุปกรณ์ หากไม่มี srcset โทรศัพท์จะดาวน์โหลดภาพฮีโร่ของเดสก์ท็อป

ข้อสรุปหลัก

รูปภาพเป็นปัจจัยที่ส่งผลต่อความเร็วของเว็บไซต์มากที่สุด เนื่องจากเป็นส่วนที่มีน้ำหนักหน้าเว็บมากที่สุด การแก้ไขทั้งสี่อย่าง ได้แก่ รูปแบบที่ทันสมัยตามขนาดการแสดงผล, การบีบอัด (compression), lazy-loading, และ CDN นั้นอาจดูไม่หวือหวา แต่สิ่งเหล่านี้คือสิ่งที่ทำให้เว็บไซต์ของลูกค้าผมลดลงจาก 3.4 MB และ LCP 4.8 วินาที เหลือเพียง 690 KB และ LCP 1.9 วินาที ให้ทำตามลำดับนี้ วัดผลในแต่ละขั้นตอน และแก้ไขรูปภาพที่ใหญ่ที่สุดก่อน

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

แหล่งที่มาของรูปภาพ

• จอคอมพิวเตอร์ที่ทันสมัยแสดงงานออกแบบเว็บในพื้นที่ทำงานสร้างสรรค์ — photo by Tranmautritam on Pexels
• ภาพระยะใกล้ของหน้าจอแล็ปท็อปที่แสดงการโหลดหน้าเครื่องมือค้นหา — photo by cottonbro studio on Pexels
• นักพัฒนาที่กำลังพิมพ์โค้ดบนแล็ปท็อปในพื้นที่ทำงานที่มีสมาธิ — photo by olia danilevich on Pexels