WebP แบบ lossless ช่วยประหยัดอะไรได้จริงเมื่อเทียบกับ PNG

สรุปสั้น ๆ

WebP แบบ lossless มักมีขนาดเล็กกว่า PNG สำหรับพิกเซลชุดเดียวกัน นี่คือเหตุผลเชิงปฏิบัติที่ผู้คนเลือกใช้มัน

แต่คำว่า "มัก" สำคัญมาก WebP แบบ lossless ไม่ใช่ตัวแทนวิเศษสำหรับ PNG ทุกไฟล์ โดยทั่วไปมันมักช่วยประหยัดได้มากที่สุดกับภาพที่มีความโปร่งใส, ภาพหน้าจอ, ภาพจับหน้าจอ UI และคอนเทนต์ที่ผสมระหว่างกราฟิกกับภาพถ่าย มันอาจช่วยได้น้อย หรือบางครั้งอาจใหญ่กว่าเดิม สำหรับแอสเซ็ตขนาดเล็กมาก, PNG แบบพาเล็ตที่ปรับแต่งมาอย่างหนัก และไอคอนเรียบง่าย

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

นี่เป็นคำถามที่แคบกว่า และตอบได้ง่ายกว่ามาก

"lossless" ในที่นี้หมายถึงอะไร

Lossless หมายถึงพิกเซลที่ถอดรหัสออกมาตรงกับพิกเซลต้นฉบับทุกประการ ถ้าแปลง PNG เป็น WebP แบบ lossless แล้วถอดรหัสกลับมาอีกครั้ง พิกเซลของภาพควรเหมือนเดิมทุกอย่าง

ไม่ได้หมายความว่าไฟล์จะเหมือนเดิม Metadata, การจัดการ color profile, ancillary PNG chunks, ข้อมูล gamma, timestamps และ chunks เฉพาะเครื่องมือ อาจถูกเปลี่ยน ลบออก หรือแทนด้วยวิธีอื่น ขึ้นอยู่กับ pipeline การแปลงของคุณ

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

ถ้าคุณเผยแพร่ภาพที่ผู้ใช้ส่งมา Metadata ก็เป็นประเด็นด้านความเป็นส่วนตัวด้วย เราเคยครอบคลุมหัวข้อที่กว้างกว่านี้ไว้ใน วิธีลบ EXIF metadata ก่อนแชร์รูปภาพออนไลน์ แต่หลักการเดียวกันก็ใช้กับกรณีนี้: การปรับแต่งภาพควรระบุให้ชัดว่ามันเก็บอะไรไว้และลบอะไรออก

ทำไม PNG จึงบีบอัดได้ดี และมันหยุดตรงไหน

PNG เป็นฟอร์แมตที่ดีมาก มันกลายเป็นค่าเริ่มต้นบนเว็บด้วยเหตุผลที่ดี:

• เป็นแบบ lossless
• รองรับ alpha transparency
• รองรับอย่างแพร่หลาย
• คาดเดาได้และทำงานด้วยง่าย
• ยอดเยี่ยมสำหรับกราฟิกแบบแบน, ภาพหน้าจอ, โลโก้ และแอสเซ็ต UI

การบีบอัด PNG ทำงานโดยกรองแถวของภาพ แล้วจึงใช้การบีบอัด DEFLATE การผสมกันนี้มีประสิทธิภาพ โดยเฉพาะเมื่อพิกเซลที่อยู่ใกล้กันมีความคล้ายกัน

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

นั่นคือจุดที่ WebP แบบ lossless เข้ามา

WebP แบบ lossless ทำต่างออกไปอย่างไร

WebP แบบ lossless ใช้ระบบบีบอัดที่ออกแบบมาเฉพาะสำหรับภาพ แทนที่จะเป็นชั้นการบีบอัดอเนกประสงค์ที่นำมาต่อเข้ากับแถวที่ถูกกรอง ภายในระบบ มันสามารถใช้เทคนิคอย่าง predictive coding, color transforms, palettes, backward references และ entropy coding เพื่อแทนรูปแบบพิกเซลที่ซ้ำหรือคาดเดาได้อย่างกะทัดรัด

