การบีบอัดภาพแบบกลุ่มสำหรับนักพัฒนาเว็บ | Bulk Image Compressor

Published December 18, 2025

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

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

จุดที่การบีบอัดภาพเหมาะสมในเวิร์กโฟลว์ของนักพัฒนา

มีสามจุดหลักที่คุณสามารถบีบอัดภาพระหว่างการพัฒนา:

ก่อนคอมมิต. คุณปรับแต่งภาพในเครื่องก่อนที่จะเข้าสู่ระบบควบคุมเวอร์ชัน วิธีนี้ช่วยให้รีโพสิทอรีของคุณมีขนาดเล็ก และทุกสภาพแวดล้อม (staging, production, เครื่องของนักพัฒนาคนอื่น) จะได้รับเวอร์ชันที่ปรับแต่งแล้วโดยอัตโนมัติ

ระหว่าง build. เครื่องมือ build อย่าง Vite หรือ webpack จัดการการบีบอัดเป็นส่วนหนึ่งของไปป์ไลน์แอสเซท ภาพต้นฉบับยังคงคุณภาพเต็มในรีโพสิทอรี และกระบวนการ build จะสร้างเวอร์ชันที่ปรับแต่งแล้วสำหรับการ部署

ที่ชั้น CDN. บริการอย่าง Cloudflare, Imgix หรือ Cloudinary จะแปลงและบีบอัดภาพทันทีตามอุปกรณ์และเบราว์เซอร์ที่ร้องขอ

แต่ละวิธีมีข้อแลกเปลี่ยน และคุณสามารถใช้ร่วมกันได้

เครื่องมือออนไลน์ vs ปลั๊กอิน build

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

ปลั๊กอิน build จัดการการปรับแต่งอัตโนมัติอย่างต่อเนื่อง นี่คือตัวอย่างการทำงานจริง

Vite

ผู้ใช้ Vite สามารถใช้ vite-plugin-imagemin หรือปลั๊กอินที่คล้ายกัน:

// vite.config.js
import imagemin from 'vite-plugin-imagemin';

export default {
  plugins: [
    imagemin({
      mozjpeg: { quality: 80 },
      webp: { quality: 80 },
      pngquant: { quality: [0.7, 0.8] },
    }),
  ],
};

วิธีนี้จะบีบอัดภาพระหว่าง vite build ไฟล์ต้นฉบับไม่ถูกแตะต้อง ไดเรกทอรีเอาต์พุตจะได้รับเวอร์ชันที่ปรับแต่งแล้ว

webpack

กับ webpack ใช้ image-minimizer-webpack-plugin เพื่อทำงานเดียวกัน:

const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [
      new ImageMinimizerPlugin({
        minimizer: {
          implementation: ImageMinimizerPlugin.sharpMinify,
          options: {
            encodeOptions: {
              jpeg: { quality: 80 },
              webp: { quality: 80 },
            },
          },
        },
      }),
    ],
  },
};

เมื่อใดควรใช้อะไร

ใช้เครื่องมือออนไลน์เมื่อ:

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

ใช้ปลั๊กอิน build เมื่อ:

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

การปรับแต่งภาพใน CI/CD

ปลั๊กอิน build ทำงานระหว่าง build ในเครื่อง แต่คุณยังสามารถเพิ่มการปรับแต่งภาพในไปป์ไลน์ CI/CD ของคุณได้ วิธีนี้จะจับภาพที่ไม่ได้ปรับแต่งที่หลุดรอดไปได้ ไม่ว่าใครจะเป็นคนคอมมิต

วิธีง่ายๆ คือการรันสคริปต์ในไปป์ไลน์ CI ที่ตรวจสอบขนาดไฟล์ภาพ:

# ทำให้ build ล้มเหลวหากมีภาพใดใหญ่กว่า 500KB
find public/images -type f \( -name "*.jpg" -o -name "*.png" -o -name "*.webp" \) -size +500k | tee oversized.txt
if [ -s oversized.txt ]; then
  echo "พบภาพที่มีขนาดใหญ่เกินไป กรุณาบีบอัดก่อน部署"
  exit 1
fi

สำหรับการบีอัดอัตโนมัติใน CI เครื่องมืออย่าง sharp-cli หรือ imagemin-cli สามารถประมวลผลภาพเป็นขั้นตอนของ build วิธีนี้รับประกันว่าจะไม่มีอะไรไปสู่ production โดยไม่ถูกบีบอัด

การโหลดแบบ Lazy และภาพแบบ Responsive

การบีบอัดอย่างเดียวไม่พอ วิธีการโหลดภาพก็สำคัญไม่แพ้กัน

การโหลดแบบ Lazy จะเลื่อนการโหลดภาพที่อยู่นอกหน้าจอจนกว่าผู้ใช้จะเลื่อนไปถึง ใส่ loading="lazy" ในทุกภาพที่อยู่ต่ำกว่าขอบจอ อย่าใช้ lazy loading กับภาพหลักหรือคอนเทนต์ที่มองเห็นได้เมื่อโหลดหน้าแรก เพราะจะทำให้คะแนน Largest Contentful Paint แย่ลง

