سعر جافا سكريبت 2019

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



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

إرشادات عملية عامة لتحسين الموقع

ماذا يعني أعلاه لمطوري الويب؟ النقطة هنا هي أن تكلفة موارد التحليل (التحليل ، التحليل) وتجميع النصوص ليست خطيرة كما كانت من قبل. لذلك ، عند تحليل حزم JavaScript وتحسينها ، يجب على المطورين مراعاة التوصيات الثلاث التالية:

1. حاول تقليل الوقت اللازم لتنزيل البرامج النصية.
   
   
   • حاول الحفاظ على حزم JS صغيرة. هذا مهم بشكل خاص للمواقع المصممة للأجهزة المحمولة. يؤدي استخدام حزم صغيرة إلى تحسين وقت تحميل الشفرة وتقليل مستوى استخدام الذاكرة وتقليل الحمل على المعالج.
   • حاول منع تقديم رمز المشروع كحزمة واحدة كبيرة. إذا تجاوز حجم الحزمة ما يقرب من 50-100 كيلو بايت - قسّمها إلى أجزاء منفصلة صغيرة الحجم. بفضل تعدد إرسال HTTP / 2 ، يمكن معالجة طلبات الخادم المتعددة والاستجابات المتعددة في وقت واحد. هذا يقلل من الحمل على النظام المرتبط بالحاجة إلى تلبية الطلبات الإضافية لتحميل البيانات.
   • إذا كنت تعمل في مشروع متنقل ، فحاول الحفاظ على الكود أصغر ما يمكن. ترتبط هذه التوصية بمعدلات بيانات منخفضة عبر شبكات المحمول. بالإضافة إلى ذلك ، نسعى جاهدين للاستخدام الاقتصادي للذاكرة.
2. حاول تقليل الوقت اللازم لتنفيذ البرامج النصية.
   
   
   • تجنب استخدام المهام المطولة التي يمكنها تحميل سلسلة الرسائل الرئيسية لفترة طويلة وزيادة الوقت اللازم لتكون الصفحات في حالة يمكن للمستخدمين التفاعل معها. في البيئة الحالية ، تقدم البرامج النصية التي تعمل بعد تحميلها مساهمة كبيرة في "سعر JavaScript".
3. لا تقم بتضمين مقتطفات شفرة كبيرة في الصفحات.
   
   
   • يجب الالتزام بالقاعدة التالية: إذا كان حجم البرنامج النصي يتجاوز 1 كيلو بايت ، فحاول عدم تضمينه في رمز الصفحة. أحد أسباب هذه التوصية هو أن 1 كيلو بايت هو الحد الذي يبدأ بعده التخزين المؤقت لرمز البرنامج النصي الخارجي في العمل في Chrome. أيضًا ، ضع في اعتبارك أن تحليل النصوص البرمجية المضمنة وتجميعها لا يزال قيد التشغيل في السلسلة الرئيسية.

ما أهمية تحميل البرامج النصية وتنفيذها؟

لماذا من المهم تحسين وقت التحميل والتنفيذ للبرامج النصية في الظروف الحديثة؟ تعتبر أوقات تحميل البرنامج النصي مهمة للغاية في المواقف التي يتم فيها الوصول إلى المواقع من خلال شبكات بطيئة. على الرغم من حقيقة أن شبكات 4G (وحتى 5G) تنتشر أكثر فأكثر ، فإن خاصية NetworkInformation.effectiveType في كثير من الحالات من استخدام اتصالات الإنترنت عبر الهاتف النقال تظهر مؤشرات على مستوى شبكات 3G أو حتى في المستويات الأدنى.

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

في الواقع ، إذا قمنا بتحليل إجمالي الوقت المستغرق في تحميل الصفحة وإعدادها للعمل في متصفح مثل Chrome ، فيمكن قضاء 30٪ تقريبًا من هذا الوقت في تنفيذ شفرة JS. فيما يلي تحليل لتحميل صفحة ويب نموذجية للغاية (reddit.com) على كمبيوتر مكتبي عالي الأداء.


