أداة إضافية لمساعدتك في تحقيق التوازن بين السرعة والحداثة عند عرض تطبيق الويب
ما الذي تم شحنه؟
يساعد stale-while-revalidate
المطوّرين في تحقيق التوازن بين الهدف الفوري، أي تحميل المحتوى المخزّن مؤقتًا بشكل فوري والحداثة، لضمان استخدام التحديثات التي يتم إجراؤها على المحتوى المخزّن مؤقتًا في المستقبل. إذا كنت
تتولّى خدمة ويب أو مكتبة تابعة لجهة خارجية يتم تحديثها وفقًا لجدول زمني منتظم، أو إذا كانت مدة مواد عرض الطرف الأول قصيرة، قد تكون إضافة
stale-while-revalidate
مفيدة إلى سياسات التخزين المؤقت الحالية التي تستخدمها.
يمكن ضبط stale-while-revalidate
إلى جانب max-age
في عنوان استجابة Cache-Control
في Chrome 75 وFirefox 68.
وستتجاهل المتصفحات التي لا تتوافق مع stale-while-revalidate
قيمة الإعداد هذه بشكلٍ غير ملحوظ، وتستخدم max-age
، كما سأشرح لك باختصار...
ما معنى ذلك؟
لنقسم stale-while-revalidate
إلى قسمَين: فكرة أنّ الاستجابة المخزَّنة مؤقتًا قد تكون قديمة، وعملية إعادة التحقّق.
أولاً، كيف يعرف المتصفّح ما إذا كانت الاستجابة المخزَّنة مؤقتًا "قديمة"؟ يجب أن يتضمّن عنوان الاستجابة Cache-Control
الذي يحتوي على stale-while-revalidate
أيضًا على max-age
، وعدد الثواني المحدّد عبر max-age
هو ما يحدّد مدى القِدم. وتُعتبر أي استجابة مخزَّنة مؤقتًا أحدث من max-age
"جديدة"، وتكون الاستجابات المخزّنة مؤقتًا قديمة.
إذا كانت الاستجابة المُخزَّنة مؤقتًا محليًا لا تزال جديدة، يمكن استخدامها كما هي
لتلبية طلب المتصفّح. من منظور stale-while-revalidate
، ما مِن إجراء يجب اتّخاذه في هذا السيناريو.
أما إذا كانت الاستجابة المخزَّنة مؤقتًا قديمة، يتم إجراء عملية تحقّق أخرى مستندة إلى العمر:
هل عمر الاستجابة المخزَّنة مؤقتًا خلال الفترة الزمنية الإضافية التي يوفّرها إعداد
stale-while-revalidate
؟
إذا كان عمر الاستجابة القديمة يقع في هذه النافذة، فسيتم استخدامه لتلبية طلب المتصفح. وفي الوقت نفسه، سيتم تقديم طلب "إعادة تحقق" ضد الشبكة بطريقة لا تؤخر استخدام الاستجابة المخزَّنة مؤقتًا. قد تحتوي الاستجابة المعروضة على المعلومات نفسها الموجودة في
الاستجابة المخزنة مؤقتًا سابقًا أو قد تكون مختلفة. وفي كلتا الحالتين، يتم تخزين استجابة الشبكة محليًا، مع استبدال أي عملية تخزين مؤقت سابقة وإعادة ضبط موقّت "الحداثة" المستخدَم أثناء أي مقارنات مستقبلية مع max-age
.
مع ذلك، إذا كانت الاستجابة القديمة المخزّنة مؤقتًا قديمة بما يكفي لدرجة أنّها خارج نطاق فترة استخدام stale-while-revalidate
، لن تستوفي الاستجابة لطلب المتصفّح. بدلاً من ذلك، سيسترد المتصفح استجابة من الشبكة ويستخدمها لتلبية الطلب الأولي وتعبئة ذاكرة التخزين المؤقت المحلية أيضًا باستجابة جديدة.
مثال مباشر
في ما يلي مثال بسيط على واجهة برمجة تطبيقات HTTP لعرض الوقت الحالي، وبشكل أكثر تحديدًا، العدد الحالي للدقائق بعد الساعة.
في هذا السيناريو، يستخدم خادم الويب عنوان Cache-Control
هذا في استجابة HTTP:
Cache-Control: max-age=1, stale-while-revalidate=59
يعني هذا الإعداد أنّه في حال تكرار طلب ما خلال الثانية التالية، ستظل القيمة المخزَّنة مؤقتًا في السابق جديدة وسيتم استخدامها كما هي، بدون أي إعادة تحقُّق.
إذا تكرّر الطلب بعد مدة تتراوح بين ثانية واحدة و60 ثانية، ستصبح القيمة المخزَّنة مؤقتًا قديمة ولكن سيتم استخدامها لتنفيذ طلب البيانات من واجهة برمجة التطبيقات. في الوقت نفسه، "في الخلفية"، سيتم إجراء طلب إعادة تحقق لملء ذاكرة التخزين المؤقت بقيمة جديدة للاستخدام المستقبلي.
إذا تكرر الطلب بعد أكثر من 60 ثانية، فلن يتم استخدام الاستجابة القديمة على الإطلاق، وسيعتمد تنفيذ طلب المتصفح وإعادة التحقق من ذاكرة التخزين المؤقت على الحصول على رد من الشبكة.
في ما يلي تصنيف لهذه الحالات الثلاث المختلفة، بالإضافة إلى الفترة الزمنية التي تنطبق فيها كل حالة من هذه الحالات على مثالنا:
ما هي حالات الاستخدام الشائعة؟
على الرغم من أنّ المثال السابق حول خدمة واجهة برمجة التطبيقات "بعد دقائق بعد الساعة" مُستبعَد، يوضّح المثال التالي حالة الاستخدام المتوقّعة، وهي الخدمات التي توفّر معلومات يجب إعادة تحميلها، ولكن عندما يكون المقدار كبيرًا من القِدم.
وقد تشمل الأمثلة الأقل انتشارًا واجهة برمجة التطبيقات لأحوال الطقس الحالية، أو أهم عناوين الأخبار التي تمت كتابتها في الساعة الماضية.
بشكل عام، من المرجَّح أن يتم طلب أي ردّ يتم تعديله عدة مرات في فترات زمنية معروفة، ويكون ثابتًا خلال هذه الفترة صالحًا للاستخدام في التخزين المؤقت القصير المدى من خلال max-age
. يؤدي استخدام العلامة stale-while-revalidate
بالإضافة إلى max-age
إلى زيادة احتمال تنفيذ الطلبات المستقبلية من ذاكرة التخزين المؤقت التي تتضمّن محتوى أحدث، بدون حظر استجابة الشبكة.
كيف تتفاعل مع عاملي الخدمة؟
إذا سمعْت عن stale-while-revalidate
، يرجّح أنّها ضمن
سياق
وصفات الطعام
المستخدَمة في عامل تقديم خدمات.
يؤدي استخدام خيار "القديمة أثناء إعادة التحقق" عبر عنوان Cache-Control
إلى مشاركة بعض أوجه التشابه
مع استخدامه في عامل الخدمات، وتنطبق العديد من الاعتبارات نفسها حول مفاضلات الحداثة والحد الأقصى لعمر الخدمة. مع ذلك، هناك بعض الاعتبارات التي يجب مراعاتها عند تحديد
ما إذا كان سيتم تطبيق نهج يستنِد إلى مشغّلي الخدمات أو الاعتماد فقط على
إعدادات عنوان Cache-Control
.
استخدِم أسلوب مشغّل الخدمات في الحالات التالية:
- أنت تستخدم حاليًا مشغّل خدمات في تطبيق الويب.
- تحتاج إلى تحكم دقيق في محتويات ذاكرات التخزين المؤقت، وتريد تنفيذ شيء مثل سياسة انتهاء الصلاحية التي لم يتم استخدامها مؤخرًا. يمكن لوحدة انتهاء صلاحية ذاكرة التخزين المؤقت في Workbox أن تساعدك في هذا الشأن.
- تريد أن يتم إعلامك عندما يتغير ردّ قديم في الخلفية أثناء خطوة إعادة التحقّق. يمكن أن تساعد وحدة Broadcast Cache Update (تحديث ذاكرة التخزين المؤقت للبث) في Workbox في هذا الشأن.
- يجب ضبط سلوك "
stale-while-revalidate
" هذا في جميع المتصفحات الحديثة.
يمكنك استخدام أسلوب التحكم في ذاكرة التخزين المؤقت في الحالات التالية:
- تفضّل عدم التعامل مع النفقات العامة لنشر وصيانة عامل خدمات لتطبيق الويب.
- لا بأس في السماح للإدارة التلقائية لذاكرة التخزين المؤقت في المتصفح بمنع زيادة حجم ذاكرات التخزين المؤقت المحلية بشكل كبير جدًا.
- لا بأس في استخدام طريقة غير متوفرة حاليًا في جميع المتصفحات الحديثة (بدءًا من تموز (يوليو) 2019، وقد تتم زيادة التوافق في المستقبل).
إذا كنت تستخدم مشغّل خدمات وفعّلت أيضًا stale-while-revalidate
لبعض الاستجابات من خلال عنوان Cache-Control
، سيكون لدى مشغّل الخدمة
بشكل عام "الاختراق الأول" عند الاستجابة للطلب. إذا قرّر مشغّل الخدمات
عدم الاستجابة، أو إذا قدّم أثناء عملية إنشاء استجابة طلب شبكة باستخدام fetch()
،
سيتم تنفيذ السلوك الذي تم ضبطه من خلال عنوان Cache-Control
.
مزيد من المعلومات
- استجابة
stale-while-revalidate
في مواصفات Fetch API. - RFC 5861، الذي يغطي
مواصفات
stale-while-revalidate
الأولية. - ذاكرة التخزين المؤقت لبروتوكول HTTP: خط الدفاع الأول، من دليل "موثوقية الشبكة" على هذا الموقع الإلكتروني.
صورة رئيسية من تصميم "صامويل زيلر".