فهم الرأس المتنوع

يتم إرسال رأس Vary HTTP بمليارات من استجابات HTTP كل يوم. لكن استخدامه لم يحقق رؤيته الأصلية أبدًا ، والعديد من المطورين يسيئون فهم ما يفعله أو لا يدركون حتى أن خادم الويب الخاص بهم يرسله. مع قدوم تلميحات العميل والمتغيرات والمواصفات الرئيسية ، بدأت الاستجابات المتنوعة بداية جديدة.

ما هو Vary؟

تبدأ قصة Vary بفكرة جميلة عن كيفية عمل الويب. من حيث المبدأ ، لا يمثل عنوان URL صفحة ويب ، ولكنه يمثل مصدرًا مفاهيميًا ، مثل كشف حسابك المصرفي. تخيل أنك تريد أن ترى كشف حسابك المصرفي: اذهب إلى bank.com وأرسل طلب GET لـ /statement . جيد حتى الآن ، لكنك لم تقل التنسيق الذي تريد البيان به. ولهذا السبب سيشمل متصفحك أيضًا شيئًا مثل Accept: text/html في طلبك. من الناحية النظرية ، هذا يعني أنه يمكنك قول Accept: text/csv بدلاً من ذلك والحصول على نفس المورد بتنسيق مختلف.

نظرًا لأن عنوان URL نفسه ينتج الآن استجابات مختلفة بناءً على قيمة رأس Accept ، فإن أي ذاكرة تخزين مؤقت تخزن هذه الاستجابة تحتاج إلى معرفة أن هذا العنوان مهم. يخبرنا الخادم أن رأس Accept مهم مثل هذا:

 Vary: Accept

يمكنك قراءة هذا على النحو التالي ، "تختلف هذه الاستجابة بناءً على قيمة Accept طلبك."

هذا في الأساس لا يعمل على شبكة الإنترنت اليوم. كان ما يسمى بـ "التفاوض على المحتوى" فكرة رائعة ، لكنها فشلت. هذا لا يعني أن Vary عديم الفائدة. يحتوي جزء لائق من الصفحات التي تزورها على الويب على رأس Vary في الاستجابة - ربما تحتوي مواقع الويب الخاصة بك عليها أيضًا ، وأنت لا تعرف ذلك. لذا ، إذا كان العنوان لا يعمل للتفاوض بشأن المحتوى ، فلماذا لا يزال يتمتع بشعبية كبيرة ، وكيف تتعامل المتصفحات معه؟ لنلقي نظرة.

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

حالات استخدام اليوم تختلف في المتصفح

كما رأينا سابقًا ، يتمثل الاستخدام التقليدي لـ Vary في إجراء تفاوض بشأن المحتوى باستخدام رؤوس Accept ، و Accept-Language ، و Accept-Encoding ، وتاريخياً ، فشل أول اثنان منهما فشلاً ذريعًا. تختلف في Accept-Encoding لتقديم استجابات مضغوطة Gzip أو Brotli ، حيث يتم دعمها ، تعمل في الغالب بشكل جيد بشكل معقول ، ولكن جميع المتصفحات تدعم Gzip هذه الأيام ، لذلك هذا ليس مثيرًا للغاية.

ماذا عن بعض هذه السيناريوهات؟

• نريد عرض الصور التي هي بالعرض الدقيق لشاشة المستخدم. إذا قام المستخدم بتغيير حجم متصفحه ، فسنقوم بتنزيل صور جديدة (تختلف حسب تلميحات العميل).
• إذا قام المستخدم بتسجيل الخروج ، فنحن نريد تجنب استخدام أي صفحات تم تخزينها مؤقتًا أثناء تسجيل الدخول (باستخدام ملف تعريف الارتباط Key ).
• يجب أن يحصل مستخدمو المستعرضات التي تدعم تنسيق صورة WebP على صور WebP ؛ وإلا ، يجب أن يحصلوا على ملفات JPEG.
• عند استخدام متصفح على شاشة عالية الكثافة ، يجب أن يحصل المستخدم على صور 2x. إذا قاموا بنقل نافذة المتصفح إلى شاشة ذات كثافة قياسية وقاموا بالتحديث ، فيجب أن يحصلوا على صور 1x.

