إذا سبق لك تثبيت إضافة تخزين مؤقت على WordPress، فأنت تعرف الروتين. تختار إضافة، تضبط عشرات الإعدادات، تأمل ألا تتعارض مع إضافاتك الأخرى، وتعقد أصابعك أملاً أن تعمل فعلاً. هناك طريقة أسرع وأنظف للحصول على نفس النتيجة، وتحدث بالكامل على مستوى السيرفر: FastCGI cache في Nginx.
يتيح FastCGI cache لـ Nginx تخزين صفحات HTML المُنشأة بالكامل وتقديمها مباشرة، متجاوزاً PHP وMySQL تماماً بالنسبة للزوار المتكررين. لا إضافة. لا تنفيذ PHP. فقط Nginx يسلّم ملفاً ثابتاً بسرعة الشبكة.
ما الذي يفعله FastCGI Cache فعلياً
عندما يزور أحدهم صفحة WordPress، هذا هو المسار المعتاد: يستقبل Nginx الطلب، يمرره إلى PHP-FPM، يحمّل PHP نواة WordPress، يشغّل القالب والإضافات، يستعلم قاعدة البيانات، يبني HTML، ثم يرسله. قد تستغرق هذه العملية بأكملها بسهولة من 200 إلى 800 ميلي ثانية في موقع عادي، وأكثر إذا كنت تستخدم أداة إنشاء صفحات ثقيلة أو WooCommerce.
يغيّر FastCGI cache هذا الأمر. في المرة الأولى التي يُطلب فيها صفحة، لا يزال Nginx يمر بكامل عملية PHP، لكنه يحفظ HTML الناتج على القرص. كل طلب لاحق لنفس الصفحة يُقدَّم مباشرة من ذلك الملف المخزّن مؤقتاً. لا PHP-FPM. لا استعلام لقاعدة بيانات. فقط Nginx يقرأ ملفاً ويرسله.
الفرق في الأداء كبير جداً. نلاحظ بانتظام انخفاض زمن الوصول للبايت الأول (TTFB) من 300-600 ميلي ثانية إلى 5-20 ميلي ثانية بعد تفعيل FastCGI cache وتسخينه. هذا ليس تحسناً هامشياً، بل تحسناً بمقدار أضعاف كاملة.
إعدادات Nginx الأساسية
هذه نسخة مبسطة من شكل الإعدادات. في كتلة http الخاصة بك، تحدد مسار التخزين المؤقت:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
بعد ذلك، داخل كتلة السيرفر أو موقع PHP، تخبر Nginx متى يستخدم التخزين المؤقت فعلياً:
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
متغير $skip_cache هذا هو الجزء المهم. لا تريد تخزين كل شيء بشكل عشوائي، بل تحتاج قواعد تتجاوز التخزين المؤقت للمستخدمين المسجلين، وطلبات POST، وصفحات الإدارة، وأي شيء يحتوي على سلسلة استعلام تشير إلى محتوى ديناميكي مثل صفحة السلة أو الدفع.
لماذا تهم قواعد التجاوز
هنا يخطئ الكثير من إعدادات FastCGI cache المُدارة ذاتياً. إذا خزّنت صفحة مستخدم مسجل الدخول، فقد يرى الزائر التالي شريط الإدارة أو محتوى شخصياً ليس له. إذا خزّنت صفحة سلة WooCommerce، قد يرى العملاء محتويات سلة شخص آخر. ضبط شروط التجاوز بشكل صحيح ليس اختيارياً، بل هو الفرق بين موقع سريع وموقع معطّل.
تتحقق كتلة التجاوز النموذجية من أشياء مثل كوكيز wordpress_logged_in، وكوكيز التعليقات، وأنماط URI معينة:
if ($http_cookie ~* "wordpress_logged_in") {
set $skip_cache 1;
}
if ($request_uri ~* "/wp-admin/|/cart/|/checkout/|/my-account/") {
set $skip_cache 1;
}
تنظيف التخزين المؤقت: الجزء الذي ينساه الجميع
التخزين المؤقت الثابت للصفحات مفيد فقط إذا بقي محدّثاً. إذا نشرت مقالاً جديداً أو حدّثت صفحة، يجب أن تختفي النسخة المخزّنة كي يحصل الزائر التالي على المحتوى المحدّث، وليس HTML قديماً من ساعة مضت.
يُعالج هذا عادة بوحدة تنظيف (مثل ngx_cache_purge) مرتبطة بخطافات الحفظ في WordPress، أو من خلال سكربت صغير يمسح مفاتيح تخزين مؤقت محددة عند تغيّر المحتوى. بدون هذا الجزء، سيتساءل المحررون باستمرار لماذا تغييراتهم "لا تظهر"، بينما الحقيقة أن الصفحة القديمة المخزّنة لا تزال تُقدَّم بسعادة.
هذا أحد الأسباب التي تجعل الإعداد المُدار يستحق التفكير فيه إذا كنت لا تريد بناء هذه العملية ومراقبتها بنفسك. في منصتنا، يُعالَج تخزين الصفحات وسلوك التنظيف تلقائياً عبر محسّن WordPress، بحيث ينظّف نشر مقال جديد إدخالات التخزين المؤقت الصحيحة دون أن يلمس أحد ملف إعدادات.
FastCGI Cache مقابل إضافات التخزين المؤقت
تقوم إضافات مثل WP Super Cache أو W3 Total Cache بشيء مشابه من الناحية المفاهيمية، حيث تُنشئ HTML ثابتاً وتقدّمه بدلاً من تشغيل PHP. لكنها تفعل ذلك من داخل WordPress، مما يعني أن PHP لا يزال يجب أن يبدأ التشغيل، ويحمّل الإضافة، ويتحقق مما إذا كانت هناك نسخة مخزّنة موجودة، ثم يقدّمها. هذا أسرع من التصيير الكامل، لكنه لا يزال أبطأ من عدم لمس PHP إطلاقاً.
يعمل FastCGI cache على مستوى أدنى، في خادم الويب نفسه. يقرر Nginx ما إذا كان سيقدّم من التخزين المؤقت قبل أن يتدخل PHP-FPM أصلاً. هذه هي الميزة الحقيقية: تُزيل طبقة كاملة من العبء بدلاً من مجرد اختصارها.
هناك أيضاً جانب الاستقرار. التخزين المؤقت القائم على الإضافات يضيف قطعة كود أخرى يمكن أن تتعارض مع قالبك، أو تتعطل أثناء تحديث، أو تتفاعل بشكل غريب مع إضافات أخرى. التخزين المؤقت على مستوى السيرفر يعيش خارج WordPress بالكامل، لذا لا يمكن لتحديث إضافة أن يعطّله عن طريق الخطأ.
أين لا تزال للإضافات دور
يتعامل FastCGI cache جيداً مع تخزين صفحات HTML كاملة، لكنه لا يمس أشياء مثل تخزين استعلامات قاعدة البيانات أو تخزين الكائنات. هنا يأتي دور شيء مثل Redis object cache، الذي يعمل جنباً إلى جنب مع تخزين الصفحات لتسريع جلسات المستخدمين المسجلين، وشاشات الإدارة، والاستعلامات الديناميكية التي لا يستطيع تخزين الصفحات مساعدتها. يعمل الاثنان معاً بشكل جيد بدلاً من أن يحل أحدهما محل الآخر.
قياس التأثير الحقيقي
لا تكتفِ بالثقة العمياء في الإعداد، تحقق منه. افحص ترويسات الاستجابة بحثاً عن مؤشر حالة التخزين المؤقت (تضيف العديد من الإعدادات ترويسة X-FastCGI-Cache تُظهر HIT أو MISS). شغّل اختبار حمل باستخدام أداة مثل ab أو wrk قبل وبعد تفعيل التخزين المؤقت، وراقب ارتفاع عدد الطلبات في الثانية.
في مواقع حقيقية قمنا بقياسها، صفحة رئيسية لـ WordPress كانت تتعامل مع 40-60 طلباً في الثانية تحت تنفيذ PHP يمكن أن تقفز إلى أكثر من 2000 طلب في الثانية بمجرد تقديمها من FastCGI cache. هذا النوع من الهامش الإضافي يعني أن ارتفاعاً مفاجئاً في الزيارات بسبب مقال منتشر أو حملة تسويقية لن يُسقط موقعك.
تناولنا استراتيجية التخزين المؤقت العامة بمزيد من التفصيل في كيفية إعداد Redis caching على سيرفرك دون كسر أي شيء، وإذا كنت لا تزال تعمل على جانب الإضافات لسرعة WordPress، فإن إصلاحات سرعة WordPress التي تستحق وقتك قراءة مكمّلة جيدة.
الخلاصة
يمنحك FastCGI cache في Nginx سرعة على مستوى السيرفر دون إضافات، يصعب على أي إضافة WordPress مجاراتها، لأنه يتجاوز PHP تماماً بالنسبة للطلبات المتكررة. المقابل هو أنه يتطلب إعداداً دقيقاً، خاصة فيما يتعلق بقواعد التجاوز والتنظيف، لتجنب تقديم محتوى قديم أو غير صحيح. إذا كنت مرتاحاً لتعديل إعدادات Nginx واختبارها بعناية، فهذا من أعلى التغييرات تأثيراً التي يمكنك إجراؤها لتحسين أداء nginx في موقع WordPress. وإذا كنت تفضّل عدم إدارة منطق التجاوز وخطافات التنظيف بنفسك، فهذا بالضبط النوع من الأمور التي تستحق تسليمها لاستضافة مُدارة قامت بضبطها مسبقاً.
