يهدف تقرير تجربة المستخدم في Chrome إلى مساعدة منتدى الويب في فهم توزيع أداء المُستخدِمين الفعلي وتطوّره. حتى الآن، كان تركيزنا على مقاييس عرض الصفحة وتحميلها، مثل سرعة عرض أول محتوى مرئي (FCP) ووقت التحميل (OL)، ما ساعدنا في معرفة مستوى أداء المواقع الإلكترونية من وجهة نظر المستخدمين. اعتبارًا من إصدار حزيران (يونيو) 2018، سنجرّب مقياسًا جديدًا يركّز على المستخدم ويركّز على التفاعل بين صفحات الويب: مهلة الاستجابة الأولى (FID). سيتيح لنا هذا المقياس الجديد فهم مدى سرعة استجابة المواقع الإلكترونية لمدخلات المستخدمين بشكل أفضل.
تم إتاحة مقياس FID مؤخرًا في Chrome كأحد الميزات التجريبية، ما يعني أنّه يمكن للمواقع الإلكترونية الاستفادة من هذه الميزة الجديدة لنظام التشغيل الويب. وبالمثل، سيكون مقياس FID متاحًا في تقرير تجربة المستخدم على Chrome كمقياس تجريبي، ما يعني أنّه سيكون متاحًا طوال مدة الفترة التجريبية للمصدر ضمن مساحة اسم "تجريبية" منفصلة.
كيفية قياس مقياس FID
ما هو رقم FID بالضبط؟ في ما يلي التعريف الوارد في مدوّنة الرسائل الإخبارية التي تتناول مهلة الاستجابة لأوّل إدخال :
تقيس مهلة الاستجابة لأوّل إدخال (FID) الوقت المستغرَق بدءًا من تفاعل المستخدِم مع موقعك الإلكتروني لأول مرة (أي عندما ينقر على رابط أو زر أو يستخدم عنصر تحكّم مخصّصًا أو يستند إلى جافا سكريبت) ولغاية تمكّن المتصفّح من الاستجابة لذلك التفاعل.
يشبه ذلك قياس الوقت المستغرَق من قرع جرس باب أحد الأشخاص إلى ردّه على الباب. إذا استغرق الأمر وقتًا طويلاً، قد يكون هناك العديد من الأسباب. على سبيل المثال، قد يكون الشخص بعيدًا عن الباب أو قد لا يتمكّن من التحرك بسرعة. وبالمثل، قد تكون صفحات الويب مشغولة في تنفيذ أعمال أخرى أو قد يكون جهاز المستخدم بطيئًا.
استكشاف مقياس FID في تقرير تجربة المستخدم على Chrome
بفضل بيانات FID التي تم جمعها خلال شهر واحد من ملايين المصادر، يمكنك استكشاف مجموعة كبيرة من الإحصاءات المثيرة للاهتمام. لنلقِ نظرة على بعض طلبات البحث التي توضّح كيفية استخراج هذه الإحصاءات من تقرير تجربة المستخدم في Chrome على BigQuery.
لنبدأ بالبحث عن النسبة المئوية لتجارب FID السريعة لموقع developers.google.com. يمكننا تعريف التجربة السريعة على أنّها تجربة تكون فيها قيمة FID أقل من 100 ملي ثانية. وفقًا لاقتراحات RAIL، إذا كان التأخير 100 ملي ثانية أو أقل، من المفترض أن يشعر المستخدم بأنّه فوري.
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
origin = 'https://developers.google.com'
تُظهر النتائج أنّه يتم تصنيف %95 من تجارب FID في هذا المصدر على أنّها فورية. هذا يبدو جيدًا حقًا، لكن كيف تقارنه بجميع الأصول في مجموعة البيانات؟
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
تُظهر نتائج طلب البحث هذا أنّ 84% من تجارب FID تقلّ عن 100 ملي ثانية. وبذلك، يكون موقع developers.google.com أعلى من المتوسط.
بعد ذلك، لنحاول تقسيم هذه البيانات لمعرفة ما إذا كان هناك فرق بين النسبة المئوية لوقت استجابة FID السريع على أجهزة الكمبيوتر المكتبي مقارنةً بالأجهزة الجوّالة. إحدى الفرضيات هي أنّ الأجهزة الجوّالة تسجِّل قيمًا أبطأ لمهلة الاستجابة لأوّل إدخال، ويعود ذلك على الأرجح إلى أنّ الأجهزة الجوّالة تتضمن أجهزة أبطأ مقارنةً بأجهزة الكمبيوتر المكتبي. إذا كانت وحدة المعالجة المركزية أقل كفاءة، قد تكون أكثر انشغالاً لفترة أطول وتؤدي إلى تجارب FID أبطأ.
SELECT
form_factor.name AS form_factor,
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
form_factor
| form_factor | fast_fid |
|---|---|
| أجهزة الكمبيوتر المكتبية | 96.02% |
| هاتف | 79.90% |
| جهاز لوحي | 76.48% |
تؤكّد النتائج فرضيتنا. تُظهر أجهزة الكمبيوتر المكتبي كثافة تراكمية أعلى لتجارب FID السريعة مقارنةً بأشكال الهاتف والجهاز اللوحي. لفهم سبب اختلافات الأداء، مثل أداء وحدة المعالجة المركزية، يجب إجراء اختبار أ/ب خارج نطاق تقرير تجربة المستخدم في Chrome.
بعد أن اطّلعنا على كيفية تحديد ما إذا كان مصدر معيّن يقدّم تجارب FID سريعة، لنلقِ نظرة على مصدرَين يحقّقان أداءً جيدًا جدًا.
المثال 1: http://secretlycanadian.com
تحقّق هذه الخدمة 98% من تجارب FID أقل من 100 ملي ثانية. كيف يتم ذلك؟ وبتحليل طريقة إنشائها في WebPageTest، تبيّن لنا أنها صفحة WordPress تتضمن صورًا كثيفة إلى حد ما، لكنها تحتوي على 168 كيلوبايت من JavaScript يتم تنفيذها خلال 500 ملي ثانية تقريبًا على جهاز المختبر. وهذا ليس عددًا كبيرًا من برمجة JavaScript وفقًا لخدمة HTTP Archive، مما يضع هذه الصفحة في الشريحة المئوية 28.
يشير الشريط الوردي الذي يتراوح طوله بين 2.7 و3.0 ثانية إلى مرحلة تحليل HTML. خلال هذه الفترة، لا تكون الصفحة تفاعلية وتبدو غير مكتملة بصريًا (يمكنك الاطّلاع على القسم "3.0 ثوانٍ" في شريط الصور أعلاه). بعد ذلك، يتم تقسيم أي مهام طويلة تحتاج إلى معالجة لضمان بقاء سلسلة التعليمات الرئيسية في وضع السكون. توضِّح الخطوط الوردية في الصف 11 كيفية توزيع عمل JavaScript في دفعات سريعة.
المثال 2: https://www.wtfast.com
يحقّق هذا المصدر %96 من تجارب FID الفورية. يتم تحميل 267 كيلوبايت من JavaScript (النسبة المئوية 38 في HTTP Archive) ويعالجه لمدة 900 ملي ثانية على جهاز المختبر. يُظهر شريط الفيلم أنّ الصفحة تحتاج إلى 5 ثوانٍ تقريبًا لعرض الخلفية وثانيتين إضافيتين لعرض المحتوى.
الأمر الأكثر إثارةً للاهتمام في النتائج هو أنّه لا يتم عرض أي محتوى تفاعلي حتى إذا كانت سلسلة التعليمات الرئيسية مشغولة لمدة تتراوح بين 3 و5 ثوانٍ. إنّ بطء FCP لهذه الصفحة هو ما يؤدي إلى تحسين FID. هذا مثال جيد على أهمية استخدام العديد من المقاييس لتمثيل تجربة المستخدم.
بدء الاستكشاف
يمكنك الاطّلاع على مزيد من المعلومات عن مقياس FID في حلقة هذا الأسبوع من سلسلة حالة الويب:
يتيح لنا توفُّر مقياس FID في "تقرير تجربة المستخدم في Chrome" وضع أساس لقياس تجارب التفاعل. باستخدام خط الأساس هذا، يمكننا ملاحظة التغيير في الإصدارات المستقبلية أو الأصول الفردية المعيارية. إذا كنت تريد بدء جمع FID في قياسات موقعك الإلكتروني، اشترِك في الإصدار التمهيدي من الإصدار الأصلي من خلال الانتقال إلى bit.ly/event-timing-ot واختيار ميزة "توقيت الحدث". وبطبيعة الحال، يمكنك البدء في استكشاف مجموعة البيانات للحصول على إحصاءات مثيرة للاهتمام حول حالة التفاعل على الويب. لا يزال هذا المقياس تجريبيًا، لذا يُرجى إرسال ملاحظاتك إلينا ومشاركته في مجموعة مناقشة "تقرير تجربة مستخدمي Chrome" أو على @ChromeUXReport على Twitter.