🕍 🖕🏾 💶 سعر JavaScript 2018 ⚔️ 🧑🏽‍🤝‍🧑🏽 👩🏻‍⚖️

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

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

أحكام عامة

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

الوقت المستغرق في معالجة كود cnn.com JS لمختلف الأجهزة

كما ترى ، يتطابق هاتف متطور (iPhone 8) مع مهمة معالجة كود JS في حوالي 4 ثوانٍ. يحتاج الهاتف متوسط المدى (Moto G4) إلى حوالي 13 ثانية لحل نفس المشكلة. تستغرق الميزانية ، على الرغم من أنها جهاز حديث ، مثل Alcatel 1X ، حوالي 36 ثانية.

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

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

مشاريع الويب الحديثة ومشكلة الاستخدام المفرط لجافا سكريبت

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

هذا ما يبدو عليه المتصفح ، وهو مليء بالملفات

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

جافا سكريبت هي أصعب جزء في الموقع

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

تصبح الصفحة المتوسطة التي تحتوي على 350 كيلوبايت من كود JS المضغوط تفاعلية على جهاز محمول في حوالي 15 ثانية

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

يساهم وقت تنزيل البيانات على شبكات الجوال ومعالجتها على معالج غير سريع في تقديم مساهمة جادة أثناء انتظار الصفحة ليتم تجهيزها للعمل على الأجهزة المحمولة.

دعونا نحلل الوضع في مجال شبكات المحمول من خلال النظر في بيانات OpenSignal . يوضح الشكل التالي ، على اليسار ، مدى توفر شبكات 4G في العالم (كلما كان اللون أغمق حيث يتم رسم أراضي الدولة - كلما زاد التوفر) ، تظهر سرعات نقل البيانات على اليمين (مرة أخرى - كلما كانت السرعة أغمق). البلدان التي تكون أراضيها رمادية اللون غير مدرجة في الدراسة. تجدر الإشارة إلى أنه في المناطق الريفية ، حتى في الولايات المتحدة الأمريكية ، يمكن أن تكون سرعة نقل البيانات المحمولة أبطأ بنسبة 20٪ من المدن.

توفر شبكة 4G ومعدل البيانات

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

أحجام تجميع JavaScript غير مغلفة لمختلف الموارد

كما ترى ، على كل من أنظمة سطح المكتب والجوّال ، يجب على المتصفحات أحيانًا معالجة عدة ميغابايت من كود JS للعمل مع مواقع مختلفة. السؤال الرئيسي هنا هو - هل يمكنك استخدام مثل هذه الأحجام الكبيرة من جافا سكريبت؟

جافا سكريبت ليست مجانية

وفقًا لـ Alex Russell ، فإن المواقع التي تتطلب كميات كبيرة جدًا من جافا سكريبت لتعمل ببساطة لا يمكن الوصول إليها من قبل طبقات واسعة من المستخدمين. وفقًا للإحصاءات ، لا ينتظر المستخدمون (ولن ينتظروا) لتحميل هذه الموارد.

هل تستطيع ذلك؟

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

غالبًا ما تتضمن حزم JS من المواقع الحديثة ما يلي:

إطار عمل العميل أو مكتبة واجهة المستخدم.
أداة لإدارة حالة التطبيق (على سبيل المثال ، Redux).
Polyfills (غالبًا للمتصفحات الحديثة التي لا تحتاجها).
إصدارات كاملة من المكتبات ، وليس فقط الأجزاء التي يتم استخدامها بالفعل (على سبيل المثال ، مكتبة Lodash بأكملها ، مكتبة Moment.js في الإصدار مع دعم جميع المعايير الإقليمية).
مجموعة من مكونات واجهة المستخدم (الأزرار والعناوين والأشرطة الجانبية وما إلى ذلك).

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

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

هل هذا يحدث؟ (هل هذا يحدث؟).
ما فائدة هذا؟ (هل هي مفيدة؟).
هل يمكن استخدام هذا؟ (هل يمكن استخدامها؟).

إليك كيفية تخيل هذه الخطوات ، والتي بدورها يمكن تقسيمها إلى "إطارات" أصغر ، إذا واصلنا القياس مع الفيلم.

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

عملية تحميل صفحة الويب

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

الصفحات التفاعلية ومشاكلها

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

ينزعج المستخدمون من الصفحات التي تستغرق وقتًا طويلاً للغاية للاستعداد

لكي تكون الصفحة تفاعلية ، يجب أن تكون قادرة على الاستجابة بسرعة لتفاعلات المستخدم. تساعد الكميات الصغيرة من كود JS التي تشغل الصفحات على تقليل الوقت اللازم لإعداد الصفحات للعمل.

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

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

