วิธีปรับขนาดรูปภาพสำหรับเว็บ: ขนาด, Retina และ srcset

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

ผมได้ปรับขนาดภาพฮีโร่เดียวกันถึงสี่รูปแบบและวัดความแตกต่าง: ภาพ JPEG จากกล้องขนาด 4.2MB ที่แสดงผลที่ช่อง 800px โดยไม่ได้แก้ไขใดๆ กลายเป็น WebP ขนาด 94KB โดยไม่มีการสูญเสียคุณภาพที่มองเห็นได้ การปรับขนาดรูปภาพสำหรับเว็บเป็นสิ่งที่ช่วยลดน้ำหนักหน้าเว็บได้มากที่สุด และส่วนใหญ่ขึ้นอยู่กับการตัดสินใจสี่อย่าง ได้แก่ ขนาดการแสดงผล (display size), ตัวคูณ Retina (retina factor), รูปแบบไฟล์ (format) และการบีบอัด (compression) นี่คือขั้นตอนการทำงานที่ผมใช้กับทุกเว็บไซต์ที่เผยแพร่

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

ให้ปรับขนาดรูปภาพแต่ละภาพให้มีแนวกว้างประมาณสองเท่าของความกว้างที่แสดงผล (ค่า retina factor) ส่งออกเป็น WebP บีบอัดที่คุณภาพ 80 และส่ง srcset ladder สั้น ๆ เพื่อให้โทรศัพท์และแล็ปท็อปได้รับไฟล์ที่เหมาะสม สำหรับ hero แบบเต็มความกว้างที่แสดงผลที่ 1920px โดยทั่วไปแล้ว WebP ขนาดเดียวตั้งแต่ 1920 ถึง 2560px ที่คุณภาพ 80 ก็เพียงพอแล้ว หากข้ามขั้นตอนนี้ คุณจะบังคับให้ทุกอุปกรณ์ดาวน์โหลดพิกเซลความละเอียดเดสก์ท็อป

ขนาดภาพสำหรับเว็บควรเป็นเท่าไหร่กันแน่?

ขนาดที่ถูกต้องคือขนาดที่แสดงผล ไม่ใช่ขนาดต้นฉบับ เปิด DevTools ตรวจสอบภาพ อ่านความกว้างของ CSS box ที่ใหญ่ที่สุดที่มันเคยครอบครองในทุก breakpoints จากนั้นจึงส่งออกด้วยความกว้างนั้นคูณด้วยค่า density target ของคุณ

สำหรับภาพประกอบบทความและผลิตภัณฑ์ส่วนใหญ่ที่อยู่ในช่วงที่คาดเดาได้ ฉันจะวัดทุกช่องก่อนส่งออก เพราะการเดาสุ่มเป็นสาเหตุที่ทำให้ภาพ 4000px ไปปรากฏในคอลัมน์ 600px

อย่าปล่อยให้ CSS ทำการลดขนาดเด็ดขาด การใช้ <img> ที่กำหนดสไตล์เป็น width: 400px ก็ยังคงดาวน์โหลดไฟล์เต็ม — เพราะเบราว์เซอร์จะทิ้งพิกเซลส่วนเกินหลังจากที่ไบต์เหล่านั้นถูกส่งผ่านสายสัญญาณไปแล้ว ให้ปรับขนาดต้นฉบับก่อน จากนั้นจึงเชื่อมั่นใน CSS สำหรับการจัดวางเท่านั้น

ขั้นตอนโดยละเอียด: เวิร์กโฟลว์การปรับขนาดของฉัน

นี่คือลำดับขั้นตอนที่ฉันใช้ ฉันได้ทดสอบสิ่งนี้ด้วยการตรวจสอบภาพถ่ายของ Lighthouse และมันผ่านการตรวจสอบ "รูปภาพที่มีขนาดเหมาะสม" ได้อย่างสม่ำเสมอ

• วัดความกว้างที่แสดงผลสูงสุดด้วย DevTools
• คูณด้วย 2 สำหรับจอ Retina (คูณ 3 เฉพาะสำหรับภาพฮีโร่บนโทรศัพท์ที่มีความหนาแน่นสูง)
• ปรับขนาดลงด้วยฟิลเตอร์คุณภาพสูง (Lanczos)
• ส่งออกเป็น WebP ที่คุณภาพ 80 หากไฟล์ยังหนัก ให้ลดเหลือ 75
• สร้าง srcset ladder สำหรับช่องที่ตอบสนอง (responsive slots)
• บีบอัดอีกครั้งหากไฟล์ยังเกิน 200KB

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

เมื่อฉันวัดค่าแล้ว ภาพถ่ายขนาด 4000x2667 (JPEG ขนาด 4.2MB) ได้กลายเป็น WebP ขนาด 1440x960 ที่ 94KB ซึ่งลดลง 98 เปอร์เซ็นต์โดยที่ไม่มีการสูญเสียความคมชัดที่มองเห็นได้บนจอแสดงผลมาตรฐาน กฎเชิงลึกสำหรับการคงรายละเอียดไว้ระหว่างการปรับขนาดลงอย่างรุนแรงอยู่ใน keep quality while resizing

