متى يجب علي استخدام Inline vs.جافا سكريبت الخارجية؟

https://stackoverflow.com/questions/138884

02-07-2019
|

سؤال

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

ما هي الممارسة العامة لذلك؟

سيناريو العالم الحقيقي - لدي العديد من صفحات html التي تحتاج إلى التحقق من صحة النموذج من جانب العميل.ولهذا أستخدم مكونًا إضافيًا لـ jQuery أقوم بتضمينه في كل هذه الصفحات.لكن السؤال هو هل أنا:

كتابة أجزاء من التعليمات البرمجية التي تقوم بتكوين هذا البرنامج النصي في السطر؟
هل تريد تضمين جميع البتات في ملف واحد يتم مشاركته بين جميع صفحات html هذه؟
تضمين كل بت في ملف خارجي منفصل، واحد لكل صفحة HTML؟

شكرًا.

المحلول

في وقت نشر هذه الإجابة في الأصل (2008)، كانت القاعدة بسيطة:يجب أن تكون جميع البرامج النصية خارجية.سواء للصيانة والأداء.

(لماذا الأداء؟لأنه إذا كان الرمز منفصلاً، فمن الأسهل تخزينه مؤقتًا بواسطة المتصفحات.)

لا تنتمي JavaScript إلى كود HTML وإذا كانت تحتوي على أحرف خاصة (مثل <, >) حتى أنه يخلق مشاكل.

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

نصائح أخرى

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

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

يعد إضفاء الطابع الخارجي على جافا سكريبت أحد قواعد أداء ياهو:http://developer.yahoo.com/performance/rules.html#external

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

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

للحصول على أفضل أداء، عليك أن تفكر في الصفحات كصواريخ ذات مرحلتين.تتوافق هاتان المرحلتان تقريبًا مع <head> و <body> المراحل، ولكن فكر فيها بدلاً من ذلك <static> و <dynamic>.الجزء الثابت هو في الأساس عبارة عن ثابت سلسلة تقوم بإدخاله في أنبوب الاستجابة بأسرع ما يمكن.يمكن أن يكون هذا الأمر صعبًا بعض الشيء إذا كنت تستخدم الكثير من البرامج الوسيطة التي تقوم بتعيين ملفات تعريف الارتباط (يجب تعيينها قبل إرسال محتوى http)، ولكن من حيث المبدأ، فهي مجرد مسح المخزن المؤقت للاستجابة، ونأمل أن يكون ذلك قبل القفز إلى بعض التعليمات البرمجية النموذجية (razor، php، الخ) على الخادم.قد يبدو هذا صعبًا، لكني أشرحه بشكل خاطئ، لأنه قريب من التافهة.كما كنت قد خمنت، يجب أن يحتوي هذا الجزء الثابت على كل جافا سكريبت المضمنة والمصغرة.سيبدو شيء من هذا القبيل

<!DOCTYPE html>
     <html>
         <head>
             <script>/*...inlined jquery, angular, your code*/</script>
             <style>/* ditto css */</style>
         </head>
         <body>
             <!-- inline all your templates, if applicable -->
             <script type='template-mime' id='1'></script>
             <script type='template-mime' id='2'></script>
             <script type='template-mime' id='3'></script>

نظرًا لأن إرسال هذا الجزء عبر السلك لا يكلفك شيئًا تقريبًا، يمكنك أن تتوقع أن يبدأ العميل في تلقي هذا في مكان ما حوالي 5 مللي ثانية + زمن الوصول بعد الاتصال بالخادم الخاص بك.بافتراض أن الخادم قريب بشكل معقول، فقد يتراوح زمن الوصول هذا بين 20 مللي ثانية إلى 60 مللي ثانية.ستبدأ المتصفحات في معالجة هذا القسم بمجرد الحصول عليه، وعادةً ما يهيمن وقت المعالجة على وقت النقل بعامل 20 أو أكثر، وهو الآن نافذتك المطفأة للمعالجة من جانب الخادم <dynamic> جزء.

يستغرق المتصفح حوالي 50 مللي ثانية (الكروم، والباقي ربما أبطأ بنسبة 20٪) لمعالجة jquery المضمنة + الإشارة + الزاوي + ng animate + ng touch + ng المسارات + lodash.هذا مذهل جدًا في حد ذاته.تحتوي معظم تطبيقات الويب على تعليمات برمجية أقل من تلك المكتبات الشائعة مجتمعة، ولكن لنفترض أن لديك نفس القدر من التعليمات البرمجية، لذلك فسنفوز بزمن الوصول + 100 مللي ثانية من المعالجة على العميل (يأتي هذا الفوز بزمن الاستجابة من مجموعة النقل الثانية).بحلول الوقت الذي تصل فيه القطعة الثانية، نكون قد قمنا بمعالجة جميع أكواد وقوالب js ويمكننا البدء في تنفيذ تحويلات dom.

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

