تسريع ووردبريس على Plesk في 20 دقيقة: 6 خطوات عملية

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

المقال موجّه لمن يملك سيرفراً افتراضياً خاصاً (VPS) أو استضافة عليها لوحة Plesk، ويُفضَّل أن يكون لديك وصول SSH لبعض الأوامر.

قبل أن تبدأ: قِس

لا تخمّن. شغّل الموقع على PageSpeed Insights قبل أي تعديل وبعد كل خطوة، واحتفظ بالأرقام. المقياس الذي يهمك هو زمن عرض أكبر عنصر (LCP)، والهدف أقل من 2.5 ثانية.

وخذ نسخة احتياطية (Backup) من الموقع وقاعدة البيانات أولاً، فبعض الخطوات القادمة تحذف بيانات.

1. انتقل إلى PHP-FPM وأحدث إصدار PHP

في Plesk افتح Websites & Domains ← PHP Settings للدومين، واضبط:

• PHP version: أحدث إصدار تدعمه إضافاتك. حسب المصدر، PHP 8.3 يشغّل موقع ووردبريس المعتاد أسرع بنحو 30% من 7.4.
• Run PHP as: اختر FPM application served by nginx.

إن كان لديك وصول SSH، تحقق من الإصدار:

plesk bin domain --info example.com | grep -i php
/opt/plesk/php/8.3/bin/php -v

2. فعّل OPcache

OPcache يحفظ كود PHP بعد ترجمته في الذاكرة، فلا يعيد السيرفر قراءة كل ملف مع كل طلب. أضف الإعدادات من PHP Settings ← Performance settings أو في خانة Additional directives:

opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
memory_limit=256M

القيمة revalidate_freq=60 تعني أن تعديل أي ملف يظهر خلال دقيقة. على بيئة الاختبار (Staging) التي تعدّل فيها الكود باستمرار، اجعلها 0.

3. دع nginx يقدّم الملفات الثابتة ويخزّن الصفحات

من Apache & nginx Settings فعّل Serve static files directly by nginx، وفعّل كاش nginx بمهلة 5 دقائق. هكذا يرد nginx على معظم الزيارات دون أن يبدأ PHP أصلاً.

إن كان في الموقع منطقة تسجيل دخول أو متجر ووكومرس، استثنِ المستخدمين المسجّلين والسلة حتى لا يرى أحد صفحة غيره. في Additional nginx directives:

# Never cache logged-in users or the cart
if ($http_cookie ~* "wordpress_logged_in|woocommerce_items_in_cart") {
    set $no_cache 1;
}

تأكد أن الصفحة تأتي من الكاش بفحص رؤوس الاستجابة:

curl -sI https://example.com/ | grep -i "x-cache|cache-control"

4. اضغط الصور المرفوعة بالفعل

إضافات الضغط تتعامل مع الصور الجديدة، لكن الوزن الحقيقي في مكتبة الوسائط (Media Library) القديمة. من SSH، حوّل كل صورة أكبر من 100 كيلوبايت إلى WebP بجانب الأصل:

cd ~/httpdocs/wp-content/uploads
find . -type f ( -iname '*.jpg' -o -iname '*.png' ) -size +100k 
  -exec sh -c 'cwebp -quiet -q 82 "$1" -o "${1%.*}.webp"' _ {} ;
du -sh .

ثم اجعل nginx يرسل نسخة .webp حين يدعمها المتصفح:

location ~* ^/wp-content/uploads/.+.(png|jpe?g)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
}

تنبيه: المتغير $webp_suffix لا يُعرَّف تلقائياً؛ يحتاج كتلة map على مستوى http في إعدادات nginx العامة، وهذا يتطلب صلاحية root على السيرفر. إن لم تكن متاحة لك، استخدم إضافة تحويل WebP تقدّم الصور عبر وسم <picture> بدلاً من ذلك.

5. نظّف قاعدة البيانات

مراجعات المقالات (Revisions) والبيانات المؤقتة (Transients) وتعليقات السبام تتراكم لسنوات. نظّفها مرة واحدة عبر WP-CLI:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp transient delete --all
wp comment delete $(wp comment list --status=spam --format=ids)
wp db optimize

ثم حدّد عدد المراجعات المستقبلية في wp-config.php:

define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 120);

مكسب هذه الخطوة صغير للزائر، لكنها توقف بطء صفحات لوحة التحكم (Dashboard).

6. ضع Cloudflare أمام الموقع

الخطة المجانية من Cloudflare تكفي معظم المواقع. وجّه الـ Nameservers إلى Cloudflare، واضبط وضع SSL على Full (strict)، وفعّل ضغط Brotli.

هذه الخطوة مهمة تحديداً لقرّائنا: لو سيرفرك في أوروبا وزوارك في القاهرة أو الرياض، شبكة توصيل المحتوى (CDN) تقدّم الملفات الثابتة من نقطة قريبة منهم بدل رحلة كاملة إلى مركز البيانات مع كل زيارة.

كم ستكسب من كل خطوة؟

تقديرات المصدر للتحسن في LCP:

في Elementor: صفحات Elementor ثقيلة بطبيعتها على PHP، لذلك تستفيد كثيراً من OPcache وكاش nginx. فعّل أيضاً من Elementor ← Settings ← Features خياري Optimized DOM Output وImproved Asset Loading إن ظهرا في إصدارك.

الأسئلة الشائعة

س: هل أحتاج وصول SSH لتسريع ووردبريس على Plesk؟
ج: الخطوات 1 و2 و3 تتم كلها من واجهة Plesk. تحويل الصور الجماعي وتنظيف قاعدة البيانات بـ WP-CLI يحتاجان SSH، أو إضافات بديلة إن لم يتوفر.

س: هل كاش nginx يتعارض مع ووكومرس؟
ج: لا، بشرط استثناء المستخدمين المسجّلين والسلة كما في قاعدة الكوكيز أعلاه، وإلا قد يرى زائر سلة زائر آخر.

س: أيهما أفضل: كاش nginx أم إضافة كاش مثل WP Rocket؟
ج: كاش nginx أسرع لأنه يرد قبل تشغيل PHP. إضافة الكاش تبقى مفيدة لتحسين ملفات CSS وJS والتحميل الكسول، ولا مانع من الجمع بينهما مع ضبط المهلة.

س: هل حذف كل الـ transients آمن؟
ج: نعم عموماً، فالإضافات تعيد إنشاءها عند الحاجة، لكن قد تلاحظ بطئاً مؤقتاً في أول تحميل بعد الحذف.

الخلاصة

قِس بـ PageSpeed الأول، وبعدين امشِ بالترتيب: PHP، OPcache، كاش nginx، الصور، قاعدة البيانات، Cloudflare. في أغلب الحالات هتوصل LCP تحت 2.5 ثانية من غير ما تغيّر الاستضافة. ولو لسه بتختار سيرفر بلوحة تحكم كويسة، بص على جرّب Hostinger.

مرجع المقال (بالإنجليزية): How to Speed Up WordPress on Plesk in 20 Minutes
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.