يهدف تقرير تجربة المستخدم في 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.