คุณไม่จำเป็นต้องจำรายละเอียดการทำงานทั้งหมด โมเดลในใจที่มีประโยชน์คือ:

PNG บีบอัดแถวได้ดี WebP แบบ lossless มีวิธีอธิบายโครงสร้างของภาพได้มากกว่า

ความยืดหยุ่นที่เพิ่มขึ้นนี้คือเหตุผลที่ WebP แบบ lossless มักสร้างไฟล์ที่เล็กลงจากภาพต้นฉบับเดียวกันได้บ่อยครั้ง

Google เคยอธิบายไว้ในอดีตว่า ภาพ WebP แบบ lossless มีขนาดเล็กกว่า PNG โดยเฉลี่ยราว 26% ในการศึกษาของตนเอง ให้มองตัวเลขนี้เป็นเกณฑ์อ้างอิงเชิงทิศทาง ไม่ใช่คำรับประกัน ภาพของคุณไม่ใช่ค่าเฉลี่ย ระบบดีไซน์, ภาพหน้าจอ, ภาพสินค้า, ภาพประกอบ, แอสเซ็ตที่ export แล้ว และอัปโหลดจาก CMS ของคุณจะมีพฤติกรรมของตัวเอง

จุดที่ WebP แบบ lossless มักประหยัดได้มากที่สุด

ภาพโปร่งใส

PNG มักถูกใช้เพราะมี alpha transparency WebP แบบ lossless ก็รองรับ alpha เช่นกัน และมักบีบอัดได้อย่างมีประสิทธิภาพ

สิ่งนี้มีประโยชน์สำหรับ:

• ภาพสินค้าแบบตัดพื้นหลัง
• สติกเกอร์และป้าย
• เลเยอร์ซ้อนทับของอินเทอร์เฟซ
• แผนภาพที่มีพื้นหลังโปร่งใส
• โลโก้ที่ export ใหญ่เกินจำเป็น

การประหยัดอาจเห็นได้ชัดเมื่อ alpha channel มีพื้นที่ขนาดใหญ่ที่คาดเดาได้, ขอบนุ่ม หรือรูปทรงซ้ำ ๆ หากคุณมีแคตตาล็อกที่เต็มไปด้วยภาพสินค้าพื้นหลังโปร่งใส WebP แบบ lossless ควรค่าแก่การทดสอบตั้งแต่เนิ่น ๆ

ภาพหน้าจอและภาพจับหน้าจอ UI

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

WebP แบบ lossless มักจัดการภาพเหล่านี้ได้ดี ภาพหน้าจอ UI แบบเต็มหน้าที่มีขนาด 900 KB ในรูป PNG ที่ปรับแต่งแล้ว อาจกลายเป็น 500–700 KB เมื่อเป็น WebP แบบ lossless บางครั้งประหยัดได้มากกว่านั้น บางครั้งน้อยกว่านั้น แต่หมวดหมู่นี้มีแนวโน้มดี

ถ้าภาพหน้าจอเหล่านั้นปรากฏในเอกสาร, หน้า marketing, onboarding flows หรือ case studies ผลรวมโดยรวมอาจมีความหมายจริง

คอนเทนต์ที่ผสมภาพประกอบและภาพจริง

กราฟิกเว็บสมัยใหม่จำนวนมากไม่ใช่ภาพประกอบล้วนและไม่ใช่ภาพถ่ายล้วน ลองนึกถึง hero image ที่มี UI ของผลิตภัณฑ์, gradients, ไอคอนเล็ก ๆ, ป้ายข้อความ และภาพถ่ายฝังอยู่

PNG อาจรักษามันไว้ได้สมบูรณ์แบบ แต่สร้างไฟล์ขนาดใหญ่ Lossy WebP หรือ AVIF อาจทำให้เกิด artifacts รอบข้อความและขอบ หากบีบหนักเกินไป WebP แบบ lossless อาจเป็นจุดกึ่งกลางที่สมเหตุสมผลเมื่อขอบที่คมชัดมีความสำคัญ

สำหรับแผนผังการตัดสินใจที่กว้างขึ้นเกี่ยวกับฟอร์แมตภาพ รวมถึง AVIF และ lossy WebP ดู ฟอร์แมตภาพในปี 2026: เมื่อไร AVIF ชนะ WebP และเมื่อไรที่ไม่ใช่

