คู่มือการปรับปรุงภาพสำหรับมือถือเพื่อหน้าเว็บที่เร็วขึ้น

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

การปรับปรุงภาพสำหรับอุปกรณ์มือถือเริ่มต้นด้วยข้อจำกัดหลักข้อหนึ่งคือ โทรศัพท์ไม่ควรดาวน์โหลดพิกเซลที่มันแสดงผลไม่ได้ คุณต้องปรับขนาดแหล่งที่มา (source), เสิร์ฟรูปแบบที่ตอบสนอง (responsive variants), เก็บภาพที่ใหญ่ที่สุดเหนือส่วนพับ (above-the-fold) ให้อยู่นอกการโหลดแบบขี้เกียจ (lazy loading), และเผยแพร่ไฟล์ WebP หรือ AVIF ที่สามารถถูกรวบรวมข้อมูลได้ (crawlable) ผ่าน CDN

คำตอบสั้นๆ: ควรปรับปรุงรูปภาพสำหรับมือถืออย่างไร?

ให้ใช้ลำดับนี้: ปรับขนาดก่อน, เข้ารหัสเป็นอันดับสอง, ส่งมอบเป็นอันดับสาม, วัดผลเป็นอันดับสุดท้าย รูปภาพสินค้าขนาด 4000 px ที่แสดงด้วยความกว้าง 390 px นั้นเป็นการสิ้นเปลืองแม้ว่าจะมีการบีบอัดแล้วก็ตาม เบราว์เซอร์ยังคงต้องดึงข้อมูล (fetch), ถอดรหัส (decode), และปรับขนาด (scale) ก่อนที่หน้าจะพร้อมใช้งานอย่างสมบูรณ์

สำหรับหน้ามือถือส่วนใหญ่ ควรใช้ชุดแหล่งที่มา (source set) ของ WebP หรือ AVIF ที่มีความกว้างประมาณ 400, 800, และ 1200 px ให้เก็บตัวสำรองเป็น JPEG หากกลุ่มเป้าหมายของคุณรวมถึงเบราว์เซอร์รุ่นเก่า, ลูกค้าอีเมล, หรือฟีดของพันธมิตร สำหรับการตัดสินใจรูปแบบที่ลึกขึ้น ให้ใช้ AVIF vs WebP comparison

แนวทางของ Google สำหรับ LCP ระบุว่าหน้าเว็บควรตั้งเป้าหมายที่ Largest Contentful Paint ที่ 2.5 วินาทีหรือน้อยกว่า ณ เปอร์เซ็นไทล์ที่ 75 โดยแยกตามอุปกรณ์มือถือและเดสก์ท็อป รูปภาพมักจะเป็นองค์ประกอบ LCP ดังนั้นรูปภาพฮีโร่จึงควรได้รับการจัดการเป็นพิเศษ: ควร preload หรือให้ความสำคัญกับมัน กำหนดขนาดจริง และไม่ควรใช้ lazy-load

อะไรที่เปลี่ยนไปจริง ๆ บนโทรศัพท์?

โทรศัพท์มือถือมีการเปลี่ยนแปลงสามอย่างพร้อมกัน ได้แก่ ความกว้างของ viewport, คุณภาพเครือข่าย, และความหนาแน่นของการจัดวาง (layout density) รูปภาพสำหรับเดสก์ท็อปมักจะใช้ไม่ได้ผลบนอุปกรณ์พกพา เนื่องจากหน้าเว็บยังคงใช้ asset ขนาด 1600 px เดิม, ครอบตัดหัวข้อได้ไม่ดี, หรือมีการหน่วงส่วน hero image ไว้หลัง JavaScript

ฉันสร้างกราฟิกต้นฉบับขนาด 1600 x 1000 และเข้ารหัสเป็น WebP q82 ที่สามความกว้าง ผลลัพธ์แสดงให้เห็นว่าทำไมการปรับขนาดจึงเหนือกว่าการปรับคุณภาพ:

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

ต้องสร้างขนาดรูปภาพสำหรับมือถือแบบไหนดี?

