يُعد تكوين سياسة قوية للتخزين المؤقت لشبكة CDN من Cloudflare واحدة من أعلى مهام الهندسة تأثيرًا لتحسين سرعة موقع إلكتروني للمؤسسات في عام 2026. تعاني العديد من منصات الويب من زمن استجابة مرتفع لأن كل طلب مستخدم يجب أن ينتقل إلى خادم قاعدة بيانات المصدر لعرض الصفحات. هذا الاعتماد على المصدر يؤخر مقياسي السرعة First Contentful Paint (FCP) وLargest Contentful Paint (LCP)، بينما يقدّم تخزين تخطيطات الصفحات الثابتة ومكوّنات الأصول في مواقع الحافة (edge) حول العالم استجابات سريعة ومنخفضة الكمون من أقرب موقع حافة. يوضّح هذا الدليل آليات التخزين المؤقت، وقواعد Edge Cache TTL، وتكوينات تجاوز ملفات تعريف الارتباط الديناميكية.

[!TIP] نصيحة لتحسين التخزين المؤقت: تجنّب تخزين صفحات HTML التي تحتوي على تفاصيل مستخدمين مسجّلي الدخول. اضبط دائمًا قواعد Cache Rules الخاصة بك لتجاوز التخزين المؤقت على الحافة عند اكتشاف ملفات تعريف ارتباط جلسة محددة (مثل ملفات تعريف ارتباط WordPress أو رموز المصادقة المخصصة) في ترويسات الطلب.

أهم النقاط:

  • يقلل التخزين المؤقت لشبكة CDN من Cloudflare من استعلامات قاعدة بيانات خادم الواجهة الخلفية، مما يخفض تكاليف الاستضافة.
  • تتيح قواعد Cache Rules للمطورين ضبط قيم TTL مخصصة استنادًا إلى أنواع المحتوى والأدلة.
  • يتطلب نشر قواعد Cache Everything تكوين تجاوزات لملفات تعريف ارتباط الجلسة لمنع تسرّب بيانات المستخدم.
  • يساعد تقديم الصفحات الثابتة مباشرةً من مواقع الحافة المواقعَ الإلكترونية على اجتياز Core Web Vitals على الأجهزة المحمولة.

تكوينات التخزين المؤقت: Page Rules مقابل Cache Rules

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

بشكل افتراضي، لا تخزّن شبكات CDN سوى تنسيقات الوسائط وأوراق الأنماط والنصوص البرمجية. وبالتالي، يجب تكوين ثلاثة خيارات أساسية للأصول:

  • التخزين المؤقت لـ HTML: لتحقيق تحميل فوري للصفحات، يجب أن توجّه شبكة CDN لتخزين بنية مستند HTML مؤقتًا. وبذلك يتوقف إجراء استعلامات قاعدة البيانات.
  • ترويسات Cache-Control: اضبط خادم الواجهة الخلفية Symfony أو PHP لديك لإرسال توجيهات s-maxage مخصصة لإخبار خوادم الحافة بالمدة التي يجب تخزين الصفحات خلالها. إضافةً إلى ذلك، يتيح هذا قواعد TTL مخصصة.
  • مدة TTL للتخزين المؤقت في المتصفح: اضبط مدد أقصر لبقاء التخزين المؤقت في المتصفح (مثلاً 4 ساعات) لضمان تلقّي المستخدمين للتحديثات عند تعديل تخطيطات الموقع. وبالتالي، يمنع هذا مشكلات عدم تطابق التخطيط.

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

  • تجاوزات الجلسة: أنشئ قواعد توجّه شبكة CDN لتجاوز التخزين المؤقت عندما يحمل الطلب ملفات تعريف ارتباط للمصادقة أو الجلسة، بحيث يتلقى المستخدمون المسجّلون دائمًا استجابات مخصصة بينما لا يزال الزوار المجهولون يُخدَمون من ذاكرة التخزين المؤقت عند الحافة.
  • فرز سلاسل الاستعلام: اضبط التخزين المؤقت لقاعدة بيانات الحافة لتجاهل متغيرات التحليلات الطفيفة (مثل وسوم UTM) عند تقييم مفاتيح التخزين المؤقت. وبالتالي، يمنع هذا تجزئة التخزين المؤقت.

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

  1. دقّق ترويسات HTTP: تحقق من أن خادم المصدر لديك يرسل ترويسات Cache-Control وVary نظيفة دون حواجز مصادقة.
  2. صُغ قواعد Cache Rules معيارية: اضبط قواعد Cache Rules مستهدفة لتخزين أدلة الفئات الثابتة لمدة تصل إلى 30 يومًا.
  3. أنشئ استثناءات المصادقة: أنشئ قواعد لتجاوز التخزين المؤقت على الحافة عند اكتشاف ملفات تعريف ارتباط تسجيل الدخول.
  4. انشر خطافات ويب لواجهة Purge API: اضبط إجراءات الحفظ في قاعدة البيانات لتشغيل طلبات آلية إلى Purge API عند تحديث الصفحات.

