الهدف من تقرير تجربة المستخدم في Chrome هو مساعدة منتدى الويب في فهم كيفية توزيع الأداء الفعلي للمستخدمين وتحسينه. حتى الآن، ركّزنا على مقاييس تحميل الصفحات وصفحاتها، مثل سرعة عرض المحتوى على الصفحة (FCP) وسرعة التحميل (OL)، ما ساعدنا على فهم أداء المواقع الإلكترونية من الناحية المرئية للمستخدمين. اعتبارًا من إصدار حزيران (يونيو) 2018، سنجرّب مقياسًا جديدًا يركِّز على المستخدم ويركّز على التفاعل بين صفحات الويب، وهو: مهلة الاستجابة لأوّل إدخال (FID). سيتيح لنا هذا المقياس الجديد أن نفهم بشكل أفضل مدى استجابة مواقع الويب لمدخلات المستخدمين.
تمت إتاحة FID مؤخرًا في Chrome كإصدار تجريبي من المصدر، ما يعني أنّه يمكن للمواقع الإلكترونية الاشتراك في تجربة هذه الميزة الجديدة لمنصة الويب الجديدة. وبالمثل، سيكون مقياس FID متاحًا في تقرير تجربة المستخدم على Chrome كمقياس تجريبي، أي أنّه سيكون متاحًا طوال مدة مرحلة التجربة والتقييم ضمن مساحة اسم "تجريبية" منفصلة.
كيفية قياس FID
فما هو مقياس FID تحديدًا؟ إليك كيفية تحديد ذلك في مشاركة المدونة التي تعلن عن مهلة الاستجابة لأوّل إدخال:
يقيس "مهلة الاستجابة لأوّل إدخال" (FID) الوقت المنقضي منذ تفاعل المستخدم مع موقعك الإلكتروني لأول مرة (أي عندما ينقر على رابط أو زر أو يستخدم عنصر تحكّم مخصّصًا يستند إلى JavaScript) إلى وقت استجابة المتصفّح لذلك التفاعل.
يشبه الأمر قياس الوقت بدءًا من قرع جرس باب شخص ما للإجابة عن على الباب. إذا استغرق الأمر وقتًا طويلاً، يمكن أن يرجع ذلك إلى العديد من الأسباب. على سبيل المثال، ربما كان الشخص بعيدًا عن الباب أو ربما لا يمكنه التحرك بسرعة. وبالمثل، قد تكون صفحات الويب مشغولة بأعمال أخرى أو قد يكون جهاز المستخدم بطيء.
استكشاف مقياس 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 للأجهزة الجوّالة أبطأ، ربما بسبب بطء الأجهزة مقارنةً بأجهزة الكمبيوتر المكتبية. إذا كانت وحدة المعالجة المركزية أقل قوة، قد تظل مشغولة لفترة أطول وتؤدي إلى تجارب أبطأ من حيث 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 السريعة مقارنةً بعوامل أشكال الهواتف والأجهزة اللوحية. يتطلب فهم سبب وجود هذه الاختلافات، مثل أداء وحدة المعالجة المركزية (CPU)، إجراء اختبار A/B خارج نطاق تقرير تجربة المستخدم على Chrome.
بعد أن تعرّفنا على كيفية تحديد ما إذا كان المصدر يتضمّن تجارب سريعة من حيث FID، لنلقِ نظرة على مصدرين يحقّقان أداءً جيدًا.
مثال 1: http://secretlycanadian.com
سجّل هذا المصدر 98% من تجارب FID أقل من 100 ملي ثانية. كيف يتم ذلك؟ وبتحليل طريقة إنشائه في WebPageTest، يمكننا ملاحظة أنها عبارة عن صفحة WordPress مليئة بالصور، ولكنها تحتوي على 168 كيلوبايت من JavaScript يتم تنفيذها في حوالي 500 مللي ثانية على الجهاز المختبري. ولا يمثّل هذا التعبير JavaScript بدرجة كبيرة بحسب أرشيف HTTP، وهو ما يضع هذه الصفحة ضمن الشريحة المئوية الثامنة والعشرين.
الشريط الوردي الذي يمتد من 2.7 إلى 3.0 ثوانٍ هو مرحلة تحليل HTML. خلال هذا الوقت، لا تكون الصفحة تفاعلية وتبدو غير مكتملة بصريًا (انظر "3.0 ثوانٍ" في شريط الصور أعلاه). بعد ذلك، يتم تقسيم أي مهام طويلة تحتاج إلى المعالجة لضمان بقاء سلسلة التعليمات الرئيسية ثابتة. توضح الخطوط الوردية في الصف 11 كيفية انتشار عمل JavaScript في صور متسلسلة سريعة.
المثال 2: https://www.wtfast.com
يحتوي هذا المصدر على تجارب FID فورية بنسبة 96%. وهو يحمِّل 267 كيلوبايت من JavaScript (الشريحة المئوية الثامنة والثلاثون في أرشيف HTTP) ويعالج لمدة 900 ملي ثانية على الجهاز المعملي. يُظهر شريط الصور أنّ الصفحة تستغرق 5 ثوانٍ تقريبًا لطلاء الخلفية وثانيتَين تقريبًا لطلاء المحتوى.
الأمر الأكثر إثارة للاهتمام في النتائج هو أنّه لا يظهر أي محتوى تفاعلي عندما تكون سلسلة التعليمات الرئيسية مشغولة لمدة تتراوح بين 3 و5 ثوانٍ. إن بطء سرعة عرض المحتوى على هذه الصفحة هو الذي يحسّن FID. هذا مثال جيد على أهمية استخدام العديد من المقاييس لتمثيل تجربة المستخدم.
بدء الاستكشاف
يمكنك التعرف على مزيد من المعلومات حول مقياس FID في حلقة هذا الأسبوع من The State of the Web:
إنّ توفُّر مقياس FID في تقرير تجربة المستخدم على Chrome يتيح لنا إنشاء قاعدة مرجعية لتجارب التفاعل. باستخدام هذا الأساس، يمكننا ملاحظة التغيير الخاص به في الإصدارات المستقبلية أو قياس الأصول الفردية. إذا كنت تريد البدء في جمع مقياس FID ضمن القياسات الميدانية لموقعك الإلكتروني، اشترِك في مرحلة التجربة والتقييم من خلال الانتقال إلى bit.ly/event-timing-ot واختيار ميزة Event Timing. وبالطبع، ابدأ في استكشاف مجموعة البيانات للحصول على إحصاءات مثيرة للاهتمام حول حالة التفاعل على الويب. لا يزال هذا مقياسًا تجريبيًا، لذا يُرجى تقديم ملاحظاتك ومشاركة تحليلك على مجموعة مناقشة تقرير تجربة المستخدم في Chrome أو @ChromeUXReport على Twitter.