การวิเคราะห์ประสิทธิภาพของเส้นทางการแสดงผลที่สำคัญ

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

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

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

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

  • การส่งข้อมูลไป-กลับของเครือข่าย (เวลาในการตอบสนองของการนำไปใช้งาน) ไปยังเซิร์ฟเวอร์จะมีค่าใช้จ่าย 100 มิลลิวินาที
  • เวลาในการตอบกลับของเซิร์ฟเวอร์คือ 100 มิลลิวินาทีสำหรับเอกสาร HTML และ 10 มิลลิวินาทีสำหรับไฟล์อื่นๆ ทั้งหมด

ประสบการณ์สวัสดีชาวโลก

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

ลองใช้

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

CRP

ดังที่คาดไว้ ไฟล์ HTML ใช้เวลาดาวน์โหลดประมาณ 200 มิลลิวินาที โปรดทราบว่าส่วนที่โปร่งใสของเส้นสีน้ำเงินแสดงถึงระยะเวลาที่เบราว์เซอร์รอบนเครือข่ายโดยไม่รับข้อมูลไบต์ตอบกลับ ในขณะที่ส่วนที่ทึบจะแสดงเวลาในการดาวน์โหลดให้เสร็จสิ้นหลังจากได้รับไบต์การตอบสนองแรกแล้ว การดาวน์โหลด HTML นั้นมีขนาดเล็ก (<4K) ดังนั้นเราจึงต้องการแค่การส่งไฟล์ไป-กลับในการเรียกไฟล์ฉบับเต็ม ดังนั้น เอกสาร HTML จะใช้เวลาประมาณ 200 มิลลิวินาทีในการดึงข้อมูล โดยใช้เวลาครึ่งหนึ่งของการรอบนเครือข่ายและอีกครึ่งหนึ่งรอการตอบกลับของเซิร์ฟเวอร์

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

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

อย่างไรก็ตาม เหตุการณ์ load (หรือที่เรียกว่า onload) ถูกบล็อกในรูปภาพ: เครื่องมือสำหรับนักพัฒนาเว็บจะรายงานเหตุการณ์ onload ที่ 335 มิลลิวินาที โปรดทราบว่าเหตุการณ์ onload จะทำเครื่องหมายจุดที่มีการดาวน์โหลดและประมวลผลทรัพยากรทั้งหมดในหน้าดังกล่าว ซึ่ง ณ จุดนี้ ไอคอนหมุนแสดงการโหลดจะหยุดหมุนในเบราว์เซอร์ (เส้นแนวตั้งสีแดงใน Waterfall)

การเพิ่ม JavaScript และ CSS ลงในการผสม

หน้า "ประสบการณ์ Hello World" ของเราดูเรียบง่าย แต่มีสิ่งต่างๆ มากมายรออยู่ ในเชิงปฏิบัติ เราต้องการมากกว่าแค่ HTML นั่นคือ เราจะมีสไตล์ชีต CSS และสคริปต์อย่างน้อย 1 สคริปต์เพื่อเพิ่มการโต้ตอบในหน้าเว็บของเรา มาลองเพิ่มทั้ง 2 แบบลงในการผสมผสานกันและดูว่าจะเกิดอะไรขึ้น

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Script</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="timing.js"></script>
  </body>
</html>

ลองใช้

ก่อนเพิ่ม JavaScript และ CSS

CRP สำหรับ DOM

เมื่อใช้ JavaScript และ CSS

DOM, CSSOM, JS

การเพิ่มไฟล์ CSS และ JavaScript ภายนอกเป็นการเพิ่มคำขอ 2 รายการไปยัง Waterfall ซึ่งเบราว์เซอร์จะส่งไปในเวลาเดียวกัน อย่างไรก็ตาม โปรดทราบว่าตอนนี้เหตุการณ์ domContentLoaded กับ onload มีความแตกต่างในเวลาน้อยกว่ามาก

เกิดอะไรขึ้น

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

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

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

JavaScript ภายนอก

DOM, CSSOM, JS

JavaScript ในบรรทัด:

DOM, CSSOM และ JS ในบรรทัด

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

ก่อนอื่น อย่าลืมว่าสคริปต์ในบรรทัดทั้งหมดเป็นการบล็อกโปรแกรมแยกวิเคราะห์ แต่สำหรับสคริปต์ภายนอก เราสามารถเพิ่มคีย์เวิร์ด "ไม่พร้อมกัน" เพื่อเลิกบล็อกโปรแกรมแยกวิเคราะห์ได้ มาเลิกทำอินไลน์ของเราและลองทำกัน

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Async</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script async src="timing.js"></script>
  </body>
</html>

ลองใช้

JavaScript การบล็อกโปรแกรมแยกวิเคราะห์ (ภายนอก)

DOM, CSSOM, JS

JavaScript (ภายนอก) แบบไม่พร้อมกัน:

DOM, CSSOM, JS ที่ไม่พร้อมกัน

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

อีกทางเลือกหนึ่งคือ เราอาจใช้ทั้ง CSS และ JavaScript ดังนี้

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Inlined</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <style>
      p {
        font-weight: bold;
      }
      span {
        color: red;
      }
      p span {
        display: none;
      }
      img {
        float: right;
      }
    </style>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script>
      var span = document.getElementsByTagName('span')[0];
      span.textContent = 'interactive'; // change DOM text content
      span.style.display = 'inline'; // change CSSOM property
      // create a new element, style it, and append it to the DOM
      var loadTime = document.createElement('div');
      loadTime.textContent = 'You loaded this page on: ' + new Date();
      loadTime.style.color = 'blue';
      document.body.appendChild(loadTime);
    </script>
  </body>
