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

Ilya Grigorik

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

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

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

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

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

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

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

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

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

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

ويتيح لك الجمع بين واجهة برمجة تطبيقات توقيت التنقل وأحداث المتصفح الأخرى الناتجة أثناء تحميل الصفحة إمكانية التقاط وتسجيل أداء 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 للمساعدة في تحديد هذه الموارد.

ملاحظات