كيفية تسريع WordPress على VPS باستخدام Nginx وPHP-FPM وRedis: دليل شامل

خطوات عملية لتحسين سرعة ووردبريس وتقليل استهلاك موارد السيرفر باستخدام التخزين المؤقت وضبط PHP

القيسيمنذ أسبوع واحد

0 19 13 دقائق

تسريع WordPress على VPS باستخدام Nginx وPHP-FPM وRedis وOPcache، مع مقارنة توضيحية لأداء الموقع قبل التحسين وبعده.

قد تلاحظ أن موقع WordPress يعمل بسرعة جيدة عند تثبيته لأول مرة، ثم يبدأ بالتباطؤ تدريجيًا مع زيادة المقالات والإضافات وعدد الزوار.

وفي بعض الحالات، يقرر صاحب الموقع ترقية VPS إلى خطة أعلى، رغم أن المشكلة الحقيقية قد تكون في إعدادات PHP-FPM أو الاستعلامات المتكررة لقاعدة البيانات أو غياب التخزين المؤقت.

لهذا، فإن تسريع WordPress على VPS لا يعتمد على زيادة RAM أو عدد أنوية المعالج فقط، بل يحتاج إلى فهم كيفية معالجة الطلبات داخل السيرفر وتحسين المكونات التي تستهلك الموارد.

في هذا الدليل من حكاية تقنية، سنتعلم كيفية تحسين أداء WordPress باستخدام Nginx وPHP-FPM وRedis وOPcache، مع مراقبة موارد Ubuntu وقياس الأداء قبل تطبيق التعديلات وبعدها.

سنستخدم Ubuntu Server 24.04 LTS مع PHP 8.3 وMariaDB، ونوضح الإعدادات التي يمكن البدء بها، وتلك التي يجب اختبارها قبل اعتمادها في بيئة الإنتاج.

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

لماذا يصبح WordPress بطيئًا على VPS؟

عندما يطلب الزائر صفحة من موقع WordPress، قد تمر العملية بعدة مراحل:

يستقبل Nginx طلب المتصفح.
يحدد ما إذا كان الطلب لملف ثابت أو صفحة ديناميكية.
يرسل الطلب الديناميكي إلى PHP-FPM.
ينفذ PHP شيفرة WordPress والإضافات والقالب.
يسترجع WordPress البيانات المطلوبة من MariaDB أو من التخزين المؤقت.
تُرسل الاستجابة إلى المتصفح.

إذا كانت إحدى هذه المراحل بطيئة، فقد يتأخر تحميل الصفحة.

ومن الأسباب الشائعة لبطء WordPress:

استعلامات قاعدة بيانات كثيرة أو بطيئة.
إضافات تستهلك موارد مرتفعة.
عمليات PHP-FPM غير مضبوطة.
عدم استخدام OPcache.
غياب التخزين المؤقت المناسب.
صور وملفات JavaScript وCSS كبيرة.
مهام خلفية متكررة.
نقص RAM أو ضغط المعالج.
بطء التخزين أو الشبكة.

لهذا ينبغي تحديد السبب قبل شراء موارد إضافية.

1. قياس سرعة WordPress قبل إجراء التحسينات

أول خطوة في تحسين الأداء هي معرفة الوضع الحالي.

لا يمكن الحكم على نجاح أي تعديل دون وجود نتائج سابقة للمقارنة.

استخدام PageSpeed Insights

افتح أداة Google:

https://pagespeed.web.dev/

أدخل رابط موقعك، ثم افحص نسخة الهاتف ونسخة سطح المكتب.

ستعرض الأداة مؤشرات تتعلق بتجربة تحميل الصفحة، وقد تتضمن بيانات مستخدمين حقيقية إذا كانت متاحة للموقع.

أهم المؤشرات

Largest Contentful Paint – LCP

يقيس الزمن اللازم لعرض أكبر عنصر محتوى ظاهر ضمن نطاق العرض.

Interaction to Next Paint – INP

يقيس استجابة الصفحة لتفاعلات المستخدمين.

Cumulative Layout Shift – CLS

يقيس مقدار التحولات البصرية غير المتوقعة أثناء استخدام الصفحة.

Time to First Byte – TTFB

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

تسجيل النتائج

قبل التعديل، سجّل:

المؤشر	قبل التحسين	بعد التحسين
LCP	يُقاس فعليًا	يُقاس فعليًا
INP	يُقاس عند توفر البيانات	يُقاس عند توفر البيانات
CLS	يُقاس فعليًا	يُقاس فعليًا
TTFB	يُقاس فعليًا	يُقاس فعليًا
استهلاك RAM	يُقاس فعليًا	يُقاس فعليًا
استهلاك CPU	يُقاس فعليًا	يُقاس فعليًا

لا تعتمد على اختبار واحد فقط؛ كرر القياسات في ظروف متقاربة.

2. فحص استهلاك موارد VPS

قبل تعديل Nginx أو PHP، افحص حالة السيرفر.

اتصل عبر SSH:

ssh adminuser@SERVER_IP

ثم نفذ:

free -h

يعرض هذا الأمر استخدام الذاكرة.

فحص المعالج

top

يعرض العمليات النشطة واستهلاك الموارد.

يمكن الخروج بالضغط على q.

فحص التخزين

df -h

فحص الذاكرة الافتراضية Swap

swapon --show

وجود Swap لا يعني وجود مشكلة بحد ذاته، لكن الاعتماد المستمر عليها نتيجة نقص RAM قد يؤثر في الأداء.

فحص ضغط النظام

uptime

يعرض متوسط الحمل، لكن لا يمكن تفسير أرقام Load Average بصورة صحيحة دون مراعاة عدد المعالجات وطبيعة العمليات.

متى تحتاج إلى ترقية VPS؟

قد تكون الترقية مناسبة إذا أثبتت المراقبة وجود ضغط مستمر على الموارد، بعد معالجة المشكلات البرمجية الواضحة.

أما إذا كان السيرفر يمتلك RAM متاحة والمعالج غير مضغوط، فقد يكون سبب البطء في قاعدة البيانات أو الإضافات أو الشبكة.

3. ما هو PHP-FPM ولماذا يؤثر في السرعة؟

PHP-FPM هو مدير عمليات PHP المسؤول عن تنفيذ ملفات WordPress عند استخدام Nginx.

عندما تصل طلبات ديناميكية متعددة، تحتاج إلى عمليات PHP لمعالجتها.

إذا كان عدد العمليات قليلًا جدًا، فقد تنتظر بعض الطلبات دورها.

وإذا كان عددها كبيرًا أكثر من اللازم، فقد تستهلك الذاكرة وتسبب ضغطًا على النظام.

أنماط إدارة العمليات

يدعم PHP-FPM ثلاثة أنماط أساسية:

النمط	طريقة العمل
static	عدد ثابت من العمليات
dynamic	زيادة وتقليل العمليات ضمن حدود
ondemand	إنشاء العمليات عند وصول الطلبات

لا يوجد نمط أفضل دائمًا؛ يعتمد الاختيار على حجم الزيارات والذاكرة وسلوك التطبيق.

4. مراجعة إعدادات PHP-FPM

في Ubuntu 24.04 مع PHP 8.3، يوجد ملف إعداد مجموعة العمليات الافتراضية عادةً في:

/etc/php/8.3/fpm/pool.d/www.conf

قبل تعديله، احتفظ بنسخة احتياطية:

sudo cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak

ثم افتحه:

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

ابحث عن التوجيهات التالية:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

هذه قيم توضيحية وليست إعدادات موصى بها لكل VPS.

ما وظيفة كل إعداد؟

pm.max_children: يحدد الحد الأقصى لعمليات PHP-FPM في المجموعة.

pm.start_servers: يحدد عدد العمليات التي تبدأ عند تشغيل الخدمة في نمط dynamic.