Retina และ 2x: คุณจำเป็นต้องใช้พิกเซลเป็นสองเท่าจริงหรือ?

ส่วนใหญ่คือใช่ สำหรับสิ่งที่ผู้ใช้ดูอย่างใกล้ชิด หน้าจอ 2x บรรจุพิกเซลได้ถึงสี่เท่าในพื้นที่ทางกายภาพเดียวกัน ดังนั้นไฟล์ 1x จึงดูนุ่มนวล กฎที่ปลอดภัยคือ: ให้ส่งออกที่ความกว้าง 2x ของ CSS สำหรับรูปภาพเนื้อหา

จุดที่ฉันจงใจละเมิดกฎนั้น:

• พื้นหลังตกแต่งที่เบลอหรือค่อยๆ จางลงสามารถใช้ค่าใกล้เคียง 1x ได้
• รูปภาพใต้ส่วนพับ (below-the-fold) ที่ความคมชัดไม่สำคัญมาก สามารถใช้ 1.5x ได้
• ไอคอนและโลโก้ควรเป็น SVG ซึ่งเป็นรูปแบบที่ไม่ขึ้นอยู่กับความละเอียด

คำแนะนำรูปภาพของ Google ที่ web.dev image guidance แนะนำให้ใช้ density descriptors หรือ width descriptors; width descriptors ผ่าน srcset นั้นง่ายต่อการทำความเข้าใจ ดังนั้นฉันจึงเลือกใช้วิธีนั้นเป็นค่าเริ่มต้น

การแสดงผลรูปภาพหลายขนาดด้วย srcset

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

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="Hero illustration of a city skyline at dusk"
  width="960" height="640" loading="lazy">

attribute sizes ต้องบอกความจริงเกี่ยวกับพื้นที่ที่แสดงผล หากคุณปล่อยค่าเป็นค่าเริ่มต้นคือ 100vw เบราว์เซอร์จะสันนิษฐานว่ารูปภาพครอบคลุม viewport ทั้งหมดและดาวน์โหลดรูปแบบที่มีขนาดใหญ่ที่สุด การเลือกกำหนดความกว้างที่จะสร้างนั้นเป็นการตัดสินใจในตัวมันเอง — วิธีที่ฉันใช้ในการตัดบันได (trimming the ladder) อยู่ที่ responsive image breakpoints

ขนาดไฟล์เทียบกับมิติภาพ: อะไรสำคัญกว่ากัน?

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

เป้าหมายที่ฉันตั้งไว้คือต่ำกว่า 200KB สำหรับภาพเนื้อหาส่วนใหญ่ และต่ำกว่า 100KB สำหรับส่วนใด ๆ ที่อยู่เหนือขอบเขต (above the fold) ซึ่งส่งผลต่อ Largest Contentful Paint เมื่อไฟล์มีขนาดเกินกว่านั้น สิ่งแรกที่ฉันทำคือการปรับคุณภาพการบีบอัด จากนั้นจึงเป็นรูปแบบไฟล์ การแจกแจงระดับไบต์ว่าการบีบอัดช่วยลดน้ำหนักได้อย่างไรอยู่ใน compress without losing quality.

Lighthouse จะแจ้งเตือนภาพที่มีขนาดใหญ่เกินไปว่าเป็นโอกาสที่ชัดเจน คุณสามารถเรียกใช้จาก Chrome DevTools หรือทำตาม Lighthouse documentation — การตรวจสอบ "properly sized images" จะรายงานว่าคุณสูญเสีย KB ไปเท่าไหร่จากการให้บริการพิกเซลที่มากกว่าที่ช่องนั้นต้องการ

การเลือกรูปแบบที่เหมาะสมที่สุด

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

MDN responsive images guide ครอบคลุมองค์ประกอบ <picture> สำหรับการให้บริการ AVIF พร้อมทางเลือกสำรอง WebP หรือ JPEG ฉันจะใช้ <picture> เมื่อต้องการการเจรจารูปแบบเท่านั้น ส่วนภาพถ่ายที่ตอบสนองธรรมดา srcset เพียงอย่างเดียวก็เพียงพอแล้ว

ข้อผิดพลาดที่ฉันพบเมื่อตรวจสอบเว็บไซต์

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

• การอัปโหลดไฟล์ที่มีความละเอียดระดับกล้องและลดขนาดด้วย CSS.
• ใช้ไฟล์ขนาดใหญ่เพียงไฟล์เดียวสำหรับทุก breakpoint แทนที่จะใช้ srcset ladder.
• ลืมระบุ width และ height ซึ่งทำให้เกิดการเลื่อนของเค้าโครง (layout shift).
• ปล่อยค่า sizes เป็นค่าเริ่มต้น ทำให้เบราว์เซอร์ดึงไฟล์ที่ใหญ่ที่สุดไปใช้.
• โหลดรูปภาพทุกรูปอย่างเร่งรีบ แทนที่จะเลื่อนการโหลดสำหรับรูปภาพที่อยู่ต่ำกว่าส่วนที่มองเห็น (below the fold).

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

สรุป