في عملية تحميل الصفحة ، يتم إنفاق حوالي 10-30٪ من الوقت على تنفيذ التعليمات البرمجية باستخدام V8

إذا كنا نتحدث عن الأجهزة المحمولة ، فحينما يستغرق الأمر على هاتف متوسط ​​(Moto G4) مدة أطول من 3 إلى 4 مرات لتنفيذ reddit.com على رمز JS منه على جهاز عالي المستوى (Pixel 3). على جهاز ضعيف (تتكلف Alcatel 1X أقل من 100 دولار) ، يتطلب حل المشكلة نفسها 6 مرات على الأقل أكثر من وقت مثل Pixel 3.


الوقت اللازم لمعالجة كود JS على الأجهزة المحمولة من فئات مختلفة

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

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


المهام طويلة المدى التقاط الخيط الرئيسي. يجب تقسيمها إلى قطع

كيف تسرع تحسينات V8 في تحليل النصوص وتجميعها؟

زادت سرعة تحليل شفرة JS المصدر في الإصدار 8 ، منذ وقت Chrome 60 ، مرتين. في الوقت نفسه ، يساهم تحليل وتجميع البيانات الآن بدرجة أقل في "سعر JavaScript". هذا بفضل جهود تحسين Chrome الأخرى التي تؤدي إلى موازاة هذه المهام.

في V8 ، يتم تقليل مقدار العمل على تحليل وتجميع التعليمات البرمجية المنتجة في مؤشر الترابط الرئيسي بمعدل 40٪. على سبيل المثال ، بالنسبة إلى Facebook ، كان تحسين هذا المؤشر 46٪ ، بالنسبة لـ Pinterest - 62٪. تم الحصول على أعلى نتيجة ، 81٪ ، لموقع YouTube. هذه النتائج ممكنة بسبب حقيقة أن التحليل والتجميع يتم نقلهما إلى دفق منفصل. وهذا بالإضافة إلى التحسينات الحالية بخصوص حل التدفق لنفس المهام خارج التيار الرئيسي.


JS تحليل الوقت في إصدارات مختلفة من كروم

يمكنك أيضًا تصور كيف تؤثر تحسينات V8 المنتجة في إصدارات مختلفة من Chrome على وقت المعالج المطلوب لمعالجة الشفرة. في نفس الوقت الذي يحتاج فيه Chrome 61 إلى تحليل رمز Facebook JS ، يمكن الآن لـ Chrome 75 تحليل رمز Facebook JS ، بالإضافة إلى تحليل رمز Twitter 6 مرات.


في الوقت الذي يحتاج فيه Chrome 61 إلى معالجة رمز JS الخاص بـ Facebook ، يمكن لـ Chrome 75 معالجة كل من كود Facebook وستة أضعاف مقدار كود Twitter.

دعونا نتحدث عن كيفية تحقيق هذه التحسينات. باختصار ، يمكن تحليل موارد النص البرمجي وتجميعها في وضع التدفق في سير العمل. وهذا يعني ما يلي:

• يمكن V8 تحليل وتجميع رمز JS دون حظر الخيط الرئيسي.
• تبدأ معالجة الدفق للبرنامج النصي عندما يواجه محلل HTML العام <script> . يعالج محلل HTML البرامج النصية التي تحظر تحليل الصفحة. لقاء مع البرامج النصية غير متزامن ، وقال انه يواصل العمل.
• في معظم سيناريوهات العالم الحقيقي ، التي تتميز بسرعات اتصال شبكة معينة ، يقوم V8 بتوزيع الرمز بشكل أسرع مما يمكن تحميله. نتيجة لذلك ، يُكمل V8 مهام تحليل وتجميع الشفرة بعدد من المللي ثانية بعد تحميل آخر بايت من البرنامج النصي.

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


