استضافة WordPress المحسّنة: الدليل التقني

صفحة WordPress لا تجد نسخة جاهزة منها تمر بثلاث مراحل قبل أن يصل أول بايت إلى الزائر: يحمّل PHP مئات الملفات، وتُرسل عشرات الاستعلامات إلى قاعدة البيانات، ثم يُبنى HTML من الصفر. في متجر WooCommerce متوسط يستغرق ذلك بين 400 و1,500 ميلي ثانية بحسب القالب والإضافات، بينما تخرج الصفحة نفسها من التخزين المؤقت في أقل من 50 ميلي ثانية. لهذا لا تعني عبارة «استضافة محسّنة لـ WordPress» شيئاً ما لم تُترجم إلى طبقات تستطيع أن تسمّيها وتقيسها: خادم ويب يخدم الصفحات المخزنة دون PHP، وإصدار PHP حديث مع OPcache، وتخزين مؤقت للكائنات في الذاكرة، وقاعدة بيانات نظيفة، ونسخ احتياطي جرّبت استعادته.

01رحلة الطلب: أين يذهب الوقت

يصل الطلب إلى خادم الويب أولاً. إن وجد نسخة جاهزة من الصفحة أرسلها فوراً، وإلا سلّمه إلى عملية PHP تنفّذ WordPress وقالبه وإضافاته، وتسأل قاعدة البيانات عن المحتوى والإعدادات، ثم تعيد HTML. لكل مرحلة مخزنها المؤقت، والاستضافة المحسّنة هي التي تفعّلها كلها وتضبطها معاً:

القاعدة العملية: كل طلب يصل إلى PHP مكلف، وكل طلب يُخدم قبله رخيص. هدفك أن تُخدم أغلب الزيارات من الطبقة الأولى، وأن يبقى ما لا يُخزَّن، كالسلة ولوحة التحكم وصفحات الزوار المسجلين، سريعاً بفضل الطبقات التالية.

02الخادم وPHP: ما قبل أول بايت

المقياس الذي يكشف جودة الخادم هو زمن أول بايت (TTFB). تعدّ Google قيمة 800 ميلي ثانية أو أقل جيدة، لكن صفحة مخزنة على خادم قريب من زوارك يجب أن تنزل دون 200 ميلي ثانية. قِسه من جهازك، وتحقق في الوقت نفسه هل خرجت الصفحة من التخزين المؤقت:

# شغّله مرتين: الطلب الأول قد يبني الصفحة، والثاني يجب أن يأتي من التخزين المؤقتcurl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://bayt-aldishdasha.com/# هل خرجت الصفحة من LSCache؟ القيمة hit أو misscurl -sI https://bayt-aldishdasha.com/ | grep -i x-litespeed-cache

وTTFB ليس من مقاييس Core Web Vitals الثلاثة، لكنه يسبق أهمها: LCP، أي ظهور أكبر عنصر في الصفحة، والجيد فيه 2.5 ثانية أو أقل، لا يبدأ قبل أول بايت. أما INP (الاستجابة للتفاعل، والجيد 200 ميلي ثانية أو أقل) وCLS (ثبات التخطيط، 0.1 أو أقل) فيحددهما القالب والسكربتات في المتصفح، ولن تصلحهما أي استضافة.

LiteSpeed وLSCache

خادم LiteSpeed يفهم إعدادات Apache وملف .htaccess، فلا تعدّل موقعك حين تنتقل إليه. وميزته الحاسمة لـ WordPress أن التخزين المؤقت للصفحات جزء من الخادم نفسه: الصفحة المخزنة تُرسل دون تشغيل أي عملية PHP. تتحكم به من إضافة LiteSpeed Cache داخل WordPress، فتمسح النسخ المخزنة تلقائياً حين تنشر أو تعدّل، وتستثني صفحات السلة والدفع والحساب في WooCommerce.

إصدار PHP وعملياته

كل إصدار رئيسي من PHP 8 أسرع من سابقه. والإصدارات الأقدم من 8.2 خرجت من الدعم الأمني الرسمي، و8.2 نفسه ينتهي دعمه في نهاية 2026. اختر 8.3 أو 8.4، وجرّب الانتقال على نسخة تجريبية قبل الموقع الحي، فالإضافات القديمة هي ما ينكسر عادة، لا WordPress نفسه.

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

OPcache

من دون OPcache يقرأ PHP ملفات WordPress ويترجمها في كل طلب، وهي مئات الملفات في موقع بإضافات معتادة. مع OPcache تبقى النسخة المترجمة في الذاكرة. القيم المعقولة لموقع WordPress: بين 128 و256 ميغابايت لذاكرة OPcache، وحد للملفات لا يقل عن 10,000، ونسبة إصابة فوق 99%. إن أظهر تقرير OPcache أن الذاكرة ممتلئة أو أن المخزن يُعاد تشغيله، فارفع الحدين أو اطلب ذلك من الدعم الفني.

