تقديم جدول زمني.yield(): أحدث واجهة برمجة تطبيقات Chrome لتحسين INP

ليس هناك شك في أن Google تركز على الاستجابة في عام 2023.

حتى الآن، هم:

• تم نقل التفاعل إلى الرسم التالي من التجريبي إلى المعلق؛
• تم الإعلان عن أن INP سيحل محل تأخير الإدخال الأول كمقياس جديد لحيوية الويب الأساسية للاستجابة في مارس 2024؛
• بدأت في الإبلاغ عن مشكلات INP في Search Console وإرسال رسائل البريد الإلكتروني إلى مواقع الويب التي تفتقد عتبة الاستجابة الجيدة.

الآن، أعلن فريق Chrome أنهم يقومون حاليًا بإجراء تجربة أصلية لواجهة برمجة التطبيقات الجديدة للجدولة - Scholter.yield() .

من المتوقع أن يساعد برنامج scheduler.yield() المطورين على تحسين استجابة مواقعهم من خلال تزويدهم بطريقة أسهل وأفضل لإعادة التحكم إلى سلسلة الرسائل الرئيسية.

تابع القراءة لمعرفة المزيد حول واجهة برمجة التطبيقات الجديدة وكيفية تجربتها على موقع الويب الخاص بك.

ملخص سريع للمهام الطويلة والموضوع الرئيسي

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

كل ما يفعله المتصفح كعمل يعتبر مهمة. يتضمن ذلك العرض، وتحليل HTML وCSS، وتشغيل كود JavaScript الذي تكتبه، وأشياء أخرى قد لا يكون لديك سيطرة مباشرة عليها.

الموضوع الرئيسي هو المكان الذي يقوم فيه المتصفح بمعظم العمل.

لسوء الحظ، يمكن للخيط الرئيسيمعالجة مهمة واحدة فقط في كل مرة .وإذا استغرق تشغيل المهمة أكثر من 50 مللي ثانية، فإنها تعتبر مهمة طويلة.

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

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

ولهذا السبب يعتبر موردًا لحظر العرض - عندما يواجهه المتصفح، يجب عليه تنزيله وتحليله وتنفيذه قبل القيام بأي شيء آخر.

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

يمكنك تقسيم المهام الطويلة عن طريق الخضوع للمهمة بشكل واضح.

بعبارات أبسط، تضمن عملية تسليم المهام عدم انشغال المتصفح بمهمة واحدة بحيث يفقده أو يؤخر الاستجابة للمهام المهمة الأخرى أو تفاعلات المستخدم.

ولسوء الحظ، فإن استراتيجيات العائد الحالية ليست مثالية ...

لماذاscheduler.yield(): المشكلة المتعلقة باستراتيجيات العائد الحالية

إن الاستسلام للخيط الرئيسي ليس مفهومًا جديدًا. لقد استخدم المطورون إستراتيجيات إنتاجية مختلفة لتقسيم المهام الطويلة لبعض الوقت:

1.setTimeout()

يتيح لك setTimeout() جدولة مهمة ليتم تشغيلها بعد تأخير محدد أو على فترات زمنية منتظمة. يؤدي هذا إلى تأجيل تنفيذ رد الاتصال إلى مهمة منفصلة، ​​حتى إذا قمت بتحديد مهلة قدرها 0. تكون هذه الطريقة فعالة عندما يكون لديك وظائف متعددة يجب تشغيلها واحدة تلو الأخرى.

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

2. طلبIdleCallback()

يسمح لك requestIdleCallback() بجدولة مهمة ليتم تشغيلها أثناء أي فترات خمول قد يمر بها المتصفح. إنه مفيد لأداء المهام غير العاجلة دون التأثير على تجربة المستخدم.

العيب: يقوم requestIdleCallback() بجدولة المهام بأدنى أولوية ممكنة، مما يعني أنه إذا كان مؤشر الترابط الرئيسي مزدحمًا، فقد لا يتم تشغيل المهام المجدولة أبدًا.

3.isInputPending()

يمكن تنفيذ التابع isInputPending() في أي وقت للتحقق مما إذا كان المستخدم يحاول التعامل مع عنصر ما في الصفحة. إذا كانت كذلك، فإن الدالة ترجعصحيحًا؛ إذا لم يكن كذلك، فإنه يعودكاذبة.

تخيل أن لديك مجموعة من المهام المطلوب تنفيذها ولكنك لا تريد تعطيل تفاعلات المستخدم. يمكنك استخدام isInputPending() والدالة resultToMain() لضمان عدم تأخير إدخال المستخدم أثناء تفاعله مع الصفحة.

العيب: قد لا يعود isInputPending() دائمًا صحيحًا فورًا بعد إدخال المستخدم. وذلك لأن نظام التشغيل يستغرق وقتًا لإخبار المتصفح بحدوث التفاعل. وهذا يعني أن تعليمات برمجية أخرى ربما تكون قد بدأت بالفعل في التنفيذ.

