لقد سمعنا جميعًا مدى أهمية الأداء، ولكن عندما نتحدث عن الأداء، وعن جعل المواقع الإلكترونية "سريعة"، ما الذي نعنيه على وجه التحديد؟
والحقيقة هي أن الأداء نسبي:
- قد يكون الموقع الإلكتروني سريعًا لمستخدم واحد (على شبكة سريعة مع جهاز قوي) ولكنه بطيء لمستخدم آخر (على شبكة بطيئة مع جهاز منخفض المستوى).
- قد ينتهي تحميل موقعين إلكترونيين في مقدار الوقت نفسه بالضبط، ولكن قد يبدو تحميل أحد المواقع الإلكترونية بشكل أسرع (إذا كان يحمّل المحتوى تدريجيًا بدلاً من الانتظار حتى النهاية لعرض أي شيء).
- قد يظهر الموقع الإلكتروني بأنّه سريع التحميل، ولكنّه يستجيب بعد ذلك ببطء (أو لا يستجيب على الإطلاق) لتفاعل المستخدم.
لذلك عند الحديث عن الأداء، من المهم أن تكون دقيقًا وأن تشير إلى الأداء من حيث المعايير الموضوعية التي يمكن قياسها كميًا. وتُعرف هذه المعايير باسم metrics.
ولكن لمجرد أن المقياس يستند إلى معايير موضوعية ويمكن قياسه كميًا، فلا يعني ذلك بالضرورة أن هذه القياسات مفيدة.
تعريف المقاييس
في السابق، كان يتم قياس أداء الويب من خلال
حدث load
. مع أنّ load
هي لحظة محدّدة جيدًا في دورة حياة الصفحة، لا تتطابق هذه اللحظة بالضرورة مع أي شيء يهتم به المستخدم.
على سبيل المثال، يمكن للخادم الاستجابة بالحد الأدنى من الصفحة التي "يتم تحميلها" على الفور،
ثم يؤجِّل بعد ذلك جلب المحتوى وعرض أي محتوى على الصفحة حتى عدة ثوانٍ بعد تنشيط حدث load
. وعلى الرغم من أنّ وقت التحميل السريع لهذه الصفحة من الناحية الفنية، لن يكون هذا الوقت متوافقًا مع تجربة المستخدم لتحميل الصفحة.
على مدار السنوات القليلة الماضية، كان أعضاء فريق Chrome يعملون بالتعاون مع مجموعة عمل أداء الويب W3C على توحيد مجموعة من واجهات برمجة التطبيقات والمقاييس الجديدة التي تقيس بدقة أكبر تجربة المستخدمين لأداء صفحة الويب.
للمساعدة في ضمان أن تكون المقاييس ذات صلة بالمستخدمين، نضعها حول بعض الأسئلة الرئيسية:
هل تحدث؟ | هل بدأ التنقل بنجاح؟ هل استجاب الخادم؟ |
هل هي مفيدة؟ | هل تعرض محتوًى كافيًا يجعل المستخدمين يتفاعلوا معه؟ |
هل هي قابلة للاستخدام؟ | هل يمكن للمستخدمين التفاعل مع الصفحة أم أنها مشغولة؟ |
هل هو ممتع؟ | هل التفاعلات سلسة وطبيعية وخالية من التأخير والتأخير؟ |
طريقة قياس المقاييس
يتم قياس مقاييس الأداء بشكل عام بإحدى الطريقتَين التاليتَين:
- في المعمل: استخدام أدوات لمحاكاة تحميل الصفحة في بيئة متّسقة وخاضعة للرقابة
- في الحقل: على المستخدمين الحقيقيين الذين يحمّلون الصفحة ويتفاعلون معها
لا يكون أي من هذين الخيارين أفضل أو أسوأ من الآخر بالضرورة، في الواقع، أنت تريد استخدام كليهما بشكل عام لضمان أداء جيد.
في جلسة المعمل،
يُعد اختبار الأداء في المختبر أمرًا ضروريًا عند تطوير ميزات جديدة. قبل إصدار الميزات في مرحلة الإنتاج، من المستحيل قياس خصائص الأداء الخاصة بها على مستخدمين حقيقيين، لذا فإن اختبارها في المختبر قبل إطلاق الميزة هو أفضل طريقة لمنع تراجع الأداء.
في الميدان
من ناحية أخرى، وعلى الرغم من أن الاختبار في المختبر وكيل معقول للأداء، إلا أنه لا يعكس بالضرورة تجربة جميع المستخدمين لموقعك على الويب.
يمكن أن يختلف أداء الموقع الإلكتروني بشكل كبير استنادًا إلى إمكانات جهاز المستخدم وظروف الشبكة التي يستخدمها. يمكن أن يختلف أيضًا بناءً على ما إذا كان (أو كيفية) تفاعل المستخدم مع الصفحة.
إضافةً إلى ذلك، قد لا تكون عمليات تحميل الصفحات محددة. على سبيل المثال، قد تختلف خصائص الأداء من مستخدم إلى آخر إلى حدّ كبير مع المواقع الإلكترونية التي تحمِّل محتوى أو إعلانات مخصّصة. لن يكشف الاختبار المعملي عن هذه الاختلافات.
والطريقة الوحيدة لمعرفة مستوى أداء موقعك الإلكتروني بشكل صحيح للمستخدمين هي قياس أدائه أثناء تحميل هؤلاء المستخدمين والتفاعل معه. ويُشار إلى هذا النوع من القياس عادةً باسم مراقبة المستخدم الحقيقي أو RUM اختصارًا.
أنواع المقاييس
هناك عدة أنواع أخرى من المقاييس ذات الصلة بكيفية رؤية المستخدمين للأداء.
- سرعة التحميل الملموسة: هي سرعة تحميل الصفحة وعرض جميع عناصرها المرئية على الشاشة.
- تحميل الاستجابة: هو مدى سرعة تحميل وتنفيذ الصفحة لأي رمز JavaScript مطلوب لاستجابة المكوّنات بسرعة لتفاعل المستخدم.
- سرعة الاستجابة في وقت التشغيل: بعد تحميل الصفحة، يتم تحديد مدى سرعة استجابة الصفحة لتفاعل المستخدم.
- الثبات البصري: هل تتغير العناصر على الصفحة بطرق لا يتوقعها المستخدمون، وقد تتداخل مع تفاعلاتهم؟
- السلاسة: هل يتم عرض الانتقالات والصور المتحركة في عدد لقطات ثابت وتتدفق بسلاسة من حالة إلى أخرى؟
بالنظر إلى جميع أنواع مقاييس الأداء المذكورة أعلاه، نأمل أن يتضح لنا أنه لا يوجد مقياس واحد كافٍ لتسجيل جميع خصائص الأداء للصفحة.
مقاييس مهمة يجب قياسها
- سرعة عرض أول محتوى مرئي (FCP): يقيّم هذا المقياس الوقت منذ بدء تحميل الصفحة وحتى وقت عرض أي جزء من محتوى الصفحة على الشاشة. (ميزة اختبارية، حقل)
- سرعة عرض أكبر محتوى مرئي (LCP): يقيّم هذا المقياس الوقت المنقضي من بدء تحميل الصفحة وحتى عرض أكبر جزء نصي أو عنصر صورة على الشاشة. (ميزة اختبارية، حقل)
- مهلة الاستجابة الأولى (FID): تقيس هذه المدة الوقت المنقضي من تفاعل المستخدم مع موقعك الإلكتروني لأول مرة (عندما ينقر على رابط أو النقر على زر أو يستخدم عنصر تحكّم مخصّصًا يستند إلى JavaScript) إلى الوقت الذي يكون فيه المتصفّح قادرًا على الاستجابة لذلك التفاعل. (حقل)
- مدى استجابة الصفحة لتفاعلات المستخدم (INP): يقيس هذا المقياس وقت الاستجابة لكل نقرة أو نقرة أو تفاعل من لوحة المفاتيح يتم إجراؤها على الصفحة، ويحدّد استنادًا إلى عدد التفاعلات، أسوأ وقت استجابة للتفاعل للصفحة (أو قريب من أعلى مستوى) كقيمة واحدة تمثيلية لوصف مدى استجابة الصفحة بشكل عام. (ميزة اختبارية، حقل)
- إجمالي وقت الحظر (TBT): يقيس إجمالي المدة الزمنية بين FCP وTTI التي تم فيها حظر سلسلة التعليمات الرئيسية لفترة كافية لمنع استجابة الإدخالات. (ميزة اختبارية)
- متغيّرات التصميم التراكمية (CLS): تقيس النتيجة التراكمية لجميع متغيّرات التصميم غير المتوقّعة التي تحدث بين وقت بدء تحميل الصفحة ووقت تغيّر حالة دورة حياتها إلى مخفيّة. (ميزة اختبارية، حقل)
- الوقت المستغرق حتى أول بايت (TTFB): يقيس هذا المقياس الوقت الذي تستغرقه الشبكة للاستجابة لطلب المستخدم باستخدام البايت الأول من المورد. (ميزة اختبارية، حقل)
على الرغم من أن هذه القائمة تتضمن مقاييس تقيس العديد من جوانب الأداء المختلفة ذات الصلة بالمستخدمين، إلا أنها لا تشمل كل شيء. على سبيل المثال، لا يتم حاليًا تناول الاستجابة والسلاسة في وقت التشغيل.
وفي بعض الحالات، سيتم طرح مقاييس جديدة لتغطية المناطق المفقودة، ولكن في حالات أخرى، تكون أفضل المقاييس هي تلك المخصّصة لموقعك الإلكتروني خصّيصًا.
المقاييس المخصّصة
تساعد مقاييس الأداء المذكورة أعلاه في فهم خصائص الأداء لمعظم المواقع على الويب بشكل عام. كما أنها مفيدة أيضًا لإنشاء مجموعة مشتركة من المقاييس للمواقع الإلكترونية لمقارنة أدائها مع المواقع الإلكترونية المنافسة.
مع ذلك، قد تحتاج في بعض الأحيان إلى مقاييس إضافية للحصول على صورة أوضح عن أداء موقع إلكتروني معيّن. على سبيل المثال، يهدف مقياس LCP إلى قياس وقت انتهاء تحميل المحتوى الرئيسي للصفحة، ولكن قد تكون هناك حالات لا يكون فيها العنصر الأكبر جزءًا من المحتوى الرئيسي للصفحة وبالتالي قد لا يكون مقياس LCP ذا صلة.
لمعالجة هذه الحالات، قامت "مجموعة عمل أداء الويب" أيضًا بتوحيد واجهات برمجة التطبيقات (API) ذات المستوى الأدنى التي يمكن أن تكون مفيدة لتنفيذ المقاييس المخصَّصة الخاصة بك:
- User Timing API
- واجهة برمجة تطبيقات "مهام Google" الطويلة
- واجهة برمجة تطبيقات Element Timing
- واجهة برمجة تطبيقات توقيت التنقل
- واجهة برمجة تطبيقات توقيت الموارد
- توقيت الخادم
يمكنك الرجوع إلى الدليل حول المقاييس المخصَّصة للتعرّف على كيفية استخدام واجهات برمجة التطبيقات هذه لقياس خصائص الأداء الخاصة بموقعك الإلكتروني.