تحسين INP في ووردبريس: دليل عملي خطوة بخطوة

الصور مضغوطة، والكاش شغال، وPageSpeed بيديك رقم محترم… بس Search Console لسه كاتب إن INP على الموبايل «ضعيف». المشكلة هنا مش في سرعة تحميل الصفحة، المشكلة في اللي بيحصل بعد ما الزائر يدوس على حاجة.

ما هو INP ولماذا لا يحله الكاش؟

زمن الاستجابة للتفاعل التالي (INP — Interaction to Next Paint) هو أحد مقاييس الأداء الأساسية (Core Web Vitals)، وحلّ رسمياً محل FID في 12 مارس 2024. يقيس الفترة بين تفاعل الزائر (نقرة، لمسة، ضغطة زر في لوحة المفاتيح) وظهور أول إطار يعكس نتيجة هذا التفاعل على الشاشة.

حدود Google ثابتة:

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

ولأن التفاعل يحدث بعد تحميل الصفحة، فإن التخزين المؤقت (Cache) وضغط الصور والـ CDN تحسّن LCP وTTFB، لكنها لا تجعل القائمة تستجيب أسرع. INP يعيش في طبقة الجافاسكربت.

مراحل التفاعل الثلاث: أين يضيع الوقت؟

بحسب وثائق web.dev، ينقسم كل تفاعل إلى ثلاث مراحل، ولكل منها علاج مختلف:

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

الخطوة 1: قِس INP بالشكل الصحيح

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

1. Google Search Console ← تقرير Core Web Vitals: هنا البيانات الميدانية (Field Data) من زوار Chrome الحقيقيين. إذا قال «ضعيف» فصدّقه.
2. PageSpeed Insights ← قسم بيانات المستخدمين الحقيقيين: يعرض INP من تقرير CrUX، وهو يجمع نحو 28 يوماً من الزيارات، فلن يظهر أثر إصلاحك فوراً.
3. Chrome DevTools ← لوحة Performance: ابدأ التسجيل، وافتح القائمة واضغط الأزرار واكتب في البحث، ثم أوقفه. ابحث عن المهام الطويلة (Long Tasks) على الخيط الرئيسي (Main Thread) واضغط على أي منها لترى السكربت المسؤول.
4. مكتبة web-vitals: للمطورين الذين يريدون إرسال INP إلى أداة التحليلات لمراقبة مستمرة.

تنبيه: لا تحكم على INP من جهازك المكتبي السريع. شريحة كبيرة من زوار المواقع في مصر والخليج تتصفح من هواتف أندرويد متوسطة، وعليها يستغرق السكربت نفسه أضعاف الوقت. فعّل CPU throttling في DevTools ليقترب الاختبار من الواقع.

الخطوة 2: حدد السكربتات المتهمة

بعد تسجيل Performance، افتح عرض Bottom-Up ورتّب حسب الوقت الكلي. ما يظهر في الأعلى هو قائمة المشتبه بهم. وفي ووردبريس يتكرر المتهمون أنفسهم تقريباً:

• جافاسكربت أدوات بناء الصفحات وتأثيرات الحركة فيها، حتى في صفحات لا تستخدم عناصرها.
• السلايدرات والنوافذ المنبثقة التي تُهيّأ عند التحميل سواء ظهرت أم لا.
• أزرار الدردشة والتضمينات الخارجية، ومنها أزرار واتساب وماسنجر المنتشرة في المواقع العربية.
• بكسلات التتبع مثل Facebook Pixel وTikTok Pixel، خصوصاً القديمة المنسية منها.
• نوافذ موافقة الكوكيز الثقيلة.
• سكربتات قوالب قديمة مكتوبة بـ jQuery لم تُحدّث منذ سنوات.
• عشرات الإضافات التي يضيف كل منها سكربتاً صغيراً، فتزدحم في المجموع.

ولقياس حجم شجرة الصفحة، افتح Console في DevTools ونفّذ:

document.getElementsByTagName('*').length

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

الخطوة 3: الإصلاحات بالترتيب الأعلى أثراً

1. خفّف وزن الجافاسكربت

كل كيلوبايت جافاسكربت هو عمل إضافي على هاتف الزائر. عطّل الإضافات (Plugins) التي لا تحتاجها، ثم ألغِ تحميل السكربتات في الصفحات التي لا تستخدمها بإضافات مثل Perfmatters أو Asset CleanUp: سكربت نموذج التواصل لا مكان له في كل مقال، وسكربت السلايدر لا مكان له في صفحة بلا سلايدر.

2. أجّل السكربتات غير الضرورية… بحذر

خيارا Defer (التحميل بعد عرض الصفحة) وDelay (التحميل عند أول تفاعل) موجودان في أغلب إضافات التسريع مثل WP Rocket وFlyingPress وLiteSpeed Cache. لكنهما سلاح ذو حدين: لو أخّرت سكربت القائمة أو البحث أو السلة، سيلمس الزائر الزر ولا يحدث شيء حتى يُحمَّل السكربت، وهذا بالضبط ما يعاقب عليه INP.

الطريقة الآمنة:

1. فعّل التأجيل للجافاسكربت عموماً.
2. استثنِ فوراً سكربتات القائمة والبحث والسلة والدفع وأزرار قبول الكوكيز والتحقق من النماذج.
3. اختبر كزائر غير مسجل على هاتف حقيقي: افتح القائمة، ابحث، أضف منتجاً للسلة. أي تردد يعني أن سكربتاً يحتاج إلى استثناء.

3. روّض السكربتات الخارجية