مخبأ على طول الطريق

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

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

• صورة مخبأ
  هذه ذاكرة تخزين مؤقت على نطاق الصفحة تخزن بيانات الصورة التي تم فك ترميزها ، بحيث ، على سبيل المثال ، إذا قمت بتضمين نفس الصورة على صفحة عدة مرات ، فإن المستعرض يحتاج فقط إلى تنزيلها وفك تشفيرها مرة واحدة.
• تحميل ذاكرة التخزين المؤقت
  يتم أيضًا تحديد نطاق الصفحة ويخزن أي شيء تم تحميله مسبقًا في عنوان Link أو علامة <link rel="preload"> ، حتى إذا كان المورد غير قابل للتخزين عادةً. مثل ذاكرة التخزين المؤقت للصورة ، يتم إتلاف ذاكرة التخزين المؤقت للتحميل المسبق عندما ينتقل المستخدم بعيدًا عن الصفحة.
• عامل خدمة التخزين المؤقت API
  يوفر هذا ذاكرة تخزين مؤقت النهاية بواجهة قابلة للبرمجة ؛ لذلك ، لا يتم تخزين أي شيء هنا ما لم تضعه هناك على وجه التحديد عبر كود JavaScript في عامل الخدمة. سيتم أيضًا فحصه فقط إذا قمت بذلك صراحة في معالج fetch عامل الخدمة. تكون ذاكرة التخزين المؤقت لعامل الخدمة محددة النطاق ، وعلى الرغم من عدم ضمان استمرارها ، إلا أنها أكثر ثباتًا من ذاكرة التخزين المؤقت HTTP الخاصة بالمستعرض.
• مخبأ HTTP
  هذه هي ذاكرة التخزين المؤقت الرئيسية التي يعرفها الناس كثيرًا. إنها ذاكرة التخزين المؤقت الوحيدة التي تلفت الانتباه إلى رؤوس ذاكرة التخزين المؤقت على مستوى HTTP مثل Cache-Control ، وهي تجمع هذه مع القواعد الاستكشافية الخاصة بالمتصفح لتحديد ما إذا كان سيتم تخزين شيء ما مؤقتًا وإلى متى. لديها أوسع نطاق ، يتم مشاركتها من قبل جميع مواقع الويب ؛ لذلك ، إذا قام موقعان غير مرتبطين بتحميل نفس الأصل (على سبيل المثال ، Google Analytics) ، فقد يشتركان في نفس نتيجة ذاكرة التخزين المؤقت.
• ذاكرة التخزين المؤقت للدفع HTTP / 2 (أو "H2 push cache")
  هذا يجلس مع الاتصال ، ويقوم بتخزين الكائنات التي تم دفعها من الخادم ولكن لم يتم طلبها بعد من قبل أي صفحة تستخدم الاتصال. يتم تحديد نطاقه للصفحات باستخدام اتصال معين ، والذي هو في الأساس نفس النطاق إلى أصل واحد ، ولكن يتم إتلافه أيضًا عند إغلاق الاتصال.

من بين هؤلاء ، يتم تحديد ذاكرة التخزين المؤقت لـ HTTP وذاكرة التخزين المؤقت لعامل الخدمة بشكل أفضل. بالنسبة للصور وذاكرة التخزين المؤقت للتحميل المسبق ، قد تقوم بعض المتصفحات بتنفيذها على أنها "ذاكرة تخزين مؤقت" واحدة مرتبطة بتصيير تنقل معين ، لكن النموذج الذهني الذي أصفه هنا لا يزال هو الطريقة الصحيحة للتفكير في العملية. راجع ملاحظة المواصفات عند preload إذا كنت مهتمًا. في حالة دفع خادم H2 ، تظل المناقشة حول مصير ذاكرة التخزين المؤقت نشطة.

