تأخر الإدخال الأول (FID)

الخلاصة — كان First Input Delay (FID) مقياسًا قديمًا. كان يقيس مدة انتظار الصفحة قبل أن تبدأ حتى في الاستجابة للنقرة أو اللمسة الأولى. تقاعدت Google عنه في مارس 2024 واستبدلته بـ INP، ثم أزالته من أدواتها بالكامل في سبتمبر 2024. لذلك لم يعد هناك ما يمكن إصلاحه هنا — لكن من المفيد معرفة ما كان يعنيه إذا صادفت “FID” في تقارير قديمة.

ما الذي كان يقيسه First Input Delay

عندما تضغط زرًا ولا يحدث شيء للحظة، تبدو الصفحة معطلة — حتى لو بدت محمّلة. كان First Input Delay (FID) طريقة Google لوضع رقم على ذلك الإحساس المحدد بالإحباط.

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

شيئان لم يكن يقيسهما:

• مدة تشغيل كود الزر بعد أن بدأ.
• المدة التي استغرقتها الصفحة للتحديث بصريًا بعد ذلك.

كان يقيس الانتظار قبل أن يبدأ أي شيء فحسب. وهذا الضيق سبب كبير لاستبداله في النهاية.

ما الذي كان يُعد نتيجة جيدة

كان FID يُقاس بالمللي ثانية:

• جيد: 100 مللي ثانية أو أقل
• بحاجة إلى تحسين: 100–300 مللي ثانية
• ضعيف: أكثر من 300 مللي ثانية

لماذا لا تحتاج إلى القلق بشأنه بعد الآن

إليك الجزء المهم لمن يقرأ هذا في 2026: لقد تقاعد FID. استبدلته Google كمؤشر ويب أساسي بـ INP (Interaction to Next Paint) في 12 مارس 2024 — وتوقفت Search Console عن عرض FID في اليوم نفسه. واصلت PageSpeed Insights وCrUX API الإبلاغ عنه مدة أطول قليلًا، ثم أزالته في 9 سبتمبر 2024. إذا كان درس تعليمي أو لوحة معلومات قديمة ما تزال تعرض FID كمؤشر ويب أساسي حالي، فهذا المحتوى قديم.

ينجز INP المهمة نفسها بصورة أفضل: فبدل توقيت انتظار التفاعل الأول فقط، يقيس الاستجابة الكاملة لكل تفاعل خلال الزيارة. إذا كنت تحاول جعل موقعك سريع الاستجابة اليوم، فراقب INP لا FID.

هل تريد التاريخ الكامل — الحدود الدقيقة، وسبب تصميم FID بهذا التضييق، ومكان بقاء بيانات FID القديمة، وكيف يرتبط بـ INP — فانتقل إلى علامة التبويب Advanced.

الخلاصة — كان FID مؤشر الويب الأساسي للاستجابة حتى استبدله INP في 12 مارس 2024 — وهو تاريخ إزالة Search Console له من تقريرها أيضًا. واصلت أدوات Chrome وPageSpeed Insights وCrUX API المباشرة دعمه مدة أطول قليلًا، ثم أوقفته في 9 سبتمبر 2024، كل منها وفق جدوله الخاص. كان يقيس تأخر الإدخال للتفاعل الأول فقط — لا وقت تشغيل المعالج ولا إعادة الرسم — عمدًا لتجنب الحوافز العكسية. الحدود: جيد ≤100 مللي ثانية، ضعيف >300 مللي ثانية عند p75، وقياس ميداني فقط (كان Total Blocking Time بديل المختبر — تشخيصًا مرتبطًا لا معادلة تحويل). لا تخلط هذه الحدود بحدود INP البالغة 200/500 مللي ثانية، ولا تحاول تحويل رقم أحد المقياسين إلى الآخر. كان ضعف FID ناتجًا عن تنافس الخيط الرئيسي — مهام JavaScript طويلة — وهو السبب نفسه لضعف INP وTBT، لذلك ما تزال الإصلاحات القديمة مفيدة. ما تزال بيانات FID التاريخية في مجموعة بيانات CrUX BigQuery (حتى إصدار 202409)، وقد اختفت من كل الأدوات المباشرة.

