الخيط الرئيسي في المتصفح مورد مكلف: كيف تنفقه باقتصاد

يدور معظم الحديث عن تحسين الواجهة الأمامية حول طلبات الشبكة وحجم الحزمة والتخزين المؤقت. أما الخيط الرئيسي (main thread) فيُذكر نادرًا، لأنه لا يمثل مشكلة على الشاشات العادية. لكن على الشاشات كثيفة التفاعل لا ينفع أي توفير في الشبكة إذا كان الخيط الذي ينفذ شفرتك محجوبًا. يتناول منشور "The Browser's Main Thread Is Expensive" في مدونة kciter.so كيفية إنفاق هذا المورد باقتصاد.

خيط واحد ومهمتان

ينفذ الخيط الرئيسي جافاسكريبت — شفرتك ومعالجات الأحداث والمؤقتات والمنطق الداخلي للإطار — ويرسم الشاشة: حساب الأنماط والتخطيط والطلاء. ليبدو العرض سلسًا يجب إنتاج إطار بمعدل تحديث الشاشة: نحو 16.6 مللي ثانية عند 60 هرتز، ولا تبقى بعد خصم كلفة المتصفح ميزانية عملية تقارب 10 مللي ثانية. تعمل جافاسكريبت بنموذج حلقة أحداث أحادي الخيط: فما دامت مهمة تعمل لا يمكن حدوث أي شيء آخر. ولهذا تُجمّد دالة تستغرق 200 مللي ثانية إعادة الرسم والحركة والمدخلات خلال تلك المدة. وتُعد المهام الأطول من 50 مللي ثانية مهام طويلة، ومقاييس مثل INP وTBT تقيس فعليًا مدة حجب الخيط الرئيسي. السبب غالبًا ليس شفرة بطيئة، بل احتلال الشفرة للخيط.

أربع طرق للإنفاق الحكيم

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

يقلل التجميع المهام المتكررة بإفراط: debounce وthrottle لأحداث التمرير والمدخلات، ورسم واحد لكل إطار للوحات الحية. ويحدد ترتيب الأولوية الترتيب: طابور مبني على MessageChannel يجعل عمل صورة نقر عليها المستخدم توًا يتقدم على توليد المعاينات في الخلفية. ويسأل التأجيل هل يجب أن يحدث العمل الآن: تقسيم الشفرة عند التحميل الأول، وIntersectionObserver لبناء المنشورات القريبة من الشاشة فقط، وإيقاف الحركات الخارجة عن الشاشة.

خارج الخيط الرئيسي

يمكن تسليم بعض العمل كليًا. تبقى حركة transform وopacity على خيط التركيب وتبقى سلسة حتى وانشغال جافاسكريبت، بينما تفرض حركة top أو width إعادة حساب التخطيط في كل إطار؛ وتقنية FLIP تحوّل تغيير التخطيط الحقيقي إلى حركة قائمة على transform. ويمكن لعامل ويب (web worker) أن يحمل حسابات ثقيلة كالتحليل أو معالجة الصور، لكنه لا يصل إلى DOM ويتبادل البيانات بالنسخ، إلا إذا نُقلت ملكية المخزن المؤقت بتكلفة تقارب الصفر.

عدم أداء العمل أصلًا

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