في الآونة الأخيرة ، كنت أدرس كتاب "دليل بناء مواقع الويب عالية الأداء". هذه المقالة هي مذكرة دراسة. سأقوم بفرز ما تعلمته لسهولة المشاهدة لاحقًا.
تشرح القاعدة الذهبية للأداء أن 10 ٪ إلى 20 ٪ فقط من وقت استجابة المستخدم النهائي يقبل قبول مستندات المستخدم HTML المطلوبة ، في حين أن 80 ٪ إلى 90 ٪ من الوقت يتم إنفاقها على طلبات HTTP لجميع المكونات (الصور ، والبرامج النصية ، وورت الأنماط ، وما إلى ذلك) المشار إليها من قبل وثيقة HTML ، ووقت استجابة الطرف في الصفحة على الصفحة.
-Sounders Steve
1 دمج ملف (قلل من عدد طلبات HTTP)
العفاريت CSS
استخدم العفاريت CSS لدمج الصور المستخدمة على موقع الويب في صورة واحدة ، واستخدم أيقونة من خلال وضع الخلفية والعرض والارتفاع للتحكم في موضع صورة الخلفية. يمكن لهذه الطريقة تقليل طلبات الصور المتعددة إلى وقت واحد. هناك العديد من الأدوات لإنشاء العفاريت CSS. هناك المكونات الإضافية ذات الصلة في Grunt و Gulp ، و CSSGAGA جيدة أيضا.
دمج JS و CSS
مثل خريطة Sprite ، يعد دمج ملفات CSS و JS أيضًا وسيلة مهمة لتقليل طلبات HTTP. لا يوجد جدل حول دمج ملفات CSS في الوقت الحاضر ، ولكن للانتشار الحالي لنظام JS ، يبدو أن دمج جميع ملفات JS في ملف واحد يبدو إلى الوراء. الطريقة الصحيحة هي الالتزام بنمط اللغة المترجمة ، والحفاظ على وحدات JS ، وإنشاء الملفات المستهدفة فقط لملفات JS المستخدمة في الطلب الأولي أثناء عملية التوليد.
2 استخدم المحتوى لنشر الشبكة (تقليل وقت طلب HTTP)
هناك عامل آخر يؤثر على وقت طلب HTTP هو المسافة التي أنت فيها من خادم الويب الإلكتروني. من الواضح أنه كلما طالت المسافة ، كلما طالما طلب الطلب ، والذي يمكن أن يتحسن بشكل كبير من خلال CDN.
CDN هو خادم ويب موزع في مواقع جغرافية متعددة ، يستخدم لنشر المحتوى للمستخدمين بشكل أكثر فعالية. تتمثل الوظيفة الرئيسية لـ CDN في تخزين الملفات الثابتة للمستخدمين النهائيين ، كما توفر خدمات التنزيل والمناسبات والوظائف الأخرى.
3 تعيين ذاكرة التخزين المؤقت للمتصفح (تجنب تكرار طلبات HTTP)
باستخدام انتهاء الصلاحية/السيطرة ذاكرة التخزين المؤقت
يمكن للمتصفحات تجنب الطلبات المتكررة في كل مرة باستخدام ذاكرة التخزين المؤقت. HTTP 1.0 و HTTP 1.1 لديهم طرق مختلفة لتنفيذ ذاكرة التخزين المؤقت ، تنتهي (1.0) وسيطرة ذاكرة التخزين المؤقت (1.1). يستخدم خادم الويب انتهاء صلاحيته لإخبار العميل بأن جميع النسخ المخبأة في الملف سيتم استخدامها في غضون وقت محدد ولم يعد يقدم طلبات إلى الخادم مرارًا وتكرارًا ، على سبيل المثال:
انتهاء صلاحية: Thu ، 01 Dec 2016 16:00:00 GMT (GMT Format)
هذا الإعداد يعني أنه اعتبارًا من 1 ديسمبر 2016 ، تتوفر النسخة المخزنة مؤقتًا دون تقديم أي طلبات أخرى.
لدى Expires قيود على طريقة تمرير المواعيد النهائية: يتطلب تزامنًا صارمًا بين ساعات العميل والخادم ، في حين يحدد التحكم في ذاكرة التخزين المؤقت التي تم تقديمها بواسطة HTTP 1.1 تاريخ ذاكرة التخزين المؤقت عن طريق تحديد وقت في ثوانٍ ، وبالتالي فإن هذا القيد غير موجود ، على سبيل المثال: على سبيل المثال:
السيطرة على ذاكرة التخزين المؤقت: أقصى سن = 31536000
هذا الإعداد يعني أن وقت ذاكرة التخزين المؤقت هو سنة واحدة ، ويوصى بها استخدام التحكم في ذاكرة التخزين المؤقت ، ولكن عندما يتم دعم HTTP 1.1 ، فإن هناك شيء آخر يجب ملاحظة: سيطرة ذاكرة التخزين المؤقت وانتهاءها في نفس الوقت ، يكون للسيطرة على ذاكرة التخزين المؤقت أولوية أعلى.
تكوين أو إزالة ETAG
يمكن أن يؤدي استخدام مراقبة Expire/Cache إلى تجنب الزيارة الثانية ، واستخدام ذاكرة التخزين المؤقت المحلية لتجنب طلبات HTTP مكررة ، وتحسين سرعة الموقع. ومع ذلك ، إذا انقر المستخدم على تحديث أو انتهاء صلاحية المتصفح ، فسيظل طلب الحصول على HTTP الحصول على الخادم. إذا لم يتغير الملف في هذا الوقت ، فلن يقوم الخادم بإرجاع الملف بأكمله ولكنه سيقوم بإرجاع رمز الحالة 304 غير المعدل.
هناك نوعان من الباسيس للخادم لتحديد ما إذا كان الملف قد تغير: آخر تعديل (آخر تاريخ تعديل) و ETAG (علامة الكيان) ؛
تم تقديم ETAG (علامات الكيان) في HTTP 1.1 وله أولوية أعلى عندما تكون موجودة في نفس الوقت المعدل الأخير. يقارن الخادم ETAG (إذا لم يكن المباراة غير المقيدة) المرسلة من قبل العميل مع ETAG الحالي ، ويعيد 304 لم يتم تعديله إذا كان الشيء نفسه صحيحًا ، وإلا فإن الملف بأكمله و 200 OK سيتم إرجاعه.
هناك مشكلة في ETAG: عندما يرسل المتصفح طلب الحصول على خادم واحد ثم يطلب المكون من خادم آخر ، لا يتطابق ETAG. بالطبع ، إذا تم استضافة موقع الويب الخاص بك على خادم واحد ، والآن تستخدم العديد من مواقع الويب خوادم متعددة ، فإن وجود ETAG يقلل بشكل كبير من معدل نجاح صحة التحقق.
يتمثل الحل لهذه المشكلة في تكوين ETAG ، وإزالة قيمة Innode الخادم والاحتفاظ فقط بجهاز التعديل وحجم التعديل كقيمة ETAG ، أو إزالة ETAG مباشرة ، واستخدم المعدل الأخير للتحقق من صحة الملف.
4 مكونات ضغط (قلل من حجم طلب HTTP)
من خلال ضغط الملفات المنقولة عن HTTP ، وتقليل حجم طلبات HTTP وتحسين سرعة الطلب ، فإن GZIP هي الطريقة الأكثر استخدامًا والأكثر فعالية في الوقت الحالي.
ومع ذلك ، لا تحتاج جميع ملفات الموارد إلى ضغط. تتضمن تكلفة الضغط أن الخادم يحتاج إلى إنفاق دورات وحدة المعالجة المركزية لضغطها ، ويحتاج العميل أيضًا إلى فك ضغط الملفات المضغوطة ، والتي يجب موازنة مع موقع الويب الخاص بها. الآن تضغط معظم مواقع الويب مستندات HTML الخاصة بها ، واختار بعض مواقع الويب ضغط JS و CSS. لا توجد مواقع على مواقع الويب تقريبًا تستخدم ضغط GZIP للصور و PDFs والملفات الأخرى. والسبب هو أن هذه الملفات قد تم ضغطها ، واستخدام HTTP لضغط الأشياء التي تم التغلب عليها لا يمكن أن تجعلها أصغر. في الواقع ، فإن إضافة الرؤوس ، وضغط القواميس ، والتحقق من جسم الاستجابة يجعله في الواقع أكبر ، وكذلك إهدار وحدة المعالجة المركزية.
تتطلب كيفية تمكين GZIP على موقع الويب إعداد في خادم الويب (IIS ، Nginx ، Apache ، إلخ).
يتم وضع ملفات CSS 5 أولاً
وضع ملف CSS في الأول والأخير لا يؤثر على طلبات HTTP ، لذلك يكون متسقًا من حيث وقت الطلب. ومع ذلك ، من وجهة نظر تجربة المستخدم ، فإن وضع ملف CSS في الأول سيمنحك تجربة مستخدم أفضل.
والسبب هو أن المتصفح يوسع مستند HTML من أعلى إلى أسفل ويضع ملف CSS في الرأس. ستقوم الصفحة أولاً بتقديم طلب إلى ملف CSS ، ثم قم بتحميل شجرة DOM وتقديمه. سيتم تقديم الصفحة تدريجياً إلى المستخدم.
على العكس من ذلك ، إذا تم وضع ملف CSS في النهاية ، فإن الصفحة تقوم بتحميل DOM الكامل وتطلب ملف CSS ، ثم يجعل شجرة DOM بأكملها وتقدمها إلى المستخدم. من وجهة نظر المستخدم ، قبل طلب ملف CSS ، تكون الصفحة بأكملها في حالة شاشة بيضاء. الشاشة البيضاء هي سلوك المتصفح. تفسير ديفيد حياة له مثل هذا
قبل تحميل شجرة النمط بالكامل ، يكون تقديم شجرة DOM مضيعة ، لأنه سيتم تقديمه مرة أخرى بعد تحميل شجرة النمط ، وتحدث مشكلة FOUC (لا توجد محتوى على النمط).
شيء آخر يجب ملاحظته هو استخدام Link بدلاً من Import لتقديم أوراق أنماط CSS. حتى إذا تم كتابة النمط الذي تم تقديمه بواسطة import في الرأس ، فسيتم تحميله في نهاية المستند.
يتم وضع ملف JS 6 في النهاية
طلبات HTTP متوازية ، وعدد التنزيلات المتوازية للمتصفحات المختلفة مختلفة (2 أو 4 أو 8). التنزيلات الموازية تحسين سرعة طلبات HTTP. إن وضع ملف JS في المقام الأول لن يمنع تنزيل الملف اللاحق فحسب ، بل سيحظر أيضًا عرض الصفحة.
لماذا هذا يحدث؟ هناك سببان:
قد يوجد document.write في ملف JS لتعديل محتوى الصفحة ، لذلك لن يتم تقديم الصفحة بعد تنفيذ البرنامج النصي.
قد تحتوي ملفات JS المختلفة على تبعيات بغض النظر عن الحجم ، لذلك يجب تنفيذها بالترتيب ، لذلك يتم حظرها عند تحميل البرامج النصية.
لذلك ، فإن أفضل طريقة هي وضع ملف JS في النهاية والانتظار حتى يتم تحميل جميع المكونات المرئية للصفحة قبل تقديم طلبات لتحسين تجربة المستخدم.
ما سبق هو بعض الاقتراحات حول تحسين أداء موقع الويب بواسطة JavaScript الذي قدمه لك المحرر (1). آمل أن يكون ذلك مفيدًا لك. إذا كنت تريد معرفة المزيد ، فيرجى الانتباه إلى wulin.com. في المقالة التالية ، سيقدم لك المحرر اقتراحات لتحسين أداء موقع الويب الخاص بـ JavaScript (II)