يعد الترتيب الذي يتحقق به الطلب من هذه ذاكرات التخزين المؤقت قبل الدخول إلى الشبكة أمرًا مهمًا ، لأن طلب شيء ما قد يسحبه من طبقة خارجية للتخزين المؤقت إلى طبقة داخلية. على سبيل المثال ، إذا دفع خادم HTTP / 2 ورقة أنماط إلى جانب الصفحة التي تحتاجها ، وكانت هذه الصفحة تُحمِّل أيضًا ورقة الأنماط مسبقًا بعلامة <link rel="preload"> ، فستنتهي ورقة الأنماط بلمس ثلاثة ذاكرة التخزين المؤقت في المتصفح. أولاً ، سيتم وضعها في ذاكرة التخزين المؤقت للدفع H2 ، في انتظار طلبها. عندما يعرض المتصفح الصفحة ويصل إلى علامة preload ، فإنه يسحب ورقة الأنماط من ذاكرة التخزين المؤقت للدفع ، من خلال ذاكرة التخزين المؤقت لـ HTTP (التي قد تخزنها ، اعتمادًا على رأس Cache-Control الخاصة بورقة الأنماط) ، وسيحفظ في ذاكرة التخزين المؤقت للتحميل المسبق.

إدخال Vary كأداة مصادقة

حسنًا ، ما الذي يحدث عندما نأخذ هذا الموقف ونضيف Vary إلى المزيج؟

على عكس ذاكرات التخزين المؤقت الوسيطة (مثل شبكات CDN) ، لا تنفذ المتصفحات عادةً القدرة على تخزين أشكال متعددة لكل عنوان URL . الأساس المنطقي لذلك هو أن الأشياء التي نستخدمها عادةً Vary (بشكل أساسي Accept-Encoding Accept-Language ) لا تتغير بشكل متكرر في سياق مستخدم واحد. قد يتغير Accept-Encoding (ولكن من المحتمل ألا يتغير) عند ترقية المتصفح ، ومن المرجح ألا تتغير Accept-Language إلا إذا قمت بتحرير إعدادات لغة نظام التشغيل. كما أنه من الأسهل جدًا تنفيذ Vary بهذه الطريقة ، على الرغم من أن بعض مؤلفي المواصفات يعتقدون أن هذا كان خطأ.

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

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

إظهار سلوك متنوع

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

دعنا نلقي نظرة على كل نوع من أنواع ذاكرة التخزين المؤقت وكيف يجب أن يعمل Vary وما إذا كان يعمل بالفعل على هذا النحو. لكل اختبار ، أعرض هنا ما إذا كان يجب أن نتوقع رؤية نتيجة من ذاكرة التخزين المؤقت ("HIT" مقابل "MISS") وما حدث بالفعل.

التحميل المسبق

لا يتم دعم التحميل المسبق حاليًا إلا في Chrome ، حيث يتم تخزين الاستجابات المحملة مسبقًا في ذاكرة تخزين مؤقت حتى تحتاجها الصفحة. تملأ الاستجابات أيضًا ذاكرة التخزين المؤقت HTTP في طريقها إلى ذاكرة التخزين المؤقت للتحميل المسبق ، إذا كانت قابلة للتخزين المؤقت لـ HTTP. نظرًا لأن تحديد رؤوس الطلب مع التحميل المسبق أمر مستحيل ، وتستمر ذاكرة التخزين المؤقت للتحميل المسبق فقط طالما كانت الصفحة ، فإن اختبار ذلك صعب ، ولكن يمكننا على الأقل رؤية أن الكائنات التي تحتوي على رأس Vary يتم تحميلها مسبقًا بنجاح:

واجهة برمجة تطبيقات ذاكرة التخزين المؤقت لعامل الخدمة

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

ذاكرة التخزين المؤقت HTTP

يجب أن تلاحظ ذاكرة التخزين المؤقت لـ HTTP الرئيسية Vary وتقوم بذلك باستمرار (كمدقق) في جميع المتصفحات. لمزيد من المعلومات حول هذا الموضوع ، راجع منشور مارك نوتنغهام "حالة التخزين المؤقت للمتصفح ، تمت إعادة النظر فيه."

HTTP / 2 Push Cache

يجب مراعاة الاختلاف ، ولكن من الناحية العملية لا يوجد متصفح يحترمه فعليًا ، وستقوم المتصفحات بمطابقة واستهلاك الردود المدفوعة مع الطلبات التي تحمل قيمًا عشوائية في الرؤوس التي Vary الردود عليها.

التجعد "304 (غير معدل)"

حالة استجابة HTTP "304 (غير معدل)" رائعة. أشار "قائدنا العزيز" ، أرتور بيرجمان ، إلي هذه الأحجار الكريمة في مواصفات التخزين المؤقت لـ HTTP (التركيز لي):

يجب أن ينشئ الخادم الذي ينشئ استجابة 304 أيًا من حقول الرأس التالية التي كان من الممكن إرسالها في استجابة 200 (موافق) لنفس الطلب: Cache-Control و Content-Location و Date و ETag و Expires و Vary .

لماذا يُرجع الرد 304 رأس Vary ؟ تتكاثف الحبكة عندما تقرأ عما يفترض أن تفعله عند تلقي استجابة 304 تحتوي على تلك الرؤوس:

إذا تم تحديد استجابة مخزنة للتحديث ، يجب أن تستخدم ذاكرة التخزين المؤقت \ [...] حقول رأس أخرى متوفرة في الاستجابة 304 (غير المعدلة) لاستبدال جميع مثيلات حقول الرأس المقابلة في الاستجابة المخزنة.

انتظر ماذا؟ لذا ، إذا كان رأس Vary الخاص بـ 304 مختلفًا عن ذلك الموجود في الكائن المخزن مؤقتًا الحالي ، فمن المفترض أن نقوم بتحديث الكائن المخزن مؤقتًا؟ ولكن هذا قد يعني أنه لم يعد يطابق الطلب الذي قدمناه!

في هذا السيناريو ، للوهلة الأولى ، يبدو أن 304 في وقت واحد أنه يمكنك ولا يمكنك استخدام النسخة المخبأة. بالطبع ، إذا كان الخادم لا يريدك حقًا أن تستخدم النسخة المخبأة ، لكان قد أرسل 200 وليس 304 ؛ لذلك ، يجب بالتأكيد استخدام النسخة المخبأة - ولكن بعد تطبيق التحديثات عليها ، قد لا يتم استخدامها مرة أخرى لطلب مستقبلي مماثل للطلب الذي قام بالفعل بملء ذاكرة التخزين المؤقت في المقام الأول.

(ملاحظة جانبية: في Fastly ، لا نحترم هذا الاختلاف في المواصفات. لذلك ، إذا تلقينا 304 من خادمك الأصلي ، فسنستمر في استخدام الكائن المخزن مؤقتًا بدون تعديل ، بخلاف إعادة تعيين TTL.)

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

تلميحات العميل

تعد ميزة تلميحات العميل من Google أحد أهم الأشياء الجديدة التي ستحدث لـ Vary في المتصفح لفترة طويلة. على عكس Accept-Encoding Accept-Language ، تصف تلميحات العميل القيم التي قد تتغير بانتظام أثناء تنقل المستخدم في موقعك على الويب ، وتحديداً ما يلي:

• DPR
  نسبة بكسل الجهاز ، كثافة البكسل للشاشة (قد تختلف إذا كان لدى المستخدم شاشات متعددة)