pm.min_spare_servers: الحد الأدنى المستهدف للعمليات الخاملة.

pm.max_spare_servers: الحد الأعلى المستهدف للعمليات الخاملة.

كيف تختار العدد المناسب؟

يجب تقدير استهلاك الذاكرة الفعلي لكل عملية PHP، ثم تحديد مقدار RAM الذي يمكن تخصيصه لـ PHP-FPM بعد احتساب احتياجات MariaDB وRedis وNginx ونظام التشغيل.

على سبيل المثال، إذا كان متوسط استهلاك عملية PHP نحو 100MB، وكانت الميزانية المتاحة لعمليات PHP تساوي 500MB، فقد يكون الحد النظري التقريبي خمس عمليات.

لكن هذا مجرد مثال حسابي، وليس قياسًا لسيرفرك.

كما أن استخدام RSS وحده قد يبالغ في تقدير الذاكرة بسبب الصفحات المشتركة بين العمليات؛ لذلك يُفضل استخدام أدوات قياس مناسبة ومراقبة الذروة.

تطبيق التعديلات بأمان

بعد تعديل الملف، افحص صحة إعدادات PHP-FPM:

sudo php-fpm8.3 -t

إذا نجح الاختبار، أعد تحميل الخدمة:

sudo systemctl reload php8.3-fpm

ثم راقب الموقع والسجلات.

مهم: لا ترفع pm.max_children بصورة عشوائية؛ فقد يؤدي ذلك إلى نفاد الذاكرة بدل تحسين الأداء.

5. ما هو OPcache وكيف يسرّع PHP؟

OPcache امتداد من PHP يحتفظ بالشيفرة المترجمة مسبقًا في الذاكرة المشتركة.

وبذلك يقلل الحاجة إلى قراءة ملفات PHP وتحليلها وترجمتها في كل طلب.

وهذا مفيد لتطبيقات PHP مثل WordPress التي تنفذ ملفات برمجية متكررة.

هل OPcache مثبت بالفعل؟

إذا اتبعت دليل تثبيت WordPress السابق واستخدمت حزمة php-opcache، فقد يكون الامتداد مثبتًا ومفعّلًا بالفعل.

تحقق من وجوده باستخدام:

php -m | grep -i opcache

لكن انتبه إلى أن إعدادات PHP في سطر الأوامر قد تختلف عن إعدادات PHP-FPM.

مراجعة إعدادات OPcache

في بيئة PHP 8.3 المعتادة على Ubuntu، يمكن مراجعة الملف:

/etc/php/8.3/fpm/conf.d/10-opcache.ini

أو ملفات الإعداد الأخرى التي يحمّلها PHP-FPM.

يمكن استخدام إعدادات مثل:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

هذه قيم ابتدائية شائعة ومتوافقة مع توثيق PHP، وقد تكون مضبوطة مسبقًا.

لا تضفها مرة ثانية دون مراجعة الإعدادات الفعلية.

شرح الإعدادات

opcache.enable: يفعّل التخزين المؤقت للشيفرة.

opcache.memory_consumption: يحدد مقدار الذاكرة المشتركة المخصصة لـ OPcache بالميغابايت.

opcache.interned_strings_buffer: يحدد مساحة تخزين السلاسل النصية المشتركة.

opcache.max_accelerated_files: يحدد السعة المستهدفة لعدد ملفات PHP المخزنة.

opcache.validate_timestamps: يسمح بالتحقق من تغيّر الملفات.

opcache.revalidate_freq: يحدد الفترة بين عمليات التحقق من تغيّر الملفات عندما يكون التحقق مفعّلًا.

هل يجب تعطيل validate_timestamps؟

لا ننصح بذلك في دليل للمبتدئين.

فإذا عطلت التحقق من تغيّر الملفات، فقد تحتاج إلى إعادة ضبط OPcache عند نشر تحديثات WordPress أو القوالب أو الإضافات.

