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

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

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

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

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

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

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

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

الأهداف:

الإرشادات:

أدوات لقياس RAIL

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

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

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

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

منارة

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

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

الردّ

التحميل

WebPageTest

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

ملخّص

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

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

  • الاستجابة لإدخال المستخدم في أقل من 100 ملي ثانية

  • إنشاء إطار في أقل من 10 ملي ثانية عند استخدام الصور المتحركة أو التمرير

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

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