คู่มือ Gzip Size Calculator: วัดขนาดไฟล์จริงที่เว็บไซต์ส่งให้ผู้ใช้

เมื่อ build tool รายงานว่าไฟล์ JavaScript ของคุณมีขนาด 200 KB ตัวเลขนั้นคือขนาดของไฟล์บนดิสก์ของคุณ ไม่ใช่ขนาดของไฟล์ที่ผู้ใช้ได้รับจริง เพราะ web server และ CDN เกือบทั้งหมดจะ compress ไฟล์ที่เป็นข้อความก่อนส่งให้ผู้ใช้เสมอ ดังนั้นตัวเลขที่กำหนดน้ำหนักหน้าเว็บจริง ๆ คือขนาดหลังผ่าน gzip โดยทั่วไปแล้ว bundle ที่ minify แล้วซึ่งรายงานขนาด 200 KB บนดิสก์ มักถูกส่งไปที่เบราว์เซอร์ด้วยขนาดราว ๆ 60 KB หลังผ่าน gzip ทีมที่ตั้ง budget หรือเปรียบเทียบจากขนาดดิบ มักประเมินขนาด payload จริงสูงเกินความจริงไปกว่าครึ่ง และบางครั้งก็ตัดสินใจ optimize ผิดทางเพราะตัวเลขนั้น

Gzip Size Calculator ช่วยปิดช่องว่างนี้ เพียงวางข้อความหรือเลือกไฟล์ลงไป เครื่องมือจะ compress ด้วย gzip ในเบราว์เซอร์ของคุณทันที แล้วแสดงขนาดต้นฉบับ ขนาดหลัง compress สัดส่วน savings เป็นเปอร์เซ็นต์ พร้อมปุ่มดาวน์โหลดผลลัพธ์ที่ compress แล้ว เนื่องจากทุกอย่างทำงานแบบ client-side ข้อมูลของคุณจึงไม่หลุดออกจากเครื่องเลย ทำให้เครื่องมือนี้เหมาะทั้งกับคอนเทนต์สาธารณะและไฟล์ config ส่วนตัวที่คุณไม่อยากส่งให้บริการออนไลน์แบบสุ่ม ๆ

บทความนี้จะพาไปดูว่าทำไมขนาดหลัง gzip จึงเป็นตัวเลขเดียวที่ควรใช้ตั้ง budget, วิธีใช้เครื่องมือให้ได้ผลลัพธ์ที่มีประโยชน์ภายในไม่กี่นาที และวิธีอ่านความหมายของ savings percentage ที่บอกคุณเกี่ยวกับ bundle, API payload และ static assets ของคุณ

ทำไมต้องใช้ Gzip Size Calculator?

• ขนาดที่โอนจริงคือตัวเลขจริง File manager และ build log แสดงขนาดก่อน compress แต่ผู้ใช้ดาวน์โหลดเวอร์ชันที่ผ่าน gzip แล้ว ถ้าคุณสนใจ performance budget, เวลาโหลด หรือการใช้เน็ตมือถือ ขนาดหลัง compress คือตัวเลขเดียวที่สำคัญ
• เช็คก่อน-หลังได้ทันที ลบคอมเมนต์ออกจาก config, ตัดฟิลด์ทิ้งจาก JSON payload หรือ refactor โค้ด แล้ว compress ทั้งสองเวอร์ชันเพื่อดูว่าการแก้นั้นประหยัดไปกี่ไบต์
• ข้อมูลไม่ออกจากเครื่องคุณ การ compress ทั้งหมดเกิดขึ้นในเบราว์เซอร์ ซอร์สโค้ดลิขสิทธิ์ ไฟล์ config ภายใน และข้อมูลผลิตภัณฑ์ที่ยังไม่เปิดตัว ยังอยู่บนเครื่องคุณทั้งหมด
• ได้ตัวเลข savings ที่วัดได้ ไม่ใช่ความรู้สึก Savings percentage เปลี่ยนคำว่า "เล็กลงนะ" ให้กลายเป็นตัวเลขชัด ๆ ที่จดใส่ pull request, เทียบข้ามรีลีส และใช้ตอบโต้ใน code review ได้
• ดาวน์โหลดผลลัพธ์ได้ บันทึกไฟล์ .gz ที่ได้ไว้ตรวจสอบ เก็บถาวร หรือทดสอบว่า server หรือ CDN จัดการ gzip payload จริงอย่างไร
• ไม่ต้องติดตั้งอะไรเลย ไม่ต้องใช้ command line, ไม่ต้อง build, ไม่ต้องสมัครบัญชี เปิดหน้าเว็บ วางคอนเทนต์ แล้วกด compress

