ค้นหาและลบ Unused CSS ด้วย Unused CSS Finder
วาง HTML และ CSS ลงใน Unused CSS Finder ฟรี เพื่อค้นหา selector ที่ไม่ถูกใช้ ประมาณจำนวน byte ที่ประหยัดได้ และคัดลอก stylesheet ฉบับ used-only ทำงานทั้งหมดในเบราว์เซอร์ของคุณ
Table of Contents
ค้นหาและลบ Unused CSS ด้วย Unused CSS Finder
Stylesheet แทบไม่มีวันเล็กลงด้วยตัวเอง ทุกครั้งที่รีดีไซน์ ทุกการทดลองที่ถูกทิ้งระหว่างทาง หรือแบนเนอร์โปรโมชัน "ชั่วคราว" ล้วนทิ้งกฎเก่าๆ เอาไว้เสมอ หลังจากสะสมมาหลายปี โปรเจกต์ทั่วไปมักจะเจอ stylesheet ที่กฎส่วนใหญ่ไม่ตรงกับอะไรในหน้าเว็บเลย — ไม่ว่าจะเป็น selector ของคอมโพเนนต์ที่ถูกลบไปแล้ว breakpoint ที่ไม่มีใครใช้ หรือ hack สำหรับเบราว์เซอร์ที่เลิกใช้ไปนาน แต่ของตายพวกนี้ยังคงถูกเขียน ถูก parse และถูกดาวน์โหลดโดยผู้ใช้ทุกคนอยู่ดี
Unused CSS Finder คือเครื่องมือสำหรับนักพัฒนาแบบฟรีที่จัดการปัญหานี้โดยตรง คุณเพียงวาง HTML และ CSS ลงไป เครื่องมือจะ parse stylesheet ตรวจ selector ทุกตัวกับมาร์กอัปของคุณ แล้วรายงานว่ากฎไหนไม่ตรงกับอะไรเลย พร้อมประมาณจำนวน byte ที่กฎ unused เหล่านี้ทำให้คุณเสียเปล่า และยังสร้าง stylesheet ฉบับ used-only ให้คัดลอกไปใช้ได้ในคลิกเดียว การวิเคราะห์ทั้งหมดรันในเบราว์เซอร์ของคุณ — ไม่ต้องอัปโหลด ไม่ต้องสมัครสมาชิก ไม่มีการส่งข้อมูลไปเซิร์ฟเวอร์
บทความนี้จะพาไปดูว่าเครื่องมือทำงานอย่างไร "unused" ในบริบทนี้หมายความว่าอะไรกันแน่ และวิธีล้าง stylesheet ให้เร็วแต่ยังปลอดภัย
ทำไมต้องใช้ Unused CSS Finder?
- ได้คำตอบทันทีโดยไม่ต้องติดตั้งอะไรเลย ไม่มี build step ไม่มีไฟล์ config ไม่ต้อง install package เพิ่ม เพียงวางข้อความสองก้อนแล้วอ่านรายงาน สำหรับการตรวจ landing page หรือ email template อย่างรวดเร็ว วิธีนี้เร็วกว่าการต่อ coverage tool หลายเท่า
- ได้ตัวเลขประหยัด byte ที่จับต้องได้ แทนที่จะเป็นคำเตือนกำกวมๆ ว่า "มี dead code" เครื่องมือจะรวมจำนวน byte ที่ติดอยู่ในกฎ unused และแสดงสัดส่วนเทียบกับ stylesheet ทั้งไฟล์ เพื่อให้คุณจัดลำดับความสำคัญจากชิ้นใหญ่ที่สุดก่อน
- คัดลอก stylesheet ฉบับ used-only ได้ทันที นอกจากชี้กฎตายแล้ว เครื่องมือยังประกอบกฎที่รอดชีวิตเป็น stylesheet ใหม่ที่คัดลอกไปใช้ได้เลย ขั้นตอนที่น่าเบื่อที่สุดถูกทำให้เสร็จสรรพ
- เป็นส่วนตัวโดยดีไซน์ การวิเคราะห์รันทั้งหมดในเบราว์เซอร์ด้วย JavaScript ฝั่ง client มาร์กอัปและสไตล์ของคุณไม่เคยถูกอัปโหลดไปที่ใด จึงใช้กับโค้ดลิขสิทธิ์ งานลูกค้า หรือ dashboard ภายในองค์กรได้อย่างปลอดภัย
- วิเคราะห์แบบเข้าใจ selector จริง engine รองรับ selector list คั่นด้วย comma, กฎที่ซ้อนอยู่ใน @media และบล็อกลักษณะเดียวกัน รวมถึง state pseudo-class อย่าง :hover รายงานจึงสะท้อนความเป็นจริงของ stylesheet ในโลกจริง
- ฟรีและไม่จำกัด ไม่มีโควตา ไม่ต้องสมัคร ไม่มีเวอร์ชันทดลองที่ตัดฟีเจอร์ ใช้กี่ครั้ง กี่หน้า ก็ได้ทั้งนั้น
ฟีเจอร์หลัก
| ฟีเจอร์ | สิ่งที่ทำ |
|---|---|
| การจับคู่ selector | parse HTML ที่วางลงไป แล้วตรวจ CSS selector ทุกตัวกับมาร์กอัปจริง |
| รายงานกฎ unused | แสดงรายการกฎที่ไม่ตรงกับ element ใดเลย พร้อม declaration block เต็ม |
| ประมาณการประหยัด byte | รวม byte ที่อยู่ในกฎ unused และแสดงสัดส่วนต่อ stylesheet ทั้งหมด |
| stylesheet ฉบับ used-only | ประกอบ stylesheet ใหม่ที่มีเฉพาะกฎที่ตรง พร้อมคัดลอกไปใช้ |
| รองรับ media query | ประเมินกฎใน @media, @supports และบล็อกซ้อนลักษณะเดียวกันตามบริบท |
| รายงาน selector ที่ parse ไม่ได้ | แยกรายการ selector ที่อ่านไม่ได้ออกมาให้เห็น ไม่มีอะไรถูกข้ามเงียบๆ |
รายละเอียดที่ควรรู้เพิ่มเติม:
- จัดการ comma list แบบระมัดระวัง กฎอย่าง .btn, .btn-alt จะนับว่า used ถ้า selector แม้แต่ตัวเดียวตรงกับ HTML ของคุณ ซึ่งช่วยกันสาเหตุการลบผิดพลาดที่พบบ่อยที่สุดในเครื่องมือตรวจ unused CSS แบบง่าย
- state pseudo-class ไม่ทำให้เกิด false flag selector อย่าง .card:hover หรือ input:focus จะถูกประเมินกับ element พื้นฐานที่มันอาจถูกใช้ สอดคล้องกับวิธีที่ state เหล่านี้ทำงานจริงตอน runtime
- selector เชิงโครงสร้างได้รับการยกเว้น กฎที่เล็งไปที่ *, :root, html หรือ body จะนับว่า used เสมอ เพราะมันมีผลกับทุกหน้าตามนิยาม
วิธีใช้งาน Unused CSS Finder
- เปิด Unused CSS Finder เครื่องมือโหลดทันทีและใช้ได้ในเบราว์เซอร์สมัยใหม่ทุกตัว ทั้งบนเดสก์ท็อปและมือถือ
- วาง HTML ของคุณ ใช้มาร์กอัปที่ render แล้วของหน้าหรือ template ที่ต้องการตรวจ — มาร์กอัปยิ่งใกล้เคียงของจริง รายงานยิ่งแม่น ถ้าบางส่วนของ DOM ถูกสร้างด้วย JavaScript ให้วาง HTML ที่ generate แล้ว (ดูจาก inspector ในเบราว์เซอร์) แทน source ดิบ
- วาง CSS ของคุณ วาง stylesheet ที่ต้องการวิเคราะห์ ไม่ว่าจะเป็นไฟล์ production เต็ม สไตล์ของคอมโพเนนต์เดียว หรือฉบับที่กำลังพิจารณาแก้ CSS แบบ minified ก็ใช้ได้สบาย
- อ่านรายงาน เครื่องมือจะแสดงจำนวนกฎ unused ตัวประมาณ byte ที่ประหยัดได้ และรายการ selector ที่ถูก flag ตรวจสอบสิ่งที่น่า surprise ก่อนลงมือทำอะไรทุกครั้ง
- คัดลอก stylesheet ฉบับ used-only เมื่อพอใจกับผลลัพธ์แล้ว ให้คัดลอก stylesheet ที่ถูกประกอบใหม่ไปใช้ — ตามหลักการควรใส่ใน branch ก่อน ดังที่จะอธิบายต่อไป
Unused หมายความว่าอย่างไรกันแน่
สิ่งสำคัญที่สุดที่ต้องเข้าใจคือ การวิเคราะห์นี้มีขอบเขตอยู่แค่ HTML ที่คุณวางลงไป เครื่องมือตอบคำถามที่แม่นยำเพียงข้อเดียว คือ selector เหล่านี้ตรงกับมาร์กอัปที่ให้ไปหรือไม่? ทำให้รายงานแม่นยำและคาดเดาได้ แต่ก็หมายความว่าทุกอย่างที่ไม่อยู่ในมาร์กอัปที่วางลงไปจะถูก flag — บางครั้งถูกต้อง บางครั้งไม่ใช่
มีสามกลุ่มที่ควรใส่ใจเป็นพิเศษ กลุ่มแรกคือ class ที่ถูกสร้างขึ้นแบบ dynamic ถ้า JavaScript สร้าง DOM บางส่วนตอน runtime class เหล่านั้นจะมีอยู่เฉพาะในหน้าที่ render แล้ว การวาง source ดิบจะ flag กฎของ class พวกนั้นอย่างเป็นเท็จ กลุ่มที่สองคือ state ที่ JavaScript เป็นคนสลับ class อย่าง .is-open, .active หรือ .error มักปรากฏในมาร์กอัปหลังจากผู้ใช้โต้ตอบเท่านั้น ให้วางมาร์กอัปหลังการโต้ตอบเข้าไปด้วย กลุ่มที่สามคือ ตัวแปรใน media query กฎใน @media (max-width: 768px) จะถูกประเมินตามบริบท แต่มันตรงได้เฉพาะ element ที่มีอยู่ในที่ที่คุณวาง — ถ้าวางแค่ layout เดสก์ท็อป กฎเฉพาะมือถืออาจถูก flag ทั้งที่จำเป็นอยู่
ให้ถือว่าตัวเลข byte ที่ประหยัดได้เป็นสัญญาณสำหรับจัดลำดับความสำคัญ ไม่ใช่คำสัญญาว่าไฟล์จะเล็กลงเท่านั้น ตัวเลขนี้รวม byte ดิบของกฎ unused เทียบกับ stylesheet ที่วางลงไป ส่วนการประหยัดจริงขึ้นอยู่กับ minification, การบีบอัดแบบ gzip หรือ brotli และว่าเบราว์เซอร์บล็อกการ render ด้วยไฟล์นี้หรือไม่ — โดยทั่วไปตัวเลขที่รายงานจะเป็นเพดานบนของสิ่งที่จะได้จริง แต่มันก็ยังเป็นตัวเลขที่ใช้ตัดสินว่า ควร ล้างตรงไหนได้อย่างถูกต้องที่สุด
จากนั้นคือ workflow การล้างที่ปลอดภัย snapshot ก่อน commit stylesheet ปัจจุบันเข้า version control (อย่างน้อยก็เก็บสำเนาที่ระบุวันที่ไว้) เพื่อให้ย้อนกลับได้ในไม่กี่วินาที ลบเป็นขั้นที่สอง นำ stylesheet ฉบับ used-only มาใช้ ลบกฎที่ถูก flag โดยทบทวนทีละรายการ ทดสอบ regression เป็นขั้นที่สาม คลิกดูทุกหน้าสำคัญ ทดลอง interactive state ต่างๆ และเช็คหลาย viewport ถ้าอะไรพัง snapshot จะทำให้การ rollback เป็นเรื่องเล็กมาก
ตัวอย่างการใช้งานจริง
Landing Page ก่อนเปิดตัว
หน้า marketing ถูกสร้างเร็วและแก้บ่อย มักส่งมอบเป็น HTML ที่ครบในตัวเองบวก stylesheet หนึ่งไฟล์ ซึ่งเป็น input ที่เหมาะที่สุดสำหรับเครื่องมือนี้ รันการตรวจก่อนเปิดตัวหนึ่งวัน วางมาร์กอัปสุดท้ายพร้อม CSS แล้วส่ง stylesheet ที่มีเฉพาะสิ่งที่หน้านั้นใช้จริง บนหน้าที่ทุกกิโลไบต์กระทบ conversion นี่คือ performance win ที่ได้ในราคาถูกที่สุดเท่าที่หาได้
เรียบร้อยหน้าเก่าที่สะสมขยะ
หน้าเว็บเก่าสะสมของตกค้างมากที่สุด ทั้งกฎจากงานรีดีไซน์ปี 2015, vendor prefix สำหรับเบราว์เซอร์ที่เลิกใช้แล้ว และสไตล์ของ widget ที่ถูกถอดออกไปนาน วางมาร์กอัปปัจจุบันของหน้าพร้อม stylesheet ของมัน คัดลอกผลแบบ used-only แล้วปลดระวางที่เหลือ หลายทีมตกใจที่พบว่า stylesheet เก่าครึ่งหนึ่งหรือมากกว่านั้นไม่ตรงกับอะไรเลย
เก็บกวาด Email Template
HTML email ยังคงอยู่ในโลกของ inline style และบล็อก <style> เดียวที่ใหญ่รวดเดียว และทุก byte มีผลต่อ clipping limit ของบาง email client วาง HTML ของอีเมลพร้อมบล็อกสไตล์เข้าเครื่องมือ ตัด selector ที่ไม่มี client ไหนจะ match ออกไป แล้วคัดลอก template ที่เพรียวลงกลับไปก่อนส่งครั้งถัดไป
ตรวจ CSS เป็นประจำ
ทำเครื่องมือนี้เป็นส่วนหนึ่งของ routine สุขอนามัยรายไตรมาส ตรวจ template ที่มี traffic สูงสุดทีละหน้า จดเปอร์เซ็นต์ byte ที่ unused แล้วเก็บสถิติต่อเนื่อง ตัวเลขที่ไต่ขึ้นคือสัญญาณเตือนล่วงหน้าว่าสไตล์ถูกเพิ่มเร็วกว่าที่ถูกลบ — สัญญาณที่มีค่าก่อน stylesheet จะกลายเป็นปัญหาจริงเสมอ
แนวทางปฏิบัติที่ดี
- วางมาร์กอัปที่ใกล้เคียงของจริง รวมถึง DOM ที่ JavaScript สร้าง รายงานจะดีเท่าไหร่ขึ้นอยู่กับ HTML ที่คุณให้ render หน้าในเบราว์เซอร์แล้วคัดลอก DOM จาก inspector จะได้ผลตรงจริงที่สุด
- เก็บ media query เอาไว้ เว้นแต่จะพิสูจน์ได้ว่าตายแล้ว กฎที่ถูก flag ใน media query อาจ match กับคอนเทนต์ที่คุณแค่ไม่ได้วางลงไป ตรวจกับหลาย viewport ก่อนลบเสมอ
- ทบทวน selector ที่ถูก flag ก่อนนำออก ระวัง class ที่ script ภายนอก ไลบรารี animation หรือ template ฝั่ง server เป็นคนใส่ ซึ่งอาจไม่ได้อยู่ในที่ที่คุณวางลงไป
- commit เข้า version control ก่อนเป็นอย่างแรก อย่าล้าง stylesheet ที่ยังไม่มี snapshot ปลอดภัย เส้นทาง rollback คือสิ่งที่ทำให้การตัดแบบเด็ดขาดปลอดภัย
- ทำทีละ template ไม่ใช่ทั้งไซต์ในรอบเดียว การตรวจทีละหน้าหรือทีละ template ทำให้รายงานอ่านรู้เรื่องและพื้นที่เสี่ยง regression แคบลง
- minify และบีบอัดหลังจากล้าง ไม่ใช่แทนการล้าง การลบกฎตายกับการเปิด compression เป็นสองขั้นตอนที่เสริมกัน ทำทั้งคู่ตามลำดับนี้
เริ่มล้าง Stylesheet ของคุณวันนี้
Dead CSS จะมองไม่เห็นจนกว่าคุณจะหามัน — และการหาใช้เวลาประมาณหนึ่งนาที เปิด Unused CSS Finder วาง HTML และ CSS ของคุณ แล้วดูว่า stylesheet แบก byte ที่ไม่จำเป็นไว้เท่าไร คัดลอกฉบับ used-only สั่ง commit แล้วรับหน้าเว็บที่เบาลงในทุกการเข้าชม
Related Tools You Might Like:
- Tailwind to CSS Converter — แปลง utility class ของ Tailwind เป็น CSS ธรรมดาที่ตรวจและตัดได้
- CSS to SCSS Converter — จัดโครงสร้าง stylesheet ที่เพิ่งล้างแล้วใหม่เป็น SCSS ที่ดูแลรักษาง่าย
- HTML Tag Remover — ลบ tag ที่ไม่ต้องการออกจากมาร์กอัป ก่อนหรือหลังการล้าง CSS
ขอให้สนุกกับการปรับ stylesheet ให้เพรียวลง!
คำถามที่พบบ่อย
ถ: HTML หรือ CSS ของฉันถูกอัปโหลดไปที่เซิร์ฟเวอร์หรือไม่?
ตอบ: ไม่ การวิเคราะห์ทั้งหมดรันฝั่ง client ในเบราว์เซอร์ของคุณ โค้ดไม่เคยออกจากเครื่อง จึงใช้กับ stylesheet ที่เป็นความลับขององค์กรหรือลูกค้าได้อย่างปลอดภัย
ถ: ทำไมเครื่องมือ flag class ที่รู้ว่ากำลังถูกใช้อยู่?
ตอบ: false positive ส่วนใหญ่เกิดจากขอบเขต ไม่ใช่บั๊ก ถ้า class ถูกเพิ่มโดย JavaScript ปรากฏหลังผู้ใช้โต้ตอบเท่านั้น หรือเป็นของ widget ภายนอก มันจะไม่อยู่ใน HTML ที่คุณวางลงไป ให้ใส่มาร์กอัปที่ render แล้วและหลังการโต้ตอบ ธงมักจะหายไปเอง
ถ: ตัวเลข byte ที่ประหยัดได้แม่นยำแค่ไหน?
ตอบ: เป็นการประมาณการ เครื่องมือรวม byte ดิบของกฎ unused เทียบกับ stylesheet ที่วางลงไป ส่วนการประหยัดจริงในการส่งข้อมูลยังขึ้นกับ minification และการบีบอัด และมักต่ำกว่าตัวเลขที่รายงานอยู่บ้าง
ถ: เครื่องมือเข้าใจ media query และ pseudo-class หรือไม่?
ตอบ: เข้าใจครับ กฎใน @media และบล็อกซ้อนลักษณะเดียวกันจะถูกประเมินตามบริบท และ state selector อย่าง :hover จะถูกจับคู่กับ element พื้นฐานที่มันมีผล ทำให้สไตล์แบบ interactive ไม่ถูกรายงานผิดพลาด
ถ: ล้างทั้งไซต์ในรอบเดียวได้ไหม?
ตอบ: ทำได้แต่ไม่ควร มาร์กอัปของหน้าเดียวไม่สามารถแทนไซต์ทั้งหมดได้ การวางของไซต์เดียวจะ flag ทุกกฎที่เกี่ยวกับหน้าอื่น ควรตรวจทีละ template แล้วค่อยรวมผลแบบ used-only เข้าด้วยกัน