تحسين لوحة ووردبريس أو WooCommerce البطيئة
اعرف ما يبطّئ wp-admin فعلًا، ثم أصلحه — بالترتيب الذي يجد السبب أسرع لا بقائمة من كل ما هو ممكن.
اللوحة البطيئة سببها الموقع عادةً لا الخادم. فـ wp-admin غير مخزَّن، فكل نقرة
تشغّل PHP وتستعلم قاعدة البيانات — ما يعني أنها تكشف مشكلات تخفيها الواجهة
المخزَّنة. ينطبق على كل الاستضافة المشتركة والموزِّعة.
امض في هذا بالترتيب. فالقسمان الأولان يجدان السبب في معظم المواقع؛ وما بعدهما يستحق الفعل على أي حال لكنه نادرًا ما يكون الجواب وحده.
1. قِس قبل أن تغيّر شيئًا
ثبّت Query Monitor. فهو يعرض، للصفحة التي أنت عليها، كم استغرقت، وكم استعلامًا عمل، وأيّها كان أبطأ، وأي إضافة أصدرته.
فبدونه أنت تخمّن، والنتيجة المعتادة عشرات التغييرات دون معرفة أيها نفع.
وPHP X-Ray، في cPanel، يفعل الشيء نفسه من جانب الخادم ويستطيع تحليل طلب دون تثبيت شيء في ووردبريس. راجع تشخيص موقع بطيء بـ PHP X-Ray.
2. اعثر على الإضافة
إضافة واحدة سيئة السلوك تسبّب معظم اللوحات البطيئة. وQuery Monitor يسمّيها صراحةً عادةً.
فإن لم يفعل، فعطّل الإضافات واحدة تلو أخرى، مختبرًا اللوحة بعد كل منها. وابدأ بكل ما يضيف أعمدة إدارية، أو يشغّل فحوصًا خلفية، أو يعرض إحصاءات — فتلك تعمل مع كل تحميل صفحة إدارة.
افعل هذا على نسخة تجريبية إن كان الموقع حيًا. فتعطيل إضافة على متجر WooCommerce قد يؤثر في الدفع.
3. عالج المسبّبات الشائعة
إضافة تخزين تمسح باستمرار. فكثير من إضافات التخزين تطهّر الذاكرة كلها وتعيد بناءها كلما حُفظت مقالة أو منتج. وعلى متجر يحدّث المخزون، ذلك مستمر. أوقف المسح الكامل التلقائي وجدول تطهيرًا مرة يوميًا بدلًا منه.
WP-Cron مع كل تحميل صفحة. فافتراضيًا يفحص ووردبريس المهام المجدولة مع كل طلب. عطّله وشغّل مهمة cron حقيقية بدلًا منه — راجع منع LiteSpeed من قطع سكربتات PHP الطويلة.
واجهة Heartbeat. فووردبريس يستطلع الخادم كل 15–60 ثانية من أي تبويب إدارة مفتوح. حُدّه في الواجهة واللوحة، واتركه يعمل في محرّر المقالات حيث يشغّل الحفظ التلقائي وكشف القفل.
الجلسات والقيم المؤقتة. فإن كان wp_options ينمو سريعًا، فجلسات عملاء
WooCommerce والقيم المؤقتة المنتهية هي السبب عادةً — ويولّدها الروبوتات غالبًا.
امسحها، ثم راجع
تحسين قاعدة بيانات ووردبريس.
4. امنحه موارد أكثر
ارفع حد الذاكرة. فـ WooCommerce يوصي بـ 256 ميغابايت؛ وباقاتنا تسمح حتى
غيغابايت. اضبطه في wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );استخدم إصدار PHP حديثًا. فإصدارات PHP الأحدث أسرع بكثير. راجع الإصدار ضمن WooCommerce ← Status، وغيّره في MultiPHP Manager داخل cPanel. واستخدم إصدارًا مدعومًا — فـ PHP 8.0 وما قبله لم يعد يتلقّى تحديثات أمنية.
فعّل OPcache. فهو يخزّن PHP المصرَّف كي لا يُعاد تصريفه مع كل طلب. وتجده في cPanel ضمن إضافات PHP.
فعّل Redis. فذاكرة الكائنات تحفظ نتائج قاعدة البيانات المتكررة في الذاكرة، وهو بالضبط ما تحتاجه لوحة كثيرة الاستعلامات.
5. قلّل ما على اللوحة فعله
أزل خصائص WooCommerce التي لا تستخدمها. فإضافة Disable WooCommerce Bloat توقف لوحات التسويق وجداول التحليلات الإدارية وما شابهها.
نظّف قاعدة البيانات. فالإضافات القديمة تترك جداول خلفها. وWP-Optimize يزيلها؛ انسخ احتياطيًا أولًا.
أعد النظر في أداة بناء الصفحات. فأدوات البناء تضيف CSS وجافاسكربت كثيرين إلى
المحرّر. فإن كان البطء في المحرّر تحديدًا لا في wp-admin كله، فهذا هو السبب
على الأرجح.
أشياء لن تنفع
تخزين wp-admin مؤقتًا. فبعض الإضافات تعرضه. لا تفعل — فسترى أعداد طلبات ومستويات مخزون قديمة، وتتصرّف بناءً عليها.
Cloudflare Argo Smart Routing. فهي تحسّن توجيه الطلبات الديناميكية وتستحق النظر، لكنها إضافة مدفوعة ولا تعالج لوحة بطيئة تكلفتها زمن PHP وقاعدة البيانات على الخادم. عالج السبب أولًا.
نقل wp-login.php. يستحق الفعل لتقليل زيارات الروبوتات، لكنه إجراء أمني لا
إصلاح أداء.
تحقّق
أعد الفحص بـ Query Monitor على الصفحة نفسها التي بدأت منها. وقارن زمن التوليد وعدد الاستعلامات بما سجّلته في الخطوة الأولى.