ภาพแบบ Responsive จะให้ขนาดที่แตกต่างกันตามความกว้างของหน้าจอ โทรศัพท์ไม่จำเป็นต้องใช้ภาพ 2400px ที่ออกแบบมาสำหรับจอมอนิเตอร์เดสก์ท็อป ใช้แอตทริบิวต์ srcset และ sizes เพื่อให้เบราว์เซอร์เลือกเวอร์ชันที่เหมาะสม:

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w, product-1600.webp 1600w"
  sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
  alt="รูปภาพสินค้า"
  width="1600"
  height="1067"
  loading="lazy"
>

สร้างขนาดที่แตกต่างกันเหล่านี้เป็นส่วนหนึ่งของกระบวนการ build หรือด้วยเครื่องมือแบบกลุ่มก่อนอัปโหลด

การส่งผ่าน CDN

CDN (Content Delivery Network) ให้บริการภาพจากเซิร์ฟเวอร์ที่อยู่ใกล้กับผู้เยี่ยมชมทางภูมิศาสตร์ วิธีนี้ช่วยลด latency แต่ CDN บางตัวยังมีการปรับแต่งภาพทันทีอีกด้วย

Cloudflare Image Resizing สามารถปรับขนาดและแปลงภาพเป็น WebP หรือ AVIF โดยอัตโนมัติตามเบราว์เซอร์ของผู้เยี่ยมชม คุณไม่จำเป็นต้องสร้างรูปแบบต่างๆ ด้วยตัวเอง

Imgix และ Cloudinary เป็น CDN ภาพโดยเฉพาะ คุณอัปโหลดภาพต้นฉบับคุณภาพสูงหนึ่งไฟล์ แล้วพวกมันจะสร้างขนาด รูปแบบ และคุณภาพที่คุณร้องขอผ่านพารามิเตอร์ URL วิธีนี้ทรงพลังแต่มีค่าใช้จ่ายต่อภาพ

สำหรับโปรเจกต์ส่วนใหญ่ การบีบอัดภาพก่อนอัปโหลดและส่งผ่าน CDN มาตรฐาน (Cloudflare, Fastly, AWS CloudFront) ก็เพียงพอแล้ว CDN ภาพโดยเฉพาะมีความจำเป็นเมื่อคุณมีภาพที่ผู้ใช้อัปโหลดนับพันภาพและต้องการการปรับขนาดแบบไดนามิก สำหรับพื้นฐานว่าทำไมการบีบอัดจึงสำคัญสำหรับเว็บ คู่มือของเราเกี่ยวกับ ทำไมภาพบนเว็บไซต์ถึงต้องบีบอัด ครอบคลุมพื้นฐาน

ข้อผิดพลาดทั่วไปที่นักพัฒนาทำ

คอมมิตภาพที่ไม่ได้ปรับแต่ง. ไฟล์ JPEG ขนาด 5MB ในรีโพสิทอรีของคุณจะอยู่ในประวัติ git ตลอดไป แม้ว่าคุณจะแทนที่มันในภายหลัง บีบอัดก่อนคอมมิต

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

ข้ามแอตทริบิวต์ width และ height. หากไม่มีขนาดที่ชัดเจน เบราว์เซอร์จะไม่รู้ว่าต้องสำรองพื้นที่เท่าไหร่สำหรับภาพจนกว่าจะโหลด ซึ่งทำให้เกิดการขยับของเลย์เอาต์ ส่งผลเสียต่อคะแนน CLS และรบกวนผู้ใช้

บีบอัดมากเกินไป. การลดคุณภาพลงเหลือ 30 หรือ 40% เพื่อให้ได้ไฟล์เล็กๆ ทำให้เกิด artifacts ที่มองเห็นได้ สำหรับภาพบนเว็บ คุณภาพ 75 ถึง 82% ให้สมดุลที่เหมาะสมระหว่างขนาดและรูปลักษณ์

ไม่สนใจขนาดของภาพ. การบีบอัดภาพ 4000px ที่คุณภาพ 80% เป็นสิ่งที่ดี แต่ถ้ามันแสดงผลที่ความกว้าง 600px บนหน้าเว็บของคุณ คุณยังคงส่งพิกเซลมากเกินความจำเป็น ปรับขนาดให้เท่ากับขนาดที่แสดงก่อน แล้วค่อยบีบอัด

ไม่ใช้ WebP. การรองรับ WebP ในเบราว์เซอร์เป็นสากลแล้ว หากคุณยังคงให้บริการเฉพาะ JPEG และ PNG แสดงว่าคุณกำลังเสียโอกาสประหยัดขนาดไฟล์ 25 ถึง 35%

แนวทางปฏิบัติ

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

ปรับขนาดและบีบอัดภาพก่อนคอมมิต โดยใช้เครื่องมือออนไลน์อย่าง Bulk Image Compressor หรือสคริปต์ในเครื่อง
เพิ่มปลั๊กอิน build เป็นตาข่ายความปลอดภัยเพื่อจับสิ่งที่หลุดรอด
ใช้การโหลดแบบ lazy และภาพแบบ responsive ใน HTML ของคุณ
ส่งผ่าน CDN

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

Ready to compress your images?

Bulk compress JPEG, PNG, WebP, and AVIF images right in your browser. No uploads, no sign-ups.

Try Bulk Image Compressor