وجد المتصفح لحظة هدوء، فجاءت الصفحة بقائمة أعمالها كلها

الخلاصة

• قدّمت مسودة W3C العامة الأولى في سبتمبر 2015 واجهة requestIdleCallback: تطلب الصفحة موعداً حين يتوقع المتصفح فترة خمول، وتتلقى IdleDeadline لتعرف مقدار الوقت المتبقي عبر timeRemaining().
• أبقت وثائق 2017 و2025 اختيار الموعد عند المتصفح واختيار العمل عند الصفحة. ويمكن للمهلة الاختيارية أن تستدعي المهمة بعدما يطول انتظارها، حتى لو لم يظهر وقت هادئ.

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

كان المؤقت setTimeout يستطيع إعادة استدعاء الشيفرة في موعد لاحق. يعرف المؤقت متى يرن، ولا يعرف ماذا يفعل المتصفح لحظة الرنين. اقترحت مسودة W3C العامة الأولى المؤرخة 17 سبتمبر 2015 ترتيباً أكثر براعة: تستدعي الصفحة requestIdleCallback، فيحدد المتصفح فترة يتوقع أن يكون فيها أقل انشغالاً. عندئذ تتلقى الدالة IdleDeadline، وتقرأ من timeRemaining() تقديراً لما بقي من تلك الفترة. الصفحة تحمل صندوق الأدوات؛ المتصفح يفتح الورشة حين يجد الباب غير مزدحم.

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

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

واجهت وثيقة المرشح للتوصية في 31 يناير 2017 ووثيقة التوصية المقترحة في 10 أكتوبر 2017 سؤالاً معاكساً: ماذا لو لم يهدأ المتصفح أبداً؟ تسمح الواجهة بتحديد timeout. عند بلوغ المهلة، يمكن استدعاء الدالة، وتخبرها قيمة didTimeout أن الانتظار بلغ حده. هذا مخرج للمهام العالقة، لكنه ينقل العمل إلى وقت قد يكون مزدحماً بالفعل. لو أعلن كل نص برمجي حالة طوارئ، صار الممر الذي خُصص للحركة السريعة مخزناً عاماً للصناديق.

يسجل تاريخ النشر الرسمي لدى W3C المسودة الأولى عام 2015 ومراحل 2017 والتنقيحات اللاحقة. ولا تزال مسودة العمل الصادرة في 21 مايو 2025 تجعل تحديد فترة الخمول قراراً يتخذه المتصفح، وتمنح الدالة حدّاً زمنياً تسترشد به. بقي التقسيم لأن المعلومات موزعة فعلاً: يرى المتصفح ضغط الرسم والتفاعل، وتعرف الصفحة قيمة أعمالها وكيف تقطعها إلى أجزاء.

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