هذه بعض الطرق الشائعة للعودة إلى الموضوع الرئيسي. كما ترون، كل واحد لديه عيوبه الخاصة.

ولكن الجانب السلبي الأكثر أهمية هو أن:

عندما تستسلم للسلسلة الرئيسية عن طريق تأجيل تشغيل التعليمات البرمجية في مهمة لاحقة، تتم إضافة هذا الرمز إلى نهاية قائمة انتظار المهام.

لماذا هذه مشكلة؟

وهي إجابة ثلاثية:

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

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

تقديم جدولة.yield ()

إن الإثارة حول تشغيل Chrome للتجربة الأصلية لـscheduler.yield() هي لأنها واجهة برمجة تطبيقات للجدولة تعالج جميع عيوب الاستراتيجيات الأخرى ذات الإنتاجية.

علاوة على ذلك، فهو حل سيمكن كلاً من المطورين والمالكين من تحقيق مواقع ويب سريعة الاستجابة ونتائج INP جيدة مع تنفيذ بقية التعليمات البرمجية بسلاسة.

إذن ما هو كل هذا الضجيج حول scheduler.yield() ؟

بالنسبة للمبتدئين، فإنscheduler.yield() هي دالة إنتاجية مخصصة. على سبيل المثال، يتم استخدام setTimeout()، لتقسيم المهام الطويلة والاستسلام للسلسلة الرئيسية، ولكنه يعد تأثيرًا جانبيًا للوظيفة أكثر من كونه خيارًا افتراضيًا.

ثانيًا، يرسل التابعscheduler.yield() ‎ العمل المتبقي إلى مقدمة قائمة الانتظار. وهذا يعني أن العمل الذي تريد استئنافه فورًا بعد الانتهاء منه لن يأخذ مقعدًا خلفيًا للمهام من مصادر أخرى.

ببساطة:

يمنحك scheduler.yield() أفضل ما في كلا العالمين - يمكنك تحسين استجابة موقعك ونقاط INP والتأكد من عدم تأخير العمل الذي تريد إكماله بعد الإنتاج.

كيفية تجربة واجهة برمجة تطبيقات الجدولة الجديدة

بدءًا من الإصدار 115 من Chrome، يمكنك اختبارscheduler.yield بنفسك.

لتجربة واجهة برمجة التطبيقات الجديدة، ما عليك سوى اتباع تعليمات Google:

1. إذا كنت ترغب في تجربة جدولة.yield محليًا، فاكتب وأدخل chrome://flags في شريط عناوين Chrome وحدد تمكين من القائمة المنسدلة في قسم ميزات منصة الويب التجريبية. سيؤدي هذا إلى جعلscheduler.yield (وأي ميزات تجريبية أخرى) متاحة فقط في مثيل Chrome لديك.
   
2. إذا كنت ترغب في تمكين Scholar.yield لمستخدمي Chromium الحقيقيين على أصل يمكن الوصول إليه بشكل عام، فسوف تحتاج إلى الاشتراك في النسخة التجريبية لـ Scholar.yield Origin. ويتيح لك ذلك تجربة الميزات المقترحة بأمان لفترة زمنية معينة، ويمنح فريق Chrome رؤى قيمة حول كيفية استخدام هذه الميزات في الميدان. لمزيد من المعلومات حول كيفية عمل تجارب الأصل، اقرأ هذا الدليل.

بمجرد اختباره، يمكنك أيضًا تقديم تعليقات حول كيفية تحسينه.

اختبار آمن!

كيف يمكن أن يساعد NitroPack في إلغاء حظر الموضوع الرئيسي

يعد تقسيم المهام الطويلة إلى أجزاء أصغر أمرًا ضروريًا لتزويد المستخدمين بتجربة سريعة.

ولكن ألن يكون من الأفضل أن تتمكن بشكل استباقي من تحسين بعض نصوص جافا سكريبت الثقيلة؟

وهنا يأتي دور NitroPack.

بفضل ما يزيد عن 35 من ميزات أداء الويب المتقدمة ، يساعد NitroPack أكثر من 180,000 موقع ويب على مستوى العالم في تحقيق تجربة مستخدم ممتازة، ومؤشرات أداء الويب الأساسية، ومعدلات التحويل.

إحدى أهم مزايا NitroPack هي طريقتها في التعامل مع تنفيذ JavaScript.

عند تثبيت NitroPack، تقوم خدمتنا بتأخير تحميل الموارد غير المهمة حتى يتم اكتشاف تفاعل المستخدم.

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

بهذه الطريقة، يمكننا أن نضمن أن يظل موضوعك الرئيسي غير محظور ومتاحًا للتعامل مع تفاعلات المستخدم.

تحسين استجابة موقعك على الفور. احصل على NitroPack مجانًا →