كيف حسنت أداء متجري على ووكومرس باستخدام إضافة Query Monitor

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

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

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

ما هي إضافة Query Monitor؟

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

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

عندما تنقر على هذا الملخص، ستظهر واجهة Query Monitor بالكامل، حيث تظهر على شكل نافذة عائمة على الصفحة، سواء كانت صفحة أمامية أو خلفية، وتظهر المعلومات ضمن تبويبات حيث يمكن التنقل بينها، فهناك تبويب لأخطاء PHP وآخر لاستعلامات قاعدة البيانات، وآخر للسكربتات وغيرها.

كيف استفدت من إضافة Query Monitor لتحسين سرعة المتجر؟

لقد كانت الإضافة مفيدة لي في ثلاث جوانب رئيسية وهي:

استعلامات قاعدة البيانات

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

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

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

أخطاء PHP

تظهر واجهة Query Monitor أخطاء PHP في تبويبين هما PHP errors و Doing it Wrong، ويكمن الاختلاف بينهما في أن أخطاء PHP errors يبلغ عنها مفسر PHP، وهي خطأ في منطق شيفرة PHP نفسها، أما أخطاء Doing it Wrong فهي أخطاء خاصة بووردبريس نفسه، أي أنها متعلقة بدوال وميزات ووردبريس الأساسية.

في الموقع الذي عملت عليه ظهرت مجموعة من الأخطاء في PHP errors، كان سبب أحدها وجود تعريف لأحد الثوابت مرتين في ملف wp-config.php، ولحله أزلت التعريف الثاني للثابت من الملف، وكان اثنين من الأخطاء عبارة عن تنبيهات PHP، حيث يتم استدعاء دوال strpos و str_replace بطريقة غير صحيحة.

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

كما أظهرت الإضافة خطأ رابع مكتوم (Suppressed) خاص بإضافة دفع في ووكومرس، بمعنى أن مطور الإضافة حاول إخفاء الخطأ، لكن الإضافة تمكنت من رصده بالرغم من ذلك، وكان الحل هنا بالتواصل مع مطور الإضافة لحل الخطأ.

وبطرق مشابهة حللت أخطاء Doing it Wrong، فقد كان هناك إضافة لا تتكامل مع Elementor بشكل صحيح، وكان الحل باستبدال تلك الإضافة بأخرى تؤدي نفس المهمة.

وجود سكربتات غير ضرورية في كل الصفحات

بعد حل أخطاء PHP، تفحصت السكربتات التي يتم تحميلها في كل أنواع صفحات المتجر عبر زيارة كل نوع صفحة وإظهار واجهة الإضافة والانتقال إلى Scripts، فكان واضحًا لي أن بعض السكربتات تُحمَّل دون داع في بعض الصفحات، فمثلًا في الصفحة الرئيسية، كانت يتم تحميل سكربتات بوابات الدفع مثل Taby و Tamara، وسكربتات الرد على التعليقات، وغيرها.

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

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

الجدير بالذكر أن هناك إضافات تسمح لك بتقييد تحميل السكربتات مثل إضافة Asset CleanUp، لكنها للأسف لم تنفع عندما جربتها، إذ لا توفر خيارات تحكم كافية في الإصدارات المجانية، فمثلًا إمكانية منع تحميل سكربت في كافة الصفحات ووضع استثناءات خيارٌ غير متوفر إلا في الإصدارات المدفوعة، ولم يكن العميل يود شراء إضافة، لهذا اتبعت الحل البرمجي.

تحسن أداء المتجر الإلكتروني

بعد تطبيق الإصلاحات السابقة والدقيقة، كانت النتائج جيدة، لكنني لم أكتفِ فقط بحل المشاكل التي كشفتها الإضافة، بل اتبعت أيضًا التوصيات المتبقية التي أوردتها أداة Google PageSpeed Insights، وبذلك أصبحت سرعة الموقع ممتازة، فقد كانت هذه نتيجة الأداء قبل العمل.

ثم أظهرت الأداة تحسنًا كبيرًا في الأداء، وكانت هذه النتيجة.

نصائح لقراءة بيانات Query Monitor

يمكن أن تبدو البيانات التي تقدمها إضافة Query Monitor مربكة في البداية، ولذلك إليك بعض التلميحات التي يمكن أن تفيدك في قراءتها وتحديد المشاكل:

• الاستعلامات البطيئة والعدد الكبير من الاستعلامات: أي استعلام يتجاوز وقته 0.5 ثانية يستدعي التدقيق، وأي عدد كبير من الاستعلامات المتشابهة دون مبرر واضح تستدعي التدقيق أيضًا.
• أخطاء PHP: الأخطاء الفادحة يمكن أن تعطل موقعك بالكامل أو جزءًا منه، أما التحذيرات، فقد تبطؤه وتدل على كود رديء، لذلك لا تتجاهلها وأصلحها.
• تأثير السكربتات على الأداء: تؤثر السكربتات بشدة على أداء الموقع، ولهذا عليك تدقيق كافة السكربتات في كافة أنواع صفحات الموقع، ثم عليك حظر السكربتات في الصفحات التي لا داعي لتحميلها فيها.
• عدد الاستعلامات الكبير: ليس لعدد الاستعلامات أهمية، فالعدد الكبير من الاستعلامات طبيعي، لكن الأهم هو وقت الاستعلام، فاستعلام بطيء قد يكون أسوأ من 100 استعلام سريع.
• إشعارات بسيطة: من الممكن أن تولد بعض الإضافات الموثوقة إشعارات بسيطة أو Notices كجزء من أخطاء PHP، وهذه الإشعارات عادة لا تؤثر على الأداء، وإذا كان إصلاحها صعبًا فلا مشكلة في تركها.

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