لماذا يصبح موقع WordPress بطيئًا؟ 10 أسباب وحلولها

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

لتسريع WordPress، قِس الصفحات المتأثرة، وحدد مصدر التأخير، ثم عالج السبب وأعد الاختبار. ضغط الصور يفيد عندما تكون الصور هي المشكلة، لكنه لن يصلح استعلامًا بطيئًا في قاعدة البيانات أو طلبًا خارجيًا يعطل الـCheckout. هذا الدليل يطوّر مقالتي المنشورة على LinkedIn إلى مسار تشخيص عملي لمواقع WordPress وElementor ومتاجر WooCommerce.

من أين تبدأ؟ حدّد شكل البطء

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

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

1. الإضافات: قِس ما تفعله، لا عددها

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

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

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

2. الصور: متى يكتشف المتصفح صورة الواجهة؟

قد تكون الصورة بصيغة WebP ومع ذلك تتأخر. افحص حجمها وأبعادها ووقت بدء طلبها. صورة خلفية لا يكتشفها المتصفح إلا بعد تحميل CSS قد تؤخر ظهور المحتوى الأساسي حتى لو كان ملفها صغيرًا.

جهّز مقاسات تناسب العرض، واستخدم srcset وsizes لاختيار المورد المناسب. اضغط الصور مع مراجعة الجودة؛ WebP أو AVIF خياران مفيدان عندما تدعمهما أدوات الموقع. احجز أبعاد الصورة لتقليل حركة العناصر أثناء التحميل.

لا تطبق Lazy Loading على صورة LCP الأساسية. اترك التحميل الكسول للصور خارج الجزء المرئي، واستخدم fetchpriority="high" انتقائيًا عند الحاجة. إذا كان المورد الحرج يُكتشف متأخرًا، قيّم Preload ثم قِس أثره؛ رفع أولوية كل الصور يلغي فائدة تحديد الأولويات.

3. JavaScript: ظهور الصفحة لا يعني جاهزيتها

عندما تظهر الواجهة سريعًا لكن القائمة أو الفلاتر تستجيب ببطء، سجّل التفاعل نفسه داخل Chrome DevTools — Performance. افحص المهام الطويلة والوقت المستهلك في JavaScript وLayout وPaint، بدل الاكتفاء بحجم الملفات في Network.

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

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

4. Elementor: راجع بنية الصفحة والإضافات الملحقة

وجود Elementor لا يكفي لتفسير البطء. صفحة بسيطة وأخرى فيها Containers متداخلة وفيديو خلفية وWidgets من عدة إضافات لن تكون لهما التكلفة نفسها. راجع العناصر الفعلية، والملفات المحملة، ووقت العرض؛ لا تحذف أداة البناء قبل فهم ما يحدث.

تنبيه عند اتباع الشروحات القديمة: أعلن Elementor في الإصدار 3.21 دمج Improved Asset Loading وOptimize Image Loading ضمن النواة. لذلك قد لا تجد مفتاح التفعيل القديم في نسختك. اتبع توثيق الإصدار الموجود عندك، ولا تعتبر اختفاء المفتاح عطلًا.

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

5. الاستضافة: افحص الاختناق قبل الترقية

إذا تأخر أول بايت، راجع زمن الاستجابة واستهلاك الموارد والطلبات البطيئة. TTFB يتأثر بالشبكة وإعادة التوجيه والكاش ومعالجة الخادم؛ ليس قياسًا مباشرًا لسرعة PHP وحدها. اطلب من الاستضافة مؤشرات CPU والذاكرة والعمليات المتزامنة وقت المشكلة.

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

الترقية تكون منطقية عندما تثبت أن الموارد لا تكفي للحمل المطلوب. احتفظ بالقياسات قبلها وبعدها؛ وإلا قد تدفع أكثر وتبقى المشكلة البرمجية كما هي.

6. قاعدة البيانات: الاستعلام أهم من الحجم وحده

تراكم Revisions وTransients وOptions وبيانات الإضافات يستحق المراجعة، لكنه لا يثبت وحده سبب البطء. ابحث عن الاستعلام البطيء أو المكرر، ومن يستدعيه، وعدد مرات تنفيذه. راجع أيضًا بيانات Autoload التي تُحمّل تلقائيًا، خاصة عندما تنمو بلا حاجة واضحة.

لا تحذف محتويات wp_options أو جداول المتجر بهدف «التنظيف» دون معرفة وظيفة البيانات. خذ نسخة احتياطية قابلة للاستعادة، واختبر التنظيف على Staging. وفي المتجر النشط، ضع الطلبات الجديدة في حساب خطة الرجوع حتى لا تفقدها عند استعادة نسخة قديمة.

حسّن الاستعلام المخصص قبل إضافة Index عشوائي. واختبر Persistent Object Cache عندما تتوافق معه بيئة الاستضافة وحاجة الموقع؛ وجود Redis وحده لا يضمن الاستفادة إذا لم يتصل به WordPress بصورة صحيحة.

7. أدوات الطرف الثالث: ماذا أضفت بعد إطلاق الموقع؟

