لكي تقلل Total Blocking Time في ووردبريس، اكتشف مهام الجافاسكريبت الطويلة بأدوات Chrome DevTools أو Lighthouse، واحذف السكربتات التي لا تحتاجها، وحمل الباقي في الصفحات التي تستخدمه فقط، وأجل أو أخر السكربتات غير الحرجة، واستبدل أدوات الطرف الثالث الثقيلة ببدائل أخف. TBT مقياس معملي، والمقياس الحقيقي الذي يتنبأ به هو INP.
هذا جزء من سلسلة السرعة، ابدأ بـ دليل Core Web Vitals لفهم السياق.
ما هو Total Blocking Time؟
يقيس Total Blocking Time المدة التي كان فيها الخيط الرئيسي في المتصفح مشغولا عن الاستجابة أثناء تحميل الصفحة. أي مهمة أطول من 50 مللي ثانية تعد “مهمة طويلة”، والوقت الزائد عن 50 يحسب تعطيلا. ويجمع TBT هذه الأجزاء بين First Contentful Paint وTime to Interactive، فمهمة مدتها 250 مللي ثانية تضيف 200.
العلاقة بين TBT وINP
Interaction to Next Paint أحد مقاييس Core Web Vitals، ويقيس سرعة استجابة الصفحة للمسات والنقرات الحقيقية طوال الزيارة. أدوات المعمل لا تستطيع الضغط على صفحتك كالمستخدمين، لذلك يعرض Lighthouse مقياس TBT بدلا منه. ارتفاع TBT يعني أن الخيط الرئيسي مشغول، فالتفاعلات أثناء التحميل غالبا ستكون بطيئة. أصلح TBT في المعمل ثم تأكد ببيانات INP الحقيقية.
الخطوة 1: اكتشف ما يعطل الخيط الرئيسي
- Lighthouse: بندا “Avoid long main-thread tasks” و”Reduce JavaScript execution time” يعرضان أسوأ السكربتات.
- “Reduce the impact of third-party code” يجمع التكلفة حسب المزود.
- لوحة Performance في DevTools: سجل تحميل الصفحة مع إبطاء المعالج، وابحث عن المهام الطويلة المعلمة بالأحمر، ووسعها لترى السكربت والدالة المسببة.
- تبويب Coverage: يعرض نسبة ما يستخدم فعلا من كل ملف JS في الصفحة.
دون كل سكربت ومصدره (إضافة، قالب، طرف ثالث) وتكلفته وهل تحتاجه هذه الصفحة.
الخطوة 2: احذف غير الضروري
أرخص جافاسكريبت هو الذي لا يحمل أبدا. مرشحون معتادون:
- إضافات لم تعد مستخدمة (راجع مراجعة الإضافات).
- مكتبات مكررة (نسختان من مكتبة سلايدر، عدة خطوط أيقونات).
- jQuery Migrate إذا لم يعتمد عليه شيء.
- سكربتات الإيموجي إذا لم تحتجها.
- أكواد تتبع قديمة من حملات سابقة في مدير الوسوم.
الخطوة 3: حمل السكربتات حيث تلزم فقط
سكربتات نموذج التواصل في كل الصفحات، وسكربتات السلايدر في صفحات بلا سلايدر، وسكربتات الخرائط في كل الموقع: كلها شائعة. أوقفها بشروط:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_script( 'contact-form-7' );
wp_dequeue_style( 'contact-form-7' );
}
}, 100 );
أسماء الـ handles تختلف من إضافة لأخرى، اعرفها من كود الصفحة أو بإضافة Query Monitor. وبعض إضافات التحسين توفر مدير سكربتات لكل صفحة يؤدي نفس الغرض دون كود.
الخطوة 4: التأجيل والتأخير
- التأجيل (سمة
defer) ينزل بالتوازي ويعمل بعد تحليل HTML. ومنذ ووردبريس 6.3 تقبلwp_enqueue_script()استراتيجية تحميل:
wp_enqueue_script( 'mx-ui', get_stylesheet_directory_uri() . '/assets/ui.js', array(), '1.0', array(
'strategy' => 'defer',
'in_footer' => true,
) );
- التأخير حتى التفاعل ينتظر حتى يمرر المستخدم أو يحرك الماوس أو يلمس الشاشة قبل تحميل السكربت. فعال جدا لأدوات الدردشة والتقييمات والخرائط الحرارية وبعض التحليلات، وغير مناسب لما يلزم فورا: قوائم التنقل، السلايدر أعلى الصفحة، وموافقة الكوكيز المطلوبة قبل التتبع.
اختبر دائما بعد تفعيل التأخير: افتح قائمة الموبايل، أرسل النماذج، أضف للسلة، وتأكد أن التحليلات ما زالت تسجل.
الخطوة 5: اضبط سكربتات الطرف الثالث
الطرف الثالث غالبا صاحب النصيب الأكبر. الخيارات:
- أدوات الدردشة: حملها عند النقر مع زر بديل خفيف، أو بعد مهلة.
- تضمينات يوتيوب والخرائط: استخدم واجهة بديلة (صورة مصغرة تحمل التضمين الحقيقي عند النقر).
- مديرو الوسوم: راجع الوسوم، فكل وسم يعمل على أجهزة مستخدميك.
- أدوات اختبار A/B: غالبا تعطل العرض بطبيعتها، فاستخدمها بوعي واحذفها عند انتهاء الاختبار.
- خلاصات السوشيال: استبدلها بمحتوى ثابت أو روابط.
الخطوة 6: قلل حجم DOM وثقل أدوات البناء
DOM الكبير يبطئ كل إعادة حساب للسكربتات والتنسيقات، فيؤثر على TBT وINP. مع أدوات بناء الصفحات:
- تجنب الأقسام والأعمدة المتداخلة بعمق.
- عطل العناصر والوحدات غير المستخدمة من إعدادات الأداة.
- استخدم خيارات الأداء في الأداة (مثل تحميل الملفات المستخدمة فقط).
- للقوالب الأساسية قد يتفوق قالب مخصص خفيف في القالب الفرعي على أداة البناء.
الخطوة 7: اكتب جافاسكريبت أخف
إذا كنت تتحكم في الكود:
- قسم العمل الطويل إلى أجزاء صغيرة وأفسح المجال للخيط الرئيسي بينها.
- استخدم event delegation بدلا من آلاف المستمعين.
- تجنب layout thrashing: اجمع قراءات DOM ثم الكتابات.
- استخدم CSS للحركة قدر الإمكان، و
IntersectionObserverبدلا من معالجات التمرير.
القياس الصحيح
TBT المعملي يتفاوت بين التشغيلات والأجهزة. شغل Lighthouse عدة مرات وقارن الوسيط، دائما بنفس إعدادات الجهاز. وبعد النشر امسح الكاش (كاش الصفحات، كاش إضافة التحسين، CDN) لتختبر النسخة الجديدة.
قائمة المراجعة
- تحديد المهام الطويلة ونسبتها للسكربتات
- حذف الإضافات والوسوم غير المستخدمة
- تحميل سكربتات الصفحات الخاصة في صفحاتها فقط
- تأجيل السكربتات غير الحرجة وتأخير الأدوات حتى التفاعل
- استبدال التضمينات بواجهات بديلة
- تقليل حجم DOM في القوالب الأساسية
- اختبار التفاعلات الأساسية بعد التغييرات
- متابعة بيانات INP الحقيقية
أخطاء شائعة
- تفعيل “تأخير كل الجافاسكريبت” دون ملاحظة أن قائمة الموبايل تعطلت.
- القياس على نسخة قديمة من الكاش.
- لوم نواة ووردبريس بينما أداة دردشة واحدة تسبب أغلب وقت التعطيل.
- دمج كل JS في ملف واحد كبير، مما قد يصنع مهمة طويلة ضخمة.
إذا كان موقعك بطيء الاستجابة على الهواتف، تواصل معي وسأتتبع أين يضيع الوقت. ذو صلة: تحسين LCP.
الأسئلة الشائعة
ما هو Total Blocking Time؟
هو إجمالي الوقت بين First Contentful Paint وTime to Interactive الذي تعطل فيه الخيط الرئيسي بما يكفي لمنع الاستجابة للمدخلات. كل مهمة تزيد عن 50 مللي ثانية تضيف ما يتجاوز الـ 50.
ما الرقم الجيد لـ TBT؟
يعتبر Lighthouse حوالي 200 مللي ثانية أو أقل على الموبايل جيدا. ولأنه مقياس معملي استخدمه لمقارنة التغييرات، واحكم على تجربة المستخدمين ببيانات INP الحقيقية.
هل تأخير الجافاسكريبت آمن؟
غالبا لكن ليس دائما. تأخير السكربتات حتى تفاعل المستخدم قد يكسر القوائم أو السلايدر أو النماذج أو التحليلات، فاستثن السكربتات الحرجة واختبر الصفحات الأساسية بعد التفعيل.
لماذا ساء TBT بعد تحديث؟
الأسباب الشائعة إصدارات إضافات جديدة، أو أكواد تتبع مضافة، أو قالب يضيف سكربتات في كل الموقع. قارن السكربتات المحملة قبل وبعد في DevTools.
