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

يكمن أساس كل استراتيجية أداء قوية في القياس الجيد والأدوات. ولا يمكنك تحسين ما لا يمكنك قياسه. يشرح هذا المستند أساليب مختلفة لقياس أداء CRP.

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

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

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

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

راجِع تدقيق تطبيقات الويب باستخدام Lighthouse للبدء.

عند تشغيل Lighthouse كإضافة في Chrome، تظهر نتائج CRP لصفحتك على النحو التالي: لقطة الشاشة.

عمليات تدقيق CRP في Lighthouse

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

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

وقت التنقل

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

إذن، ماذا تعني هذه الطوابع الزمنية؟

  • domLoading: هذا هو الطابع الزمني للبدء في العملية بأكملها، والمتصفّح على وشك البدء في تحليل أوّل وحدات بايت تم استلامها من مستند 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>

التجربة الآن

قد يبدو المثال أعلاه شاقًا بعض الشيء للوهلة الأولى، ولكنه في الواقع بسيط للغاية. تسجِّل واجهة برمجة التطبيقات Accessibility Timing API جميع الطوابع الزمنية ذات الصلة، وينتظر رمزنا ببساطة تنشيط حدث "onload". وتذكَّر أنّه يتم تنشيط حدث "onload" بعد domInteractive وdomContentLoaded وdomComplete، ويحسِب الفرق بين الطوابع الزمنية المختلفة.

الإصدار التجريبي من NavTiming

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

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

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

إضافة ملاحظات