مقدمة إلى HTTP / 2 وسرعة الصفحة

نشرت: 2020-01-03

مقدمة

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

تستهدف هذه المقالة مُحسّنات محرّكات البحث التي ترغب في تنفيذ HTTP / 2 كجزء من مبادرات تحسين سرعة الصفحة الخاصة بهم.

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

  1. كيف سيؤثر هذا بشكل مباشر على تحسين محرك البحث و / أو سرعة الصفحة؟
  2. هل يمكن تقديم توصية من البصيرة؟
  3. هل يمكن تنفيذ التوصية بشكل واقعي؟

تساعدك هذه الأسئلة على طرح السؤال "هل ما أفعله فعال وقيّم؟" ويضعك في النهاية في وضع أفضل لتقييم كيف يمكن أن يساعد HTTP / 2 في تحسين موقع الويب.

نظرًا للطبيعة الواسعة للموضوع ، هناك قدر كبير من المعرفة حول HTTP / 2 غير مطلوبة عند محاولة فهم أهمية تحسين محركات البحث. الميزة الأساسية لـ HTTP / 2 لتحسين محركات البحث هي سرعة الصفحة.

لمساعدتك في التنقل عبر ثروة المعلومات عبر الإنترنت ، إليك مقدمة إلى HTTP / 2 ، تصف التطور من HTTP 1.1 إلى Spdy المتوافق مع HTTP من Google وفي النهاية إلى HTTP / 2.

سيساعد فهم كيفية تطور الويب في إبراز التحسينات التي تم إجراؤها عليها كنتيجة لإضافة بروتوكول HTTP / 2.

كيف تقيم Google سرعة الصفحة؟

لإلقاء نظرة على كيفية تقييم Google لسرعة الصفحة ، لا تنظر إلى أبعد من تقارير تجربة مستخدم Chrome . توفر هذه التقارير مقاييس تجربة المستخدم لكيفية تجربة المستخدمين للوجهات الشائعة عبر الويب. يتم تشغيل هذا باستخدام مقاييس تفاعل المستخدم الرئيسية (First Paint و First Contentful Paint و First Meaningful Paint و Time to Interactive) ويتم دعمه أيضًا عبر أدوات شائعة مثل Page Speed ​​Insights و Public Google Big Query Project و Lighthouse و Web Page Test. يمكن أن يساعد استخدام هذه المقاييس والأدوات في إجراء تحسينات ممكنة حول سرعة الصفحة.

مقدمة إلى HTTP / 2

HTTP 1.1

بحلول عام 2015 ، أصبح HTTP 1.1 قديمًا. لقد ولت الأيام التي تم فيها بناء / اعتماد صفحات / مواقع الويب على HTML و CSS و JavaScript الأساسيين والعديد من الموارد والأطر المختلفة. استند حقبة ما قبل 2015 إلى فكرة أنك كنت مقيدًا بطلب واحد لكل اتصال TCP. أدى ذلك إلى مواقف كان فيها عملاء الويب لديهم موارد متعددة في قائمة انتظار للتنزيل ، مما تسبب في ازدحام الشبكة وأوقات تحميل الصفحة البطيئة.

تم تصميم HTTP / 2 لاستهداف ثلاثة مجالات رئيسية للتحسين للتخفيف من المشكلات التي تمت مناقشتها أعلاه:

  • بساطة
  • أداء عالي
  • المتانة

فوائد تحسين محركات البحث لـ HTTP / 2

ربما تكون سرعة الصفحة هي السبب الرئيسي الذي يدفع مُحسّنات محرّكات البحث إلى التفكير في تنفيذ HTTP / 2 عبر مواقع الويب الخاصة بهم أو مواقع عملائهم. سرعة / أداء الصفحة عبارة عن مجموعة من المقاييس التي كانت عاملاً في الترتيب منذ عام 2010 لاستعلامات سطح المكتب. نظرًا لارتفاع استخدام الأجهزة المحمولة ، أعلنت Google رسميًا في يوليو 2018 أن سرعة الصفحة ستصبح عاملاً تصنيفيًا للجوال.

يوفر HTTP / 2 3 وظائف رئيسية يمكن استخدامها عند تحسين المواقع لسرعة الصفحة:

  1. مضاعفة
  2. دفع الخادم
  3. ترتيب أولويات البث