قد يؤدي سوء إدارة هذه العملية إلى استمرار تشغيل شيفرة قديمة.

بعد أي تغيير في إعدادات OPcache، اختبر PHP-FPM وأعد تحميله أو تشغيله وفق التغيير المطلوب، ثم تحقق من الموقع.

6. ما هو Redis Object Cache؟

Redis مخزن بيانات سريع يعمل غالبًا في الذاكرة.

يمكن استخدامه مع WordPress لتوفير Persistent Object Cache، أي تخزين بعض البيانات والكائنات المحسوبة بحيث يمكن إعادة استخدامها بين الطلبات.

بدل تنفيذ بعض العمليات والاستعلامات المتكررة في كل مرة، قد يستطيع WordPress استرجاع البيانات من Redis.

هل Redis يخزن صفحات الموقع كاملة؟

ليس بالضرورة.

يجب التمييز بين ثلاثة أنواع من التخزين المؤقت:

النوع	الوظيفة
OPcache	تخزين الشيفرة المترجمة لـ PHP
Object Cache	تخزين كائنات وبيانات التطبيق
Page Cache	تخزين استجابة الصفحة كاملة

Redis Object Cache ليس بديلًا مباشرًا عن Page Cache.

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

7. تثبيت Redis على Ubuntu

قبل تثبيت Redis، تحقق من وجود خدمة سابقة على السيرفر لتجنب تشغيل نسخ متعارضة.

لتثبيت Redis من مستودعات Ubuntu:

sudo apt update

sudo apt install redis-server php-redis

بعد اكتمال التثبيت، تحقق من حالة الخدمة:

systemctl is-active redis-server

اختبار Redis

يمكن تنفيذ:

redis-cli ping

إذا كانت الخدمة متاحة محليًا ولا تتطلب مصادقة إضافية، فقد تظهر الاستجابة:

PONG

لكن هذه النتيجة وحدها لا تعني أن Redis مؤمّن بصورة كاملة.

التحقق من امتداد PHP

نفذ:

php -m | grep -i redis

ثم تأكد من أن الامتداد محمّل أيضًا في بيئة PHP-FPM، وليس في CLI فقط.

إذا احتاج PHP-FPM إلى تحميل امتداد جديد، فراجع الإعدادات وأعد تحميل الخدمة.

8. تأمين Redis قبل ربطه بـ WordPress

هذه خطوة مهمة جدًا.

لا تجعل Redis متاحًا للعامة عبر الإنترنت.

في حالة وجود WordPress وRedis على السيرفر نفسه، يُفضل إبقاء Redis على واجهة محلية أو استخدام Unix Socket بإعدادات صلاحيات مناسبة.

مراجعة ملف الإعداد

في تثبيت Ubuntu المعتاد:

sudo nano /etc/redis/redis.conf

تحقق من إعدادات الربط بالشبكة.

قد يتضمن الإعداد:

bind 127.0.0.1 -::1

ويجب فهم طريقة تعامل إصدار Redis المثبت مع IPv4 وIPv6.

التحقق من المنافذ

نفذ:

sudo ss -ltnp

وابحث عن المنفذ 6379 إذا كان Redis يستخدم منفذ TCP الافتراضي.

يجب ألا يكون Redis مكشوفًا على واجهة عامة دون إعداد أمني مقصود ومناسب.

هل يكفي UFW؟

لا تعتمد على الجدار الناري وحده.

اجمع بين ضبط عنوان الاستماع وسياسة الشبكة والصلاحيات والمصادقة عند الحاجة.

وإذا كنت تستضيف عدة مواقع لعملاء مختلفين، فلا تفترض أن استخدام Redis واحد دون عزل مناسب آمن لجميع الحالات.

9. ربط Redis بموقع WordPress

بعد التأكد من عمل Redis وأمان اتصاله، تحتاج إلى إضافة تدعم Persistent Object Cache.

من الإضافات المعروفة:

Redis Object Cache