ให้เริ่มต้นจากพื้นที่แสดงผลที่ถูกเรนเดอร์ (rendered slot) ไม่ใช่ไฟล์จากกล้อง ตรวจสอบเทมเพลตของคุณที่จุด Breakpoints ทั่วไป และบันทึกความกว้าง CSS สูงสุดสำหรับรูปภาพแต่ละประเภท

ใช้ตัวกำหนดความกว้างเมื่อความกว้างของเลย์เอาต์มีการเปลี่ยนแปลง:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Reusable water bottle on a kitchen counter"
>

[responsive images guide] ของ MDN อธิบายโมเดลการเลือกใช้ srcset และ sizes โดยสรุปคือ: srcset จะระบุตัวเลือกที่เป็นไปได้ และ sizes จะบอกเบราว์เซอร์ว่าพื้นที่แสดงผลที่ถูกเรนเดอร์จะกว้างแค่ไหนก่อนที่เลย์เอาต์จะสมบูรณ์

สำหรับเวิร์กโฟลว์แบบแบทช์ (batch workflow) ให้สร้างความกว้างจากไฟล์ต้นฉบับเดียวกัน [batch resize guide] ครอบคลุมรูปแบบการใช้ command-line และ [image compression deep dive] อธิบายว่าทำไมควรปรับขนาดก่อนการบีบอัดขั้นสุดท้าย

ควรใช้ เมื่อใดสำหรับการครอปภาพสำหรับอุปกรณ์มือถือ?

ให้ใช้ <picture> เมื่อภาพสำหรับอุปกรณ์มือถือต้องการการครอปที่แตกต่างออกไป ไม่ใช่แค่ไฟล์ที่มีขนาดเล็กลงเท่านั้น ภาพฮีโร่ (hero) แบบแนวกว้างบนเดสก์ท็อปอาจไร้ประโยชน์บนโทรศัพท์หากวัตถุหลักอยู่ทางซ้ายสุด หรือพื้นที่ข้อความบดบังผลิตภัณฑ์

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Trail running shoe with the sole tread visible"
  >
</picture>

ควรใช้ art direction สำหรับกรณีต่อไปนี้:

1. ภาพฮีโร่ผลิตภัณฑ์ที่สินค้ามีขนาดเล็กมากบนอุปกรณ์มือถือ
2. แบนเนอร์บทความ (Editorial) ที่ใบหน้าหรือวัตถุต้องอยู่ตรงกลางเสมอ
3. รายการสินค้าในตลาดออนไลน์ที่ต้องการภาพย่อแบบสี่เหลี่ยมจัตุรัสและภาพรายละเอียดแนวกว้าง
4. ภาพก่อน/หลัง ที่ทั้งสองด้านต้องยังคงอ่านได้
5. ภาพหน้าจอที่มีข้อความขนาดเล็กที่ต้องการการครอปที่กระชับกว่านี้

ห้ามใช้ <picture> แทนการกำหนดความกว้างแบบ responsive ทั่วไป หากองค์ประกอบภาพเหมือนกัน การใช้ srcset บวกกับ sizes จะง่ายกว่า

WebP, AVIF และ JPEG มีส่วนช่วยด้านประสิทธิภาพบนมือถือได้อย่างไร?

ควรใช้ WebP เป็นรูปแบบพื้นฐานสำหรับมือถือเมื่อคุณต้องการไฟล์สมัยใหม่ที่ใช้งานได้กว้างขวาง ใช้ AVIF เมื่อ pipeline ของคุณสามารถสร้างมันได้ และคุณยังคงมี WebP หรือ JPEG เป็นตัวสำรอง เก็บ JPEG ไว้สำหรับอีเมล ระบบพันธมิตรเก่า ๆ และคลังข้อมูลต้นฉบับที่เครื่องมืออื่นต้องเปิด

รายการตรวจสอบการปรับปรุงรูปภาพที่สมบูรณ์แบบ ครอบคลุมลำดับการเผยแพร่ที่กว้างขึ้น หากคุณต้องการเปรียบเทียบเครื่องมือที่ส่งออก WebP และ AVIF โปรดดู ทางเลือกของ TinyPNG

