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