ตัวลดขนาด HTML

ตัวลดขนาด HTML เป็นเครื่องมือฟรีที่ตัดอักขระซึ่งไม่จำเป็นออกจาก HTML แล้วส่งคืนฉบับที่กะทัดรัดกว่า พร้อมแสดงจำนวนอักขระก่อนและหลังประมวลผล

การลดขนาด HTML ทำอะไรบ้าง?

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

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

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

ใช้ตัวลดขนาด HTML อย่างไร?

ใส่เอกสารต้นฉบับในช่อง HTML แล้วเรียกใช้เครื่องมือ ระบบจะส่งคืนซอร์สฉบับกะทัดรัดในช่อง HTML ที่ลดขนาดแล้ว พร้อมค่า จำนวนอักขระ HTML และ จำนวนอักขระ HTML ที่ลดขนาดแล้ว

1. ใช้เอกสาร HTML ฉบับเต็ม หรือส่วนย่อยที่ทำงานได้อย่างสมบูรณ์ในตัวเอง
2. เรียกใช้การลดขนาด แล้วตรวจสอบมาร์กอัปที่ได้
3. เปรียบเทียบจำนวนอักขระทั้งสองค่า เพื่อยืนยันว่าขนาดลดลงมากพอที่จะเป็นประโยชน์
4. ทดสอบเอกสาร HTML ที่ลดขนาดแล้วและผลลัพธ์ที่เบราว์เซอร์แสดง ก่อนนำไปแทนที่ไฟล์บนระบบจริง

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

วิธีอ่านผลลัพธ์ที่ลดขนาดแล้ว

ผลลัพธ์จะแสดงมาร์กอัปที่ลดขนาดแล้ว พร้อมจำนวนอักขระก่อนและหลังประมวลผล หากค่า จำนวนอักขระ HTML ที่ลดขนาดแล้ว ต่ำลง แสดงว่ามีอักขระถูกตัดออก แต่ค่านี้ไม่ใช่หน่วยวัดเดียวกับขนาดไฟล์ที่ดาวน์โหลด

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

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

ตัวอย่างการใช้งานและข้อมูลป้อนเข้าที่ต้องระวัง

ตัวอย่างพื้นฐานที่เหมาะกับการลดขนาดคือการตัดการเยื้องรอบองค์ประกอบแบบบล็อกทั่วไป

ข้อมูลป้อนเข้า โดย \n แทนการขึ้นบรรทัดใหม่ <main>\n <p>Ready</p>\n</main>

รูปแบบกะทัดรัด <main><p>Ready</p></main>

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

ข้อมูลป้อนเข้า <span>Account</span> <span>settings</span>

รูปแบบกะทัดรัดที่ไม่ปลอดภัย <span>Account</span><span>settings</span>

รูปแบบที่สองอาจแสดงเป็น "Accountsettings" ควรตรวจสอบเนื้อหาอินไลน์ทุกครั้ง อย่าคิดว่าช่องว่างระหว่างแท็กทุกจุดสามารถตัดทิ้งได้

• ช่องว่างและการขึ้นบรรทัดใหม่ภายใน <pre>, <textarea> และเนื้อหาประเภทอื่นที่ไวต่อช่องว่างอาจมีความหมาย
• ตัวเลขและเครื่องหมายวรรคตอนในข้อความหรือค่าแอตทริบิวต์เป็นเนื้อหาของเอกสาร ไม่ใช่การจัดรูปแบบที่ควรตัดทิ้ง
• ตัวอักษรที่มีเครื่องหมายกำกับและอักษรที่ไม่ใช่ละตินใช้เป็นข้อความ HTML ได้อย่างถูกต้อง เมื่อเอกสารเลือกการเข้ารหัสอักขระที่เหมาะสม
• นิพจน์ของเทมเพลต คำสั่งฝั่งเซิร์ฟเวอร์ และคอมเมนต์แบบมีเงื่อนไขอาจมีกฎที่ตัวลดขนาด HTML ทั่วไปไม่เข้าใจ
• ข้อมูลป้อนเข้า HTML ที่ว่างเปล่าไม่มีสิ่งใดให้ลดขนาดอย่างเป็นประโยชน์ สำหรับเอกสาร HTML ที่ยาวมาก ควรใช้กระบวนการบิลด์ HTML ที่ทำซ้ำได้ แทนการคัดลอกด้วยตนเอง

ควรลดขนาด HTML เมื่อใด?

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

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

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

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

ลดขนาด HTML ที่มี CSS หรือ JavaScript แบบอินไลน์ได้ไหม?

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

HTML ที่ลดขนาดแล้วช่วยให้อันดับการค้นหาดีขึ้นไหม?

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

ลดขนาดเทมเพลต Twig, Blade หรือเทมเพลต HTML อื่นได้ไหม?

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

ทำไมจำนวนอักขระจึงไม่เท่ากับขนาดไฟล์?

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

การลดขนาดลบคอมเมนต์ HTML ได้อย่างปลอดภัยไหม?

คอมเมนต์มักลบได้ แต่บางรายการมีคำสั่งสำหรับกระบวนการบิลด์ คำสั่ง include ฝั่งเซิร์ฟเวอร์ หรือมาร์กอัปสำหรับความเข้ากันได้ อย่าคิดว่าคอมเมนต์ทุกส่วนตัดทิ้งได้ หากคอมเมนต์มีผลต่อการทำงานของโปรเจกต์ ให้ตรวจสอบทั้งซอร์สที่ได้และหน้าที่เรนเดอร์แล้ว

ตรวจสอบขั้นสุดท้าย

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