نقلت المتجر لاستضافة أغلى، وركّبت إضافة كاش، وضغطت الصور، والمتجر لسه بياخد 6 ثواني عشان يفتح؟ ساعتها الحل مش إنك تقول “ووردبريس إلى متجر إلكتروني كامل: منتجات وسلة ودفع وشحن ومخزون وطلبات. تتوسع بإضافات لبوابات الدفع المحلية والشحن، وتمنحك ملكية كاملة لمتجرك…">WooCommerce تقيل” وتستسلم. البطء ده غالبًا له سبب محدد، وفي أغلب الحالات هو واحد من أربعة.
باختصار: صفحات السلة والدفع لا يمكن تخزينها مؤقتًا، وجدول الإعدادات متضخم، واستعلامات المنتجات تمر على جدول بيانات وصفية غير مفهرس، والإضافات تحمّل ملفاتها في كل صفحة. أما الاستضافة فهي آخر ما تغيّره، لا أوله.
لماذا يختلف المتجر عن المدونة؟
المقال في المدونة واحد لكل الزوار، فيُولَّد مرة واحدة ويُقدَّم من التخزين المؤقت للصفحات (Page Cache) للجميع. لذلك تكون المواقع التعريفية سريعة تقريبًا مهما كانت طريقة بنائها.
المتجر مختلف، لأن السلة شخصية. بمجرد أن يضيف الزائر منتجًا، يجب أن تعكس الصفحة حالته هو. لذلك تتجاوز صفحات السلة والدفع وحساب العميل الكاش تمامًا، وتشغّل PHP واستعلامات السيرفر.">قاعدة البيانات مع كل طلب.
وهذه بالضبط الصفحات التي يكلفك بطؤها مالًا مباشرة: صفحة تصنيف بطيئة تخسرك متصفحًا، وصفحة دفع بطيئة تخسرك مشتريًا. فالسؤال الصحيح ليس “هل موقعي سريع؟” بل “ما سرعته لزائر مسجل الدخول وفي سلته منتجات؟”
الأسباب الأربعة الحقيقية
1. جدول الإعدادات متضخم
يحمّل ووردبريس مجموعة من صفحة الدفع نفسها.">الإعدادات المحمّلة تلقائيًا (Autoloaded Options) من جدول wp_options مع كل طلب، والإضافات تضيف إليها بلا حساب. والإضافات التي حذفتها غالبًا تترك صفوفها خلفها.
في المتاجر القديمة قد يصل حجم هذه البيانات إلى عشرات الميغابايتات تُقرأ في كل صفحة، بما فيها صفحة الدفع. ابدأ بقياس الحجم الكلي:
SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');
لو الرقم بالميغابايت بدل الكيلوبايت، فقد وجدت وقتًا حقيقيًا ضائعًا. وهذا Elementor.">JetEngine تبني الاستعلامات بصريًا بمنشئ…">الاستعلام يعرض أكبر الصفوف لتعرف أي إضافة تقف وراءها:
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;
2. استعلامات المنتجات على بيانات وصفية غير مفهرسة
خزّن WooCommerce تاريخيًا خصائص المنتجات والأسعار والمخزون في جدول بيانات وصفية عام يشاركه مع كل شيء آخر. التصفية أو الترتيب في كتالوج كبير يعني ربط هذا الجدول مرات متكررة.
مع بضع مئات من المنتجات لن يلاحظ أحد. مع عشرات الآلاف، تصبح صفحات التصنيفات والفلاتر بطيئة جدًا. لهذا نقلت الإصدارات الأحدث بيانات الطلبات إلى جداول مخصصة عبر ميزة تخزين الطلبات عالي الأداء (HPOS)، وتفعيلها في متجر له سجل طلبات طويل يستحق التجربة وحده.
تجدها في: WooCommerce ← الإعدادات ← متقدم ← الميزات (Features). جرّبها أولًا على نسخة تجريبية (Staging)، لأن بعض الإضافات القديمة لا تدعمها.
3. إضافات تحمّل ملفاتها في كل مكان
المشكلة نادرًا ما تكون في عدد الإضافات، بل في أن أغلبها يحمّل ملفات CSS و JavaScript في كل صفحة بدل الصفحات التي يحتاجها فقط. إضافة حجوزات تستخدمها في صفحة واحدة قد تحمّل ملفاتها في صفحة الدفع.
الحل غير مبهر لكنه فعّال: راجع ما تحمّله كل إضافة، وألغِ تحميل ملفاتها خارج صفحاتها، واحذف أي إضافة لا تستطيع أن تقول بالضبط ماذا تفعل. مثال لإلغاء تحميل ملفات إضافة خارج صفحة بعينها (اسم الـ handle هنا افتراضي، استخرج الاسم الحقيقي من أداة مثل Query Monitor):
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'booking' ) ) {
wp_dequeue_script( 'booking-plugin-js' );
wp_dequeue_style( 'booking-plugin-css' );
}
}, 100 );
في Elementor: فعّل خيارات تحسين الأداء في Elementor ← الإعدادات ← الميزات، مثل تحميل الأصول بشكل محسّن (Improved Asset Loading)، وراجع إضافات Crocoblock المفعّلة: JetEngine يتيح تعطيل الوحدات (Modules) التي لا تستخدمها من لوحة إعداداته.
4. اتصالات خارجية بلا كاش
أسعار الشحن الحية، وحساب الضرائب، وتحويل العملات، والتحقق من المخزون في نظام خارجي، كلها طلبات شبكة تحدث أثناء تحميل الصفحة. لو المزود بطيء، صفحة الدفع بطيئة. ولو تعطّل، صفحة الدفع تتعطل.
وهذا شائع عندنا مع تكاملات شركات الشحن المحلية وبوابات الدفع مثل Paymob و Fawry، ومع إضافات تحويل العملة بين الجنيه والريال والدولار. كل اتصال خارجي في مسار الصفحة يحتاج مهلة (Timeout) قصيرة، وكاشًا، وبديلًا لو فشل.
ما الذي يساعد فعلًا؟ بالترتيب
اعمل بهذا التسلسل، لأن كل خطوة تغيّر ما يخبرك به القياس التالي.
| الترتيب | الخطوة | لماذا في هذا الموقع |
|---|---|---|
| 1 | التخزين المؤقت للكائنات (Redis) | يسرّع السلة والدفع التي لا يصلها كاش الصفحات |
| — | — | — |
| 2 | صيانة قاعدة البيانات | يزيل التضخم الذي يُقرأ مع كل طلب |
| 3 | الاستضافة | تفرق فعلًا بعد إصلاح ما سبق، لا قبله |
| 4 | الصور والملفات | تحسّن تجربة التحميل، لا زمن المعالجة على الخادم |
التخزين المؤقت للكائنات (Object Cache): يحفظ نتائج استعلامات قاعدة البيانات في الذاكرة، فيسرّع تحديدًا الصفحات التي لا يصلها كاش الصفحات. في المتاجر هو غالبًا أكبر تحسين متاح، وأكثر خطوة تُتجاهل لأن إضافة الكاش المثبتة توحي بأن المهمة انتهت. كثير من الاستضافات المُدارة توفر Redis بضغطة زر، فاسأل عنه قبل أن تغيّر الباقة.
صيانة قاعدة البيانات: احذف البيانات المؤقتة (Transients) المنتهية، والبيانات الوصفية اليتيمة لمنتجات وطلبات محذوفة، وقلّل مراجعات المقالات. اجعلها مهمة مجدولة لا عملية لمرة واحدة. لو عندك WP-CLI:
wp transient delete --expired
wp post delete $(wp post list --post_type=revision --format=ids) --force
ثم الاستضافة: بعد ضبط الكاش وقاعدة البيانات، تبدأ الاستضافة في الفرق فعلًا: إصدار PHP، والذاكرة المتاحة، وهل قاعدة البيانات على الخادم نفسه، وهل أنت على استضافة مشتركة تنافس فيها مواقع أخرى. نقل المتجر قبل ذلك ينقل المشكلة إلى عنوان أغلى فقط.
الملفات أخيرًا: صيغ الصور الحديثة والتحميل الكسول (Lazy Loading) وتأجيل السكربتات مفيدة، لكنها لا تفعل شيئًا لصفحة دفع تقضي 4 ثوانٍ في PHP قبل إرسال أول بايت.
كيف تقيس أداء المتجر صح؟
- اختبر حالة الزائر المسجل وفي سلته منتجات. أغلب أدوات القياس تختبر زائرًا مجهولًا على الصفحة الرئيسية، وهو أسرع مسار في موقعك ولا يخبرك شيئًا عن الدفع.
- افصل زمن الخادم عن زمن الواجهة. لو زمن وصول أول بايت (TTFB) 3 ثوانٍ، فلا تحسين للصور سينقذ الصفحة. هذا الرقم يحدد أي نصف من المشكلة تواجه.
- استخدم بيانات الزوار الحقيقيين. زوارك على شبكات الموبايل في مصر والخليج يرون صورة مختلفة عن اختبار من مركز بيانات في أوروبا، ومؤشرات Core Web Vitals تُقيَّم على بيانات الزوار الحقيقيين.
- راقب قاعدة البيانات أثناء طلب بطيء. إضافة مثل Query Monitor تكشف لو الاستعلام نفسه يتكرر 200 مرة في تحميل صفحة واحدة، وهو نمط شائع جدًا مع إضافات متعددة تطلب بيانات المنتج كلٌّ على حدة.
اقرأ أيضًا
الأسئلة الشائعة
س: لماذا متجري على WooCommerce بطيء رغم وجود إضافة كاش؟
ج: لأن كاش الصفحات لا يعمل على السلة والدفع وحساب العميل، فهي تشغّل PHP واستعلامات قاعدة البيانات مع كل طلب. تسريعها يحتاج كاش الكائنات وتنظيف قاعدة البيانات.
س: هل نقل المتجر لاستضافة أفضل يحل مشكلة البطء؟
ج: جزئيًا فقط، ولا يجب أن يكون الخطوة الأولى. لو جدول الإعدادات متضخم والإضافات تحمّل ملفاتها في كل مكان، فالاستضافة الأقوى ستنقل المشكلة نفسها بتكلفة أعلى.
س: كم إضافة تعتبر كثيرة على WooCommerce؟
ج: العدد أقل أهمية مما تحمّله كل إضافة. عشرون إضافة منضبطة تحمّل ملفاتها في صفحاتها فقط أخف من ثماني إضافات تحمّل سكربتاتها في كل الموقع.
س: ما هو Redis وهل أحتاجه لمتجري؟
ج: Redis أداة تخزين في الذاكرة تُستخدم ككاش للكائنات، وتسرّع الصفحات الديناميكية كالسلة والدفع. لأي متجر فيه طلبات يومية منتظمة، هو غالبًا أكبر تحسين متاح.
س: كيف أختبر سرعة متجر WooCommerce بشكل صحيح؟
ج: اختبر كزائر مسجل الدخول وفي سلته منتجات، وافصل زمن الخادم (TTFB) عن زمن الواجهة، واعتمد على بيانات الزوار الحقيقيين لا اختبارات المعمل فقط.
الخلاصة
متجرك مش بطيء عشان WooCommerce تقيل، هو بطيء لسبب تقدر تحدده وتقيسه. ابدأ بحجم الإعدادات المحمّلة تلقائيًا، وفعّل كاش الكائنات، ونظّف قاعدة البيانات، وبعد كده بس فكّر في الاستضافة. وجرّب النهارده تفتح صفحة الدفع وأنت مسجل دخول وفي السلة منتج، الرقم ده هو اللي بيفرق في مبيعاتك.
مرجع المقال (بالإنجليزية): WooCommerce Performance: Why Your Store Is Slow
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.