</html>

ลองใช้

DOM, CSS ในบรรทัด, JS ในบรรทัด

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

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

เรามาลองย้อนกลับไปดูรูปแบบประสิทธิภาพทั่วไปกัน

รูปแบบประสิทธิภาพ

หน้าที่ง่ายที่สุดเท่าที่จะเป็นไปได้ประกอบด้วยมาร์กอัป HTML เท่านั้น ไม่มี CSS, ไม่มี JavaScript หรือทรัพยากรประเภทอื่นๆ หากต้องการแสดงผลหน้านี้ เบราว์เซอร์ต้องเริ่มต้นคำขอ ให้รอจนกว่าเอกสาร HTML จะมาถึง แยกวิเคราะห์เอกสาร สร้าง DOM จากนั้นแสดงผลบนหน้าจอในท้ายที่สุด:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

ลองใช้

CRP สำหรับ Hello World

เวลาระหว่าง T0 ถึง T1 จะบันทึกเวลาในการประมวลผลของเครือข่ายและเซิร์ฟเวอร์ ในกรณีที่ดีที่สุด (หากไฟล์ HTML มีขนาดเล็ก) มีเพียงเครือข่ายเดียวที่จะดึงข้อมูลเอกสารทั้งหมด โปรโตคอลการรับส่ง TCP ทำงาน ไฟล์ที่มีขนาดใหญ่อาจต้องใช้การส่งข้อมูลไปกลับมากขึ้น ดังนั้น ในกรณีที่ดีที่สุด หน้าข้างต้นจะมีเส้นทางการแสดงผลวิกฤติแบบไป-กลับ (ขั้นต่ำ) 1 เส้นทาง

ตอนนี้ ลองพิจารณาหน้าเว็บเดียวกัน แต่ใช้ไฟล์ CSS ภายนอก

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

ลองใช้

DOM + CSSOM CRP

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

มาดูคำศัพท์ที่เราใช้อธิบายเส้นทางการแสดงผลวิกฤติกัน

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

ทีนี้ลองมาเปรียบเทียบกับลักษณะเส้นทางวิกฤติของตัวอย่าง HTML + CSS ข้างต้น

DOM + CSSOM CRP

  • ทรัพยากรสำคัญ 2 รายการ
  • 2 รอบขึ้นไปสำหรับความยาวเส้นทางวิกฤติขั้นต่ำ
  • ไบต์วิกฤต 9 KB

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

คราวนี้ลองเพิ่มไฟล์ JavaScript อีก 1 ไฟล์ลงในการผสม

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js"></script>
  </body>
</html>

ลองใช้

เราได้เพิ่ม app.js ซึ่งเป็นทั้งเนื้อหา JavaScript ภายนอกในหน้าเว็บและทรัพยากรการบล็อกโปรแกรมแยกวิเคราะห์ (สำคัญ) แต่ที่แย่กว่านั้นคือ เราต้องบล็อกและรอ CSSOM เพื่อเรียกใช้ไฟล์ JavaScript เนื่องจาก JavaScript สามารถสืบค้น CSSOM ได้ เบราว์เซอร์จึงหยุดชั่วคราวจนกว่าจะดาวน์โหลด style.css และสร้าง CSSOM ขึ้น

DOM, CSSOM, JavaScript CRP

แต่ในทางปฏิบัติ หากเราดูที่ "Waterfall เครือข่าย" ของหน้านี้ คุณจะเห็นว่าทั้งคำขอ CSS และ JavaScript เริ่มต้นในเวลาเดียวกัน เบราว์เซอร์จะได้รับ HTML, ค้นพบทรัพยากรทั้งสอง และเริ่มต้นคำขอทั้งสอง ด้วยเหตุนี้ หน้าข้างต้นจึงมีลักษณะเส้นทางวิกฤตดังนี้

  • ทรัพยากรสำคัญ 3 รายการ
  • 2 รอบขึ้นไปสำหรับความยาวเส้นทางวิกฤติขั้นต่ำ
  • 11 KB ของไบต์วิกฤติ

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

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

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

ลองใช้

DOM, CSSOM, CRP ของ JavaScript ที่ไม่พร้อมกัน

สคริปต์แบบไม่พร้อมกันมีข้อดีหลายประการดังนี้

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

ทำให้ตอนนี้หน้าเว็บที่เพิ่มประสิทธิภาพของเรากลับมาแสดงทรัพยากรที่สำคัญ 2 รายการ (HTML และ CSS) โดยมีความยาวเส้นทางวิกฤติขั้นต่ำที่ 2 รอบ และรวมไบต์วิกฤติขนาด 9 KB

สุดท้าย หากสไตล์ชีต CSS จำเป็นสำหรับการพิมพ์เท่านั้น จะเป็นอย่างไร

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" media="print" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

ลองใช้

DOM, CSS ที่ไม่บล็อก และ CRP JavaScript แบบไม่พร้อมกัน

เนื่องจากทรัพยากร style.css ใช้สำหรับการพิมพ์เท่านั้น เบราว์เซอร์ไม่จำเป็นต้องบล็อกทรัพยากรดังกล่าวเพื่อแสดงผลหน้าเว็บ ดังนั้น เมื่อการสร้าง DOM เสร็จสมบูรณ์ เบราว์เซอร์จะมีข้อมูลเพียงพอที่จะแสดงผลหน้าเว็บ ดังนั้นหน้านี้จึงมีทรัพยากรวิกฤติเพียงที่เดียว (เอกสาร HTML) และความยาวเส้นทางการแสดงผลวิกฤติขั้นต่ำคือ 1 รอบ

ความคิดเห็น