المتجر شغال حلو قدام الزبون، بس أول ما تفتح صفحة الطلبات تقعد تستنى عشر ثواني. وحفظ منتج واحد بقى مشوار. الخبر الحلو إن البطء ده غالباً له أسباب محدودة وواضحة، ومعظمها يتصلّح من غير ما تبني المتجر من الأول.
بطء لوحة التحكم (Dashboard) ليس مجرد إزعاج. فريقك يجهّز الطلبات أبطأ، وتحديثات المنتجات تتأجل، والسيرفر الذي يختنق في الإدارة غالباً سيختنق في الواجهة أول يوم عروض كبير.
لماذا تبطئ الإدارة والواجهة سريعة؟
زوار المتجر يحصلون في الغالب على صفحات من التخزين المؤقت (Cache)، لذلك يبدو المتجر سريعاً حتى لو كان السيرفر يعاني. أما لوحة التحكم فلا تُخزَّن أبداً: كل نقرة تشغّل PHP واستعلامات قاعدة البيانات (Database) كاملة.
لهذا تظهر أي نقطة ضعف في الإدارة أولاً. الأسباب المعتادة، بترتيب شيوعها تقريباً:
- إضافات كثيرة أو ثقيلة: كل إضافة (Plugin) قد تضيف استعلامات واتصالات خارجية وسكريبتات لكل صفحة في الإدارة.
- جدول
wp_optionsمتضخم: صفوف محمَّلة تلقائياً مع كل طلب، كثير منها بقايا إضافات حذفتها من زمان. - الطلبات في جداول المقالات القديمة: المتاجر الكبيرة تبطئ حين تعيش الطلبات في
wp_postsوwp_postmeta. - طابور مهام خلفية متراكم: آلاف المهام المعلّقة أو الفاشلة في Action Scheduler.
- لا يوجد كاش للكائنات وإصدار PHP قديم.
- استضافة ضعيفة: عدد محدود من PHP Workers وتخزين بطيء.
التخمين في هذه القائمة يضيّع وقتك. ابدأ بالقياس.
ووكومرس
ترتيب علاج لوحة تحكم ووكومرس البطيئة
قِس أولاً بـ Query Monitor
سجّل زمن التحميل وأثقل الاستعلامات والإضافة المسؤولة عنها.
فعّل HPOS
انقل الطلبات لجداول مخصصة بعد التأكد من توافق إضافات الدفع والشحن.
نظّف wp_options
احذف صفوف الـ autoload التي تركتها إضافات محذوفة، والـ transients المنتهية.
صفِّ طابور Action Scheduler
عالج مصدر المهام الفاشلة أولاً، ثم انقل WP-Cron إلى cron حقيقي.
خفّف الإضافات وأضف Redis
عطّل الإضافات واحدة واحدة، ثم أضف Object Cache وحدّث PHP.
الخطوة 1: حدّد عنق الزجاجة قبل أي تعديل
خذ نسخة احتياطية (Backup) كاملة أولاً. ثبّت إضافة Query Monitor المجانية على بيئة الاختبار (Staging)، أو على الموقع الحي لاختبار قصير إن لم تكن لديك بيئة اختبار.
افتح الشاشة البطيئة، مثل WooCommerce ← Orders، وراقب ثلاثة أشياء في Query Monitor:
- Slow Queries (الاستعلامات البطيئة): مرتبة بالزمن، مع اسم الإضافة أو القالب المسؤول عن كل منها.
- Queries by Component (الاستعلامات حسب المكوّن): إن كانت إضافة واحدة تستهلك معظم الزمن، فهي المشتبه الأول.
- HTTP API Calls (الطلبات الخارجية): إضافة تتصل بسيرفر التراخيص مع كل تحميل قد تضيف ثواني وحدها.
دوّن زمن التحميل وأكبر المتسببين قبل أي تغيير. هذه الأرقام هي دليلك على أن كل إصلاح أفاد فعلاً. وتذكّر: إجمالي الزمن المستهلك أهم من استعلام واحد يبدو مخيفاً.
الخطوة 2: فعّل تخزين الطلبات عالي الأداء (HPOS)
المتاجر القديمة تحفظ الطلبات في جداول المقالات العامة. ميزة High-Performance Order Storage تنقلها إلى جداول مخصصة، فتسرع شاشات الطلبات واستعلاماتها كلما زاد عددها.
تجدها في WooCommerce ← Settings ← Advanced ← Features. قبل التفعيل:
- تأكد أن كل إضافة تتعامل مع الطلبات تعلن دعمها لـ HPOS: بوابات الدفع (Payment Gateway) مثل Paymob وFawry، وإضافات الشحن مثل Bosta، والفواتير والاشتراكات.
- نفّذ الترحيل على بيئة الاختبار أولاً.
- استخدم وضع التوافق الذي يزامن مكانَي التخزين أثناء الانتقال، فتستطيع الرجوع إن تعطّل شيء.
المتاجر الجديدة على إصدارات ووكومرس الحديثة تعمل بـ HPOS افتراضياً، فهذه الخطوة تخص المتاجر القديمة أساساً.
الخطوة 3: نظّف بيانات الـ Autoload في wp_options
كل صف في wp_options عليه علامة autoload يُحمَّل مع كل طلب. لعرض أكبر الصفوف، شغّل هذا الاستعلام على نسخة احتياطية أو قاعدة بيانات بيئة الاختبار:
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY bytes DESC
LIMIT 20;
القيم المتعددة لعمود autoload سببها اختلاف إصدارات ووردبريس. إن كان الحجم الإجمالي عدة ميجابايت، أو كانت صفوف قليلة تستحوذ عليه، فقد وجدت مشكلة حقيقية.
احذف الصفوف التابعة لإضافات أزلتها، واسأل مطوّر الإضافة عن الباقي. لا تحذف صفاً لا تعرف صاحبه. أما البيانات المؤقتة (Transients) المنتهية فتُحذف بأمان عبر WP-CLI:
wp transient delete --expired
الخطوة 4: صفِّ طابور Action Scheduler
ادخل WooCommerce ← Status ← Scheduled Actions. آلاف المهام المعلّقة أو المتأخرة، أو قائمة طويلة من المهام الفاشلة، معناها أن المُجدول يعمل ضدك.
ابحث عن المصدر: إضافة إيميل مضبوطة غلط، أو Webhook يفشل باستمرار، أو مزامنة تعمل أكثر من اللازم. عالج المصدر أولاً؛ لو مسحت الطابور فقط سيعود خلال أيام. بعدها امسح المهام القديمة المكتملة والفاشلة.
راجع أيضاً WP-Cron. في المتجر المزدحم، الأفضل إيقاف تشغيله مع تحميل الصفحات وتشغيل cron حقيقي من السيرفر. أضف هذا السطر في wp-config.php:
define( 'DISABLE_WP_CRON', true );
ثم أنشئ مهمة cron من لوحة الاستضافة (hPanel أو cPanel أو Plesk) تستدعي wp-cron.php كل 5 دقائق. هكذا يصبح التوقيت متوقعاً، ولا يتحمل زائر المتجر عبء المهام الخلفية.
الخطوة 5: خفّف وزن الإضافات وأضف كاش الكائنات
على بيئة الاختبار، عطّل الإضافات واحدة تلو الأخرى وأعد تحميل الشاشة البطيئة. حين تُحدث إضافة فرقاً كبيراً، اسأل: هل أحتاجها؟ هل توجد بديلة أخف؟ هل تكفي بضعة أسطر كود مكانها؟
راقب بشكل خاص الإضافات التي تعمل في كل صفحات الإدارة رغم أنها تهم صفحة واحدة: ودجات التحليلات، ولوحات التسويق، ونوافذ “الاقتراحات”. كثير منها يسمح بإخفاء ودجت لوحة التحكم من الإعدادات.
بعد التنظيف، أضف كاش الكائنات (Object Cache) الدائم عبر Redis. يحفظ نتائج الاستعلامات المتكررة فلا تعيدها الإدارة مع كل نقرة، وأثره أكبر في المتاجر ذات المنتجات والطلبات الكثيرة. وحدّث PHP لأحدث إصدار تدعمه إضافاتك بعد اختباره على بيئة الاختبار.
مهم: الكاش وPHP الحديث يأتيان بعد الأساسيات، لا بدلاً منها. Redis لن يصلح جدول options متضخماً ولا إضافة تتصل بسيرفر خارجي مع كل تحميل.
متى تكون الاستضافة هي المشكلة؟
إن كانت الإضافات مرتبة وقاعدة البيانات نظيفة والإدارة ما زالت بطيئة، انظر للاستضافة (Hosting). العلامات: حد منخفض لعدد PHP Workers، تخزين بطيء، سيرفر قاعدة بيانات مشترك مع مواقع كثيرة، أو عدم إمكانية تثبيت Redis.
الانتقال إلى سيرفر افتراضي خاص (VPS) أو استضافة مُدارة تتحكم فيها ليس الحل دائماً، لكنه يمنحك أدوات تسلبها الاستضافة المشتركة الرخيصة: الكاش، وإعدادات PHP، وcron السيرفر. ولقرّاء مصر والخليج، اختر مركز بيانات في أوروبا (فرانكفورت مثلاً) مع Cloudflare لتقليل زمن الاستجابة. لو حابب تبدأ بخطة تسمح بـ Redis وcron، شوف جرّب Hostinger.
متى تتوقف عن الترقيع؟
يرى كاتب المقال الأصلي أن بعض المتاجر تتجاوز قدرات ووردبريس فعلاً: قائمة إضافات ضخمة، ومنطق مخصص ثقيل، وحاجة لمخزون وطلبات لحظية. في هذه الحالة قد يكلّف بناء مخصص أقل من الضبط المستمر على مدى ثلاث سنوات.
لكن بالنسبة لمعظم متاجر ووكومرس، خاصة المتاجر المصرية الصغيرة والمتوسطة، الإصلاحات الخمسة أعلاه كافية.
اقرأ أيضًا
الأسئلة الشائعة
س: لماذا لوحة تحكم ووكومرس بطيئة بينما واجهة المتجر سريعة؟
ج: لأن الواجهة تُقدَّم غالباً من كاش الصفحات، أما الإدارة فلا تُخزَّن، فتظهر فيها الاستعلامات البطيئة والإضافات الثقيلة والمهام الخلفية وحدها.
س: هل إضافة كاش مثل WP Rocket أو LiteSpeed Cache تسرّع لوحة التحكم؟
ج: كاش الصفحات لا يفيد الإدارة. كاش الكائنات (Redis) يفيد، لكنه لن يعالج جدول options متضخماً أو إضافة تبطئ الإدارة باتصالات خارجية.
س: هل تفعيل HPOS آمن على متجر شغال؟
ج: جرّبه على بيئة الاختبار أولاً، وتأكد أن بوابات الدفع وإضافات الشحن تدعمه، واحتفظ بنسخة احتياطية، وفعّل وضع المزامنة أثناء الانتقال.
س: كم يستغرق إصلاح بطء لوحة تحكم ووكومرس؟
ج: تنظيف options والـ transients والمهام المجدولة سريع نسبياً. استبدال إضافات أو نقل الاستضافة يحتاج وقتاً أطول واختباراً.
الخلاصة
اقِس الأول بـ Query Monitor، وبعدين اشتغل بالترتيب: HPOS، ثم wp_options، ثم Action Scheduler، ثم الإضافات والكاش. كل خطوة سجّل رقمها عشان تعرف إيه اللي فرق فعلاً. ولو محتاج حد يبص على متجرك معاك، احجز استشارة من احجز استشارة مجانية.
مرجع المقال (بالإنجليزية): Why WooCommerce Admin Is Slow and How to Fix It
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.



