Cloudflare Workers Cache: ثورة التخزين المؤقت في يوليو 2026

كل طلب يصل إلى تطبيقك المدعوم بـ Workers كان ينفذ الكود، حتى عندما لا تتغير الاستجابة لساعات. انتهت هذه الضريبة على الحوسبة اللاخادمية. إطلاق Workers Cache من Cloudflare في 6 يوليو 2026 يقلب البنية المعمارية: التخزين المؤقت الآن يعمل قبل Worker الخاص بك، ويقدم الاستجابات المخزنة مؤقتاً دون حرق ميلي ثانية واحدة من وقت المعالج.

الانقلاب المعماري الذي يغير كل شيء

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

Workers Cache يقلب هذا التدفق رأساً على عقب. طبقة تخزين مؤقت متدرجة تجلس الآن أمام Worker. إذا وُجدت استجابة مخزنة مؤقتاً، تقدمها Cloudflare مباشرة من الحافة ولا يعمل Worker أبداً. صفر وقت معالج مفوتر.

هذا مهم جداً للتطبيقات المعروضة من الخادم. أطر العمل مثل Astro و Next.js و Remix و SvelteKit و TanStack Start دفعت Workers من "وكيل ذكي" إلى "مصدر حقيقي". المقايضة كانت دفع "عقوبة العرض اللاخادمي" على كل طلب، حتى عندما يطلب آلاف المستخدمين نفس الصفحة.

مع Workers Cache، يصبح نمط العرض عند الطلب والتخزين المؤقت في الحافة واقعياً مالياً لـ SSR عالي الحركة.

مملوك للـ Worker، وليس للمنطقة

التحول ليس فقط حول السرعة - إنه حول الملكية. هذا تخزين مؤقت لـ Worker الخاص بك، وليس للمنطقة. بدلاً من التلاعب بقواعد مستوى المنطقة، تشارك بإعداد Wrangler بسيط:

tomlCopy
[cache]
enabled = true

وهذا هو التبديل كاملاً. لا مزيد من التنقل بين قواعد التخزين المؤقت وقواعد الصفحة وقوائم امتدادات الملفات في إعدادات المنطقة. سلوك التخزين المؤقت يسافر مع Worker أينما نُشر: النطاقات المخصصة، workers.dev، روابط الخدمة، عناوين المعاينة، مستأجري Workers for Platforms، وفئات WorkerEntrypoint المسماة.

هذا السطر enabled = true يخبر Cloudflare بفحص التخزين المؤقت قبل استدعاء Worker الخاص بك. سلوك التخزين المؤقت الفعلي لا يزال يعتمد على رؤوس HTTP التي يعيدها Worker الخاص بك. فكر فيه كانضمام للنظام، ثم التحكم فيه بدلالات التخزين المؤقت المعيارية.

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

بنية إقليمية ثنائية المستوى

شبكة Cloudflare العالمية تمتد عبر 337 مدينة مع أكثر من 13,000 اتصال متبادل. Workers Cache يستخدم هيكل ثنائي المستوى عبر تلك الشبكة.

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

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

Stale-While-Revalidate يعمل أخيراً بشكل صحيح

إعداد تخزين مؤقت SSR قوي عادة ما يعتمد على TTL بالإضافة إلى التحديث في الخلفية:

textCopy
Cache-Control: public, max-age=300, stale-while-revalidate=3600

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

max-age=300 هو النافذة "الطازجة" حيث تُقدم الاستجابات دون أي إعادة تحقق. بعد 5 دقائق، stale-while-revalidate=3600 يتولى الأمر: Cloudflare يعيد الاستجابة القديمة فوراً بينما يستدعي أيضاً Worker الخاص بك في الخلفية لتحديث التخزين المؤقت.

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

إبطال Cache-Tag للتحكم الدقيق

مسح كل شيء هو أسرع طريقة لحرق معدل النجاح الخاص بك. Workers Cache يدعم الإبطال القائم على العلامات:

javascriptCopy
export default {
  async fetch(request, env, ctx) {
    const response = await renderProductPage(request);
    return new Response(response.body, {
      headers: {
        'Cache-Control': 'public, max-age=3600',
        'Cache-Tag': 'product:123, category:electronics, homepage-featured'
      }
    });
  }
}

عندما يتغير المنتج 123، امسح فقط تلك العلامة:

javascriptCopy
await ctx.cache.purge({ tags: ['product:123'] });

Cache-Tag يأخذ قيم مفصولة بفواصل، لذا يمكن لاستجابة واحدة أن تنتمي إلى مجموعات إبطال متعددة. عندما يعمل ctx.cache.purge مع علامة، Cloudflare يبطل كل استجابة مخزنة مؤقتاً تحمل تلك العلامة عبر الشبكة بأكملها. Cloudflare تقول أن هذا يكتمل في أقل من 150 ميلي ثانية عالمياً، بناءً على إعلان المسح الفوري.

للتجارة الإلكترونية وأنظمة إدارة المحتوى وأي تطبيق بمحتوى متصل، التغييرات يمكن أن تبطل بالضبط ما يحتاج للتغيير، دون مسح طبقات تخزين مؤقت كاملة.

التخزين المؤقت لكل نقطة دخول للبنى القابلة للتركيب

Workers Cache لا يفرض نهج الكل أو لا شيء. الإعداد يمكن أن يختلف بين التصدير الافتراضي الخاص بك، وفئات WorkerEntrypoint المسماة، واستدعاءات ربط الخدمة، واستدعاءات ctx.exports الارتدادية.

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

نموذج التكلفة يتطلب تحليلاً دقيقاً

Workers Cache يغير الفوترة بطرق يمكن أن توفر المال أو تفاجئك. نجاحات التخزين المؤقت تُحسب كطلبات Workers معيارية (0.30 دولار لكل مليون بعد 10 ملايين مشمولة) لكن تفوتر صفر وقت معالج.

وثائق تسعير Cloudflare تعطي مثالاً ملموساً: Worker يتعامل مع 100 مليون طلب شهرياً بمتوسط 7 ميلي ثانية معالج لكل طلب ينخفض من 45.40 دولار/شهر إلى 34.20 دولار/شهر مع معدل نجاح تخزين مؤقت 80%. هذا تقريباً تخفيض 25% في إجمالي الفاتورة و84% أقل في تكاليف تجاوز المعالج.

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

استنتاج AI في الحافة يصبح أرخص

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

javascriptCopy
export default {
  async fetch(request, env, ctx) {
    const prompt = await request.text;
    const cacheKey = `inference:${hashPrompt(prompt)}`;

    const response = await generateResponse(prompt, env);

    return new Response(JSON.stringify(response), {
      headers: {
        'Cache-Control': 'public, max-age=86400',
        'Cache-Tag': `model:${env.MODEL_VERSION}`
      }
    });
  }
}

hashPrompt ينشئ مفتاح تخزين مؤقت حتمي من المدخل. عندما تظهر نفس المطالبة مرة أخرى، Workers Cache يمكن أن يقدم نتيجة الاستنتاج المخزنة مؤقتاً دون استدعاء Worker الخاص بك أو النموذج اللاحق. وضع علامات على الإدخالات بإصدار النموذج يعطيك قصة مسح نظيفة كلما شحنت نموذجاً جديداً. نقاط نهاية AI الحافة يمكن أن تقدم الاستعلامات المتكررة بسرعات CDN دون تكلفة استنتاج.

المخاطر التي يجب تجنبها

رأس Vary أيضاً يحتاج انضباط حقيقي. كل مزيج فريد من الرؤوس المتنوعة ينشئ إدخال تخزين مؤقت منفصل. Vary: Accept-Encoding جيد. Vary: Cookie عادة يفجر تخزينك المؤقت إلى إدخالات لكل مستخدم ويهزم الهدف.

لا تفترض التوفير حتى تفحص معدلات النجاح في Workers Observability. معدل نجاح 20% على Worker خفيف المعالج يمكن بسهولة أن ينتهي بتكلفة أكثر من الإعداد القديم. الميزة قوية، لكنها لن تصلح استراتيجية تخزين مؤقت غير متطابقة بمفردها.

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

• Smart Tiered Cache لمصادر السحابة العامة: Cloudflare أطلقت هذا بجانب Workers Cache، مما يشير إلى تحول استراتيجية تخزين مؤقت حافة أكبر
• نظام إجماع Meerkat العالمي: مبني على QuePaxa، هذا يشير إلى استثمار أعمق في الحالة الموزعة في الحافة
• تحديثات محول إطار العمل: Astro و Next.js وأطر SSR أخرى ستشحن على الأرجح أنماط Workers Cache أوضح
• مقاييس تخزين مؤقت Workers Observability: هذه ما ستعتمد عليه للتحقق من معدلات النجاح وتأثير التكلفة
• تغييرات حد حجم كائن التخزين المؤقت: وثائق الحدود الحالية قد تتغير مع نمو الاستخدام

اتخذ إجراء

ابدأ هنا (خطوتك الأولى)
أضف [cache]\nenabled = true إلى wrangler.toml الخاص بك على Worker تجريبي وراقب لوحة Observability لمعدلات نجاح التخزين المؤقت.

انتصارات سريعة (تأثير فوري)

• أضف رؤوس Cache-Control: public, max-age=300, stale-while-revalidate=3600 إلى أثقل مسارات SSR الخاصة بك
• راجع الاستجابات لرؤوس Set-Cookie التي تمنع التخزين المؤقت

غوص عميق (لمن يريد المزيد)

• اعمل نموذج للفوترة الحالية مقابل معدلات النجاح المتوقعة باستخدام حاسبة تسعير Cloudflare
• نفذ إبطال Cache-Tag لتحديثات CMS أو كتالوج المنتجات

موارد مفيدة

• إعداد Workers Cache - دليل الإعداد الرسمي لإعداد Wrangler وإعدادات كل نقطة دخول
• Workers Cache API - وثائق Runtime API للتحكم البرمجي في التخزين المؤقت
• تسعير Workers - نموذج التسعير الحالي بما في ذلك فوترة نجاح التخزين المؤقت
• حدود Workers - قيود المنصة بما في ذلك أحجام كائن التخزين المؤقت
• المسح الفوري للجميع - خلفية عن بنية مسح Cloudflare العالمية تحت 150 ميلي ثانية

ما يعنيه هذا لك

Workers Cache هو واحد من أكبر التحولات في اقتصاديات Workers منذ الإطلاق. الانتقال من "تخزين مؤقت بعد Worker" إلى "تخزين مؤقت قبل Worker" يزيل مشكلة التكلفة الأساسية التي جعلت SSR مكلفاً على نطاق واسع.

إذا كان فريقك يشغل تطبيقات معروضة من الخادم على Workers، هذه هي الميزة التي تجعل المنصة تنافسية في التكلفة مع نموذج CDN-plus-origin الكلاسيكي، مع الحفاظ على قصة النشر البسيطة والوصول العالمي الذي جذب الفرق إلى Workers في المقام الأول.

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