Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

First Input Delay (FID)

Philip Walton

Browser Support

ندرك جميعًا أهمية ترك انطباع أول جيد. وهذا مهم عند مقابلة أشخاص جدد، كما أنّه مهم أيضًا عند إنشاء تجارب على الويب.

على الويب، يمكن أن يكون الانطباع الأول الجيد هو الفرق بين أن يصبح المستخدم مخلصًا أو أن يغادر الموقع ولا يعود إليه أبدًا. السؤال هو: ما الذي يترك انطباعًا جيدًا، وكيف يمكنك قياس نوع الانطباع الذي من المحتمل أن تتركه لدى المستخدمين؟

على الويب، يمكن أن تتخذ الانطباعات الأولى أشكالًا مختلفة، مثل الانطباعات الأولى عن تصميم الموقع الإلكتروني وجاذبيته المرئية، بالإضافة إلى الانطباعات الأولى عن سرعته ومدى استجابته.

في حين أنّه من الصعب قياس مدى إعجاب المستخدمين بتصميم الموقع الإلكتروني باستخدام واجهات برمجة تطبيقات الويب، فإنّ قياس سرعته ومدى استجابته ليس صعبًا.

يمكن قياس الانطباع الأول لدى المستخدمين عن مدى سرعة تحميل موقعك الإلكتروني باستخدام سرعة عرض المحتوى على الصفحة (FCP). ولكنّ مدى سرعة عرض موقعك الإلكتروني للوحدات بكسل على الشاشة ليس سوى جزء من القصة. من المهم أيضًا مدى استجابة موقعك الإلكتروني عندما يحاول المستخدمون التفاعل مع هذه الوحدات بكسل.

يساعد مقياس "مهلة الاستجابة لأوّل إدخال" (FID) في قياس الانطباع الأول لدى المستخدم عن مدى تفاعل موقعك الإلكتروني واستجابته.

ما هو FID؟

يقيس FID الوقت منذ أن يتفاعل المستخدم لأول مرة مع صفحة (أي عندما ينقر على رابط أو زر أو يستخدم عنصر تحكم مخصّصًا أو يستند إلى JavaScript) حتى يتمكّن المتصفّح فعليًا من بدء معالجة معالِجات الأحداث استجابةً لذلك التفاعل.

ما هي نتيجة FID الجيدة؟

لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن تكون "مهلة الاستجابة لأوّل إدخال" 100 ملّي ثانية أو أقل. لضمان تحقيق هذا الهدف لمعظم المستخدمين، فإنّ المعيار الجيد للقياس هو أن تتحقق هذه القيم في %75 على الأقل من عمليات تحميل الصفحات، موزعةً بين أجهزة الجوال وأجهزة الكمبيوتر المكتبية.

تكون قيم FID جيدة إذا كانت 2.5 ثانية أو أقل، وتكون سيئة إذا كانت أكبر من 4.0 ثوانٍ، أما القيم بين هاتين المدتين فتكون بحاجة إلى تحسين.

FID بالتفصيل

بصفتنا مطوّرين نكتب رمزًا يستجيب للأحداث، نفترض غالبًا أنّه سيتم تشغيل الرمز على الفور، أي بمجرد وقوع الحدث. ولكن بصفتنا مستخدمين، فقد واجهنا جميعًا في كثير من الأحيان العكس، فقد حمّلنا صفحة ويب على هواتفنا وحاولنا التفاعل معها، ثم شعرنا بالإحباط عندما لم يحدث أي شيء.

بشكل عام، يحدث تأخير الإدخال (المعروف أيضًا باسم وقت استجابة الإدخال) لأنّ سلسلة التعليمات الرئيسية للمتصفّح مشغولة بتنفيذ مهمة أخرى، لذا لا يمكنها (حتى الآن) الاستجابة للمستخدم. أحد الأسباب الشائعة لحدوث ذلك هو أنّ المتصفّح مشغول بتحليل ملف JavaScript كبير تم تحميله بواسطة تطبيقك وتنفيذه. أثناء ذلك، لا يمكنه تشغيل أي مستمعين للأحداث لأنّ JavaScript الذي يتم تحميله قد يطلب منه تنفيذ مهمة أخرى.

لا يقيس FID سوى "التأخير" في معالجة الأحداث. ولا يقيس إجمالي مدة معالجة الحدث نفسه، ولا الوقت الذي يستغرقه المتصفّح لتحديث واجهة المستخدم بعد تشغيل معالِجات الأحداث. على الرغم من أنّ هذا الوقت يؤثر في تجربة المستخدم، فإنّ تضمينه كجزء من FID سيشجّع المطوّرين على الاستجابة للأحداث بشكل غير متزامن، ما سيؤدي إلى تحسين المقياس ولكن من المحتمل أن يجعل التجربة أسوأ. لمزيد من التفاصيل، يُرجى الاطّلاع أدناه على سبب عدم أخذ سوى تأخير الإدخال في الاعتبار.