ฟีเจอร์หลัก

รายละเอียดที่ควรรู้เวลาใช้เครื่องมือ:

• การ compress ทำงานในเบราว์เซอร์ทั้งหมด ผลลัพธ์จึงออกมาทันทีและไม่มีข้อมูลถูกส่งไปที่ server ใด ๆ
• Savings percentage คำนวณเทียบกับขนาดต้นฉบับ ไฟล์ 200 KB ที่ compress เหลือ 60 KB จะรายงาน savings ที่ 70%
• gzip เป็นการ compress แบบ lossless ผลลัพธ์หลังคลายกลับจะเหมือนต้นฉบับระดับไบต์ เนื้อหาของคุณจึงไม่ถูกแก้ไข

วิธีการใช้งาน

1. เปิดเครื่องมือ เข้าไปที่ Gzip Size Calculator ด้วยเบราว์เซอร์สมัยใหม่ตัวไหนก็ได้ ไม่ต้องติดตั้งอะไรเพิ่ม
2. ใส่คอนเทนต์ของคุณ วางข้อความลงในช่อง input โดยตรง หรือเลือกไฟล์ เช่น JavaScript bundle, ไฟล์ export เป็น JSON, CSV หรือไฟล์ config
3. กด compress เครื่องมือจะรัน gzip ในเบราว์เซอร์ของคุณ ซึ่งสำหรับข้อความทั่วไปมักเสร็จภายในเสี้ยววินาที
4. อ่านผลลัพธ์ เทียบขนาดต้นฉบับ ขนาดหลัง compress และ savings percentage ทั้งสามอย่างนี้บอกทั้งจำนวนไบต์ที่ประหยัดได้และประสิทธิภาพของการ compress กับคอนเทนต์ชิ้นนั้น
5. ดาวน์โหลดหรือปรับซ้ำ ดาวน์โหลดไฟล์ที่ compress แล้วถ้าต้องใช้ หรือแก้ input แล้ว compress ใหม่เพื่อวัดผลของการแก้แต่ละครั้ง

ทำไมข้อความ compress ได้ดีแต่รูปภาพไม่ได้

Gzip ผสมเทคนิคคลาสสิกสองอย่างเข้าด้วยกันในรอบเดียว LZ77 สแกนหาลำดับไบต์ที่ซ้ำกันแล้วแทนที่การปรากฏครั้งถัด ๆ ไปด้วย back-reference สั้น ๆ ที่ชี้กลับไปยังตำแหน่งก่อนหน้า จากนั้น Huffman coding จะกำหนด bit pattern ที่สั้นที่สุดให้กับสัญลักษณ์ที่ปรากฏบ่อยที่สุด ข้อความธรรมดาเต็มไปด้วยความซ้ำ ชุดเทคนิคนี้จึงได้ผลอย่างทำลายล้างกับมัน

คอนเทนต์ที่ compress ได้ดีคืออะไรก็ตามที่มีความซ้ำสูง: บทความภาษามนุษย์, JSON ที่มีชื่อ key ซ้ำ ๆ, ซอร์สโค้ดที่มี keyword และรูปแบบการย่อหน้าที่เกิดซ้ำ, ไฟล์ export เป็น CSV ที่มีแถวคล้ายกันยาว ๆ, HTML, SVG และ XML ไฟล์กลุ่มนี้มักเล็กลง 70 ถึง 90 เปอร์เซ็นต์ ส่วนคอนเทนต์ที่ compress ได้ไม่ดีคืออะไรที่ถูก compress มาแล้ว: รูป JPEG, PNG, WebP, AVIF, วิดีโอ MP4 และ WebM, ฟอนต์ WOFF2 และไฟล์ ZIP ที่มีอยู่แล้ว ฟอร์แมตพวกนี้กำจัดความซ้ำไปข้างในหมดแล้ว gzip จึงแทบไม่มีอะไรให้บีบ และบางทียังเพิ่ม overhead อีกไม่กี่ไบต์เสียด้วย

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

เวิร์กโฟลว์ที่ใช้ประโยชน์ได้จริงอย่างหนึ่งคือการวัด bundle ก่อนและหลัง minify ลองเอาซอร์ส bundle แบบอ่านได้ผ่านเครื่องมือนี้และจดขนาดหลัง gzip จากนั้น minify โค้ดชุดเดียวกันด้วย Code Minifier แล้วเอาผลลัพธ์มา compress อีกครั้ง คุณจะเห็นว่าสองการ optimize นี้ซ้อนทับกันได้: การ minify ลบ whitespace, คอมเมนต์ และชื่อตัวแปรยาว ๆ ออก แล้ว gzip จะบีบโค้ดที่เหลือซึ่งหนาแน่นขึ้นได้มีประสิทธิภาพยิ่งขึ้น ส่วนลดรวมที่ได้คือสิ่งที่ผู้ใช้สัมผัสจริง

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

กรณีการใช้งานจริง

เช็ค Budget ของ Bundle

Performance budget จะมีความหมายที่สุดเมื่อระบุเป็นกิโลไบต์หลัง gzip เพราะนั่นคือสิ่งที่เครือข่ายส่งจริง ก่อนเพิ่ม dependency ใหม่ ลองเอาไฟล์ dist ของมันมา compress แล้วดูว่ามันแพงแค่ไหนเวลาอยู่บนสาย ไลบรารีที่ดูเหมือน 150 KB แบบดิบอาจใช้แค่ 45 KB หลัง gzip ซึ่งเปลี่ยนบทสนทนาทั้งหมด การเช็คแบบเดียวกันใช้ได้หลังทุกรีลีส: compress bundle แล้วเทียบกับ budget เพื่อจับ bloat ที่แอบแฝงก่อนผู้ใช้จะเจอมัน

ประเมินขนาด API Response

ผู้ใช้มือถือบนเน็ตความเร็วต่ำรู้สึกถึงทุกกิโลไบต์ของ API response ลองวาง JSON payload ตัวอย่างลงเครื่องมือเพื่อดูว่า endpoint นั้นโอนจริงกี่ไบต์หลังผ่าน compression ถ้าขนาดหลัง gzip ยังไม่น่าพอใจ คุณมีหลักฐานชัด ๆ สำหรับการทำ pagination, การตัดฟิลด์ หรือการแยก response ใหญ่เป็นหลาย call เล็ก ๆ วัดซ้ำหลังแก้ทุกครั้งเพื่อให้การคุยยึดอยู่ที่ไบต์ ไม่ใช่ความเห็น

ลดขนาดไฟล์ Config

ไฟล์ config ที่ฝังอยู่ใน deployment แบบ serverless, Docker image หรือเครื่องมือ HTML ไฟล์เดียว ล้วนเพิ่มเวลา startup และขนาด artifact ลอง compress ไฟล์ YAML, JSON หรือ TOML ของคุณเพื่อดูว่า config ที่ยาวเหยียดสร้างภาระแค่ไหน เรื่องเดียวกันใช้กับ HTML template แบบ inline: ตัด markup ที่ไม่จำเป็นออกด้วย HTML Tag Remover แล้ววัดใหม่ จะเห็นชัดว่า template ของคุณหอบน้ำหนักตายตัวมาแค่ไหน ไฟล์ config มักไม่ค่อยถูกตรวจ และนี่คือการตรวจที่เร็วที่สุดเท่าที่หาได้

สอนเรื่องการ Compress

เครื่องมือนี้ยังเป็นห้องเรียนขนาดกระทัดรัด ลองวางย่อหน้าภาษาอังกฤษปกติแล้วจด savings จากนั้นวางตัวอักษรสุ่มความยาวเท่ากันแล้วดู savings ลดลงจนใกล้ศูนย์ การสาธิตครั้งเดียวสอนเรื่อง "ทำไม compression ถึงได้ผล" มากกว่าทฤษฎีหนึ่งหน้า เพราะผู้เรียนเห็นความซ้ำกลายเป็นไบต์แบบเรียลไทม์ ใช้ได้ดีไม่แพ้กันในการ onboard ทีม เวลาอธิบายว่าทำไม dashboard ถึงรายงานขนาดหลัง gzip แทนขนาดไฟล์ดิบ

แนวทางปฏิบัติที่ดีที่สุด

• วัดที่ gzip ไม่ใช่ขนาดดิบ ให้ตัวเลขหลัง compress เป็นค่าอ้างอิงเริ่มต้นสำหรับ budget, changelog และการเปรียบเทียบ เพราะมันใกล้เคียงกับสิ่งที่ผู้ใช้ดาวน์โหลดจริง
• เปิด compression ที่ server ด้วย เครื่องมือนี้ประมาณขนาดที่โอน แต่ server หรือ CDN ของคุณต้องส่ง response แบบ compress จริง เช็ค header Content-Encoding: gzip ใน network panel เพื่อให้ค่าประมาณตรงกับความจริง
• อย่า compress รูปกับวิดีโอซ้ำอีก JPEG, PNG, WebP, MP4 และ WebM ถูก compress มาแล้ว การ compress ซ้ำเปลือง CPU และอาจทำให้ไฟล์ใหญ่ขึ้นด้วยซ้ำ ปล่อยเสิร์ฟตามเดิม
• เทียบของกับของ เวลาประเมินสอง bundle หรือสองฟอร์แมต payload ให้ gzip ทั้งคู่ก่อนตัดสิน เพราะการเทียบขนาดดิบมักตัดสินผิดฝ่ายเป็นประจำ
• วัดซ้ำหลังการเปลี่ยนแปลงที่สำคัญ Savings เปลี่ยนตามเนื้อหา ควรวัดใหม่หลัง refactor ใหญ่, อัปเกรด dependency หรือแก้ schema อย่าเชื่อตัวเลขจากไตรมาสที่แล้ว
• ถือว่า gzip เป็นจุดต่ำสุด ไม่ใช่ข้ออ้าง อัตรา compress ที่ดีช่วยลดโทษของ payload หนัก แต่ไม่เคยตัดมันทิ้ง การประหยัด 70% จากไฟล์หนึ่งเมกะไบต์ที่ไม่จำเป็น ก็ยังส่ง 300 KB ที่ไม่มีใครต้องการเหมือนเดิม

พร้อมดูแล้วว่าไฟล์ของคุณหนักแค่ไหนจริง ๆ หรือยัง? เปิด Gzip Size Calculator ฟรี วาง bundle, payload หรือ config ลงไป แล้วรับขนาดที่โอนจริงพร้อม savings percentage ภายในไม่กี่วินาที ทั้งหมดในเบราว์เซอร์ของคุณ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• JSON Formatter — ตรวจสอบ, จัดรูปแบบ และ minify JSON payload ที่เพิ่งวัดขนาดการส่งไป
• HTML Tag Remover — ตัด markup ออกจาก template และ snippet ก่อนนำไป compress
• Code Minifier — ลบ whitespace และคอมเมนต์จากซอร์สโค้ด แล้ว compress ซ้ำเพื่อดูส่วนลดรวม

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

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

ถ: Gzip Size Calculator อัปโหลดข้อมูลของฉันไปที่ไหนหรือเปล่า?

ตอบ: ไม่เลย การ compress ทำงานในเบราว์เซอร์บนเครื่องคุณทั้งหมด ข้อความและไฟล์ของคุณไม่เคยถูกส่งไปหรือเก็บไว้ที่ server ใด ๆ

ถ: ผลลัพธ์จะตรงกับสิ่งที่ server ของฉันส่งจริงไหม?

ตอบ: โดยทั่วไปจะใกล้เคียงมาก server อาจใช้ compression level ต่างกันหรือใช้ Brotli แทน gzip จึงควรมองผลลัพธ์เป็นค่าประมาณขนาดที่โอนที่แม่นยำ ไม่ใช่การรับประกันระดับไบต์

ถ: ทำไม PNG หรือ JPEG ของฉัน compress แล้วแทบไม่ลดขนาด?

ตอบ: ฟอร์แมตรูปภาพอย่าง PNG, JPEG และ WebP ถูก compress มาแล้วภายใน gzip จึงเจอความซ้ำเหลืออยู่น้อยมากและบางทียังเพิ่ม overhead อีกไม่กี่ไบต์ นั่นคือเหตุผลที่ savings percentage ออกมาใกล้ศูนย์

ถ: ใส่ไฟล์ขนาดใหญ่แค่ไหนได้?

ตอบ: ไฟล์ข้อความขนาดใหญ่พอสมควรใช้ได้ดีบนเบราว์เซอร์สมัยใหม่เพราะทุกอย่างรันในหน่วยความจำเครื่องคุณ ไฟล์ขนาดมหึมาหลายร้อยเมกะไบต์จะถูกจำกัดด้วยหน่วยความจำที่มี ควรใช้ command line tool แทน

ถ: gzip เปลี่ยนเนื้อหาของฉันหรือเปล่า?

ตอบ: ไม่เปลี่ยนแปลง gzip เป็นการ compress แบบ lossless ผลลัพธ์หลังคลายจะเหมือนต้นฉบับระดับไบต์ จึงใช้ได้อย่างปลอดภัยกับโค้ด, config และไฟล์ข้อมูล