مضاعفة

يسمح تعدد الإرسال لعميل الويب بتضمين طلبات متعددة في اتصال TCP واحد ، مما يؤدي إلى انخفاض تحميل الخادم وتقليل ازدحام الشبكة.

عملاء الويب الحديثون (Chrome و Firefox و Safari و Opera) الذين يستخدمون بروتوكولات HTTP 1 / 1.1 الأقدم لديهم حد افتراضي لعدد اتصالات TCP المتزامنة لكل اسم مضيف. لذلك ، يمكن أن يواجه عميل الويب الذي يستخدم HTTP 1 / 1.1 صعوبة في ازدحام TCP. مع عملاء الويب الحديثين ، يتم حل هذه المشكلة باستخدام مضاعفة الإرسال ، والتي يمكن أن توفر بعضًا من أهم التحسينات على سرعة الصفحة.

الموضح أدناه هو فائدة تعدد الإرسال باستخدام مقارنة HTTP / 1.1 و HTTP / 2 ، مما يُظهر السلوك النموذجي عندما يكون تعدد إرسال HTTP / 2 ممكّنًا وغير ممكن.

( WebpageTest ، HTTP / 1.1 ، لا يوجد تعدد معروض )

( WebpageTest، HTTP / 2، Multiplexing Demonstrated )

في الصور أعلاه ، يتم استخدام الشلال المستند إلى الأداء لإظهار تحميل الموارد بين المستخدم (الذي يطلب الموارد) والخادم (الذي يستجيب للموارد) لصفحة الويب. عادةً ما تتضمن موارد الصفحة HTML و JavaScript و CSS والصور. يوضح الشلال المستند إلى الأداء النقطة الدقيقة عند استدعاء مورد معين وتنزيله وعرضه داخل العميل وهو أمر بالغ الأهمية في اكتشاف مشكلات سرعة الصفحة وتقييمها وتحليلها على الموقع. كما هو موضح بالصورة أعلاه "HTTP / 2" ، تبدأ جميع الموارد في التنزيل بشكل متزامن دون بدء تحميل أي موارد عند نقطة مختلفة. نظرًا لأن HTTP / 2 يستخدم تعدد الإرسال ولم يعد يعتمد على إرسال طلب واحد فقط عبر اتصال TCP واحد ، يمكن تنزيل موارد متعددة في نفس الوقت كما هو موضح أعلاه. في المقابل ، كما هو موضح في الصورة "HTTP / 1.1" ، لا يتم تنزيل الموارد بشكل متزامن لأنها غير قادرة على استخدام وظيفة تعدد الإرسال. يمكن للمتصفح الحديث المتوسط ​​تحت HTTP / 1.1 أن يكون لديه 6 اتصالات بشكل متزامن ، ولكن فائدة تنفيذ HTTP / 2 هي أن مصافحة TCP ليست ضرورية لكل طلب بينما بغض النظر عن عدد الاتصالات التي يمكن تشغيلها بشكل متزامن مع HTTP / 1.1 أولي يجب أن تكتمل عملية الاتصال في كل مرة. لذلك بدأوا في التنزيل في نقاط مختلفة مما تسبب في تحميل صفحة أطول للمستخدم.

( Upwork HTTP / 1.1 مقابل مخطط HTTP / 2 )

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

دفع الخادم

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

افتراضيًا ، فكر في موقع به جميع أنماطه المحددة في ورقة أنماط خارجية تسمى styles.css. عندما يطلب المستخدم هيكل HTML للصفحة (دعنا نقول في هذه الحالة index.html) ، يمكن لدفع دفع الخادم "دفع" CSS إلى المستخدم مباشرة بعد البدء في إرسال استجابة إلى index.html.

( مجلة S mashing ، دفع الخادم )

قبل فهم كيف يمكن أن يساعد Server Push في تحسين سرعة الصفحة ، من المهم فهم كيفية عمل المستعرض مع الموارد المختلفة مثل الصور و CSS و JavaScript للظهور داخل المستعرض الخاص بك. كما ترى ، يرسل المستعرض إرشادات حول كيفية تنزيل موارد الصور و CSS وجافا سكريبت. عند زيارتك لموقع ويب لأول مرة ، عادة ما تقدم طلب GET ، وهو ملف .html. بمجرد استلام ملف .html هذا ، يقوم المستعرض بالمسح من خلاله لفهمه ومن ثم قد يقدم طلبات GET إضافية بناءً على ما هو موجود في ملف HTML.

كيف يساعد Server Push في تحسين سرعة الصفحة؟

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

بينما لا يؤثر Server Push بشكل مباشر في كيفية قيام Googlebot بالزحف إلى موقعك ، أو في الواقع برامج الزحف الأخرى ، يتم اكتساب فائدة تحسين محركات البحث من خلال التحسينات على العوامل التي تركز على المستخدم مثل First Paint و First Meaningful Content.

باستخدام Web Page Test و Lighthouse و Page Speed ​​Insights وتقرير تجربة مستخدم Chrome ، يمكنك تحديد كيفية أداء موقع / صفحة مقارنة بالمنافسين في نفس الصناعات. يوجد أدناه صورتان توضحان التنفيذ بدون (الصورة 1) وبواسطة Server Push (الصورة 2).

(WebpageTest ، بدون دفع الخادم)

(WebpageTest ، HTTP / 1.1 ، مع دفع الخادم)

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

في الشلالات أعلاه يمكننا أن نرى أن push.php يستخدم أربعة ملفات CSS.

بدون دفع الخادم ، يحتاج المتصفح إلى تلقي ملف push.php وتحليل HTML ثم تقديم طلبات محددة لكل ملف CSS إضافي. بمجرد استلام جميع ملفات CSS ، يمكنه البدء في استخدامها في عملية العرض.

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

تحديد أولويات HTTP / 2

تتحكم أولوية HTTP / 2 في ترتيب تحميل الموارد ، والعودة إلى مالكي الموقع. إذا تم بشكل صحيح ، فإن تحديد الأولويات يفيد تجربة المستخدم وسرعة الصفحة / الموقع من خلال تقديم موارد الصفحة بترتيب مُحسَّن ، وبالتالي إنشاء تجربة مستخدم "سريعة".

إذا نظرنا إلى HTTP / 1.1 السابق لـ HTTP / 2 ، فإن عميل الويب يتحكم في ترتيب وقت تحميل الموارد. كما نوقش أعلاه ، كان هذا بسبب حقيقة أن كل اتصال TCP كان قادرًا فقط على دعم مورد واحد في كل مرة. الأمر متروك للمتصفح لجدولة الطلبات من خلال تحديد الموارد التي يختارها وعدد الاتصالات التي سيتم فتحها بشكل متوازٍ.

قبل الدخول في كيفية القيام بذلك ، من المهم أن نفهم سبب رغبتنا في استخدام تحديد الأولويات لمواردنا.

إذا كانت لدينا صورة في الجزء العلوي من الصفحة وصورة في الجزء السفلي من الصفحة ، فمن المنطقي أننا نريد التأكد من تحميل الصورة في الجزء العلوي قبل تحميل الصورة في الجزء السفلي. يساعد هذا المفهوم في إظهار أهمية وتأثير HTTP / 2 Prioritization الذي يمكن أن يجلبه. تتيح لنا أولوية HTTP / 2 تحديد الموارد التي يجب تسليمها أولاً وتحميلها قبل الآخرين (سواء كانت JavaScript أو CSS أو صورًا) ، وبالتالي ضمان أسرع وقت تحميل للصفحة.

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

دفق: هذا هو تدفق ثنائي الاتجاه للبايتات داخل اتصال قائم قد يحمل واحدًا أو رسالة.

الدفق الأصل: هذا دفق تعتمد عليه الموارد

دفق الطفل: هذا دفق تابع للتيار الرئيسي. يتشاركون نفس الوالد وبالتالي يُعرفون باسم التدفق الفرعي

الوزن: هذا هو الرقم المخصص بين 1 و 256 والذي يحدد مقدار النطاق الترددي المراد تخصيصه للدفق إذا كانت هناك تدفقات متعددة تشترك في الاتصال. يتم تخصيص النطاق الترددي بالنسبة إلى أوزان جميع التدفقات النشطة الأخرى.

بت حصري: هذه علامة تشير إلى وجوب تنزيل الدفق دون مشاركة النطاق الترددي مع أي تدفقات أخرى.

