لقد تصفحت اليوم لفترة وجيزة "مواقع الويب عالية الأداء". النسخة الصينية من هذا الكتاب هي "دليل إنشاء موقع ويب عالي الأداء".
يحتوي هذا الكتاب أيضًا على فصل متقدم بعنوان "مواقع الويب الأسرع" الذي يستكشف المشكلات الفردية بعمق، والترجمة الصينية هي "الدليل المتقدم لبناء مواقع الويب عالية الأداء".
لقد قدمه المؤلف في رابط Douban أعلاه، لذا لن أنسخه هنا.
يقدم هذا الكتاب 14 مبدأ لتحسين أداء موقع الويب، كل مبدأ عبارة عن فصل مستقل مع أمثلة. معظم هذه المبادئ عملية للغاية ومناسبة لمهندسي المواقع ومهندسي الواجهة الأمامية. إنها ذات أهمية أكبر لمهندسي الواجهة الأمامية.
هذه المرة شاهدت النسخة الأصلية. أفتقر إلى الخبرة العملية في تطوير الويب، وأقرأه على عجل، لذلك قد يكون هناك إغفالات وتعبيرات غير لائقة، وآمل أن لا تتردد مستخدمي الإنترنت في تصحيحي.
المبدأ 1: تقليل عدد طلبات HTTP
يستغرق إنشاء الطلب وانتظار الرد وقتًا، لذا كلما قل عدد الطلبات، كلما كان ذلك أفضل. الفكرة العامة لتقليل الطلبات هي دمج الموارد وتقليل عدد الملفات المطلوبة لعرض الصفحة.
1. خريطة الصور
من خلال تعيين سمة usemap للعلامة <img> واستخدام العلامة <map>، يمكنك تقسيم الصورة إلى مناطق متعددة والإشارة إلى روابط مختلفة. بالمقارنة مع استخدام صور متعددة لإنشاء روابط بشكل منفصل، يتم تقليل عدد الطلبات.
2. CSS SPRite (تكامل نسيج CSS/خياطة النسيج/تحديد موضع النسيج)
يتم ذلك عن طريق تحديد نمط موضع الخلفية للعنصر. تستخدم بشكل عام لأيقونات الواجهة. يمكن أن تشير الأزرار النموذجية إلى الأزرار الصغيرة الموجودة أعلى محرر TinyMCE. يتم قطع العديد من الصور الصغيرة بشكل أساسي من صورة كبيرة موحدة بإزاحات مختلفة، وبهذه الطريقة، لا يلزم طلب العديد من الأزرار الموجودة على واجهة التحميل إلا مرة واحدة (طلب الصورة الكبيرة مرة واحدة)، وبالتالي تقليل عدد طلبات HTTP.
3. الصورة المضمنة
لا تحدد عنوان URL لملف الصورة الخارجي في src الخاص بـ <img>، بل قم بوضع معلومات الصورة مباشرة. على سبيل المثال، يكون src="data:image/gif;base64,R0lGODlhDAAMAL..." مفيدًا في بعض الحالات الخاصة (على سبيل المثال، يتم استخدام صورة صغيرة فقط في الصفحة الحالية).
المبدأ 2: استخدام CDN متعدد الخطوط
تزويد موقعك بإمكانية الوصول إلى خطوط متعددة (مثل الاتصالات المحلية، تشاينا يونيكوم، تشاينا موبايل) ومواقع جغرافية متعددة (شمال، جنوب، غرب) حتى يتمكن جميع المستخدمين من الوصول إليه بسرعة.
المبدأ 3: استخدم ذاكرة التخزين المؤقت لـ HTTP
قم بإضافة معلومات رأس انتهاء الصلاحية الأطول إلى الموارد التي لا يتم تحديثها بشكل متكرر (مثل الصور الثابتة) بمجرد تخزين هذه الموارد مؤقتًا، لن يتم إرسالها مرة أخرى لفترة طويلة في المستقبل.
المبدأ الرابع: استخدم ضغط Gzip
استخدم Gzip لضغط رسائل HTTP لتقليل الحجم ووقت الإرسال.
المبدأ الخامس: ضع أوراق الأنماط في مقدمة الصفحة
قم بتحميل ورقة الأنماط أولاً حتى يبدأ عرض الصفحة مبكرًا، مما يمنح المستخدمين شعورًا بأن الصفحة يتم تحميلها بشكل أسرع.
المبدأ السادس: ضع النصوص في نهاية الصفحة
السبب هو نفسه 5. تتم معالجة عرض الصفحة أولاً، ويتم إكمال عرض الصفحة مسبقًا، ويتم تنفيذ منطق البرنامج النصي لاحقًا، مما يمنح المستخدم الشعور بأن الصفحة يتم تحميلها بشكل أسرع.
المبدأ السابع: تجنب استخدام تعبيرات CSS
سيؤدي منطق البرنامج النصي JavaScript المعقد للغاية وبحث DOM وعمليات التحديد إلى تقليل كفاءة معالجة الصفحة.
المبدأ الثامن: استخدم Javascript وCSS كموارد خارجية
يبدو أن هذا يتعارض مع فكرة الدمج في المبدأ 1، ولكنه ليس كذلك: مع الأخذ في الاعتبار أن كل صفحة تقدم مصدر JavaScript عام (مثل jQuery أو مكتبة JavaScript مثل ExtJS)، انطلاقًا من أداء صفحة واحدة فقط، مضمنة سيتم تحميل الصفحات (أي تضمين JavaScript في HTML) بشكل أسرع (بسبب انخفاض عدد طلبات HTTP) مقارنة بالصفحات الصادرة (المقدمة باستخدام علامات <script>). ولكن إذا قدمت العديد من الصفحات مورد JavaScript العام هذا، فسيتسبب المخطط المضمن في الإرسال المتكرر (نظرًا لأن هذا المورد مضمن في كل صفحة، يجب إرسال هذا الجزء من المورد في كل مرة يتم فيها فتح الصفحة، مما يتسبب في إهدار النقل عبر الشبكة) موارد). يمكن حل هذه المشكلة عن طريق جعل هذا المورد مستقلاً والرجوع إليه خارجيًا.
نظرًا لأن JavaScript وCSS مستقران نسبيًا، فيمكننا تعيين تواريخ انتهاء صلاحية أطول للموارد المقابلة لهما (راجع المبدأ 3).
المبدأ التاسع: تقليل عمليات بحث DNS
نصيحة المؤلف هي:
1. استخدم Keep-Alive للبقاء على اتصال
إذا تم قطع الاتصال، فسيتعين إجراء بحث DNS في المرة التالية التي يتم فيها الاتصال. حتى إذا تم تخزين تعيين اسم المجال IP المقابل مؤقتًا، فسيستغرق البحث بعض الوقت.
2. تقليل أسماء النطاقات
في كل مرة تطلب فيها اسم مجال جديد، تحتاج إلى البحث عن اسم مجال مختلف من خلال DNS، ولا يمكن أن تعمل ذاكرة التخزين المؤقت لـ DNS. لذلك، يجب أن تبذل قصارى جهدك لتنظيم الموقع تحت اسم نطاق موحد وتجنب استخدام عدد كبير جدًا من أسماء النطاقات الفرعية.
المبدأ العاشر: تصغير جافا سكريبت الخاص بك
استخدم أداة الضغط JS لضغط JavaScript، فهي فعالة جدًا. ما عليك سوى إلقاء نظرة على التوزيعتين المختلفتين لـ jQuery لمعرفة الفرق:
http://code.jquery.com/jquery-1.6.2.js نسخة القراءة كود jQuery، 230 كيلو بايت
http://code.jquery.com/jquery-1.6.2.min.js نسخة مضغوطة من كود jQuery (للنشر الفعلي)، 89.4 كيلو بايت
المبدأ 11 حاول تجنب عمليات إعادة التوجيه
تعني إعادة التوجيه أنه تتم إضافة جولة إضافية من طلبات HTTP قبل الوصول فعليًا إلى الصفحة التي تريد رؤيتها (يبدأ العميل طلب HTTP ← يقوم خادم HTTP بإرجاع استجابة إعادة توجيه ← يبدأ العميل طلبًا لعنوان URL جديد ← HTTP يقوم الخادم بإرجاع المحتوى، والأجزاء التي تحتها خط هي طلبات إضافية)، لذلك يستهلك المزيد من الوقت (مما يمنح الأشخاص أيضًا شعورًا بالاستجابة البطيئة). لذلك لا تستخدم عمليات إعادة التوجيه إلا إذا لزم الأمر. عدة حالات "ضرورية":
1. تجنب عناوين URL غير الصالحة
بعد ترحيل الموقع القديم، ومن أجل منع عنوان URL القديم من أن يصبح غير صالح، تتم عادةً إعادة توجيه طلبات عنوان URL القديم إلى العنوان المقابل للنظام الجديد.
2. تجميل URL
التحويل بين عناوين URL القابلة للقراءة وعناوين URL للموارد الفعلية، على سبيل المثال، بالنسبة لشريط أدوات Google، يتذكر المستخدمون http://toolbar.google.com، وهو عنوان دلالي للبشر، ولكن من الصعب تذكر http://www.google .com/tools/Firefox/toolbar/FT3/intl/en/index.html هو عنوان المورد الحقيقي. ولذلك فمن الضروري الإبقاء على الأول وإعادة توجيه طلبات الأول إلى الأخير.
المبدأ 12 إزالة البرامج النصية المكررة
لا تقم بتضمين نفس البرنامج النصي بشكل متكرر على الصفحة. على سبيل المثال، يعتمد كل من النصين B وC على A، لذلك قد تكون هناك إشارات متكررة إلى A في الصفحات التي تستخدم B وC. الحل هو التحقق يدويًا من التبعيات للمواقع البسيطة والتخلص من المقدمات المتكررة؛ بالنسبة للمواقع المعقدة، تحتاج إلى إنشاء آلية إدارة التبعيات/التحكم في الإصدار الخاصة بك.
المبدأ 13 تعامل مع علامات ETag بعناية
ETag هي طريقة أخرى لـ HTTP Cache إلى جانب Last-Modified. تحديد ما إذا كان المورد قد تم تعديله من خلال التجزئة. ولكن هناك بعض المشاكل في ETag، مثل:
1. عدم الاتساق: تحدد خوادم الويب المختلفة (Apache، IIS، وما إلى ذلك) تنسيقات ETag مختلفة
2. حساب ETag غير مستقر (بسبب مراعاة العديد من العوامل)، مثل:
1) تحتوي نفس الموارد على علامات ETag مختلفة محسوبة على خوادم مختلفة، وعادةً ما يتم تقديم تطبيقات الويب واسعة النطاق بواسطة أكثر من خادم واحد. وهذا يتسبب في أن تظل موارد العميل المخزنة مؤقتًا على الخادم A صالحة، ولكن في المرة التالية التي يطلب فيها B لأن عندما تكون علامة ETag مختلفة، فإنها تعتبر غير صالحة، مما يؤدي إلى تكرار إرسال نفس المورد.
2) يظل المورد دون تغيير، ولكن تتغير علامة ETag بسبب التغييرات في بعض العوامل الأخرى، مثل تغييرات ملف التكوين. والنتيجة المباشرة هي أنه بعد تحديث النظام، تحدث حالات فشل في ذاكرة التخزين المؤقت للعميل على نطاق واسع، مما يؤدي إلى زيادة كبيرة في حجم الإرسال وانخفاض في أداء الموقع.
اقتراح المؤلف هو: إما تحسين طريقة حساب ETag الحالية وفقًا لخصائص تطبيقك، أو ببساطة عدم استخدام ETag واستخدام أبسط طريقة تم تعديلها مؤخرًا.
المبدأ 14: الاستفادة من ذاكرة التخزين المؤقت لـ HTTP مع Ajax
أجاكس هو طلب غير متزامن، ولن تمنع الطلبات غير المتزامنة عملياتك الحالية، وعند اكتمال الطلب، يمكنك رؤية النتائج على الفور. لكن غير المتزامن لا يعني أنه يمكن إكماله على الفور، ولا يعني أنه يمكن التسامح معه ويستغرق وقتًا لا نهائيًا لإكماله. لذلك، يجب أيضًا الانتباه إلى أداء طلبات Ajax. هناك العديد من طلبات Ajax التي يمكنها الوصول إلى موارد مستقرة نسبيًا، لذا لا تنس الاستفادة من آلية HTTP Cache لطلبات Ajax للحصول على التفاصيل، راجع المبدأين 3 و13.
المؤلف: يانغ مينغدونغ
مصدر المقال: مدونة Yang Mengdong، يرجى الإشارة إلى رابط المصدر عند إعادة الطباعة.