تضغط على زر في موقع ما ولا يحدث شيء لثانية أو ثانيتين. هذه اللحظة المزعجة الصغيرة لها اسم: First Input Delay. ورغم أن معظم الناس يظنون أنها مشكلة JavaScript، فالحقيقة أن قوة معالجة خادم الاستضافة لديك تلعب دورًا أكبر بكثير مما يدركه معظم المطورين.
إذا كنت تسعى لإعداد استضافة أفضل تحسّن Core Web Vitals في الاستضافة لرفع نتائجك، فإن فهم المصدر الحقيقي لـ FID سيوفر عليك ساعات من ملاحقة الحل الخاطئ.
ما الذي يقيسه First Input Delay فعليًا
يتتبع First Input Delay الزمن الفاصل بين أول تفاعل للمستخدم (نقرة، لمسة، ضغطة مفتاح) واللحظة التي يصبح فيها الخيط الرئيسي (main thread) في المتصفح حرًا فعليًا للاستجابة. تعتبر Google أي رقم أقل من 100 مللي ثانية جيدًا، و100-300 مللي ثانية يحتاج إلى تحسين، وأي شيء أعلى من 300 مللي ثانية ضعيف.
هنا الجزء الذي يغفل عنه كثيرون: FID لا يقيس سرعة تنفيذ JavaScript لديك. بل يقيس مدى انشغال الخيط الرئيسي في المتصفح عندما يحاول المستخدم التفاعل. فإذا كان الخيط مشغولاً بتحليل حزمة JavaScript ضخمة أو ينتظر استجابة بطيئة من الخادم لعرض المحتوى، فإن نقرة المستخدم تبقى ببساطة في طابور الانتظار.
يُذكر أن Google استبدلت FID بمقياس Interaction to Next Paint (INP) كمقياس Core Web Vital الرسمي. لكن الدرس الأساسي يبقى نفسه: الاستجابة تعتمد على ما يحدث في المتصفح وعلى الخادم معًا قبل أن تصبح الصفحة قابلة للتفاعل أصلاً.
لماذا الخادم أهم مما تظن
الخادم البطيء يؤخر كل شيء لاحقًا. إذا كان Time to First Byte لديك عند 800 مللي ثانية بدلاً من 200، فإن المتصفح لن يبدأ حتى في بناء الصفحة إلى أن تصل تلك الاستجابة. وهذا يؤخر عملية التحليل والعرض، واللحظة التي يصبح فيها الخيط الرئيسي حرًا للتعامل مع إدخال المستخدم.
تخيلها سلسلة من ردود الفعل:
- استجابة خادم بطيئة تؤخر تسليم HTML
- تأخر HTML يؤخر تحليل CSS وJS
- تأخر التحليل يبقي الخيط الرئيسي مشغولًا لفترة أطول
- خيط رئيسي مشغول يعني أن نقرتك أو لمستك تنتظر في الطابور
سبق أن كتبنا عن لماذا يكلفك Time to First Byte تحويلات وكيف تصلحه، وتنطبق الآلية نفسها هنا. سرعة الخادم ليست قضية منفصلة عن استجابة الإدخال، بل هي حجر الدومينو الأول.
قوة المعالج ومعالجة PHP خلف الكواليس
إذا كنت تدير WordPress أو WooCommerce أو أي نظام إدارة محتوى ديناميكي، فعادة ما يُطلق كل طلب صفحة تنفيذ PHP واستعلامات قاعدة بيانات وأحيانًا معالجة على مستوى الإضافات قبل أن يرسل الخادم أي شيء. كل هذا يحدث على معالج (CPU) خادمك.
على خادم مشترك ضعيف الإمكانيات أو مُباع أكثر من طاقته، قد تتنافس عمليات PHP-FPM لديك مع عشرات المواقع الأخرى على نفس دورات المعالج. وهذا يعني:
- وقت تنفيذ أبطأ لكل طلب PHP
- أوقات انتظار أطول في طابور المعالجة خلال ذروة الزيارات
- استعلامات قاعدة بيانات تنتظر توفر المعالج
- أوقات استجابة غير مستقرة ترتفع تحت الضغط
تناولنا آلية هذا الأمر في كيف يؤثر إعداد مجمع PHP-FPM على استجابة خادمك تحت الضغط. باختصار: إذا كان مجمع العمليات لديك غير مضبوط بشكل صحيح أو كان المعالج يعمل بأقصى طاقته، فإن كل طلب يستغرق وقتًا أطول للمعالجة، وهذا التأخير ينعكس على سرعة أن تصبح الصفحة قابلة للاستخدام للزائر.
اتصال قاعدة البيانات الذي ربما لا تفكر فيه
الاستعلامات البطيئة تضيف مللي ثوانٍ حقيقية لوقت معالجة الخادم. صفحة منتج تشغّل 40 استعلامًا غير محسّن على خادم قاعدة بيانات ضعيف يمكن أن تضيف بسهولة 300-500 مللي ثانية لوقت استجابتك. اضرب هذا الرقم في عدد الزوار المتزامنين، وستحصل على خادم متأخر باستمرار، ما يعني استجابات أبطأ واستجابة إدخال أسوأ من حيث إدراك المستخدم لكل من يزور الموقع في الوقت نفسه.
فهرسة الأعمدة الصحيحة، وتخزين نتائج الاستعلامات المتكررة مؤقتًا، واستخدام تجميع الاتصالات (connection pooling)، كلها أمور تقلل عمل المعالج الذي يجب على خادمك القيام به لكل طلب. عمل أقل للمعالج لكل طلب يعني مساحة أكبر عند وصول حركة مرور حقيقية.
كيف يقلل التخزين المؤقت الضغط على معالجك
يوجد التخزين المؤقت الكامل للصفحة (full-page caching) والتخزين المؤقت للكائنات (object caching) خصيصًا لتخفيف الضغط عن معالجك. فبدلاً من تشغيل PHP والوصول إلى قاعدة البيانات مع كل طلب، تُقدَّم الاستجابة المخزنة مؤقتًا بشكل شبه فوري مباشرة من الذاكرة.
التخزين المؤقت للكائنات القائم على Redis مثال جيد على ذلك. فهو يخزن نتائج استعلامات قاعدة البيانات المتكررة في الذاكرة، فيتجنب خادمك رحلة الذهاب والإياب المكلفة إلى قاعدة البيانات لأشياء سبق حسابها. لاحظنا أن مواقع WordPress تقلص وقت استعلام قاعدة البيانات بشكل كبير بعد تفعيل التخزين المؤقت للكائنات، لأن المعالج ببساطة يصبح لديه عمل أقل.
إذا أردت نظرة أعمق حول كيفية إعداد هذا بشكل صحيح، فقد تناولناه في كيف تُعدّ Redis caching على خادمك دون أن تفسد شيئًا.
كيف تبدو استضافة جيدة تحسّن Core Web Vitals
عندما يبحث الناس عن استضافة تحسّن Core Web Vitals في الاستضافة، فهم عادة يبحثون عن مزود يتقن الأساسيات قبل أن يلمسوا الكود أصلاً. وهذا يعني:
- مساحة كافية من المعالج لكل موقع، وليس موارد مشتركة مُباعة أكثر من طاقتها
- تخزين NVMe لإدخال وإخراج أقراص أسرع أثناء تنفيذ الاستعلامات
- مجمعات عمال PHP-FPM مضبوطة بشكل صحيح تتوسع مع حركة المرور
- تخزين مؤقت على مستوى الخادم متوفر جاهزًا للاستخدام
- مراقبة ترصد ارتفاعات المعالج قبل أن تتحول إلى استجابات بطيئة
الاستضافة المُدارة التي تراقب استخدام موارد الخادم بشكل استباقي يمكنها اكتشاف اختناق المعالج قبل أن يظهر كنتيجة سيئة لـ FID أو INP في تقرير Search Console لديك. ولهذا السبب نراقب توزيع الموارد عبر خوادمنا بدلاً من مجرد بيع رقم على ورقة مواصفات.
ما يمكنك فعله فعليًا حيال ذلك
إذا كان تقرير Core Web Vitals لديك يُظهر نتائج استجابة ضعيفة، فلا تبدأ بإعادة كتابة JavaScript. ابدأ من هنا بدلاً من ذلك:
- تحقق من متوسط وقت استجابة خادمك تحت حركة مرور حقيقية، وليس فقط في اختبار خامل
- انظر إلى أبطأ استعلامات قاعدة بياناتك وأضف فهارس حيث يلزم
- فعّل التخزين المؤقت للكائنات إذا كان نظام إدارة المحتوى لديك يدعمه
- تأكد من أن مجمع عمال PHP لديك لا يعمل بأقصى طاقته خلال ساعات الذروة
- فكّر فيما إذا كانت خطتك الحالية تمنحك موارد معالج مخصصة أم مشتركة
تناولنا الصورة الأوسع في Core Web Vitals والاستضافة: لماذا خادمك إما يساعد نتائجك أو يضرها، وهو مقال يكمّل هذا الموضوع إذا أردت الصورة الكاملة بعيدًا عن تأخير الإدخال فقط.
الخلاصة
يبدو First Input Delay مشكلة واجهة أمامية لأنه يظهر في المتصفح. لكن جزءًا كبيرًا مما يسببه يحدث قبل أن تحصل الصفحة حتى على فرصة العرض في المتصفح. قوة معالج الخادم، وكفاءة معالجة PHP، ووقت استجابة قاعدة البيانات، كلها تغذي مباشرة سرعة أن تصبح صفحتك قابلة للتفاعل.
إذا كنت قد حسّنت حجم حزمة JavaScript لديك وما زلت ترى نتائج استجابة ضعيفة، فيستحق الأمر النظر إلى خادمك، لا إلى كودك. أحيانًا الحل الأسرع ليس سطر كود على الإطلاق، بل ببساطة الانتقال إلى استضافة تمنح موقعك مساحة المعالجة التي يحتاجها فعلاً.