يتم إرسال البرامج النصية إلى المستعرض في أجزاء. يبدأ V8 في دفق معالجة البيانات بعد أن يحتوي على 30 كيلو بايت على الأقل من التعليمات البرمجية.

في Chrome 71 ، انتقلنا إلى نظام قائم على المهام. هنا ، يمكن لبرنامج الجدولة بدء جلسات معالجة نصية متعددة غير متزامنة / مؤجلة في وقت واحد. بسبب هذا التغيير ، انخفض الحمل الناتج عن تحليل الخيط الرئيسي بنحو 20٪. أدى ذلك إلى تحسن بنسبة 2٪ تقريبًا في درجات TTI / FID التي تم الحصول عليها في مواقع حقيقية.


يستخدم Chrome 71 نظامًا لمعالجة التعليمات البرمجية المستندة إلى المهام. باستخدام هذا الأسلوب ، يمكن لجدولة معالجة العديد من البرامج النصية غير المتزامنة / المعلقة في نفس الوقت.

في Chrome 72 ، جعلنا معالجة البث هي الطريقة الأساسية لتحليل البرامج النصية. الآن يتم التعامل مع البرامج النصية المتزامنة العادية بهذه الطريقة (على الرغم من أن هذا لا ينطبق على البرامج النصية المضمنة). بالإضافة إلى ذلك ، توقفنا عن إلغاء عمليات التحليل المعتمدة على المهام إذا كان الخيط الرئيسي يحتاج إلى كود محلل. يتم ذلك بسبب حقيقة أن هذا يؤدي إلى الحاجة إلى إعادة تنفيذ بعض الأعمال المنجزة بالفعل.

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

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

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

كيف أثرت التحسينات على ما يمكن رؤيته في أدوات المطور؟

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


تكمن المشكلة في أدوات المطورين ، حيث يتم عرض المعلومات حول تحليل البرامج النصية كما لو كانت تمنع سلسلة الرسائل الرئيسية تمامًا

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


في Chrome 76 ، يتم تقسيم التحليل إلى العديد من المهام الصغيرة

بشكل عام ، يمكن الإشارة إلى أن علامة تبويب "الأداء" الخاصة بأدوات المطورين رائعة لمعرفة الصورة الكلية لما يحدث على الصفحة. من أجل الحصول على مزيد من المعلومات المفصلة التي تعكس ميزات V8 ، مثل تحليل وقت ووقت الترجمة ، يمكنك استخدام دعم Chrome Tracing مع RCS (إحصائيات وقت التشغيل). في بيانات RCS المستلمة ، يمكنك العثور على مؤشرات Parse-Background و Compile-Background. وهم قادرون على الإبلاغ عن مقدار الوقت الذي استغرقته عملية تحليل وتجميع شفرة JS خارج الخيط الرئيسي. تشير مقاييس التحليل والتجميع إلى مقدار الوقت الذي تم إنفاقه على الأنشطة ذات الصلة في سلسلة الرسائل الرئيسية.


تحليل بيانات RCS باستخدام تتبع جوجل

كيف أثرت التغييرات على العمل مع المواقع الحقيقية؟

دعونا نلقي نظرة على بعض الأمثلة عن كيفية تأثير معالجة النصوص البرمجية في تصفح المواقع الحقيقية.

▍Reddit

عرض reddit.com على MacBook Pro. حان الوقت لتحليل وتجميع كود JS الذي تم إنفاقه في المواضيع الرئيسية وفي سلاسل العمل

هناك العديد من حزم JS على موقع reddit.com ، يتجاوز حجم كل منها 100 كيلو بايت. يتم لفها في وظائف خارجية ، مما يؤدي إلى تنفيذ كميات كبيرة من التجميع "كسول" في الموضوع الرئيسي. المهم في المخطط أعلاه هو الوقت اللازم لمعالجة البرامج النصية في الموضوع الرئيسي. ويرجع ذلك إلى حقيقة أن التحميل الكبير على سلسلة الرسائل الرئيسية يمكن أن يزيد من الوقت الذي تستغرقه الصفحة للتبديل إلى الوضع التفاعلي. عند معالجة رمز موقع reddit.com ، يتم قضاء معظم الوقت في سلسلة الرسائل الرئيسية ، ويتم استخدام موارد سلسلة العمل / الخلفية إلى الحد الأدنى.

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