إليك المخطط الزمني لتحميل صفحة ويب نموذجية:

مثال على تتبُّع تحميل الصفحة

تعرض الصورة المرئية أعلاه صفحة تُجري طلبَين على الشبكة للحصول على موارد (من المحتمل أن تكون ملفات CSS وJS)، وبعد انتهاء تنزيل هذه الموارد، تتم معالجتها على سلسلة التعليمات الرئيسية.

يؤدي ذلك إلى فترات تكون فيها سلسلة التعليمات الرئيسية مشغولة مؤقتًا، ويتم الإشارة إلى ذلك من خلال مربّعات المهام ذات اللون البيج.

تحدث حالات تأخير الاستجابة لأوّل إدخال الطويلة عادةً بين سرعة عرض أول محتوى مرئي (FCP) وسرعة الاستعداد للتفاعل (TTI) لأنّ الصفحة قد عرضت بعض محتواها ولكنّها لم تصبح بعد تفاعلية بشكل موثوق. لتوضيح كيفية حدوث ذلك، تمت إضافة FCP وTTI إلى المخطط الزمني:

مثال على تتبُّع تحميل الصفحة مع FCP وTTI

ربما لاحظت أنّه هناك قدرًا كبيرًا من الوقت (بما في ذلك ثلاث مهام طويلة) بين FCP وTTI. إذا حاول المستخدم التفاعل مع الصفحة خلال ذلك الوقت (على سبيل المثال، من خلال النقر على رابط)، سيكون هناك تأخير بين وقت تلقّي النقرة ووقت تمكّن سلسلة التعليمات الرئيسية من الاستجابة.

لنفترض أنّ المستخدم حاول التفاعل مع الصفحة بالقرب من بداية أطول مهمة:

مثال على تتبُّع تحميل الصفحة مع سرعة عرض أوّل محتوى مرئي ومهلة الاستجابة لأوّل إدخال ووقت التفاعل

بما أنّ الإدخال يحدث أثناء تشغيل المتصفّح لمهمة، يجب أن ينتظر حتى تكتمل المهمة قبل أن يتمكّن من الاستجابة للإدخال. الوقت الذي يجب أن ينتظره هو قيمة FID لهذا المستخدم على هذه الصفحة.

ماذا لو لم يكن للتفاعل متتبِّع أحداث؟

يقيس FID الفرق بين وقت تلقّي حدث إدخال ووقت عدم انشغال سلسلة التعليمات الرئيسية بعد ذلك. هذا يعني أنّه يتم قياس FID حتى في الحالات التي لم يتم فيها تسجيل مستمع أحداث. السبب هو أنّ العديد من تفاعلات المستخدمين لا تتطلب مستمع أحداث، ولكنّها تتطلب عدم انشغال سلسلة التعليمات الرئيسية لتشغيلها.

على سبيل المثال، يجب أن تنتظر جميع عناصر HTML التالية اكتمال المهام قيد التنفيذ على سلسلة التعليمات الرئيسية قبل الاستجابة لتفاعلات المستخدمين:

حقول النص ومربّعات الاختيار والأزرار الدائرية (<input> و<textarea>)
القوائم المنسدلة للاختيار (<select>)
الروابط (<a>)

لماذا يتم أخذ الإدخال الأول فقط في الاعتبار؟

على الرغم من أنّ التأخير الناتج عن أي إدخال يمكن أن يؤدي إلى تجربة سيئة للمستخدم، فإنّنا ننصح في المقام الأول بقياس تأخير الاستجابة لأوّل إدخال لعدة أسباب:

سيكون تأخير الاستجابة لأوّل إدخال هو الانطباع الأول لدى المستخدم عن مدى استجابة موقعك الإلكتروني، وتكون الانطباعات الأولى مهمة في تشكيل انطباعنا العام عن جودة الموقع الإلكتروني وموثوقيته.
تحدث أكبر مشاكل التفاعل التي نراها على الويب اليوم أثناء تحميل الصفحة. لذلك، نعتقد أنّ التركيز في البداية على تحسين تفاعل المستخدم الجديد مع الموقع الإلكتروني سيؤثر بشكل كبير في تحسين التفاعل العام على الويب.
إنّ الحلول المقترَحة لكيفية معالجة المواقع الإلكترونية لحالات تأخير الاستجابة لأوّل إدخال الطويلة (تقسيم الرمز، وتحميل قدر أقل من JavaScript مقدمًا، وما إلى ذلك) ليست بالضرورة الحلول نفسها لمعالجة حالات تأخير الاستجابة للإدخال البطيئة بعد تحميل الصفحة. من خلال فصل هذه المقاييس، سنتمكّن من تقديم إرشادات أداء أكثر تحديدًا لمطوّري الويب.

ما الذي يتم احتسابه كأوّل إدخال؟

FID هو مقياس يقيس مدى استجابة الصفحة أثناء التحميل. على هذا النحو، يركّز فقط على أحداث الإدخال من الإجراءات المنفصلة، مثل النقرات والنقر والضغط على المفاتيح.

إنّ التفاعلات الأخرى، مثل التمرير والتكبير/التصغير، هي إجراءات مستمرة ولها قيود أداء مختلفة تمامًا (بالإضافة إلى ذلك، غالبًا ما تتمكّن المتصفّحات من إخفاء وقت الاستجابة من خلال تشغيلها على سلسلة تعليمات منفصلة).

بعبارة أخرى، يركّز FID على الاستجابة (R) في نموذج أداء RAIL performance model، في حين أنّ التمرير والتكبير/التصغير مرتبطان أكثر بالرسوم المتحركة (A)، ويجب تقييم خصائص أدائهما بشكل منفصل.

ماذا لو لم يتفاعل المستخدم مطلقًا مع موقعك الإلكتروني؟

لن يتفاعل بعض المستخدمين مع موقعك الإلكتروني في كل مرة يزورونه. وليست كل التفاعلات ذات صلة بـ FID (كما هو مذكور في القسم السابق). بالإضافة إلى ذلك، ستحدث بعض التفاعلات الأولى للمستخدمين في أوقات سيئة (عندما تكون سلسلة التعليمات الرئيسية مشغولة لفترة طويلة)، وستحدث بعض التفاعلات الأولى للمستخدمين في أوقات جيدة (عندما تكون سلسلة التعليمات الرئيسية غير مستخدمة من قِبل أي برنامج حاليًا).

هذا يعني أنّه لن يكون لدى بعض المستخدمين أي قيم FID، وسيكون لدى بعض المستخدمين قيم FID منخفضة، ومن المحتمل أن يكون لدى بعض المستخدمين قيم FID عالية.

من المحتمل أن تكون طريقة تتبُّع FID وإعداد تقارير عنه وتحليله مختلفة تمامًا عن المقاييس الأخرى التي قد تكون معتادًا عليها. يوضّح القسم التالي أفضل طريقة لإجراء ذلك.

لماذا يتم أخذ تأخير الإدخال فقط في الاعتبار؟

كما ذكرنا أعلاه، لا يقيس FID سوى "التأخير" في معالجة الأحداث. ولا يقيس إجمالي مدة معالجة الحدث نفسه، ولا الوقت الذي يستغرقه المتصفّح لتحديث واجهة المستخدم بعد تشغيل معالِجات الأحداث.

على الرغم من أنّ هذا الوقت مهم للمستخدم ويؤثر في التجربة، فإنّه لا يتم تضمينه في هذا المقياس لأنّ ذلك قد يشجّع المطوّرين على إضافة حلول بديلة تجعل التجربة أسوأ في الواقع، أي يمكنهم تضمين منطق معالِج الأحداث في ردّ غير متزامن (من خلال setTimeout() أو requestAnimationFrame()) لفصله عن المهمة المرتبطة بالحدث. ستكون النتيجة تحسينًا في نتيجة المقياس ولكن استجابة أبطأ كما يراها المستخدم.

ومع ذلك، على الرغم من أنّ FID لا يقيس سوى جزء "التأخير" من وقت استجابة الحدث، يمكن للمطوّرين الذين يريدون تتبُّع المزيد من دورة حياة الحدث إجراء ذلك باستخدام Event Timing API. لمزيد من التفاصيل، يُرجى الاطّلاع على دليل المقاييس المخصّصة.

كيفية قياس FID

FID هو مقياس لا يمكن قياسه إلا في الحقل، لأنّه يتطلب تفاعل مستخدم حقيقي مع صفحتك. يمكنك قياس FID باستخدام الأدوات التالية.

أدوات الحقل

قياس FID في JavaScript

