เส้นทางการแสดงผลวิกฤติคือขั้นตอนที่เกี่ยวข้องจนกว่าหน้าเว็บจะเริ่มแสดงผลในเบราว์เซอร์ ในการแสดงผลหน้าเว็บ เบราว์เซอร์จำเป็นต้องมีเอกสาร HTML ของตัวเอง รวมถึงทรัพยากรสำคัญทั้งหมดที่จำเป็นต่อการแสดงผลเอกสารนั้น
การส่งเอกสาร HTML ลงในเบราว์เซอร์ครอบคลุมโดยโมดูลการพิจารณาประสิทธิภาพ HTML ทั่วไปก่อนหน้า อย่างไรก็ตาม ในโมดูลนี้ เราจะมาดูเพิ่มเติมว่าเบราว์เซอร์ทำอะไรหลังจากดาวน์โหลดเอกสาร HTML เพื่อแสดงผลหน้าเว็บ
การแสดงภาพแบบโปรเกรสซีฟ
เว็บมีการกระจายตามธรรมชาติ เบราว์เซอร์ไม่สามารถพึ่งพาเว็บไซต์ที่มีทรัพยากรทั้งหมดที่จำเป็นต่อการแสดงผลหน้าเว็บได้ ซึ่งต่างจากแอปพลิเคชันที่มาพร้อมเครื่องซึ่งติดตั้งก่อนใช้งาน ดังนั้น เบราว์เซอร์จึงแสดงหน้า ได้อย่างต่อเนื่องมากขึ้น โดยทั่วไปแอปที่มาพร้อมเครื่องจะมีระยะการติดตั้ง จากนั้นเป็นช่วงระยะการวิ่ง อย่างไรก็ตาม สำหรับหน้าเว็บและเว็บแอป เส้นแบ่งระหว่าง 2 ระยะนี้มีความแตกต่างกันมาก และเบราว์เซอร์ได้รับการออกแบบมาโดยเฉพาะโดยคำนึงถึงสิ่งนี้
เมื่อเบราว์เซอร์มีทรัพยากรที่จะแสดงหน้าเว็บ ก็มักจะเริ่มแสดงผลหน้าเว็บ ตัวเลือกนี้ขึ้นอยู่กับเวลาที่จะแสดง ซึ่งก็คือ เร็วเกินไป
หากเบราว์เซอร์แสดงผลโดยเร็วที่สุดเมื่อมี HTML เพียงบางส่วนเท่านั้น แต่ก่อนที่จะมี CSS หรือ JavaScript ที่จำเป็น หน้าเว็บอาจใช้งานไม่ได้ชั่วคราวและมีการเปลี่ยนแปลงอย่างมากในการแสดงผลสุดท้าย ซึ่งจะให้ประสบการณ์ที่แย่กว่าการนำเสนอหน้าจอว่างเปล่าเป็นระยะเวลาหนึ่งจนกว่าเบราว์เซอร์จะมีทรัพยากรเหล่านี้มากกว่าสำหรับการแสดงภาพครั้งแรกซึ่งทำให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้น
ในทางกลับกัน หากเบราว์เซอร์รอให้ทรัพยากรทั้งหมดพร้อมใช้งานแทนการแสดงผลตามลำดับ ระบบจะปล่อยให้ผู้ใช้รอเป็นเวลานาน ซึ่งโดยมากจะไม่จำเป็นถ้าหน้าเว็บใช้งานได้ในช่วงเวลาก่อนหน้านั้นมาก
เบราว์เซอร์จำเป็นต้องทราบจำนวนทรัพยากรขั้นต่ำที่ควรรอ เพื่อหลีกเลี่ยงการมอบประสบการณ์ที่ไม่สมบูรณ์แบบชัดเจน ในทางกลับกัน เบราว์เซอร์ไม่ควรรอนานเกินความจำเป็นก่อนที่จะนำเสนอเนื้อหาบางส่วนต่อผู้ใช้ ลำดับขั้นตอนที่เบราว์เซอร์ใช้ก่อนแสดงผลครั้งแรกเรียกว่าเส้นทางการแสดงผลวิกฤติ
การเข้าใจเส้นทางการแสดงผลวิกฤติจะช่วยปรับปรุงประสิทธิภาพของเว็บได้ โดยการตรวจสอบว่าคุณไม่ได้บล็อกการแสดงผลหน้าเริ่มต้นเกินความจำเป็น อย่างไรก็ตาม ในขณะเดียวกัน สิ่งที่สำคัญคือการไม่อนุญาตให้แสดงผลเร็วเกินไปโดยการนำทรัพยากรที่จำเป็นสำหรับการแสดงผลครั้งแรกออกจากเส้นทางการแสดงผลวิกฤติ
เส้นทางการแสดงผล (วิกฤติ)
เส้นทางการแสดงผลมีขั้นตอนดังต่อไปนี้
- การสร้าง Document Object Model (DOM) จาก HTML
- การสร้าง CSS Object Model (CSSOM) จาก CSS
- การใช้ JavaScript ที่เปลี่ยนแปลง DOM หรือ CSSOM
- การสร้างโครงสร้างการแสดงผลจาก DOM และ CSSOM
- ดำเนินการตามรูปแบบและเลย์เอาต์ในหน้าเว็บเพื่อดูว่าองค์ประกอบใดเหมาะสมในตำแหน่งต่างๆ
- ระบายสีพิกเซลขององค์ประกอบในหน่วยความจำ
- รวมพิกเซลเข้าด้วยกันหากพิกเซลใดภาพหนึ่งทับซ้อนกัน
- วาดพิกเซลที่ได้ทั้งหมดบนหน้าจอจริงๆ
ผู้ใช้จะเห็นเนื้อหาบนหน้าจอหลังจากที่ทำขั้นตอนเหล่านี้เสร็จแล้วเท่านั้น
กระบวนการแสดงผลนี้เกิดขึ้นหลายครั้ง การแสดงผลครั้งแรกจะเรียกใช้กระบวนการนี้ แต่เมื่อมีทรัพยากรที่มีผลต่อการแสดงผลของหน้ามากขึ้น เบราว์เซอร์จะเรียกใช้กระบวนการนี้อีกครั้ง (หรืออาจเป็นเพียงบางส่วน) เพื่ออัปเดตสิ่งที่ผู้ใช้เห็น เส้นทางการแสดงผลวิกฤติจะมุ่งเน้นที่กระบวนการที่ระบุไว้ก่อนหน้านี้สำหรับการแสดงผลครั้งแรก และขึ้นอยู่กับทรัพยากรสำคัญที่จำเป็นต่อการแสดงผล
มีทรัพยากรใดบ้างบนเส้นทางการแสดงผลวิกฤติ
เบราว์เซอร์ต้องรอการดาวน์โหลดทรัพยากรที่สำคัญบางอย่างก่อน จึงจะแสดงผลครั้งแรกเสร็จสมบูรณ์ได้ แหล่งข้อมูลเหล่านี้จะมีข้อมูลต่อไปนี้
- ส่วนของ HTML
- การแสดงผล CSS ที่บล็อกการแสดงผลในองค์ประกอบ
<head> - JavaScript ที่บล็อกการแสดงผลในองค์ประกอบ
<head>
ประเด็นสำคัญคือเบราว์เซอร์จะประมวลผล HTML ในลักษณะของการสตรีม ทันทีที่เบราว์เซอร์ได้รับส่วนใดส่วนหนึ่งของ HTML ของหน้าเว็บ เบราว์เซอร์จะเริ่มประมวลผลหน้าเว็บนั้น จากนั้นเบราว์เซอร์จะตัดสินใจแสดงผลได้ดีก่อนที่จะรับ HTML ส่วนที่เหลือของหน้าเว็บ
ที่สำคัญ ในการแสดงผลครั้งแรก เบราว์เซอร์จะไม่รอสิ่งต่อไปนี้
- HTML ทั้งหมด
- แบบอักษร
- รูปภาพ
- JavaScript ที่บล็อกการแสดงผลนอกองค์ประกอบ
<head>(เช่น องค์ประกอบ<script>ที่วางไว้ท้าย HTML) - CSS ที่บล็อกการแสดงผลนอกองค์ประกอบ
<head>หรือ CSS ที่มีค่าแอตทริบิวต์mediaซึ่งไม่ได้ใช้กับวิวพอร์ตปัจจุบัน
เบราว์เซอร์มักจะถือว่าแบบอักษรและรูปภาพเป็นเนื้อหาที่จะใส่เข้ามาในการแสดงผลหน้าถัดไปในหน้าต่อๆ มา จึงไม่จำเป็นต้องระงับการแสดงผลครั้งแรกไว้ แต่อาจหมายความว่ามีพื้นที่ว่างเปล่าในการแสดงผลครั้งแรกในขณะที่ข้อความซ่อนอยู่ขณะรอแบบอักษรหรือจนกว่ารูปภาพจะพร้อมใช้งาน แต่ที่แย่กว่านั้นคือเมื่อไม่มีการจองพื้นที่เพียงพอสำหรับเนื้อหาบางประเภท โดยเฉพาะอย่างยิ่งเมื่อไม่ได้ระบุขนาดรูปภาพใน HTML เลย์เอาต์ของหน้าอาจเปลี่ยนไปเมื่อมีการโหลดเนื้อหานี้ในภายหลัง ประสบการณ์ของผู้ใช้ในด้านนี้วัดด้วยเมตริก Cumulative Layout Shift (CLS)
องค์ประกอบ <head> เป็นกุญแจสำคัญในการประมวลผลเส้นทางการแสดงผลวิกฤติ เพราะว่าส่วนถัดไปจะพูดถึงรายละเอียดบางอย่าง การเพิ่มประสิทธิภาพเนื้อหาขององค์ประกอบ <head>
เป็นแง่มุมสำคัญของประสิทธิภาพเว็บ แต่เพื่อให้เข้าใจเส้นทางการแสดงผลที่สำคัญในตอนนี้ คุณเพียงต้องทราบว่าองค์ประกอบ <head> มีข้อมูลเมตาเกี่ยวกับหน้าและทรัพยากรของหน้า แต่ไม่มีเนื้อหาจริงที่ผู้ใช้จะเห็น เนื้อหาที่มองเห็นได้อยู่ภายในองค์ประกอบ <body> ที่ตามหลังองค์ประกอบ <head> ก่อนที่เบราว์เซอร์จะแสดงผลเนื้อหาได้ เบราว์เซอร์จำเป็นต้องมีทั้งเนื้อหาที่จะแสดงผลและข้อมูลเมตาเกี่ยวกับวิธีแสดงผล
อย่างไรก็ตาม ทรัพยากรบางส่วนที่อ้างอิงในองค์ประกอบ <head> ไม่ได้จำเป็นอย่างยิ่งในการแสดงผลหน้าเริ่มต้น ดังนั้นเบราว์เซอร์จะรอเฉพาะทรัพยากรที่จำเป็นเท่านั้น ในการระบุว่าทรัพยากรใดอยู่ในเส้นทางการแสดงผลวิกฤติ คุณต้องทำความเข้าใจ CSS และ JavaScript ที่บล็อกการแสดงผลและการบล็อกโปรแกรมแยกวิเคราะห์
ทรัพยากรที่บล็อกการแสดงผล
ทรัพยากรบางอย่างถือเป็นเรื่องสำคัญมากจนเบราว์เซอร์ต้องหยุดแสดงผลหน้าเว็บชั่วคราวจนกว่าจะจัดการได้แล้ว CSS จะอยู่ในหมวดหมู่นี้โดยค่าเริ่มต้น
เมื่อเบราว์เซอร์เห็น CSS ไม่ว่าจะเป็น CSS ในบรรทัดในองค์ประกอบ <style> หรือทรัพยากรที่อ้างอิงภายนอกที่ระบุโดยองค์ประกอบ <link rel=stylesheet href="..."> เบราว์เซอร์จะหลีกเลี่ยงการแสดงผลเนื้อหาเพิ่มเติมจนกว่าจะดาวน์โหลดและประมวลผล CSS ดังกล่าวเสร็จสมบูรณ์
การที่ทรัพยากรบล็อกการแสดงผลไม่ได้หมายความว่าทำให้เบราว์เซอร์หยุดทำสิ่งอื่นๆ ได้เสมอไป เบราว์เซอร์จะพยายามทำงานได้อย่างมีประสิทธิภาพมากที่สุด ดังนั้นเมื่อเบราว์เซอร์เห็นว่าจำเป็นต้องดาวน์โหลดทรัพยากร CSS เบราว์เซอร์จะขอและหยุดการแสดงผลชั่วคราว แต่จะยังคงประมวลผล HTML ส่วนที่เหลืออยู่และมองหางานอื่นๆ ที่ต้องทำในระหว่างนี้
ทรัพยากรที่บล็อกการแสดงผล เช่น CSS ใช้เพื่อบล็อกการแสดงผลทั้งหมดของหน้าเว็บเมื่อค้นพบ ซึ่งหมายความว่า CSS บางรายกำลังบล็อกการแสดงผลหรือไม่ ขึ้นอยู่กับว่าเบราว์เซอร์ค้นพบ CSS หรือไม่ เบราว์เซอร์บางประเภท (ครั้งแรกคือ Firefox และตอนนี้รวมถึง Chrome) จะบล็อกเฉพาะการแสดงผลเนื้อหาใต้ทรัพยากรการบล็อกการแสดงผลเท่านั้น ซึ่งหมายความว่าสำหรับเส้นทางการบล็อกการแสดงผลที่สำคัญ โดยทั่วไปเราสนใจทรัพยากรการบล็อกการแสดงผลใน <head> เนื่องจากทรัพยากรดังกล่าวสามารถบล็อกการแสดงผลของทั้งหน้าได้อย่างมีประสิทธิภาพ
นวัตกรรมใหม่ล่าสุดคือแอตทริบิวต์ blocking=render ที่เพิ่มลงใน Chrome 105 วิธีนี้ช่วยให้นักพัฒนาซอฟต์แวร์ทำเครื่องหมายองค์ประกอบ <link>, <script> หรือ <style> ว่าเป็นการบล็อกการแสดงผลอย่างชัดแจ้งจนกว่าจะมีการประมวลผลองค์ประกอบ แต่ยังคงอนุญาตให้โปรแกรมแยกวิเคราะห์ประมวลผลเอกสารต่อได้ในระหว่างนี้
ทรัพยากรการบล็อกโปรแกรมแยกวิเคราะห์
ทรัพยากรที่บล็อกโปรแกรมแยกวิเคราะห์คือทรัพยากรที่ป้องกันไม่ให้เบราว์เซอร์ทำงานอื่นๆ ด้วยการแยกวิเคราะห์ HTML อย่างต่อเนื่อง โดยค่าเริ่มต้น JavaScript จะบล็อกโปรแกรมแยกวิเคราะห์ (ยกเว้นจะมีการทำเครื่องหมายโดยเฉพาะเป็นอะซิงโครนัสหรือเลื่อนเวลา) เนื่องจาก JavaScript สามารถเปลี่ยน DOM หรือ CSSOM ได้เมื่อประมวลผล ดังนั้นเบราว์เซอร์จะประมวลผลทรัพยากรอื่นๆ ต่อไปไม่ได้จนกว่าจะทราบผลกระทบทั้งหมดจาก JavaScript ที่ขอใน HTML ของหน้าเว็บ JavaScript แบบซิงโครนัสจึงบล็อกโปรแกรมแยกวิเคราะห์
ทรัพยากรที่บล็อกโปรแกรมแยกวิเคราะห์ยังบล็อกการแสดงผลได้อย่างมีประสิทธิภาพด้วย เนื่องจากโปรแกรมแยกวิเคราะห์ไม่สามารถดำเนินการต่อผ่านทรัพยากรที่บล็อกการแยกวิเคราะห์ได้จนกว่าจะได้รับการประมวลผลโดยสมบูรณ์ โปรแกรมจึงเข้าถึงและแสดงผลเนื้อหาไม่ได้หลังจากนั้น เบราว์เซอร์จะแสดงผล HTML ใดก็ได้ที่ได้รับขณะที่รออยู่ แต่เมื่อพิจารณาเส้นทางการแสดงผลวิกฤติแล้ว ทรัพยากรที่บล็อกโปรแกรมแยกวิเคราะห์ใน <head> อย่างมีประสิทธิภาพหมายความว่าเนื้อหาหน้าเว็บทั้งหมดถูกบล็อกไม่ให้มีการแสดงผล
การบล็อกโปรแกรมแยกวิเคราะห์อาจสร้างค่าใช้จ่ายด้านประสิทธิภาพที่สูง ซึ่งมากกว่าการบล็อกการแสดงผลเพียงอย่างเดียว ด้วยเหตุนี้ เบราว์เซอร์จะพยายามลดค่าใช้จ่ายนี้ด้วยการใช้โปรแกรมแยกวิเคราะห์ HTML รองที่เรียกว่าตัวสแกนล่วงหน้าเพื่อดาวน์โหลดทรัพยากรที่กำลังจะเกิดขึ้นในขณะที่โปรแกรมแยกวิเคราะห์ HTML หลักถูกบล็อก แม้ว่าการแยกวิเคราะห์ HTML จะไม่ดีเท่าการแยกวิเคราะห์ HTML จริงๆ แต่อย่างน้อยก็ช่วยให้ฟังก์ชันเครือข่ายในเบราว์เซอร์ทำงานนำหน้าโปรแกรมแยกวิเคราะห์ที่ถูกบล็อกได้ ซึ่งหมายความว่ามีโอกาสน้อยลงที่จะถูกบล็อกอีกครั้งในอนาคต
การระบุทรัพยากรการบล็อก
เครื่องมือตรวจสอบประสิทธิภาพหลายอย่างระบุทรัพยากรที่บล็อกการแสดงผลและการบล็อกโปรแกรมแยกวิเคราะห์ได้ WebPageTest จะทำเครื่องหมายทรัพยากรที่บล็อกการแสดงผลด้วยวงกลมสีส้มทางด้านซ้ายของ URL ของทรัพยากร ดังนี้
ทรัพยากรที่บล็อกการแสดงผลทั้งหมดต้องมีการดาวน์โหลดและประมวลผลก่อนที่จะเริ่มแสดงผล ซึ่งสังเกตได้จากเส้นสีเขียวเข้มที่แสดงให้เห็นใน Waterfall
นอกจากนี้ Lighthouse ยังไฮไลต์ทรัพยากรที่บล็อกการแสดงผลด้วย แต่ละเอียดยิ่งขึ้นและก็ต่อเมื่อทรัพยากรดังกล่าวทำให้การแสดงผลหน้าเว็บล่าช้าเท่านั้น วิธีนี้ช่วยหลีกเลี่ยงข้อสันนิษฐานที่ผิดพลาดที่ช่วยลดการบล็อกการแสดงผลได้ การเรียกใช้ URL ของหน้าเดียวกันกับตัวเลข WebPageTest ก่อนหน้านี้ผ่าน Lighthouse จะระบุเฉพาะสไตล์ชีตรายการหนึ่งเป็นทรัพยากรที่บล็อกการแสดงผล
การเพิ่มประสิทธิภาพเส้นทางการแสดงผลวิกฤติ
การเพิ่มประสิทธิภาพเส้นทางการแสดงผลวิกฤตินั้นจะช่วยลดเวลาในการรับ HTML (แทนด้วยเมตริกเวลาเป็นไบต์แรก (TTFB)) ตามที่อธิบายไว้ในโมดูลก่อนหน้า และลดผลกระทบของทรัพยากรที่บล็อกการแสดงผล เราจะตรวจสอบแนวคิดเหล่านี้ในโมดูลถัดไป
เส้นทางการแสดงผลเนื้อหาวิกฤติ
เส้นทางการแสดงผลวิกฤติให้ความสำคัญกับการแสดงผลเริ่มต้นมาเป็นเวลานาน อย่างไรก็ตาม เกิดเมตริกที่มุ่งเน้นผู้ใช้มากขึ้นสำหรับประสิทธิภาพของเว็บ ซึ่งมีข้อสงสัยว่าจุดสิ้นสุดของเส้นทางการแสดงผลวิกฤติควรเป็นการแสดงผลครั้งแรกมากหรือสีที่มีเนื้อหามากกว่า ซึ่งจะตามมาหลังจากนั้น
อีกมุมมองหนึ่งคือการให้ความสำคัญกับเวลาจนกว่าจะเป็น Largest Contentful Paint (LCP) หรือแม้กระทั่ง First Contentful Paint (FCP) เพื่อเป็นส่วนหนึ่งของเส้นทางการแสดงผลแบบคอนเทนต์ (หรือเส้นทางคีย์อย่างที่ผู้อื่นอาจเรียกว่า) ในกรณีนี้ คุณอาจต้องรวมทรัพยากรที่ไม่จำเป็นต้องมีการบล็อก ดังที่เป็นคำจำกัดความทั่วไปของเส้นทางการแสดงผลวิกฤติ แต่จำเป็นต้องใช้ในการแสดงผล Contentful Paint
ไม่ว่าคุณจะให้คำจำกัดความคำว่า "สำคัญ" ว่าอะไร การทำความเข้าใจถึงปัจจัยที่ทำให้การแสดงผลเริ่มต้นและเนื้อหาหลักเป็นสิ่งที่สำคัญ โดย First Paint จะวัดโอกาสแรกที่เป็นไปได้ในการแสดงผลทุกอย่างสำหรับผู้ใช้ ตามหลักการแล้ว รูปภาพนั้นควรสื่อความหมาย ไม่ เช่น สีพื้นหลัง แต่ถึงแม้ว่าจะไม่ใช่เนื้อหาสาระ แต่ก็ยังควรนำเสนอบางอย่างแก่ผู้ใช้ ซึ่งเป็นอาร์กิวเมนต์สำหรับวัดผลเส้นทางการแสดงผลวิกฤติตามที่กำหนดไว้แต่เดิม ในขณะเดียวกัน ก็ยังมีคุณค่าในการวัดผลเมื่อมีการนำเสนอเนื้อหาหลักต่อผู้ใช้
การระบุเส้นทางการแสดงผลที่มีเนื้อหาเต็ม
เครื่องมือจำนวนมากสามารถระบุองค์ประกอบ LCP และเวลาที่แสดงผล นอกเหนือจากองค์ประกอบ LCP แล้ว Lighthouse ยังช่วยระบุระยะ LCP และเวลาที่ใช้ในแต่ละระยะ เพื่อช่วยให้คุณทราบว่าควรเน้นเพิ่มประสิทธิภาพในจุดใด
สำหรับเว็บไซต์ที่มีความซับซ้อนมากขึ้น Lighthouse ยังไฮไลต์เชนคำขอที่สำคัญในการตรวจสอบที่แยกต่างหากดังต่อไปนี้
การตรวจสอบ Lighthouse นี้จะสังเกตทรัพยากรทั้งหมดที่โหลดด้วยลำดับความสำคัญสูง ดังนั้นจึงมีแบบอักษรเว็บและเนื้อหาอื่นๆ ที่ Chrome กำหนดเป็นทรัพยากรลำดับความสำคัญสูง แม้ว่าจริงๆ แล้วทรัพยากรจะไม่ได้บล็อกการแสดงผลก็ตาม
ทดสอบความรู้ของคุณ
เส้นทางการแสดงผลวิกฤติหมายถึงอะไร
มีทรัพยากรใดบ้างที่เกี่ยวข้องในเส้นทางการแสดงผลวิกฤติ
<head><head>เหตุใดการบล็อกการแสดงผลจึงเป็นส่วนที่จำเป็นในการแสดงผลหน้าเว็บ
เหตุใด JavaScript ถึงบล็อกโปรแกรมแยกวิเคราะห์ HTML (สมมติว่าไม่ได้ระบุแอตทริบิวต์ defer, async หรือ module ในองค์ประกอบ <script>)
<script> จะเป็นการบล็อกโปรแกรมแยกวิเคราะห์และการบล็อกการแสดงผลถัดไป: เพิ่มประสิทธิภาพการโหลดทรัพยากร
โมดูลนี้กล่าวถึงทฤษฎีบางประการที่อยู่เบื้องหลังวิธีที่เบราว์เซอร์แสดงผลหน้าเว็บ โดยเฉพาะสิ่งที่จำเป็นในการแสดงผลครั้งแรกของหน้าเว็บให้เสร็จสมบูรณ์ โมดูลถัดไปดูวิธีเพิ่มประสิทธิภาพเส้นทางการแสดงผลนี้โดยดูวิธีเพิ่มประสิทธิภาพการโหลดทรัพยากร