يمكن العثور عليها في مستودع إضافات WordPress الرسمي.

خطوات الإعداد

من لوحة تحكم WordPress:

افتح الإضافات ثم أضف إضافة جديدة.
ابحث عن Redis Object Cache.
تحقق من اسم الإضافة والمطور والتوافق.
ثبّت الإضافة وفعّلها.
افتح صفحة إعدادات الإضافة.
تحقق من نجاح الاتصال بخادم Redis.
فعّل Object Cache إذا كانت البيئة جاهزة.

قد تختلف أسماء الأزرار والخطوات بحسب إصدار الإضافة.

ماذا لو فشل الاتصال؟

تحقق من:

حالة خدمة Redis.
عنوان الاتصال والمنفذ.
توفر امتداد PHP Redis.
إعدادات PHP-FPM.
سياسات Redis الأمنية.
سجلات الأخطاء.

لا تعطل حماية Redis أو تفتح المنفذ للعامة لمجرد معالجة خطأ الاتصال.

10. ضبط Redis عند استضافة عدة مواقع

إذا كنت تستضيف أكثر من موقع WordPress على السيرفر نفسه، فقد تشترك المواقع في خدمة Redis.

لهذا يجب تجنب تعارض مفاتيح التخزين المؤقت بين المواقع.

تدعم بعض إضافات Redis إعداد بادئة مميزة للمفاتيح.

وقد تحتاج أيضًا إلى عزل أقوى إذا كانت المواقع تخص عملاء مختلفين أو تتطلب حدودًا أمنية مستقلة.

تنبيه: البادئة المختلفة للمفاتيح ليست بديلًا عن العزل الأمني بين العملاء.

هل يجب تفعيل Redis لكل موقع؟

ليس بالضرورة.

قد يستفيد موقع يحتوي على استعلامات متكررة من Object Cache، بينما لا يلاحظ موقع بسيط فرقًا كبيرًا.

والأفضل قياس التأثير الفعلي بدل تفعيل Redis لمجرد أنه متاح.

11. تحسين إعدادات Nginx

يمكن تحسين أداء Nginx بطرق متعددة، لكن يجب أولًا تحديد ما إذا كان خادم الويب يمثل عنق الزجاجة.

التحقق من الإعدادات

قبل أي تعديل:

sudo nginx -t

مراجعة ملفات السجلات

sudo tail -n 50 /var/log/nginx/error.log

إذا كنت قد أنشأت سجلًا خاصًا بالموقع، فراجع ملفه أيضًا.

تقديم الملفات الثابتة

يستطيع Nginx تقديم ملفات الصور وCSS وJavaScript مباشرة دون تشغيل PHP.

وهذا يقلل الحاجة إلى تمرير الطلبات الثابتة إلى WordPress.

التخزين المؤقت للمتصفح

يمكن إرسال رؤوس HTTP تسمح للمتصفح بالاحتفاظ بالملفات الثابتة لفترة مناسبة.

لكن يجب مراعاة أسماء الملفات وتحديثاتها، حتى لا يستمر المتصفح في استخدام نسخة قديمة بعد تغيير المحتوى.

ضغط الملفات

يمكن استخدام ضغط HTTP للموارد النصية عند توفر الدعم والإعداد المناسب.

لكن الضغط يستهلك بعض موارد المعالج، ويجب اختبار تأثيره.

12. هل يجب تفعيل FastCGI Cache؟

يوفر Nginx إمكانية التخزين المؤقت لاستجابات FastCGI.

وقد تساعد هذه الميزة على تقليل عدد الطلبات التي تصل إلى PHP-FPM.

لكن إعدادها بصورة غير صحيحة قد يسبب مشكلات خطيرة في المواقع الديناميكية.

صفحات يجب التعامل معها بحذر

لوحة إدارة WordPress.
صفحات تسجيل الدخول.
صفحات الحسابات الشخصية.
سلة التسوق والدفع.
الصفحات التي تحتوي على بيانات خاصة بالمستخدم.
الطلبات التي تغيّر البيانات.
الصفحات المعتمدة على Cookies أو جلسات المستخدمين.

