في إطار تطوير المواقع الإلكترونية التي تعتمد بشكل أكبر على JavaScript، ندفع أحيانًا مقابل ما نرسله بطرق يصعب علينا رؤيتها في بعض الأحيان. سنتحدّث في هذه المقالة عن أهمية الانتظام في تحميل الموقع الإلكتروني والتفاعل بسرعة على الأجهزة الجوّالة على الأجهزة الجوّالة. قد يؤدي تقديم عدد أقل من رموز JavaScript إلى استهلاك وقت أقل في نقل بيانات الشبكة، وتقليل الوقت الذي يتم استغراقه في فك ضغط الرموز البرمجية، وتقليل الوقت اللازم في تحليل محتوى JavaScript وتجميعه.
الشبكة
عندما يفكر معظم مطوّري البرامج في تكلفة JavaScript، يفكرون فيها من حيث تكلفة التنزيل والتنفيذ. يستغرق إرسال المزيد من وحدات بايت من JavaScript عبر السلك وقتًا أطول كلّما كان اتصال المستخدم أبطأ.
قد تكون هذه مشكلة، حيث إن نوع الاتصال الفعال بالشبكة لدى المستخدم قد لا يكون في الواقع من شبكة الجيل الثالث أو شبكة الجيل الرابع أو شبكة Wi-Fi. يمكنك الاتصال بشبكة Wi-Fi في أحد المقاهي ولكنك متصل بنقطة اتصال خلوية بسرعة 2G.
يمكنك خفض تكلفة نقل بيانات JavaScript عبر الشبكة من خلال:
- إرسال الرمز الذي يحتاجه المستخدم فقط:
- استخدِم ميزة تقسيم الرموز لتقسيم JavaScript إلى محتوى مهم وغير مهم. تتوافق حِزم الوحدات، مثل webpack، مع تقسيم الرموز البرمجية.
- يتم التحميل الكسول في الرمز البرمجي غير المُهم.
- تقليل البيانات
- استخدِم UglifyJS لتصغير رمز ES5.
- استخدِم babel-minify أو uglify-es لتصغير ES2015+.
- الضغط
- إزالة الرموز غير المستخدَمة:
- حدِّد الفرص المتاحة للرموز البرمجية التي يمكن إزالتها أو تحميلها ببطء باستخدام تغطية الرموز البرمجية في "أدوات مطوّري البرامج".
- استخدِم babel-preset-env وقائمة المتصفِّح لتجنُّب ترجمة الميزات المتوفّرة في المتصفِّحات الحديثة. قد يجد المطوّرون المتقدمون أنّ التحليل الدقيق لحِزم حِزم الويب يساعد في تحديد الفرص المتوفّرة لتقليص التبعيات غير الضرورية.
- بالنسبة إلى إزالة الرمز، يُرجى الاطّلاع على التعديلات المتقدمة في Closure Compiler والمكوّنات الإضافية لقطع المكتبة مثل lodash-babel-extension أو ContextReplacementPlugin للمكتبات مثل Moment.js.
- تخزين الرمز مؤقتًا لتقليل رحلات الشبكة:
- استخدِم التخزين المؤقت لبروتوكول HTTP لضمان عمل استجابات ذاكرة التخزين المؤقت للمتصفحات بشكل فعّال. يمكنك تحديد فترات العمر المثالية للنصوص البرمجية (الحدّ الأقصى للعمر) والرموز المميّزة لإثبات صحة بيانات الاعتماد (ETag) لتجنُّب نقل وحدات البايت غير المتغيرة.
- يمكن أن يساعد التخزين المؤقت "لمشغّلي الخدمات" في مرونة شبكة تطبيقاتك ومنحك إمكانية استخدام ميزات مثل ذاكرة التخزين المؤقت لرموز V8.
- استخدِم التخزين المؤقت طويل المدى لتجنّب الاضطرار إلى إعادة جلب الموارد التي لم تتغيّر. في حال استخدام Webpack، راجِع تجزئة أسماء الملفات.
التحليل/التجميع
وبعد التنزيل، يُعتبر وقت تحليل/تجميع هذا الرمز أحد أثقل تكاليف JavaScript. في Chrome DevTools، يكون التحليل والتجميع جزءًا من وقت "البرمجة النصية" باللون الأصفر في لوحة "الأداء".
تعرض لك علامتا التبويب "من أسفل إلى أعلى" و"شجرة المكالمات" التوقيتات الدقيقة للتحليل/التجميع:
ولكن ما هي أهميّة ذلك؟
قد يؤدي قضاء وقت طويل في التحليل/تجميع الرمز إلى تأخير كبير في سرعة تفاعل المستخدم مع موقعك. وكلما زاد عدد رموز JavaScript التي ترسلها، استغرق تحليلها وتجميعها وقتًا أطول قبل أن يصبح موقعك تفاعليًا.
وحدة بايت لكل بايت، تعتبر معالجة JavaScript أكثر تكلفة في المتصفح من الصورة أو خط الويب ذي الحجم المكافئ — توم ديل
مقارنةً بJavaScript، هناك العديد من التكاليف التي تنتج عن معالجة الصور ذات الأحجام المتساوية (يجب فك ترميزها أيضًا)، ولكن في المتوسط، من المرجح أن يؤثر JavaScript سلبًا على تفاعل الصفحة بشكل سلبي،
عندما نتحدث عن بطء التحليل والتجميع، يكون السياق مهمًا. سنتحدث هنا عن الهواتف الجوّالة المتوسطة. قد يكون لدى المستخدمين العاديين هواتف ذات وحدات معالجة مركزية (CPU) ووحدة معالجة رسومات بطيئة، بدون ذاكرة تخزين مؤقت من L2/L3 والتي قد تكون محدودة في الذاكرة.
لا تتطابق إمكانات الشبكة مع إمكانات الجهاز دائمًا. ليس بالضرورة أن يمتلك المستخدم الذي لديه اتصال رائع عبر الألياف الضوئية أفضل وحدة معالجة مركزية (CPU) لتحليل وتقييم JavaScript المُرسَل إلى جهازه. وهذا يحدث أيضًا بالعكس... اتصال شبكة سيئ، ووحدة معالجة مركزية (CPU) سريعة للغاية. — كريستوفر باكستر، LinkedIn
تظهر لنا أدناه تكلفة تحليل حوالى 1 ميغابايت من ملفات JavaScript (البسيطة) على الأجهزة المنخفضة الجودة والعالية المستوى. هناك فرق بمقدار 2 إلى 5 مرات في الوقت اللازم لتحليل/تجميع الرموز بين أسرع الهواتف في السوق والهواتف العادية.
ماذا عن موقع في العالم الحقيقي، مثل CNN.com؟
على هواتف iPhone 8 المتطورة، يتطلب الأمر حوالي 4 ثوانٍ فقط لتحليل/تجميع JS من CNN مقارنةً بحوالي 13 ثانية للهاتف العادي (Moto G4). يمكن أن يؤثر هذا بشكل كبير في مدى سرعة تفاعل المستخدم بشكل كامل مع هذا الموقع.
وهذا يسلط الضوء على أهمية الاختبار على الأجهزة المتوسطة (مثل Moto G4) بدلاً من الهاتف الذي قد يكون في جيبك فقط. ومع ذلك، للسياق أهمية: يمكنك تحسين حالات الجهاز والشبكة التي يمتلكها المستخدمون.
هل نرسل الكثير من محتوى JavaScript؟ خطأ، ربما :)
من خلال استخدام أرشيف HTTP (أهم 500 ألف موقع إلكتروني) لتحليل حالة JavaScript على الأجهزة الجوّالة، نلاحظ أنّ 50% من المواقع الإلكترونية تستغرق أكثر من 14 ثانية للتفاعل. وتقضي هذه المواقع الإلكترونية ما يصل إلى 4 ثوانٍ في تحليل وتجميع JavaScript.
عليك التفكير في الوقت الذي يستغرقه استرجاع ومعالجة JavaScript والموارد الأخرى، وقد لا يفاجئك أنّ المستخدمين قد ينتظرون بعض الوقت قبل أن يشعروا بأنّ الصفحات جاهزة للاستخدام. يمكننا بالتأكيد القيام بعمل أفضل هنا.
يمكن أن تؤدي إزالة محتوى JavaScript غير المُهم من صفحاتك إلى تقليل أوقات الإرسال والتحليل الذي تستهلكه وحدة المعالجة المركزية (CPU) وتجميع البيانات، بالإضافة إلى الحد من الاستخدام المحتمل للذاكرة. يساعد ذلك أيضًا في زيادة سرعة تفاعل صفحاتك.
وقت التنفيذ
إنه ليس مجرد تحليل وتجميع يمكن أن يكون له تكلفة. تنفيذ JavaScript (تشغيل الرمز بعد تحليله/تجميعه) هو إحدى العمليات التي يجب أن تحدث على سلسلة التعليمات الرئيسية. ويمكن أن تؤدي أوقات التنفيذ الطويلة إلى زيادة سرعة تفاعل المستخدم مع موقعك.
في حال تنفيذ النص البرمجي لمدة تزيد عن 50 ملي ثانية، يتأخر وقت التفاعل بمقدار الكامل من الوقت المستغرق لتنزيل JavaScript وتجميعها وتنفيذها، أليكس راسل
لحلّ هذه المشكلة، تكون لغة JavaScript في أجزاء صغيرة لتجنُّب قفل سلسلة التعليمات الرئيسية. اكتشف ما إذا كان بإمكانك تقليل مقدار العمل الذي يتم إنجازه أثناء التنفيذ.
التكاليف الأخرى
يمكن أن تؤثر لغة JavaScript في أداء الصفحة بطرق أخرى:
- الذاكرة قد تبدو الصفحات متوقِّفة أو تتوقف مؤقتًا بشكل متكرر بسبب تجميع البيانات المهملة. عندما يستعيد المتصفّح الذاكرة، يتم إيقاف عملية تنفيذ JavaScript مؤقتًا، وبالتالي يمكن لأي متصفّح يجمع البيانات غير المهمة بشكل متكرر إيقاف التنفيذ مؤقتًا أكثر مما قد نرغب في ذلك. تجنَّب تسرُّب الذاكرة والتوقفات المتكررة المتكررة للذاكرة لإبقاء الصفحات خالية من المحتوى غير المهم.
- أثناء وقت التشغيل، يمكن أن تحظر لغة JavaScript التي تم تشغيلها لفترة طويلة سلسلة التعليمات الرئيسية التي تتسبب في
عدم استجابة الصفحات. يمكن أن يؤدي تقسيم العمل إلى أجزاء أصغر (باستخدام
requestAnimationFrame()أوrequestIdleCallback()لجدولة) إلى تقليل مشاكل الاستجابة، ما يساعد في تحسين مدى استجابة الصفحة لتفاعلات المستخدم (INP).
أنماط لخفض تكلفة تسليم JavaScript
عند محاولة الحفاظ على بطء أوقات إرسال الشبكة للتحليل/التجميع والإرسال عبر الشبكة للغة JavaScript، هناك أنماط يمكن أن تساعد مثل التقسيم المستند إلى المسار أو PRPL.
بروتوكول PRPL
PRPL (الدفع، وعرض، وذاكرة التخزين المؤقت المسبق، والتحميل الكسول) هو نمط يحسّن التفاعل من خلال التقسيم الحاد للرموز والتخزين المؤقت:
دعونا نتصور التأثير الذي يمكن أن تحدثه.
نحلّل وقت تحميل المواقع الإلكترونية الشائعة للأجهزة الجوّالة وتطبيقات الويب التقدّمية باستخدام "إحصاءات مكالمات وقت التشغيل" في الإصدار 8. يتّضح لنا أنّ تحليل الوقت (المعروض باللون البرتقالي) هو جزء مهم من الموقع الإلكتروني الذي يقضي فيه العديد من هذه المواقع الإلكترونية وقته:
Wego، وهو موقع إلكتروني يستخدم PRPL، ينجح في الحفاظ على وقت تحليل منخفض لمساراته، ما يتيح له التفاعل بسرعة كبيرة. اعتمدت العديد من المواقع الإلكترونية الأخرى أعلاه ميزانيات تقسيم الرموز والأداء لمحاولة خفض تكاليف JavaScript.
تجميع عينات عشوائية لتوقّع النتائج
فالعديد من المواقع الإلكترونية تحسّن إمكانية رؤية المحتوى بتكلفة التفاعل المكلفة. للحصول على سرعة عرض الصفحة عند توفُّر حِزم JavaScript كبيرة، يستخدم المطوِّرون أحيانًا العرض من جهة الخادم ثم "ترقيته" لإرفاق معالِجات الأحداث عند استرجاع JavaScript في النهاية.
توخ الحذر - فهذا له تكاليف خاصة به. يمكنك 1) إرسال استجابة HTML أكبر بشكل عام، ما قد يؤدي إلى زيادة تفاعلنا، 2) يمكن أن يترك المستخدم في وسيل غير مرغوب فيه حيث لا يمكن أن تكون نصف التجربة تفاعلية إلى أن تنتهي معالجة JavaScript.
وقد يكون التجميع التدريجي التدريجي منهجًا أفضل. أرسل صفحة ذات وظائف بسيطة (تتألف فقط من HTML/JS/CSS المطلوب للمسار الحالي). مع توفُّر المزيد من الموارد، يمكن للتطبيق استخدام ميزة "التحميل الكسول" والاستفادة من المزيد من الميزات.
إنّ تحميل الرموز بما يتناسب مع ما هو معروض هو الكأس المقدس. وPRPL والبدء التمهيد التدريجي عبارة عن أنماط يمكن أن تساعد في تحقيق ذلك.
الاستنتاجات
يعدّ حجم الإرسال مهمًا للشبكات المنخفضة النهاية. يُعد وقت التحليل مهمًا للأجهزة المرتبطة بوحدة المعالجة المركزية (CPU). ننصحك بعدم بذل مجهود كبير.
لاقت الفرق نجاحًا في اعتماد ميزانيات أداء صارمة للحفاظ على انخفاض أوقات نقل JavaScript والتحليل أو التجميع. راجع كتاب أليكس راسل بعنوان "Can You Afford It?: ميزانيات أداء الويب الفعلي" للحصول على إرشادات بشأن ميزانيات الأجهزة الجوّالة.
إذا كنت تريد إنشاء موقع إلكتروني يستهدف الأجهزة الجوّالة، ابذل قصارى جهدك للتطوير على أجهزة تمثيلية، واجعل وقت تحليل/تجميع JavaScript منخفضًا، واعتمد ميزانية أداء لضمان قدرة فريقك على مراقبة تكاليف JavaScript الخاصة بهم.
مزيد من المعلومات
- مؤتمر Chrome Dev Summit لعام 2017 - أفضل ممارسات التحميل الحديثة
- أداء بدء التشغيل باستخدام JavaScript
- حلّ أزمات أداء الويب — نولان لوسون
- هل يمكنك دفع ثمنه؟ ميزانيات الأداء في العالم الفعلي — أليكس راسل
- تقييم أطر عمل الويب والمكتبات — كريستوفر باكستر
- نتائج تجربة Cloudflare لها أثناء تجربة الضغط على Brotli (يُرجى العلم أنّ جودة Brotli الديناميكية ذات الجودة الأعلى قد تؤخّر عرض الصفحة الأوّلية، لذا عليك تقييمها بعناية.) ربما ترغب في الضغط بشكل ثابت بدلاً من ذلك).
- الأداء المستقبلي — سام ساكون