تقرير المنارة ، والذي يتضمن مؤشرات تعكس تصور المستخدم للصفحة

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

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

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

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

حاول التقليل من المواقف التي قد يتم فيها حظر الخيط الرئيسي. فيما يلي المواد التي يمكنك العثور على تفاصيل حولها.

نرى كيف تعاني الفرق التي نعمل معها من عمل جافا سكريبت على TTI في العديد من أنواع المواقع.

جافا سكريبت قادرة على تأخير إخراج العناصر المرئية في الوضع التفاعلي

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

TTI والأجهزة المحمولة

إليك TTIs لـ news.google.com عند استخدام اتصال إنترنت 3G بطيء. هنا يمكنك رؤية البيانات التي تم بناء هذا المخطط على أساسها. يتم إجراء القياسات عن طريق WebPageTest والمنارة.

TTI لـ news.google.com

بعد تحليل هذه البيانات ، يمكنك أن ترى أن هناك فجوة خطيرة بين الأجهزة من الفئات الأدنى والأعلى. لذا ، فإن أقوى جهاز في اختبار TTI هو حوالي 7 ثوانٍ. على أبسط - إنها بالفعل 55 ثانية.

هنا لدينا سؤال حول ما يجب أن يكون TTI. نعتقد أنه يجب عليك السعي لجعل الصفحات أكثر تفاعلية على الأجهزة متوسطة المدى المتصلة بشبكات 3G البطيئة في أقل من 5 ثوانٍ.

يجدر بنا السعي إلى TTI في 5 ثوان

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

تأثير تقليص شفرة JS على TTI

في ما يلي بعض الأمثلة عن كيفية تأثير تقليل حجم رمز صفحة JS على TTI.

قلل مشروع Pinterest حزم JS من 2.5 ميغابايت إلى أقل من 200 كيلوبايت. انخفض وقت التفاعل من 23 ثانية إلى 5.6 ثانية. نمت إيرادات الشركة بنسبة 44٪ ، وزاد عدد الاشتراكات بنسبة 753٪ ، وارتفع عدد المستخدمين الأسبوعيين النشطين لنسخة الهاتف المحمول من الموقع بنسبة 103٪.
قامت AutoTrader بتخفيض حزمة JS بنسبة 56٪ ، مما أدى إلى انخفاض TTI بحوالي 50٪.
قلل مورد Nikkei.com حجم حزمة JS بنسبة 43٪ ، مما سمح بتحسين TTI بمقدار 14 ثانية.

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

يعتمد تصميم المواقع على بيئة متنقلة مرنة

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

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

لماذا جافا سكريبت باهظة الثمن؟

لفهم لماذا يمكن أن يؤدي إعداد شفرة JavaScript للصفحات إلى إنشاء حمل ضخم على النظام ، فلنتحدث عما يحدث عندما يرسل الخادم البيانات إلى المتصفح.

لذلك ، يبدأ كل شيء بحقيقة أن المستخدم يدخل عنوان URL الخاص بالموقع الذي يريد الدخول إليه في شريط عنوان المتصفح.

يبدأ كل شيء بإدخال عنوان URL في شريط عنوان المتصفح

يتم بعد ذلك إرسال الطلب إلى الخادم ، الذي يعيد ترميز HTML إلى المستعرض. يقوم المتصفح بتحليل هذا الترميز والعثور على الموارد اللازمة لتكوين الصفحة: CSS و JavaScript والصور. ثم يحتاج المتصفح إلى طلب كل هذا من الخادم ومعالجته.
في هذا السيناريو ، يحدث كل شيء ، على سبيل المثال ، عند العمل مع Google Chrome.

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

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

كيف تسريع العمل مع جافا سكريبت؟

يمكن تقسيم مهمة تسريع JavaScript إلى عدة مهام فرعية. الوقت المستغرق في كل ما يتعلق بـ JS هو مجموع الحمل والتحليل وتجميع وتنفيذ التعليمات البرمجية.

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

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

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

تستغرق خطوات التحليل والتجميع 10-30٪ من الوقت في V8 عند تحميل الصفحة

يتم تمييز الأجزاء التي تمثل الوقت المطلوب لتحليل رمز المواقع الشائعة باللون البرتقالي. يمثل اللون الأصفر وقت التجميع. وتستغرق هاتان المرحلتان معًا حوالي 30٪ من إجمالي الوقت اللازم لمعالجة شفرة JS للصفحة. 30٪ هو رقم خطير.

