كثير من المواقع الثابتة تكون سريعة من ناحية المعمارية، لكنها بطيئة من ناحية السياسة.

يبدو هذا متناقضًا حتى تبدأ بالنظر إلى الـ headers الفعلية الخارجة إلى المتصفح وإلى الـ edge. يمكن لموقع مبني بـ Astro، ومولّد كملفات ثابتة، ومرفوع على Cloudflare Pages، أن يهدر جزءًا معتبرًا من الأداء فقط لأن سياسة الكاش فيه ضبابية أو منسوخة من starter عام.

وهنا تبدأ التفاصيل التشغيلية في إظهار قيمتها.

ما الذي توضحه وثائق Cloudflare الرسمية

وثائق Cloudflare الرسمية الخاصة بـ Pages headers توضح أن ملف _headers داخل مجلد الأصول الثابتة يتم تحليله وتطبيقه على استجابات الأصول الثابتة، ولا يُخدم هو نفسه كملف. كما توضح الوثائق نفسها أن قواعد _headers لا تُطبق على الاستجابات المولدة عبر Pages Functions أو SSR، وأن هذه الحالات تحتاج headers من الكود نفسه.

وفي جانب آخر، توضح وثائق Cloudflare Cache أن Origin Cache Control مفعّل افتراضيًا في الخطط Free وPro وBusiness، وأن Cloudflare يحترم توجيهات Cache-Control القادمة من الأصل ما لم تقم أنت بتجاوزها عبر Cache Rules.

وهذا يعطينا النموذج الذهني الصحيح:

  • _headers تحكم الاستجابات الثابتة في Pages
  • Cache-Control يظل عنصرًا حاسمًا
  • أي استجابة ديناميكية يجب أن تضبط headers من داخل الكود

المواقع التحريرية تحتاج ثلاث طبقات كاش

المنصة الجادة تحتاج غالبًا إلى ثلاث سلوكيات منفصلة:

  1. الأصول المولّدة ببصمات fingerprinted يجب أن تُخزن بقوة
  2. صفحات HTML يجب أن تبقى منعشة بما يكفي لالتقاط النشر الجديد بسرعة
  3. ملفات البحث يجب أن تكون مستقرة ولكن قابلة للاستبدال مع كل build

إذا انهارت هذه الطبقات كلها داخل default واحد، ستحصل إما على محتوى stale أو على أداء ضائع.

الطبقة الأولى: الأصول immutable يجب أن تكون مملة

إذا كان ملف CSS أو JS أو font أو image يولّده الـ build ببصمة URL واضحة، فتعامل معه كما لو أنه لن يتغير أبدًا تحت نفس الرابط:

مقتطف شيفرة

txt 

    /_astro/*
  Cache-Control: public, max-age=31556952, immutable

/fonts/*
  Cache-Control: public, max-age=31556952, immutable

/og/covers/*
  Cache-Control: public, max-age=31556952, immutable

هذا من أسهل مكاسب الأداء في المواقع الثابتة، لأن المتصفح والـ edge يستطيعان الاسترخاء. الرابط نفسه سيتغير إذا تغير الملف. وهذا هو السيناريو المثالي لـ immutable caching.

الطبقة الثانية: HTML يجب أن يكون قصير العمر وصادقًا

HTML هو أكثر جزء يتغير في المنصات التحريرية. وإذا خزّنته مثل bundle ثابت، فسيبدأ النشر عندك بالشعور بالبطء والغموض.

بالنسبة لمنصة تتحرك يوميًا، أميل إلى سياسة محافظة:

مقتطف شيفرة

txt 

    /en/*
  Cache-Control: public, max-age=0, must-revalidate

/ar/*
  Cache-Control: public, max-age=0, must-revalidate

هذا يُبقي المتصفح صريحًا، ويترك لـ Cloudflare فرصة إعادة التحقق بدلًا من خدمة نسخة stale من الـ markup إلى ما لا نهاية.

الطبقة الثالثة: ملفات البحث تستحق معاملة صريحة

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

لذلك أرى أن هذه تسوية قوية:

مقتطف شيفرة

txt 

    /pagefind/*
  Cache-Control: public, max-age=3600, stale-while-revalidate=60

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

إعادة التحقق هي المكان الذي يتراخى فيه كثير من الفرق

وثائق Cloudflare حول revalidation وrequest collapsing مفيدة جدًا لأنها تذكّرنا بأن “الانتعاش” لا يعني دائمًا ضغطًا دائمًا على الأصل. توجيهات مثل stale-while-revalidate وstale-if-error ليست حيل CDN، بل أدوات اعتمادية.

وبالنسبة للبحث التحريري أو الفهارس الخفيفة، فهي مفيدة جدًا:

  • stale-while-revalidate ينعّم لحظات تحديث الفهارس أثناء البناء
  • stale-if-error يمنحك هامش أمان إذا فشلت إعادة التحقق
  • s-maxage يسمح بتفريق سلوك Cloudflare عن المتصفح عند الحاجة

أين يقع الخطأ غالبًا

أكثر الأخطاء التي أراها شيوعًا هي:

  • التعامل مع HTML والأصول الثابتة بنفس السياسة
  • افتراض أن _headers يغطي أيضًا Pages Functions
  • نسيان أن ملفات البحث جزء من المنتج نفسه
  • تجاوز نية الأصل من دون توثيق سبب ذلك
  • تفعيل immutable caching قبل التأكد أن الأصول فعلًا fingerprinted

هذه ليست أخطاء درامية، لكنها تجعل الأداء صعب الفهم، ولذلك تستمر.

الـ playbook الذي سأعتمده فعليًا

لو كنت أطلق منصة ثنائية اللغة على Cloudflare Pages الآن، فسأبقي السياسة بسيطة:

  • immutable caching للأصول المولدة ببصمات ولصور الـ covers
  • revalidated caching للـ HTML
  • freshness مضبوط لملفات Pagefind
  • headers من الكود لأي Pages Functions أو SSR مستقبلًا
  • فحص دوري للـ headers بعد كل deploy

وهذا يكفي ليبقى الموقع سريعًا، سهل التفسير، وسهل الصيانة لكل الفريق.

الخلاصة

استراتيجية الكاش من المجالات التي يبدو فيها الاحتراف مملًا بشكل جميل. لا توجد خدعة سحرية هنا، بل نية واضحة تُترجم إلى headers تتوافق مع سلوك الموقع الفعلي.

ولهذا فهي مهمة جدًا. في المنصات التحريرية الجادة، تكون سياسة الكاش المملة أحيانًا هي الفرق بين “سريع نظريًا” و”سريع كل يوم”.