• Save-Data
  ما إذا كان المستخدم قد قام بتمكين وضع توفير البيانات
• Viewport-Width
  عرض البكسل لإطار العرض الحالي
• Width
  عرض المورد المطلوب بوحدات البكسل الفعلية

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

اقتراح العنوان الرئيسي

تلميحات العميل والرؤوس الأخرى شديدة الدقة تلائم الاقتراح الذي كان مارك يعمل عليه ، المسمى Key. لنلقِ نظرة على بعض الأمثلة:

 Key: Viewport-Width;div=50

يشير هذا إلى أن الاستجابة تختلف بناءً على قيمة رأس طلب Viewport-Width ، ولكن يتم تقريبها إلى أقرب مضاعف 50 بكسل!

 Key: cookie;param=sessionAuth;param=flags

تعني إضافة هذا العنوان في استجابة أننا نختلف في نوعين من ملفات تعريف الارتباط المحددة: sessionAuth و flags . إذا لم يتم تغييرها ، فيمكننا إعادة استخدام هذه الاستجابة لطلب مستقبلي.

إذن ، الاختلافات الرئيسية بين Key و Vary هي:

• يسمح Key بالتنوع في الحقول الفرعية داخل الرؤوس ، مما يجعل من الممكن فجأة التباين في ملفات تعريف الارتباط ، لأنه يمكنك التباين في ملف تعريف ارتباط واحد فقط - سيكون هذا ضخمًا ؛
• يمكن تجميع القيم الفردية في نطاقات ، لزيادة فرصة حدوث نتيجة ذاكرة التخزين المؤقت ، وهي مفيدة بشكل خاص للتنويع في أشياء مثل عرض منفذ العرض.
• يجب أن تحتوي جميع الأشكال التي لها نفس عنوان URL على نفس المفتاح. لذلك ، إذا تلقت ذاكرة التخزين المؤقت استجابة جديدة لعنوان URL يحتوي بالفعل على بعض المتغيرات الحالية ، وكانت قيمة رأس Key الاستجابة الجديدة لا تتطابق مع القيم الموجودة في تلك المتغيرات الحالية ، فيجب إخلاء جميع المتغيرات من ذاكرة التخزين المؤقت.

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

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

اقتراح المتغيرات

Key هو آلية عامة لطيفة ، ولكن بعض العناوين لديها قواعد أكثر تعقيدًا لقيمها ، ويمكن أن يساعدنا فهم دلالات هذه القيم في إيجاد طرق آلية لتقليل تنوع ذاكرة التخزين المؤقت. على سبيل المثال ، تخيل أن هناك طلبين يأتيان بقيم مختلفة Accept-Language ، وهما en-gb و en-us ، ولكن على الرغم من أن موقعك على الويب يدعم تنوع اللغة ، إلا أن لديك "الإنجليزية" واحدة فقط. إذا أجبنا على طلب اللغة الإنجليزية الأمريكية وتم تخزين هذا الرد مؤقتًا على CDN ، فلا يمكن إعادة استخدامه لطلب اللغة الإنجليزية في المملكة المتحدة ، لأن قيمة Accept-Language ستكون مختلفة وذاكرة التخزين المؤقت ليست ذكية بما يكفي لمعرفة أفضل .

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

في الوقت الحالي ، تعد المتغيرات مسودة مبكرة جدًا ، ولأنها مصممة للمساعدة في Accept-Encoding Accept-Language ، فإن فائدتها تقتصر إلى حد ما على ذاكرات التخزين المؤقت المشتركة ، مثل شبكات CDN ، بدلاً من ذاكرات التخزين المؤقت للمتصفح. لكنه يقترن بشكل جيد مع Key ويكمل الصورة للتحكم بشكل أفضل في تنوع ذاكرة التخزين المؤقت.

خاتمة

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

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

انطلق وكن متغيرًا.