الاستضافة والأداء
كيف نجعل WordPress سريعاً: LiteSpeed Enterprise و LSCache و Redis لكل موقع
أسرع طلب WordPress هو الطلب الذي لا يتم تنزيله أبداً — إليك كيف تلبي بنيتنا معظم الزيارات من ذاكرة التخزين المؤقت قبل استدعاء PHP أو MySQL نهائياً، وماذا يعني ذلك بالنسبة لـ Core Web Vitals.
أسرع طلب هو الطلب الذي لا يُنفذ أبداً
طلبات WordPress القياسية مكلفة للغاية. يقدم خادم الويب الطلب إلى PHP، وتقوم PHP بتهيئة WordPress، وتشغيل الإضافات، والاستعلام من MySQL بضع عشرات من المرات، وتجميع HTML، وبعد ذلك فقط ترسل البيانات في النهاية. وفي المواقع ذات الزيارات العالية، تتكرر هذه العملية بأكملها لكل زائر، وهي السبب وراء استهلاك معظم وقت الوصول إلى أول بايت (time-to-first-byte) لديك.
الحل الذي نقدمه هو ضمان ألا يحدث أي من ذلك في معظم الزيارات. عبر المواقع التي نستضيفها — أكثر من 100,000 موقع من شبكات PBN بالإضافة إلى مواقع WordPress المُدارة الرئيسية — تتم تلبية الغالبية العظمى من مشاهدات صفحات الواجهة الأمامية كصفحة كاملة مُجهّزة مسبقاً مباشرة من ذاكرة التخزين المؤقت، دون استدعاء PHP أو لمس قاعدة البيانات. يدور ما تبقى من هذا المنشور حول كيفية تكامل الطبقات التي تحقق ذلك، والمكان الذي تستحق فيه كل طبقة مكانتها.
الجانب الهام هو أن هذه ليست خيارات متنافسة للاختيار من بينها. فالتخزين المؤقت للصفحة الكاملة، والتخزين المؤقت للكائنات، وشبكة توصيل المحتوى (CDN) تتعامل كل منها مع فئة مختلفة من الطلبات، وتكمن القيمة الحقيقية في كيفية تكاملها وتسليم المهام فيما بينها.
LiteSpeed Enterprise + LSCache: طبقة الصفحة الكاملة
يعمل كل موقع على LiteSpeed Enterprise مع LSCache على مستوى الخادم. عندما تكون استجابة الواجهة الأمامية قابلة للتخزين المؤقت، يضع خادم الويب عليها ترويسات LiteSpeed للتحكم في التخزين المؤقت والعلامات، ويقدم LiteSpeed الصفحة الكاملة مباشرة في الزيارة التالية — دون تشغيل أي عملية PHP، ودون إجراء أي استعلام MySQL. يُعد ذلك أثر عامل مؤقت في تقليل TTFB لمواقع WordPress، لأنه يزيل تمهيد التطبيق بالكامل من المسار النشط.
نظرًا لأن LSCache يعمل داخل خادم الويب بدلاً من المكون الإضافي لـ PHP، فهو يبدأ العمل في وقت مبكر من دورة حياة الطلب ويحتفظ بالصفحات في نموذج يمكن للخادم تفريغه على الفور. يحافظ زاحف التخزين المؤقت على الصفحات الشائعة دافئة، لذا فإن الزائر الأول بعد عملية الحذف ليس هو من يتحمل تكلفة إعادة إنشاء الصفحة. والنتيجة هي TTFB أقل بشكل ملحوظ وأكثر اتساقًا مقارنةً بالتخزين المؤقت المعتمد على المكون الإضافي فقط والمثبت على حزمة عامة، حيث يظل ذاكرة التخزين المؤقت خلف PHP.
يأتي المكون الإضافي للتخزين المؤقت بمستوى المستودعات الخاص بنا مثبتاً مسبقاً ومحدّثاً تلقائياً على كل موقع، ليقوم بربط WordPress بـ LSCache بشكل صحيح وجاهز للاستخدام الفوري. أما على خادم مصدر غير تابع لـ LiteSpeed، فهو ببساطة لا يصدر أي رؤوس صفحات كاملة ويتنحي جانباً، بينما يستمر التخزين المؤقت للأشياء وقواعد الاستثناء في أداء عمله - بحيث لا يترك أي موقع تم نقله أبداً في حالة معطلة أو مُكوّنة بشكل جزئي.
الحفاظ على السرعة دون تقديم محتوى قديم: ESI والإخلاء التلقائي الذكي
التخزين المؤقت الكامل للصفحات بطريقة عدوانية له نمطا فشل تقليديان: عرض صفحة شخص آخر لمستخدم مسجل الدخول، وعرض صفحة لأي شخص كان يجب أن تتغير. يتم حل كلتا المشكلتين في طبقة التخزين المؤقت بدلاً من تقليل التخزين المؤقت.
تتيح تقنية ESI (Edge Side Includes) تخزين الصفحة مؤقتاً مع ترك أجزاء مخصصة للأجزاء التي يجب أن تظل نشطة. في متجر يعمل بنظام WooCommerce، يتم تقديم صفحات الكتالوج والمنتجات والفئات كذاكرة تخزين مؤقت للصفحة بأكملها لضمان أسرع وقت استجابة ممكن للـ TTFB، بينما يقوم ESI بعرض أجزاء سلة التسوق، وإجمالي السلة المصغرة، وحالة الحساب لكل طلب. يتم استثناء سلة التسوق، والدفع، وحسابي، وأي صفحات تعتمد على الرموز الفريدة (nonces) أو الجلسات افتراضياً. يرى المتسوقون دائماً سلات التسوق الخاصة بهم وصفحة دفع تعمل بشكل صحيح، بينما يستمتع الجميع بمتجر سريع من الذاكرة المؤقتة.
يتم التعامل مع نضارة المحتوى من خلال الحذف التلقائي الذكي. تُطلق خطوات الحذف تلقائياً عند تغير المحتوى أو المنتجات أو الأسعار أو الطلبات، بحيث يتم تحديث صفحات التخزين المؤقت ذات الصلة على الفور بدلاً من الاعتماد على مؤقت، كما يمكنك إجراء الحذف حسب الطلب من لوحة التحكم أو من داخل WordPress. يعني الحذف القائم على العلامات أن تعديل منشور واحد يؤدي إلى مسح ذلك المنشور وأرشيفاته - وليس ذاكرة التخزين المؤقت بأكملها - بحيث لا يؤدي التعديل الفردي إلى إعادة تشغيل الموقع بالكامل على البارد.
التخزين المؤقت لكائنات Redis لكل موقع: لما لا يمكن أن يكون صفحة كاملة
لا يمكن أن تكون كل طلبية صفحة ثابتة بالكامل. إن الجلسات التي تسجل دخول المستخدمين، ولوحة تحكم WordPress، وسلال تسوق WooCommerce، والبحث، والأجزاء الديناميكية التي تتركها ESI لتعمل، كلها تتطلب تشغيل PHP. وبالنسبة لهذه الحالات، يتحول الهدف من «تخطي التطبيق» إلى «تخطي قاعدة البيانات».
يحصل كل موقع على ذاكرة تخزين مؤقت مستقلة من نوع Redis. يقوم WordPress بتخزين نتائج عمليات قراءة قاعدة البيانات المتكررة — الخيارات، والمتغيرات المؤقتة، وعمليات البحث عن المنشورات والمصطلحات، وبيانات منتجات وجلسات WooCommerce — في الذاكرة، بحيث لا يتم تشغيل نفس الاستعلام مقابل MySQL مع كل زيارة. ويكون هذا التأثير أكثر وضوحاً في الأماكن التي لا يستطيع فيها التخزين المؤقت للصفحات الكاملة تقديم المساعدة: لوحات تحكم أسرع، وسلات تسوق أسرع، وضغط أقل بكثير على قاعدة البيانات أثناء حركة المرور.
ذاكرة الكاش الخاصة بالكائنات تكون مخصصة لكل موقع على حدة وليست مشتركة، وهو أمر مهم لكل من الأداء والعزل. إلى جانب تقييد قاعدة البيانات لكل موقع، لا يمكن للاستعلامات الثقيلة أو سيئة الكتابة لموقع واحد أن تستنزف قاعدة البيانات عن المواقع المجاورة لها. يمكنك قراءة المزيد حول كيفية تكامل إعدادات الطبقات المتعددة معاً على صفحة ميزة التخزين المؤقت الخاصة بنا، وحول الحدود بين المستأجرين ضمن العزل.
الحافة ووسيلة النقل الأساسية لها
لا يزال يتعين على ذاكرة التخزين المؤقت الموجودة على خادم المصدر عبور الشبكة. وتقع حافة شبكة CDN أمام الخادم، بحيث يتم تقديم الأصول الثابتة والصفحات القابلة للتخزين المؤقت من نقطة تواجد قريبة من الزائر، ويبقى خادم المصدر هادئًا حتى تحت الضغط. بالنسبة لخط الاستضافة الخالي من الأثر Footprint-Free الخاص بنا، فإن الحافة نفسها عبارة عن مجمع شبكات CDN متعددة ممتد عبر عدة مزودين، وهو ما يخدم هدفًا متعلقًا بالأثر الرقمي بالإضافة إلى هدف الأداء؛ أما في استضافة WordPress الاعتيادية، فهو مجرد طبقة سريعة وحسنة السلوك تحافظ على خمول خوادم المصدر.
تحت السطح، لم يتم التهاون في الأساسات. تعمل المواقع على وحدات تخزين NVMe مع بروتوكول HTTP/3، لذا فإن البايضات التي يرسلها التخزين المؤقت تصل عبر وسيلة نقل حديثة ومتعددة الإرسال مع تخزين سريع خلف أي فشل في التخزين المؤقت. ليس أي من هذه الطبقات إضافة اختيارية: فكل من LiteSpeed و LSCache و Redis لكل موقع و NVMe و HTTP/3 تشكل الأساس في كل خطة، وليست ضمن باقة ترقية مدفوعة.
ما الذي يحرك فعلياً مؤشرات أداء الويب الأساسية Core Web Vitals
من الجدير أن نكون دقيقين، لأن الاستضافة غالباً ما تُباع بوعود مبالغ فيها بشأن Core Web Vitals. يُعد مؤشر TTFB هو الجزء من المعادلة الذي يخص الخادم، بينما تقوم طبقة التخزين المؤقت الموجودة فوقه بتقليصه؛ فالصفحة الكاملة المخزنة مؤقتاً والتي يتم تقديمها عبر بروتوكول HTTP/3 من الطرفية (edge) تكون قريبة من أدنى مستوى يمكن أن يصل إليه مؤشر TTFB. ونظراً لأن TTFB يمثل البداية الأساسية لمؤشر Largest Contentful Paint، فإن الخادم الأصلي السريع يمنح كل مقياس لاحق انطلاقة مبكرة لا يمكنه الحصول عليها بطريقة أخرى.
لكن مؤشرات LCP و CLS و INP تُحسم غالباً داخل المتصفح، بواسطة الصفحة نفسها: صورة رئيسية غير مُحسّنة، وCSS وJavaScript تُعيطلان العرض، وتخطيط يتحرك مع تحميل الخطوط والإعلانات، وعبء عمل ثقيل على الخيط الرئيسي من الإضافات. فمهما بلغ التخزين المؤقت للخادم فإنه لن يُصلح صورة رئيسية بحجم 2 ميجابايت أو قالباً ينقل ميجابايتات من JavaScript. الاستضافة النزيهة تجعل مساهمة الخادم مجانية وفعالة باستمرار، وحينها يقع عبء الحفاظ على الواجهة الأمامية خفيفة على عاتق الموقع نفسه.
إن تقسيم العمل هذا هو النموذج الذهني المفيد. نحن نضمن وصول الطلب إلى المتصفح بسرعة وبقائه سريعاً تحت الضغط المروري؛ وتحافظ أنت على الحِمل الصغير والمستقرار. وحيث يلتقي الاثنين — تسخين ذاكرة التخزين المؤقت، والتسليم عبر الحافة، والحفاظ على استجابة قاعدة البيانات حتى لا تتوقف الصفحات الديناميكية — هو بالتحديد المكان الذي تم ضبط بنيتنا تحته، وهو ما يجعل WordPress المُدار على هذه المنصة أسرع من نفس الموقع على مضيف عام.
الأسئلة الشائعة
هل ما زلت بحاجة إلى إضافة تخزين مؤقت مثل WP Rocket؟
لا. تتم إدارة التخزين المؤقت للصفحة بالكامل على خادم الويب بواسطة LSCache من LiteSpeed، بينما يقوم المكون الإضافي الخاص بنا للتخزين المؤقت — المثبت مسبقاً والمحدث تلقائياً — بربط WordPress به بشكل صحيح، مع وجود ذاكرة تخزين مؤقت لكائنات Redis لكل موقع في الخلفية. إن إضافة مكون إضافي ثانٍ للتخزين المؤقت للصفحة بالكامل يتعارض عادةً مع ذاكرة التخزين المؤقت على مستوى الخادم بدلاً من المساعدة، لذا فهو غير مطلوب ولا يُنصح به.
هل يؤدي التخزين المؤقت إلى تعطيل سلة التسوق WooCommerce الخاصة بي أو الصفحات التي يتم تسجيل الدخول إليها؟
لا يتم تضمين سلة التسوق، وعملية الدفع، وحسابي، وأي صفحات لرموز الأمان (nonce) أو الجلسات في التخزين المؤقت افتراضياً، بينما يحافظ تقنية ESI على تحديث جزء سلة التسوق والإجماليات في الصفحات المخزنة مؤقتاً. يرى المتسوقون دائماً سلة التسوق الخاصة بهم وعملية دفع تعمل بشكل صحيح بينما يستمر المتجر في التحميل من الذاكرة المؤقتة.
كيف يبقى التخزين المؤقت محدثاً عند النشر أو التعديل؟
تعمل ميزة الحذف التلقائي الذكي على خطافات WordPress ذات الصلة، لذا فإن نشر المحتوى أو تعديله، أو تغيير منتج أو سعر أو طلب، يؤدي إلى مسح الصفحات المتأثرة وحدها وأرشيفاتها - وليس ذاكرة التخزين المؤقت بأكملها - ويقوم زحّاف بإعادة تسخينها. يمكنك أيضاً الحذف عند الطلب من لوحة التحكم أو من داخل WordPress.
هل يمكن للاستضافة وحدها أن تمنحني Core Web Vitals مثالية؟
يمنحك أفضل وقت استجابة ممكن للخادم (TTFB)، وهو نصيب الخادم وبداية قوية لمؤشر أكبر محتوى مرئي (Largest Contentful Paint). لكن مؤشرات LCP وCLS وINP تُحسم إلى حد كبير بواسطة الصفحة نفسها — أحجام الصور، والأصول التي تعيق العرض، واستقرار تخطيط الصفحة، وجافا سكريبت الخاصة بالخيط الرئيسي. إن بنيتنا التقنية تجعل مساهمة الخادم سريعة وثابتة؛ أما الحفاظ على حمولة الواجهة الأمامية خفيفة فهو ما يسد ما تبقى من الفجوة.
ذات صلة
جربه مجاناً لمدة 14 يوماً
أنشئ مواقعك الأولى مجاناً لمدة 14 يوماً — دون بطاقة ائتمان. هل تنقل شبكة موجودة؟ هجرتنا الأولى على حسابنا.
ابدأ مجاناً