الاستضافة والأداء
كيف نجعل WordPress سريعًا: LiteSpeed Enterprise وLSCache وRedis مخصص لكل موقع
إن أسرع طلب WordPress هو الطلب الذي لا يعمل مطلقًا — إليكم كيف يستجيب مكدسنا لمعظم الزيارات من التخزين المؤقت قبل استدعاء PHP أو MySQL على الإطلاق، وما يعنيه ذلك لـ Core Web Vitals.
أسرع طلب هو الطلب الذي لا يعمل أبداً
إن طلب WordPress القياسي مكلف. ينقل خادم الويب المعالجة إلى PHP، ويقوم PHP بتشغيل WordPress، وتنفيذ الإضافات، وإرسال استعلامات إلى MySQL لعشرات المرات، وتجميع HTML، وبعد ذلك فقط يعيد إرسال البايتات. وفي المواقع ذات الزيارات العالية، تتكرر هذه العملية برمتها لكل زائر، وهنا يُستهلك كل وقت الوصول إلى أول بايت تقريبًا.
إجابتنا هي التأكد من أنه، في معظم الزيارات، لا يحدث أي من ذلك على الإطلاق. عبر المواقع التي نستضيفها — أكثر من 100,000 موقع PBN بالإضافة إلى مواقع WordPress المُدارة السائدة — يتم تقديم الغالبية العظمى من مشاهدات صفحات الواجهة الأمامية كصفحة كاملة معروضة مسبقًا مباشرة من التخزين المؤقت، دون استدعاء PHP أو لمس قاعدة البيانات. يتناول بقية هذا المنشور كيفية ترابط الطبقات التي تحقق ذلك، والمكان الذي تستحق فيه كل طبقة موقعها.
الإطار المهم هو أن هذه ليست ذاكرات تخزين مؤقت متنافسة تختارون من بينها. فالذاكرة المؤقتة للصفحة الكاملة، وذاكرة الكائنات المؤقتة، وحافة شبكة توصيل المحتوى (CDN) يلتقط كل منها فئة مختلفة من الطلبات، وتكمن القيمة الحقيقية في كيفية تسليم كل منها للأخرى.
LiteSpeed Enterprise + LSCache: طبقة الصفحة الكاملة
يعمل كل موقع على LiteSpeed Enterprise مع LSCache على مستوى الخادم. عندما تكون استجابة الواجهة الأمامية قابلة للتخزين المؤقت، يختمها خادم الويب بترويسات LiteSpeed cache-control والوسوم، ويقدم LiteSpeed الصفحة الكاملة مباشرة عند الطلب التالي — دون تشغيل أي عملية PHP، ودون إرسال أي استعلام MySQL. وتلك هي الرافعة الفردية الأكبر لـ TTFB في WordPress، لأنها تزيل إقلاع التطبيق بالكامل من المسار الحرج.
نظراً لأن LSCache يعمل مباشرة داخل خادم الويب وليس في مكون PHP إضافي، فإنه يبدأ العمل في مرحلة مبكرة من دورة حياة الطلب ويحتفظ بالصفحات بتنسيق يتيح للخادم إفراغها فورياً. ويعمل زاحف التخزين المؤقت على إبقاء الصفحات الشائعة جاهزة ونشطة، بحيث لا يتحمل الزائر الأول بعد عملية التفريغ عبء إعادة إنشاء الصفحة. والنتيجة هي الحصول على زمن استجابة أولي (TTFB) أقل بشكل ملحوظ وأكثر ثباتاً مقارنة بالتخزين المؤقت المعتمد على الإضافات فقط والمثبت على حزمة برمجية عامة، حيث يظل التخزين المؤقت قابعاً خلف PHP.
يأتي ملحق التخزين المؤقت المعتمد في مستودعاتنا مثبتًا مسبقًا ويتم تحديثه تلقائيًا على كل موقع، مما يربط WordPress بـ LSCache بشكل صحيح ومباشر فور التثبيت. على خادم أصل غير تابع لـ LiteSpeed، لا يُصدر الملحق رؤوس صفحات كاملة ويفسح المجال دون تدخل، بينما يستمر التخزين المؤقت للكائنات وقواعد الاستبعاد في أداء عملهما — وبذلك لا يُترك الموقع المنقول أبدًا في حالة معطلة أو نصف مهيأة.
الحفاظ على السرعة دون تقديم محتوى قديم: تقنية ESI والإفراغ التلقائي الذكي للمخزن المؤقت
يتضمن التخزين المؤقت الكامل والنشط للصفحات وضعين كلاسيكيين للفشل: تقديم صفحة شخص آخر لمستخدم مسجل دخوله، وتقديم صفحة كان ينبغي تغييرها لأي مستخدم. ويتم حل كلا الأمرين في طبقة التخزين المؤقت بدلاً من تقليل التخزين المؤقت.
تتيح لنا تقنية ESI (Edge Side Includes) تخزين الصفحة مؤقتًا مع فتح ثغرات للأجزاء التي يجب أن تظل مباشرة. في متجر WooCommerce، يتم تقديم صفحات الكتالوج والمنتجات والفئات كذاكرة تخزين مؤقت لصفحة كاملة للحصول على أسرع TTFB ممكن، بينما تقوم ESI بعرض أجزاء سلة التسوق، وإجماليات السلة المصغرة، وحالة الحساب لكل طلب. ويتم استبعاد صفحات سلة التسوق وإتمام الطلب وحسابي وأي صفحات nonce أو جلسات افتراضيًا. يرى المتسوقون دائمًا سلتهم الخاصة وعملية دفع تعمل بشكل سليم؛ بينما لا يزال الجميع يحصلون على واجهة المتجر من ذاكرة التخزين المؤقت.
تتم إدارة حداثة المحتوى عبر التطهير التلقائي الذكي. تنطلق خطافات التطهير تلقائيًا عند تغيير المحتوى أو المنتجات أو الأسعار أو الطلبات، مما يؤدي إلى تحديث الصفحات المخزنة مؤقتًا ذات الصلة على الفور بدلاً من الاعتماد على موقّت، كما يمكنكم أيضًا إجراء التطهير عند الطلب من لوحة التحكم أو من داخل WordPress. يعني التطهير المستند إلى الوسوم أن تعديل مقال واحد يؤدي إلى مسح هذا المقال وأرشيفاته فقط — وليس ذاكرة التخزين المؤقت بأكملها — وبذلك لا يؤدي أي تعديل فردي إلى إعادة تشغيل الموقع بالكامل من نقطة الصفر.
التخزين المؤقت للكائنات عبر Redis لكل موقع: لما لا يمكن أن يكون صفحة كاملة
لا يمكن أن يكون كل طلب صفحة كاملة ثابتة. فالجلسات التي تم تسجيل الدخول إليها، ولوحة تحكم WordPress، وسلات WooCommerce، والبحث، والأجزاء الديناميكية المتبقية من ESI، كلها يجب أن تشغّل PHP. بالنسبة لهؤلاء، يتحول الهدف من «تخطي التطبيق» إلى «تخطي قاعدة البيانات».
يحصل كل موقع على ذاكرة تخزين مؤقت مخصصة لكائنات Redis. يقوم WordPress بتخزين نتائج قراءات قاعدة البيانات المتكررة مؤقتًا — الخيارات، والبيانات المؤقتة (transients)، وعمليات البحث عن المنشورات والمصطلحات، وبيانات منتجات وجلسات WooCommerce — في الذاكرة، وبذلك لا يتم تنفيذ نفس الاستعلام في MySQL مع كل زيارة. يظهر التأثير بأوضح صورة تمامًا حيث لا يمكن لذاكرة التخزين المؤقت للصفحة الكاملة المساعدة: لوحات تحكم أسرع، وعربات تسوق أسرع، وحمل أقل بكثير على قاعدة البيانات أثناء حركة المرور العالية.
ذاكرة التخزين المؤقت للكائنات مخصصة لكل موقع وليست مشتركة، وهو أمر مهم لكل من الأداء والعزل. وبالاقتران مع ميزة تقييد قاعدة البيانات لكل موقع، لا يمكن للاستعلامات الثقيلة أو الرديئة لأحد المواقع أن تحرم جيرانه من موارد قاعدة البيانات. يمكنك قراءة المزيد حول كيفية تكامل الإعداد متعدد الطبقات بأكمله على صفحة ميزات التخزين المؤقت، وحول الحدود بين المستأجرين ضمن قسم العزل.
الحافة ووسيلة النقل التي تقع تحتها
ذاكرة التخزين المؤقت التي تعيش على الخادم الأصلي لا تزال مضطرة لعبور الشبكة. وأمام الخادم تقع حافة شبكة توصيل المحتوى (CDN)، بحيث يتم تقديم الأصول الثابتة والصفحات القابلة للتخزين المؤقت من نقطة تواجد قريبة من الزائر، ويظل الخادم الأصلي هادئاً حتى في ظل أعباء العمل المرتفعة. وبالنسبة لخط الاستضافة الخالي من البصمات (footprint-free) الخاص بنا، فإن الحافة نفسها عبارة عن مجمع شبكات توصيل محتوى متعدد (multi-CDN) موزع عبر عدة مزودين، وهو ما يخدم هدف تجنب البصمات إلى جانب هدف الأداء؛ أما على WordPress القياسي، فهي مجرد طبقة سريعة ومهندمة تحافظ على خمول الخوادم الأصلية.
في جوهر الأمر، لم يتم التهاون في الأساسيات. تعمل المواقع على سعة تخزين NVMe مع بروتوكول HTTP/3، بحيث تصل وحدات البايت التي ترسلها ذاكرة التخزين المؤقت عبر وسيلة نقل حديثة ومتعددة الإرسال، مع وجود سعة تخزين سريعة وراء أي حالة عدم تطابق في ذاكرة التخزين المؤقت (cache miss). لا تُعد أيّ من هذه الطبقات ميزة إضافية مدفوعة: فكل من LiteSpeed وLSCache وRedis لكل موقع وNVMe وHTTP/3 هي المعيار الأساسي في كل خطة، وليست ترقية باهظة الثمن.
ما الذي يُحدث فارقاً حقيقياً في Core Web Vitals
يجدر بنا أن نكون دقيقين، لأن خدمات الاستضافة غالبًا ما يُبالغ في الترويج لها بناءً على Core Web Vitals. يُعد TTFB الجزء من المعادلة الذي يتحكم فيه الخادم، ومجموعة التخزين المؤقت الموضحة أعلاه هي ما يعمل على خفضه — حيث إن صفحة كاملة مخزنة مؤقتًا ومقدمة عبر HTTP/3 من الحافة تمثل أدنى مستوى يمكن أن يصل إليه TTFB تقريبًا. ونظرًا لأن TTFB هو الحافة الأمامية لـ Largest Contentful Paint، فإن نقطة الأصل السريعة تمنح كل مقياس لاحق ميزة البداية المبكرة التي لا يمكنه الحصول عليها بأي طريقة أخرى.
لكن مقاييس LCP وCLS وINP تُحسم في الغالب داخل المتصفح بواسطة الصفحة نفسها: صورة رئيسية (hero image) غير مُحسَّنة، وملفات CSS وJavaScript التي تحظر العرض، وتخطيط يتبدل مع تحميل الخطوط والإعلانات، وأعباء عمل ثقيلة على المسار الرئيسي (main-thread) ناتجة عن الإضافات. لن يُجدي أي قدر من التخزين المؤقت على الخادم في معالجة صورة رئيسية بحجم 2 ميغابايت أو قالب يرسل ميغابايتات من ملفات JavaScript. إن الاستضافة الصادقة تجعل مساهمة الخادم سريعة ومستقرة تمامًا، ثم يقع العبء بعد ذلك على الموقع للحفاظ على خفة أداء الواجهة الأمامية.
هذا التقسيم للعمل هو النموذج الفكري المفيد. نحن نضمن وصول الطلب إلى المتصفح بسرعة واستمراره سريعاً تحت وطأة حركة المرور؛ وأنتم تحافظون على حمولة البيانات صغيرة ومستقرة. وحيث يلتقي الجانبان — إحماء التخزين المؤقت، والتسليم عبر الحافة، والحفاظ على استجابة قاعدة البيانات حتى لا تتعطل الصفحات الديناميكية — يتم بالضبط ضبط بنيتنا التقنية، وهذا ما يجعل WordPress المدار على هذه المنصة أسرع من نفس الموقع على استضافة عامة.
الأسئلة الشائعة
هل ما زلت بحاجة إلى إضافة تخزين مؤقت مثل WP Rocket؟
لا. تتم معالجة التخزين المؤقت الكامل للصفحة على مستوى خادم الويب بواسطة LSCache الخاص بـ LiteSpeed، وتعمل إضافة التخزين المؤقت الخاصة بنا — المثبتة مسبقًا والمحدّثة تلقائيًا — على ربط WordPress بها بشكل صحيح، مع وجود ذاكرة تخزين مؤقت للكائنات مستندة إلى Redis لكل موقع خلفها. إن تثبيت إضافة ثانية للتخزين المؤقت الكامل للصفحة فوقها يتعارض عادةً مع التخزين المؤقت على مستوى الخادم بدلاً من المساعدة، لذلك فهو غير مطلوب ولا يُنصح به.
هل سيؤدي التخزين المؤقت إلى تعطيل سلة تسوق WooCommerce أو الصفحات التي تم تسجيل الدخول إليها؟
لا. يتم استبعاد صفحات سلة التسوق، وإتمام الطلب، وحسابي (my-account)، وأي صفحات تتضمن رموز nonce أو جلسات (session) من التخزين المؤقت افتراضيًا، وتحافظ تقنية ESI على تحديث أجزاء السلة والإجماليات في الصفحات المخزنة مؤقتًا. يرى المتسوقون دائمًا سلتهم الخاصة وصفحة إتمام طلب تعمل بشكل سليم، بينما يستمر المتجر في التحميل من التخزين المؤقت.
كيف تظل ذاكرة التخزين المؤقت مُحدّثة عندما أقوم بالنشر أو التعديل؟
يعمل التطهير التلقائي الذكي عند خطافات WordPress ذات الصلة، لذا فإن نشر المحتوى أو تعديله أو تغيير منتج أو سعر أو طلب يؤدي إلى مسح الصفحات المتأثرة وأرشيفاتها فقط — وليس ذاكرة التخزين المؤقت بأكملها — ويقوم برنامج الزحف بتجهيزها مرة أخرى. يمكنك أيضاً إجراء التطهير عند الطلب من لوحة التحكم أو من داخل WordPress.
هل يمكن للاستضافة وحدها أن تمنحني Core Web Vitals مثالية؟
يمنحكم ذلك أفضل TTFB ممكن، وهو ما يمثل مساهمة الخادم وانطلاقة قوية لـ Largest Contentful Paint. ولكن يتم تحديد LCP وCLS وINP إلى حد كبير بواسطة الصفحة نفسها — أحجام الصور، والموارد التي تحظر العرض، واستقرار التخطيط، وجافا سكريبت على مؤشر الترابط الرئيسي. تجعل بنيتنا مساهمة الخادم سريعة ومتسقة؛ والحفاظ على حمولة الواجهة الأمامية خفيفة هو ما يسد الفجوة المتبقية.
ذات صلة
جربه مجاناً لمدة 14 يوماً
أنشئ مواقعك الأولى مجانًا لمدة 14 يومًا — دون الحاجة لبطاقة. هل تنقل شبكة حالية؟ عمليات الترحيل مجانية وبلا حدود.
ابدأ مجانًا