إطار الرؤوس: هذا هو التعريف للدفق الذي ينتمي إليه الإطار

طبقة الإطارات الثنائية: هذه هي الطريقة التي يتم بها تغليف رسائل HTTP ونقلها بين العميل والخادم

يوضح المثال أدناه مثالاً لما سبق:

( Google Developers HTTP / 2 Stream Prioritization )

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

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

تحديد أولويات HTTP / 2 - توافق الخادم المشترك / الاستضافة / شبكات CDN

كانت هذه المقارنة صحيحة في 02/01/2020 ، لكن الأمر يستحق التحقق مما إذا كان مقدمو الخدمة المحتملون قد قاموا بتحسين توافقهم قبل اتخاذ قرارك بشأن الاختيار.

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

توافق عميل ويب HTTP / 2 Prioritization Web Client

يمكن أن يؤدي تحديد أولويات HTTP / 2 إلى تحسين تصور المستخدم بشكل كبير لسرعة الصفحة / الموقع وسيؤثر بشكل إيجابي على البيانات المتراكمة في تقرير تجربة مستخدم Chrome. في حين أن هذا التحسين ليس له أي تأثير على برامج زحف البحث مثل Googlebot ، فإن أدوات مثل Lighthouse و Page Speed ​​Insights ستساعدك على تقييم تأثير تحديد أولوية HTTP / 2 على أداء سرعة الصفحة من منظور المستخدم.

من خلال تكوين وزن البث بشكل صحيح مع كل من الخادم والعميل باستخدام HTTP / 2 CDN / المضيف المدعوم ، ستتمكن من تحسين مقاييس سرعة صفحتك بشكل كبير لعميلك.

ما هي المتطلبات الأساسية لـ HTTP / 2

قبل أن تتمكن من الاستفادة من مزايا سرعة HTTP / 2 ، تأكد من قدرتك على الاستفادة منه. هناك بعض المتطلبات الأساسية التي يجب مراعاتها:

  1. من المهم التأكد من تمكين HTTPS.
  2. استخدم شهادة TLS من سلطة مصادقة وقم بتنشيط الشهادة وتثبيتها.
  3. تأكد من أن برنامج خادم الويب الخاص بك مثل Nginx و Apache و IIS يدعم HTTP / 2. يمكن العثور على قائمة مصادقة كاملة للدعم على http://ayi.ma/browsershttp2 والتي ستظهر دعم المتصفح لـ HTTP / 2. إذا كنت تبحث عن دعم HTTP / 2 لـ CDN / Hosting ، فيرجى الرجوع إلى http://ayi.ma/serverhosting .

المزالق / الأشياء الشائعة التي يجب أن تتغير مع إدخال HTTP / 2

نظرًا للقيود المفروضة على بروتوكولات HTTP 1.0 و HTTP 1.1 السابقة ، سعى المطورون ومُحسِّن محركات البحث إلى إيجاد طرق للتغلب على المشكلات العديدة التي قدمتها هذه القيود لأداء سرعة الصفحة وأمانها.

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

تجنب تقسيم المجال

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

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

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

الاستفادة بشكل صحيح من دفع الخادم

يحتوي Server Push على بعض العيوب التي يجب أن تكون على دراية بها. يمكن في الواقع الإفراط في استخدام Server Push ويجب أن تكون انتقائيًا عند اختيار وقت استخدامه. أنت لا تريد بالضرورة دفع الكثير من الموارد لأن هذا قد يتسبب في قيام عميل الويب بتنزيل HTML ليس فقط ولكن كل ما يتم "دفعه" من خلاله. هذا يعني أن الصفحة قد تستغرق وقتًا أطول للتحميل والعرض (زيادة المقاييس التي تركز على المستخدم والتي تركز عليها Google مثل Time to Interactive).

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

اختبارات الحياة الواقعية تحت HTTP / 2

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

الجزء 2 من سلسلة سرعة الصفحة هذه ، HTTP / 2 In Real Life - باستخدام اختبارات وتحليلات موقع الويب سيناقش الفائدة الحقيقية لـ HTTP / 2 فيما يتعلق بسرعة الصفحة وقيمة تحسين محركات البحث ، لذلك لا تفوت!

ماذا عن HTTP / 3؟

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