03التخزين المؤقت للكائنات وقاعدة البيانات

التخزين المؤقت للصفحات لا يفيد الزائر المسجل، ولا صفحة السلة، ولا لوحة التحكم. هنا يأتي دور التخزين المؤقت للكائنات: يحفظ WordPress نتائج استعلاماته وإعداداته في Redis بدل أن يكررها مع كل طلب. من دونه يعيش مخزن WordPress الداخلي طوال طلب واحد ثم يُمحى. فعّل Redis من إعدادات إضافة LiteSpeed Cache أو من إضافة Redis Object Cache، ثم تحقق من صفحة «صحة الموقع» في WordPress أن التخزين الدائم للكائنات يعمل. وMemcached بديل أبسط يؤدي الغرض نفسه، لكن Redis أوسع انتشاراً اليوم.

أما قاعدة البيانات فثلاث مشكلات تتكرر في المواقع القديمة: خيارات تُحمَّل تلقائياً مع كل طلب حتى تبلغ عدة ميغابايت، ومراجعات مقالات بلا حد، وبيانات مؤقتة (transients) انتهت ولم تُحذف. تنبّهك «صحة الموقع» إن تجاوزت الخيارات المحمّلة تلقائياً 800 كيلوبايت. هذه أوامر تكشف ذلك وتنظّفه:

cd ~/public_html# حجم الخيارات التي تُحمَّل مع كل طلب، بالكيلوبايتwp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb FROM $(wp db prefix)options WHERE autoload IN ('yes','on','auto-on','auto');"# حذف البيانات المؤقتة المنتهيةwp transient delete --expired# الإبقاء على 10 مراجعات لكل مقال من الآن فصاعداًwp config set WP_POST_REVISIONS 10 --raw# إعادة بناء الجداول: خذ نسخة احتياطية أولاً ونفّذه خارج ساعات الذروةwp db optimize

وهذه أعراض تدلك على الطبقة الناقصة:

المشكلةTTFB فوق ثانية في كل زيارة، والترويسة x-litespeed-cache تقول miss دائماً

الحلالتخزين المؤقت للصفحات غير مفعّل، أو تتجاوزه إضافة تضع ملف تعريف ارتباط في كل زيارة. فعّل LSCache، وابحث عن الإضافة المسببة بتعطيل الإضافات واحدة تلو الأخرى على النسخة التجريبية.

المشكلةالواجهة سريعة، لكن لوحة التحكم والسلة بطيئتان

الحلهذه طلبات لا تُخزَّن صفحاتها. فعّل Redis للكائنات، وقِس حجم الخيارات المحمّلة تلقائياً، واستخدم PHP X-Ray لتعرف أي إضافة تستهلك الوقت.

المشكلةالمقالات المجدولة تُنشر متأخرة أو لا تُنشر

الحلالمهام المجدولة في WordPress تنتظر زيارة تصل إلى PHP. شغّلها من مجدول النظام كما في القسم التالي.

المشكلةالتعديلات لا تظهر للزوار بعد الحفظ

الحلنسخة قديمة في التخزين المؤقت. امسح LSCache للصفحة أو للموقع، وتأكد أن إضافة واحدة فقط تدير التخزين المؤقت للصفحات.

04WP-CLI: صيانة لا تمر بالمتصفح

WP-CLI أداة سطر الأوامر الرسمية لـ WordPress، تعمل عبر SSH وتنجز في ثوانٍ ما يأخذ دقائق من لوحة التحكم. هذا تسلسل تحديث آمن: نسخة من قاعدة البيانات، ثم النواة، ثم الإضافات والقوالب، ثم مقارنة الملفات بأصلها:

cd ~/public_html# نسخة من قاعدة البيانات خارج مجلد الموقع قبل أي تحديثmkdir -p ~/backups && wp db export ~/backups/before-update-$(date +%F).sqlwp core update && wp core update-dbwp plugin update --allwp theme update --all# مقارنة ملفات النواة والإضافات بالنسخ المنشورة على wordpress.orgwp core verify-checksumswp plugin verify-checksums --all

وحين تنقل الموقع من نطاق تجريبي إلى نطاقه الحقيقي، لا تستبدل الروابط بمحرر نصوص داخل ملف SQL. يحفظ WordPress بعض البيانات بصيغة مُسلسلة (serialized) تسجّل طول كل نص، والاستبدال الأعمى يكسرها. الأمر search-replace يعالج ذلك:

cd ~/public_html# معاينة دون أي تغييرwp search-replace 'https://staging.bayt-aldishdasha.com' 'https://bayt-aldishdasha.com' --all-tables --skip-columns=guid --dry-run# التنفيذ بعد مراجعة المعاينةwp search-replace 'https://staging.bayt-aldishdasha.com' 'https://bayt-aldishdasha.com' --all-tables --skip-columns=guid# مسح التخزين المؤقت للكائنات ثم صفحات LSCachewp cache flushwp litespeed-purge all

