เครื่องมือบีบอัด HTML

ทำไมต้องย่อขนาด HTML

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

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

เครื่องมือบีบอัดตัดอะไรออกบ้าง

แต่ละตัวเลือกมุ่งจัดการกับแหล่งที่ทำให้ไฟล์อ้วนขึ้นโดยเฉพาะ การลบคอมเมนต์ HTML (Remove HTML comments) จะลบบันทึกของนักพัฒนาและโค้ดที่ถูกคอมเมนต์ทิ้งไว้ซึ่งผู้เข้าชมไม่เคยเห็น การลบช่องว่างที่ไม่จำเป็น (Remove unnecessary whitespace) จะยุบช่องว่าง แท็บ และการขึ้นบรรทัดใหม่ระหว่างแท็กที่มีไว้เพื่อให้อ่านง่ายเท่านั้น การลบแอตทริบิวต์ว่าง (Remove empty attributes) จะตัดแอตทริบิวต์ที่ไม่มีค่าออก และการลบแท็ก HTML ที่ไม่จำเป็น (Remove optional HTML tags) จะละแท็กปิดที่สเปก HTML อนุญาตให้คุณละไว้ได้ เช่น แท็กปิดของรายการในลิสต์ในบางบริบท

การยุบแอตทริบิวต์บูลีน (Collapse boolean attributes) เป็นชัยชนะเล็ก ๆ ที่เรียบร้อยดี แอตทริบิวต์อย่าง disabled หรือ checked ไม่จำเป็นต้องมีค่าใน HTML ดังนั้นรูปแบบที่เขียนเต็มอย่าง disabled ที่กำหนดค่าเป็นสตริง disabled จึงถูกย่อให้เหลือเพียงชื่อแอตทริบิวต์ การประมวลผลเหล่านี้รวมกันจะลบอักขระที่ไม่มีผลต่อการแสดงผลเลย ซึ่งเป็นเหตุผลว่าทำไมการย่อขนาดมาตรฐานจึงปลอดภัยสำหรับหน้าเว็บที่เขียนถูกต้องตามรูปแบบ

ตัวอย่างที่ลองทำจริง

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

อะไรตัดได้อย่างปลอดภัย และอะไรเสี่ยง

ขอบเขตที่ต้องเคารพคือช่องว่างที่หน้าเว็บพึ่งพาอยู่จริง ภายในอิลิเมนต์ pre และ textarea ทุกช่องว่างและทุกการขึ้นบรรทัดใหม่มีความสำคัญ เพราะมันถูกแสดงผลตามตัวอักษรเป๊ะ ๆ ดังนั้นการยุบมันลงจะเปลี่ยนผลลัพธ์ให้เห็นได้ชัด ข้อควรระวังเดียวกันนี้ใช้กับอิลิเมนต์ที่ CSS กำหนด white-space ให้คงรูปแบบไว้ คอมเมนต์มักจะลบออกได้อย่างปลอดภัย แต่บางอันก็มีบทบาทสำคัญ เช่น คอมเมนต์แบบมีเงื่อนไขของ Internet Explorer รุ่นเก่า หรือคอมเมนต์ที่ระบบเทมเพลตหรือเฟรมเวิร์กอ่านเป็นเครื่องหมาย การลบมันออกอาจทำให้การทำงานเสียได้

ตัวเลือกการย่อขนาด CSS และ JavaScript ถูกระบุว่าเป็นการทดลอง (experimental) ด้วยเหตุผลที่ดี การย่อขนาด CSS ที่ฝังอยู่ในแท็กและแอตทริบิวต์ style หรือ JavaScript ในแท็ก script นั้นเกี่ยวข้องกับการเขียนโค้ดใหม่ ไม่ใช่แค่การตัดช่องว่างของเลย์เอาต์ออก และมีกรณีขอบที่อาจเกิดปัญหาได้ ควรทดสอบหน้าเว็บเสมอหลังเปิดใช้งานตัวเลือกเหล่านี้ โดยเฉพาะถ้าสคริปต์ของคุณพึ่งพารูปแบบเฉพาะ คำสั่งที่อาศัยคอมเมนต์ หรือการจัดการสตริงที่เปราะบาง

การย่อขนาดเกี่ยวข้องกับ gzip อย่างไร

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

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

การย่อขนาดอยู่ตรงไหนในไปป์ไลน์การ build

บนเว็บไซต์ที่ใช้งานจริง การย่อขนาดควรเกิดขึ้นโดยอัตโนมัติในฐานะส่วนหนึ่งของขั้นตอนการ build หรือการ deploy เพื่อให้ซอร์สที่คุณแก้ไขยังคงอ่านง่ายในขณะที่ผลลัพธ์ที่คุณส่งออกยังคงเล็ก บันเดิลเลอร์และตัวสร้างเว็บไซต์แบบสแตติกสมัยใหม่ส่วนใหญ่มีขั้นตอนการย่อขนาด HTML รวมอยู่ด้วย และเครื่องมือนี้เป็นวิธีรวดเร็วในการทำสิ่งเดียวกันสำหรับไฟล์เดี่ยว ๆ หน้าแลนดิงที่สร้างด้วยมือ เทมเพลตอีเมล หรือสนิปเพตที่คุณกำลังจะฝังลงไป

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

ข้อผิดพลาดที่พบบ่อยที่ควรหลีกเลี่ยง

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