การทำความเข้าใจเส้นทางวิกฤติ

เส้นทางการแสดงผลวิกฤติคือขั้นตอนที่เกี่ยวข้องจนกว่าหน้าเว็บจะเริ่มแสดงผลในเบราว์เซอร์ ในการแสดงผลหน้าเว็บ เบราว์เซอร์จำเป็นต้องมีเอกสาร 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 ของเครือข่ายที่สร้างโดย WebPageTest ทรัพยากรที่บล็อกโปรแกรมแยกวิเคราะห์จะสังเกตเป็นวงกลมสีส้มทางด้านซ้ายของ URL ของทรัพยากร และเวลาเริ่มต้นในการแสดงผลจะระบุด้วยเส้นทึบสีเขียวเข้ม

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

นอกจากนี้ Lighthouse ยังไฮไลต์ทรัพยากรที่บล็อกการแสดงผลด้วย แต่ละเอียดยิ่งขึ้นและก็ต่อเมื่อทรัพยากรดังกล่าวทำให้การแสดงผลหน้าเว็บล่าช้าเท่านั้น วิธีนี้ช่วยหลีกเลี่ยงข้อสันนิษฐานที่ผิดพลาดที่ช่วยลดการบล็อกการแสดงผลได้ การเรียกใช้ URL ของหน้าเดียวกันกับตัวเลข WebPageTest ก่อนหน้านี้ผ่าน Lighthouse จะระบุเฉพาะสไตล์ชีตรายการหนึ่งเป็นทรัพยากรที่บล็อกการแสดงผล

ภาพหน้าจอของการตรวจสอบของ Lighthouse สำหรับการกำจัดทรัพยากรที่บล็อกการแสดงผล การตรวจสอบจะแสดงทรัพยากรที่บล็อกการแสดงผลและระยะเวลาที่บล็อกการแสดงผล

การเพิ่มประสิทธิภาพเส้นทางการแสดงผลวิกฤติ

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

เส้นทางการแสดงผลเนื้อหาวิกฤติ

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

อีกมุมมองหนึ่งคือการให้ความสำคัญกับเวลาจนกว่าจะเป็น Largest Contentful Paint (LCP) หรือแม้กระทั่ง First Contentful Paint (FCP) เพื่อเป็นส่วนหนึ่งของเส้นทางการแสดงผลแบบคอนเทนต์ (หรือเส้นทางคีย์อย่างที่ผู้อื่นอาจเรียกว่า) ในกรณีนี้ คุณอาจต้องรวมทรัพยากรที่ไม่จำเป็นต้องมีการบล็อก ดังที่เป็นคำจำกัดความทั่วไปของเส้นทางการแสดงผลวิกฤติ แต่จำเป็นต้องใช้ในการแสดงผล Contentful Paint

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

การระบุเส้นทางการแสดงผลที่มีเนื้อหาเต็ม

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

ภาพหน้าจอของการตรวจสอบ LCP ของ Lighthouse ซึ่งแสดงองค์ประกอบ LCP ของหน้าเว็บและระยะเวลาที่ใช้งานในหลายๆ ระยะ เช่น TTFB, ความล่าช้าในการโหลด, เวลาที่ใช้ในการโหลด และความล่าช้าในการแสดงผล

สำหรับเว็บไซต์ที่มีความซับซ้อนมากขึ้น Lighthouse ยังไฮไลต์เชนคำขอที่สำคัญในการตรวจสอบที่แยกต่างหากดังต่อไปนี้

ภาพหน้าจอของแผนภาพเชนคำขอที่สำคัญของ Lighthouse ซึ่งแสดงให้เห็นทรัพยากรที่สำคัญซึ่งฝังอยู่ใต้ทรัพยากรที่สำคัญอื่นๆ รวมถึงเวลาในการตอบสนองทั้งหมดที่เกี่ยวข้องในเชนคำขอสำคัญ

การตรวจสอบ Lighthouse นี้จะสังเกตทรัพยากรทั้งหมดที่โหลดด้วยลำดับความสำคัญสูง ดังนั้นจึงมีแบบอักษรเว็บและเนื้อหาอื่นๆ ที่ Chrome กำหนดเป็นทรัพยากรลำดับความสำคัญสูง แม้ว่าจริงๆ แล้วทรัพยากรจะไม่ได้บล็อกการแสดงผลก็ตาม

ทดสอบความรู้ของคุณ

เส้นทางการแสดงผลวิกฤติหมายถึงอะไร

จำนวนทรัพยากรขั้นต่ำที่จำเป็นในการแสดงผลหน้าเริ่มต้น
จำนวนทรัพยากรขั้นต่ำที่จำเป็นในการแสดงผลหน้าเว็บอย่างสมบูรณ์

มีทรัพยากรใดบ้างที่เกี่ยวข้องในเส้นทางการแสดงผลวิกฤติ

การแสดงผล CSS ที่บล็อกการแสดงผลในองค์ประกอบ <head>
JavaScript ที่บล็อกการแสดงผลในองค์ประกอบ <head>
ส่วนของ HTML

เหตุใดการบล็อกการแสดงผลจึงเป็นส่วนที่จำเป็นในการแสดงผลหน้าเว็บ

เพื่อป้องกันไม่ให้หน้าเว็บแสดงผลในตอนแรกอยู่ในสถานะใช้งานไม่ได้หรือดูเหมือนใช้งานไม่ได้
เพื่อป้องกันไม่ให้ผู้ใช้มองเห็นหน้าเว็บจนกว่าจะแสดงผลเสร็จสมบูรณ์

เหตุใด JavaScript ถึงบล็อกโปรแกรมแยกวิเคราะห์ HTML (สมมติว่าไม่ได้ระบุแอตทริบิวต์ defer, async หรือ module ในองค์ประกอบ <script>)

หากไม่มีแอตทริบิวต์ดังกล่าวอย่างน้อย 1 รายการ <script> จะเป็นการบล็อกโปรแกรมแยกวิเคราะห์และการบล็อกการแสดงผล
JavaScript ทั้งหมดบล็อกโปรแกรมแยกวิเคราะห์อยู่โดยไม่คำนึงถึงแอตทริบิวต์เหล่านั้น
ต้องเรียกใช้ JavaScript แบบพร้อมกันเมื่อโปรแกรมแยกวิเคราะห์เข้าถึง JavaScript เนื่องจากอาจทำให้ DOM เปลี่ยนแปลง

ถัดไป: เพิ่มประสิทธิภาพการโหลดทรัพยากร

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