ก่อนที่ฉันจะเผยแพร่รูปภาพ ฉันจะตรวจสอบรายการเหล่านี้: ปรับขนาดเป็น 2x ของความกว้างการแสดงผลที่ใหญ่ที่สุด, ส่งออกเป็น WebP, บีบอัดให้ต่ำกว่า 200KB, พร้อมด้วย srcset ladder, attribute sizes ที่ถูกต้อง, ความกว้างและความสูงที่ระบุชัดเจน, loading="lazy" สำหรับส่วนที่อยู่ใต้หน้าจอ (below the fold), และ alt text ที่สื่อความหมาย

ข้อควรระวังที่แท้จริงคือ: การปรับขนาดเป็นปัจจัยสำคัญที่สุด แต่ไม่ใช่ทั้งหมด ฉันเคยเห็นทีมงานที่กำหนดมิติได้อย่างสมบูรณ์แบบ แต่ยังคงเผยแพร่หน้าเว็บที่ช้า เพราะพวกเขาให้บริการไฟล์จาก origin โดยไม่มีการแคช (caching), ไม่มี CDN, และไม่มีชื่อไฟล์ที่ผ่านการแฮชเนื้อหา (content-hashed filename) ให้วัดผลด้วย Lighthouse และโปรไฟล์อุปกรณ์จริง จากนั้นเชื่อตัวเลขมากกว่ารายการตรวจสอบ WebP ขนาด 94KB ที่เบราว์เซอร์ดาวน์โหลดซ้ำในการนำทางทุกครั้ง ก็ยังคงเป็นความผิดพลาดขนาด 94KB

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

ภาพฮีโร่บนเว็บไซต์ควรมีขนาดเท่าไหร่?

ให้ตรงกับขนาดการแสดงผล: โดยประมาณ 1600px สำหรับภาพฮีโร่แบบเต็มความกว้าง และ 800–1200px สำหรับรูปภาพในคอลัมน์เนื้อหา การส่งออกที่ขนาด 2x ของขนาดการแสดงผล (สำหรับ retina) จะทำให้จำนวนพิกเซลเพิ่มขึ้นเป็นสองเท่า ควรใช้ srcset เพื่อให้บริการขนาดที่เหมาะสมกับอุปกรณ์แต่ละชนิด แทนที่จะอัปโหลดไฟล์ขนาดใหญ่เพียงไฟล์เดียว

จำเป็นต้องมีภาพ 2x สำหรับหน้าจอ retina หรือไม่?

สำหรับกราฟิกที่คมชัดและภาพฮีโร่ คำตอบคือใช่ — หน้าจอ retina จะแสดงความนุ่มนวลหากไม่มี การใช้ภาพ 1x เพียงไฟล์เดียวมักจะเพียงพอสำหรับส่วนเนื้อหาด้านล่าง (below-the-fold) และรูปภาพตกแต่ง ใช้ srcset เพื่อให้บริการทั้งเวอร์ชัน 1x และ 2x เพื่อที่อุปกรณ์ที่ไม่ใช่ retina จะไม่ดาวน์โหลดไฟล์ขนาดใหญ่

อะไรสำคัญกว่ากัน ระหว่างมิติหรือขนาดไฟล์?

ทั้งสองอย่าง แต่ขนาดไฟล์มีผลต่อ Core Web Vitals มากกว่า ควรปรับขนาดให้ตรงกับมิติการแสดงผลก่อน (เพื่อกำจัดพิกเซลส่วนเกิน) จากนั้นจึงบีบอัดให้อยู่ในคุณภาพเป้าหมาย (เพื่อกำจัดไบต์ส่วนเกิน) web speed guide ได้กล่าวถึงลำดับขั้นตอนทั้งหมด

ฉันจะให้บริการเวอร์ชันที่ตอบสนองได้อย่างไร?

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

srcset คืออะไร?

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

แอตทริบิวต์ sizes คืออะไร?

แอตทริบิวต์ HTML ที่บอกเบราว์เซอร์ว่ารูปภาพจะแสดงความกว้างเท่าใดในแต่ละ breakpoint ทำให้เบราว์เซอร์สามารถเลือกแหล่งที่มาของ srcset ได้อย่างถูกต้องก่อนดาวน์โหลด หากไม่มี sizes เบราว์เซอร์จะต้องคาดเดา ควรจับคู่ srcset (แหล่งที่มา) กับ sizes (ความกว้างในการแสดงผล) สำหรับรูปภาพแบบ responsive ที่ดาวน์โหลดได้อย่างมีประสิทธิภาพ ดู responsive images guide

เครดิตรูปภาพ

• แล็ปท็อป MacBook บนโต๊ะที่แสดงเค้าโครงเว็บไซต์ที่ออกแบบไว้ — photo by Tranmautritam on Pexels
• ภาพระยะใกล้ของจอคอมพิวเตอร์ที่แสดงโค้ดต้นฉบับ — photo by Nemuel Sereti on Pexels
• หน้าจอแล็ปท็อปที่แสดงเว็บไซต์กำลังโหลดในแท็บเบราว์เซอร์ — photo by cottonbro studio on Pexels