จุดที่ PNG อาจยังดีกว่า

ไอคอนจิ๋วและแอสเซ็ตเรียบง่าย

สำหรับไฟล์ขนาดเล็กมาก overhead ของฟอร์แมตมีผล ไอคอน PNG ขนาด 650 ไบต์ไม่ใช่ตัวเลือกที่เห็นได้ชัดว่าควรแปลง WebP อาจประหยัดได้ 80 ไบต์ หรืออาจใหญ่ขึ้นก็ได้

ในระดับนั้น ความซับซ้อนด้านการปฏิบัติงานอาจมากกว่าประโยชน์ที่ได้ หากไฟล์เล็กอยู่แล้ว ไม่ได้บล็อกการ render และถูก cache ไว้นาน คุณน่าจะมีเรื่องอื่นที่ควรแก้มากกว่า

PNG แบบพาเล็ตที่ปรับแต่งอย่างระมัดระวัง

PNG บางไฟล์เล็กกว่าที่คนคาดมาก เพราะใช้ palette ที่จำกัด PNG แบบ indexed-color ที่ทำมาดีอาจเอาชนะได้ยากสำหรับกราฟิกเรียบง่าย

โดยเฉพาะอย่างยิ่งกับ:

• โลโก้ขนาดเล็ก
• Pixel art
• ไอคอนแบบแบน
• แผนภาพเรียบง่าย
• กราฟิกที่มีสีน้อย

ระวังเมื่อเปรียบเทียบ WebP กับไฟล์ PNG ที่ export มาอย่างหละหลวม ถ้า PNG มาจากเครื่องมือดีไซน์โดยตรงพร้อม metadata ที่ไม่จำเป็นและการตั้งค่าบีบอัดที่ไม่ดี WebP อาจดูดีกว่าอย่างมาก นั่นไม่ได้หมายความว่า WebP ชนะ PNG ที่ปรับแต่งมาอย่างดีด้วยส่วนต่างเท่ากัน

การทดสอบที่ยุติธรรมคือการเปรียบเทียบ WebP แบบ lossless กับ PNG ที่ปรับแต่งแล้ว ไม่ใช่ไฟล์ใดก็ตามที่บังเอิญถูกอัปโหลดมา

ภาพที่ควรใช้แบบ lossy แทน

นี่คือข้อผิดพลาดที่เงียบ ๆ: ทีมแปลง PNG เป็น WebP แบบ lossless ทั้งที่ภาพนั้นไม่ควรเป็น PNG ตั้งแต่แรก

กรณีปกติคือภาพถ่าย ภาพถ่ายสีเต็มรูปแบบที่บันทึกเป็น PNG อาจใหญ่โตมาก การแปลงเป็น WebP แบบ lossless อาจลดขนาดไฟล์ได้ แต่โดยทั่วไปก็ยังใหญ่กว่า WebP หรือ AVIF แบบ lossy คุณภาพสูงอยู่มาก

ถ้าผู้ใช้มองไม่เห็นความแตกต่าง lossless มักเป็นเป้าหมายที่ผิด ภาพถ่ายสินค้า, ภาพ editorial, พื้นหลัง และภาพ portrait มักเหมาะกับฟอร์แมตแบบ lossy พร้อมการตั้งค่าคุณภาพที่สมเหตุสมผล

ควรเก็บ lossless ไว้สำหรับกรณีที่พิกเซลที่ตรงเป๊ะมีความสำคัญ: ภาพหน้าจอ UI, แผนภาพ, กราฟิกที่มีข้อความมาก, ความโปร่งใส, แผนภูมิที่สร้างขึ้น และแอสเซ็ตที่เสื่อมคุณภาพอย่างเห็นได้ชัดภายใต้การบีบอัดแบบ lossy

นอกจากไบต์แล้ว มันช่วยประหยัดอะไรอีก

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

แต่ยังมีประโยชน์รองอีก:

• ผู้เข้าชมที่ใช้แพ็กเกจจำกัดปริมาณข้อมูลใช้ data น้อยลง
• เติม image cache ได้เร็วขึ้น
• ลด CDN bandwidth
• ลดปริมาณ storage และ backup ในระดับใหญ่
• ลดแรงกดดันต่อ performance budgets