لا تستخدم قاعدة تخزين مؤقت عامة لجميع الصفحات دون تحديد الاستثناءات.

هل FastCGI Cache ضروري؟

لا.

إذا كنت تستخدم إضافة Page Cache مناسبة أو طبقة تخزين مؤقت خارجية، فقد لا تحتاج إلى FastCGI Cache.

وقد يؤدي الجمع بين عدة أنظمة تخزين مؤقت للصفحات دون تنسيق إلى ظهور محتوى قديم أو صعوبة في تفريغ الذاكرة المؤقتة.

لهذا نوصي بتخصيص إعداد FastCGI Cache لمقال مستقل يتضمن قواعد الاستثناء والاختبار.

13. تحسين قاعدة بيانات MariaDB

قد تكون قاعدة البيانات أحد أسباب بطء WordPress، خصوصًا عند استخدام إضافات تنفذ استعلامات كثيرة.

مراقبة الخدمة

systemctl is-active mariadb

مراجعة السجلات

sudo journalctl -u mariadb --since "1 hour ago"

ما الذي يؤثر في أداء MariaDB؟

حجم قواعد البيانات.
عدد الاتصالات المتزامنة.
الاستعلامات البطيئة.
الفهارس.
حجم الذاكرة المخصصة للتخزين المؤقت.
سرعة التخزين.
عدد عمليات القراءة والكتابة.

هل يجب زيادة innodb_buffer_pool_size؟

قد يفيد تعديل هذا الإعداد في بعض البيئات، لكنه يعتمد على حجم قاعدة البيانات والذاكرة المتاحة والخدمات الأخرى.

لا تخصص معظم RAM لقاعدة البيانات دون حساب احتياجات PHP-FPM وRedis ونظام التشغيل.

ابدأ بالمراقبة، ثم غيّر الإعدادات وفق نتائج فعلية.

14. تقليل استهلاك إضافات WordPress

حتى مع وجود VPS قوي، يمكن لإضافة غير محسّنة أن تؤثر في الأداء.

قد تنفذ بعض الإضافات استعلامات كثيرة أو مهام خلفية متكررة أو عمليات اتصال بخدمات خارجية.

كيف تحدد الإضافة المسببة للبطء؟

يمكن استخدام أدوات تشخيص مثل Query Monitor في بيئة اختبار مناسبة.

تساعد هذه الأدوات على تحليل الاستعلامات والأخطاء وبعض جوانب تنفيذ الطلبات.

لكن يجب مراعاة أن أدوات التشخيص نفسها قد تضيف عبئًا أثناء تشغيلها.

هل حذف الإضافات يسرّع الموقع دائمًا؟

ليس عدد الإضافات وحده هو العامل الحاسم.

فقد تكون إضافة واحدة ثقيلة أكثر تأثيرًا من عدة إضافات بسيطة.

الأهم هو جودة البرمجة والوظائف المستخدمة وسلوك الإضافة أثناء الطلبات.

15. تحسين مهام WP-Cron

يستخدم WordPress آلية WP-Cron لتنفيذ المهام المجدولة.

قد تتضمن هذه المهام نشر المقالات المجدولة أو تشغيل بعض وظائف الإضافات.

في بعض البيئات، يمكن استخدام مجدول النظام بدل الاعتماد على تشغيل WP-Cron عبر زيارات الموقع.

هل يجب تعطيل WP-Cron؟

ليس دائمًا.

إذا كان الموقع صغيرًا ولا تواجه مشكلات في المهام المجدولة، فقد لا تحتاج إلى تغييره.

أما في المواقع ذات الحمل المرتفع، فقد يكون استخدام Cron على مستوى النظام خيارًا مناسبًا.

مهم: لا تعطل WP-Cron قبل إنشاء آلية بديلة واختبارها؛ فقد تتوقف مهام مهمة في الموقع.