لا يمكنك تحسين كود الآخرين، لكن يمكنك التحكم في توقيت تحميله:

• أخّر أزرار الدردشة حتى أول تفاعل؛ لا أحد يحتاج واتساب في أول 3 ثوانٍ.
• استخدم واجهة بديلة (Facade) لفيديوهات YouTube وخلاصات السوشيال: صورة خفيفة تتحول إلى التضمين الحقيقي عند النقر.
• راجع البكسلات واحذف ما لم تعد تستخدمه.

4. قلّص شجرة DOM

• اعتمد الحاويات المرنة بدلاً من الأقسام والأعمدة المتداخلة.
• قلل عدد العناصر في الصفحة الواحدة.
• احذف العناصر المخفية المحمّلة: سلايدر من 10 شرائح يظهر منها واحدة، أو قائمة ضخمة بمئات الروابط على الموبايل.

في Elementor: استخدم Flexbox Container بدل البنية القديمة (Section ← Column ← Widget) في الصفحات الجديدة، فهي تنتج عناصر أقل تداخلاً. وراجع إعدادات الأداء في Elementor لتحميل الأصول حسب الحاجة بدلاً من تحميلها في كل صفحة.

5. ساعد الخيط الرئيسي (للمطورين)

توصيات web.dev الرسمية هنا واضحة:

• قسّم العمل الثقيل داخل معالج الحدث إلى مهام منفصلة باستخدام setTimeout، وحدّث الواجهة أولاً ثم أجّل الباقي.
• تجنّب إرهاق التخطيط (Layout Thrashing): لا تغيّر التنسيق ثم تقرأ أبعاد العنصر في المهمة نفسها.
• استخدم خاصية CSS content-visibility لتأجيل رسم العناصر خارج الشاشة.
• اقصر الحركة على transform وopacity لأنهما لا يعيدان حساب التخطيط.

6. قوِّ جهة الخادم (دور مساند)

الخادم السريع لا يصلح INP مباشرة، لكنه يسرّع التفاعلات التي تنتظر ردّاً من الخادم مثل البحث والفلاتر وتحديث السلة. شغّل PHP 8.x مع OPcache، وفعّل Object Cache مثل Redis، واختر استضافة بعدد كافٍ من عمليات PHP. وللزوار في مصر والخليج، يقلل مركز بيانات أوروبي قريب مثل فرانكفورت مع Cloudflare زمن الوصول.

الخطوة 4: تحقق من النتيجة دون أن تخدع نفسك

• فوراً: سجّل تتبع Performance جديداً مع CPU throttling، وتأكد أن المهام الطويلة اختفت.
• خلال أيام: إن ركّبت web-vitals، تابع منحنى INP وهو ينخفض.
• بعد نحو شهر: انتظر تحديث Search Console وPageSpeed؛ نافذة CrUX تقارب 28 يوماً، فلا تقلق إن ظل التقييم «ضعيفاً» في الأسبوع الأول.

بصراحة: لا تطارد رقماً مثالياً على حساب الوظائف. موقع INP فيه 180 مللي ثانية وكل أزراره تعمل أفضل من موقع بـ 120 مللي ثانية وقائمته معطلة.

ما لا يصلح INP

• الكاش وحده: يسرّع تسليم HTML، لكن التفاعل يحدث بعد التحميل.
• ضغط الصور: حاسم لـ LCP، وأثره على INP شبه معدوم.
• إضافة تسريع جديدة دون حذف السكربتات الثقيلة: الإضافات لا تلغي بعضها، والحِمل باقٍ.
• الـ CDN: يسرّع التوصيل عالمياً، لكنه لا يقلل حجم الجافاسكربت.

الأسئلة الشائعة

س: ما هي قيمة INP الجيدة؟
ج: 200 مللي ثانية أو أقل جيدة، وما بين 200 و500 يحتاج إلى تحسين، وما فوق 500 ضعيف. استهدف الحد الجيد على الموبايل تحديداً لأنه موضع معظم المشاكل.

س: لماذا INP ضعيف على الموبايل وجيد على الكمبيوتر؟
ج: لأن معالج الهاتف أبطأ بكثير، فيستغرق الجافاسكربت نفسه وقتاً أطول. علاج ذلك تقليل وزن السكربتات، لا الاختبار على الكمبيوتر فقط.

س: هل تأجيل الجافاسكربت يحسّن INP أم يضره؟
ج: قد يفعل الاثنين. تأجيل السكربتات غير الضرورية يحرر الخيط الرئيسي، لكن تأجيل سكربتات القائمة والبحث والسلة يجعل الأزرار لا تستجيب، فاستثنِها دائماً.

س: متى يظهر التحسن في Search Console؟
ج: بعد نحو 28 يوماً، لأن البيانات الميدانية تُجمع على هذه الفترة. استخدم DevTools للتأكد الفوري.

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

الخلاصة

تحسين INP في ووردبريس معركة جافاسكربت لا معركة كاش: قِس بالبيانات الميدانية، واعثر على السكربتات الثقيلة بـ DevTools، واحذف ما لا تحتاجه، وأجّل ما ليس ضرورياً مع حماية عناصر التفاعل.

امشِ على الخطوات بالترتيب واختبر على موبايل حقيقي، وادي البيانات شهرها. ولو موقعك محتاج حد يبص عليه معاك، احجز جلسة من هنا احجز استشارة مجانية.

مراجع إضافية: Optimize Interaction to Next Paint – web.dev، Interaction to Next Paint becomes a Core Web Vital on March 12 – web.dev

مرجع المقال (بالإنجليزية): How to Improve INP in WordPress (2026 Guide)
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.