تحسين بدء تشغيل JavaScript

Addy Osmani
Addy Osmani

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

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

عندما يطلب المتصفح موردًا،
يجب جلب هذا المورد ثم فك ضغطه. في حالة الموارد مثل JavaScript، يجب تحليلها وتجميعها قبل التنفيذ.

قد تكون هذه مشكلة، حيث إن نوع الاتصال الفعال بالشبكة لدى المستخدم قد لا يكون في الواقع من شبكة الجيل الثالث أو شبكة الجيل الرابع أو شبكة Wi-Fi. يمكنك الاتصال بشبكة Wi-Fi في أحد المقاهي ولكنك متصل بنقطة اتصال خلوية بسرعة 2G.

يمكنك خفض تكلفة نقل بيانات JavaScript عبر الشبكة من خلال:

  • إرسال الرمز الذي يحتاجه المستخدم فقط:
  • تقليل البيانات
  • الضغط
    • على الأقل، استخدم gzip لضغط الموارد النصية.
    • يمكنك استخدام Botli ~q11. يتفوّق Brotli على سرعة gzip من خلال نسبة الضغط. فقد ساعد ذلك CertSimple في توفير 17% من حجم وحدات بايت JS المضغوطة وتوفير 4% من أوقات التحميل على LinkedIn.
  • إزالة الرموز غير المستخدَمة:
  • تخزين الرمز مؤقتًا لتقليل رحلات الشبكة:
    • استخدِم التخزين المؤقت لبروتوكول HTTP لضمان عمل استجابات ذاكرة التخزين المؤقت للمتصفحات بشكل فعّال. يمكنك تحديد فترات العمر المثالية للنصوص البرمجية (الحدّ الأقصى للعمر) والرموز المميّزة لإثبات صحة بيانات الاعتماد (ETag) لتجنُّب نقل وحدات البايت غير المتغيرة.
    • يمكن أن يساعد التخزين المؤقت "لمشغّلي الخدمات" في مرونة شبكة تطبيقاتك ومنحك إمكانية استخدام ميزات مثل ذاكرة التخزين المؤقت لرموز V8.
    • استخدِم التخزين المؤقت طويل المدى لتجنّب الاضطرار إلى إعادة جلب الموارد التي لم تتغيّر. في حال استخدام Webpack، راجِع تجزئة أسماء الملفات.

التحليل/التجميع

وبعد التنزيل، يُعتبر وقت تحليل/تجميع هذا الرمز أحد أثقل تكاليف JavaScript. في Chrome DevTools، يكون التحليل والتجميع جزءًا من وقت "البرمجة النصية" باللون الأصفر في لوحة "الأداء".

ALT_TEXT_HERE

تعرض لك علامتا التبويب "من أسفل إلى أعلى" و"شجرة المكالمات" التوقيتات الدقيقة للتحليل/التجميع:

ALT_TEXT_HERE
Chrome لوحة أداء أدوات مطوّري البرامج في Chrome > من أسفل إلى أعلى. من خلال تفعيل "إحصاءات مكالمات وقت التشغيل" في V8، يمكننا معرفة الوقت المقضي على مراحل مثل التحليل والتجميع

ولكن ما هي أهميّة ذلك؟

ALT_TEXT_HERE

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

وحدة بايت لكل بايت، تعتبر معالجة JavaScript أكثر تكلفة في المتصفح من الصورة أو خط الويب ذي الحجم المكافئ — توم ديل

مقارنةً بJavaScript، هناك العديد من التكاليف التي تنتج عن معالجة الصور ذات الأحجام المتساوية (يجب فك ترميزها أيضًا)، ولكن في المتوسط، من المرجح أن يؤثر JavaScript سلبًا على تفاعل الصفحة بشكل سلبي،

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

عندما نتحدث عن بطء التحليل والتجميع، يكون السياق مهمًا. سنتحدث هنا عن الهواتف الجوّالة المتوسطة. قد يكون لدى المستخدمين العاديين هواتف ذات وحدات معالجة مركزية (CPU) ووحدة معالجة رسومات بطيئة، بدون ذاكرة تخزين مؤقت من L2/L3 والتي قد تكون محدودة في الذاكرة.

لا تتطابق إمكانات الشبكة مع إمكانات الجهاز دائمًا. ليس بالضرورة أن يمتلك المستخدم الذي لديه اتصال رائع عبر الألياف الضوئية أفضل وحدة معالجة مركزية (CPU) لتحليل وتقييم JavaScript المُرسَل إلى جهازه. وهذا يحدث أيضًا بالعكس... اتصال شبكة سيئ، ووحدة معالجة مركزية (CPU) سريعة للغاية. — كريستوفر باكستر، LinkedIn