16. مراقبة أداء PHP-FPM بعد التحسين

بعد ضبط PHP-FPM، راقب استخدام الموارد والأخطاء.

يمكن مراجعة السجلات:

sudo journalctl -u php8.3-fpm --since "1 hour ago"

ابحث عن تحذيرات تتعلق بوصول مجموعة العمليات إلى الحد الأقصى.

ماذا يعني الوصول إلى pm.max_children؟

قد يعني أن جميع عمليات PHP المسموح بها مشغولة.

لكن الحل ليس دائمًا زيادة العدد؛ فقد يكون السبب طلبات بطيئة أو استعلامات ثقيلة أو عمليات خارجية تستغرق وقتًا طويلًا.

راجع سبب بطء الطلبات أولًا.

ماذا لو زاد استهلاك RAM؟

قد تحتاج إلى تقليل عدد عمليات PHP أو تحسين التطبيق أو ترقية الموارد بعد التأكد من الحاجة الفعلية.

17. قياس الأداء بعد تفعيل Redis وOPcache

بعد تطبيق كل تحسين، أعد الاختبار.

استخدم الصفحات نفسها والظروف نفسها قدر الإمكان.

ماذا تقارن؟

زمن استجابة الخادم.
استهلاك CPU.
استخدام RAM.
عدد استعلامات قاعدة البيانات عند توفر القياس.
زمن تنفيذ PHP.
أداء الصفحات العامة.
أداء لوحة التحكم.
أداء الصفحات الديناميكية.

هل يجب أن تتحسن جميع النتائج؟

لا.

قد يؤدي Redis إلى تقليل بعض استعلامات قاعدة البيانات، لكنه لا يضمن تحسن LCP إذا كانت المشكلة الأساسية في صورة كبيرة أو ملفات JavaScript.

وقد يؤدي التخزين المؤقت للصفحات إلى تحسين زمن الاستجابة دون تغيير أداء لوحة الإدارة.

لذلك يجب ربط كل تحسين بالمشكلة التي يعالجها.

18. أخطاء شائعة عند تسريع WordPress على VPS

زيادة عدد عمليات PHP بصورة مبالغ فيها

قد يؤدي ذلك إلى نفاد الذاكرة وبدء استخدام Swap أو توقف بعض العمليات.

تفعيل Redis دون التحقق من إعدادات الأمان

قد يؤدي كشف Redis للعامة إلى مخاطر أمنية كبيرة.

استخدام عدة إضافات Page Cache معًا

قد يسبب تعارضًا في التخزين المؤقت وصعوبة في تحديث المحتوى.

تغيير إعدادات كثيرة دفعة واحدة

يجعل تحديد سبب التحسن أو التراجع أمرًا صعبًا.

الاعتماد على نتيجة PageSpeed واحدة

قد تتغير النتائج بسبب ظروف الاختبار والشبكة والخدمات الخارجية.

تجاهل الإضافات والقالب

قد يكون سبب البطء في التطبيق نفسه، وليس في موارد السيرفر.

تعطيل فحص تغيّر ملفات OPcache دون خطة نشر

قد يؤدي إلى استمرار استخدام شيفرة قديمة بعد تحديث الموقع.

إهمال النسخ الاحتياطية

قد تؤدي تعديلات الإعدادات غير المدروسة إلى توقف الموقع، لذلك يجب الاحتفاظ بإمكانية التراجع.

19. خطة عملية لتحسين أداء WordPress

لتحسين الموقع بطريقة منظمة، يمكن اتباع التسلسل التالي:

المرحلة الأولى: القياس

سجّل أداء الموقع وموارد السيرفر قبل أي تغيير.

المرحلة الثانية: التشخيص

حدد هل المشكلة في PHP أو قاعدة البيانات أو الملفات الثابتة أو الإضافات أو الشبكة.

المرحلة الثالثة: OPcache

تحقق من تفعيله وضبطه بصورة مناسبة.

