تحسين الأداء باستخدام شبكة توصيل المحتوى.
تُحسِّن شبكات توصيل المحتوى (CDN) أداء الموقع الإلكتروني من خلال استخدام شبكة من الخوادم الموزعة لتوفير الموارد للمستخدمين. نظرًا لأن شبكات توصيل المحتوى (CDN) تقلِّل حِمل الخادم، فهي تقلِّل تكاليف الخادم وهي مناسبة تمامًا للتعامل مع تكدس البيانات. تناقش هذه المقالة كيفية عمل شبكات توصيل المحتوى (CDN) وتقدّم إرشادات غير مرتبطة بالنظام الأساسي حول اختيار إعداد شبكة توصيل محتوى (CDN) وتهيئته وتحسينه.
نظرة عامة
تتكون شبكة توصيل المحتوى من شبكة من الخوادم التي تم تحسينها لتقديم المحتوى بسرعة للمستخدمين. على الرغم من أنّ شبكات توصيل المحتوى (CDN) هي الأكثر شهرة في مجال عرض المحتوى المخزن مؤقتًا، يمكنها أيضًا تحسين عرض المحتوى غير القابل للتخزين المؤقت. وبشكلٍ عام، كلما تقدّم شبكة توصيل المحتوى (CDN) أكثر من موقعك الإلكتروني، كان ذلك أفضل.
وعلى مستوى عالٍ، تنبع فوائد أداء شبكات توصيل المحتوى (CDN) من مجموعة من المبادئ: تقع خوادم شبكة توصيل المحتوى (CDN) بالقرب من المستخدمين أكثر من خوادم المصدر، وبالتالي يكون وقت الاستجابة المراسلة النصية في الوقت الفعلي (RTT) أقصر. وتتيح تحسينات الشبكات لشبكات توصيل المحتوى (CDN) عرض المحتوى بسرعة أكبر مما لو تم تحميل المحتوى "مباشرة" من خادم المصدر. وأخيرًا، تلغي ذاكرات التخزين المؤقت لشبكة عرض المحتوى الحاجة إلى نقل الطلب إلى الخادم.
تسليم الموارد
على الرغم من أنّ استخدام شبكة توصيل المحتوى (CDN) لتسليم الموارد (حتى لو لم يكن قابلاً للتخزين المؤقت) قد يبدو غير بديهيّ، سيكون عادةً أسرع من تحميل المستخدم للمورد "مباشرةً" من خوادمك.
عند استخدام شبكة توصيل المحتوى (CDN) لتسليم الموارد من المصدر، يتم إنشاء اتصال جديد بين العميل وخادم شبكة توصيل المحتوى (CDN) القريب. تحدث بقية الرحلة (أي نقل البيانات بين خادم CDN ومصدره) عبر شبكة CDN التي تتضمن غالبًا الاتصالات الحالية والمستمرة مع المصدر. هناك فوائد لذلك من شقين: إنهاء الاتصال الجديد أقرب ما يكون إلى المستخدم يؤدي إلى توفير تكاليف إعداد الاتصال غير الضرورية (إن إنشاء اتصال جديد مكلف ويتطلب عدة رحلات ذهاب وعودة)؛ ويسمح استخدام اتصال تمت إعادة تشغيله مسبقًا بنقل البيانات على الفور بأقصى سرعة ممكنة لمعالجة البيانات.
وتحسّن بعض شبكات توصيل المحتوى (CDN) هذا الأمر بشكل أكبر من خلال توجيه حركة البيانات إلى المصدر عبر خوادم شبكة توصيل المحتوى (CDN) المتعددة المنتشرة على الإنترنت. تحدث الاتصالات بين خوادم شبكة توصيل المحتوى عبر مسارات موثوق بها ومحسّنة للغاية، بدلاً من المسارات التي يحددها بروتوكول بوابة الحدود (BGP). على الرغم من أن بروتوكول BGP هو بروتوكول التوجيه الفعلي على الإنترنت، فإن قرارات التوجيه الخاصة به لا تكون دائمًا موجهة نحو الأداء. لذلك، من المحتمل أن تكون المسارات المحددة بواسطة BGP أقل أداءً من المسارات المحددة بين خوادم شبكة توصيل المحتوى (CDN).
التخزين المؤقت
يغني تخزين الموارد مؤقتًا على خوادم شبكة توصيل المحتوى في الحاجة إلى انتقال الطلب إلى المصدر المطلوب لتقديمه. ونتيجة لذلك، يتم تسليم المورد بسرعة أكبر، وهذا يقلل أيضًا من الحمل على خادم المصدر.
إضافة موارد إلى ذاكرة التخزين المؤقت
أكثر الطرق شيوعًا لتعبئة ذاكرات التخزين المؤقت لشبكة توصيل المحتوى (CDN) هي الاستعانة بموارد "سحب" شبكة توصيل المحتوى (CDN) عند الحاجة، وهو ما يُعرف باسم "سحب المصدر". في المرة الأولى التي يتم فيها طلب مورد معيّن من ذاكرة التخزين المؤقت، ستطلبه شبكة توصيل المحتوى (CDN) من خادم المصدر وتخزّن الاستجابة في ذاكرة التخزين المؤقت. وبهذه الطريقة، يتم إنشاء محتوى ذاكرة التخزين المؤقت بمرور الوقت حيث يتم طلب موارد إضافية غير مخزّنة مؤقتًا.
إزالة الموارد من ذاكرة التخزين المؤقت
تستخدم شبكات توصيل المحتوى (CDN) تفريغ ذاكرة التخزين المؤقت لإزالة الموارد غير المفيدة من ذاكرة التخزين المؤقت بشكل دوري. بالإضافة إلى ذلك، يمكن لمالكي المواقع الإلكترونية استخدام ميزة الإزالة النهائية لإزالة الموارد صراحةً.
إخلاء ذاكرة التخزين المؤقت
تتسم ذاكرات التخزين المؤقت بسعة تخزين محدودة. عندما تقترب ذاكرة التخزين المؤقت من سعتها، فإنها توفر مساحة لموارد جديدة عن طريق إزالة الموارد التي لم يتم الوصول إليها مؤخرًا أو التي تشغل مساحة كبيرة. وتُعرف هذه العملية باسم إخلاء ذاكرة التخزين المؤقت. المورد الذي يتم إخراجه من ذاكرة تخزين مؤقت واحدة لا يعني بالضرورة أنه قد تم حذفه من جميع ذاكرات التخزين المؤقت في شبكة توصيل المحتوى (CDN).
تنظيف البيانات
الإزالة النهائية (المعروفة أيضًا باسم "إيقاف ذاكرة التخزين المؤقت") هي آلية لإزالة المورد من ذاكرات التخزين المؤقت لشبكة توصيل المحتوى (CDN) بدون الحاجة إلى الانتظار حتى انتهاء صلاحيته أو إزالته. ويتم تنفيذها عادةً عبر واجهة برمجة تطبيقات. ويجب إزالة المحتوى نهائيًا في الحالات التي يجب فيها سحب المحتوى (على سبيل المثال، تصحيح الأخطاء الإملائية أو أخطاء التسعير أو المقالات الإخبارية غير الصحيحة). فضلاً عن ذلك، يمكن أن تلعب دورًا مهمًا في استراتيجية التخزين المؤقت للموقع.
إذا كانت شبكة توصيل المحتوى تتيح الإزالة الفورية تقريبًا، يمكن استخدام الإزالة النهائية كآلية لإدارة التخزين المؤقت للمحتوى الديناميكي: التخزين المؤقت للمحتوى الديناميكي باستخدام مدة بقاء طويلة، ثم إزالة المورد نهائيًا متى تم تحديثه. بهذه الطريقة، يمكن زيادة مدة التخزين المؤقت لمورد ديناميكي إلى أقصى حد، على الرغم من عدم معرفة وقت تغيير المورد مسبقًا. يُشار إلى هذه التقنية أحيانًا باسم "التخزين المؤقت حتى تكتمل العملية".
وعند استخدام ميزة الإزالة النهائية على نطاق واسع، يتم استخدامها عادةً مع مفهوم يُعرف باسم "علامات ذاكرة التخزين المؤقت" أو "مفاتيح ذاكرة التخزين المؤقت البديلة". وتتيح هذه الآلية لمالكي المواقع الإلكترونية ربط معرِّف إضافي واحد أو أكثر (يُشار إليه أحيانًا باسم "العلامات") بمورد مخزَّن مؤقتًا. ويمكن بعد ذلك استخدام هذه العلامات لإجراء إزالة نهائية عالية الدقة. على سبيل المثال، يمكنك إضافة علامة "تذييل" إلى جميع الموارد (مثل
/aboutو/blog) التي تحتوي على تذييل موقعك الإلكتروني. عند تحديث التذييل، يمكنك توجيه شبكة توصيل المحتوى لإزالة جميع الموارد المرتبطة بعلامة "التذييل" نهائيًا.
الموارد القابلة للتخزين المؤقت
تعتمد طريقة تخزين المورد مؤقتًا على ما إذا كان عامًا أو خاصًا أو ثابتًا أو ديناميكيًا.
الموارد الخاصة والعامة
المراجع الخاصة
تحتوي الموارد الخاصة على بيانات مخصصة لمستخدم واحد، وبالتالي يجب ألا يتم تخزينها مؤقتًا بواسطة شبكة توصيل المحتوى (CDN). تتم الإشارة إلى الموارد الخاصة من خلال العنوان
Cache-Control: private.المراجع العامة
لا تحتوي الموارد العامة على معلومات خاصة بالمستخدم، وبالتالي يمكن تخزينها مؤقتًا بواسطة شبكة توصيل المحتوى (CDN). قد يُعتبَر المورد قابلاً للتخزين المؤقت في شبكة توصيل المحتوى إذا لم يكن يتضمّن العنوان
Cache-Control: no-storeأوCache-Control: private. تعتمد المدة الزمنية التي يمكن خلالها تخزين مورد عام في ذاكرة التخزين المؤقت على مدى تكرار تغيير مادة العرض.
المحتوى الديناميكي والثابت
المحتوى الديناميكي
المحتوى الديناميكي هو محتوى يتغير بشكل متكرر. ومن الأمثلة على هذا النوع من المحتوى الردّ من واجهة برمجة التطبيقات والصفحة الرئيسية للمتجر. في المقابل، إنّ تغيُّر هذا المحتوى بشكل متكرر لا يمنع بالضرورة تخزينه مؤقتًا. خلال فترات الازدحام الشديد، يمكن أن يؤدي التخزين المؤقت لهذه الردود لفترات زمنية قصيرة جدًا (على سبيل المثال، 5 ثوانٍ) إلى تقليل الحمل على خادم المصدر بشكل كبير، مع تقليل التأثير إلى حد أدنى على مدى حداثة البيانات.
المحتوى الثابت
يتغيّر المحتوى الثابت بشكل غير متكرر، إذا حدث ذلك. وعادةً ما تكون الصور والفيديوهات والمكتبات ذات الإصدارات أمثلة على هذا النوع من المحتوى. وبما أنّ المحتوى الثابت لا يتغيّر، يجب أن يتم تخزينه مؤقتًا ضمن مدة البقاء (TTL) الطويلة، على سبيل المثال، 6 أشهر أو سنة واحدة.
اختيار شبكة توصيل المحتوى (CDN)
عادةً ما يكون الأداء من أهم الاعتبارات عند اختيار شبكة توصيل المحتوى. ومع ذلك، فإن الميزات الأخرى التي تقدمها شبكة توصيل المحتوى (مثل ميزات الأمان والتحليلات)، بالإضافة إلى أسعار شبكة توصيل المحتوى والدعم والإعداد كلها مهمة يجب مراعاتها عند اختيار شبكة توصيل المحتوى.
عروض أداء
على المستوى العام، يمكن التفكير في استراتيجية أداء شبكة توصيل المحتوى (CDN) من حيث المفاضلة بين تقليل وقت الاستجابة وزيادة نسبة نتائج ذاكرة التخزين المؤقت إلى أقصى حد. يمكن لشبكات توصيل المحتوى (CDN) ذات العديد من نقاط التواجد (PoPs) توفير وقت استجابة أقل، ولكن قد تواجه نسب أداء أقل لنتائج ذاكرة التخزين المؤقت نتيجةً لتقسيم الزيارات على عدد أكبر من ذاكرات التخزين المؤقت. وعلى العكس، يمكن تحديد مواقع شبكات توصيل المحتوى (CDN) التي تتضمّن عددًا أقل من نقاط الدفع (PP) جغرافيًا بعيدًا عن المستخدمين، ولكن يمكنها تحقيق نسب نتائج أعلى لذاكرة التخزين المؤقت.
نتيجةً لهذه المفاضلة، تستخدم بعض شبكات توصيل المحتوى (CDN) نهجًا متعدّد المستويات للتخزين المؤقت، إذ يتم تزويد نقاط البيع (PoP) القريبة من المستخدمين (المعروفة أيضًا باسم "ذاكرات التخزين المؤقت الهامشية") بنقاط عرض مركزية ذات نِسب أعلى لنتائج ذاكرة التخزين المؤقت. عندما يتعذَّر على ذاكرة التخزين المؤقت على الحافة العثور على مورد، سيتم البحث عن نقطة بيع مركزية للمورد. ويتبادل هذا الأسلوب وقت استجابة أكبر بقليل لزيادة احتمال عرض المورد من ذاكرة التخزين المؤقت لشبكة توصيل المحتوى (CDN)، إلا أنّه ليس بالضرورة ذاكرة التخزين المؤقت على الحافة.
تتمثل المفاضلة بين تقليل وقت الاستجابة وزيادة نسبة نتائج ذاكرة التخزين المؤقت إلى أقصى حد في المجال. ولا يوجد منهج محدد أفضل على الصعيد العالمي، ولكن استنادًا إلى طبيعة موقعك الإلكتروني وقاعدة مستخدميه، قد يتبيّن لك أنّ أحد هذين الأسلوبين يحقق أداءً أفضل بكثير من الآخر.
ومن الجدير بالذكر أيضًا أنّ أداء شبكة توصيل المحتوى قد يختلف بشكل كبير باختلاف الموقع الجغرافي والوقت من اليوم والأحداث الجارية. على الرغم من أنّه من المفيد دائمًا إجراء أبحاثك الخاصة حول أداء شبكة توصيل المحتوى (CDN)، إلا أنّه قد يكون من الصعب توقّع الأداء الدقيق الذي ستحصل عليه من شبكة توصيل المحتوى (CDN).
التأثيرات على سرعة عرض أكبر محتوى مرئي (LCP)
كما تم توضيحه من قبل في هذه المقالة، فإن الغرض الأساسي من شبكة توصيل المحتوى (CDN) هو تقليل وقت الاستجابة عن طريق توزيع الموارد على الخوادم الأقرب جغرافيًا إلى المستخدمين. ولهذا السبب، فإنّ الميزة الأساسية لشبكة توصيل المحتوى (CDN) هي تحسين أداء التحميل. وعلى وجه التحديد، يمكن إدخال تحسينات كبيرة على الوقت حتى أول بايت (TTFB) للمورد عند إدخال شبكة توصيل المحتوى (CDN) في بنية موقعك الإلكتروني من جهة الخادم.
مع أنّ مقياس TTFB ليس مقياس أداء يركّز على المستخدم، إنه مقياس مهم لتشخيص المشاكل باستخدام سرعة عرض أكبر محتوى مرئي (LCP)، وهو مقياس يركّز على المستخدم.
تتميّز شبكات توصيل المحتوى (CDN) بأنّها فعّالة بشكل خاص في تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)، لأنّها يمكنها تحسين عرض المستندات (من خلال تقليل تقنية تحويل البيانات إلى كلام (TTFB) في إعداد الاتصال وفي التخزين المؤقت للمستند) وتحسين عرض أي موارد ثابتة مطلوبة لعرض عنصر سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP).
ميزات إضافية
تقدم شبكات توصيل المحتوى (CDN) عادةً مجموعة متنوعة من الميزات بالإضافة إلى عروضها الأساسية في شبكة توصيل المحتوى (CDN). تشمل الميزات المعروضة بشكل عام ما يلي: موازنة التحميل، وتحسين الصور، وبث الفيديو، وحوسبة الحافة، ومنتجات الأمان.
كيفية إعداد شبكة توصيل محتوى وتهيئتها
من الناحية المثالية، عليك استخدام شبكة توصيل للمحتوى (CDN) لعرض موقعك الإلكتروني بأكمله. تتكون عملية إعداد هذا المستوى من الاشتراك مع مزود شبكة توصيل المحتوى (CDN)، ثم تحديث سجل DNS الخاص بك للإشارة إلى مزود شبكة توصيل المحتوى (CDN). على سبيل المثال، قد يشير سجلّ CNAME للنطاق www.example.com إلى example.my-cdn.com. نتيجةً لهذا التغيير في نظام أسماء النطاقات، سيتم توجيه حركة البيانات إلى موقعك الإلكتروني عبر شبكة توصيل المحتوى (CDN).
إذا لم يكن استخدام شبكة توصيل المحتوى (CDN) لخدمة جميع الموارد خيارًا، فيمكنك تهيئة شبكة توصيل المحتوى (CDN) لخدمة مجموعة فرعية من الموارد فقط، على سبيل المثال الموارد الثابتة فقط. يمكنك القيام بذلك عن طريق إنشاء سجل CNAME منفصل والذي سيتم استخدامه فقط للموارد التي يجب عرضها بواسطة شبكة توصيل المحتوى (CDN). على سبيل المثال، يمكنك إنشاء سجلّ CNAME الخاص بـ static.example.com يشير إلى example.my-cdn.com. ستحتاج أيضًا إلى إعادة كتابة عناوين URL للموارد التي تعرضها شبكة توصيل المحتوى للتوجيه إلى نطاق static.example.com الفرعي الذي أنشأته.
على الرغم من أنه سيتم إعداد شبكة توصيل المحتوى (CDN) في هذه المرحلة، من المحتمل أن يكون هناك أوجه قصور في الضبط. سيوضح القسمان التاليان من هذه المقالة كيفية تحقيق أقصى استفادة من شبكة توصيل المحتوى (CDN) من خلال زيادة نسبة نتائج ذاكرة التخزين المؤقت وتفعيل ميزات الأداء.
تحسين نسبة نتائج ذاكرة التخزين المؤقت
سيخدم إعداد شبكة توصيل المحتوى الفعال أكبر عدد ممكن من الموارد من ذاكرة التخزين المؤقت. ويتم قياس هذا عادةً باستخدام نسبة نتيجة ذاكرة التخزين المؤقت (CHR). تُعرف نسبة نتائج ذاكرة التخزين المؤقت بأنها عدد نتائج ذاكرة التخزين المؤقت مقسومًا على إجمالي عدد الطلبات خلال فترة زمنية معينة.
سيكون لذاكرة التخزين المؤقت التي تم إعدادها حديثًا قيمة 0 CHR، إلا أن هذا يزيد عند ملء ذاكرة التخزين المؤقت بالموارد. ويكون معدل CHR بنسبة 90% هدفًا جيدًا لمعظم المواقع. يجب أن يزودك موفر شبكة توصيل المحتوى بالتحليلات والتقارير المتعلقة بـ CHR.
عند تحسين CHR، أول شيء يجب التحقق منه هو أن جميع الموارد القابلة للتخزين المؤقت يتم تخزينها مؤقتًا وتخزينها مؤقتًا طوال المدة الزمنية الصحيحة. وهذا تقييم بسيط يجب أن تُجريه جميع المواقع الإلكترونية.
المستوى التالي من تحسين CHR، بشكل عام، هو ضبط إعدادات شبكة توصيل المحتوى (CDN) للتأكد من عدم تخزين استجابات الخادم المكافئة منطقيًا بشكل منفصل بشكل منفصل. وهو أمر يشيع عدم الكفاءة يحدث بسبب تأثير عوامل مثل مَعلمات طلب البحث وملفات تعريف الارتباط وعناوين الطلبات في التخزين المؤقت.
التدقيق الأولي
ستوفر معظم شبكات توصيل المحتوى (CDN) تحليلات ذاكرة التخزين المؤقت. بالإضافة إلى ذلك، يمكن أيضًا استخدام أدوات مثل WebPageTest وLighthouse للتحقّق بسرعة من أنه يتم تخزين جميع الموارد الثابتة في الصفحة مؤقتًا طوال المدة الزمنية الصحيحة. ويمكن تحقيق ذلك من خلال التحقق من عناوين ذاكرة التخزين المؤقت لـ HTTP لكل مورد. سيؤدي تخزين مورد مؤقتًا باستخدام الحد الأقصى المناسب لمدة البقاء (TTL) إلى تجنب عمليات استرجاع المصادر غير الضرورية في المستقبل، وبالتالي زيادة معدّل CHR.
يجب على الأقل ضبط أحد هذه العناوين عادةً حتى يتم تخزين المورد مؤقتًا بواسطة شبكة توصيل المحتوى (CDN):
Cache-Control: max-age=Cache-Control: s-maxage=Expires
بالإضافة إلى ذلك، ورغم عدم تأثير ذلك في ما إذا كان يتم تخزين مورد مؤقتًا بواسطة شبكة توصيل المحتوى (CDN) أو كيفية ذلك، فمن الممارسات الجيدة أيضًا ضبط التوجيه Cache-Control: immutable.Cache-Control: immutable يشير إلى أن المورد "لن يتم تحديثه خلال فترة حداثة". ونتيجة لذلك، لن يعيد المتصفح التحقق من المورد عند عرضه من ذاكرة التخزين المؤقت في المتصفح، وبالتالي يؤدي ذلك إلى إزالة طلب غير ضروري من الخادم. للأسف، هذا التوجيه متوافق فقط مع Firefox وSafari، إذ إنّه غير متوافق مع المتصفحات المستندة إلى Chromium. تؤدّي هذه المشكلة إلى تتبُّع توافق Chromium مع Cache-Control: immutable. ويمكن أن يساعد تمييز هذه المشكلة في تشجيع المستخدمين على استخدام هذه الميزة.
للحصول على شرح أكثر تفصيلاً عن التخزين المؤقت لـ HTTP، يمكنك الاطّلاع على منع الطلبات غير الضرورية للشبكة باستخدام ذاكرة التخزين المؤقت لـ HTTP.
ضبط دقيق لتحسين الأداء
هناك شرح مبسط إلى حدٍ ما حول طريقة عمل ذاكرات التخزين المؤقت لشبكة توصيل المحتوى (CDN) وهو استخدام عنوان URL للمورد كمفتاح للتخزين المؤقت واسترداد المورد من ذاكرة التخزين المؤقت. من الناحية العملية، لا يزال هذا صحيحًا بشكل كبير، ولكنه معقّد بعض الشيء بسبب تأثير أشياء مثل عناوين الطلبات ومَعلمات طلبات البحث. نتيجةً لذلك، تُعدّ إعادة كتابة عناوين URL الخاصة بالطلب أسلوبًا مهمًا لزيادة معدّل CHR إلى أقصى حد وضمان عرض المحتوى الصحيح للمستخدمين. يحقق مثيل شبكة توصيل المحتوى (CDN) الذي تم إعداده بشكل صحيح التوازن الصحيح بين التخزين المؤقت الدقيق بشكل مفرط (ما يؤثر سلبًا في CHR) والتخزين المؤقت الدقيق بشكل غير كافٍ (ما يؤدي إلى عرض ردود غير صحيحة للمستخدمين).
معلمات طلب البحث
بشكل تلقائي، تراعي شبكات توصيل المحتوى مَعلمات طلب البحث عند تخزين مورد مؤقتًا. ومع ذلك، يمكن أن يكون للتعديلات الصغيرة التي يتم إجراؤها على التعامل مع مَعلمات طلب البحث تأثير كبير في معدّل CHR. مثلاً:
مَعلمات طلب البحث غير الضرورية
بشكل تلقائي، ستحتفظ شبكة توصيل المحتوى بـ
example.com/blogوexample.com/blog?referral_id=2zjkفي ذاكرة التخزين المؤقت بشكل منفصل على الرغم من أنّهما على الأرجح المورد الأساسي نفسه. يتم إصلاح هذا من خلال ضبط إعدادات شبكة توصيل المحتوى (CDN) لتجاهل معلَمة طلب البحثreferral\_id.ترتيب مَعلمات طلب البحث
ستخزِّن شبكة توصيل المحتوى
example.com/blog?id=123&query=dogsفي ذاكرة التخزين المؤقت بشكل منفصل عنexample.com/blog?query=dogs&id=123. بالنسبة إلى معظم المواقع الإلكترونية، لا يُعدّ ترتيب مَعلمات طلب البحث مهمًا، لذا فإنّ ضبط شبكة توصيل المحتوى لترتيب مَعلمات طلب البحث (وبالتالي تسوية عنوان URL المستخدَم لتخزين استجابة الخادم مؤقتًا) سيؤدي إلى زيادة معدّل CHR.
تنويع
يُعلم عنوان الاستجابة Vary ذاكرات التخزين المؤقت أن استجابة الخادم المقابلة لعنوان URL معين يمكن أن تختلف بناءً على العناوين المحددة في الطلب (مثل عناوين الطلب accept-Language أو accept-Encoding). ونتيجةً لذلك، يتم توجيه شبكة توصيل المحتوى (CDN) لتخزين هذه الاستجابات مؤقتًا بشكل منفصل. لا تتوافق رأس Vary مع شبكات توصيل المحتوى (CDN) على نطاق واسع، وقد يؤدي هذا إلى عدم عرض مورد قابل للتخزين المؤقت من ذاكرة التخزين المؤقت.
وبالرغم من أن الرأس Vary يمكن أن يكون أداة مفيدة، إلا أن الاستخدام غير الملائم يضر CHR. بالإضافة إلى ذلك، في حال استخدام Vary، ستساعد تسوية عناوين الطلبات في تحسين معدّل CHR. على سبيل المثال، في حال عدم تسوية عنوانَي الطلب Accept-Language: en-US وAccept-Language: en-US,en;q=0.9، سيؤدي ذلك إلى إدخالَين منفصلَين لذاكرة التخزين المؤقت، على الرغم من أنّ محتواهما من المحتمل أن يكونا متطابقَين.
بسكويت
يتم ضبط ملفات تعريف الارتباط على الطلبات من خلال العنوان Cookie، ويتم ضبطها على الاستجابات من خلال العنوان Set-Cookie. ويجب تجنُّب الاستخدام غير الضروري لعنوان Set-Cookie لأنّ ذاكرات التخزين المؤقت لن تخزّن عادةً استجابات الخادم التي تحتوي على هذا العنوان مؤقتًا.
ميزات الأداء
يناقش هذا القسم ميزات الأداء التي تقدمها شبكات توصيل المحتوى عادةً كجزء من عرض المنتج الأساسي. تنسى العديد من المواقع الإلكترونية تفعيل هذه الميزات، وبالتالي تفقد مكاسب الأداء السهلة.
الضغط
يجب ضغط جميع الردود المستندة إلى النص باستخدام gzip أو Brotli. إذا كان لديك الخيار، فاختر Brotli بدلاً من gzip. Brotli هي خوارزمية ضغط أحدث، ويمكنها تحقيق نسب ضغط أعلى مقارنةً بـ gzip.
يتوفر نوعان من شبكات توصيل المحتوى (CDN) لضغط Brotli فيهما: "Brotli من المصدر" و "ضغط Brotli تلقائيًا".
صورة "بروتلي" من المصدر
لغة Brotli من الأصل هي عندما تعرض شبكة توصيل المحتوى موارد تم ضغطها من خلال Brotli حسب الأصل. على الرغم من أن هذه قد تبدو ميزة يجب أن تكون جميع شبكات توصيل المحتوى (CDN) قادرة على دعمها بشكل فوري، إلا أنها تتطلب أن تكون شبكة توصيل المحتوى قادرة على التخزين المؤقت لإصدارات متعددة (بعبارة أخرى، إصدارات مضغوطة بتنسيق gzip وBortli) من المورد المقابل لعنوان URL معيّن.
ضغط Brotli تلقائيًا
يتم الضغط التلقائي لـ Brotli عندما يتم ضغط الموارد من خلال Brotli بواسطة شبكة توصيل المحتوى (CDN). يمكن شبكات توصيل المحتوى (CDN) ضغط كل من الموارد القابلة للتخزين المؤقت والموارد غير القابلة للتخزين المؤقت.
عند طلب مورد للمرة الأولى، يتم عرضه باستخدام الضغط "جيد بما يكفي"، على سبيل المثال، Brotli-5. ينطبق هذا النوع من الضغط على كل من الموارد القابلة للتخزين المؤقت وغير القابلة للتخزين المؤقت.
وفي الوقت نفسه، إذا كان المورد قابلاً للتخزين المؤقت، ستستخدم شبكة توصيل المحتوى المعالجة بلا اتصال بالإنترنت لضغط المورد بمستوى ضغط أكثر قوة ولكن أبطأ بكثير - على سبيل المثال، Brotli-11. بعد اكتمال هذا الضغط، سيتم تخزين النسخة المضغوطة أكثر مؤقتًا واستخدامها للطلبات اللاحقة.
أفضل ممارسات الضغط
على المواقع الإلكترونية التي تريد تحقيق أفضل أداء أن تطبّق ضغط Brotli على كل من خادم المصدر وشبكة توصيل المحتوى (CDN). يقلل ضغط Brotli عند الأصل من حجم نقل الموارد التي لا يمكن عرضها من ذاكرة التخزين المؤقت. لمنع التأخير في عرض الطلبات، يجب أن يضغط المصدر الموارد الديناميكية باستخدام مستوى ضغط معتدل إلى حدّ ما، مثل Brotli-4، ويمكن ضغط الموارد الثابتة باستخدام Brotli-11. إذا كان المصدر لا يتوافق مع Brotli، يمكن استخدام gzip-6 لضغط الموارد الديناميكية، ويمكن استخدام gzip-9 لضغط الموارد الثابتة.
الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS)
الإصدار 1.3 من بروتوكول أمان طبقة النقل هو أحدث إصدار من بروتوكول أمان طبقة النقل (TLS)، وهو بروتوكول التشفير الذي يستخدمه HTTPS. يوفّر الإصدار 1.3 من طبقة النقل الآمنة خصوصية وأداء أفضل مقارنةً بالإصدار 1.2 من بروتوكول أمان طبقة النقل.
يعمل الإصدار 1.3 من بروتوكول أمان طبقة النقل على اختصار تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) من جولتَي ذهاب وعودة إلى جولة واحدة. بالنسبة إلى الاتصالات التي تستخدم HTTP/1 أو HTTP/2، فإن اختصار تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) إلى جولة ذهاب وعودة يقلل بشكل فعّال من وقت إعداد الاتصال بنسبة 33%.
HTTP/2 وHTTP/3
يوفّر كل من HTTP/2 وHTTP/3 مزايا في الأداء مقارنةً بـ HTTP/1. ويوفّر HTTP/3 من بين الاثنين مزايا أداء محتملة أكبر. لم يتم توحيد HTTP/3 بالكامل بعد، ولكنه سيصبح متوافقًا على نطاق واسع بعد حدوث ذلك.
HTTP/2
إذا لم يسبق لك تفعيل HTTP/2 تلقائيًا في شبكة توصيل المحتوى (CDN)، ننصحك بتفعيله. ويوفر HTTP/2 العديد من مزايا الأداء على HTTP/1 ويتوافق مع جميع المتصفحات الرئيسية. تتضمّن ميزات الأداء في HTTP/2 ما يلي: تعدد الإرسال وتحديد أولويات البث وضغط العناوين.
مضاعفة الإرسال
يمكن القول إن مضاعفة الإرسال هو أهم ميزة في HTTP/2. يتيح تعدد الإرسال اتصال TCP واحد لخدمة أزواج طلب واستجابة متعددة في نفس الوقت. وهذا يلغي عبء عمليات إعداد الاتصالات غير الضرورية، ونظرًا لأنّ عدد الاتصالات التي يمكن أن يفتحها المتصفّح في وقت معيّن محدود، قد ينتج أيضًا عن قدرة المتصفّح الآن على طلب المزيد من موارد الصفحة بالتوازي. من الناحية النظرية، يؤدي مضاعفة الإرسال إلى التقليل من الحاجة إلى تحسينات HTTP/1، مثل الترابط وأوراق الرموز المتحركة. أمّا من الناحية العملية، فستظل هذه الأساليب ذات صلة لأنّ الملفات الأكبر حجمًا يتم ضغطها بشكل أفضل.
تحديد أولويات البث
تتيح ميزة مضاعفة الإرسال إجراء عدة أحداث بث متزامنة، أما تحديد أولوية البث، فيوفّر واجهة لعرض الأولوية النسبية لكل مصدر من هذه المصادر. ويساعد هذا الخادم في إرسال الموارد الأكثر أهمية أولاً - حتى إذا لم يتم طلبها أولاً.
يعبّر المتصفّح عن أولوية ساحة المشاركات من خلال شجرة اعتمادية، وهي مجرد بيان التفضيل: أي أن الخادم غير مُلزَم بتلبية (أو حتى مراعاة) الأولويات التي يوفّرها المتصفّح. تصبح أولوية مجموعات البث أكثر فعالية عند عرض المزيد من محتوى الموقع الإلكتروني من خلال شبكة توصيل المحتوى.
تختلف عمليات تنفيذ شبكة توصيل المحتوى (CDN) لتحديد أولوية موارد HTTP/2 بشكل كبير. لتحديد ما إذا كانت شبكة توصيل المحتوى تتيح تحديد أولويات موارد HTTP/2 بشكل كامل وصحيح، راجِع المقالة هل HTTP/2 سريع حتى الآن؟.
على الرغم من أنّ تبديل مثيل شبكة توصيل المحتوى (CDN) إلى HTTP/2 يعتمد إلى حدّ كبير على قلب مفتاح تحكّم، من المهم اختبار هذا التغيير بدقّة قبل تفعيله في مرحلة الإنتاج. يستخدم HTTP/1 وHTTP/2 الاصطلاحات نفسها لرؤوس الطلبات والاستجابة - ولكن HTTP/2 يكون أقل تساهلًا بكثير عندما لا يتم الالتزام بهذه الاصطلاحات. ونتيجةً لذلك، قد تبدأ الممارسات غير المتعلّقة بالمواصفات، مثل تضمين أحرف غير ASCII أو الأحرف الكبيرة في العناوين، في حدوث أخطاء بعد تفعيل HTTP/2. إذا حدث هذا، فستفشل محاولات المتصفح لتنزيل المورد. ستظهر محاولة التنزيل التي تعذّر تنزيلها في علامة التبويب "الشبكة" في "أدوات مطوّري البرامج". بالإضافة إلى ذلك، سيتم عرض رسالة الخطأ "ERR_HTTP2_PROTOCOL_ERROR" في وحدة التحكّم.
HTTP/3
HTTP/3 هو الجزء اللاحق من HTTP/2. اعتبارًا من أيلول (سبتمبر) 2020، أصبحت جميع المتصفّحات الرئيسية متوافقة مع HTTP/3، وتتيح بعض شبكات توصيل المحتوى (CDN) استخدام هذه الطريقة. الأداء هو الفائدة الأساسية لبروتوكول HTTP/3 عن HTTP/2. وعلى وجه التحديد، يلغي HTTP/3 حظر العنوان على مستوى الاتصال ويقلل من وقت إعداد الاتصال.
إلغاء الحظر العنواني
قدّم HTTP/2 ميزة تعدد الإرسال، وهي ميزة تتيح استخدام اتصال واحد لنقل مجموعات متعددة من البيانات في وقت واحد. ومع ذلك، باستخدام HTTP/2، تحظر حزمة واحدة تم إسقاطها جميع عمليات البث على الاتصال (وهي ظاهرة تُعرف بحظر رأس الخط). في حال استخدام HTTP/3، لا تحظر الحزمة التي تم إفلاتها إلا بثًا واحدًا فقط. يرجع هذا التحسين إلى حد كبير إلى استخدام HTTP/3 باستخدام UDP (يستخدم HTTP/3 بروتوكول UDP عبر QUIC) بدلاً من استخدام TCP. وهذا يجعل HTTP/3 مفيدًا على وجه الخصوص لنقل البيانات عبر الشبكات المكتظة أو ذات فقدان البيانات.
تقليل وقت إعداد الاتصال
يستخدم HTTP/3 بروتوكول أمان طبقة النقل (TLS) الإصدار 1.3 وبالتالي يشارك مزايا أدائه: لا يتطلب إنشاء اتصال جديد سوى رحلة ذهاب وعودة واحدة واستئناف الاتصال الحالي لا يتطلب أي رحلات ذهاب وعودة.
سيكون لاستخدام HTTP/3 التأثير الأكبر في مستخدمي الاتصالات الضعيفة بالشبكة: ليس فقط لأن HTTP/3 يتعامل مع فقدان الحزم بشكل أفضل من سابقاته، ولكن أيضًا بسبب توفير الوقت المطلق الناتج عن إعداد اتصال 0-RTT أو 1-RTT سيكون أكبر على الشبكات ذات وقت الاستجابة الطويل.
تحسين الصور
تركّز خدمات تحسين الصور في شبكة توصيل المحتوى (CDN) عادةً على عمليات تحسين الصور التي يمكن تطبيقها تلقائيًا لتقليل حجم نقل الصور. على سبيل المثال، إزالة بيانات EXIF وتطبيق الضغط بدون فقدان البيانات وتحويل الصور إلى تنسيقات ملفات أحدث (مثل WebP). تشكّل الصور حوالي 50% من وحدات بايت النقل في صفحة الويب المتوسطة، لذا يمكن أن يؤدي تحسين الصور إلى تقليل حجم الصفحة بشكل كبير.
تصغير
يؤدي التصغير إلى إزالة الأحرف غير الضرورية من JavaScript وCSS وHTML. من الأفضل إجراء تصغير في خادم المصدر بدلاً من شبكة توصيل المحتوى. يمتلك مالكو المواقع الإلكترونية سياقًا أكبر حول الرمز الذي سيتم تصغيره، وبالتالي يمكنهم غالبًا استخدام أساليب تصغير أكثر صرامة من تلك التي تستخدمها شبكات توصيل المحتوى (CDN). ومع ذلك، إذا لم يكن تصغير الرمز في الأصل خيارًا، يكون التقليل من خلال شبكة توصيل المحتوى (CDN) بديلاً جيدًا.
الخلاصة
- استخدام شبكة توصيل محتوى (CDN): توفّر شبكات توصيل المحتوى (CDN) الموارد بسرعة وتقلل من الحمل على خادم المصدر ومفيدة للتعامل مع الارتفاعات المفاجئة في حركة الزيارات.
- تخزين المحتوى في ذاكرة التخزين المؤقت بأكبر قدر ممكن من القوة: يجب تخزين المحتوى الثابت والديناميكي في ذاكرة التخزين المؤقت، حتى لو كان ذلك لفترات مختلفة. افحص موقعك بشكل دوري للتأكد من أنك تخزّن المحتوى بشكل مثالي.
- تفعيل ميزات أداء شبكة توصيل المحتوى (CDN): تعمل ميزات مثل Brotli وTLS 1.3 وHTTP/2 وHTTP/3 على تحسين الأداء بشكلٍ أكبر.