การบีบอัดรูปภาพโดยไม่สูญเสียคุณภาพ: WebP Workflow

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

ปัญหาด้านคุณภาพส่วนใหญ่เริ่มต้นก่อนการบีบอัด ภาพถ่ายขนาด 4000 px ที่ถูกอัปโหลดไปยังช่องเนื้อหาขนาด 800 px นั้นเป็นการสูญเสีย bytes ไปแล้ว การจับภาพหน้าจอผลิตภัณฑ์ที่บันทึกเป็น JPEG คุณภาพต่ำก็พร้อมที่จะทำให้ข้อความเบลออยู่แล้ว การบีบอัดรูปภาพโดยไม่ให้สูญเสียคุณภาพที่มองเห็นได้นั้น ส่วนใหญ่เกี่ยวข้องกับการทำขั้นตอนต่างๆ ให้ถูกลำดับ

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

คำตอบสั้นๆ: จะบีบอัดรูปภาพโดยไม่สูญเสียคุณภาพได้อย่างไร?

ให้ทำตามลำดับนี้: เก็บไฟล์ต้นฉบับไว้, ครอบตัดหากจำเป็น, ปรับขนาดให้เท่ากับขนาดที่ใหญ่ที่สุดที่หน้าเว็บแสดงผลจริง, เลือก format ที่เหมาะสม, ส่งออกตัวเลือกคุณภาพ 2-3 แบบ, จากนั้นเปรียบเทียบในขนาดการแสดงผลสุดท้าย ไฟล์ที่มีขนาดเล็กที่สุดแต่ยังผ่านการตรวจสอบด้วยสายตาได้ คือรูปภาพที่ถูกบีบอัดอย่างถูกต้อง

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

อย่าตัดสินผลลัพธ์จากแถบเลื่อนการส่งออกเพียงอย่างเดียว ภาพถ่ายบุคคล (portrait), รูปภาพเครื่องประดับ, และภาพหน้าจอตารางราคา จะมีจุดที่ผิดพลาดแตกต่างกัน ตรวจสอบใบหน้า, ขอบผลิตภัณฑ์, ข้อความขนาดเล็ก, gradient, และเงา ก่อนที่จะแทนที่รูปภาพจริง

การปรับขนาดมีความสำคัญกว่าการตั้งค่าการบีบอัดอย่างไร?

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

เบราว์เซอร์ยังคงต้องดึงและถอดรหัสไฟล์ที่คุณเสิร์ฟ คู่มือประสิทธิภาพรูปภาพของ web.dev ระบุว่ารูปแบบสมัยใหม่ เช่น WebP และ AVIF สามารถลดขนาดการดาวน์โหลด ซึ่งยังช่วย Largest Contentful Paint ได้ด้วยเมื่อรูปภาพนั้นสำคัญต่อ viewport แรก ดูได้ที่ web.dev's image performance guide

ควรกำหนดงบประมาณความกว้างก่อนเลือกการตั้งค่าคุณภาพ:

กรณีใช้งาน	ความกว้างสูงสุดที่ใช้ได้จริง	จุดเริ่มต้นของรูปแบบ	การตรวจสอบคุณภาพ
Blog hero	1600-1920 px	WebP q80	Gradients, faces, text overlays
Article image	1000-1400 px	WebP q80-85	Edges, labels, fine texture
Product gallery	1200-1800 px	WebP q82-88	Fabric, shine, packaging text
Thumbnail	300-600 px	WebP q70-78	Cropping, face clarity
UI screenshot	Rendered width or 2x	PNG or lossless WebP	Small text and thin borders

หากคุณเริ่มต้นจากชุดไฟล์ที่อัปโหลดเกินขนาด ให้จัดการมิติก่อน คู่มือการปรับขนาดแบบกลุ่ม (Batch Resize Guide) จะครอบคลุมขีดจำกัดความกว้างแบบกลุ่ม และ Resize Images Without Losing Quality อธิบายวิธีหลีกเลี่ยงขอบนุ่มระหว่างการปรับขนาด

ต้องใช้รูปแบบใดก่อนปรับคุณภาพ?

การเลือกรูปแบบช่วยปกป้องรายละเอียดที่ผู้ใช้สังเกตได้ JPEG และ WebP แบบสูญเสีย (lossy) เหมาะสำหรับรูปภาพเพราะการเปลี่ยนแปลงสีเล็กน้อยยากที่จะมองเห็น PNG และ WebP แบบไม่สูญเสีย (lossless) ปลอดภัยกว่าสำหรับภาพหน้าจอ เพราะสิ่งแปลกปลอมจากการบีบอัดรอบข้อความจะดูยุ่งเหยิงทันที

แผนผังการตัดสินใจที่แสดง WebP หรือ AVIF สำหรับรูปภาพ, PNG หรือ WebP แบบไม่สูญเสียสำหรับภาพหน้าจอ, และ SVG หรือ WebP สำหรับกราฟิกแบน

คู่มือรูปแบบรูปภาพของ MDN อธิบายว่า WebP รองรับทั้งการบีบอัดแบบสูญเสีย (lossy) และไม่สูญเสีย (lossless) โดยโหมดเหล่านี้จัดเก็บข้อมูลรูปภาพแตกต่างกัน นั่นคือเหตุผลที่ "save as WebP" ไม่ใช่คำแนะนำที่สมบูรณ์ WebP แบบสูญเสียอาจยอดเยี่ยมสำหรับภาพถ่ายผลิตภัณฑ์ แต่ผิดสำหรับภาพหน้าจอแดชบอร์ดที่มีรายละเอียดสูง ดูคู่มือ image file type and format guide ของ MDN

ใช้กฎเหล่านี้เมื่อรูปแบบไม่ชัดเจน:

ใช้ WebP หรือ AVIF สำหรับรูปภาพถ่ายที่ขนาดไฟล์มีความสำคัญ
ใช้ WebP แบบไม่สูญเสียหรือ PNG สำหรับภาพหน้าจอที่มีข้อความที่อ่านได้
ใช้ SVG สำหรับโลโก้และไอคอนง่ายๆ เมื่อคุณมีงานศิลปะแบบเวกเตอร์ (vector)
รักษาความโปร่งใสใน WebP, PNG หรือ SVG แทนการทำให้แบนลงบนพื้นหลังสุ่ม
หลีกเลี่ยงการแปลง JPEG ที่คุณภาพต่ำให้เป็น WebP และคาดหวังว่ารายละเอียดจะกลับมา
เก็บไฟล์ต้นฉบับ (master file) ไว้ เพื่อที่คุณจะได้ส่งออกใหม่ได้อย่างสะอาด

สำหรับการเปรียบเทียบรูปแบบที่ลึกขึ้น โปรดอ่าน AVIF vs WebP Comparison หากคุณต้องการกลไกการบีบอัดที่อยู่เบื้องหลังสิ่งแปลกปลอม (artifacts) ให้ใช้ How Image Compression Works

การตั้งค่าคุณภาพ WebP ใดที่ช่วยป้องกันการสูญเสียที่มองเห็นได้?

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

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

แผนภูมิแท่งแสดงตัวอย่างการส่งออก WebP ที่ q95, q85, q80, q72 และ q60 พร้อมขนาดไฟล์ที่ลดลงและความเสี่ยงที่มองเห็นได้ที่เพิ่มขึ้น

ใช้การตั้งค่าคุณภาพเป็นตัวเลือก ไม่ใช่กฎเกณฑ์:

ประเภทเนื้อหา	ตัวเลือกแรก	ตัวเลือกที่สอง	ควรหลีกเลี่ยงเว้นแต่จะทดสอบ
รูปถ่ายสินค้า	WebP q85	WebP q80	ต่ำกว่า q72
รูปภาพบล็อก	WebP q82	WebP q76	ต่ำกว่า q68
ภาพบุคคล	WebP q85	WebP q80	การปรับให้เรียบมากเกินไป (Heavy smoothing)
ภาพหน้าจอ	Lossless WebP	PNG	JPEG แบบสูญเสียข้อมูล (Lossy JPEG)
ภาพประกอบแบบเรียบ	WebP q80 หรือ lossless WebP	SVG if vector	การบันทึกด้วย JPEG ซ้ำๆ

ข้อผิดพลาดที่ง่ายที่สุดคือการเปรียบเทียบไฟล์โดยซูม 300 เปอร์เซ็นต์และปฏิเสธการตั้งค่าการบีบอัดทุกอย่าง ให้ตรวจสอบก่อนในขนาดที่ผู้อ่านจะเห็นจริง จากนั้นจึงซูมเข้าไปในบริเวณที่มีความเสี่ยง: ข้อความ, เครื่องประดับ, ผ้า, เส้นผม, เงา และเกรเดียนต์แบบเรียบ

หากคุณต้องการอัตราส่วนเป้าหมาย ให้ใช้ Image Compression Ratio: Quality and Size Guide ซึ่งอธิบายวิธีการคำนวณอัตราส่วนหลังการปรับขนาดและเหตุผลที่ว่าทำไมอัตราส่วนสูงจึงอาจใช้ได้สำหรับภาพพื้นหลัง แต่มีความเสี่ยงสำหรับป้ายกำกับหรือภาพหน้าจอ

ต้องตรวจสอบอย่างไรว่าคุณภาพยังคงอยู่จริงหรือไม่?

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

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

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

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

เอกสารด้าน SEO รูปภาพของ Google ยังแนะนำให้ใช้ alt text ที่มีประโยชน์และเหมาะสมกับบริบท รวมถึงการทำ image markup ที่สามารถถูกรวบรวมข้อมูลได้ สิ่งนี้มีความสำคัญหลังจากการบีบอัด เพราะรูปภาพขนาดเล็ก ไม่ชัดเจน และคำอธิบายไม่ดีจะไม่เป็นผลดีต่อการค้นหาหรือการเข้าถึง (accessibility) ดูที่ Google Images best practices

คุณควรใช้เวิร์กโฟลว์ใดสำหรับโฟลเดอร์ทั้งหมด?

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

ใช้เวิร์กโฟลว์สำหรับโฟลเดอร์นี้:

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

ขั้นตอน	เงื่อนไขผ่าน	แก้ไขหากล้มเหลว
Source retained	Original master is still available	Restore from backup before re-exporting
Resize completed	File width matches real layout needs	Resize before touching quality
Format matched	Photos, screenshots, and logos use different rules	Split into content groups
Visual sample checked	Risky details still look clean	Raise quality or use lossless
Published URL tested	CDN image returns 200	Re-upload or correct the path

สำหรับหน้าเว็บที่เน้นอุปกรณ์มือถือ ให้จับคู่เวิร์กโฟลว์นี้กับ Mobile Image Optimization Guide สำหรับรายการตรวจสอบการเปิดตัวที่ครอบคลุมยิ่งขึ้น ให้ใช้ Complete Image Optimization Checklist

เมื่อใดที่คุณควรยอมรับไฟล์ที่มีขนาดใหญ่กว่า?

ควรยอมรับไฟล์ที่มีขนาดใหญ่ขึ้นเมื่อรูปภาพนั้นสื่อถึงความน่าเชื่อถือ รายละเอียด หรือมูลค่าในการเปลี่ยนเป็นยอดขาย ผู้ขายไม่ควรเบลอพื้นผิวของเสื้อแจ็คเก็ตเพียงเพื่อประหยัด 30 KB ทีม SaaS ไม่ควรทำให้ภาพหน้าจอราคาอ่านยาก และผู้เผยแพร่ก็ไม่ควรบีบอัดแผนภูมิจนกระทั่งป้ายกำกับแกน (axis labels) เลือนหาย

ไฟล์ขนาดใหญ่ถือว่าสมเหตุสมผลเมื่อรูปภาพประกอบด้วย:

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

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

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

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

กราฟิกรายการตรวจสอบที่มีการตรวจสอบก่อนเผยแพร่ 6 รายการ: ปรับขนาด รูปแบบ ผู้สมัครรายละเอียดภาพ เมตาข้อมูล และสถานะ CDN

ใช้ขั้นตอนสุดท้ายนี้:

การตรวจสอบ	ผลลัพธ์ที่ดี	ความสำคัญ
Display width	รูปภาพไม่กว้างกว่าช่องที่แสดงผลใหญ่ที่สุดมากนัก	ป้องกันการสูญเสียพิกเซลที่มองไม่เห็น
Format	ภาพถ่ายใช้ WebP หรือ AVIF; ภาพหน้าจอจะยังคง lossless เมื่อจำเป็น	ปกป้องรายละเอียด
Quality	ผู้สมัครที่มีขนาดเล็กที่สุดผ่านการตรวจสอบด้วยสายตา	หลีกเลี่ยงสิ่งแปลกปลอมที่มองเห็นได้
Metadata	สำเนาสาธารณะมีการลบ EXIF ที่ไม่จำเป็นออกแล้ว	ประหยัดไบต์และจำกัดการรั่วไหลของข้อมูล
Alt text	อธิบายรูปภาพจริงในบริบทนั้นๆ	ช่วยเรื่องการเข้าถึง (accessibility) และการค้นหารูปภาพ
CDN	URL WebP สุดท้ายส่งคืน HTTP 200	ป้องกันโพสต์และตัวอย่างที่เสีย

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

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

สามารถบีบอัดรูปภาพโดยไม่สูญเสียคุณภาพได้หรือไม่?

การบีบอัดแบบไร้การสูญเสีย (Lossless compression) จะรักษาสารข้อมูลพิกเซลไว้ ในขณะที่การบีบอัดแบบมีการสูญเสีย (lossy compression) สามารถรักษาคุณภาพที่รับรู้ได้ ณ ขนาดการดูสุดท้าย โดยไม่จำเป็นต้องเหมือนกันทางคณิตศาสตร์

ควรปรับขนาดก่อนบีบอัดหรือไม่?

ควรปรับขนาดก่อนเมื่อแหล่งที่มามีความกว้างกว่าช่องว่างที่ใหญ่ที่สุดที่จะแสดงผล

WebP เล็กกว่า JPEG เสมอไปหรือไม่?

ไม่เสมอไป ดังนั้นจึงควรส่งออกทั้งสองรูปแบบจากแหล่งที่มาเดียวกันและเปรียบเทียบไบต์กับรายละเอียดที่มองเห็นได้ แทนที่จะสันนิษฐานว่ารูปแบบใดจะชนะ

ควรใช้ WebP quality เท่าใด?

Quality 75–85 เป็นช่วงทดสอบที่มีประโยชน์สำหรับภาพถ่าย แต่ภาพหน้าจอ (screenshots) และการไล่ระดับสีที่ราบรื่นอาจต้องการการตั้งค่าที่สูงขึ้นหรือผลลัพธ์แบบไร้การสูญเสีย

การบีบอัดจะลบ metadata ของรูปภาพหรือไม่?

ตัวส่งออกบางตัวจะลบ metadata ออกและบางตัวจะเก็บไว้ ดังนั้นควรตรวจสอบไฟล์สุดท้ายหากการลบ EXIF มีความสำคัญต่อขนาดหรือความเป็นส่วนตัว

ทำไมรูปภาพที่ถูกบีบอัดจึงมีขนาดใหญ่ขึ้นในบางครั้ง?

แหล่งที่มาที่มีขนาดเล็กหรือได้รับการปรับให้เหมาะสมอยู่แล้ว อาจมีขนาดใหญ่ขึ้นเมื่อมีการเข้ารหัสใหม่ด้วยการตั้งค่าที่ไม่มีประสิทธิภาพหรือรูปแบบที่ไม่ตรงกัน

ควรเปรียบเทียบตัวเลือกที่ถูกบีบอัดอย่างไร?

ควรดูตัวเลือกเหล่านี้ข้างต้นฉบับเดิม ณ ขนาดที่แสดงผลสุดท้าย และตรวจสอบข้อความ ขอบ การไล่ระดับสี ผิวหนัง และรายละเอียดผลิตภัณฑ์

สามารถบีบอัดรูปภาพแบบกลุ่มได้อย่างปลอดภัยหรือไม่?

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