أعمل كثيرًا على تحسين تطبيقات SPA.من الشائع أن يعتقد الناس أن حجم البيانات يمثل مشكلة كبيرة، بينما في الحقيقة غالبًا ما يهيمن زمن الوصول والتنفيذ.تضيف المكتبات المصغرة التي أدرجتها ما يصل إلى 300 كيلو بايت من البيانات، وهذا فقط 68 كيلو بايت مضغوطة، أو 200 مللي ثانية تنزيل على هاتف 3g/4g بسرعة 2 ميجابت، وهو بالضبط زمن الاستجابة الذي سيستغرقه نفس الهاتف للتحقق مما إذا كان لديه نفس البيانات في ذاكرة التخزين المؤقت الخاصة به بالفعل، حتى لو تم تخزينه مؤقتًا بالوكيل، لأن ضريبة زمن الوصول للأجهزة المحمولة (زمن الوصول من الهاتف إلى البرج) لا تزال سارية.وفي الوقت نفسه، عادةً ما تتمتع اتصالات سطح المكتب التي تتميز بزمن انتقال أقل للقفزة الأولى بنطاق ترددي أعلى على أي حال.

باختصار، في الوقت الحالي (2014)، من الأفضل تضمين جميع البرامج النصية والأنماط والقوالب.

تحرير (مايو 2016)

مع استمرار نمو تطبيقات JS، وبعض الحمولات الخاصة بي تتراكم الآن بما يصل إلى 3 ميغابايت من التعليمات البرمجية المصغرة، أصبح من الواضح أنه على الأقل لا ينبغي تضمين المكتبات الشائعة.

اعتقد ان محددة لصفحة واحدة، حالة النص القصير هي (فقط) حالة يمكن الدفاع عنها للبرنامج النصي المضمن

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

محلية.ليست هناك حاجة للتنقل في ملف خارجي للتحقق من صحة سلوك بعض برامج جافا سكريبت
اياكس.إذا كنت تقوم بتحديث قسم ما من الصفحة عبر AJAX، فهذا يعني أنك يمكن تفقد جميع معالجات DOM الخاصة بك (عند النقر، وما إلى ذلك) لهذا القسم، اعتمادًا على كيفية ربطها.على سبيل المثال، باستخدام jQuery يمكنك إما استخدام live أو delegate طرق للتحايل على هذا، لكنني أجد أنه إذا كان JS صغيرًا بدرجة كافية فمن الأفضل وضعه في السطر.

هناك سبب آخر يدفعك دائمًا إلى استخدام البرامج النصية الخارجية وهو تسهيل الانتقال إليها سياسة أمان المحتوى (CSP).تحظر الإعدادات الافتراضية لـ CSP جميع البرامج النصية المضمنة، مما يجعل موقعك أكثر مقاومة لهجمات XSS.

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

ثم أثناء تطوير الموقع في كل صفحة HTML، تقوم فقط بتضمين تلك الصفحات المطلوبة.عند بدء التشغيل المباشر لموقعك، يمكنك تحسينه من خلال دمج كل ملف js تحتاجه الصفحة في ملف واحد.

الدفاع الوحيد الذي يمكنني تقديمه لـ javascipt المضمن هو أنه عند استخدام طرق العرض المكتوبة بقوة مع .net MVC، يمكنك الرجوع إلى متغيرات c# في منتصف جافا سكريبت والتي وجدتها مفيدة.

ثلاثة اعتبارات:

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

من السهل أيضًا تصحيح البرامج النصية الخارجية باستخدام Firebug.أحب اختبار وحدة جافا سكريبت الخاصة بي والحصول على كل المساعدة الخارجية.أكره رؤية JavaScript في كود PHP وHTML، حيث يبدو الأمر بمثابة فوضى كبيرة بالنسبة لي.

فيما يتعلق بإبقاء JavaScript خارجيًا:

قدم ASP.NET 3.5SP1 مؤخرًا وظيفة لإنشاء مورد نصي مركب (دمج مجموعة من ملفات js في ملف واحد).فائدة أخرى لذلك هي أنه عند تشغيل ضغط خادم الويب، فإن تنزيل ملف واحد أكبر قليلاً سيكون له نسبة ضغط أفضل من العديد من الملفات الأصغر حجمًا (أيضًا أقل حمل http، ذهابًا وإيابًا، وما إلى ذلك...).أعتقد أن هذا يتم حفظه عند التحميل الأولي للصفحة، ثم يبدأ التخزين المؤقت للمتصفح كما هو مذكور أعلاه.

وبغض النظر عن ASP.NET، يشرح هذا التسجيل الرقمي للشاشة الفوائد بمزيد من التفاصيل:http://www.asp.net/learn/3.5-SP1/video-296.aspx

فائدة أخرى مخفية للبرامج النصية الخارجية هي أنه يمكنك تشغيلها بسهولة من خلال مدقق بناء الجملة مثل com.jslint.يمكن أن ينقذك ذلك من الكثير من أخطاء IE6 المفجعة والتي يصعب العثور عليها.

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

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

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

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

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

حاول دائمًا استخدام Js الخارجية حيث يصعب دائمًا الحفاظ على js المضمنة.

علاوة على ذلك، من الضروري استخدام js خارجيًا بشكل احترافي نظرًا لأن غالبية المطورين يوصون باستخدام js خارجيًا.

أنا بنفسي أستخدم js خارجي.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow