تجزیه و تحلیل عملکرد مسیر رندر بحرانی

ایلیا گریگوریک

تاریخ انتشار: 31 مارس 2014

شناسایی و رفع تنگناهای عملکرد مسیر رندر حیاتی مستلزم دانش خوب از مشکلات رایج است. یک تور راهنما برای شناسایی الگوهای عملکرد رایج به شما کمک می کند تا صفحات خود را بهینه کنید.

بهینه‌سازی مسیر رندر حیاتی به مرورگر اجازه می‌دهد تا صفحه را در سریع‌ترین زمان ممکن نقاشی کند: صفحات سریع‌تر به تعامل بالاتر، صفحات بیشتر مشاهده شده و تبدیل بهبود یافته تبدیل می‌شوند. برای به حداقل رساندن مدت زمانی که یک بازدیدکننده صرف مشاهده یک صفحه خالی می کند، باید بهینه سازی کنیم که کدام منابع و به ترتیب بارگذاری می شوند.

برای کمک به تشریح این فرآیند، با ساده‌ترین حالت ممکن شروع کنید و صفحه ما را به صورت تدریجی بسازید تا منابع، سبک‌ها و منطق برنامه‌های کاربردی اضافی را شامل شود. در این فرآیند، ما هر مورد را بهینه خواهیم کرد. ما همچنین خواهیم دید که در کجا ممکن است همه چیز خراب شود.

تا کنون ما به طور انحصاری روی آنچه در مرورگر پس از در دسترس قرار گرفتن منبع (فایل CSS، JS یا HTML) برای پردازش اتفاق می‌افتد، تمرکز کرده‌ایم. ما زمان لازم برای واکشی منبع از حافظه پنهان یا از شبکه را نادیده گرفته ایم. موارد زیر را فرض می کنیم:

  • یک رفت و برگشت شبکه (تاخیر انتشار) به سرور 100 میلی ثانیه هزینه دارد.
  • زمان پاسخگویی سرور برای سند HTML 100 میلی‌ثانیه و برای همه فایل‌های دیگر 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 یا جاوا اسکریپت. سپس، پانل شبکه را در Chrome DevTools باز کنید و آبشار منبع حاصل را بررسی کنید:

CRP

همانطور که انتظار می رفت، دانلود فایل HTML تقریباً 200 میلی ثانیه طول کشید. توجه داشته باشید که قسمت شفاف خط آبی نشان دهنده مدت زمانی است که مرورگر بدون دریافت هیچ بایت پاسخی در شبکه منتظر می ماند در حالی که بخش جامد زمان پایان دانلود را پس از دریافت اولین بایت پاسخ نشان می دهد. دانلود HTML بسیار کوچک است (<4K)، بنابراین تنها چیزی که ما نیاز داریم یک رفت و برگشت برای واکشی فایل کامل است. در نتیجه، واکشی سند HTML تقریباً 200 میلی‌ثانیه طول می‌کشد که نیمی از زمان انتظار در شبکه و نیمی دیگر در انتظار پاسخ سرور است.

هنگامی که محتوای HTML در دسترس می شود، مرورگر بایت ها را تجزیه می کند، آنها را به توکن تبدیل می کند و درخت DOM را می سازد. توجه داشته باشید که DevTools به راحتی زمان رویداد DOMContentLoaded را در پایین (216 میلی‌ثانیه) گزارش می‌کند که با خط عمودی آبی نیز مطابقت دارد. فاصله بین پایان دانلود HTML و خط عمودی آبی (DOMContentLoaded) زمانی است که مرورگر برای ساختن درخت DOM طول می‌کشد — در این مورد، فقط چند میلی ثانیه.

توجه داشته باشید که "عکس عالی" ما رویداد domContentLoaded را مسدود نکرد. به نظر می رسد، ما می توانیم درخت رندر را بسازیم و حتی صفحه را بدون منتظر ماندن برای هر دارایی در صفحه نقاشی کنیم: همه منابع برای ارائه اولین رنگ سریع حیاتی نیستند . در واقع، وقتی در مورد مسیر رندر بحرانی صحبت می کنیم، معمولاً در مورد نشانه گذاری HTML، CSS و جاوا اسکریپت صحبت می کنیم. تصاویر رندر اولیه صفحه را مسدود نمی‌کنند - اگرچه ما باید سعی کنیم تصاویر را در اسرع وقت نقاشی کنیم.

گفته شد، رویداد load (همچنین به عنوان onload شناخته می‌شود)، روی تصویر مسدود شده است: DevTools رویداد onload را با سرعت 335 میلی‌ثانیه گزارش می‌کند. به یاد داشته باشید که رویداد onload نقطه ای را مشخص می کند که در آن تمام منابع مورد نیاز صفحه دانلود و پردازش شده اند. در این مرحله، اسپینر بارگیری می تواند چرخش را در مرورگر متوقف کند (خط عمودی قرمز در آبشار).

افزودن جاوا اسکریپت و CSS به ترکیب

صفحه "تجربه سلام جهان" ما ابتدایی به نظر می رسد، اما چیزهای زیادی در زیر سرپوش وجود دارد. در عمل ما به چیزی بیش از HTML نیاز خواهیم داشت: به احتمال زیاد، یک شیوه نامه CSS و یک یا چند اسکریپت برای افزودن مقداری تعامل به صفحه خود خواهیم داشت. هر دو را به مخلوط اضافه کنید تا ببینید چه اتفاقی می افتد:

<!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>

آن را امتحان کنید

قبل از افزودن جاوا اسکریپت و CSS:

DOM CRP

با جاوا اسکریپت و CSS:

DOM، CSSOM، JS

افزودن فایل‌های CSS و جاوا اسکریپت خارجی دو درخواست اضافی را به آبشار ما اضافه می‌کند که مرورگر همه آنها را تقریباً همزمان ارسال می‌کند. با این حال، توجه داشته باشید که اکنون تفاوت زمانی بسیار کمتری بین رویدادهای domContentLoaded و onload وجود دارد.

