نعلم جميعًا مدى أهمية ترك انطباع أول جيد. إنه مهم عند مقابلة أشخاص جدد، وأيضًا عند إنشاء تجارب على الويب.
على الويب، يمكن أن يُحدث الانطباع الأول الجيد على الويب الفرق بين أن يصبح المستخدم مستخدمًا وفيًا أو عندما يغادر المستخدم ولا يعود إليه مرة أخرى. يتبادر إلى أذهاننا سؤالٌ مُلح هو، ما الذي يُترك انطباعًا جيدًا، وكيف يمكنك قياس نوع الانطباع الذي يُحتمَل أن تتركه لدى المستخدمين؟
على الويب، قد تتخذ الانطباعات الأولى العديد من الأشكال المختلفة، حيث تكون لدينا الانطباعات الأولى عن تصميم الموقع وجاذبيته المرئية بالإضافة إلى الانطباعات الأولى عن سرعته واستجابته.
في حين أنّه من الصعب قياس مدى إعجاب المستخدمين بتصميم الموقع الإلكتروني باستخدام واجهات برمجة تطبيقات الويب، ليس من السهل قياس سرعته واستجابته.
إنّ الانطباع الأول الذي يتركه المستخدمون حول مدى سرعة تحميل موقعك الإلكتروني يمكن قياسه باستخدام سرعة عرض أول محتوى مرئي (FCP). ولكن مدى سرعة عرض موقعك على الويب لوحدات البكسل على الشاشة ليس سوى جزء من القصة. لا تقل أهمية عن مدى استجابة موقعك الإلكتروني عندما يحاول المستخدمون التفاعل مع وحدات البكسل هذه.
يساعد مقياس "مهلة الاستجابة الأولى" (FID) على قياس انطباع المستخدم الأول عن مدى تفاعل موقعك الإلكتروني واستجابته.
ما هو مقياس FID (مهلة الاستجابة الأولى)؟
يقيس FID الوقت منذ تفاعل المستخدم مع الصفحة لأول مرة (أي عندما ينقر على رابط أو ينقر على زر أو يستخدم عنصر تحكم مخصصًا يستند إلى JavaScript) إلى الوقت الذي يتمكن فيه المتصفح بالفعل من بدء معالجة معالِجات الأحداث استجابةً لذلك التفاعل.
ما هي درجة FID الجيدة؟
لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن يكون لها "مهلة الاستجابة الأولى" 100 ملّي ثانية أو أقل. لضمان تحقيق هذا الهدف لدى معظم المستخدمين، يُعدّ الحد الأدنى المناسب لقياسه الشريحة المئوية الخامسة والسبعين من عمليات تحميل الصفحات، مقسّمةً على الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي.
تفاصيل FID بالتفصيل
بصفتنا مطوّري برامج يكتبون تعليمات برمجية تستجيب للأحداث، غالبًا ما نفترض أنّه سيتم تشغيل الرمز البرمجي على الفور فور وقوع الحدث. ولكن كمستخدمين، مررنا جميعًا بعكس ذلك في كثير من الأحيان - فقد حمّلنا صفحة ويب على هاتفنا، وحاولنا التفاعل معها، ثم شعرنا بالإحباط عندما لم يحدث شيء.
بشكل عام، يحدث تأخر الإدخال (أي وقت استجابة الإدخال) لأنّ سلسلة التعليمات الرئيسية في المتصفّح مشغولة بفعل شيء آخر، لذلك لا يمكنها الاستجابة إلى المستخدم (بعد). وأحد الأسباب الشائعة لحدوث ذلك هو انشغال المتصفح بتحليل وتنفيذ ملف JavaScript كبير يُحمّله تطبيقك. وأثناء ذلك، لا يمكنه تشغيل أي أدوات معالجة للأحداث لأنّ لغة JavaScript التي يتم تحميلها قد تطلب منه اتخاذ إجراء آخر.
فكّر في المخطط الزمني التالي لتحميل صفحة ويب نموذجي:
يُظهر التمثيل المرئي أعلاه صفحة تُجري طلبين من الشبكة للحصول على موارد (على الأرجح ملفات CSS وJS)، وبعد الانتهاء من تنزيل هذه الموارد، تتم معالجتها في سلسلة التعليمات الرئيسية.
وينتج عن ذلك فترات تكون فيها سلسلة التعليمات الرئيسية مزدحمة للحظات، وهو ما يتضح من كتل المهام ذات اللون البيج.
عادةً ما يحدث تأخير طويل في الإدخال الأول بين سرعة عرض المحتوى على الصفحة (FCP) ووقت التفاعل (TTI) لأنّ الصفحة قد عرضت جزءًا من محتواها ولكنّها ليست تفاعلية بشكل موثوق إلى الآن. ولتوضيح كيفية حدوث ذلك، تمّت إضافة مقياسَي "سرعة عرض المحتوى على الصفحة" و"مؤشر جودة الهواء" إلى المخطط الزمني:
ربما لاحظت أنّ هناك وقتًا كافيًا (بما في ذلك ثلاث مهام طويلة) بين سرعة عرض أكبر جزء من المحتوى على الصفحة (FCP) وتقنية TTI، إذا حاول المستخدم التفاعل مع الصفحة خلال هذه الفترة (على سبيل المثال، من خلال النقر على رابط)، سيكون هناك تأخير بين وقت تلقّي النقرة ووقت تلقّي سلسلة التعليمات الرئيسية الإجابة.
ضع في اعتبارك ما سيحدث إذا حاول مستخدم التفاعل مع الصفحة بالقرب من بداية أطول مهمة:
ولأن الإدخال يحدث أثناء تشغيل المتصفح في منتصف عملية تشغيل مهمة، يتعين عليه الانتظار حتى تكتمل المهمة قبل أن تستجيب للمدخل. الوقت الذي يجب انتظاره هو قيمة FID لهذا المستخدم على هذه الصفحة.
ماذا لو لم يكن هناك مستمع للحدث في التفاعل؟
وتقيس FID مقدار دلتا بين وقت تلقّي حدث إدخال ووقت عدم نشاط سلسلة التعليمات الرئيسية في المرة التالية. وهذا يعني أنّه يتم قياس FID حتى في الحالات التي لم يتم فيها تسجيل مستمع الفعالية. يرجع السبب في ذلك إلى أنّ العديد من تفاعلات المستخدمين لا تتطلب أداة معالجة للحدث، ولكنّها تتطلب أن تكون سلسلة التعليمات الرئيسية غير نشطة من أجل تشغيلها.
على سبيل المثال، يجب انتظار اكتمال المهام الجارية في سلسلة التعليمات الرئيسية قبل الاستجابة لتفاعلات المستخدم:
- الحقول النصية ومربّعات الاختيار وأزرار الاختيار (
<input>و<textarea>) - اختيار القوائم المنسدلة (
<select>) - روابط (
<a>)
لماذا نراعي الإدخال الأول فقط؟
على الرغم من أنّ أي تأخير في الإدخال يمكن أن يؤدي إلى تجربة سيئة للمستخدم، ننصحك في المقام الأول بقياس تأخير الإدخال الأول لعدة أسباب:
- سيكون التأخير الأول في الاستجابة هو انطباع المستخدم الأول عن استجابة موقعك الإلكتروني، والانطباعات الأولى مهمة في تشكيل الانطباع العام عن جودة الموقع الإلكتروني وموثوقيته.
- إنّ أكبر مشاكل التفاعل التي نراها على الويب تحدث اليوم أثناء تحميل الصفحة. ولذلك، نرى أنّ التركيز المبدئي على تحسين أول تفاعل للمستخدم مع الموقع الإلكتروني سيكون له التأثير الأكبر على تحسين التفاعل الكلي على الويب.
- والحلول المقترحة لكيفية معالجة المواقع الإلكترونية لتأخيرات الإدخال الأولى العالية (تقسيم الرمز، وتحميل عدد أقل من ملفات JavaScript مقدمًا وما إلى ذلك) ليست بالضرورة الحلول نفسها لإصلاح تأخيرات الإدخال البطيئة بعد تحميل الصفحة. فمن خلال فصل هذه المقاييس، سنتمكن من توفير إرشادات أداء أكثر تحديدًا لمطوّري الويب.
ما الذي يتم احتسابه كإدخال أول؟
FID هو مقياس يقيس مدى استجابة الصفحة أثناء التحميل. وبناءً على ذلك، فإنّه يركّز فقط على أحداث الإدخال من الإجراءات المنفصلة، مثل النقرات والنقرات والضغط على المفاتيح.
التفاعلات الأخرى، مثل التمرير والتكبير/التصغير، هي إجراءات مستمرة لها قيود أداء مختلفة تمامًا (أيضًا، غالبًا ما تتمكن المتصفحات من إخفاء وقت الاستجابة عن طريق تشغيلها في سلسلة محادثات منفصلة).
بعبارة أخرى، تركز FID على R (الاستجابة) في نموذج أداء RAIL، في حين أن التمرير والتكبير/التصغير أكثر صلة بـ A (الرسوم المتحركة)، ويجب تقييم صفات الأداء بشكل منفصل.
ماذا لو لم يتفاعل المستخدم مع موقعك الإلكتروني مطلقًا؟
لن يتفاعل جميع المستخدمين مع موقعك الإلكتروني في كل مرة يزورون فيها. وليست كل التفاعلات ذات صلة بمهلة FID (كما هو مذكور في القسم السابق). وبالإضافة إلى ذلك، ستكون بعض التفاعلات الأولى للمستخدم في أوقات سيئة (عندما تكون سلسلة التعليمات الرئيسية مشغولة لفترة طويلة من الوقت)، وستكون بعض تفاعلات المستخدم الأولى في أوقات مناسبة (عندما تكون سلسلة التعليمات الرئيسية غير نشطة تمامًا).
وهذا يعني أنّ بعض المستخدمين لن يكون لديهم قيم FID، وستكون لدى بعض المستخدمين قيم منخفضة لـ FID، ومن المحتمل أن يكون لدى بعض المستخدمين قيم عالية لمهلة FID.
من المحتمل أن تكون كيفية تتبع مقياس FID وإعداد تقارير عنه وتحليله مختلفةً بعض الشيء عن المقاييس الأخرى التي قد تكون معتادًا عليها. يشرح القسم التالي أفضل طريقة للقيام بذلك.
لماذا لا نأخذ في الاعتبار سوى تأخير عملية الإدخال؟
وكما ذُكر أعلاه، لا تقيس FID سوى "التأخير" في معالجة الحدث. ولا يقيس هذا المقياس وقت معالجة الحدث نفسه أو الوقت الذي يستغرقه المتصفّح لتحديث واجهة المستخدم بعد تشغيل معالِجات الأحداث.
على الرغم من أنّ هذا الوقت مهم للمستخدم ويؤثر في تجربة الاستخدام،
لا يتم تضمينه في هذا المقياس لأنّ ذلك قد يحفز المطورين على إضافة حلول بديلة تزيد من سوء التجربة، أي أنه يمكنهم تضمين منطق معالج الأحداث في معاودة اتصال غير متزامنة (عبر
setTimeout() أو requestAnimationFrame()) لفصلها عن
المهمة المرتبطة بالحدث. ستكون النتيجة تحسنًا في درجة المقياس
ولكن استجابة أبطأ كما لاحظها المستخدم.
مع ذلك، وعلى الرغم من أنّ مقياس FID يقيس فقط نسبة "التأخير" من وقت استجابة الحدث، يمكن للمطوّرين الذين يريدون تتبُّع المزيد من مراحل نشاط الحدث إجراء ذلك باستخدام واجهة برمجة تطبيقات توقيت الحدث. راجِع دليل المقاييس المخصّصة لمزيد من التفاصيل.
كيفية قياس FID
إنّ مقياس FID هو مقياس لا يمكن قياسه إلا في الحقل، لأنّه يتطلّب استخدام مستخدم حقيقي للتفاعل مع صفحتك. يمكنك قياس مقياس FID باستخدام الأدوات التالية:
الأدوات الميدانية
- تقرير تجربة المستخدم على Chrome
- PageSpeed Insights
- Search Console (تقرير "مؤشرات أداء الويب الأساسية")
- مكتبة JavaScript
web-vitals
قياس FID في JavaScript
لقياس مقياس FID في JavaScript، يمكنك استخدام واجهة برمجة تطبيقات توقيت الحدث. يوضح المثال التالي كيفية إنشاء PerformanceObserver للاستماع إلى first-input الإدخالات وتسجيلها في وحدة التحكم:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
const delay = entry.processingStart - entry.startTime;
console.log('FID candidate:', delay, entry);
}
}).observe({type: 'first-input', buffered: true});
في المثال أعلاه، يتم قياس قيمة التأخير لإدخال first-input من خلال أخذ قيمة دلتا بين الطابع الزمني startTime للإدخال وprocessingStart. وفي معظم الحالات، تكون هذه القيمة هي قيمة FID، ولكن ليست كل إدخالات first-input صالحة لقياس FID.
يسرد القسم التالي الاختلافات بين ما تعرضه واجهة برمجة التطبيقات وكيفية حساب المقياس.
الاختلافات بين المقياس وواجهة برمجة التطبيقات
- سترسل واجهة برمجة التطبيقات إدخالات
first-inputللصفحات التي يتم تحميلها في علامة تبويب في الخلفية، ولكن يجب تجاهل هذه الصفحات عند احتساب مقياس FID. - سترسِل واجهة برمجة التطبيقات أيضًا إدخالات
first-inputإذا كانت الصفحة معروضة في الخلفية قبل حدوث أول عملية إدخال، ولكن يجب أيضًا تجاهل هذه الصفحات عند احتساب FID (لا يتم أخذ الإدخالات في الاعتبار إلا إذا كانت الصفحة في المقدّمة طوال الوقت). - لا تُبلغ واجهة برمجة التطبيقات عن إدخالات
first-inputعند استعادة الصفحة من التخزين المؤقت للصفحات، ولكن يجب قياس مقياس FID في هذه الحالات لأنّ المستخدمين يواجهونها كزيارات مختلفة للصفحات. - لا تُبلغ واجهة برمجة التطبيقات عن الإدخالات التي تحدث ضمن إطارات iframe، ولكن المقياس يُبلغ عنها
لأنها جزء من تجربة المستخدم على الصفحة. ويمكن أن يظهر ذلك على أنّه الفرق بين CrUX وRUM.
لقياس FID بشكل صحيح، يجب مراعاة ذلك. يمكن للإطارات الفرعية استخدام واجهة برمجة التطبيقات
لإبلاغ إدخالات
first-inputالخاصة بها إلى الإطار الأصلي للتجميع.
بدلاً من تذكُّر كل هذه الاختلافات الطفيفة، يمكن للمطوّرين استخدام مكتبة JavaScript web-vitals لقياس مقياس FID الذي يعالج هذه الاختلافات نيابةً عنك (حيثما أمكن ذلك، مع العِلم أنّ مشكلة iframe غير مشمولة):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
يمكنك الرجوع إلى رمز المصدر onFID() للاطّلاع على مثال كامل حول كيفية قياس FID في JavaScript.
تحليل بيانات FID وإعداد تقارير عنها
بسبب التباين المتوقّع في قيم FID، من المهم عند إعداد تقارير عن FID أن تنظر إلى توزيع القيم وتركز على الشرائح المئوية الأعلى.
مع أنّ اختيار النسبة المئوية لجميع الحدود الدنيا لـ "مؤشرات أداء الويب الأساسية" هو رقم 75، فإنّنا ننصح بشدة بالتحقّق من الشرائح المئوية الأولى من 95 إلى 99، لأنّ هذه الشرائح ستتوافق بشكل خاص مع التجارب الأولى السيئة التي يمر بها المستخدمون على موقعك الإلكتروني. وسوف تظهر لك المجالات التي تحتاج إلى أكبر قدر من التحسين.
وينطبق ذلك حتى في حال تقسيم تقاريرك حسب فئة الجهاز أو نوعه. على سبيل المثال، إذا شغّلت تقارير منفصلة لأجهزة الكمبيوتر المكتبي والأجهزة الجوّالة، يجب أن تكون قيمة FID الأكثر أهمية على أجهزة الكمبيوتر المكتبي هي بين 95 و99 في المئة من مستخدمي الكمبيوتر المكتبي، ويجب أن تكون قيمة FID الأكثر أهمية على الأجهزة الجوّالة هي نسبة ما بين 95 و99 في المئة من مستخدمي الأجهزة الجوّالة.
طريقة تحسين مقياس FID
يتوفّر دليل كامل حول تحسين مقياس FID لإرشادك خلال أساليب تحسين هذا المقياس.
سجلّ التغييرات
في بعض الأحيان، يتم اكتشاف أخطاء في واجهات برمجة التطبيقات المستخدمة لقياس المقاييس، وفي بعض الأحيان في تعريفات المقاييس نفسها. نتيجةً لذلك، يجب إجراء تغييرات في بعض الأحيان، وقد تظهر هذه التغييرات على أنّها تحسينات أو تراجع في التقارير ولوحات البيانات الداخلية.
لمساعدتك في إدارة ذلك، سيتم عرض كل التغييرات التي تطرأ على تنفيذ هذه المقاييس أو تعريفها في سجلّ التغييرات هذا.
إذا كانت لديك ملاحظات حول هذه المقاييس، يمكنك تقديمها من خلال مجموعة Google الخاصة بملاحظات حول الإلكترونيات الشخصية.