مقارنة الأداء: التخزين المؤقت على الحافة مقابل الجلب من المصدر

لتوضيح فوائد السرعة، يفصّل الجدول التالي مقاييس تحميل فعلية:

مقياس الأداءالجلب من خادم المصدر (بدون تخزين مؤقت لـ CDN)إصابة التخزين المؤقت على الحافة (CDN نشط)تحسّن السرعة المتوقع
Time to First Byte (TTFB)450 - 800 مللي ثانية15 - 35 مللي ثانيةاستجابة أولية للخادم أسرع بنسبة تصل إلى 95%
LCP على الجوال (أكبر صورة)3.8 ثانية (ضعيف)1.4 ثانية (جيد)اجتياز مقاييس Core Web Vitals بنظافة
حمل وحدة المعالجة المركزية على المصدرمرتفع (كل صفحة تستعلم قاعدة البيانات)ضئيل (تتولى الحافة 90% من الإصابات)خفض تكاليف الاستضافة وثبات أعلى

المتطلبات الأساسية

قبل أن تلمس لوحة التحكم، تأكد من توفر ما يلي:

  • نطاق مُوجَّه بالفعل عبر Cloudflare (إعداد DNS السحابة البرتقالية، وليس الرمادية/DNS فقط).
  • الوصول إلى تكوين المصدر لديك – Nginx أو Apache أو طبقة التطبيق – حتى تتمكن من ضبط ترويسات الاستجابة.
  • رمز API محدود النطاق على Zone → Cache Purge إذا كنت تنوي أتمتة عمليات المسح. أنشئه من My Profile → API Tokens.
  • وسيلة لفحص ترويسات HTTP الخام: curl في سطر الأوامر، أو علامة التبويب Network في Chrome DevTools.
  • عنوان URL للتجهيز أو مسار منخفض الحركة يمكنك التجربة عليه قبل طرح أي شيء على مستوى الموقع بالكامل.

تكفي خطة Free أو Pro لاتباع كل خطوة أدناه. تتوفر قواعد Cache Rules في جميع الخطط، رغم أن بعض خيارات مفتاح التخزين المؤقت وTiered Cache متاحة فقط في المستويات الأعلى.


الخطوة 1: إرسال ترويسات Cache-Control صحيحة من المصدر

لا تعامل Cloudflare استجابةً على أنها قابلة للتخزين المؤقت إلا إذا لم يمنع المصدر ذلك بشكل فعّال. أكثر الأسباب شيوعًا لعدم تخزين HTML مؤقتًا على الإطلاق هو مصدر يعيد ترويسة Set-Cookie أو Cache-Control تقييدية مع كل طلب.

اضبط توجيهات صريحة عند المصدر. في Nginx:

1location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
2    add_header Cache-Control "public, max-age=31536000, immutable";
3}
4
5location / {
6    # HTML: short browser life, long shared (edge) life
7    add_header Cache-Control "public, max-age=0, s-maxage=86400";
8}

يستهدف توجيه s-maxage أنواع التخزين المؤقت المشتركة مثل حافة Cloudflare، بينما يبقي max-age=0 متصفح الزائر في حالة إعادة تحقق حتى لا يرى أبدًا HTML قديمًا بعد النشر. ويخبر الرمز immutable على الأصول ذات البصمة المتصفحاتِ بألا تعيد التحقق منها إطلاقًا.

بالنسبة إلى استجابة مدفوعة بالتطبيق (PHP أو Symfony)، عبّر عن النية نفسها في الشيفرة:

1$response->setPublic();
2$response->setMaxAge(0);            // browser
3$response->setSharedMaxAge(86400);  // edge / s-maxage

يجب أن تنسحب الاستجابات المصادَق عليها أو المخصّصة صراحةً، وإلا فقد تقدّم قاعدة واسعة صفحة أحد المستخدمين إلى مستخدم آخر:

1Cache-Control: private, no-store

الخطوة 2: جعل HTML مؤهلاً للتخزين المؤقت باستخدام Cache Rule

بشكل افتراضي، تضع Cloudflare علامة DYNAMIC على HTML ولا تخزّنه أبدًا. لتغيير ذلك، أنشئ قاعدة من Caching → Cache Rules → Create rule.

اكتب تعبيرًا يطابق الصفحات التي تريد تخزينها مؤقتًا مع استبعاد أي محتوى ديناميكي:

1(http.host eq "example.com"
2  and not starts_with(http.request.uri.path, "/wp-admin")
3  and not starts_with(http.request.uri.path, "/cart")
4  and not starts_with(http.request.uri.path, "/checkout")
5  and not starts_with(http.request.uri.path, "/my-account"))

ثم اضبط إجراءات القاعدة:

  • Cache eligibility: Eligible for cache – المكافئ الحديث للسلوك القديم «Cache Everything».
  • Edge TTL: Use cache-control header if present، بحيث يفوز s-maxage الذي ضبطته في الخطوة 1؛ مع الرجوع إلى قيمة ثابتة مثل يوم واحد في حال غياب الترويسة.
  • Browser TTL: Respect origin.

الخطوة 3: إضافة تجاوز لملفات تعريف الارتباط حتى لا يُخزَّن المستخدمون المسجّلون أبدًا

هذه هي الخطوة التي تتخطّاها معظم الأدلة، وهي التي تُسرّب البيانات عند تخطّيها. أضف قاعدة ثانية موضوعة فوق قاعدة الأهلية، تفرض التجاوز كلما وُجد ملف تعريف ارتباط جلسة حقيقي. تقيّم Cloudflare قواعد Cache Rules من الأعلى إلى الأسفل، لذا تفوز دائمًا قاعدة التجاوز الأسبق بالنسبة إلى الزوار المصادَق عليهم.

1http.cookie contains "wordpress_logged_in_"
2or http.cookie contains "wp-postpass_"
3or http.cookie contains "woocommerce_items_in_cart"
4or http.cookie contains "comment_author_"

اضبط الإجراء على Bypass cache. بالنسبة إلى المكدسات غير WordPress، استبدل أسماء ملفات تعريف الارتباط بمعرّف الجلسة الخاص بإطار عملك – PHPSESSID، laravel_session، connect.sid، وهكذا. حدّد النطاق بدقة: مطابقة ملف تعريف ارتباط تحليلات واسع مثل _ga هنا ستؤدي عن طريق الخطأ إلى تجاوز التخزين المؤقت لكل زائر مجهول أيضًا.


الخطوة 4: توحيد مفتاح التخزين المؤقت