چه اتفاقی افتاد؟

  • برخلاف مثال ساده HTML ما، ما همچنین باید فایل CSS را برای ساختن CSSOM واکشی و تجزیه کنیم، و برای ساختن درخت رندر به هر دو DOM و CSSOM نیاز داریم.
  • از آنجایی که صفحه حاوی یک تجزیه کننده فایل جاوا اسکریپت مسدود کننده است، رویداد domContentLoaded تا زمانی که فایل CSS دانلود و تجزیه نشود مسدود می شود: چون جاوا اسکریپت ممکن است CSSOM را پرس و جو کند، ما باید فایل CSS را تا زمانی که دانلود شود مسدود کنیم تا بتوانیم جاوا اسکریپت را اجرا کنیم.

اگر اسکریپت خارجی خود را با یک اسکریپت درون خطی جایگزین کنیم چه؟ حتی اگر اسکریپت مستقیماً داخل صفحه باشد، مرورگر نمی‌تواند آن را تا زمانی که CSSOM ساخته شود اجرا کند. به طور خلاصه، جاوا اسکریپت درون خطی نیز مسدودکننده تجزیه کننده است.

گفتنی است، با وجود مسدود شدن در CSS، آیا درون‌خط‌سازی اسکریپت باعث می‌شود صفحه سریع‌تر رندر شود؟ آن را امتحان کنید و ببینید چه اتفاقی می افتد.

جاوا اسکریپت خارجی:

DOM، CSSOM، JS

جاوا اسکریپت درون خطی:

DOM، CSSOM، و JS داخلی

ما یک درخواست کمتر ارائه می کنیم، اما هر دو زمان onload و domContentLoaded ما عملاً یکسان هستند. چرا؟ خوب، ما می دانیم که مهم نیست جاوا اسکریپت درون خطی یا خارجی باشد، زیرا به محض اینکه مرورگر تگ اسکریپت را زد، آن را مسدود می کند و منتظر می ماند تا CSSOM ساخته شود. علاوه بر این، در مثال اول ما، مرورگر هر دو CSS و جاوا اسکریپت را به صورت موازی دانلود می‌کند و تقریباً همزمان دانلود می‌شوند. در این مثال، داخل کردن کد جاوا اسکریپت کمک زیادی به ما نمی کند. اما چندین استراتژی وجود دارد که می تواند صفحه ما را سریعتر رندر کند.

ابتدا به یاد بیاورید که همه اسکریپت های درون خطی مسدود کننده تجزیه کننده هستند، اما برای اسکریپت های خارجی می توانیم ویژگی async را برای رفع انسداد تجزیه کننده اضافه کنیم. inlining ما را لغو کنید و آن را امتحان کنید:

<!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>

آن را امتحان کنید

جاوا اسکریپت مسدودکننده تجزیه کننده (خارجی):

DOM، CSSOM، JS

جاوا اسکریپت غیرهمگام (خارجی):

DOM، CSSOM، JS غیر همگام

خیلی بهتر! رویداد domContentLoaded مدت کوتاهی پس از تجزیه HTML فعال می شود. مرورگر می داند که در جاوا اسکریپت مسدود نمی شود و از آنجایی که هیچ اسکریپت مسدودکننده تجزیه کننده دیگری وجود ندارد، ساخت CSSOM نیز می تواند به صورت موازی ادامه یابد.

از طرف دیگر، ما می‌توانستیم هم CSS و هم جاوا اسکریپت را درون خطی کنیم:

<!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 را در خود صفحه قرار داده‌ایم. این باعث می‌شود صفحه HTML ما بسیار بزرگ‌تر شود، اما نکته مثبت این است که مرورگر برای دریافت منابع خارجی نیازی به صبر ندارد. همه چیز همانجا در صفحه است.

همانطور که می بینید، حتی با یک صفحه بسیار ابتدایی، بهینه سازی مسیر رندر بحرانی یک تمرین غیر ضروری است: ما باید نمودار وابستگی بین منابع مختلف را درک کنیم، باید شناسایی کنیم که کدام منابع "بحرانی" هستند و باید انتخاب کنیم. در میان استراتژی های مختلف برای نحوه گنجاندن آن منابع در صفحه. هیچ راه حلی برای این مشکل وجود ندارد. هر صفحه متفاوت است برای تعیین استراتژی بهینه باید فرآیند مشابهی را به تنهایی دنبال کنید.

با این اوصاف، ببینید آیا می‌توانیم به عقب برگردیم و برخی از الگوهای عملکرد کلی را شناسایی کنیم.

الگوهای عملکرد

ساده ترین صفحه ممکن فقط از نشانه گذاری HTML تشکیل شده است. بدون CSS، بدون جاوا اسکریپت یا انواع دیگر منابع. برای رندر کردن این صفحه، مرورگر باید درخواست را آغاز کند، صبر کند تا سند 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

زمان بین T 0 و T 1 زمان پردازش شبکه و سرور را ثبت می کند. در بهترین حالت (اگر فایل HTML کوچک باشد)، فقط یک بار رفت و برگشت شبکه کل سند را واکشی می کند. با توجه به نحوه کار پروتکل های انتقال TCP، فایل های بزرگتر ممکن است به رفت و برگشت بیشتری نیاز داشته باشند. در نتیجه، در بهترین حالت صفحه فوق دارای یک مسیر رفت و برگشت (حداقل) مسیر رندر بحرانی است.

اکنون همان صفحه را در نظر بگیرید، اما با یک فایل 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 را دریافت کند. در نتیجه، این صفحه قبل از نمایش حداقل دو بار رفت و برگشت انجام می شود. یک بار دیگر، فایل CSS ممکن است چندین بار رفت و برگشت داشته باشد، از این رو بر روی "حداقل" تاکید می شود.

در اینجا اصطلاحاتی وجود دارد که برای توصیف مسیر رندر بحرانی استفاده می کنیم:

  • منبع بحرانی: منبعی که می تواند رندر اولیه صفحه را مسدود کند.
  • طول مسیر بحرانی: تعداد سفرهای رفت و برگشت یا کل زمان لازم برای واکشی همه منابع حیاتی.
  • بایت های بحرانی: تعداد کل بایت های مورد نیاز برای رسیدن به اولین رندر صفحه، که مجموع حجم فایل های انتقالی همه منابع حیاتی است. اولین مثال ما، با یک صفحه HTML، حاوی یک منبع حیاتی واحد (سند HTML) بود. طول مسیر بحرانی نیز برابر با یک رفت و برگشت شبکه بود (با فرض کوچک بودن فایل)، و کل بایت های بحرانی فقط اندازه انتقال خود سند HTML بود.

اکنون آن را با ویژگی های مسیر بحرانی مثال قبلی HTML و CSS مقایسه کنید:

DOM + CSSOM CRP

  • 2 منابع حیاتی
  • 2 یا بیشتر رفت و برگشت برای حداقل طول مسیر بحرانی
  • 9 کیلوبایت بایت بحرانی

برای ساختن درخت رندر به هر دو HTML و CSS نیاز داریم. در نتیجه، هر دو HTML و CSS منابع حیاتی هستند: CSS تنها پس از دریافت سند HTML توسط مرورگر واکشی می شود، بنابراین طول مسیر بحرانی حداقل دو رفت و برگشت است. هر دو منبع در مجموع به 9 کیلوبایت بایت بحرانی می‌رسند.

اکنون یک فایل جاوا اسکریپت اضافی را به ترکیب اضافه کنید.

<!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 اضافه کردیم که هم یک دارایی جاوا اسکریپت خارجی در صفحه و هم یک منبع مسدودکننده تجزیه کننده (یعنی حیاتی) است. بدتر از آن، برای اجرای فایل جاوا اسکریپت باید مسدود کنیم و منتظر CSSOM باشیم. به یاد بیاورید که جاوا اسکریپت می تواند CSSOM را پرس و جو کند و از این رو مرورگر مکث می کند تا style.css دانلود شود و CSSOM ساخته شود.

DOM، CSSOM، JavaScript CRP

در عمل، اگر به "شبکه آبشار" این صفحه نگاه کنیم، خواهید دید که هر دو درخواست CSS و جاوا اسکریپت تقریباً در یک زمان آغاز می شوند. مرورگر HTML را دریافت می کند، هر دو منبع را کشف می کند و هر دو درخواست را آغاز می کند. در نتیجه، صفحه نشان داده شده در تصویر قبلی دارای مشخصات مسیر حیاتی زیر است:

  • 3 منابع حیاتی
  • 2 یا بیشتر رفت و برگشت برای حداقل طول مسیر بحرانی
  • 11 کیلوبایت بایت بحرانی

ما اکنون سه منبع حیاتی داریم که تا 11 کیلوبایت بایت بحرانی اضافه می کنند، اما طول مسیر بحرانی ما هنوز دو رفت و برگشت است زیرا می توانیم CSS و جاوا اسکریپت را به صورت موازی انتقال دهیم. مشخص کردن ویژگی‌های مسیر رندر بحرانی شما به این معنی است که می‌توانید منابع حیاتی را شناسایی کنید و همچنین درک کنید که مرورگر چگونه واکشی آنها را زمان‌بندی می‌کند.

پس از گپ زدن با توسعه دهندگان سایت، متوجه می شویم که جاوا اسکریپتی که در صفحه خود قرار داده ایم نیازی به مسدود شدن ندارد. ما مقداری تجزیه و تحلیل و کدهای دیگر در آنجا داریم که نیازی به مسدود کردن رندر صفحه ما ندارد. با این دانش، می‌توانیم ویژگی async را به عنصر <script> برای رفع انسداد تجزیه‌کننده اضافه کنیم:

<!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 ناهمگام جاوا اسکریپت

یک اسکریپت ناهمزمان چندین مزیت دارد:

  • اسکریپت دیگر مسدود کننده تجزیه کننده نیست و بخشی از مسیر رندر حیاتی نیست.
  • از آنجا که هیچ اسکریپت مهم دیگری وجود ندارد، CSS نیازی به مسدود کردن رویداد domContentLoaded ندارد.
  • هر چه زودتر رویداد domContentLoaded فعال شود، منطق برنامه دیگر زودتر شروع به اجرا می کند.

در نتیجه، صفحه بهینه شده ما اکنون به دو منبع حیاتی (HTML و CSS) با حداقل طول مسیر بحرانی دو رفت و برگشت و مجموعا 9 کیلوبایت بایت بحرانی بازگشته است.

در نهایت، اگر شیوه نامه 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 جاوا اسکریپت غیر همگام

از آنجایی که منبع style.css فقط برای چاپ استفاده می شود، مرورگر نیازی به مسدود کردن آن برای ارائه صفحه ندارد. از این رو، به محض تکمیل ساخت DOM، مرورگر اطلاعات کافی برای رندر صفحه را دارد. در نتیجه، این صفحه تنها یک منبع حیاتی دارد (سند HTML) و حداقل طول مسیر رندر بحرانی یک رفت و برگشت است.

بازخورد

،

ایلیا گریگوریک

تاریخ انتشار: 31 مارس 2014

شناسایی و رفع تنگناهای عملکرد مسیر رندر حیاتی مستلزم دانش خوب از مشکلات رایج است. یک تور راهنما برای شناسایی الگوهای عملکرد رایج به شما کمک می کند تا صفحات خود را بهینه کنید.

بهینه‌سازی مسیر رندر حیاتی به مرورگر اجازه می‌دهد تا صفحه را در سریع‌ترین زمان ممکن نقاشی کند: صفحات سریع‌تر به تعامل بالاتر، صفحات بیشتر مشاهده شده و تبدیل بهبود یافته تبدیل می‌شوند. برای به حداقل رساندن مدت زمانی که یک بازدیدکننده صرف مشاهده یک صفحه خالی می کند، باید بهینه سازی کنیم که کدام منابع و به ترتیب بارگذاری می شوند.

برای کمک به تشریح این فرآیند، با ساده‌ترین حالت ممکن شروع کنید و صفحه ما را به صورت تدریجی بسازید تا منابع، سبک‌ها و منطق برنامه‌های کاربردی اضافی را شامل شود. در این فرآیند، ما هر مورد را بهینه خواهیم کرد. ما همچنین خواهیم دید که در کجا ممکن است همه چیز خراب شود.

تا کنون ما به طور انحصاری روی آنچه در مرورگر پس از در دسترس قرار گرفتن منبع (فایل CSS، JS یا HTML) برای پردازش اتفاق می‌افتد، تمرکز کرده‌ایم. ما زمان لازم برای واکشی منبع از حافظه پنهان یا از شبکه را نادیده گرفته ایم. موارد زیر را فرض می کنیم:

  • یک رفت و برگشت شبکه (تاخیر انتشار) به سرور 100 میلی ثانیه هزینه دارد.
  • زمان پاسخگویی سرور برای سند HTML 100 میلی‌ثانیه و برای همه فایل‌های دیگر 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 یا جاوا اسکریپت. سپس، پانل شبکه را در Chrome DevTools باز کنید و آبشار منبع حاصل را بررسی کنید:

CRP

همانطور که انتظار می رفت، دانلود فایل HTML تقریباً 200 میلی ثانیه طول کشید. توجه داشته باشید که قسمت شفاف خط آبی نشان دهنده مدت زمانی است که مرورگر بدون دریافت هیچ بایت پاسخی در شبکه منتظر می ماند در حالی که بخش جامد زمان پایان دانلود را پس از دریافت اولین بایت پاسخ نشان می دهد. دانلود HTML بسیار کوچک است (<4K)، بنابراین تنها چیزی که ما نیاز داریم یک رفت و برگشت برای واکشی فایل کامل است. در نتیجه، واکشی سند HTML تقریباً 200 میلی‌ثانیه طول می‌کشد که نیمی از زمان انتظار در شبکه و نیمی دیگر در انتظار پاسخ سرور است.

هنگامی که محتوای HTML در دسترس می شود، مرورگر بایت ها را تجزیه می کند، آنها را به توکن تبدیل می کند و درخت DOM را می سازد. توجه داشته باشید که DevTools به راحتی زمان رویداد DOMContentLoaded را در پایین (216 میلی‌ثانیه) گزارش می‌کند که با خط عمودی آبی نیز مطابقت دارد. فاصله بین پایان دانلود HTML و خط عمودی آبی (DOMContentLoaded) زمانی است که مرورگر برای ساختن درخت DOM طول می‌کشد — در این مورد، فقط چند میلی ثانیه.

توجه داشته باشید که "عکس عالی" ما رویداد domContentLoaded را مسدود نکرد. به نظر می رسد، ما می توانیم درخت رندر را بسازیم و حتی صفحه را بدون منتظر ماندن برای هر دارایی در صفحه نقاشی کنیم: همه منابع برای ارائه اولین رنگ سریع حیاتی نیستند . در واقع، وقتی در مورد مسیر رندر بحرانی صحبت می کنیم، معمولاً در مورد نشانه گذاری HTML، CSS و جاوا اسکریپت صحبت می کنیم. تصاویر رندر اولیه صفحه را مسدود نمی‌کنند - اگرچه ما باید سعی کنیم تصاویر را در اسرع وقت نقاشی کنیم.

گفته شد، رویداد load (همچنین به عنوان onload شناخته می‌شود)، روی تصویر مسدود شده است: DevTools رویداد onload را با سرعت 335 میلی‌ثانیه گزارش می‌کند. به یاد داشته باشید که رویداد onload نقطه ای را مشخص می کند که در آن تمام منابع مورد نیاز صفحه دانلود و پردازش شده اند. در این مرحله، اسپینر بارگیری می تواند چرخش را در مرورگر متوقف کند (خط عمودی قرمز در آبشار).

افزودن جاوا اسکریپت و CSS به ترکیب

صفحه "تجربه سلام جهان" ما ابتدایی به نظر می رسد، اما چیزهای زیادی در زیر سرپوش وجود دارد. در عمل ما به چیزی بیش از HTML نیاز خواهیم داشت: به احتمال زیاد، یک شیوه نامه CSS و یک یا چند اسکریپت برای افزودن مقداری تعامل به صفحه خود خواهیم داشت. هر دو را به مخلوط اضافه کنید تا ببینید چه اتفاقی می افتد:

<!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>

آن را امتحان کنید

قبل از افزودن جاوا اسکریپت و CSS:

DOM CRP

با جاوا اسکریپت و CSS:

DOM، CSSOM، JS

افزودن فایل‌های CSS و جاوا اسکریپت خارجی دو درخواست اضافی را به آبشار ما اضافه می‌کند که مرورگر همه آنها را تقریباً همزمان ارسال می‌کند. با این حال، توجه داشته باشید که اکنون تفاوت زمانی بسیار کمتری بین رویدادهای domContentLoaded و onload وجود دارد.

چه اتفاقی افتاد؟

  • برخلاف مثال ساده HTML ما، ما همچنین باید فایل CSS را برای ساختن CSSOM واکشی و تجزیه کنیم، و برای ساختن درخت رندر به هر دو DOM و CSSOM نیاز داریم.
  • از آنجایی که صفحه حاوی یک تجزیه کننده فایل جاوا اسکریپت مسدود کننده است، رویداد domContentLoaded تا زمانی که فایل CSS دانلود و تجزیه نشود مسدود می شود: چون جاوا اسکریپت ممکن است CSSOM را پرس و جو کند، ما باید فایل CSS را تا زمانی که دانلود شود مسدود کنیم تا بتوانیم جاوا اسکریپت را اجرا کنیم.

اگر اسکریپت خارجی خود را با یک اسکریپت درون خطی جایگزین کنیم چه؟ حتی اگر اسکریپت مستقیماً داخل صفحه باشد، مرورگر نمی‌تواند آن را تا زمانی که CSSOM ساخته شود اجرا کند. به طور خلاصه، جاوا اسکریپت درون خطی نیز مسدودکننده تجزیه کننده است.

گفتنی است، با وجود مسدود شدن در CSS، آیا درون‌خط‌سازی اسکریپت باعث می‌شود صفحه سریع‌تر رندر شود؟ آن را امتحان کنید و ببینید چه اتفاقی می افتد.

جاوا اسکریپت خارجی:

DOM، CSSOM، JS

جاوا اسکریپت درون خطی:

DOM، CSSOM، و JS داخلی

ما یک درخواست کمتر ارائه می کنیم، اما هر دو زمان onload و domContentLoaded ما عملاً یکسان هستند. چرا؟ خوب، ما می دانیم که مهم نیست جاوا اسکریپت درون خطی یا خارجی باشد، زیرا به محض اینکه مرورگر تگ اسکریپت را زد، آن را مسدود می کند و منتظر می ماند تا CSSOM ساخته شود. علاوه بر این، در مثال اول ما، مرورگر هر دو CSS و جاوا اسکریپت را به صورت موازی دانلود می‌کند و تقریباً همزمان دانلود می‌شوند. در این مثال، داخل کردن کد جاوا اسکریپت کمک زیادی به ما نمی کند. اما چندین استراتژی وجود دارد که می تواند صفحه ما را سریعتر رندر کند.

ابتدا به یاد بیاورید که همه اسکریپت های درون خطی مسدود کننده تجزیه کننده هستند، اما برای اسکریپت های خارجی می توانیم ویژگی async را برای رفع انسداد تجزیه کننده اضافه کنیم. inlining ما را لغو کنید و آن را امتحان کنید:

<!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>

آن را امتحان کنید

جاوا اسکریپت مسدودکننده تجزیه کننده (خارجی):

DOM، CSSOM، JS

جاوا اسکریپت غیرهمگام (خارجی):

DOM، CSSOM، JS غیر همگام

خیلی بهتر! رویداد domContentLoaded مدت کوتاهی پس از تجزیه HTML فعال می شود. مرورگر می داند که در جاوا اسکریپت مسدود نمی شود و از آنجایی که هیچ اسکریپت مسدودکننده تجزیه کننده دیگری وجود ندارد، ساخت CSSOM نیز می تواند به صورت موازی ادامه یابد.

از طرف دیگر، ما می‌توانستیم هم CSS و هم جاوا اسکریپت را درون خطی کنیم:

<!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 را در خود صفحه قرار داده‌ایم. این باعث می‌شود صفحه HTML ما بسیار بزرگ‌تر شود، اما نکته مثبت این است که مرورگر برای دریافت منابع خارجی نیازی به صبر ندارد. همه چیز همانجا در صفحه است.

همانطور که می بینید، حتی با یک صفحه بسیار ابتدایی، بهینه سازی مسیر رندر بحرانی یک تمرین غیر ضروری است: ما باید نمودار وابستگی بین منابع مختلف را درک کنیم، باید شناسایی کنیم که کدام منابع "بحرانی" هستند و باید انتخاب کنیم. در میان استراتژی های مختلف برای نحوه گنجاندن آن منابع در صفحه. هیچ راه حلی برای این مشکل وجود ندارد. هر صفحه متفاوت است برای تعیین استراتژی بهینه باید فرآیند مشابهی را به تنهایی دنبال کنید.

با این اوصاف، ببینید آیا می‌توانیم به عقب برگردیم و برخی از الگوهای عملکرد کلی را شناسایی کنیم.

الگوهای عملکرد

ساده ترین صفحه ممکن فقط از نشانه گذاری HTML تشکیل شده است. بدون CSS، بدون جاوا اسکریپت یا انواع دیگر منابع. برای رندر کردن این صفحه، مرورگر باید درخواست را آغاز کند، صبر کند تا سند 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

زمان بین T 0 و T 1 زمان پردازش شبکه و سرور را ثبت می کند. در بهترین حالت (اگر فایل HTML کوچک باشد)، فقط یک بار رفت و برگشت شبکه کل سند را واکشی می کند. با توجه به نحوه کار پروتکل های انتقال TCP، فایل های بزرگتر ممکن است به رفت و برگشت بیشتری نیاز داشته باشند. در نتیجه، در بهترین حالت صفحه فوق دارای یک مسیر رفت و برگشت (حداقل) مسیر رندر بحرانی است.

اکنون همان صفحه را در نظر بگیرید، اما با یک فایل 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 را دریافت کند. در نتیجه، این صفحه قبل از نمایش حداقل دو بار رفت و برگشت انجام می شود. یک بار دیگر، فایل CSS ممکن است چندین بار رفت و برگشت داشته باشد، از این رو بر روی "حداقل" تاکید می شود.

در اینجا اصطلاحاتی وجود دارد که برای توصیف مسیر رندر بحرانی استفاده می کنیم:

  • منبع بحرانی: منبعی که می تواند رندر اولیه صفحه را مسدود کند.
  • طول مسیر بحرانی: تعداد سفرهای رفت و برگشت یا کل زمان لازم برای واکشی همه منابع حیاتی.
  • بایت های بحرانی: تعداد کل بایت های مورد نیاز برای رسیدن به اولین رندر صفحه، که مجموع حجم فایل های انتقالی همه منابع حیاتی است. اولین مثال ما، با یک صفحه HTML، حاوی یک منبع حیاتی واحد (سند HTML) بود. طول مسیر بحرانی نیز برابر با یک رفت و برگشت شبکه بود (با فرض کوچک بودن فایل)، و کل بایت های بحرانی فقط اندازه انتقال خود سند HTML بود.

اکنون آن را با ویژگی های مسیر بحرانی مثال قبلی HTML و CSS مقایسه کنید:

DOM + CSSOM CRP

  • 2 منابع حیاتی
  • 2 یا بیشتر رفت و برگشت برای حداقل طول مسیر بحرانی
  • 9 کیلوبایت بایت بحرانی

برای ساختن درخت رندر به هر دو HTML و CSS نیاز داریم. در نتیجه، هر دو HTML و CSS منابع حیاتی هستند: CSS تنها پس از دریافت سند HTML توسط مرورگر واکشی می شود، بنابراین طول مسیر بحرانی حداقل دو رفت و برگشت است. هر دو منبع در مجموع به 9 کیلوبایت بایت بحرانی می‌رسند.

اکنون یک فایل جاوا اسکریپت اضافی را به ترکیب اضافه کنید.

<!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 اضافه کردیم که هم یک دارایی جاوا اسکریپت خارجی در صفحه و هم یک منبع مسدودکننده تجزیه کننده (یعنی حیاتی) است. بدتر از آن، برای اجرای فایل جاوا اسکریپت باید مسدود کنیم و منتظر CSSOM باشیم. به یاد بیاورید که جاوا اسکریپت می تواند CSSOM را پرس و جو کند و از این رو مرورگر مکث می کند تا style.css دانلود شود و CSSOM ساخته شود.

DOM، CSSOM، JavaScript CRP

در عمل، اگر به "شبکه آبشار" این صفحه نگاه کنیم، خواهید دید که هر دو درخواست CSS و جاوا اسکریپت تقریباً در یک زمان آغاز می شوند. مرورگر HTML را دریافت می کند، هر دو منبع را کشف می کند و هر دو درخواست را آغاز می کند. در نتیجه، صفحه نشان داده شده در تصویر قبلی دارای مشخصات مسیر حیاتی زیر است:

  • 3 منابع حیاتی
  • 2 یا بیشتر رفت و برگشت برای حداقل طول مسیر بحرانی
  • 11 کیلوبایت بایت بحرانی

ما اکنون سه منبع حیاتی داریم که تا 11 کیلوبایت بایت بحرانی اضافه می کنند، اما طول مسیر بحرانی ما هنوز دو رفت و برگشت است زیرا می توانیم CSS و جاوا اسکریپت را به صورت موازی انتقال دهیم. مشخص کردن ویژگی‌های مسیر رندر بحرانی شما به این معنی است که می‌توانید منابع حیاتی را شناسایی کنید و همچنین درک کنید که مرورگر چگونه واکشی آنها را زمان‌بندی می‌کند.

پس از گپ زدن با توسعه دهندگان سایت، متوجه می شویم که جاوا اسکریپتی که در صفحه خود قرار داده ایم نیازی به مسدود شدن ندارد. ما مقداری تجزیه و تحلیل و کدهای دیگر در آنجا داریم که نیازی به مسدود کردن رندر صفحه ما ندارد. با این دانش، می‌توانیم ویژگی async را به عنصر <script> برای رفع انسداد تجزیه‌کننده اضافه کنیم:

<!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 ناهمگام جاوا اسکریپت

یک اسکریپت ناهمزمان چندین مزیت دارد:

  • اسکریپت دیگر مسدود کننده تجزیه کننده نیست و بخشی از مسیر رندر حیاتی نیست.
  • از آنجا که هیچ اسکریپت مهم دیگری وجود ندارد، CSS نیازی به مسدود کردن رویداد domContentLoaded ندارد.
  • هر چه زودتر رویداد domContentLoaded فعال شود، منطق برنامه دیگر زودتر شروع به اجرا می کند.

در نتیجه، صفحه بهینه شده ما اکنون به دو منبع حیاتی (HTML و CSS) با حداقل طول مسیر بحرانی دو رفت و برگشت و مجموعا 9 کیلوبایت بایت بحرانی بازگشته است.

در نهایت، اگر شیوه نامه 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 جاوا اسکریپت غیر همگام

از آنجایی که منبع style.css فقط برای چاپ استفاده می شود، مرورگر نیازی به مسدود کردن آن برای ارائه صفحه ندارد. از این رو، به محض تکمیل ساخت DOM، مرورگر اطلاعات کافی برای رندر صفحه را دارد. در نتیجه، این صفحه تنها یک منبع حیاتی دارد (سند HTML) و حداقل طول مسیر رندر بحرانی یک رفت و برگشت است.

بازخورد

،

ایلیا گریگوریک

تاریخ انتشار: 31 مارس 2014

شناسایی و رفع تنگناهای عملکرد مسیر رندر حیاتی مستلزم دانش خوب از مشکلات رایج است. یک تور راهنما برای شناسایی الگوهای عملکرد رایج به شما کمک می کند تا صفحات خود را بهینه کنید.

بهینه‌سازی مسیر رندر حیاتی به مرورگر اجازه می‌دهد تا صفحه را در سریع‌ترین زمان ممکن نقاشی کند: صفحات سریع‌تر به تعامل بالاتر، صفحات بیشتر مشاهده شده و تبدیل بهبود یافته تبدیل می‌شوند. برای به حداقل رساندن مدت زمانی که یک بازدیدکننده صرف مشاهده یک صفحه خالی می کند، باید بهینه سازی کنیم که کدام منابع و به ترتیب بارگذاری می شوند.

برای کمک به تشریح این فرآیند، با ساده‌ترین حالت ممکن شروع کنید و صفحه ما را به صورت تدریجی بسازید تا منابع، سبک‌ها و منطق برنامه‌های کاربردی اضافی را شامل شود. در این فرآیند، ما هر مورد را بهینه خواهیم کرد. ما همچنین خواهیم دید که در کجا ممکن است همه چیز خراب شود.

تا کنون ما به طور انحصاری روی آنچه در مرورگر پس از در دسترس قرار گرفتن منبع (فایل CSS، JS یا HTML) برای پردازش اتفاق می‌افتد، تمرکز کرده‌ایم. ما زمان لازم برای واکشی منبع از حافظه پنهان یا از شبکه را نادیده گرفته ایم. موارد زیر را فرض می کنیم:

  • یک رفت و برگشت شبکه (تاخیر انتشار) به سرور 100 میلی ثانیه هزینه دارد.
  • زمان پاسخگویی سرور برای سند HTML 100 میلی‌ثانیه و برای همه فایل‌های دیگر 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 یا جاوا اسکریپت. سپس، پانل شبکه را در Chrome DevTools باز کنید و آبشار منبع حاصل را بررسی کنید:

CRP

همانطور که انتظار می رفت، دانلود فایل HTML تقریباً 200 میلی ثانیه طول کشید. توجه داشته باشید که قسمت شفاف خط آبی نشان دهنده مدت زمانی است که مرورگر بدون دریافت هیچ بایت پاسخی در شبکه منتظر می ماند در حالی که بخش جامد زمان پایان دانلود را پس از دریافت اولین بایت پاسخ نشان می دهد. دانلود HTML بسیار کوچک است (<4K)، بنابراین تنها چیزی که ما نیاز داریم یک رفت و برگشت برای واکشی فایل کامل است. در نتیجه، واکشی سند HTML تقریباً 200 میلی‌ثانیه طول می‌کشد که نیمی از زمان انتظار در شبکه و نیمی دیگر در انتظار پاسخ سرور است.

هنگامی که محتوای HTML در دسترس می شود، مرورگر بایت ها را تجزیه می کند، آنها را به توکن تبدیل می کند و درخت DOM را می سازد. توجه داشته باشید که DevTools به راحتی زمان رویداد DOMContentLoaded را در پایین (216 میلی‌ثانیه) گزارش می‌کند که با خط عمودی آبی نیز مطابقت دارد. فاصله بین پایان دانلود HTML و خط عمودی آبی (DOMContentLoaded) زمانی است که مرورگر برای ساختن درخت DOM طول می‌کشد — در این مورد، فقط چند میلی ثانیه.

توجه داشته باشید که "عکس عالی" ما رویداد domContentLoaded را مسدود نکرد. به نظر می رسد، ما می توانیم درخت رندر را بسازیم و حتی صفحه را بدون منتظر ماندن برای هر دارایی در صفحه نقاشی کنیم: همه منابع برای ارائه اولین رنگ سریع حیاتی نیستند . در واقع، وقتی در مورد مسیر رندر بحرانی صحبت می کنیم، معمولاً در مورد نشانه گذاری HTML، CSS و جاوا اسکریپت صحبت می کنیم. تصاویر رندر اولیه صفحه را مسدود نمی‌کنند - اگرچه ما باید سعی کنیم تصاویر را در اسرع وقت نقاشی کنیم.

