The #ChromeDevSummit site is live, happening Nov 12-13 in San Francisco, CA
Check it out for details and request an invite. We'll be diving deep into modern web tech & looking ahead to the platform's future.

قياس مسار العرض الحرج باستخدام توقيت التنقل

لا يمكنك تحسين ما لا يمكنك قياسه. ولكن من حسن الطالع أن واجهة برمجة تطبيقات Navigation Timing تتيح لنا جميع الأدوات اللازمة لقياس كل خطوة في مسار العرض الحرج.

TL;DR

  • توفر Navigation Timing طوابع زمنية عالية الدقة لقياس CRP.
  • يرسل المتصفح سلسلة من الأحداث القابلة للاستهلاك لتحديد عدة مراحل من CRP.

يعتمد أساس كل إستراتيجية أداء ثابتة على القياس الجيد والأدوات المفيدة. وقد اتضح لنا أن هذا ما توفره واجهة برمجة تطبيقات Navigation Timing تحديدًا.

Navigation Timing

تمثل كل علامة من العلامات الواردة في الرسم البياني أعلاه طابعًا زمنيًا عالي الدقة يتتبعه المتصفح مع كل صفحة يحملها. وفي الحقيقة، في هذه الحالة تحديدًا لا نعرض سوى جزء من جميع الطوابع الزمنية المختلفة - ذلك أننا في الوقت الحالي نتخطى جميع الطوابع الزمنية المتعلقة بالشبكة، ولكننا سنتناولها في درس لاحق.

ولكن ما المقصود بهذه الطوابع الزمنية؟

  • domLoading: هذا الطابع الزمني لبدء العملية بالكامل، حيث يكون المتصفح على وشك بدء تحليل وحدات بايت الأولى التي يتم الحصول عليها من HTML المستند.
  • domInteractive: يحدد نقطة انتهاء المتصفح من تحليل كل بنية HTML وDOM
  • domContentLoaded: يحدد نقطة استعداد DOM ووجود أوراق أنماط تحظر تنفيذ جافا سكريبت - مما يعني أنه يمكننا الآن (بشكل محتمل) إنشاء شجرة العرض.
    • تنتظر العديد من إطارات عمل جافا سكريبت هذا الحدث حتى تبدأ تنفيذ منطقها الخاص. لذلك يحدد المتصفح الطابعين الزمنيين EventStart و_EventEnd_ للسماح لنا بتتبع المدة التي يستغرقها هذا التنفيذ.
  • domComplete: كما يتضح من الاسم، تكتمل المعالجة ويكتمل تنزيل جميع الموارد على الصفحة (مثل الصور وما إلى ذلك) أي تتوقف أداة الانتقال في التحميل عن الانتقاء.
  • loadEvent: كخطوة أخيرة عند تحميل كل صفحة، يشغِّل المتصفح حدث onload يمكنه تشغيل منطق تطبيق إضافي.

تحدد مواصفات HTML شروطًا معينة لكل حدث: للوقوف على وقت التشغيل وأي الشروط يجب توفرها وهكذا. وفقًا لأهدافنا، سنركز على بعض المعالم الرئيسية ذات الصلة بمسار العرض الحرج:

  • domInteractive لتحديد وقت استعداد DOM.
  • domContentLoaded يستخدم عادة لتحديد وقت استعداد كل من DOM و CSSOM.
    • إذا لم يكن هناك جافا سكريبت يحظر المحلل، فسيتم تشغيل DOMContentLoaded في الحال بعد domInteractive.
  • domComplete لتحديد وقت استعداد الصفحة وجميع مواردها الفرعية.
<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure</title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <script>
      function measureCRP() {
        var t = window.performance.timing,
          interactive = t.domInteractive - t.domLoading,
          dcl = t.domContentLoadedEventStart - t.domLoading,
          complete = t.domComplete - t.domLoading;
        var stats = document.createElement('p');
        stats.textContent = 'interactive: ' + interactive + 'ms, ' +
            'dcl: ' + dcl + 'ms, complete: ' + complete + 'ms';
        document.body.appendChild(stats);
      }
    </script>
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>

قد يبدو المثال الوارد أعلاه مفزعًا لأول وهلة، إلا أنه بسيط للغاية. تحدد واجهة برمجة تطبيقات Navigation Timing جميع الطوابع الزمنية ذات الصلة وتنتظر الشفرة الخاصة بنا بدء تشغيل الحدث onload event — تذكر أنه يتم تشغيل حدث onload بعد domInteractive وdomContentLoaded وdomComplete — كما تحسب الفرق بين الطوابع الزمنية المختلفة. عرض تجريبي لـ NavTiming

بعد أن أوضحنا كل شيء نظريًا وعمليًا، أصبحت لدينا الآن بعض المعالم التي يمكننا تتبعها ووظيفة بسيطة للحصول على هذه المقاييس. لاحظ أنه بدلاً من طباعة هذه المقاييس على الصفحة، يمكنك أيضًا تعديل الشفرة لإرسالها إلى خادم إحصائي (Google Analytics يتولى تنفيذ ذلك تلقائيًا)، وهي طريقة رائعة للحفاظ على أداء علامات التبويب في صفحاتك وتحديد الصفحات المرشحة التي يمكنها الاستفادة من بعض التحسين.