المرحلة الرابعة: PHP-FPM

راجع عدد العمليات واستهلاك الذاكرة الفعلي.

المرحلة الخامسة: Redis

فعّل Persistent Object Cache إذا كانت طبيعة الموقع تستفيد منه.

المرحلة السادسة: Nginx

راجع تقديم الملفات الثابتة والتخزين المؤقت المناسب.

المرحلة السابعة: إعادة القياس

قارن النتائج مع خط الأساس، واحتفظ بالتعديلات التي أثبتت فائدتها.

الأسئلة الشائعة حول تسريع WordPress على VPS

هل Redis ضروري لكل موقع WordPress؟

لا. قد يفيد المواقع التي تنفذ استعلامات وعمليات متكررة، لكن فائدته تختلف بحسب التطبيق.

هل Redis أفضل من OPcache؟

لا يؤديان الوظيفة نفسها. OPcache يخزن شيفرة PHP المترجمة، بينما يمكن استخدام Redis لتخزين كائنات وبيانات التطبيق.

هل زيادة RAM تسرّع WordPress؟

قد تساعد إذا كان السيرفر يعاني نقصًا فعليًا في الذاكرة، لكنها لا تعالج جميع أسباب البطء.

هل Nginx أسرع من Apache دائمًا؟

لا. يعتمد الأداء على الإعدادات وطبيعة الموقع والموارد والتخزين المؤقت.

هل يمكن تشغيل Redis على VPS صغير؟

يمكن ذلك بحسب الذاكرة المتاحة وحجم البيانات، لكن يجب احتساب استهلاكه ضمن ميزانية RAM الإجمالية.

هل يمكن استخدام Redis مع WooCommerce؟

نعم، لكن يجب استخدام تكامل متوافق واختبار الصفحات والبيانات الديناميكية بعناية.

هل OPcache يحتاج إلى إضافة WordPress؟

لا. OPcache امتداد على مستوى PHP، وليس إضافة WordPress.

هل FastCGI Cache ضروري إذا كنت أستخدم Redis؟

ليس بالضرورة. Redis Object Cache وFastCGI Page Cache يؤديان وظيفتين مختلفتين، ويعتمد القرار على احتياجات الموقع.

هل يجب إعادة تشغيل السيرفر بعد كل تعديل؟

لا. غالبًا تكفي إعادة تحميل الخدمة المعنية أو إعادة تشغيلها وفق نوع الإعداد الذي تغير.

كيف أعرف أن التحسين نجح؟

من خلال مقارنة قياسات الأداء والموارد قبل التغيير وبعده، مع التأكد من استمرار عمل الموقع بصورة صحيحة.

الخلاصة

يعتمد تسريع WordPress على VPS على تحسين طريقة استخدام الموارد، وليس على زيادة مواصفات السيرفر فقط.

ابدأ بقياس الأداء ومراقبة استهلاك CPU وRAM، ثم راجع إعدادات PHP-FPM وتأكد من عمل OPcache.

بعد ذلك، يمكن استخدام Redis لتوفير Persistent Object Cache عندما تكون هناك فائدة فعلية منه، مع ضرورة تأمين اتصاله وعدم كشفه للعامة.

كما ينبغي مراجعة إعدادات Nginx وقاعدة بيانات MariaDB والإضافات والمهام المجدولة، مع تجنب تفعيل عدة أنظمة تخزين مؤقت دون تنسيق.

والقاعدة الأهم هي تغيير إعداد واحد في كل مرة، ثم قياس النتيجة قبل الانتقال إلى التعديل التالي.

إذا كنت تتابع سلسلة إدارة السيرفرات على حكاية تقنية، يمكنك مراجعة الأدلة السابقة:

وفي المقال القادم، سنتعرف على كيفية إنشاء نسخ احتياطية تلقائية لمواقع WordPress وقواعد البيانات على VPS، مع شرح خطوات الاستعادة واختبار النسخ الاحتياطية.