استراتيجيات التخزين المؤقت عند الحافة لتطبيقات React

تتحكم ترويسة الاستجابة Cache-Control في مدة تخزين استجابات SSR مؤقتًا لدى Cloudflare وغيرها من شبكات CDN. والتوجيهات الأساسية هي: max-age (ذاكرة التخزين المؤقت للمتصفح)، وs-maxage (مدة التخزين المؤقت لدى CDN أو الذاكرة المشتركة)، وstale-while-revalidate (عرض المحتوى القديم أثناء إعادة التحقق منه في الخلفية).

تلتزم الذاكرات المؤقتة المشتركة، مثل شبكات CDN، بالتوجيه s-maxage، بينما يخص max-age ذاكرة المتصفح المؤقتة. وبالنسبة إلى صفحات SSR، ستحتاج عادةً إلى s-maxage=60 (تخزّن CDN الصفحة مؤقتًا لمدة 60 ثانية) وmax-age=0 (يعيد المتصفح التحقق دائمًا)، وبذلك يحصل جميع المستخدمين على محتوى حديث بدرجة معقولة من ذاكرة الحافة المؤقتة.

إضافة stale-while-revalidate=30 إلى ترويسة Cache-Control تخبر Cloudflare بعرض الصفحة المخزنة مؤقتًا فورًا، مع جلب نسخة حديثة في الخلفية. ويحصل المستخدمون دائمًا على استجابة سريعة، بينما يبلغ الحد الأقصى لقِدم المحتوى s-maxage + stale-while-revalidate ثانية.

يجب ألا يُقدَّم المحتوى المخصص، المستند إلى جلسة المستخدم أو إعدادات اللغة، من ذاكرة مشتركة إلى المستخدم الخطأ. وتخبر الترويسة Vary: Cookie Cloudflare بأن تتعامل مع كل قيمة Cookie فريدة بوصفها إدخالًا مستقلًا في الذاكرة المؤقتة، مما يمنع تقديم بيانات مستخدم إلى مستخدم آخر.

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

Cloudflare KV هو مخزن مفتاح-قيمة موزع عالميًا، يخزّن البيانات بالقرب من المستخدمين. ويمكنك تخزين HTML المعروض مؤقتًا في KV — خزّن الصفحة المعروضة بوصفها قيمة مع TTL، ثم اقرأها من KV عند الطلبات اللاحقة على الحافة بدلًا من إعادة عرضها باستخدام React.

تتم قراءات KV بسرعة لأن البيانات تُكرَّر في نقطة PoP الطرفية التي تخدم الطلب — ويكون زمن القراءة المعتاد أقل من 5ms. أما كتابات KV فتستخدم الاتساق النهائي؛ إذ تنتقل الكتابة في منطقة واحدة إلى جميع نقاط PoP العالمية خلال 60 ثانية، مما يعني أن بعض المستخدمين قد يرون بيانات قديمة لفترة وجيزة.

Cloudflare R2 هي خدمة لتخزين الكائنات متوافقة مع S3 ولا تفرض رسومًا على نقل البيانات إلى الخارج. وهي مناسبة للأصول الكبيرة التي لا تتسع لها KV، مثل وحدات WASM وصور OG المُسبقة العرض ومجموعات بيانات JSON الكبيرة. وتصل Workers إلى R2 عبر الارتباطات، تمامًا كما تصل إلى KV.

تدعم Cloudflare Enterprise وسوم الذاكرة المؤقتة: تضع وسمًا على الاستجابة باستخدام Cache-Tag: product-42، وعندما يتغير المنتج 42، تستدعي API الخاصة بـ Cloudflare لحذف جميع الاستجابات الموسومة بـ product-42. ويتيح ذلك إبطالًا دقيقًا للذاكرة المؤقتة من دون حذف محتوى الذاكرة المؤقتة بأكمله.

عند نشر إصدار جديد من Worker، قد يشير HTML المخزن مؤقتًا إلى أسماء قديمة لحزم JavaScript. وتتمثل الاستراتيجية المتينة في تضمين إصدار النشر في مفاتيح الذاكرة المؤقتة، أو استخدام أسماء حزم ذات إصدارات، عبر تجزئة المحتوى في Vite، بحيث يشير HTML القديم دائمًا إلى ملفات JavaScript صالحة ومخزنة مؤقتًا.

يتبع Worker الذي يخزّن HTML الناتج عن SSR مؤقتًا في KV النمط التالي: احسب مفتاحًا من URL، ومن إعدادات اللغة اختياريًا، ثم تحقّق من وجوده في KV وأعد HTML المخزن مؤقتًا فورًا إذا عثرت عليه. وعند عدم العثور عليه، اعرض الصفحة باستخدام React، وخزّن النتيجة في KV مع TTL، ثم أعد HTML الذي عُرض حديثًا.

ما نموذج الاتساق الذي تستخدمه Cloudflare KV للكتابات؟

يستخدم التخزين المؤقت عند الحافة لتطبيقات React عدة استراتيجيات متراكبة: s-maxage في Cache-Control لتخزين الصفحات العامة مؤقتًا لدى CDN، وVary: Cookie لمنع مشاركة الاستجابات المخصصة، وKV لتخزين HTML المعروض مؤقتًا عند الحافة، ووسوم الذاكرة المؤقتة للإبطال الدقيق. ويعني نموذج الاتساق النهائي في KV أن نشر الكتابة قد يستغرق ما يصل إلى 60 ثانية — لذا صمّم قيم TTL واستراتيجية الإبطال وفقًا لذلك.