▍Facebook

عرض facebook.com على جهاز MacBook Pro الخاص بك. حان الوقت لتحليل وتجميع كود JS الذي تم إنفاقه في المواضيع الرئيسية وفي سلاسل العمل

يمكننا أيضًا النظر في موقع مثل facebook.com ، والذي يستخدم حوالي 6 ميغابايت من كود JS المضغوط. يتم تحميل هذا الرمز باستخدام 292 طلبًا تقريبًا. بعضها غير متزامن ، وبعضها يهدف إلى تحميل البيانات مسبقًا ، وبعضها له أولوية منخفضة. معظم البرامج النصية على Facebook صغيرة الحجم وذات تركيز ضيق. هذا يمكن أن يكون له تأثير جيد على معالجة البيانات الموازية عن طريق الخلفية / تدفقات العمل. والحقيقة هي أن العديد من البرامج النصية الصغيرة يمكن تحليلها وتجميعها في نفس الوقت عن طريق تدفق معالجة النصوص.

يرجى ملاحظة أن موقعك مختلف على الأرجح عن موقع Facebook. من المحتمل ألا يكون لديك تطبيقات تظل مفتوحة لفترة طويلة (مثل موقع Facebook أو واجهة Gmail) ، وعند العمل معها ، قد يكون هناك ما يبرر تنزيل مثل هذه الكميات الخطيرة من البرامج النصية باستخدام متصفح سطح المكتب. ولكن على الرغم من ذلك ، يمكننا تقديم توصية عامة منصفة لأي مشاريع. يكمن في حقيقة أن الأمر يستحق تقسيم رمز التطبيق إلى حزم متواضعة ، وأنك تحتاج إلى تنزيل هذه الحزم فقط عندما تكون هناك حاجة إليها.

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

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

JSON تحليل السعر

تحليل كود JSON يمكن أن يكون أكثر فاعلية من تحليل كود JavaScript. الشيء أن قواعد JSON أبسط بكثير من قواعد جافا سكريبت JavaScript. يمكن تطبيق هذه المعرفة لتحسين سرعة التحضير لعمل تطبيقات الويب التي تستخدم كائنات التكوين الكبيرة (مثل مستودعات Redux) ، والتي يشبه هيكلها كود JSON. نتيجة لذلك ، اتضح أنه بدلاً من تقديم البيانات كحرفيات مضمنة في الكود ، يمكنك تمثيلها كسلسلة من كائنات JSON وتحليل هذه الكائنات في وقت التشغيل.

الطريقة الأولى ، باستخدام كائنات JS ، تبدو كما يلي:

 const data = { foo: 42, bar: 1337 }; //  

النهج الثاني ، باستخدام سلاسل JSON ، ينطوي على استخدام مثل هذه البنيات:

 const data = JSON.parse('{"foo":42,"bar":1337}'); //  

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

استخدام حرفية الكائن كتخزين لكميات كبيرة من البيانات يشكل تهديدا آخر. النقطة المهمة هي أن هناك خطرًا في إمكانية معالجة هذه القيم الحرفية مرتين:

1. يتم تنفيذ ممر المعالجة الأول بالتحليل الأولي للحرف.
2. يتم تنفيذ النهج الثاني أثناء تحليل "كسول" الحرفي.

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

ماذا عن تحليل وتجميع التعليمات البرمجية في الزيارات المتكررة للمواقع؟

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


كود نظام التخزين المؤقت في V8

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

النتائج

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

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

أعزائي القراء! هل تقوم بتحسين مشاريع الويب الخاصة بك مع مراعاة خصائص معالجة JS-code بواسطة المتصفحات الحديثة؟