ขนาด DOM ขนาดใหญ่ส่งผลต่อการโต้ตอบมากกว่าที่คุณคิด คู่มือนี้จะอธิบายสาเหตุและสิ่งที่คุณทำได้
ไม่สามารถทำได้ กล่าวคือ เมื่อคุณสร้างหน้าเว็บ หน้านั้นจะต้องมี Document Object Model (DOM) DOM จะแสดงโครงสร้าง HTML ของหน้าเว็บ และให้ JavaScript และ CSS ในการเข้าถึงโครงสร้างและเนื้อหาของหน้าเว็บ
อย่างไรก็ตาม ปัญหาคือขนาดของ DOM ส่งผลต่อความสามารถของเบราว์เซอร์ในการแสดงผลหน้าเว็บอย่างรวดเร็วและมีประสิทธิภาพ กล่าวโดยทั่วไปคือ ยิ่ง DOM มีขนาดใหญ่เท่าใด การแสดงผลหน้านั้นในตอนแรกและอัปเดตการแสดงผลในภายหลังก็จะยิ่งมีราคาสูงเท่านั้น
ปัญหานี้จะทำให้เกิดปัญหาในหน้าที่มี DOM ขนาดใหญ่มากเมื่อการโต้ตอบที่แก้ไขหรืออัปเดต DOM จะทริกเกอร์เลย์เอาต์ที่มีราคาแพงซึ่งส่งผลต่อความสามารถของหน้าเว็บในการตอบสนองอย่างรวดเร็ว งานเลย์เอาต์ที่มีราคาแพงอาจส่งผลกระทบต่อการโต้ตอบกับ Next Paint (INP) ของหน้าเว็บ หากคุณต้องการให้หน้าเว็บตอบสนองการโต้ตอบของผู้ใช้อย่างรวดเร็ว สิ่งสำคัญคือต้องตรวจสอบว่าขนาด DOM ของคุณมีขนาดใหญ่เท่าที่จำเป็นเท่านั้น
เมื่อ DOM ของหน้าเว็บมากเกินไป
จาก Lighthouse ได้ระบุว่า DOM ของหน้าเว็บมีขนาดใหญ่เกินเมื่อมีโหนดเกิน 1,400 โหนด Lighthouse จะเริ่มแสดงคำเตือนเมื่อ DOM ของหน้าเว็บเกิน 800 โหนด ใช้ HTML ต่อไปนี้เป็นตัวอย่าง
<ul>
<li>List item one.</li>
<li>List item two.</li>
<li>List item three.</li>
</ul>
ในโค้ดข้างต้นมีองค์ประกอบ DOM 4 อย่าง ได้แก่ องค์ประกอบ <ul>
และองค์ประกอบย่อย <li>
3 รายการ หน้าเว็บของคุณจะมีโหนดมากกว่านี้อีกหลายโหนด คุณจึงควรทำความเข้าใจสิ่งที่ทำได้เพื่อให้ขนาด DOM ตรวจสอบอยู่เสมอ รวมถึงกลยุทธ์อื่นๆ ในการเพิ่มประสิทธิภาพการแสดงผลเมื่อคุณได้รับ DOM ของหน้าเว็บให้เล็กที่สุดเท่าที่จะเป็นไปได้
DOM ขนาดใหญ่ส่งผลต่อประสิทธิภาพของหน้าเว็บอย่างไร
DOM ขนาดใหญ่ส่งผลต่อประสิทธิภาพของหน้าเว็บใน 3 ลักษณะ ดังนี้
- ระหว่างการแสดงผลครั้งแรกของหน้าเว็บ เมื่อใช้ CSS กับหน้าเว็บ ระบบจะสร้างโครงสร้างที่คล้ายกับ DOM ซึ่งรู้จักกันในชื่อ CSS Object Model (CSSOM) เมื่อตัวเลือก CSS มีความเฉพาะเจาะจงมากขึ้น CSSOM จะซับซ้อนมากขึ้นและต้องใช้เวลาเพิ่มขึ้นในการเรียกใช้เลย์เอาต์ที่จำเป็น การจัดรูปแบบ การประกอบ และการวาดภาพซึ่งจำเป็นต่อการวาดหน้าเว็บลงในหน้าจอ งานที่เพิ่มเข้ามานี้จะเพิ่มเวลาในการตอบสนองของการโต้ตอบสำหรับการโต้ตอบที่เกิดขึ้นในช่วงแรกๆ ระหว่างการโหลดหน้าเว็บ
- เมื่อการโต้ตอบแก้ไข DOM ไม่ว่าจะผ่านการแทรกหรือการลบองค์ประกอบ หรือด้วยการแก้ไขเนื้อหาและรูปแบบ DOM การทำงานที่จำเป็นในการแสดงผลการอัปเดตนั้นอาจส่งผลให้มีการออกแบบ การจัดรูปแบบ การจัดวางองค์ประกอบ และการวาดภาพซึ่งมีค่าใช้จ่ายสูง ในกรณีของการแสดงผลครั้งแรกของหน้าเว็บ ความจำเพาะของตัวเลือก CSS ที่เพิ่มขึ้นอาจเพิ่มไปยังการแสดงผลเมื่อมีการแทรกองค์ประกอบ HTML ลงใน DOM ซึ่งเป็นผลจากการโต้ตอบ
- เมื่อ JavaScript ค้นหาใน DOM ระบบจะจัดเก็บการอ้างอิงถึงองค์ประกอบ DOM ไว้ในหน่วยความจำ ตัวอย่างเช่น หากคุณเรียกใช้
document.querySelectorAll
เพื่อเลือกองค์ประกอบ<div>
ทั้งหมดในหน้าเว็บ ค่าใช้จ่ายด้านหน่วยความจำอาจเป็นไปได้สูงหากผลลัพธ์แสดงองค์ประกอบ DOM จำนวนมาก
![ภาพหน้าจอของงานที่ใช้เวลานานซึ่งเกิดจากการแสดงผลมากเกินไปในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome Call Stack ของงานที่ใช้เวลานานแสดงเวลาที่ต้องใช้ในการคำนวณรูปแบบหน้าเว็บใหม่ รวมถึงการระบายสีล่วงหน้า](https://web.dev/static/articles/dom-size-and-interactivity/image/a-screenshot-a-long-task-a768ec4a643a9.png?authuser=6&hl=th)
สิ่งเหล่านี้ทั้งหมดอาจส่งผลต่อการโต้ตอบ แต่รายการที่ 2 ในรายการด้านบนมีความสำคัญเป็นพิเศษ หากการโต้ตอบส่งผลให้เกิดการเปลี่ยนแปลง DOM อาจเริ่มต้นการทำงานจำนวนมากที่อาจเป็นผลให้เกิด INP ที่ไม่ดีในหน้าเว็บ
ฉันจะวัดขนาด DOM ได้อย่างไร
คุณวัดขนาด DOM ได้ 2 วิธี วิธีที่ 1 จะใช้ Lighthouse เมื่อคุณเรียกใช้การตรวจสอบ สถิติใน DOM ของหน้าเว็บปัจจุบันจะอยู่ในคอลัมน์ "หลีกเลี่ยง DOM ที่มีขนาดใหญ่เกินไป" การตรวจสอบในส่วน "การวินิจฉัย" ส่วนหัว ในส่วนนี้ คุณจะเห็นจำนวนรวมขององค์ประกอบ DOM, องค์ประกอบ DOM ที่มีองค์ประกอบย่อยส่วนใหญ่ รวมถึงองค์ประกอบ DOM ที่ลึกที่สุด
วิธีที่ง่ายกว่าคือการใช้คอนโซล JavaScript ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ในเบราว์เซอร์หลักๆ หากต้องการดูจำนวนองค์ประกอบ HTML ทั้งหมดใน DOM คุณสามารถใช้โค้ดต่อไปนี้ในคอนโซลหลังจากที่หน้าเว็บโหลดแล้ว
document.querySelectorAll('*').length;
หากต้องการดูการอัปเดตขนาด DOM แบบเรียลไทม์ คุณสามารถใช้เครื่องมือตรวจสอบประสิทธิภาพได้เช่นกัน เมื่อใช้เครื่องมือนี้ คุณจะเชื่อมโยงการดำเนินการเลย์เอาต์และการจัดรูปแบบ (และประสิทธิภาพด้านอื่นๆ ด้านประสิทธิภาพ) กับขนาด DOM ปัจจุบันได้
![ภาพหน้าจอของการตรวจสอบประสิทธิภาพใน Chrome DevTools ทางด้านซ้ายมีแง่มุมต่างๆ ของประสิทธิภาพหน้าเว็บที่สามารถตรวจสอบได้อย่างต่อเนื่องตลอดอายุของหน้าเว็บ ในภาพหน้าจอ จำนวนโหนด DOM, เลย์เอาต์ต่อวินาที และการคำนวณรูปแบบต่อส่วนใหม่กำลังได้รับการตรวจสอบอย่างต่อเนื่อง](https://web.dev/static/articles/dom-size-and-interactivity/image/a-screenshot-the-perform-d46dd7f32a5de.png?authuser=6&hl=th)
หากขนาดของ DOM ใกล้ถึงเกณฑ์คำเตือนของขนาด Lighthouse DOM หรือล้มเหลวเลย ขั้นตอนถัดไปคือการหาวิธีลดขนาด DOM เพื่อปรับปรุงความสามารถของหน้าเว็บในการตอบสนองต่อการโต้ตอบของผู้ใช้ เพื่อให้ INP ของเว็บไซต์พัฒนาขึ้น
ฉันจะวัดจำนวนองค์ประกอบ DOM ที่ได้รับผลกระทบจากการโต้ตอบได้อย่างไร
หากคุณกำลังทำโปรไฟล์การโต้ตอบช้าในห้องทดลองที่คุณสงสัยว่าอาจเกี่ยวข้องกับขนาดของ DOM ของหน้าเว็บ คุณสามารถดูจำนวนองค์ประกอบ DOM ที่ได้รับผลกระทบได้ โดยเลือกกิจกรรมใดๆ ก็ตามในเครื่องมือสร้างโปรไฟล์ที่มีป้ายกำกับว่า "คำนวณรูปแบบใหม่" แล้วสังเกตข้อมูลบริบทในแผงด้านล่าง
![ภาพหน้าจอของกิจกรรมการคำนวณรูปแบบใหม่ที่เลือกในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome แทร็กการโต้ตอบด้านบนจะแสดงการโต้ตอบการคลิก และงานส่วนใหญ่จะใช้ในการคำนวณสไตล์ใหม่และระบายสีก่อนวาดเสร็จ แผงจะแสดงรายละเอียดเพิ่มเติมของกิจกรรมที่เลือกที่ด้านล่าง ซึ่งรายงานว่าได้รับผลกระทบจากองค์ประกอบ DOM จำนวน 2,547 รายการ](https://web.dev/static/articles/dom-size-and-interactivity/image/a-screenshot-selected-st-9a6c0cc217aa3.png?authuser=6&hl=th)
ในภาพหน้าจอด้านบน ให้สังเกตว่าการคำนวณรูปแบบอีกครั้งของงานจะแสดงจำนวนองค์ประกอบที่ได้รับผลกระทบเมื่อเลือกงาน ในขณะที่ภาพหน้าจอด้านบนแสดงให้เห็นกรณีที่สุดโต่งของผลกระทบของขนาด DOM ที่มีต่อการแสดงผลในหน้าที่มีองค์ประกอบ DOM จำนวนมาก แต่ข้อมูลการวินิจฉัยนี้จะมีประโยชน์ในกรณีต่างๆ ในการพิจารณาว่าขนาดของ DOM เป็นปัจจัยจำกัดระยะเวลาที่ใช้ในการวาดเฟรมถัดไปเพื่อตอบสนองต่อการโต้ตอบหรือไม่
ฉันจะลดขนาด DOM ได้อย่างไร
นอกจากการตรวจสอบ HTML ของเว็บไซต์เพื่อหามาร์กอัปที่ไม่จำเป็นแล้ว วิธีหลักในการลดขนาด DOM คือการลดความลึกของ DOM สัญญาณหนึ่งที่บ่งบอกว่า DOM ของคุณอาจมีความลึกโดยไม่จำเป็นคือ หากคุณเห็นมาร์กอัปที่มีลักษณะเช่นนี้ในแท็บองค์ประกอบของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์
<div>
<div>
<div>
<div>
<!-- Contents -->
</div>
</div>
</div>
</div>
เมื่อเห็นรูปแบบเช่นนี้ คุณอาจทำให้รูปแบบเหล่านั้นง่ายขึ้นได้โดยการปรับโครงสร้าง DOM ให้แบนราบ การทำเช่นนั้นจะทำให้องค์ประกอบ DOM มีจำนวนลดลงและมีแนวโน้มที่จะทำให้คุณมีโอกาสลดความซับซ้อนของสไตล์หน้าเว็บ
ความลึกของ DOM อาจเป็นลักษณะปัญหาของเฟรมเวิร์กที่คุณใช้ โดยเฉพาะอย่างยิ่ง เฟรมเวิร์กที่อิงตามคอมโพเนนต์ เช่น เฟรมเวิร์กที่ใช้ JSX กำหนดให้คุณต้องฝังคอมโพเนนต์หลายรายการในคอนเทนเนอร์ระดับบนสุด
อย่างไรก็ตาม เฟรมเวิร์กจำนวนมากช่วยให้คุณหลีกเลี่ยงการซ้อนคอมโพเนนต์โดยใช้สิ่งที่เรียกว่าส่วนย่อยได้ เฟรมเวิร์กที่อิงตามคอมโพเนนต์ที่เสนอ Fragment เป็นฟีเจอร์รวมถึง (แต่ไม่จำกัดเพียง) รายการต่อไปนี้
คุณลดความลึกของ DOM ได้โดยใช้ Fragment ในเฟรมเวิร์กที่คุณเลือก หากคุณกังวลเกี่ยวกับผลกระทบจากการแยกโครงสร้าง DOM ที่มีต่อการจัดรูปแบบ คุณอาจได้ประโยชน์จากการใช้โหมดเลย์เอาต์ที่ทันสมัยกว่า (และเร็วกว่า) เช่น flexbox หรือ grid
กลยุทธ์อื่นๆ ที่ควรพิจารณา
แม้ว่าคุณจะพบปัญหาในการแยกโครงสร้าง DOM และนำองค์ประกอบ HTML ที่ไม่จำเป็นออกเพื่อให้ DOM มีขนาดเล็กที่สุด แต่ DOM ยังคงมีขนาดค่อนข้างใหญ่และเริ่มการแสดงผลได้เป็นจำนวนมากเมื่อมีการเปลี่ยนแปลงตามการโต้ตอบของผู้ใช้ หากคุณพบว่าตนเองอยู่ในตำแหน่งนี้ ก็อาจมีกลยุทธ์อื่นๆ ที่คุณอาจนำไปใช้จำกัดการแสดงผลได้
พิจารณาใช้แนวทางเสริม
คุณอาจอยู่ในตำแหน่งที่เนื้อหาส่วนใหญ่ของหน้าเว็บไม่สามารถแสดงต่อผู้ใช้ได้ตั้งแต่เริ่มแสดงผลครั้งแรก การทำเช่นนี้อาจเป็นโอกาสในการโหลด HTML แบบ Lazy Loading ด้วยการละเว้นส่วนเหล่านั้นของ DOM เมื่อเริ่มต้นใช้งาน แต่ให้เพิ่มเข้ามาเมื่อผู้ใช้มีการโต้ตอบกับส่วนต่างๆ ของหน้าที่ต้องใช้ด้านที่ซ่อนอยู่ของหน้าในตอนแรก
วิธีการนี้มีประโยชน์ทั้งในระหว่างการโหลดครั้งแรกและบางทีหลังจากนั้น สำหรับการโหลดหน้าเว็บเริ่มต้น คุณจะลดการแสดงผลงานแรกลง ซึ่งหมายความว่าเพย์โหลด HTML เริ่มต้นจะเบาลงและจะแสดงผลได้เร็วขึ้น ซึ่งจะทำให้การโต้ตอบในระหว่างระยะเวลาสำคัญดังกล่าวมีโอกาสมากขึ้นในการทำงานโดยมีการแข่งขันเพื่อชิงความสนใจของชุดข้อความหลักน้อยลง
หากคุณมีหลายส่วนของหน้าเว็บที่ถูกซ่อนไว้ตอนโหลด ก็อาจทำให้การโต้ตอบอื่นๆ ที่ทริกเกอร์การแสดงผลอีกครั้งเร็วขึ้นด้วย อย่างไรก็ตาม เมื่อการโต้ตอบอื่นๆ เพิ่มเข้าใน DOM งานการแสดงผลจะเพิ่มขึ้นเมื่อ DOM เติบโตขึ้นตลอดวงจรของหน้า
การเพิ่ม DOM เมื่อเวลาผ่านไปอาจยุ่งยากและมีข้อดีข้อเสียของตัวเอง หากใช้เส้นทางนี้ ก็มีแนวโน้มว่าคุณจะสร้างคำขอของเครือข่ายเพื่อรับข้อมูลที่จะเติม HTML ที่คุณตั้งใจจะเพิ่มลงในหน้าเว็บเพื่อตอบสนองต่อการโต้ตอบของผู้ใช้ แม้ว่าคำขอเครือข่ายที่กำลังดำเนินการอยู่จะไม่นับรวมใน INP แต่ก็สามารถเพิ่มเวลาในการตอบสนองที่รับรู้ได้ หากเป็นไปได้ ให้แสดงไอคอนหมุนแสดงการโหลดหรือสัญญาณบอกสถานะอื่นๆ ว่ากำลังดึงข้อมูลอยู่ เพื่อให้ผู้ใช้เข้าใจว่ากำลังมีบางอย่างเกิดขึ้น
จำกัดความซับซ้อนของตัวเลือก CSS
เมื่อเบราว์เซอร์แยกวิเคราะห์ตัวเลือกใน CSS เบราว์เซอร์จะต้องข้ามผ่านแผนผัง DOM เพื่อทำความเข้าใจวิธี และหากตัวเลือกเหล่านั้นมีผลกับเลย์เอาต์ปัจจุบัน ยิ่งตัวเลือกเหล่านี้มีความซับซ้อนมากเท่าใด เบราว์เซอร์ก็ต้องทำงานมากขึ้นเท่านั้นเพื่อที่จะแสดงผลทั้งการแสดงผลครั้งแรกของหน้าเว็บ รวมทั้งการคำนวณรูปแบบและการออกแบบใหม่ที่มีประสิทธิภาพมากขึ้นถ้าหน้าเว็บมีการเปลี่ยนแปลงเนื่องจากการโต้ตอบ
ใช้พร็อพเพอร์ตี้ content-visibility
CSS เสนอพร็อพเพอร์ตี้ content-visibility
ซึ่งเป็นวิธีแสดงผลองค์ประกอบ DOM นอกหน้าจออย่างมีประสิทธิภาพ และจะแสดงผลตามคำขอเมื่อองค์ประกอบเข้าใกล้วิวพอร์ต ประโยชน์ของ content-visibility
ไม่เพียงตัดการแสดงผลจำนวนมากในการแสดงผลหน้าเว็บเริ่มต้น แต่ยังข้ามการแสดงผลสำหรับองค์ประกอบนอกหน้าจอเมื่อ DOM ของหน้ามีการเปลี่ยนแปลงอันเป็นผลมาจากการโต้ตอบของผู้ใช้
บทสรุป
การลดขนาด DOM ให้มีขนาดเท่าที่จำเป็นเท่านั้นเป็นวิธีที่ดีในการเพิ่มประสิทธิภาพ INP ของเว็บไซต์ การดำเนินการดังกล่าวจะช่วยลดเวลาที่เบราว์เซอร์ใช้ในการจัดเลย์เอาต์และแสดงผลเมื่อมีการอัปเดต DOM แม้ว่าคุณจะลดขนาด DOM ได้อย่างมีนัยสำคัญ แต่ก็มีเทคนิคบางอย่างที่คุณสามารถใช้เพื่อแยกการแสดงผลงานไปยังแผนผังย่อย DOM เช่น การควบคุม CSS และพร็อพเพอร์ตี้ CSS content-visibility
ไม่ว่าจะเลือกอะไร การสร้างสภาพแวดล้อมที่ลดการแสดงผลงานลง รวมทั้งลดจำนวนการแสดงผลหน้าเว็บเพื่อตอบสนองต่อการโต้ตอบ ผลก็คือเว็บไซต์จะตอบสนองผู้ใช้มากขึ้นเมื่อโต้ตอบกับผู้ใช้ ซึ่งหมายความว่าคุณจะมี INP ลดลงสำหรับเว็บไซต์ของคุณ และนั่นหมายถึงประสบการณ์ของผู้ใช้ที่ดียิ่งขึ้น
รูปภาพหลักจาก Unsplash โดย Louis Reed