ينبغي أن يتشارك عنوانا URL يختلفان فقط في معلمة تتبّع كائنًا واحدًا مخزّنًا مؤقتًا. داخل قاعدة الأهلية، افتح Cache Key → Query String، واختر Ignore specific query string parameters، وأدرج مفاتيح التحليلات:

1utm_source, utm_medium, utm_campaign, utm_term, utm_content, fbclid, gclid

يؤدي هذا إلى دمج /pricing?utm_source=newsletter و/pricing?gclid=123 في مدخل واحد مخزّن مؤقتًا، مما يرفع نسبة الإصابة لديك بدلاً من تجزئتها عبر آلاف المفاتيح شبه المكررة.


كيفية التحقق من إصابة (HIT) أو إخفاق (MISS) التخزين المؤقت

لا تفترض أبدًا أن القاعدة تعمل – بل قِسها. تحمل كل استجابة تقدّمها Cloudflare ترويسة cf-cache-status. اطلب عنوان URL نفسه مرتين وراقب تغيّره:

1curl -sI https://example.com/ | grep -i cf-cache-status
2# First request:  cf-cache-status: MISS
3# Second request: cf-cache-status: HIT

القيم التي ستصادفها ومعنى كل منها:

cf-cache-statusالمعنىما يجب فعله
HITقُدّم مباشرةً من الحافةيعمل كما هو مقصود
MISSغير مخزّن بعد؛ جُلب من المصدر وخُزّن الآنأعد الطلب للتأكد من أنه يصبح HIT
DYNAMICحكمت Cloudflare بأنه غير قابل للتخزين المؤقتالقاعدة غير مطابِقة، أو المصدر يمنع التخزين المؤقت
BYPASSقاعدة أو تجاوز ملف تعريف ارتباط تخطّى التخزين المؤقتمتوقع في الطلبات المسجّلة الدخول
EXPIREDانقضت مدة TTL، وأُعيد التحقق مع المصدرطبيعي؛ ارفع Edge TTL إذا حدث ذلك كثيرًا
REVALIDATEDقديم، لكن تأكّد أنه ما يزال حديثًا عبر ETagطبيعي

إذا كنت ترى DYNAMIC فقط دائمًا، فإن قاعدة الأهلية لا تُطلَق. تأكد من اسم المضيف في التعبير، ثم تحقق من أن المصدر لا يرسل Cache-Control: private أو Set-Cookie على مستند HTML.


المزالق الشائعة واستكشاف الأخطاء وإصلاحها

  • وجود Set-Cookie في كل استجابة. لن تخزّن Cloudflare مؤقتًا استجابةً تضبط ملف تعريف ارتباط. كثيرًا ما تُرفق إضافات التحليلات ورموز CSRF وأدوات اختبار A/B واحدًا منها بمستند HTML. انقل تلك المنطقة إلى طلب غير متزامن، أو أزل الترويسة على المسارات القابلة للتخزين المؤقت.
  • BYPASS على الزوار المجهولين. يكون السبب دائمًا تقريبًا قاعدة تجاوز ملف تعريف ارتباط واسعة أكثر من اللازم – ملف تعريف ارتباط عام مثل _ga يطابق تعبيرك. اقصر التجاوز على ملفات تعريف ارتباط الجلسة الحقيقية فقط.
  • صفحات قديمة بعد النشر. إن Edge TTL تؤدي عملها؛ إنما نسيت ببساطة إجراء المسح. شغّل مسحًا مستهدفًا عند النشر بدلاً من تقصير مدة TTL إلى بضع ثوانٍ.
  • تجاهل ترويسات Vary. تنوّع Cloudflare تخزينها المؤقت على Accept-Encoding فقط؛ ولن تحتفظ بنسخ منفصلة لأي Vary: User-Agent أو Vary: Cookie اعتباطي. قدّم الترميز الخاص بالجهاز عبر CSS متجاوب أو عبر Worker بدلاً من الاعتماد على Vary.
  • ترك Development Mode قيد التشغيل. يتجاوز التخزين المؤقت لمدة ثلاث ساعات ويجعل كل استجابة تبدو بصمت غير قابلة للتخزين المؤقت. تأكد من إيقافه قبل الاختبار.

اعتبارات الإنتاج والمسح الآلي

بمجرد أن يتصرف مسار واحد بشكل صحيح، وسّع القاعدة لتشمل الموقع بالكامل خلال نافذة منخفضة الحركة وراقب نسبة الإصابة لديك في Caching → Overview – يستقر الموقع الثابت الصحي بارتياح فوق 90%.

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

1curl -X POST \
2  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
3  -H "Authorization: Bearer ${CF_API_TOKEN}" \
4  -H "Content-Type: application/json" \
5  --data '{"files":["https://example.com/pricing"]}'

استدعِ هذا من خطاف النشر لديك حتى ينشر تحديث المحرر خلال ثوانٍ بينما يبقى كل شيء آخر مخزّنًا مؤقتًا. بالنسبة إلى الكتالوجات الكبيرة، اجمع عناوين URL المترابطة خلف Cache Tag (Enterprise) أو امسح حسب البادئة، وفعّل Tiered Cache لرفع نسبة الإصابة العالمية عبر توجيه حالات الإخفاق عبر أصل إقليمي قبل أن تصل إلى مصدرك أصلاً.


تعاون مع استشارية Cloudflare مُعتمَدة في المملكة المتحدة

اتخاذ قرارات التخزين المؤقت هذه بشكل صحيح يحمي خوادم المصدر لديك ويسرّع تسليم الصفحات لكل زائر. تقدّم Mecanik خدمات احترافية لـتدقيق SEO التقني وقياس البنية التحتية عبر صفحة تطوير الويب لدينا. نحن متخصصون في تكاملات الحافة مع Symfony، وقواعد Cloudflare Cache Rules المخصصة، وعمليات النشر الأصلية على الحافة. تواصل معنا اليوم لجدولة ورشة التحديد التقني الخاصة بك.


الأسئلة الشائعة (FAQ)

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

كيف أخزّن صفحات HTML مؤقتًا دون تسريب بيانات المستخدمين؟ لتخزين HTML مؤقتًا بأمان، اضبط قاعدة Cache Rule بإجراء «Bypass Cache» يُطلَق عند وجود ملفات تعريف ارتباط جلسة أو مسؤول في ترويسات الطلب. يضمن هذا الإعداد أن يجلب مستخدمو البوابة المسجّلون المحتوى الديناميكي دائمًا من قاعدة بيانات المصدر.

ما الفرق بين Edge TTL وBrowser TTL؟ تحدد Edge TTL (Time-To-Live) المدة التي تخزّن خلالها خوادم CDN من Cloudflare محتواك قبل طلب نسخة جديدة من خادم المصدر لديك. في المقابل، تحدد Browser TTL المدة التي يحتفظ خلالها التخزين المؤقت المحلي لمتصفح الزائر بالملفات.

لماذا يؤثر التخزين المؤقت لسلاسل الاستعلام في أداء الموقع الإلكتروني؟ إذا لم تُوحَّد سلاسل الاستعلام (مثل وسوم تتبّع UTM)، فإن شبكة CDN تعامل كل صيغة كعنوان URL فريد، مما يولّد طلبات مكررة إلى خادم المصدر لديك. يمنع تكوين توحيد مفتاح التخزين المؤقت هذا التكرار في الزحف.

هل يمكن للتخزين المؤقت على الحافة تحسين درجات Core Web Vitals الخاصة بي؟ نعم، إن تقديم HTML وأصول الوسائط لديك مباشرةً من خوادم الحافة يقلل إلى أدنى حد أوقات Time-to-First-Byte (TTFB) وLargest Contentful Paint (LCP). وبالتالي، تحسّن استراتيجية التخزين المؤقت هذه مباشرةً ترتيب سرعة صفحتك على الجوال.