ما الذي كان FID يقيسه فعلًا

كان تعريف Google دقيقًا. وفق web.dev: “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” (ترجمة) «يقيس FID الوقت من تفاعل المستخدم الأول مع الصفحة (أي عند النقر على رابط أو الضغط على زر أو استخدام عنصر تحكم مخصص يعمل بـJavaScript) إلى أن يصبح المتصفح قادرًا فعلًا على بدء معالجة معالجات الأحداث استجابةً لذلك التفاعل.»

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

لماذا كان المتصفح غير قادر على “البدء” أصلًا؟ يوضح web.dev السبب بصراحة: “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” (ترجمة) «يحدث تأخر الإدخال (ويُسمى أيضًا زمن استجابة الإدخال) عمومًا لأن الخيط الرئيسي للمتصفح مشغول بشيء آخر، فلا يستطيع (بعد) الاستجابة للمستخدم.» يوجد خيط رئيسي واحد، وإذا كان في منتصف تحليل JavaScript أو تنفيذه عندما يتفاعل المستخدم، يبقى التفاعل في قائمة الانتظار حتى تنتهي تلك المهمة. وأوضح النقطة نفسها في دليلي عن FID في Ahrefs: يوجد خيط رئيسي واحد فقط، وتتنافس JavaScript على تشغيل المهام فيه، وطوال تشغيل المهمة لا تستطيع الصفحة الاستجابة للإدخال؛ وهذا التوقف هو التأخر الذي يشعر به المستخدم فعلًا.

لماذا كان FID يقيس التأخر فقط (لا التفاعل كاملًا)

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

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

الحدود — والخطأ الذي ستراه الناس يرتكبونه

كان القياس عند المئين الخامس والسبعين من تحميلات الصفحة، مع الفصل بين الهاتف المحمول وسطح المكتب. وكانت إرشادات web.dev ببساطة أن تسعى المواقع إلى FID يبلغ 100 مللي ثانية أو أقل. وتستخدم مقالتي عن FID الأرقام نفسها — جيد ≤100 مللي ثانية، وبحاجة إلى تحسين >100 مللي ثانية و≤300 مللي ثانية، وضعيف >300 مللي ثانية.

الخطأ الشائع: الخلط بين حدود FID وحدود INP. إنها أرقام مختلفة لمقياسين مختلفين. FID = جيد عند 100 مللي ثانية / ضعيف عند 300 مللي ثانية. INP = جيد عند 200 مللي ثانية / ضعيف عند 500 مللي ثانية. تخلط عدة ملخصات من جهات خارجية — وحتى عمليات محتوى آلية — بينهما، لذلك إذا رأيت “200 مللي ثانية” مذكورة بوصفها حد FID الجيد، فهي خاطئة.

كان FID مقياسًا ميدانيًا فقط

لم يكن ممكنًا الحصول على FID من Lighthouse أو أي أداة مختبر، لأنه يتطلب تفاعلًا أول حقيقيًا من مستخدم حقيقي — ويوضح web.dev أن FID مقياس لا يمكن قياسه إلا ميدانيًا، إذ يتطلب تفاعل مستخدم حقيقي مع صفحتك. لا تنقر أدوات المختبر، لذلك لم يكن هناك شيء يمكن لـ FID توقيته.

كان البديل المختبري دائمًا Total Blocking Time (TBT). وكما شرحت في دليلي عن PageSpeed Insights، لن تجد FID أو INP في بيانات المختبر — فهما يتطلبان نقرات على الصفحة لا تعيدها اختبارات المختبر — ولذلك تستخدم Total Blocking Time مقياسًا بديلًا تعمل على تحسينه. وقد استمرت هذه العلاقة بعد تقاعد FID: فما يزال TBT هو البديل المختبري لـ INP.

هناك حارس واحد يستحق التصريح به: TBT تشخيص مرتبط، وليس معادلة تحويل. لم توجد قط معادلة تحول رقم TBT إلى رقم FID دقيق، ولا توجد واحدة لـ INP أيضًا — فالنتيجة السيئة لـ TBT تخبرك بأن عمل الخيط الرئيسي سبب محتمل، لا بما كانت ستؤول إليه قيمة FID أو INP الميدانية.

لماذا تقاعد FID: انتقال INP

أُعلن عن بديل FID قبل وقت طويل. وفق web.dev، أصبح INP رسميًا مؤشر ويب أساسيًا واستبدل FID في 12 مارس 2024، وعندها أُهمل FID وأُزيل من البرنامج. وكان سبب Google المعلن هو أنه اتضح مع مرور الوقت أن هناك حاجة إلى مقياس جديد يلتقط جوانب التفاعلية التي لم يلتقطها FID.

كان للجدول الزمني محطتان منفصلتان — ومن المفيد إبقاؤهما واضحتين، لأن من السهل والشائع، حتى في المحتوى الآلي، دمجهما في تاريخ واحد:

1. 12 مارس 2024 — التقاعد كمؤشر ويب أساسي. تولى INP المهمة؛ ولم يعد FID جزءًا من المجموعة الأساسية ذات الصلة بالترتيب. وأزالت Search Console مقياس FID من تقرير مؤشرات الويب الأساسية في اليوم نفسه.
2. 9 سبتمبر 2024 — الإزالة من الأدوات وفق جداول خاصة بالمنتج. وفق web.dev، لم يعد FID مدعومًا في أدوات Chrome اعتبارًا من ذلك التاريخ. وتوقفت PageSpeed Insights عن عرض بيانات FID من المستخدمين الحقيقيين، وأوقفت CrUX API تقديم المقياس مستقبلًا؛ كما توقفت مجموعة بيانات CrUX BigQuery عن إضافة حقول FID جديدة بدءًا من إصدار 202409، مع بقاء الأشهر السابقة قابلة للاستعلام.

ليس دقيقًا القول إن كل واجهة من Google أزالت FID في 9 سبتمبر — فقد كان حد Search Console قبل ذلك بستة أشهر، مرتبطًا باستبدال INP له، لا بتنظيف الأدوات اللاحق.

تبدأ مقالة FID نفسها على web.dev الآن بإشعار التقاعد: لم يعد First Input Delay مؤشر ويب أساسيًا، واستُبدل بمقياس Interaction to Next Paint (INP). كما أن وثائق Google Search Central الحالية لمؤشرات الويب الأساسية لا تذكر FID أصلًا — فهي تغطي LCP وINP وCLS فقط. عندما تتوقف وثيقة الترتيب الرسمية عن تسمية مقياس، فذلك أقرب ما يكون إلى تقاعده.

FID مقابل INP: ما الذي تغير

يقيس المقياسان أشياء مختلفة فعلًا، ولهذا لا يمكنك إسقاط أحدهما على الآخر ببساطة:

الخيط الناظم هو أن FID كان يوقّت الباب الأمامي لتفاعل واحد، بينما يوقّت INP الرحلة كاملة لكل تفاعل. لا توجد معادلة تحول رقم FID قديمًا إلى رقم INP مكافئ، كما أن FID لصفحة ما مقارنة بصفحات أخرى لا يتنبأ بترتيب INP للصفحات نفسها — فهما يقيسان مجموعتي تفاعل مختلفتين مقابل نقطتي نهاية مختلفتين، وأي تشابه بين الرقمين في صفحة معينة محض مصادفة لا قاعدة. راجع Interaction to Next Paint للشرح الكامل للمقياس الذي حل محله.

أين توجد بيانات FID القديمة

لم يؤدِّ التقاعد إلى تبخر السجل التاريخي. إليك ما اختفى مقابل ما بقي:

• اختفى (مباشر/حالي): أزال تقرير مؤشرات الويب الأساسية في Search Console مقياس FID في 12 مارس 2024، يوم تولي INP المهمة. واصلت واجهة PageSpeed Insights وCrUX API المباشرة الإبلاغ عنه مدة أطول قليلًا، ثم توقفتا في 9 سبتمبر 2024.
• ما يزال موجودًا (تاريخي): تظل بيانات FID قبل الحد الفاصل قابلة للاستعلام في مجموعة بيانات CrUX BigQuery العامة — لكن حتى مجموعة بيانات 202409 فقط؛ فقد توقفت BigQuery عن إضافة حقول FID جديدة بدءًا من ذلك الإصدار، مع بقاء الأشهر السابقة. إذا احتجت إلى إعادة بناء تاريخ الاستجابة القديم لموقع، فهناك تبحث — لا في الأدوات المباشرة. ثبّت شهر مجموعة البيانات عند الاستشهاد برقم، وسمّه تاريخيًا، ولا تعامل رقم FID قديمًا على أنه قابل للمقارنة عدديًا مع رقم INP حالي — فلا تحويل بينهما (راجع جدول المقارنة أعلاه).

هل ما يزال FID مهمًا اليوم؟

مباشرةً، لا — فلا شيء بقي لقياسه أو الإبلاغ عنه، وبالتالي لا شيء “لإصلاحه”. لكن أسباب ضعف FID وأسباب ضعف INP متطابقة تقريبًا: مهام JavaScript طويلة تستحوذ على الخيط الرئيسي. لذلك لم يذهب العمل الذي أنجزته لتحسين FID هباءً. وكما أشير في دليلي عن FID، رغم استبدال FID بـ INP في مارس 2024، ما يزال العمل على المشكلات الأساسية نفسها جديرًا بالاهتمام — فكثير من الأشياء التي تحسن TBT وFID تحسن INP أيضًا.

الإصلاحات التي خفّضت FID هي نفسها التي تساعد INP وTBT الآن:

• قلّل كمية JavaScript التي تشحنها.
• حمّل JavaScript لاحقًا حيثما أمكن (async/defer).
• قسّم المهام الطويلة باستخدام تقسيم الكود حتى لا تحتكر مهمة واحدة الخيط الرئيسي.
• انقل العمل خارج الخيط الرئيسي باستخدام عمال الويب.
• استخدم التصيير من جهة الخادم أو التصيير المسبق لتقليل العمل على العميل.

هل كان FID عامل ترتيب كبيرًا؟

حتى أثناء نشاطه، لم يكن FID — بوصفه جزءًا من مؤشرات الويب الأساسية — إشارة ترتيب قوية قط. وقد وصف ممثلو Google مؤشرات الويب الأساسية مرارًا بأنها أقرب إلى كاسر تعادل منها إلى إشارة أساسية، ولا تُطبق إلا عندما تكون الأمور الأخرى متقاربة تقريبًا. وقراءتي الشخصية، من دليلي عن مؤشرات الويب الأساسية، هي نفسها: “I don’t think Core Web Vitals have much impact on SEO and, unless you are extremely slow, I generally won’t prioritize fixing them.” (ترجمة) «لا أعتقد أن لمؤشرات الويب الأساسية أثرًا كبيرًا في SEO، وما لم تكن بطيئًا للغاية فلن أعطي إصلاحها الأولوية عادةً.» نادرًا ما كان FID يُذكر منفردًا في تعليقات الممثلين، بل كان يُناقش دائمًا تقريبًا كجزء من حزمة مؤشرات الويب الأساسية، لا كأداة ترتيب مستقلة.

Bing وFID

لا توجد هنا زاوية خاصة بـBing عمليًا. فلم تعتمد Bing مؤشرات الويب الأساسية كإشارة ترتيب مسماة بالطريقة التي فعلتها Google، ولم تنشر حدود FID (أو INP) الخاصة بها. تهتم Bing بالصفحات السريعة وسريعة الاستجابة بوجه عام، لكن FID كان مقياسًا من منظومة Google من البداية إلى النهاية.

إلى أين تذهب بعد ذلك

يقع FID تحت مبادرة Web Vitals، في مجموعة Web Performance. المقاييس الأكثر صلة بـ FID هي:

• Interaction to Next Paint — مؤشر الويب الأساسي الذي حل محله، والذي ينبغي تحسينه فعلًا الآن.
• Total Blocking Time — البديل المختبري الذي حل محل FID (والآن يحل محل INP) عندما لا يمكنك قياس التفاعلات الحقيقية.
• Core Web Vitals — الثلاثي المرتبط بالترتيب (LCP وINP وCLS) الذي كان FID ينتمي إليه.

ملخص الذكاء الاصطناعي

خلاصة مركزة من النسخة المتقدمة:

• FID = مؤشر ويب أساسي متقاعد للاستجابة. كان يقيس تأخر الإدخال في التفاعل الأول فقط — الانتظار قبل أن يبدأ المتصفح معالجة معالج الحدث — لا وقت تشغيل المعالج ولا إعادة الرسم.
• الحدود: جيد ≤ 100 مللي ثانية، وبحاجة إلى تحسين 100–300 مللي ثانية، وضعيف > 300 مللي ثانية، عند المئين الخامس والسبعين، مع فصل الهاتف المحمول/سطح المكتب. ميداني فقط — لا يمكن قياسه قط في Lighthouse؛ وكان Total Blocking Time البديل المختبري.
• لا تخلط الحدود: FID = 100/300 مللي ثانية؛ INP = 200/500 مللي ثانية. مقياسان مختلفان، ورقمان مختلفان.
• سبب ضعف FID: تنافس الخيط الرئيسي — مهام JavaScript طويلة. السبب الجذري نفسه لضعف INP وTBT.
• الجدول الزمني للتقاعد: استبدله INP في 12 مارس 2024 — وهو اليوم نفسه الذي أزالت فيه Search Console مقياس FID من تقريرها. توقفت أدوات Chrome وPageSpeed Insights وCrUX API المباشرة عن دعمه في 9 سبتمبر 2024، كل منها وفق جدوله الخاص — وليس في حد فاصل عالمي واحد. لم تعد وثيقة Google Search Central الحالية لمؤشرات الويب الأساسية تذكره.
• FID مقابل INP: كان FID يوقّت تأخر التفاعل الأول؛ ويقيس INP الزمن الكامل لكل التفاعلات (التأخر + المعالجة + العرض). لا توجد معادلة تحول أحد الرقمين إلى الآخر.
• البيانات القديمة: اختفت من الأدوات المباشرة؛ وما تزال بيانات FID قبل الحد الفاصل في مجموعة بيانات CrUX BigQuery حتى إصدار 202409 — ثبّت شهر مجموعة البيانات ولا تقارنها عدديًا بـ INP الحالي.
• لا تحويل، أبدًا: TBT بديل مختبري مرتبط لـ FID وINP، وليس معادلة تترجم أحدهما إلى الآخر.
• هل ما يزال مهمًا؟ لا يوجد شيء لإصلاحه مباشرة، لكن إصلاحات JS (تقليل JS وتأجيله، وتقسيم المهام الطويلة، وعمال الويب، وSSR) تنتقل مباشرة إلى INP وTBT.
• وزن الترتيب: كان طفيفًا حتى أثناء النشاط — فقد صُوّرت مؤشرات الويب الأساسية ككاسر تعادل؛ ويقول Patrick: لا تعطها الأولوية إلا إذا كنت بطيئًا للغاية. ولا تملك Bing مقابلًا لـ FID.

الوثائق الرسمية

وثائق المصادر الأولية عن FID وتقاعده.

Google / web.dev

• تأخر الإدخال الأول (FID) — تعريف المقياس وحدوده وسبب قياس تأخر الإدخال فقط وإشعار التقاعد (Philip Walton؛ تحديث 2024-10-06).
• توقف Chrome عن دعم تأخر الإدخال الأول — الإزالة في سبتمبر 2024 من أدوات Chrome وPSI وCrUX API (Rick Viscomi).
• يصبح التفاعل مع الرسم التالي مؤشر ويب أساسيًا في 12 مارس — الإعلان عن استبدال INP لـ FID (Jeremy Wagner وRick Viscomi).
• فهم مؤشرات الويب الأساسية ونتائج بحث Google — وثيقة الترتيب الحالية التي تسرد LCP وINP وCLS فقط (ولا تذكر FID).
• التفاعل مع الرسم التالي (INP) — المقياس الذي استبدل FID.

MDN

• مسرد تأخر الإدخال الأول (FID) — تعريف مرجعي مختصر.

Bing / Microsoft

• لا يوجد مصدر خاص بـFID. لم تنشر Bing قط حدود FID أو تسمِّ مؤشرات الويب الأساسية إشارة ترتيب خاصة بها.

اقتباسات من المصدر

تصريحات مسجلة من وثائق Google الرسمية على web.dev. كل رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google / web.dev — ما الذي كان FID يقيسه

• “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” (ترجمة) «يقيس FID الوقت من تفاعل المستخدم الأول مع الصفحة (أي عند النقر على رابط أو الضغط على زر أو استخدام عنصر تحكم مخصص يعمل بـJavaScript) إلى أن يصبح المتصفح قادرًا فعلًا على بدء معالجة معالجات الأحداث استجابةً لذلك التفاعل.» الانتقال إلى الاقتباس
• “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” (ترجمة) «يحدث تأخر الإدخال عمومًا لأن الخيط الرئيسي للمتصفح مشغول بشيء آخر، فلا يستطيع (بعد) الاستجابة للمستخدم.» الانتقال إلى الاقتباس

Google / web.dev — حد “الجيد”

• “To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.” (ترجمة) «لتقديم تجربة مستخدم جيدة، ينبغي أن تسعى المواقع إلى جعل تأخر الإدخال الأول 100 مللي ثانية أو أقل.» الانتقال إلى الاقتباس

ورقة الغش الخاصة بـ First Input Delay

الحالة: متقاعد. احتفظ بهذا لقراءة البيانات التاريخية والتقارير القديمة — لا بوصفه هدفًا للتحسين.

FID في لمحة

FID مقابل INP — لا تخلط بينهما

التواريخ الأساسية

• 12 مارس 2024 — يستبدل INP مقياس FID كمؤشر ويب أساسي؛ وتزيل Search Console مقياس FID من تقريرها في اليوم نفسه.
• 9 سبتمبر 2024 — تتوقف أدوات Chrome وPageSpeed Insights وCrUX API المباشرة عن دعم FID، وفق جدولها الخاص (وليس التاريخ نفسه في GSC).

أين توجد بيانات FID الآن

• الأدوات المباشرة (واجهة PSI وGSC وCrUX API): اختفت (GSC منذ 12 مارس 2024؛ وPSI/CrUX منذ 9 سبتمبر 2024).
• السجل السابق للحد الفاصل: مجموعة بيانات CrUX BigQuery حتى إصدار 202409. لا تقارن أرقامها مباشرة بـ INP الحالي — فلا تحويل بينهما.

إصلاح المشكلة الأساسية (ما يساعد INP/TBT الآن)

• تقليل JavaScript · تحميل مؤجل/غير متزامن · تقسيم المهام الطويلة (تقسيم الكود) · عمال الويب · SSR/التصيير المسبق.

أخطاء يجب تجنبها مع بيانات FID القديمة

التعامل مع FID كمؤشر ويب أساسي حالي

استُبدل FID بـ INP في مارس 2024 وأُزيل من أسطح تقارير Chrome الحالية لاحقًا في ذلك العام. استخدم INP لأعمال الاستجابة الحالية، واحتفظ بـ FID فقط عند تفسير مجموعات البيانات التاريخية.

مقارنة FID وINP بالحدود نفسها

كانت حدود FID التاريخية للجيد/الضعيف 100/300 مللي ثانية؛ وحدود INP هي 200/500 مللي ثانية. الأرقام غير قابلة للتبادل لأن FID كان يقيس تأخر ما قبل المعالج فقط، بينما يغطي INP التفاعل حتى الرسم التالي.

البحث عن FID في اختبار مختبري

تطلب FID إدخالًا أول حقيقيًا من مستخدم حقيقي وكان ميدانيًا فقط. كان Total Blocking Time هو البديل المختبري؛ ولم تكن نتيجة Lighthouse ملاحظة مباشرة لـFID قط.

تحسين نتيجة متقاعدة بدلًا من مشكلة المستخدم

لا تجعل لوحة FID القديمة هدفًا. قسّم مهام الخيط الرئيسي الطويلة وقلل JavaScript الحاجب، ثم قِس الاستجابة الحالية باستخدام INP ميدانيًا.

اختبر نفسك: First Input Delay (FID)

خمسة أسئلة سريعة عما كان FID يقيسه وسبب تقاعده. اختر إجابة لكل سؤال، ثم تحقق.

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