การประหยัดเหล่านี้ไม่ได้กระจายเท่ากันทุกที่ PNG ขนาด 2 MB เพียงไฟล์เดียวที่แปลงเป็น WebP ขนาด 900 KB สำคัญกว่าไอคอนห้าสิบไฟล์ที่ลดลงไฟล์ละ 100 ไบต์

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

การแลกเปลี่ยนด้านต้นทุนการถอดรหัส

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

การถอดรหัส PNG สุกงอมและมักเร็ว WebP ก็รองรับอย่างแพร่หลายและมีประสิทธิภาพเช่นกัน แต่อาจใช้ CPU มากกว่าในบางกรณี บนอุปกรณ์สมัยใหม่ เรื่องนี้แทบไม่ใช่ตัวขวาง แต่บนโทรศัพท์ระดับล่าง, หน้าเว็บที่มีภาพจำนวนมาก หรือแอสเซ็ตขนาดใหญ่ที่อยู่ above-the-fold ก็ควรวัดผล

กฎเชิงปฏิบัติ: ถ้า WebP แบบ lossless ลด PNG ขนาดใหญ่ลงได้ 30–50% ประโยชน์ด้านเครือข่ายมักมีน้ำหนักมากกว่า ถ้ามันลด PNG ขนาดเล็กได้ 3% การแลกเปลี่ยนนั้นอาจไม่คุ้มให้สนใจ

งานด้านประสิทธิภาพเต็มไปด้วยการตัดสินใจตาม threshold แบบนี้ อย่าปรับแต่งทุกไบต์ด้วยความเข้มข้นเท่ากัน

วิธีทดสอบแบบง่าย

ใช้ชุดตัวอย่างที่เป็นตัวแทน ไม่ใช่ภาพเดียว

สร้างโฟลเดอร์ที่มีตัวอย่างจากเว็บไซต์จริงของคุณ:

• โลโก้และไอคอน
• ภาพหน้าจอ
• ภาพสินค้าแบบตัดพื้นหลัง
• แผนภาพ
• PNG ที่อัปโหลดผ่าน CMS
• ภาพ social preview
• กราฟิก hero ขนาดใหญ่

จากนั้นเปรียบเทียบสามสิ่ง:

1. PNG ต้นฉบับตามที่อัปโหลด
2. PNG ที่ปรับแต่งแล้ว
3. เวอร์ชัน WebP แบบ lossless

สำหรับเวิร์กโฟลว์ command-line ทีมมักใช้เครื่องมืออย่าง oxipng, pngcrush, zopflipng หรือ cwebp -lossless เครื่องมือที่แน่นอนสำคัญน้อยกว่าวินัยในการเปรียบเทียบสิ่งที่เทียบเคียงกันได้

ติดตาม:

• ขนาดไฟล์
• ความเท่ากันของพิกเซลหลังถอดรหัส
• การแสดงผลในเบราว์เซอร์เป้าหมาย
• ความถูกต้องของความโปร่งใส
• ลักษณะสีที่ปรากฏ
• เวลา build
• ความติดขัดใน CMS หรือเวิร์กโฟลว์ดีไซน์

สเปรดชีตง่าย ๆ ก็เพียงพอ เพิ่มขนาดไฟล์ต้นฉบับ, ขนาด PNG ที่ปรับแต่งแล้ว, ขนาด WebP แบบ lossless, เปอร์เซ็นต์ที่ประหยัดได้ และหน้าที่ภาพนั้นปรากฏอยู่

จากนั้นเรียงตามจำนวนไบต์รวมที่ประหยัดได้ ลำดับการเรียงนั้นมักบอกคุณว่าควรทำอะไร

การส่งมอบ: อย่าทำให้ client รุ่นเก่าใช้งานไม่ได้โดยไม่จำเป็น

ตอนนี้ WebP รองรับกว้างในเบราว์เซอร์สมัยใหม่ สำหรับเว็บไซต์สาธารณะส่วนใหญ่ ใช้ได้อย่างปลอดภัย ถึงอย่างนั้น หากคุณมี embedded webviews, email clients, เบราว์เซอร์ enterprise รุ่นเก่า, native apps หรือ crawlers ที่ไม่ปกติอยู่ในระบบ ให้ทดสอบก่อนแทนที่ PNG โดยตรง