في Chrome 66 ، يجمع V8 الشفرة في سلسلة المحادثات الخلفية ، والتي يمكن أن توفر ما يصل إلى 20٪ من وقت الترجمة. ومع ذلك ، لا يزال التحليل والتجميع عمليات مكلفة للغاية ، لذلك نادرًا ما ترى نصًا كبيرًا يبدأ في التنفيذ في أقل من 50 مللي ثانية. بعد التحميل ، حتى لو تم تجميعه في سلسلة المحادثات الخلفية.

كيف تختلف جافا سكريبت عن الموارد الأخرى؟

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

200 كيلوبايت من كود JavaScript وملف JPEG من نفس الحجم هما شيئان مختلفان.

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

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

الويب للجوال وتنوع الجهاز

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

الأجهزة المحمولة المختلفة

إذا سارت الظروف على ما يرام ، فسيتعين على الموقع العمل على أجهزة متوسطة وعالية المستوى. ومع ذلك ، في الواقع ، ليس كل المستخدمين لديهم مثل هذه الأجهزة.

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

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

فيما يلي نتائج دراسة حول هواتف Android الذكية المستخدمة حاليًا بواسطة newzoo . كما ترى ، تم تثبيت نظام التشغيل Android على 75.9٪ من الهواتف المستخدمة ، في حين أنه من المتوقع أنه في عام 2018 سيتم إضافة 300 مليون جهاز آخر إليها. سيكون العديد من هذه الأجهزة الجديدة مناسبًا للميزانية.

هواتف Android الذكية في 2018

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

الوقت المطلوب للمعالجة (التحليل والتجميع) 1 ميجابايت من كود JS غير المضغوط (على سبيل المثال ، يمكن أن يكون حوالي 200 كيلوبايت من التعليمات البرمجية المصغرة مضغوطة باستخدام gzip). تم إجراء القياسات يدويًا على الأجهزة الحقيقية.

في الجزء العلوي من الرسم البياني توجد أجهزة من الدرجة الأولى ، مثل iPhone 8 ، التي تعالج البرامج النصية بسرعة نسبية. إذا نزلت إلى الأسفل ، فهناك بالفعل أجهزة متوسطة المدى ، مثل Moto G4 ، و Alcatel 1X البسيط جدًا. الفرق بين هذه الأجهزة مرئي للعين المجردة.

بمرور الوقت ، تصبح الهواتف التي تعمل بنظام Android أرخص ، ولكنها ليست أسرع . عادةً ما تستخدم الهواتف الرخيصة معالجات ضعيفة مع ذاكرة تخزين مؤقت صغيرة L2 / L3. ونتيجة لذلك ، إذا ركزت على الأجهزة ذات المستوى الأعلى ، يمكنك تجاهل احتياجات المستخدم العادي الذي ليس لديه مثل هذا الجهاز.

دعونا نعود على سبيل المثال مع موقع حقيقي ، قد لمسناه بالفعل. تم تنفيذ القياسات باستخدام WebPageTest ، وهنا بيانات المصدر.

الوقت المستغرق في معالجة كود cnn.com JS لمختلف الأجهزة

على iPhone 8 (باستخدام شريحة A11 ) ، تستغرق المعالجة 9 ثوانٍ أسرع من هاتف متوسط المدى. نحن نتحدث عن حقيقة أن الموقع على iPhone 8 سيكون تفاعليًا قبل 9 ثوانٍ.

الآن ، عندما يدعم WebPageTest Alcatel 1X (تم بيع هذا الهاتف في الولايات المتحدة مقابل 100 دولار تقريبًا ، تم بيعه في بداية المبيعات) ، يمكننا رؤية " لوحة العمل " لموقع cnn.com للتحميل على الهواتف ذات المستوى المبتدئ والمتوسط. قامت Alcatel 1X بتحميل الموقع بالكامل باستخدام شبكة 3G في 65 ثانية. حتى أنها ليست "بطيئة". هذا ببساطة غير مقبول.

قم بتنزيل cnn.com مع Alcatel 1X و Moto G gen 1 و Moto G4

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

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

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

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

مواقع الاختبار على أجهزة حقيقية متصلة بشبكات حقيقية

إذا لم يكن الخيار الخاص بهاتفك متوسط المدى مناسبًا لك ، فإن مشروع WebPageTest يتيح الوصول إلى هواتف Moto G4 المخصصة عند اختيار تكوينات اختبار الهاتف المحمول. هناك تكوينات أخرى هناك.

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

اعرف جمهورك

وتجدر الإشارة إلى أنه لا يجب أن يعمل كل موقع بشكل جيد على جهاز مبتدئ متصل بشبكة 2G. , — .

, , Google Analytics → Audience → Mobile → Devices. .

Google Analytics

, . — , , , , .

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );