أداء الواجهة الأمامية 2021: الشبكات ، HTTP / 2 ، HTTP / 3

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

جدول المحتويات

1. الاستعداد: التخطيط والقياسات
2. تحديد أهداف واقعية
3. تعريف البيئة
4. تحسينات الأصول
5. بناء التحسينات
6. تحسينات التسليم
7. الشبكات ، HTTP / 2 ، HTTP / 3
8. الاختبار والمراقبة
9. انتصارات سريعة
10. كل شيء في صفحة واحدة
11. قم بتنزيل قائمة التحقق (PDF ، Apple Pages ، MS Word)
12. اشترك في النشرة الإخبارية عبر البريد الإلكتروني حتى لا تفوت الأدلة التالية.

الشبكات ، HTTP / 2 ، HTTP / 3

1. هل التدبيس OCSP ممكّن؟
   من خلال تمكين تدبيس OCSP على الخادم الخاص بك ، يمكنك تسريع مصافحات TLS الخاصة بك. تم إنشاء بروتوكول حالة الشهادة عبر الإنترنت (OCSP) كبديل لبروتوكول قائمة إبطال الشهادات (CRL). يتم استخدام كلا البروتوكولين للتحقق مما إذا كان قد تم إبطال شهادة SSL.

   ومع ذلك ، فإن بروتوكول OCSP لا يتطلب من المتصفح قضاء بعض الوقت في التنزيل ثم البحث في قائمة للحصول على معلومات الشهادة ، وبالتالي تقليل الوقت المطلوب للمصافحة.

2. هل قللت من تأثير إلغاء شهادة SSL؟
   في مقالته عن "تكلفة أداء شهادات EV" ، يقدم Simon Hearne نظرة عامة رائعة على الشهادات الشائعة ، والتأثير الذي قد يكون لاختيار الشهادة على الأداء العام.

   كما كتب سايمون ، في عالم HTTPS ، هناك عدة أنواع من مستويات التحقق من صحة الشهادات المستخدمة لتأمين حركة المرور:

   • التحقق من صحة المجال (DV) يتحقق من أن طالب الشهادة يمتلك المجال ،
   • التحقق من صحة المؤسسة (OV) يتحقق من أن المؤسسة تمتلك المجال ،
   • التحقق من الصحة الموسعة (EV) يتحقق من أن المؤسسة تمتلك المجال ، مع التحقق الصارم من الصحة.

   من المهم ملاحظة أن جميع هذه الشهادات هي نفسها من حيث التكنولوجيا ؛ أنها تختلف فقط في المعلومات والخصائص المقدمة في تلك الشهادات.

   شهادات EV باهظة الثمن وتستغرق وقتًا طويلاً لأنها تتطلب من الإنسان مراجعة الشهادة والتأكد من صحتها. من ناحية أخرى ، غالبًا ما يتم توفير شهادات DV مجانًا - على سبيل المثال من خلال Let's Encrypt - سلطة تصديق آلية مفتوحة ومتكاملة جيدًا في العديد من موفري الاستضافة وشبكات CDN. في الواقع ، في وقت كتابة هذا التقرير ، كان يشغل أكثر من 225 مليون موقع (PDF) ، على الرغم من أنه يمثل 2.69٪ فقط من الصفحات (المفتوحة في Firefox).

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

   لا تعد شهادات EV خيارًا رائعًا لأداء الويب ، ويمكن أن تسبب تأثيرًا أكبر بكثير على الأداء من شهادات DV. للحصول على أفضل أداء للويب ، قم دائمًا بتقديم شهادة DV مدمجة OCSP. كما أنها أرخص بكثير من شهادات EV وأقل صعوبة في الحصول عليها. حسنًا ، على الأقل حتى يتوفر CRLite.

   

   ملاحظة : مع استخدام QUIC / HTTP / 3 علينا ، تجدر الإشارة إلى أن سلسلة شهادات TLS هي المحتوى المتغير الحجم الذي يهيمن على عدد البايت في QUIC Handshake. يختلف الحجم بين بضع مئات من البايت وأكثر من 10 كيلوبايت.

   لذا ، فإن الاحتفاظ بشهادات TLS صغيرة أمر مهم كثيرًا على QUIC / HTTP / 3 ، حيث أن الشهادات الكبيرة ستتسبب في العديد من المصافحة. أيضًا ، نحتاج إلى التأكد من أن الشهادات مضغوطة ، وإلا ستكون سلاسل الشهادات كبيرة جدًا بحيث لا يمكن وضعها في رحلة QUIC واحدة.

   يمكنك العثور على مزيد من التفاصيل والمؤشرات للمشكلة والحلول على:

   • شهادات EV تجعل الويب بطيئًا وغير موثوق به بواسطة آرون بيترز ،
   • تأثير إبطال شهادة SSL على أداء الويب بواسطة Matt Hobbs ،
   • تكلفة أداء شهادات EV بواسطة Simon Hearne ،
   • هل تتطلب مصافحة QUIC الضغط لتكون سريعة؟ بواسطة باتريك مكمانوس.
3. هل اعتمدت IPv6 حتى الآن؟
   نظرًا لأن المساحة المتوفرة لدينا مع IPv4 تنفد ، وتعتمد شبكات المحمول الرئيسية IPv6 بسرعة (وصلت الولايات المتحدة تقريبًا إلى حد اعتماد IPv6 بنسبة 50٪) ، فمن المستحسن تحديث DNS الخاص بك إلى IPv6 للبقاء ضد الرصاص في المستقبل. فقط تأكد من توفير دعم المكدس المزدوج عبر الشبكة - فهو يسمح لـ IPv6 و IPv4 بالعمل في نفس الوقت جنبًا إلى جنب مع بعضهما البعض. بعد كل شيء ، IPv6 غير متوافق مع الإصدارات السابقة. تظهر الدراسات أيضًا أن IPv6 جعل ​​هذه المواقع أسرع بنسبة 10 إلى 15٪ بسبب اكتشاف الجوار (NDP) وتحسين المسار.
4. تأكد من تشغيل جميع الأصول عبر HTTP / 2 (أو HTTP / 3).
   مع دفع Google نحو شبكة HTTPS أكثر أمانًا على مدار السنوات القليلة الماضية ، يعد التحول إلى بيئة HTTP / 2 استثمارًا جيدًا بالتأكيد. في الواقع ، وفقًا لتقويم الويب Web Almanac ، فإن 64٪ من جميع الطلبات تعمل عبر HTTP / 2 بالفعل.

   من المهم أن نفهم أن HTTP / 2 ليس مثاليًا ولديه مشكلات في تحديد الأولويات ، ولكنه مدعوم جيدًا ؛ وفي معظم الحالات ، تكون أفضل حالًا معها.

   كلمة تحذير: تتم إزالة HTTP / 2 Server Push من Chrome ، لذلك إذا كان التنفيذ يعتمد على Server Push ، فقد تحتاج إلى إعادة النظر فيه. بدلاً من ذلك ، ربما نبحث في Early Hints ، والتي تم دمجها كتجربة في Fastly بالفعل.

   إذا كنت لا تزال تعمل على HTTP ، فستكون المهمة الأكثر استهلاكا للوقت هي الترحيل إلى HTTPS أولاً ، ثم ضبط عملية الإنشاء الخاصة بك لتلبية تعدد إرسال وتوازي HTTP / 2. إن إحضار HTTP / 2 إلى Gov.uk هو دراسة حالة رائعة لفعل ذلك بالضبط ، وإيجاد طريقة من خلال CORS و SRI و WPT على طول الطريق. بالنسبة لبقية هذه المقالة ، نفترض أنك إما تقوم بالتبديل إلى HTTP / 2 أو أنك قمت بالفعل بالتبديل إليه.

1. نشر HTTP / 2 بشكل صحيح.
   مرة أخرى ، يمكن أن يستفيد عرض الأصول عبر HTTP / 2 من الإصلاح الجزئي لكيفية خدمة الأصول حتى الآن. ستحتاج إلى إيجاد توازن دقيق بين وحدات التغليف وتحميل العديد من الوحدات الصغيرة بالتوازي. في نهاية اليوم ، لا يزال أفضل طلب هو عدم وجود طلب ، ومع ذلك ، فإن الهدف هو إيجاد توازن جيد بين التسليم الأول السريع للأصول والتخزين المؤقت.

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

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

   

   

   ومع ذلك ، يمكنك محاولة تحميل CSS بشكل تدريجي. في الواقع ، لم يعد CSS داخل الجسم يحظر العرض لـ Chrome. ولكن هناك بعض مشكلات تحديد الأولويات ، لذا فهي ليست مباشرة بنفس القدر ، ولكنها تستحق التجربة.

   يمكنك الابتعاد عن دمج اتصال HTTP / 2 ، والذي يسمح لك باستخدام تجزئة النطاق أثناء الاستفادة من HTTP / 2 ، ولكن تحقيق ذلك عمليًا أمر صعب ، وبشكل عام ، لا يعتبر ممارسة جيدة. أيضًا ، لا يتم دائمًا تشغيل HTTP / 2 و Subresource Integrity.

   ما يجب القيام به؟ حسنًا ، إذا كنت تعمل عبر HTTP / 2 ، فإن إرسال حوالي 6-10 حزم يبدو وكأنه حل وسط لائق (وليس سيئًا للغاية بالنسبة للمتصفحات القديمة). قم بالتجربة والقياس للعثور على التوازن الصحيح لموقعك على الويب.

2. هل نرسل جميع الأصول عبر اتصال HTTP / 2 واحد؟
   تتمثل إحدى المزايا الرئيسية لـ HTTP / 2 في أنه يسمح لنا بإرسال الأصول عبر السلك عبر اتصال واحد. ومع ذلك ، في بعض الأحيان ربما نكون قد فعلنا شيئًا خاطئًا - على سبيل المثال ، لديك مشكلة في CORS ، أو أخطأنا في تكوين سمة crossorigin ، لذلك سيضطر المتصفح إلى فتح اتصال جديد.

   للتحقق مما إذا كانت جميع الطلبات تستخدم اتصال HTTP / 2 واحدًا أو خطأ في تكوين شيء ما ، قم بتمكين عمود "معرف الاتصال" في DevTools → Network. على سبيل المثال ، تشترك جميع الطلبات هنا في نفس الاتصال (286) - باستثناء الملف manifest.json ، الذي يفتح اتصالاً منفصلاً (451).

1. هل تدعم الخوادم وشبكات CDN بروتوكول HTTP / 2؟
   الخوادم المختلفة وشبكات CDN (لا تزال) تدعم HTTP / 2 بشكل مختلف. استخدم مقارنة CDN للتحقق من خياراتك ، أو ابحث بسرعة عن كيفية أداء الخوادم والميزات التي يمكنك توقع دعمها.

   استشر بحث Pat Meenan المذهل حول أولويات HTTP / 2 (فيديو) واختبار دعم الخادم لتحديد أولويات HTTP / 2. وفقًا لبات ، يوصى بتمكين التحكم في ازدحام BBR وتعيين tcp_notsent_lowat على 16 كيلو بايت لتحديد أولويات HTTP / 2 للعمل بشكل موثوق على Linux 4.9 kernels والإصدارات الأحدث ( شكرًا ، Yoav! ). أجرى Andy Davies بحثًا مشابهًا لتحديد أولويات HTTP / 2 عبر المتصفحات وشبكات CDN وخدمات الاستضافة السحابية.

   أثناء تشغيله ، تحقق جيدًا مما إذا كان kernel الخاص بك يدعم TCP BBR وقم بتمكينه إذا كان ذلك ممكنًا. يتم استخدامه حاليًا على Google Cloud Platform و Amazon Cloudfront و Linux (مثل Ubuntu).

2. هل ضغط HPACK قيد الاستخدام؟
   إذا كنت تستخدم HTTP / 2 ، فتحقق جيدًا من أن خوادمك تنفذ ضغط HPACK لرؤوس استجابة HTTP لتقليل الحمل غير الضروري. قد لا تدعم بعض خوادم HTTP / 2 المواصفات بشكل كامل ، ويعتبر HPACK مثالاً على ذلك. H2spec هي أداة رائعة (إذا كانت مفصلة للغاية من الناحية الفنية) للتحقق من ذلك. خوارزمية ضغط HPACK رائعة للغاية ، وهي تعمل.
3. تأكد من أن الأمن على الخادم الخاص بك مضاد للرصاص.
   تعمل جميع عمليات تنفيذ المستعرض لـ HTTP / 2 عبر TLS ، لذلك قد ترغب في تجنب التحذيرات الأمنية أو أن بعض العناصر في صفحتك لا تعمل. تحقق جيدًا من تعيين رؤوس الأمان بشكل صحيح ، وتخلص من الثغرات الأمنية المعروفة ، وتحقق من إعداد HTTPS.

   تأكد أيضًا من تحميل جميع المكونات الإضافية الخارجية ونصوص التتبع عبر HTTPS ، وأن البرمجة النصية عبر المواقع غير ممكنة وأنه تم تعيين رؤوس HTTP Strict Transport Security ورؤوس سياسة أمان المحتوى بشكل صحيح.

4. هل تدعم الخوادم وشبكات CDN بروتوكول HTTP / 3؟
   على الرغم من أن HTTP / 2 قد جلب عددًا من التحسينات الهامة في الأداء على الويب ، إلا أنه ترك أيضًا مجالًا للتحسين - خاصةً حظر رأس الخط في TCP ، والذي كان ملحوظًا على شبكة بطيئة مع فقد كبير في الحزمة. يقوم HTTP / 3 بحل هذه المشكلات إلى الأبد (مقال).

   لمعالجة مشكلات HTTP / 2 ، تعمل IETF جنبًا إلى جنب مع Google و Akamai وغيرهما على بروتوكول جديد تم توحيده مؤخرًا باعتباره HTTP / 3.

   لقد شرح روبن ماركس HTTP / 3 جيدًا ، والتفسير التالي مبني على تفسيره. في جوهره ، يشبه HTTP / 3 إلى حد كبير HTTP / 2 من حيث الميزات ، ولكنه يعمل بشكل مختلف تمامًا تحت الغطاء. يوفر HTTP / 3 عددًا من التحسينات: مصافحة أسرع وتشفير أفضل وتدفق مستقل أكثر موثوقية وتشفير أفضل وتحكم في التدفق. يتمثل الاختلاف الملحوظ في أن HTTP / 3 يستخدم QUIC كطبقة نقل ، مع حزم QUIC مغلفة أعلى مخططات UDP ، بدلاً من TCP.

   يدمج QUIC بشكل كامل TLS 1.3 في البروتوكول ، بينما في TCP يتم وضعه في الأعلى. في مكدس TCP النموذجي ، لدينا بضع مرات ذهابًا وإيابًا من النفقات العامة لأن TCP و TLS يحتاجان إلى إجراء مصافحة منفصلة خاصة بهما ، ولكن مع QUIC يمكن دمجهما وإكمالهما في رحلة واحدة ذهابًا وإيابًا فقط . نظرًا لأن TLS 1.3 يسمح لنا بإعداد مفاتيح التشفير لاتصال لاحق ، فمن الاتصال الثاني فصاعدًا ، يمكننا بالفعل إرسال واستقبال بيانات طبقة التطبيق في أول رحلة ذهابًا وإيابًا ، والتي تسمى "0-RTT".

   أيضًا ، تمت إعادة كتابة خوارزمية ضغط الرأس لـ HTTP / 2 بالكامل ، جنبًا إلى جنب مع نظام تحديد الأولويات الخاص بها. بالإضافة إلى ذلك ، يدعم QUIC ترحيل الاتصال من Wi-Fi إلى الشبكة الخلوية عبر معرفات الاتصال في رأس كل حزمة QUIC. تتم معظم عمليات التنفيذ في مساحة المستخدم ، وليس في مساحة kernel (كما هو الحال مع TCP) ، لذلك يجب أن نتوقع تطور البروتوكول في المستقبل.

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

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

   HTTP / 3 لا يزال قيد العمل. Chrome و Firefox و Safari بها تطبيقات بالفعل. بعض شبكات CDN تدعم QUIC و HTTP / 3 بالفعل. في أواخر عام 2020 ، بدأ Chrome في نشر HTTP / 3 و IETF QUIC ، وفي الواقع تعمل جميع خدمات Google (Google Analytics و YouTube وما إلى ذلك) بالفعل عبر HTTP / 3. يدعم LiteSpeed ​​Web Server بروتوكول HTTP / 3 ، ولكن لا يدعمه أي من Apache أو nginx أو IIS حتى الآن ، ولكن من المحتمل أن يتغير بسرعة في عام 2021.

   خلاصة القول : إذا كان لديك خيار استخدام HTTP / 3 على الخادم وعلى شبكة CDN الخاصة بك ، فمن المحتمل أن يكون القيام بذلك فكرة جيدة. ستأتي الفائدة الرئيسية من جلب كائنات متعددة في وقت واحد ، لا سيما في الاتصالات ذات زمن الانتقال العالي. لا نعرف على وجه اليقين حتى الآن لأنه لم يتم إجراء الكثير من الأبحاث في هذا المجال ، ولكن النتائج الأولى واعدة للغاية.

   إذا كنت ترغب في التعمق أكثر في تفاصيل ومزايا البروتوكول ، فإليك بعض نقاط البداية الجيدة للتحقق منها:

   • شرح HTTP / 3 ، جهد تعاوني لتوثيق بروتوكولات HTTP / 3 و QUIC. متوفر بلغات مختلفة ، أيضًا بصيغة PDF.
   • رفع مستوى أداء الويب باستخدام HTTP / 3 مع Daniel Stenberg.
   • يقدم الدليل الأكاديمي لـ QUIC مع Robin Marx المفاهيم الأساسية لبروتوكولات QUIC و HTTP / 3 ، ويشرح كيف يتعامل HTTP / 3 مع حظر رأس الخط وترحيل الاتصال ، وكيف تم تصميم HTTP / 3 ليكون دائمًا (شكرًا ، Simon ) !).
   • يمكنك التحقق مما إذا كان الخادم الخاص بك يعمل على HTTP / 3 على HTTP3Check.net.

جدول المحتويات

1. الاستعداد: التخطيط والقياسات
2. تحديد أهداف واقعية
3. تعريف البيئة
4. تحسينات الأصول
5. بناء التحسينات
6. تحسينات التسليم
7. الشبكات ، HTTP / 2 ، HTTP / 3
8. الاختبار والمراقبة
9. انتصارات سريعة
10. كل شيء في صفحة واحدة
11. قم بتنزيل قائمة التحقق (PDF ، Apple Pages ، MS Word)
12. اشترك في النشرة الإخبارية عبر البريد الإلكتروني حتى لا تفوت الأدلة التالية.