مقاييس الأداء التي تركّز على المستخدم

Philip Walton

لقد سمعنا جميعًا مدى أهمية الأداء، ولكن عندما نتحدث عن الأداء وجعل المواقع الإلكترونية "سريعة"، ما الذي نعنيه تحديدًا؟

والحقيقة هي أن الأداء نسبيًا:

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

عند الحديث عن الأداء، من المهم أن تكون دقيقًا وأن تشير إلى الأداء من حيث metrics، وهي معايير موضوعية يمكن قياسها كميًا. ولكن من المهم أيضًا التأكد من أن المقاييس التي تقيسها مفيدة.

المقاييس

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

على سبيل المثال، يمكن أن يستجيب الخادم بالحد الأدنى من الصفحة التي "يتم تحميلها" على الفور، ثم يؤجِّل بعد ذلك جلب المحتوى أو عرض أي محتوى على الصفحة حتى عدة ثوانٍ بعد بدء حدث load. مثل هذه الصفحة من الناحية الفنية لديها وقت تحميل سريع، ولكن هذا الوقت لا يتوافق مع تجربة المستخدم لتحميل الصفحة.

على مدار السنوات القليلة الماضية، تعاون أعضاء فريق Chrome بالتعاون مع مجموعة عمل أداء الويب W3C على توحيد مجموعة من واجهات برمجة التطبيقات والمقاييس الجديدة التي تقيس بدقة أكبر تجربة المستخدمين لأداء صفحة الويب.

للمساعدة في ضمان أن تكون المقاييس ذات صلة بالمستخدمين، نضعها حول بعض الأسئلة الرئيسية:

هل تحدث؟ هل بدأ التنقل بنجاح؟ هل استجاب الخادم؟
هل هي مفيدة؟ هل تعرض محتوًى كافيًا يجعل المستخدمين يتفاعلوا معه؟
هل هي قابلة للاستخدام؟ هل يمكن للمستخدمين التفاعل مع الصفحة أم أنها مشغولة؟
هل هو ممتع؟ هل التفاعلات سلسة وطبيعية وخالية من التأخير والتأخير؟

طريقة قياس المقاييس

يتم قياس مقاييس الأداء بشكل عام بإحدى الطريقتَين التاليتَين:

  • في المعمل: استخدام أدوات لمحاكاة تحميل الصفحة في بيئة متّسقة وخاضعة للرقابة
  • في الحقل: على المستخدمين الحقيقيين الذين يحمّلون الصفحة ويتفاعلون معها

لا يُعدّ أيّ من هذين الخيارين بالضرورة أفضل أو أسوأ من الآخر. في الواقع، أنت تريد بشكل عام استخدام كليهما لضمان الأداء الجيد.

في جلسة المعمل،

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

في الميدان

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

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

أيضًا لا تكون عمليات تحميل الصفحات مؤكدة دائمًا. على سبيل المثال، قد تختلف خصائص الأداء من مستخدم إلى آخر إلى حدّ كبير مع المواقع الإلكترونية التي تُحمّل محتوى أو إعلانات مخصّصة. لن يكشف الاختبار المعملي عن هذه الاختلافات.

الطريقة الوحيدة لمعرفة مدى جودة أداء موقعك الإلكتروني للمستخدمين هي قياس أدائه أثناء تحميل هؤلاء المستخدمين والتفاعل معه. ويُطلق على هذا النوع من القياس عادةً اسم مراقبة المستخدم الحقيقي (RUM).

أنواع المقاييس

هناك عدة أنواع أخرى من المقاييس ذات الصلة بكيفية رؤية المستخدمين للأداء:

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

بالنظر إلى جميع هذه الأنواع من مقاييس الأداء، نأمل أن يتضح لنا أنه لا يوجد مقياس واحد كافٍ لتسجيل جميع خصائص أداء الصفحة.

مقاييس مهمة يجب قياسها

سرعة عرض أول محتوى مرئي (FCP)
الوقت منذ بدء تحميل الصفحة حتى وقت عرض أي جزء من محتوى الصفحة على الشاشة. (مختبر، حقل)
سرعة عرض أكبر محتوى مرئي (LCP)
الوقت المطلوب منذ بدء تحميل الصفحة وحتى عرض أكبر جزء نصي أو عنصر صورة على الشاشة. (مختبر، حقل)
مدى استجابة الصفحة لتفاعلات المستخدم (INP)
وقت الاستجابة لكل نقرة أو نقرة أو تفاعل باستخدام لوحة المفاتيح يتم إجراؤه على الصفحة. استنادًا إلى عدد التفاعلات، يحدّد هذا المقياس أسوأ (أو أقرب إلى أسوأ وقت) تفاعل على الصفحة كقيمة واحدة تمثيلية لوصف مدى استجابة الصفحة بشكل عام. (مختبر، حقل)
إجمالي وقت الحظر (TBT)
إجمالي الوقت بين FCP ووقت التفاعل (TTI) الذي تم فيه حظر سلسلة التعليمات الرئيسية لمدة كافية لمنع استجابة الإدخالات. (مختبر)
متغيّرات التصميم التراكمية (CLS)
النتيجة التراكمية لجميع تغيُّرات التصميم غير المتوقَّعة التي تحدث بين وقت بدء تحميل الصفحة ووقت تغيّر حالة دورة حياتها إلى مخفيّة. (مختبر، حقل)
مدة تحميل أول بايت (TTFB)
الوقت الذي تستغرقه الشبكة للاستجابة لطلب أحد المستخدمين بالبايت الأول من المورد. (المختبر، الحقل)

تتضمن هذه القائمة مقاييس تقيس العديد من جوانب الأداء المختلفة ذات الصلة بالمستخدمين، لكنها لا تشمل كل شيء. على سبيل المثال، لا يتم تناول استجابة وقت التشغيل والسلاسة.

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

المقاييس المخصّصة

إنّ مقاييس الأداء المدرجة هنا مفيدة للحصول على فهم عام لخصائص أداء معظم المواقع على الويب. كما أنها جيدة لوجود مجموعة مشتركة من المقاييس للمواقع لمقارنة أدائها في مقابل المنافسين.

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

لمعالجة هذه الحالات، قامت "مجموعة عمل أداء الويب" أيضًا بتوحيد واجهات برمجة التطبيقات (API) ذات المستوى الأدنى التي يمكن أن تكون مفيدة لتنفيذ المقاييس المخصَّصة الخاصة بك:

يمكنك الاطّلاع على دليل المقاييس المخصَّصة لمعرفة كيفية استخدام واجهات برمجة التطبيقات هذه لقياس خصائص الأداء الخاصة بموقعك الإلكتروني.