لقياس FID في JavaScript، يمكنك استخدام الـ Event Timing API. يوضّح المثال التالي كيفية إنشاء إنشاء 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 في وحدة التحكّم وحساب تأخيرها. ومع ذلك، فإنّ قياس FID في JavaScript أكثر تعقيدًا. إليك التفاصيل أدناه:

في المثال أعلاه، يتم قياس قيمة التأخير لإدخال first-input من خلال أخذ الفرق بين الطابعَين الزمنيَين startTime وprocessingStart للإدخال. في معظم الحالات، ستكون هذه هي قيمة FID، ولكن ليست جميع إدخالات first-input صالحة لقياس FID.

يسرد القسم التالي الاختلافات بين ما تعرضه واجهة برمجة التطبيقات وكيفية احتساب المقياس.

الاختلافات بين المقياس وواجهة برمجة التطبيقات

سترسل واجهة برمجة التطبيقات إدخالات first-input للصفحات التي يتم تحميلها في علامة تبويب في الخلفية، ولكن يجب تجاهل هذه الصفحات عند احتساب FID.
سترسل واجهة برمجة التطبيقات أيضًا إدخالات first-input إذا تم نقل الصفحة إلى الخلفية قبل حدوث الإدخال الأول، ولكن يجب أيضًا تجاهل هذه الصفحات عند احتساب FID (لا يتم أخذ الإدخالات في الاعتبار إلا إذا كانت الصفحة في المقدّمة طوال الوقت).
لا تعرض واجهة برمجة التطبيقات إدخالات first-input عند استعادة الصفحة من ميزة "التخزين المؤقت للصفحات"، ولكن يجب قياس مهلة الاستجابة الأولى (FID) في هذه الحالات لأنّ المستخدمين يعتبرونها زيارات مختلفة للصفحة.
لا تعرض واجهة برمجة التطبيقات الإدخالات التي تحدث داخل عناصر iframe، ولكنّ المقياس يعرضها لأنّها جزء من تجربة المستخدم للصفحة. يمكن أن يظهر ذلك كفرق بين CrUX وRUM. لقياس FID بشكل صحيح، عليك أخذها في الاعتبار. يمكن أن تستخدم الإطارات الفرعية واجهة برمجة التطبيقات لإرسال إدخالات first-input إلى الإطار الرئيسي لتجميعها.

تحليل بيانات FID وإعداد تقارير عنها

نظرًا إلى التباين المتوقّع في قيم FID، من المهم عند إعداد تقارير عن FID الاطّلاع على توزيع القيم والتركيز على النسب المئوية الأعلى.

على الرغم من أنّ اختيار النسبة المئوية لجميع الحدود القصوى لمقاييس Core Web Vitals هو النسبة المئوية الـ 75، فإنّنا لا نزال ننصح بشدة بالاطّلاع على النسب المئوية من 95 إلى 99، لأنّها ستتوافق مع التجارب الأولى السيئة بشكل خاص التي يواجهها المستخدمون مع موقعك الإلكتروني. وسيظهر لك ذلك المجالات التي تحتاج إلى أكبر قدر من التحسين.

ينطبق ذلك حتى إذا قسّمت تقاريرك حسب فئة الجهاز أو نوعه. على سبيل المثال، إذا كنت تُجري تقارير منفصلة لأجهزة الكمبيوتر المكتبي والأجهزة الجوّالة، يجب أن تكون قيمة FID التي تهتم بها أكثر على أجهزة الكمبيوتر المكتبي هي النسبة المئوية من 95 إلى 99 لمستخدمي أجهزة الكمبيوتر المكتبي، وقيمة FID التي تهتم بها أكثر على الأجهزة الجوّالة هي النسبة المئوية من 95 إلى 99 لمستخدمي الأجهزة الجوّالة.

كيفية تحسين FID

يتوفّر دليل كامل عن تحسين FID لإرشادك خلال تقنيات تحسين هذا المقياس.

سجلّ التغييرات

في بعض الأحيان، يتم اكتشاف أخطاء في واجهات برمجة التطبيقات المستخدَمة لقياس المقاييس، وأحيانًا في تعريفات المقاييس نفسها. نتيجةً لذلك، يجب أحيانًا إجراء تغييرات، ويمكن أن تظهر هذه التغييرات على شكل تحسينات أو تراجعات في تقاريرك ولوحات البيانات الداخلية.

لمساعدتك في إدارة ذلك، سيتم عرض جميع التغييرات التي يتم إجراؤها على تنفيذ هذه المقاييس أو تعريفها في سجلّ التغييرات هذا .

إذا كان لديك ملاحظات عن هذه المقاييس، يمكنك تقديمها في مجموعة web-vitals-feedback على Google.