محادثة مباشرة، خريطة، فيديو مضمّن، ثم عدة Pixels: إضافات صغيرة في ظاهرها قد تتراكم. رتّب الطلبات في Network بحسب النطاق، واربطها بالوقت المستهلك في Performance. راجع ما يحتاجه الزائر فورًا وما يمكن تحميله عند الاستخدام.

راجع مع فريق التسويق طريقة تثبيت أدوات القياس. وضع Pixel مباشرة وعبر GTM معًا قد يكرر التنفيذ والأحداث إذا لم تضبطه. لا تُلغِ التتبع لتحقيق نتيجة أفضل في تقرير فقط؛ اختبر أن الأحداث المطلوبة ما زالت تعمل مرة واحدة وبالبيانات الصحيحة، مع مراعاة إعدادات الموافقة.

للخرائط والفيديوهات غير الأساسية، يمكن استخدام معاينة خفيفة تفتح التضمين عند الطلب. قِس الفرق، ووضّح للزائر زر التشغيل بدل تحميل كل الخدمات عند أول زيارة.

8. الكاش: أي طبقة تحتاجها الصفحة؟

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

في WooCommerce، يجب أن تبقى صفحات Cart وCheckout وMy Account ديناميكية وألا تُقدَّم بياناتها الشخصية من كاش مشترك. تحقق من الاستثناءات في جميع الطبقات، ومن تغير السعر والمخزون والسلة بصورة صحيحة. صفحة سريعة تعرض سلة شخص آخر ليست تحسينًا.

9. WooCommerce: اختبر العملية البطيئة نفسها

هل يتأخر فلتر المنتجات، أم تغيير العنوان، أم حساب الشحن، أم إنشاء الطلب؟ كل عملية لها مسار مختلف. راجع طلبات AJAX أو Store API المستخدمة في واجهتك، وسجلات WooCommerce والمهام المجدولة المتأخرة أو الفاشلة. لا تفترض أن سرعة الرئيسية تصف تجربة الشراء.

HPOS ينقل تخزين الطلبات إلى جداول مخصصة، وأصبح مستقرًا وافتراضيًا للتثبيتات الجديدة بدءًا من WooCommerce 8.2 في أكتوبر 2023. المتجر القديم يحتاج فحص توافق الإضافات ومزامنة البيانات وخطة رجوع قبل النقل. استفد من WooCommerce CRUD APIs في التخصيصات بدل افتراض مكان تخزين الطلب.

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

10. PageSpeed: اقرأ المؤشرات قبل مطاردة الدرجة

Lab Data اختبار في ظروف محددة، وField Data قياسات مستخدمين فعليين عندما تتوفر بيانات كافية. لا تتوقع أن تتطابق النتيجتان، ولا تعتبر عدم وجود بيانات ميدانية دليلًا على نجاح الموقع أو فشله.

تُقيّم هذه الحدود عند الشريحة المئوية 75، مع فصل الهاتف عن الكمبيوتر. TTFB مؤشر تشخيصي مساعد وليس أحد المؤشرات الثلاثة. واختبار تحميل Lighthouse المعتاد لا يقيس INP مباشرة؛ يحتاج التفاعل إلى قياس مناسب، ويمكن الاستفادة من TBT كمؤشر معملي مساعد.

خطة مراجعة عملية: من القياس إلى المتابعة

1. سجّل خط البداية: اختر الرئيسية وصفحة خدمة أو مقال، وفي المتجر أضف التصنيف والمنتج والسلة والدفع. دوّن ظروف القياس والنتائج.
2. ضع فرضية محددة: مثل «سكريبت المحادثة يؤخر التفاعل على الهاتف». اختر الأداة التي يمكنها إثباتها أو نفيها.
3. اعزل السبب: غيّر مكوّنًا واحدًا على Staging وقارن بنفس الحالة. راجع أيضًا مهام الخلفية إن ارتبط البطء بوقت معين.
4. طبّق التعديل: ابدأ بما يجمع أثرًا واضحًا ومخاطر أقل، مع طريقة رجوع موثقة.
5. اختبر الوظيفة: راجع النماذج والتتبع والدخول والسلة والدفع، ثم أعد قياس الأداء.
6. تابع التراجع: قارن بعد تحديث الإضافات أو إدخال أدوات جديدة، وليس بعد تغيير التصميم فقط.

إذا احتجت System Cron بدل التشغيل الافتراضي لـWP-Cron، جهّز الجدولة وتحقق من عملها قبل تعطيل المحفز القديم. مهام الطلبات والبريد ليست مكانًا لتجربة إعداد منسوخ دون مراجعة.

أسئلة تتكرر عن تسريع WordPress

هل إضافة Cache واحدة تكفي؟

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

لماذا الموقع سريع عندي وبطيء عند العميل؟

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

هل الوصول إلى 100 في PageSpeed يضمن الترتيب؟

لا. نتيجة الاختبار لا تضمن ترتيبًا في البحث ولا تعوض ضعف المحتوى. اهتم بسرعة الاستخدام الفعلية، مع صفحات تجيب عن حاجة الزائر وتعمل وظائفها بصورة صحيحة.

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

حسام حامد

Web Developer

ناقش مشروعك معي