گفته شد، رویداد load (همچنین به عنوان onload شناخته می‌شود)، روی تصویر مسدود شده است: DevTools رویداد onload را با سرعت 335 میلی‌ثانیه گزارش می‌کند. به یاد داشته باشید که رویداد onload نقطه ای را مشخص می کند که در آن تمام منابع مورد نیاز صفحه دانلود و پردازش شده اند. در این مرحله، اسپینر بارگیری می تواند چرخش را در مرورگر متوقف کند (خط عمودی قرمز در آبشار).

افزودن جاوا اسکریپت و CSS به ترکیب

صفحه "تجربه سلام جهان" ما ابتدایی به نظر می رسد، اما چیزهای زیادی در زیر سرپوش وجود دارد. در عمل ما به چیزی بیش از HTML نیاز خواهیم داشت: به احتمال زیاد، یک شیوه نامه CSS و یک یا چند اسکریپت برای افزودن مقداری تعامل به صفحه خود خواهیم داشت. هر دو را به مخلوط اضافه کنید تا ببینید چه اتفاقی می افتد:

<!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>

آن را امتحان کنید

قبل از افزودن جاوا اسکریپت و CSS:

DOM CRP

با جاوا اسکریپت و CSS:

DOM، CSSOM، JS

افزودن فایل‌های CSS و جاوا اسکریپت خارجی دو درخواست اضافی را به آبشار ما اضافه می‌کند که مرورگر همه آنها را تقریباً همزمان ارسال می‌کند. با این حال، توجه داشته باشید که اکنون تفاوت زمانی بسیار کمتری بین رویدادهای domContentLoaded و onload وجود دارد.

چه اتفاقی افتاد؟

  • برخلاف مثال ساده HTML ما، ما همچنین باید فایل CSS را برای ساختن CSSOM واکشی و تجزیه کنیم، و برای ساختن درخت رندر به هر دو DOM و CSSOM نیاز داریم.
  • از آنجایی که صفحه حاوی یک تجزیه کننده فایل جاوا اسکریپت مسدود کننده است، رویداد domContentLoaded تا زمانی که فایل CSS دانلود و تجزیه نشود مسدود می شود: چون جاوا اسکریپت ممکن است CSSOM را پرس و جو کند، ما باید فایل CSS را تا زمانی که دانلود شود مسدود کنیم تا بتوانیم جاوا اسکریپت را اجرا کنیم.

اگر اسکریپت خارجی خود را با یک اسکریپت درون خطی جایگزین کنیم چه؟ حتی اگر اسکریپت مستقیماً داخل صفحه باشد، مرورگر نمی‌تواند آن را تا زمانی که CSSOM ساخته شود اجرا کند. به طور خلاصه، جاوا اسکریپت درون خطی نیز مسدودکننده تجزیه کننده است.

گفتنی است، با وجود مسدود شدن در CSS، آیا درون‌خط‌سازی اسکریپت باعث می‌شود صفحه سریع‌تر رندر شود؟ آن را امتحان کنید و ببینید چه اتفاقی می افتد.

جاوا اسکریپت خارجی:

DOM، CSSOM، JS

جاوا اسکریپت درون خطی:

DOM، CSSOM، و JS داخلی

ما یک درخواست کمتر ارائه می کنیم، اما هر دو زمان onload و domContentLoaded ما عملاً یکسان هستند. چرا؟ خوب، ما می دانیم که مهم نیست جاوا اسکریپت درون خطی یا خارجی باشد، زیرا به محض اینکه مرورگر تگ اسکریپت را زد، آن را مسدود می کند و منتظر می ماند تا CSSOM ساخته شود. علاوه بر این، در مثال اول ما، مرورگر هر دو CSS و جاوا اسکریپت را به صورت موازی دانلود می‌کند و تقریباً همزمان دانلود می‌شوند. در این مثال، داخل کردن کد جاوا اسکریپت کمک زیادی به ما نمی کند. اما چندین استراتژی وجود دارد که می تواند صفحه ما را سریعتر رندر کند.

ابتدا به یاد بیاورید که همه اسکریپت های درون خطی مسدود کننده تجزیه کننده هستند، اما برای اسکریپت های خارجی می توانیم ویژگی async را برای رفع انسداد تجزیه کننده اضافه کنیم. inlining ما را لغو کنید و آن را امتحان کنید:

<!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>

آن را امتحان کنید

جاوا اسکریپت مسدودکننده تجزیه کننده (خارجی):

DOM، CSSOM، JS

جاوا اسکریپت غیرهمگام (خارجی):

DOM، CSSOM، JS غیر همگام

خیلی بهتر! رویداد domContentLoaded مدت کوتاهی پس از تجزیه HTML فعال می شود. مرورگر می داند که در جاوا اسکریپت مسدود نمی شود و از آنجایی که هیچ اسکریپت مسدودکننده تجزیه کننده دیگری وجود ندارد، ساخت CSSOM نیز می تواند به صورت موازی ادامه یابد.

از طرف دیگر، ما می‌توانستیم هم CSS و هم جاوا اسکریپت را درون خطی کنیم:

<!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 را در خود صفحه قرار داده‌ایم. این باعث می‌شود صفحه HTML ما بسیار بزرگ‌تر شود، اما نکته مثبت این است که مرورگر برای دریافت منابع خارجی نیازی به صبر ندارد. همه چیز همانجا در صفحه است.

همانطور که می بینید، حتی با یک صفحه بسیار ابتدایی، بهینه سازی مسیر رندر بحرانی یک تمرین غیر ضروری است: ما باید نمودار وابستگی بین منابع مختلف را درک کنیم، باید شناسایی کنیم که کدام منابع "بحرانی" هستند و باید انتخاب کنیم. در میان استراتژی های مختلف برای نحوه گنجاندن آن منابع در صفحه. هیچ راه حلی برای این مشکل وجود ندارد. هر صفحه متفاوت است برای تعیین استراتژی بهینه باید فرآیند مشابهی را به تنهایی دنبال کنید.

با این اوصاف، ببینید آیا می‌توانیم به عقب برگردیم و برخی از الگوهای عملکرد کلی را شناسایی کنیم.

