لا توجد طريقة أسرع لإبطاء موقع الويب (يقصد التورية) من استخدام مجموعة من كود JavaScript عليه. عند استخدام JavaScript ، يتعين عليك الدفع مقابل أداء المشاريع بما لا يقل عن أربع مرات. إليك كيفية تحميل شفرة JavaScript الخاصة بالموقع على أنظمة المستخدمين:
- تنزيل ملف عبر الشبكة.
- تحليل وتجميع التعليمات البرمجية المصدر التي تم فك حزمها بعد التنزيل.
- تنفيذ كود JavaScript.
- استهلاك الذاكرة.
اتضح هذا المزيج .
ونقوم بتضمين المزيد والمزيد من كود JS في مشاريعنا. مع تحرك المؤسسات نحو المواقع المدعومة بأطر عمل ومكتبات مثل React و Vue وغيرها ، فإننا نجعل الوظائف الأساسية للمواقع تعتمد بشكل كبير على JavaScript.
لقد رأيت الكثير من المواقع الثقيلة جدًا التي تستخدم أطر عمل JavaScript. لكن رؤيتي للقضية منحازة للغاية. الحقيقة هي أن الشركات التي أعمل معها تلجأ إليّ على وجه التحديد لأنها تواجه مشاكل معقدة في مجال أداء الموقع. ونتيجة لذلك ، أصبح لدي فضول لمعرفة مدى شيوع هذه المشكلة ، وحول نوع "العقوبات" التي ندفعها عندما نختار إطار عمل أو آخر كأساس لموقع معين.
ساعدني المشروع في اكتشاف ذلك. .
معطيات
يتتبع مشروع HTTP Archive إجمالي 4308655 رابطًا لمواقع سطح المكتب العادية و 5484239 رابطًا لمواقع الجوال. من بين العديد من المقاييس المرتبطة بهذه الروابط ، توجد قائمة بالتقنيات الموجودة في المواقع المعنية. هذا يعني أنه يمكننا أخذ عينات من آلاف المواقع التي تستخدم أطر عمل ومكتبات مختلفة والتعرف على مقدار التعليمات البرمجية التي يرسلونها إلى العملاء ومقدار التحميل الذي تنشئه هذه الشفرة على أنظمة المستخدمين.
جمعت بيانات آذار (مارس) 2020 ، وهي أحدث البيانات التي تمكنت من الوصول إليها.
قررت مقارنة بيانات أرشيف HTTP المجمعة عبر جميع المواقع ببيانات من مواقع تم العثور عليها باستخدام React و Vue و Angular ، على الرغم من أنني فكرت في استخدام مواد مصدر أخرى أيضًا.
لجعلها أكثر إثارة للاهتمام ، أضفت أيضًا المواقع التي تستخدم jQuery إلى مجموعة البيانات المصدر. لا تزال هذه المكتبة تحظى بشعبية كبيرة. يقدم أيضًا نهجًا مختلفًا لتطوير الويب عن نموذج تطبيق الصفحة الواحدة (SPA) الذي تقدمه React و Vue و Angular.
الروابط الموجودة في أرشيف HTTP تمثل المواقع التي تم اكتشاف أنها تستخدم تقنيات ذات أهمية
الإطار أو المكتبة
روابط لمواقع الجوال
روابط لمواقع عادية
مسج
4615474
3714643
رد فعل
489827
241023
رأي
85649
43691
زاوي
19423
18088
آمال وأحلام
قبل أن ننتقل إلى تحليل البيانات ، أود أن أتحدث عما أود أن أتمناه.
أعتقد أنه في عالم مثالي ، يجب أن تتجاوز أطر العمل تلبية احتياجات المطورين وتوفر بعض الفوائد المحددة للمستخدم العادي الذي يعمل مع مواقعنا. الأداء هو مجرد واحدة من تلك الفوائد. هذا هو المكان الذي تلعب فيه إمكانية الوصول والأمان. لكن هذا فقط هو الأهم.
لذلك ، في عالم مثالي ، يجب أن يسهّل نوع من الإطار إنشاء موقع عالي الأداء. يجب أن يتم ذلك إما بسبب حقيقة أن إطار العمل يمنح المطور قاعدة لائقة لبناء مشروع عليه ، أو بسبب حقيقة أنه يفرض قيودًا على التطوير ، ويضع متطلبات له تعقيد تطوير شيء يتحول الخروج ليكون بطيئا.
يجب أن تقوم أفضل الأطر بكلا الأمرين: إعطاء قاعدة جيدة ، وفرض قيود على العمل ، مما يسمح لك بتحقيق نتيجة لائقة.
لن يمنحنا تحليل القيم المتوسطة للبيانات المعلومات التي نحتاجها. وفي الواقع ، فإن هذا النهج يترك اهتمامنا . بدلاً من ذلك ، اشتقت النسب المئوية من البيانات التي أملكها. هذه هي 10 ، 25 ، 50 (متوسط) ، 75 ، 90 في المائة.
أنا مهتم بشكل خاص بالنسب المئوية العاشرة والتسعين. تمثل النسبة المئوية العاشرة أفضل أداء (أو على الأقل أقرب أو أقل من الأفضل) لإطار عمل معين. بمعنى آخر ، هذا يعني أن 10٪ فقط من المواقع التي تستخدم إطار عمل معين تصل إلى هذا المستوى أو أعلى. النسبة المئوية التسعون ، من ناحية أخرى ، هي الوجه الآخر للعملة - إنها توضح لنا كيف يمكن أن تسوء الأمور. النسبة المئوية التسعون هي المواقع التي تليها - تلك الـ 90٪ الأدنى من المواقع التي تحتوي على أكبر عدد من كود JS أو أطول وقت لمعالجة التعليمات البرمجية الخاصة بها على مؤشر الترابط الرئيسي.
أحجام كود JavaScript
بادئ ذي بدء ، من المنطقي تحليل حجم شفرة JavaScript التي تنقلها مواقع مختلفة عبر الشبكة.
مقدار كود JavaScript (Kb) الذي تم نقله إلى الأجهزة المحمولة
النسب المئوية
10
25
50
75
90
كل المواقع
93.4
196.6
413.5
746.8
1201.6
مواقع jQuery
110.3
219.8
430.4
748.6
1162.3
مواقع Vue
244.7
409.3
692.1
1065.5
1570.7
المواقع الزاويّة
445.1
675.6
1066.4
1761.5
2893.2
رد فعل المواقع
345.8
441.6
690.3
1238.5
1893.6
مقدار كود JavaScript المرسل إلى الأجهزة المحمولة
يتم نقل مقدار كود JavaScript (Kb) إلى أجهزة سطح المكتب
النسب المئوية
10
25
50
75
90
كل المواقع
105.5
226.6
450.4
808.8
1267.3
مواقع jQuery
121.7
242.2
458.3
803.4
1235.3
مواقع Vue
248.0
420.1
718.0
1122.5
1643.1
المواقع الزاويّة
468.8
716.9
1144.2
1930.0
3283.1
رد فعل المواقع
308.6
469.0
841.9
1472.2
2197.8
مقدار كود JavaScript المرسل إلى أجهزة سطح المكتب
إذا تحدثنا فقط عن حجم كود JS الذي ترسله المواقع إلى الأجهزة ، فحينئذٍ سيبدو كل شيء كما قد تتوقع. وبالتحديد ، إذا تم استخدام أحد الأطر ، فهذا يعني أنه حتى في الوضع المثالي ، سيزداد حجم كود JavaScript الخاص بالموقع. هذا ليس مفاجئًا - لا يمكنك جعل إطار عمل JavaScript أساسًا لموقع ما وتتوقع أن حجم كود JS الخاص بالمشروع سيكون منخفضًا جدًا.
ما يميز هذه البيانات هو أن بعض الأطر والمكتبات يمكن اعتبارها نقطة انطلاق أفضل للمشروع من غيرها. المواقع التي تحتوي على jQuery تبدو الأفضل. في إصدارات سطح المكتب من المواقع ، فإنها تحتوي على جافا سكريبت بنسبة 15٪ أكثر من جميع المواقع ، وعلى الجوال تحتوي على 18٪ أكثر. (من المسلم به أن هناك بعض الفساد في البيانات هنا. والحقيقة هي أن jQuery موجود في العديد من المواقع ، لذلك من الطبيعي أن ترتبط هذه المواقع ارتباطًا وثيقًا أكثر من غيرها بالعدد الإجمالي للمواقع. ومع ذلك ، فإن هذا لا يؤثر على مدى يتم إخراج البيانات لكل إطار عمل.)
في حين أن الزيادة في حجم الشفرة بنسبة 15-18٪ تعد رقمًا ملحوظًا ، بمقارنة ذلك مع الأطر والمكتبات الأخرى ، يمكن للمرء أن يستنتج أن "الضريبة" التي يفرضها jQuery منخفضة جدًا. ترسل المواقع الزاويّة في الشريحة المئوية العاشرة بيانات أكثر إلى سطح المكتب بنسبة 10٪ مقارنة بجميع المواقع ، و 344٪ أكثر إلى الجوّال. مواقع React هي الأثقل التالية ، حيث ترسل أكواد أكثر بنسبة 377٪ إلى سطح المكتب مقارنة بجميع المواقع ، و 193٪ أكثر إلى الأجهزة المحمولة.
ذكرت سابقًا أنه على الرغم من أن استخدام إطار عمل يعني أنه سيتم تضمين قدر معين من التعليمات البرمجية في المشروع ، في بداية العمل عليه ، آمل أن يكون الإطار قادرًا على تقييد المطور بطريقة ما. على وجه الخصوص ، نحن نتحدث عن الحد من الحد الأقصى لمقدار الشفرة.
ومن المثير للاهتمام أن مواقع jQuery تتبع هذه الفكرة. في حين أنها أثقل قليلاً من جميع المواقع في الشريحة المئوية العاشرة (بنسبة 10-15٪) ، إلا أنها أخف قليلاً عند النسبة المئوية التسعين عند حوالي 18٪ على كل من أجهزة سطح المكتب والجوّال. هذا لا يعني أن هذه فائدة كبيرة جدًا ، ولكن يمكن القول أن مواقع jQuery ، على الأقل ، لا تحتوي على أحجام شفرات جافا سكريبت ضخمة ، حتى في أكبر إصداراتها.
لكن لا يمكن قول الشيء نفسه عن أطر أخرى.
تمامًا كما في حالة الشريحة المئوية العاشرة ، في المواقع المئوية التسعين على Angular و React تختلف عن المواقع الأخرى ، لكنها تختلف ، للأسف ، للأسوأ.
عند النسبة المئوية التسعين ، ترسل المواقع الزاويّة بيانات إلى الجوّال بنسبة 90٪ أكثر من جميع المواقع ، و 141٪ أكثر إلى سطح المكتب. ترسل مواقع React إلى سطح المكتب 159٪ أكثر من جميع المواقع ، و 73٪ أكثر إلى الأجهزة المحمولة. حجم كود مواقع React عند النسبة المئوية التسعين هو 58 كيلوبايت. هذا يعني أن مثل هذه المواقع ترسل 90 كيلوبايت من البيانات إلى الأجهزة المحمولة أكثر من أقرب منافسيها استنادًا إلى Vue. الفجوة بين مواقع سطح المكتب القائمة على Angular و React والمواقع الأخرى أكبر. على سبيل المثال ، ترسل مواقع React لسطح المكتب 2197.8 كيلوبايت من كود JS أكثر من مواقع Vue المكافئة.
الوقت المستغرق لمعالجة كود JavaScript في السلسلة الرئيسية
تشير البيانات الواردة أعلاه بوضوح إلى أن المواقع التي تستخدم الأطر والمكتبات قيد الدراسة تحتوي على كميات كبيرة من كود JavaScript. لكن بالطبع ، هذا مجرد جزء واحد من المعادلة.
بعد وصول شفرة JavaScript إلى المتصفح ، يجب إحضارها إلى حالة قابلة للتطبيق. تحدث العديد من المشكلات بشكل خاص عن تلك الإجراءات التي يجب تنفيذها باستخدام الكود الموجود في مؤشر ترابط المتصفح الرئيسي. الموضوع الرئيسي مسؤول عن معالجة إجراءات المستخدم ، وحساب الأنماط ، وبناء تخطيط الصفحة وعرضه. إذا أغرقت الخيط الرئيسي بمهام JavaScript ، فلن تتاح له الفرصة لإكمال بقية المهام في الوقت المناسب. وهذا يؤدي إلى تأخيرات و "مكابح" في عمل الصفحات.
تحتوي قاعدة بيانات HTTP Archive على معلومات حول المدة التي تستغرقها معالجة كود JavaScript في السلسلة الرئيسية لمحرك V8. هذا يعني أنه يمكننا جمع هذه البيانات ومعرفة مقدار الوقت الذي يستغرقه مؤشر الترابط الرئيسي لمعالجة JavaScript في مواقع مختلفة.
وقت المعالج (بالملي ثانية) المرتبط بمعالجة البرنامج النصي على الأجهزة المحمولة
النسب المئوية
10
25
50
75
90
كل المواقع
356.4
959.7
2372.1
5367.3
10485.8
مواقع jQuery
575.3
1147.4
2555.9
5511.0
10349.4
مواقع Vue
1130.0
2087.9
4100.4
7676.1
12849.4
المواقع الزاويّة
1471.3
2380.1
4118.6
7450.8
13296.4
رد فعل المواقع
2700.1
5090.3
9287.6
14509.6
20813.3
وقت المعالج المرتبط بمعالجة البرنامج النصي على الأجهزة المحمولة
وقت المعالج (بالملي ثانية) المرتبط بمعالجة البرنامج النصي على أجهزة سطح المكتب
النسب المئوية
10
25
50
75
90
كل المواقع
146.0
351.8
831.0
1739.8
3236.8
مواقع jQuery
199.6
399.2
877.5
1779.9
3215.5
مواقع Vue
350.4
650.8
1280.7
2388.5
4010.8
المواقع الزاويّة
482.2
777.9
1365.5
2400.6
4171.8
رد فعل المواقع
508.0
1045.6
2121.1
4235.1
7444.3
وقت المعالج المرتبط بمعالجة البرنامج النصي على أجهزة سطح المكتب
هنا يمكنك أن ترى شيئًا مألوفًا جدًا.
بالنسبة للمبتدئين ، تنفق المواقع التي تحتوي على jQuery أقل بكثير على معالجة JavaScript على السلسلة الرئيسية مقارنة بالمواقع الأخرى. في النسبة المئوية العاشرة ، مقارنة بجميع المواقع ، تقضي مواقع jQuery على الهاتف المحمول وقتًا أطول بنسبة 10٪ في معالجة كود JS على السلسلة الرئيسية. في حالة مواقع jQuery لسطح المكتب ، يزداد وقت المعالجة بنسبة 61٪. عند النسبة المئوية التسعين ، تسجل مواقع jQuery نتائج قريبة جدًا من الدرجات الإجمالية. على وجه التحديد ، تقضي مواقع jQuery على الأجهزة المحمولة وقتًا أقل بنسبة 37٪ على سلسلة المحادثات الرئيسية مقارنة بجميع المواقع ، ووقتًا أقل بنسبة 90٪ على أجهزة سطح المكتب.
على الجانب الآخر من تصنيفنا توجد الأطر التي تتميز بأعلى حمل على الخيط الرئيسي. هذا ، مرة أخرى ، هو Angular و React. الاختلاف الوحيد بين الاثنين هو أنه بينما ترسل مواقع Angular المزيد من التعليمات البرمجية إلى المتصفحات أكثر من مواقع React ، فإن المواقع Angular تستغرق وقتًا أقل لوحدة المعالجة المركزية لمعالجة التعليمات البرمجية. اقل بكثير.
عند النسبة المئوية العاشرة ، تقضي مواقع Angular لسطح المكتب وقتًا أطول بنسبة 10٪ في معالجة شفرة JS لخيط رئيسي مقارنة بجميع المواقع. بالنسبة لمواقع الجوال ، فإن هذا الرقم هو 230٪. مواقع التفاعل هي الأسوأ أداءً. على سطح المكتب ، يقضون 313٪ وقتًا أطول في معالجة الأكواد مقارنة بجميع المواقع ، و 248٪ أكثر على الهاتف المحمول. 658٪ ليس خطأ مطبعي. عند النسبة المئوية العاشرة ، تقضي مواقع React 658 ثانية من وقت مؤشر الترابط الرئيسي في معالجة شفرتها.
النسبة المئوية التسعون ، بالمقارنة مع هذه الأعداد الضخمة ، تبدو أفضل قليلاً على الأقل. مقارنةً بجميع المواقع ، تقضي مشاريع Angular وقتًا أطول بنسبة 90٪ على أجهزة سطح المكتب في السلسلة الرئيسية ، و 29٪ وقتًا إضافيًا على الأجهزة المحمولة. في حالة مواقع React ، تبدو الأرقام نفسها 27٪ و 130٪ على التوالي.
تبدو الانحرافات بالنسبة المئوية للشريحة المئوية التسعين أفضل من القيم المماثلة للشريحة المئوية العاشرة. ولكن هنا يجدر بنا أن نتذكر أن الأرقام التي تشير إلى الوقت تبدو مخيفة إلى حد ما. لنفترض أن 90 ثانية على سلسلة المحادثات الرئيسية للجوال لموقع ويب تم إنشاؤه باستخدام React. (أعتقد أن قصة ما يحدث بالفعل خلال هذا الوقت تستحق مقالة منفصلة).
هناك تعقيد واحد محتمل هنا (شكرًا لجذب انتباهي إلى هذه الميزة ، وللنظر بعناية في البيانات من وجهة النظر هذه). الحقيقة هي أن العديد من المواقع تستخدم العديد من أدوات الواجهة الأمامية. على وجه الخصوص ، لقد رأيت الكثير من المواقع التي تستخدم jQuery جنبًا إلى جنب مع React أو Vue ، حيث تنتقل هذه المواقع من jQuery إلى أطر عمل أو مكتبات أخرى. نتيجة لذلك ، قمت بالضغط على قاعدة البيانات مرة أخرى ، ولكن هذه المرة فقط حدد الروابط التي تتوافق مع المواقع التي تستخدم React أو jQuery أو Angular أو Vue فقط ، ولكن ليس أي مزيج منها. هذا ما حصلت عليه.
وقت المعالج (بالمللي ثانية) المرتبط بمعالجة البرامج النصية على الأجهزة المحمولة في حالة تستخدم فيها المواقع إطار عمل واحدًا أو مكتبة واحدة فقط
النسب المئوية
10
25
50
75
90
المواقع التي تستخدم jQuery فقط
542.9
1062.2
2297.4
4769.7
8718.2
المواقع التي تستخدم Vue فقط
944.0
1716.3
3194.7
5959.6
9843.8
المواقع التي تستخدم Angular فقط
1328.9
2151.9
3695.3
6629.3
11607.7
المواقع التي تستخدم React فقط
2443.2
4620.5
10061.4
17074.3
24956.3
وقت المعالج المرتبط بمعالجة البرامج النصية على الأجهزة المحمولة في حالة تستخدم فيها المواقع إطارًا واحدًا فقط أو مكتبة واحدة فقط
أولاً ، شيء لا يثير الدهشة: عندما يستخدم موقع ما إطار عمل واحد فقط أو مكتبة واحدة ، فإن أداء مثل هذا الموقع يتحسن في كثير من الأحيان. تعمل كل أداة بشكل أفضل عند النسب المئوية العاشرة والخامسة والعشرين. يبدو الأمر معقولا. يجب أن يكون أداء الموقع الذي يتم إنشاؤه باستخدام إطار عمل واحد أفضل من الموقع الذي يتم إنشاؤه باستخدام إطارين أو مكتبات أو أكثر.
في الواقع ، يبدو أداء كل أداة أمامية تمت دراستها أفضل في جميع الحالات ، باستثناء استثناء واحد غريب. ما أدهشني هو أنه عند النسبة المئوية الخمسين وما فوق ، يكون أداء المواقع التي تستخدم React أسوأ عندما تكون React هي المكتبة الوحيدة التي تستخدمها. هذا ، بالمناسبة ، كان سبب تقديمي لهذه البيانات هنا.
هذا غريب بعض الشيء ، لكني ما زلت أحاول البحث عن تفسير لهذا الغرابة.
إذا كان المشروع يستخدم كلاً من React و jQuery ، فمن المحتمل أن يكون هذا المشروع في منتصف الطريق خلال الانتقال من jQuery إلى React. ربما يحتوي على قاعدة بيانات حيث تختلط هذه المكتبات. نظرًا لأننا رأينا بالفعل أن مواقع jQuery تقضي وقتًا أقل في الخيط الرئيسي مقارنة بمواقع React ، فقد يخبرنا هذا أن تنفيذ بعض الوظائف في jQuery يساعد الموقع على أداء أفضل قليلاً.
ولكن مع انتقال المشروع من jQuery إلى React واعتماده بشكل أكبر على React ، فإن الأمور تتغير. إذا كان الموقع عالي الجودة حقًا ، واستخدم مطورو الموقع React بعناية ، فسيكون كل شيء على ما يرام مع مثل هذا الموقع. ولكن بالنسبة إلى موقع React المتوسط ، فإن الاستخدام المكثف لـ React يعني أن الخيط الرئيسي تحت عبء ثقيل.
الفجوة بين الأجهزة المحمولة وأجهزة سطح المكتب
وجهة نظر أخرى نظرت من خلالها إلى البيانات التي تم البحث عنها وهي دراسة مدى اتساع الفجوة بين العمل مع المواقع على الأجهزة المحمولة وأجهزة سطح المكتب. إذا تحدثنا عن مقارنة أحجام كود JavaScript ، فإن هذه المقارنة لا تكشف عن أي شيء رهيب. بالطبع ، سيكون من الجيد رؤية كميات أقل من التعليمات البرمجية القابلة للتنزيل ، ولكن لا يوجد فرق كبير في مقدار كود الهاتف المحمول وسطح المكتب.
ولكن إذا قمنا بتحليل الوقت اللازم لمعالجة الكود ، فستلاحظ وجود فجوة كبيرة جدًا بين الأجهزة المحمولة وأجهزة سطح المكتب.
زيادة الوقت (النسبة المئوية) المتعلقة بمعالجة البرامج النصية على الأجهزة المحمولة مقارنة بسطح المكتب
النسب المئوية
10
25
50
75
90
كل المواقع
144.1
172.8
185.5
208.5
224.0
مواقع jQuery
188.2
187.4
191.3
209.6
221.9
مواقع Vue
222.5
220.8
220.2
221.4
220.4
المواقع الزاويّة
205.1
206.0
201.6
210.4
218.7
رد فعل المواقع
431.5
386.8
337.9
242.6
179.6
في حين أنه من المتوقع حدوث بعض الاختلاف في سرعة معالجة الكود بين الهاتف والكمبيوتر المحمول ، فإن هذه الأرقام الكبيرة تخبرني أن الأطر الحديثة لا تستهدف بشكل كاف الأجهزة منخفضة الطاقة ، وأنهم يسعون جاهدين لسد الفجوة التي اكتشفوها. حتى في النسبة المئوية العاشرة ، تقضي مواقع React وقتًا أطول بنسبة 10٪ على سلسلة المحادثات الرئيسية للجوّال مقارنةً بخيط سطح المكتب الرئيسي. لدى jQuery أصغر فجوة ، ولكن حتى هنا الرقم المقابل هو 431.5٪. عندما يصنع مطورو مواقع الويب مشاريعهم بطريقة تتطلب معالجتها وقتًا أطول للمعالج (وهذا يحدث ، ويزداد الأمر سوءًا بمرور الوقت) ، يتعين على مالكي الأجهزة منخفضة الطاقة الدفع مقابل ذلك.
نتائج
يجب أن تمنح الأطر الجيدة المطورين أساسًا جيدًا لبناء مشاريع الويب (من حيث الأمان وإمكانية الوصول والأداء) ، أو يجب أن يكون لديهم قيود مضمنة تجعل من الصعب إنشاء شيء ينتهك هذه القيود.
لا يبدو أن هذا ينطبق على أداء مشاريع الويب (ويفترض أنه لا ينطبق على ).
تجدر الإشارة إلى أنه لمجرد أن مواقع React أو Angular تقضي وقتًا أطول لوحدة المعالجة المركزية في إعداد الكود أكثر من غيرها ، فهذا لا يعني بالضرورة أن مواقع React أكثر كثافة في وحدة المعالجة المركزية من مواقع Vue أثناء التشغيل. في الواقع ، لا تشير البيانات التي قمنا بمراجعتها إلا القليل جدًا عن الأداء التشغيلي لأطر العمل والمكتبات. يتحدثون أكثر عن مناهج التطوير التي ، بوعي أو بغير وعي ، يمكن لهذه الأطر أن تدفع المبرمجين. نحن نتحدث عن توثيق لأطر العمل ، وعن النظام البيئي الخاص بهم ، وعن تقنيات التنمية المشتركة.
وتجدر الإشارة أيضًا إلى شيء لم نحلله هنا ، وهو مقدار الوقت الذي يقضيه الجهاز في تنفيذ كود JavaScript عند التنقل بين صفحات الموقع. الحجة المؤيدة لـ SPA هي أنه بمجرد تحميل تطبيق الصفحة الواحدة في المتصفح ، سيتمكن المستخدم نظريًا من فتح صفحات الموقع بشكل أسرع. تجربتي الخاصة تخبرني أن هذا بعيد كل البعد عن الحقيقة. لكن ليس لدينا بيانات لتوضيح هذه المشكلة.
ما هو واضح هو أنك إذا كنت تستخدم إطار عمل أو مكتبة لإنشاء موقع على شبكة الإنترنت ، فأنت تقدم حل وسط فيما يتعلق بتحميل المشروع مبدئيًا وتجهيزه للعمل. وهذا ينطبق حتى على أكثر السيناريوهات إيجابية.
من الممكن تمامًا تقديم بعض التنازلات في المواقف المناسبة ، ولكن من المهم أن يقوم المطورون بتقديم مثل هذه التنازلات بوعي.
لكن لدينا أيضًا سببًا للتفاؤل. أنا متحمس لمعرفة مدى تعاون مطوري Chrome مع مطوري بعض أدوات الواجهة الأمامية التي قمنا بمراجعتها في محاولة للمساعدة في تحسين أداء هذه الأدوات.
ومع ذلك ، فأنا شخص عملي. تخلق البنى الجديدة مشاكل في الأداء بقدر ما يتم حلها. ويستغرق إصلاح الخلل وقتًا. تماما كما لا ينبغي أن نتوقع سيحل جميع مشاكل الأداء ، يجب ألا تتوقع ذلك من الإصدارات الجديدة من أطر العمل المفضلة لدينا.
إذا كنت تريد استخدام إحدى أدوات الواجهة الأمامية التي تمت مناقشتها في هذه المقالة ، فهذا يعني أنه سيتعين عليك بذل جهد إضافي حتى لا تضر بأداء مشروعك في هذه الأثناء. فيما يلي بعض الاعتبارات التي يجب مراعاتها قبل البدء في إطار عمل جديد:
- اختبر نفسك بالمنطق السليم. هل تحتاج حقًا إلى استخدام الإطار الذي اخترته؟ نقية جافا سكريبت اليوم قادرة على الكثير.
- هل هناك بديل أخف للإطار المختار (مثل Preact أو Svelte أو أي شيء آخر) يمكن أن يمنحك 90٪ من إمكانيات هذا الإطار؟
- إذا كنت تستخدم إطار عمل بالفعل ، ففكر في ما إذا كان هناك شيء يقدم خيارات قياسية أفضل وأكثر تحفظًا (على سبيل المثال Nuxt.js بدلاً من Vue و Next.js بدلاً من React وما إلى ذلك).
- ماذا سيكون لديك أداء JavaScript؟
- كيف يمكنك عملية تطوير لجعل إدخال كود JavaScript في مشروع أكثر صعوبة مما هو ضروري للغاية؟
- إذا كنت تستخدم إطار عمل لسهولة التطوير ، ففكر في ذلك إرسال رمز الإطار إلى العملاء. ربما يمكنك حل جميع المشاكل على الخادم؟
عادة ما تكون هذه الأفكار جديرة بالنظر ، بغض النظر عما اخترته بالضبط لتطوير الواجهة الأمامية. لكنها مهمة بشكل خاص عندما تعمل في مشروع يفتقر إلى الأداء منذ البداية.
القراء الأعزاء! كيف ترى إطار عمل JavaScript المثالي؟
المصدر: www.habr.com