วิธีการทำงานของการบีบอัด CSS
ตัวบีบอัดเดินผ่านสไตล์ชีตด้วย tokeniser ที่รู้จักสถานะซึ่งแยกแยะพื้นที่ที่ต้องเก็บไว้ (string literal และค่า url()) จากช่องว่างที่แก้ไขได้ซึ่งการยุบและลบออกนั้นปลอดภัย
- เก็บ string และ URL ไว้. ก่อน transform อื่น ๆ tokeniser จะระบุทุก string ที่อยู่ในเครื่องหมายคำพูด (“…” หรือ '…') และทุกอาร์กิวเมนต์ url(…) แล้วเก็บไว้ตามตัวอักษร การ pass ถัดไปจะไม่แตะต้องไบต์เหล่านี้ ดังนั้น URL รูปภาพพื้นหลังที่มีช่องว่างหรือ property content ที่มีเครื่องหมายวรรคตอนจะถูกเก็บไว้อย่างถูกต้อง
- ลบคอมเมนต์. บล็อก
/* … */ถูกลบเมื่อเปิดสวิตช์ หากเปิดสวิตช์คอมเมนต์สัญญาอนุญาตด้วย บล็อก/*! … */จะยังคงอยู่ เพื่อให้ส่วนหัวสัญญาอนุญาต MIT, Apache และ BSD ยังอยู่ในผลลัพธ์ตามที่สัญญาอนุญาตเหล่านั้นกำหนด - ยุบช่องว่าง. ทุกชุดของช่องว่าง แท็บ และบรรทัดใหม่ยุบเป็นช่องว่างเดียว จากนั้นช่องว่างรอบอักขระโครงสร้าง CSS
{,},;,:และ,ถูกลบออกทั้งหมด รายการ selector และ value จะถูก reflow ในลักษณะเดียวกับที่ตัวแยกวิเคราะห์ของเบราว์เซอร์อ่าน - ปรับค่าให้เหมาะสม. การ pass เสริมจะทำให้รหัสสี hex เป็นตัวพิมพ์เล็ก ยุบ hex channel 6 หลักที่เป็นคู่กันเป็นรูปย่อ 3 หลัก (
#aabbcc→#abc) และลบหน่วยมิติออกจากค่าศูนย์ (0px→0) การ pass ลบหน่วยศูนย์จะข้ามค่าภายในการเรียกtransform()ที่หน่วยมีความสำคัญ - รายงานไบต์ที่ประหยัด. ทั้งข้อความต้นฉบับและข้อความที่บีบอัดแล้วถูกวัดด้วย
new TextEncoder().encode(…).byteLength— จำนวนไบต์ UTF-8 เดียวกับที่ CDN หรือเซิร์ฟเวอร์ HTTP จะเห็น แถบเมตริกแสดงขนาดเดิม ขนาดที่บีบอัด ไบต์ที่ประหยัด และเปอร์เซ็นต์ที่ประหยัด
ทำไมต้องบีบอัด CSS
- โหลดเร็วขึ้นโดยไม่ block การแสดงผล. เบราว์เซอร์จะไม่วาดแม้แต่หนึ่งพิกเซลจนกว่าจะแยกวิเคราะห์ CSS เสร็จ การลดสไตล์ชีต 30 เปอร์เซ็นต์จะย่น block นั้น ยก First Contentful Paint และแสดงผลโดยตรงในคะแนน Lighthouse Performance
- ค่า egress CDN ต่ำลง. CloudFront, Cloudflare และ Fastly เรียกเก็บเงินต่อกิกะไบต์ของการส่งออก การลด 20 เปอร์เซ็นต์จากสไตล์ชีตที่โหลดในทุก page view จะกลายเป็นรายการจริงในใบแจ้งหนี้เมื่อ traffic รายเดือนเกินหลายล้าน view
- ส่วนฝังและ CSS อีเมลที่เล็กลง. เทมเพลตอีเมลธุรกรรม inline CSS เพื่อผ่านปัญหาการแสดงผลของ Outlook และ Gmail และทุกไบต์พิเศษนำคุณเข้าใกล้ขีดจำกัดการตัด 102 KB ของ Gmail การบีบอัดก่อน inline จะทำให้ข้อความอยู่ใต้ขีดจำกัด
- ไม่ต้องพึ่ง build tool. งานครั้งเดียว repo เก่าที่ไม่มี build pipeline และสภาพแวดล้อมที่ไม่มีอินเทอร์เน็ต ไม่จำเป็นต้องมี Node toolchain เสมอไป คุณสามารถรัน pass ที่นี่โดยไม่ต้องติดตั้ง PostCSS, cssnano หรืออะไรอื่น
การใช้งานทั่วไป
CSS minification ปรากฏท้าย front-end build pipeline แทบทุกแห่งและในบริบท runtime หลายอย่างที่จำนวนไบต์สำคัญ
- Production build pipeline: Webpack, Vite, Rollup และ Parcel ต่างมีขั้นตอน CSS minification ใน production mode เริ่มต้น การรัน pass ที่นี่ก่อน commit ช่วยให้ตรวจสอบผลลัพธ์โดยไม่ต้องรัน build เต็ม
- ฝัง CSS ใน tag
<style>: framework ที่ server-render ซึ่ง inline critical CSS ลงใน HTML document ได้รับประโยชน์จากการประหยัดไบต์เดียวกันกับสไตล์ชีตแบบ standalone และ inline CSS ที่เล็กลงจะลด Time to First Byte - อีเมลธุรกรรมและการตลาด: HTML ของอีเมล inline CSS ทั้งหมด ดังนั้นทุกกิโลไบต์ในสไตล์ชีตจะเพิ่มขนาดข้อความรวม การบีบอัดก่อน inline จะทำให้ข้อความอยู่ใต้ขีดจำกัดขนาด ESP
ตัวอย่างที่ใช้งานได้จริง
วาง ruleset ขนาด 1 KB ที่มีการเยื้อง 2 ช่องว่าง บรรทัดว่างระหว่าง selector บล็อกคอมเมนต์สัญญาอนุญาตด้านบน และสี hex แบบยาวอย่าง #FFFFFF กับ margin แบบ zero-padded อย่าง margin: 0px เมื่อเปิดทุกตัวเลือก ผลลัพธ์จะยุบลงเหลือประมาณ 600 ไบต์ — ประหยัด 40 เปอร์เซ็นต์ — ขณะที่หน้าที่แสดงผลดูเทียบเท่าไบต์กับซอร์ส
CSS minification เปลี่ยนพฤติกรรม CSS ของฉันหรือไม่?
ไม่ เมื่อใช้สวิตช์เริ่มต้น ตัวบีบอัดเก็บเฉพาะไบต์ที่ตัวแยกวิเคราะห์ CSS ละทิ้งอยู่แล้ว — ช่องว่าง คอมเมนต์ เซมิโคลอนท้ายเสริม — และข้ามภายใน transform() ที่หน่วยมีความสำคัญ ทุก selector, property และ value ถูกเก็บไว้
รองรับ SCSS หรือ LESS หรือไม่?
รองรับได้ก็ต่อเมื่อ compile เป็น CSS ธรรมดาก่อนเท่านั้น syntax ของ SCSS และ LESS (ตัวแปร การ nest mixins selector ด้วย &) ไม่ใช่ CSS ที่ถูกต้อง และตัวบีบอัดจะทำให้เสียหาย compile preprocessor source ก่อน แล้ว paste ผลลัพธ์ที่ compile แล้วที่นี่
ทำไมคอมเมนต์สัญญาอนุญาตของฉันถูกลบ?
"ลบคอมเมนต์" เปิดอยู่ตามค่าเริ่มต้นและลบทุกบล็อก /* … */ เปิดใช้ "เก็บคอมเมนต์ /*! สัญญาอนุญาต" เพื่อเก็บบล็อกที่เริ่มด้วย /*! ไว้ สัญญาอนุญาต MIT, Apache และ BSD ต่างกำหนดให้ส่วนหัว copyright ต้องอยู่ใน CSS ที่แจกจ่าย
สามารถประหยัดได้เท่าไร?
CSS ที่เขียนด้วยมือมักลดลง 15 ถึง 35 เปอร์เซ็นต์ ไฟล์ที่มีคอมเมนต์หนาแน่นหรือเยื้องลึกพร้อม color literal จำนวนมากอาจถึง 40 เปอร์เซ็นต์ ผลลัพธ์ที่ compile จาก Sass หรือ CSS-in-JS มักถูกบีบอัดบางส่วนแล้วและประหยัดน้อยกว่า — โดยทั่วไป 5 ถึง 15 เปอร์เซ็นต์
รัน CSS minification ในแท็บเบราว์เซอร์และข้าม Node toolchain ไปทั้งหมด วางสไตล์ชีตด้านบน สลับตัวเลือกตามที่ต้องการ แล้วคัดลอกผลลัพธ์หรือดาวน์โหลดเป็น .min.css ไม่มีการอัปโหลด ไม่มีบัญชี ไม่มีไลบรารีผู้จำหน่าย