الگوهای عملکرد

ساده ترین صفحه ممکن فقط از نشانه گذاری HTML تشکیل شده است. بدون CSS ، بدون جاوا اسکریپت یا انواع دیگر منابع. برای ارائه این صفحه ، مرورگر باید درخواست را آغاز کند ، صبر کنید تا سند 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 جهان

زمان بین T 0 و T 1 زمان پردازش شبکه و سرور را ضبط می کند. در بهترین حالت (اگر پرونده HTML کوچک باشد) ، فقط یک سفر دور شبکه کل سند را واگذار می کند. با توجه به نحوه انتقال پروتکل های TCP ، پرونده های بزرگتر ممکن است به سفرهای دور بیشتری نیاز داشته باشند. در نتیجه ، در بهترین حالت صفحه فوق دارای یک مسیر یک سفر یک دور (حداقل) مسیر ارائه مهم است.

اکنون همان صفحه را در نظر بگیرید ، اما با یک پرونده 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 را بدست آورد. در نتیجه ، این صفحه قبل از نمایش ، حداقل دو دورگرد را متحمل می شود. یک بار دیگر ، پرونده CSS ممکن است چندین مسابقه را انجام دهد ، از این رو تأکید بر "حداقل".

در اینجا چند اصطلاح که ما برای توصیف مسیر مهم ارائه استفاده می کنیم:

  • منبع بحرانی: منبعی که می تواند ارائه اولیه صفحه را مسدود کند.
  • طول مسیر بحرانی: تعداد دورگرد یا کل زمان لازم برای واکشی همه منابع مهم.
  • بایت های بحرانی: تعداد کل بایت های لازم برای رسیدن به اولین صفحه ، که مجموع پرونده های انتقال از همه منابع مهم است. مثال اول ما ، با یک صفحه HTML منفرد ، حاوی یک منبع بحرانی واحد (سند HTML) بود. طول مسیر بحرانی نیز برابر با یک دورگرد شبکه بود (با فرض اینکه پرونده کوچک بود) ، و کل بایت های بحرانی فقط اندازه انتقال خود سند HTML بود.

اکنون آن را با ویژگی های مهم مسیر HTML و CSS قبلی مقایسه کنید:

DOM + CSSOM CRP

  • 2 منبع مهم
  • 2 یا بیشتر دورگرد برای حداقل طول مسیر بحرانی
  • 9 کیلوبایت بایت های بحرانی

ما برای ساخت درخت رندر به HTML و CSS نیاز داریم. در نتیجه ، هر دو HTML و CS منابع بحرانی هستند: CSS فقط پس از دریافت مرورگر ، سند HTML را بدست می آورد ، از این رو طول مسیر بحرانی حداقل در دو دور است. هر دو منبع در مجموع 9 کیلوبایت بایت های بحرانی اضافه می کنند.

اکنون یک فایل JavaScript اضافی را به مخلوط اضافه کنید.

<!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 خارجی در صفحه است و یک منبع مسدود کننده تجزیه کننده (یعنی بحرانی). از همه بدتر ، برای اجرای پرونده JavaScript باید مسدود کنیم و منتظر CSSOM باشیم. به یاد بیاورید که JavaScript می تواند CSSOM را پرس و جو کند و از این رو مرورگر مکث می کند تا style.css بارگیری شود و CSSOM ساخته شود.

DOM ، CSSOM ، JavaScript CRP

گفته می شود ، در عمل اگر به "آبشار شبکه" این صفحه نگاه کنیم ، خواهید دید که هر دو درخواست CSS و JavaScript تقریباً در همان زمان آغاز می شوند. مرورگر HTML را دریافت می کند ، هر دو منابع را کشف می کند و هر دو درخواست را آغاز می کند. در نتیجه ، صفحه نشان داده شده در تصویر قبلی دارای ویژگی های مسیر بحرانی زیر است:

  • 3 منبع مهم
  • 2 یا بیشتر دورگرد برای حداقل طول مسیر بحرانی
  • 11 کیلوبایت بایت های بحرانی

اکنون ما سه منبع مهم داریم که حداکثر 11 کیلوبایت بایت های بحرانی را اضافه می کنیم ، اما طول مسیر بحرانی ما هنوز دو دورگرد است زیرا می توانیم CSS و JavaScript را به طور موازی منتقل کنیم. کشف ویژگی های مسیر رندر مهم شما به معنای قادر به شناسایی منابع مهم و همچنین درک چگونگی برنامه ریزی مرورگر است.

پس از گپ زدن با توسعه دهندگان سایت خود ، ما می دانیم که جاوا اسکریپت که در صفحه خود گنجانده ایم ، نیازی به مسدود کردن ندارد. ما برخی از تجزیه و تحلیل ها و کد های دیگر در آنجا داریم که نیازی به جلوگیری از ارائه صفحه ما نیست. با این دانش ، می توانیم ویژگی async را به عنصر <script> اضافه کنیم تا تجزیه کننده را از بین ببرد:

<!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 ، Async JavaScript CRP

یک اسکریپت ناهمزمان چندین مزیت دارد:

  • فیلمنامه دیگر مسدود کننده تجزیه کننده نیست و بخشی از مسیر مهم ارائه نیست.
  • از آنجا که اسکریپت های مهم دیگری وجود ندارد ، CSS نیازی به مسدود کردن رویداد domContentLoaded ندارد.
  • هرچه زودتر از domContentLoaded رویداد بارگیری شود ، زودتر منطق برنامه دیگر می تواند اجرای آن را آغاز کند.

در نتیجه ، صفحه بهینه سازی شده ما اکنون به دو منبع مهم (HTML و CSS) باز می گردد ، با حداقل طول مسیر بحرانی دو دورگرد و در مجموع 9 کیلوبایت بایت های بحرانی.

سرانجام ، اگر برگه سبک 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 غیر مسدود کننده و Async JavaScript CRP

از آنجا که منبع Style.css فقط برای چاپ استفاده می شود ، مرورگر برای ارائه صفحه نیازی به مسدود کردن آن ندارد. از این رو ، به محض اتمام ساخت DOM ، مرورگر اطلاعات کافی برای ارائه صفحه دارد. در نتیجه ، این صفحه فقط یک منبع مهم بحرانی (سند HTML) دارد و حداقل طول مسیر رندر مهم یک دورگرد است.

بازخورد