قياس مسار العرض الحرج

تاريخ النشر: 31 آذار (مارس) 2014

إنّ الأساس لكل استراتيجية أداء فعّالة هو القياس الجيد و الأدوات الجيدة. لا يمكنك تحسين ما لا يمكنك قياسه. يشرح هذا الدليل الطرق المختلفة لقياس أداء تكلفة الإجراء.

  • ينفّذ نهج Lighthouse سلسلة من الاختبارات المبرمَجة على صفحة معيّنة، وينشئ بعد ذلك تقريرًا عن أداء الصفحة في ما يتعلّق بقياس الأداء في الوقت الفعلي. يقدّم هذا النهج نظرة عامة سريعة وأساسية على مستوى عالٍ لأداء CRP لصفحة معيّنة يتم تحميلها في المتصفّح، ما يتيح لك اختبار أدائها وتكرارها وتحسينها بسرعة.
  • يرصد نهج Navigation Timing API مقاييس مراقبة المستخدِمين الفعليين (RUM). كما يشير الاسم، يتم تسجيل هذه المقاييس من تفاعلات المستخدمين الفعليين مع موقعك الإلكتروني، وتقدّم نظرة دقيقة على أداء CRP في العالم الواقعي، وفقًا لتجربة المستخدمين على مجموعة متنوعة من الأجهزة وحالات الشبكة.

بشكل عام، من الطرق الجيدة استخدام Lighthouse لتحديد فرص تحسين CRP الواضحة، ثم تجهيز الرمز البرمجي باستخدام واجهة برمجة التطبيقات Navigation Timing API لمراقبة أداء تطبيقك في الوقت الفعلي.

تدقيق صفحة باستخدام Lighthouse

Lighthouse هي أداة لتدقيق تطبيقات الويب تُجري سلسلة من الاختبارات على صفحة معيّنة، ثم تعرِض نتائج الصفحة في تقرير موحّد. يمكنك تشغيل Lighthouse كإضافة Chrome أو وحدة NPM، وهو ما يُعدّ مفيداً لدمج Lighthouse مع أنظمة الدمج المستمر.

اقرأ مقالة تدقيق تطبيقات الويب باستخدام Lighthouse للبدء.

عند تشغيل Lighthouse كإضافة في Chrome، تبدو نتائج سرعة التحميل في صفحتك مثل لقطة الشاشة التالية.

عمليات تدقيق الأداء في "منارة Google"

اطّلِع على سلاسل الطلبات المهمة للحصول على مزيد من المعلومات عن نتائج عملية التدقيق هذه.

يتيح لك الجمع بين Navigation Timing API وأحداث المتصفّح الأخرى التي يتمّ بثّها أثناء تحميل الصفحة تسجيل أداء CRP لأي صفحة في العالم الحقيقي.

وقت التنقل

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

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

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

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

  • يشير domInteractive إلى وقت جاهزية عنصر DOM.
  • يشير الرمز domContentLoaded عادةً إلى وقت استعداد كلّ من بنية DOM وCSSOM.
    • إذا لم يكن هناك محلل نحوي يحظر JavaScript، سيتم تشغيل 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 API جميع الطوابع الزمنية ذات الصلة وينتظر رمزنا بدء حدث onload، ويُرجى العِلم أنّ حدث onload يبدأ بعد domInteractive وdomContentLoaded وdomComplete، ويحسب الاختلاف بين الطوابع الزمنية المختلفة.

عرض NavTiming التجريبي

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

ماذا عن "أدوات مطوّري البرامج"؟

على الرغم من أنّ هذه المستندات تستخدِم أحيانًا لوحة "الشبكة" في Chrome DevTools لشرح مفاهيم CRP، إلا أنّ DevTools غير ملائم جيدًا لقياسات CRP لأنّه لا يحتوي على آلية مضمّنة لعزل الموارد المُهمّة. يمكنك إجراء عملية تدقيق في Lighthouse للمساعدة في تحديد هذه الموارد.

ملاحظات