تظهر لنا أدناه تكلفة تحليل حوالى 1 ميغابايت من ملفات JavaScript (البسيطة) على الأجهزة المنخفضة الجودة والعالية المستوى. هناك فرق بمقدار 2 إلى 5 مرات في الوقت اللازم لتحليل/تجميع الرموز بين أسرع الهواتف في السوق والهواتف العادية.

ALT_TEXT_HERE
يسلّط هذا الرسم البياني الضوء على مدة التحليل لحزمة JavaScript بحجم 1 ميغابايت (حوالي 250 كيلوبايت في ضغط gzip) على أجهزة الكمبيوتر المكتبي والأجهزة الجوّالة من فئات مختلفة. عند النظر إلى تكلفة التحليل، نجد أنّ الأشكال غير المضغوطة التي يجب أخذها في الاعتبار، على سبيل المثال، يتم فك ضغط ملف JS المضغوط بحجم 250 كيلوبايت تقريبًا إلى 1 ميغابايت تقريبًا من الرمز.

ماذا عن موقع في العالم الحقيقي، مثل CNN.com؟

على هواتف iPhone 8 المتطورة، يتطلب الأمر حوالي 4 ثوانٍ فقط لتحليل/تجميع JS من CNN مقارنةً بحوالي 13 ثانية للهاتف العادي (Moto G4). يمكن أن يؤثر هذا بشكل كبير في مدى سرعة تفاعل المستخدم بشكل كامل مع هذا الموقع.

ALT_TEXT_HERE
كما يظهر هنا، تظهر إحصاءات تقارن بين أداء شريحة A11 Bionic من Apple وSnapdragon 617 في أجهزة Android المتوسطة الأعلى.

وهذا يسلط الضوء على أهمية الاختبار على الأجهزة المتوسطة (مثل Moto G4) بدلاً من الهاتف الذي قد يكون في جيبك فقط. ومع ذلك، للسياق أهمية: يمكنك تحسين حالات الجهاز والشبكة التي يمتلكها المستخدمون.

ALT_TEXT_HERE
يمكن أن توفر خدمة "إحصاءات Google" إحصاءات حول فئات الأجهزة الجوّالة التي يصل المستخدمون من خلالها إلى موقعك الإلكتروني. وقد يوفّر ذلك فرصًا لفهم القيود الفعلية التي تفرضها وحدة المعالجة المركزية (CPU)/وحدة معالجة الرسومات التي يتعاملون معها.

هل نرسل الكثير من محتوى JavaScript؟ خطأ، ربما :)

من خلال استخدام أرشيف HTTP (أهم 500 ألف موقع إلكتروني) لتحليل حالة JavaScript على الأجهزة الجوّالة، نلاحظ أنّ 50% من المواقع الإلكترونية تستغرق أكثر من 14 ثانية للتفاعل. وتقضي هذه المواقع الإلكترونية ما يصل إلى 4 ثوانٍ في تحليل وتجميع JavaScript.

ALT_TEXT_HERE

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

يمكن أن تؤدي إزالة محتوى JavaScript غير المُهم من صفحاتك إلى تقليل أوقات الإرسال والتحليل الذي تستهلكه وحدة المعالجة المركزية (CPU) وتجميع البيانات، بالإضافة إلى الحد من الاستخدام المحتمل للذاكرة. يساعد ذلك أيضًا في زيادة سرعة تفاعل صفحاتك.

وقت التنفيذ

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

ALT_TEXT_HERE

في حال تنفيذ النص البرمجي لمدة تزيد عن 50 ملي ثانية، يتأخر وقت التفاعل بمقدار الكامل من الوقت المستغرق لتنزيل JavaScript وتجميعها وتنفيذها، أليكس راسل

لحلّ هذه المشكلة، تكون لغة JavaScript في أجزاء صغيرة لتجنُّب قفل سلسلة التعليمات الرئيسية. اكتشف ما إذا كان بإمكانك تقليل مقدار العمل الذي يتم إنجازه أثناء التنفيذ.

التكاليف الأخرى