ควรใช้ <picture> stack เมื่อคุณสามารถ:

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Blue ceramic mug beside a notebook">
</picture>

การทำ lazy loading บนมือถือควรเป็นอย่างไร?

ควรทำ lazy-load รูปภาพที่อยู่ต่ำกว่า viewport แรก ห้ามทำ lazy-load รูปภาพ LCP การใช้ lazy loading ระดับ browser มีประโยชน์ แต่ไม่ได้หมายความว่าเป็นแผนการเพิ่มประสิทธิภาพด้วยตัวมันเอง

แนวทาง browser-level lazy loading guide ของ Google แนะนำให้ใช้ loading="lazy" แบบ native สำหรับรูปภาพที่อยู่นอกหน้าจอ คำแนะนำเดียวกันนี้เตือนว่าไม่ควรทำ lazy-loading กับรูปภาพที่มองเห็นได้ทันที เพราะอาจทำให้เนื้อหาที่ผู้ใช้กำลังรอคอยล่าช้าออกไป

ใช้รายการตรวจสอบนี้:

1. กำหนดให้รูปภาพฮีโร่มี loading="eager" หรือละเว้นการระบุ loading
2. เพิ่ม fetchpriority="high" ให้กับรูปภาพที่มีแนวโน้มเป็น LCP มากที่สุด
3. เพิ่ม loading="lazy" ให้กับรูปภาพที่อยู่หลังหน้าจอแรก
4. กำหนดค่า width และ height ให้กับทุกรูปภาพ
5. ใช้ CSS aspect-ratio เมื่ออัตราส่วนที่แสดงผลมีการเปลี่ยนแปลงตาม breakpoint
6. หลีกเลี่ยงการใส่รูปภาพสำหรับฮีโร่ด้วย JavaScript เพียงอย่างเดียว
7. ตรวจสอบว่า URL รูปภาพของ CDN มี long cache headers
8. ทดสอบบนโปรไฟล์มือถือที่จำกัดความเร็ว (throttled) ไม่ใช่แค่ Wi-Fi ของเดสก์ท็อปเท่านั้น
9. ตรวจสอบองค์ประกอบ LCP ใน PageSpeed Insights
10. รันซ้ำหลังจากมีการเปลี่ยนแปลงการออกแบบ เนื่องจากองค์ประกอบ LCP อาจเปลี่ยนแปลงได้

เอกสาร LCP documentation ของ Google ระบุองค์ประกอบรูปภาพ (image elements), โปสเตอร์วิดีโอ (video posters), และรูปภาพพื้นหลัง (background images) ว่าเป็นผู้สมัคร LCP ที่เป็นไปได้ นั่นคือเหตุผลที่ว่าแม้จะเป็น background hero ก็ยังสามารถส่งผลเสียต่อ LCP ได้ แม้ว่าจะไม่ใช่แท็ก <img>

Image CDN ควรทำอะไรเพื่อรองรับมือถือ?

Image CDN ควรช่วยลดงานที่ต้องทำด้วยตนเองซ้ำ ๆ เช่น การปรับขนาดที่ edge, การเจรจา format, การแคช variants, และการรักษาความเสถียรของ public URLs. CDN ไม่ได้มาแทนที่ source hygiene. การอัปโหลดภาพสินค้าที่มีความเบลอ 900 px ไปยัง image CDN จะไม่สร้างรายละเอียดจริง 1600 px ได้

มองหาการควบคุมเหล่านี้:

• การแปลงความกว้างสำหรับช่องว่างทั่วไปของมือถือและเดสก์ท็อป
• Output ของ WebP และ AVIF พร้อมด้วย Content-Type ที่ถูกต้อง
• Cache keys ที่รวมความกว้าง, คุณภาพ, และ format
• วิธีการเก็บรักษาไฟล์ที่อัปโหลดต้นฉบับแยกจาก derivative สาธารณะ
• public URLs ที่เสถียรซึ่ง Google Images สามารถ crawl ได้
• การตรวจสอบ 404s หลังจากการ deploy และ migration