والمهام المجدولة في WordPress (WP-Cron) لا تعمل بساعة، بل تنطلق مع الزيارات التي تصل إلى PHP. ومع تخزين مؤقت جيد تقل هذه الزيارات، فتتأخر المقالات المجدولة ونسخ الإضافات. الحل أن تفصلها عن الزيارات وتشغّلها من مجدول النظام كل 5 دقائق، بالأوامر التالية أو من «المهام المجدولة» في cPanel:

cd ~/public_html# فصل WP-Cron عن الزياراتwp config set DISABLE_WP_CRON true --raw# إضافة مهمة كل 5 دقائق (استبدل /usr/local/bin/wp بما يعيده الأمر which wp)(crontab -l 2>/dev/null; echo "*/5 * * * * cd $HOME/public_html && /usr/local/bin/wp cron event run --due-now --quiet") | crontab -

05الأمان: سطح هجوم أصغر

معظم الثغرات المعلنة في منظومة WordPress كل عام تقع في الإضافات والقوالب، لا في النواة. لذلك يبدأ الأمان من عدد ما تثبّته:

• إضافات أقل: كل إضافة كود يُنفَّذ مع الطلبات ومصدر محتمل للثغرات. احذف ما لا تحتاجه بدل أن تعطّله، فالإضافة المعطلة تبقى ملفاتها على الخادم.
• تحديثات منتظمة: التحديثات الصغرى للنواة تلقائية افتراضياً. فعّل التحديث التلقائي للإضافات الموثوقة، وراجع الباقي أسبوعياً بعد نسخة احتياطية.
• XML-RPC: إن لم تعتمد على Jetpack أو أداة نشر خارجية تستخدمه، فأغلق الملف xmlrpc.php، فهو هدف مفضل لتخمين كلمات المرور بالجملة.
• حماية الدخول: مصادقة ثنائية لكل حساب مدير، واسم مستخدم غير admin، وحد لمحاولات الدخول. وعلى مستوى الخادم يحجب جدار الحماية محاولات التخمين قبل أن تصل إلى PHP.
• محرر الملفات: عطّل تعديل ملفات القالب والإضافات من لوحة التحكم، فمن يسرق كلمة مرور مدير لا يحصل معها على تنفيذ كود مباشر.

# أضف هذه الأسطر إلى ملف .htaccess في مجلد الموقع لإغلاق xmlrpc.php<Files xmlrpc.php>  Require all denied</Files>

cd ~/public_html# تعطيل محرر الملفات في لوحة WordPresswp config set DISALLOW_FILE_EDIT true --raw# مراجعة حسابات المديرين وحذف من لا يحتاجهاwp user list --role=administrator --fields=ID,user_login,user_email

06النسخ الاحتياطي والبيئة التجريبية

النسخة الاحتياطية التي لم تجرّب استعادتها افتراض لا خطة. ثلاث قواعد تكفي لمعظم المواقع:

1. 01نسخة يومية تلقائية خارج الخادم: تشمل الملفات وقاعدة البيانات معاً، وتحتفظ بأيام تكفي لتكتشف إصابة صامتة قبل أن تُستبدل كل النسخ السليمة.
2. 02نسخة يدوية قبل كل تغيير كبير: تحديث WooCommerce أو تبديل القالب أو ترقية PHP: نسخة قبل التغيير تختصر الاستعادة إلى دقائق.
3. 03تجربة استعادة كل ربع سنة: استعد نسخة إلى نطاق فرعي، وتأكد أن الموقع يفتح وأن آخر الطلبات والتعليقات موجودة.

والبيئة التجريبية (Staging) نسخة من موقعك على نطاق فرعي مثل staging.bayt-aldishdasha.com، تجرّب عليها التحديثات وترقية PHP قبل الموقع الحي. أنشئها بأداة الاستنساخ في WP Toolkit أو يدوياً، واحمها بكلمة مرور، وامنع أرشفتها في محركات البحث، ثم انقل التغييرات بالطريقة التي شرحناها مع search-replace.

07قبل أن تختار استضافة لـ WordPress

اسأل عن هذه النقاط قبل أن تسأل عن السعر، وتحقق منها بنفسك في يومك الأول:

في استضافة cPanel لدى إليفانتي تجد هذه الطبقات مفعّلة في الخطط الثلاث: LiteSpeed مع LSCache، وRedis للكائنات، وOPcache، وHTTP/3، ومحدد لإصدارات PHP، وSSH مع Git والمهام المجدولة، ونسخ JetBackup يومية تُحفظ على خوادم منفصلة، وImunify360 وCloudLinux للحماية والعزل، وPHP X-Ray لتتبع الطلبات البطيئة. ابدأ بقياس TTFB قبل كل تعديل وبعده، فالرقم وحده يخبرك هل أضافت الطبقة شيئاً.

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