รูปแบบที่ระมัดระวังคือเก็บ PNG ไว้เป็น fallback และส่ง WebP เมื่อรองรับ:

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

แนวทางนี้น่าเบื่อ และความน่าเบื่อเป็นเรื่องดี ผู้ใช้ที่รองรับ WebP ได้ไฟล์ที่เล็กกว่า คนอื่น ๆ ได้ PNG

ถ้า build system ของคุณ fingerprint แอสเซ็ตและ CDN cache อย่างถูกต้อง สิ่งนี้ไม่ได้ดูแลรักษายาก ถ้า CMS ของคุณทำให้การจัดการฟอร์แมตสำรองยุ่งยาก ให้เริ่มจากภาพที่ใหญ่ที่สุดและถูกใช้ซ้ำมากที่สุด แทนที่จะพยายามแปลงทั้ง media library ใน sprint เดียว

ความเป็นส่วนตัวและการประมวลผลในเครื่อง

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

เครื่องมือภาพฝั่งเบราว์เซอร์ดีพอแล้วสำหรับการแปลงง่าย ๆ, previews และการตรวจ metadata หลายกรณี ยังมีข้อจำกัดอยู่ แต่การประมวลผลในเครื่องสามารถลดการอัปโหลดภาพส่วนตัวที่ไม่จำเป็นได้ เราเคยครอบคลุมข้อแลกเปลี่ยนไว้ใน ทำไมการประมวลผลภาพในเบราว์เซอร์จึงเป็นชัยชนะด้านความเป็นส่วนตัว

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

กฎง่าย ๆ ที่ใช้ได้จริง

ใช้ WebP แบบ lossless เมื่อทั้งสามข้อนี้เป็นจริง:

• ต้นฉบับปัจจุบันเป็น PNG
• พิกเซลที่ตรงเป๊ะหรือความโปร่งใสที่สะอาดมีความสำคัญ
• WebP แบบ lossless ประหยัดได้อย่างมีนัยสำคัญหลังเปรียบเทียบกับ PNG ที่ปรับแต่งแล้ว

ใช้ PNG ต่อเมื่อ:

• ไฟล์มีขนาดจิ๋ว
• PNG ถูกปรับแต่งแบบ palette มาแล้วและยังแข่งขันได้
• ข้อจำกัดด้านความเข้ากันได้ไม่ปกติ
• ความซับซ้อนด้านการปฏิบัติงานไม่คุ้มกับไบต์ที่ประหยัดได้

ใช้ lossy WebP หรือ AVIF เมื่อ:

• ภาพเป็นภาพถ่าย
• พิกเซลที่ตรงเป๊ะไม่สำคัญ
• การตั้งค่าคุณภาพสามารถลดขนาดได้มากโดยไม่มีความเสียหายที่มองเห็นได้

กลยุทธ์ภาพที่ดีที่สุดแทบไม่ใช่การใช้ฟอร์แมตเดียวทุกที่ แต่เป็นชุดกฎเล็ก ๆ ที่ใช้ให้สม่ำเสมอ

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: นำ PNG เดียวกันไปผ่าน Image Converter เพื่อสร้างเวอร์ชัน WebP แบบไม่สูญเสียข้อมูล แล้วเปรียบเทียบขนาดไฟล์โดยตรง

<!-- tool-cta:end -->

แล้ว WebP แบบ lossless ช่วยประหยัดอะไรได้จริง?

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

นั่นคือส่วนสำคัญ WebP แบบ lossless ไม่ใช่การอัปเกรดทางศีลธรรมจาก PNG มันเป็นตัวเลือกเชิงปฏิบัติสำหรับงานเฉพาะ: ภาพเว็บแบบ lossless ที่เล็กลง พร้อมความโปร่งใสและการรองรับกว้างในเบราว์เซอร์สมัยใหม่

ใช้มันเมื่อมีตัวเลขรองรับ ปล่อย PNG ไว้ตามเดิมเมื่อไม่มี