يمكن أن تؤثر لغة JavaScript في أداء الصفحة بطرق أخرى:

  • الذاكرة قد تبدو الصفحات متوقِّفة أو تتوقف مؤقتًا بشكل متكرر بسبب تجميع البيانات المهملة. عندما يستعيد المتصفّح الذاكرة، يتم إيقاف عملية تنفيذ JavaScript مؤقتًا، وبالتالي يمكن لأي متصفّح يجمع البيانات غير المهمة بشكل متكرر إيقاف التنفيذ مؤقتًا أكثر مما قد نرغب في ذلك. تجنَّب تسرُّب الذاكرة والتوقفات المتكررة المتكررة للذاكرة لإبقاء الصفحات خالية من المحتوى غير المهم.
  • أثناء وقت التشغيل، يمكن أن تحظر لغة JavaScript التي تم تشغيلها لفترة طويلة سلسلة التعليمات الرئيسية التي تتسبب في عدم استجابة الصفحات. يمكن أن يؤدي تقسيم العمل إلى أجزاء أصغر (باستخدام requestAnimationFrame() أو requestIdleCallback() لجدولة) إلى تقليل مشاكل الاستجابة، ما يساعد في تحسين مدى استجابة الصفحة لتفاعلات المستخدم (INP).

أنماط لخفض تكلفة تسليم JavaScript

عند محاولة الحفاظ على بطء أوقات إرسال الشبكة للتحليل/التجميع والإرسال عبر الشبكة للغة JavaScript، هناك أنماط يمكن أن تساعد مثل التقسيم المستند إلى المسار أو PRPL.

بروتوكول PRPL

PRPL (الدفع، وعرض، وذاكرة التخزين المؤقت المسبق، والتحميل الكسول) هو نمط يحسّن التفاعل من خلال التقسيم الحاد للرموز والتخزين المؤقت:

ALT_TEXT_HERE

دعونا نتصور التأثير الذي يمكن أن تحدثه.

نحلّل وقت تحميل المواقع الإلكترونية الشائعة للأجهزة الجوّالة وتطبيقات الويب التقدّمية باستخدام "إحصاءات مكالمات وقت التشغيل" في الإصدار 8. يتّضح لنا أنّ تحليل الوقت (المعروض باللون البرتقالي) هو جزء مهم من الموقع الإلكتروني الذي يقضي فيه العديد من هذه المواقع الإلكترونية وقته:

ALT_TEXT_HERE

Wego، وهو موقع إلكتروني يستخدم PRPL، ينجح في الحفاظ على وقت تحليل منخفض لمساراته، ما يتيح له التفاعل بسرعة كبيرة. اعتمدت العديد من المواقع الإلكترونية الأخرى أعلاه ميزانيات تقسيم الرموز والأداء لمحاولة خفض تكاليف JavaScript.

تجميع عينات عشوائية لتوقّع النتائج

فالعديد من المواقع الإلكترونية تحسّن إمكانية رؤية المحتوى بتكلفة التفاعل المكلفة. للحصول على سرعة عرض الصفحة عند توفُّر حِزم JavaScript كبيرة، يستخدم المطوِّرون أحيانًا العرض من جهة الخادم ثم "ترقيته" لإرفاق معالِجات الأحداث عند استرجاع JavaScript في النهاية.

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

وقد يكون التجميع التدريجي التدريجي منهجًا أفضل. أرسل صفحة ذات وظائف بسيطة (تتألف فقط من HTML/JS/CSS المطلوب للمسار الحالي). مع توفُّر المزيد من الموارد، يمكن للتطبيق استخدام ميزة "التحميل الكسول" والاستفادة من المزيد من الميزات.

ALT_TEXT_HERE
تعزيز القوة التدريجية من تأليف "بول لويس"

إنّ تحميل الرموز بما يتناسب مع ما هو معروض هو الكأس المقدس. وPRPL والبدء التمهيد التدريجي عبارة عن أنماط يمكن أن تساعد في تحقيق ذلك.

الاستنتاجات

يعدّ حجم الإرسال مهمًا للشبكات المنخفضة النهاية. يُعد وقت التحليل مهمًا للأجهزة المرتبطة بوحدة المعالجة المركزية (CPU). ننصحك بعدم بذل مجهود كبير.

لاقت الفرق نجاحًا في اعتماد ميزانيات أداء صارمة للحفاظ على انخفاض أوقات نقل JavaScript والتحليل أو التجميع. راجع كتاب أليكس راسل بعنوان "Can You Afford It?: ميزانيات أداء الويب الفعلي" للحصول على إرشادات بشأن ميزانيات الأجهزة الجوّالة.

ALT_TEXT_HERE
من المفيد أن نأخذ في الاعتبار مقدار "المساحة المتزايدة" في JavaScript التي نتخذها بشأن بنية التطبيقات، ما يمكن أن يتركنا نتراجع عن منطق التطبيق.

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

مزيد من المعلومات