สำหรับการค้นหา Google's image SEO best practices เน้นย้ำภาพที่ใช้งานได้และมองเห็นได้ใกล้กับข้อความที่เกี่ยวข้อง, ชื่อไฟล์และ alt text ที่สื่อความหมาย, และ image URLs ที่สามารถ crawl ได้. CDN URL จะใช้ได้เมื่อมันสามารถ indexable, stable, และถูกอ้างถึงจากหน้า

ต้องทดสอบอะไรบ้างก่อนเผยแพร่?

ควรทดสอบหน้าเว็บในลักษณะที่ผู้ใช้งานผ่านมือถือได้รับดู การรัน Lighthouse ครั้งเดียวก็ช่วยได้มาก แต่ก็อาจซ่อนปัญหา CDN ที่ขาดหายไป, รูปภาพ Responsive ขนาดใหญ่เกินไป, และการเลื่อนของเค้าโครง (layout shifts) ซึ่งจะปรากฏเฉพาะในเทมเพลตจริงเท่านั้น

คำสั่งที่ใช้ได้จริงสำหรับการตรวจสอบในเครื่อง:

curl -I https://cdn.example.com/images/product-card-480.webp

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

รายการตรวจสอบ SEO และ GEO สำหรับรูปภาพบนมือถือ

Search engines และ answer engines ต้องการสิ่งที่คนต้องการเหมือนกัน นั่นคือบริบทที่ชัดเจน อย่าฝังรูปภาพไว้ใน carousel ที่ไม่มีคำอธิบายใกล้เคียง แล้วคาดหวังว่าทรัพยากรนั้นจะสื่อความหมายได้ด้วยตัวเอง

ก่อนเผยแพร่ ให้ตรวจสอบว่า:

1. หน้ามีคำตอบที่ชัดเจนเพียงหนึ่งเดียวใกล้ส่วนบน
2. รูปภาพสำคัญแต่ละรูปมี alt text ที่บรรยายได้ดี
3. ชื่อไฟล์อธิบายถึงหัวข้อที่มองเห็น ไม่ใช่ IMG_9021
4. URL ของรูปภาพสามารถถูก crawl ได้โดยไม่ใช้คุกกี้
5. ย่อหน้าโดยรอบอธิบายว่าทำไมจึงมีรูปภาพนี้อยู่
6. รูปภาพฮีโร่สำหรับมือถือต้องไม่ใหญ่กว่าพื้นที่ที่แสดงผลจำเป็น
7. รูปภาพในเนื้อหาใช้ loading="lazy" เฉพาะเมื่ออยู่ต่ำกว่า viewport แรกเท่านั้น
8. ตารางสรุปการตัดสินใจที่ผู้อ่านสามารถนำกลับมาใช้ใหม่ได้
9. ข้อกล่าวอ้างภายนอกต้องลิงก์ไปยังแหล่งข้อมูลที่มีอำนาจ
10. ลิงก์ภายในชี้ไปยังขั้นตอนการทำงานจริงถัดไป ไม่ใช่หน้ากลุ่มแบบสุ่ม

สำหรับการตรวจสอบเฉพาะ SEO หลังจากการบีบอัด ให้ใช้ image SEO optimization checklist สำหรับงานไฟล์แบบครั้งเดียว เครื่องมือ Image Compressor, Image Converter, และ Image Resizer จะครอบคลุมขั้นตอนด้วยตนเองที่พบบ่อย

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

• ภาพปก แผนผังความกว้างที่ตอบสนอง (responsive width chart) การครอปแบบกำหนดทิศทางศิลปะ (art-direction crop) และแผนผังลำดับความสำคัญในการโหลด (loading-priority chart) ถูกสร้างขึ้นสำหรับบทความนี้ด้วย ImageMagick และส่งออกเป็น WebP โดยแผนผังความกว้างที่ตอบสนองใช้ผลลัพธ์ WebP q82 ที่วัดได้จากกราฟิกต้นฉบับขนาด 1600 x 1000 เดียวกัน