قياس الأداء باستخدام نموذج RAIL

RAIL هو نموذج أداء يركّز على المستخدم ويوفر بنية للتفكير في الأداء. يقسّم النموذج تجربة المستخدم إلى إجراءات رئيسية (مثل النقر والتمرير والتحميل)، ويساعدك في تحديد أهداف الأداء لكل إجراء.

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

الأجزاء الأربعة لنموذج الأداء RAIL: الاستجابة، والحركة، والخمول، والتحميل
الأجزاء الأربعة لنموذج الأداء RAIL

التركيز على احتياجات المستخدم واهتماماته

اجعل المستخدمين محور تركيز جهودك لتحسين الأداء. يوضّح الجدول أدناه المقاييس الرئيسية التي توضّح مدى إدراك المستخدمين لتأخّر الأداء:

تقدير المستخدم لتأخُّر الأداء
من 0 إلى 16 ملي ثانية يُجيد المستخدمون تتبُّع الحركة، ولا يعجبهم عندما لا تكون الرسوم المتحركة سلسة. ويعتبرون الصور المتحركة سلسة ما دام يتم عرض 60 لقطة جديدة كل ثانية. هذا يعني أنّ كل إطار يستغرق 16 مللي ثانية، بما في ذلك الوقت الذي يستغرقه المتصفّح لعرض الإطار الجديد على الشاشة، ما يترك للتطبيق حوالي 10 مللي ثانية لإنتاج إطار.
‫0 إلى 100 مللي ثانية الاستجابة لإجراءات المستخدمين خلال إطار الوقت هذا، ما يجعلهم يشعرون بأنّ النتيجة فورية وإذا طالت المدة أكثر من ذلك، ستنقطع العلاقة بين الفعل ورد الفعل.
من 100 إلى 1000 مللي ثانية خلال هذه الفترة، تبدو المهام وكأنّها جزء من تسلسل طبيعي ومستمر. بالنسبة إلى معظم المستخدمين على الويب، يمثّل تحميل الصفحات أو تغيير طرق العرض مهمة.
‫1000 مللي ثانية أو أكثر بعد 1,000 ملي ثانية (ثانية واحدة)، يفقد المستخدمون تركيزهم على المهمة التي يؤدونها.
‫10000 مللي ثانية أو أكثر بعد مرور 10,000 ملي ثانية (10 ثوانٍ)، يشعر المستخدمون بالإحباط ومن المرجّح أن يتخلّوا عن المهام. وقد تعود هذه الميزة أو لا تعود في وقت لاحق.

الأهداف والإرشادات

في سياق RAIL، يحمل المصطلحان الأهداف والإرشادات معاني محددة:

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

  • الإرشادات اقتراحات تساعدك في تحقيق أهدافك، وقد تكون خاصة بظروف الأجهزة الحالية واتصال الشبكة، وبالتالي قد تتغيّر بمرور الوقت.

الاستجابة: معالجة الأحداث في أقل من 50 ملي ثانية

الهدف: إكمال عملية انتقال بدأها المستخدم من خلال إدخال بيانات في غضون 100 مللي ثانية، كي يشعر المستخدمون بأنّ التفاعلات تتم على الفور.

الإرشادات:

  • لضمان استجابة مرئية في غضون 100 مللي ثانية، عالِج أحداث إدخال المستخدم في غضون 50 مللي ثانية. وينطبق ذلك على معظم عمليات الإدخال، مثل النقر على الأزرار أو تبديل عناصر التحكّم في النماذج أو بدء الرسوم المتحركة. ولا ينطبق ذلك على عمليات السحب أو التمرير التي تتم باللمس.

  • على الرغم من أنّ ذلك قد يبدو غير منطقي، إلا أنّه ليس من المناسب دائمًا الاستجابة لإدخال المستخدم على الفور. يمكنك استخدام فترة الـ 100 مللي ثانية هذه لتنفيذ مهام أخرى مكلفة، ولكن احرص على عدم حظر المستخدم. إذا أمكن، نفِّذ العمليات في الخلفية.

  • بالنسبة إلى الإجراءات التي تستغرق أكثر من 50 مللي ثانية لإكمالها، يجب دائمًا تقديم ملاحظات.

‫50 مللي ثانية أو 100 مللي ثانية؟

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

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

الصورة المتحركة: إنشاء إطار في 10 مللي ثانية

الأهداف:

  • إنتاج كل لقطة في صورة متحركة في غضون 10 مللي ثانية أو أقل من الناحية الفنية، تبلغ الميزانية القصوى لكل إطار 16 ملي ثانية (1000 ملي ثانية / 60 إطارًا في الثانية ≈ 16 ملي ثانية)، ولكن تحتاج المتصفحات إلى 6 ملي ثانية تقريبًا لعرض كل إطار، وبالتالي فإنّ الإرشادات تنص على 10 ملي ثانية لكل إطار.

  • احرص على أن تكون العناصر المرئية سلسة. يلاحظ المستخدمون اختلاف معدّلات عرض اللقطات.

الإرشادات:

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

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

  • الرسوم المتحركة المرئية، مثل عمليات الدخول والخروج والرسوم المتحركة بين اللقطات ومؤشرات التحميل
  • جارٍ الانتقال. ويشمل ذلك التمرير السريع، أي عندما يبدأ المستخدم في التمرير، ثم يرفع إصبعه، وتستمر الصفحة في التمرير.
  • السحب غالبًا ما تتبع الرسوم المتحركة تفاعلات المستخدم، مثل تحريك خريطة أو الضغط بإصبعين للتكبير.

غير نشط: زيادة وقت عدم النشاط إلى أقصى حد

الهدف: زيادة وقت الخمول إلى أقصى حد لزيادة فرص استجابة الصفحة لإدخال المستخدم في غضون 50 مللي ثانية.

الإرشادات:

  • استخدِم وقت الخمول لإكمال العمل المؤجّل. على سبيل المثال، عند تحميل الصفحة في البداية، حمِّل أقل قدر ممكن من البيانات، ثم استخدِم وقت الخمول لتحميل بقية البيانات.

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

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

التحميل: عرض المحتوى وإتاحة التفاعل معه في أقل من 5 ثوانٍ

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

الأهداف:

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

  • بالنسبة إلى عمليات التحميل اللاحقة، من المستحسن أن يتم تحميل الصفحة في أقل من ثانيتَين.

الإرشادات:

أدوات قياس RAIL

تتوفّر بعض الأدوات لمساعدتك في أتمتة قياسات RAIL. يعتمد اختيارك على نوع المعلومات التي تحتاج إليها ونوع سير العمل الذي تفضّله.

أدوات مطوري البرامج في Chrome

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

في ما يلي ميزات "أدوات مطوّري البرامج" ذات الصلة بشكل خاص:

منارة

تتوفّر Lighthouse في أدوات مطوّري البرامج في Chrome، وفي إحصاءات PageSpeed، وكإضافة في Chrome، ووحدة Node.js، وضمن WebPageTest. ما عليك سوى إدخال عنوان URL، وستحاكي الأداة جهازًا متوسط الأداء مع اتصال شبكة جيل ثالث بطيء، وستنفّذ سلسلة من عمليات التدقيق على الصفحة، ثم ستزوّدك بتقرير عن أداء التحميل، بالإضافة إلى اقتراحات حول كيفية التحسين.

عمليات التدقيق التالية مهمة بشكل خاص:

الردّ

التحميل

WebPageTest

WebPageTest هي أداة لقياس أداء الويب تستخدم متصفّحات حقيقية للوصول إلى صفحات الويب وجمع مقاييس التوقيت. أدخِل عنوان URL في webpagetest.org/easy للحصول على تقرير مفصّل حول أداء تحميل الصفحة على جهاز Moto G4 حقيقي باستخدام اتصال شبكة جيل ثالث بطيء. يمكنك أيضًا ضبطه لتضمين عملية تدقيق Lighthouse.

ملخّص

‫RAIL هي أداة للنظر إلى تجربة المستخدم على موقع إلكتروني على أنّها رحلة تتألف من تفاعلات مميزة. تعرَّف على انطباعات المستخدمين عن موقعك الإلكتروني لتحديد أهداف الأداء التي لها أكبر تأثير في تجربة المستخدم.

  • التركيز على احتياجات المستخدم واهتماماته

  • الردّ على إدخال المستخدم في أقل من 100 مللي ثانية

  • إنتاج إطار في أقل من 10 مللي ثانية عند تحريك العناصر أو التنقّل بين الصفحات

  • زيادة وقت عدم نشاط سلسلة التعليمات الرئيسية إلى أقصى حد

  • تحميل المحتوى التفاعلي في أقل من 5,000 مللي ثانية