تشخيص بطء ووردبريس هو الخطوة التي يجب أن تسبق أي محاولة للتسريع. إذا بدأت بتغيير إعدادات Cache وCSS وJavaScript قبل أن تعرف أين يوجد الاختناق، فقد تحصل على تحسن مؤقت، أو تكسر وظيفة في الموقع، أو تخفي المشكلة الحقيقية بدل حلها.
الخلاصة السريعة: حدّد أولًا أين يظهر البطء: قبل وصول HTML؟ أثناء عرض المحتوى؟ عند التفاعل؟ داخل wp-admin؟ أم فقط في WooCommerce؟ بعد ذلك اربط العَرَض بالمقياس والأداة المناسبة. لا تبدأ الحل قبل أن تستطيع وصف المشكلة بجملة قابلة للقياس.
هذه الصفحة مخصصة لـDiagnosis فقط. بعد تحديد السبب، استخدم الدليل الشامل لتسريع ووردبريس وتحسين Core Web Vitals لتنفيذ الإصلاح المناسب. هذا الفصل يمنع تنافس صفحتين على نفس نية البحث ويعطيك مسارًا واضحًا: تشخيص هنا، تنفيذ هناك.
كيف تعرف أن المشكلة من WordPress فعلًا؟
قبل الدخول إلى الإضافات وقاعدة البيانات، افصل بين أربعة أنواع من البطء:
| النوع | ما الذي تلاحظه؟ | الاحتمال الأكبر |
|---|---|---|
| بطء قبل ظهور الصفحة | المتصفح ينتظر قبل وصول أول محتوى | TTFB، Server، PHP، Database، Redirects |
| بطء أثناء العرض | HTML يصل لكن Hero أو النص يتأخر | LCP، CSS، Fonts، Images |
| بطء عند التفاعل | النقر أو القائمة أو Add to Cart يتأخر | INP، JavaScript، Main Thread |
| بطء داخل الإدارة | wp-admin أو حفظ المنتجات بطيء | Queries، autoload، cron، Action Scheduler، Plugins |
المرحلة 1: أنشئ Baseline يمكن الرجوع إليه
اختر 4 إلى 6 صفحات تمثل الموقع بدل اختبار الصفحة الرئيسية وحدها:
- Homepage.
- مقال طويل.
- صفحة خدمة أو Landing Page.
- صفحة منتج WooCommerce.
- Product Category.
- صفحة ديناميكية للمستخدم المسجل إذا كانت مهمة لنشاطك.
سجل لكل صفحة: TTFB، LCP، INP أو مؤشرات JavaScript القريبة منه في المختبر، CLS، حجم الصفحة، عدد Requests، وهل الاختبار Warm Cache أم Cold Cache. إذا لم تفهم الفرق بين Field Data وLab Data فابدأ من دليل قياس سرعة الموقع.
المرحلة 2: افحص TTFB أولًا
إذا كان TTFB مرتفعًا، فكل تحسين Frontend سيبدأ متأخرًا أصلًا. قارن النتائج في ثلاثة سيناريوهات:
- زيارة عامة لأول مرة.
- زيارة عامة بعد امتلاء Page Cache.
- زيارة كمستخدم مسجل حيث Page Cache غالبًا لا يعمل بنفس الطريقة.
إذا تحسن السيناريو الثاني بشدة، فالخادم أو تنفيذ WordPress نفسه هو الجزء المكلف لكن Page Cache يخفيه للزوار. إذا بقي المستخدم المسجل بطيئًا، راقب Database وObject Cache والإضافات التي تعمل لكل Request.
علامات أن الخادم هو الاختناق
- TTFB مرتفع في معظم الصفحات، حتى الصفحات البسيطة.
- الأداء يتدهور وقت الزيارات المرتفعة فقط.
- CPU أو RAM أو PHP workers تصل حدودها.
- الصفحات غير المخزنة أبطأ كثيرًا من النسخ المخبأة.
المرحلة 3: هل البطء من Plugin أم Theme؟
لا تستخدم قاعدة «عدد الإضافات = البطء». إضافة واحدة سيئة قد تكون أثقل من عشر إضافات صغيرة. ابحث عن الأثر:
- Requests أو Scripts تظهر في كل صفحة بلا حاجة.
- Queries كثيرة أو مكررة.
- HTTP calls خارجية أثناء الطلب.
- Widgets في Elementor أو Theme Components تحمل Assets كبيرة.
- Admin hooks تعمل في كل شاشة.
إذا توفر Staging، عطّل المشتبه به هناك وقارن نفس الصفحة ونفس السيناريو. لا تعطل إضافة دفع أو أمان أو WooCommerce عشوائيًا على Production لمجرد الاختبار.
المرحلة 4: افحص LCP وحدد العنصر نفسه
لا تقل «LCP سيئ» ثم تضغط كل الصور. استخدم DevTools أو PageSpeed لمعرفة عنصر LCP. بعد ذلك اسأل:
- هل هو Hero Image بحجم أكبر من المطلوب؟
- هل عليه Lazy Load وهو أول عنصر رئيسي؟
- هل يبدأ تحميله متأخرًا بسبب CSS أو JavaScript؟
- هل النص نفسه يتأخر بسبب Web Font؟
- هل TTFB أكل جزءًا كبيرًا من ميزانية LCP قبل أن يبدأ العنصر؟
إذا كان العنصر محددًا وواضحًا، انتقل إلى تشخيص وتحسين LCP وCLS في WordPress.
المرحلة 5: شخّص INP والبطء عند النقر
قد تحمل الصفحة بسرعة ثم تتأخر القائمة أو البحث أو Add to Cart. هنا لا تركز على الصور؛ ركز على JavaScript والمهام الطويلة.
اختبارات مفيدة
- جرّب الصفحة بدون Chat/Heatmap/Tracking غير الضروري على Staging.
- افحص Long Tasks في Performance panel.
- حدد Script الذي يعمل بعد Click وليس فقط أثناء Load.
- اختبر Variation selectors وMini Cart وSearch وMenu كل منها منفصلًا.
للمشكلة المتخصصة استخدم دليل تشخيص تأخر التفاعل وتحسين INP.
المرحلة 6: افصل مشكلة CLS عن «السرعة»
القفزات البصرية تحدث عندما تتغير مساحة عنصر بعد بدء العرض. افحص الصور بلا أبعاد، Fonts، Banners، Cookie bars، إعلانات، Embeds وأي Component يدخل أعلى المحتوى متأخرًا. لا تعالج CLS بإضافة Cache؛ عالج مصدر تغير Layout.
المرحلة 7: متى تكون قاعدة البيانات هي المشكلة؟
علامات Database bottleneck تشمل بطء wp-admin، صفحات ديناميكية أبطأ من العامة، Queries متكررة، Search/Filters ثقيلة، أو تأخر حفظ المنتجات والطلبات.
- افحص Slow Queries بدل حذف جداول أو Transients بصورة عمياء.
- راجع autoloaded options إذا كانت كبيرة أو تحتوي بيانات إضافات قديمة.
- راقب WP-Cron وAction Scheduler عند وجود Tasks متراكمة.
- لا تنفذ Cleanup قبل Backup وفهم مالك البيانات.
إذا كان الاشتباه في قاعدة البيانات، انتقل إلى دليل تحسين قاعدة بيانات WordPress بأمان.
المرحلة 8: تشخيص WooCommerce كمنظومة منفصلة
إذا كانت المقالات سريعة والمتجر بطيئًا، لا تعمم المشكلة على WordPress كله. اختبر:
- Product page بسيطة مقابل منتج Variations كثيرة.
- Category بدون Filters مقابل Category بفلاتر Attributes.
- Cart وCheckout بدون Cache.
- My Account كمستخدم مسجل.
- Admin orders وAction Scheduler.
إذا كان الاختناق من الاستعلامات والفلاتر والمنتجات، استخدم دليل تشخيص استعلامات WooCommerce البطيئة.
شجرة قرار لتحديد سبب بطء WordPress
| السؤال | إذا كانت الإجابة نعم | الخطوة التالية |
|---|---|---|
| هل TTFB مرتفع في كل الصفحات؟ | Backend/Server محتمل | PHP، DB، Cache، Hosting |
| هل TTFB جيد لكن LCP سيئ؟ | Frontend/LCP asset محتمل | Hero، CSS، Font، preload |
| هل الصفحة سريعة قبل أول تفاعل ثم تتأخر؟ | JavaScript/INP محتمل | Long Tasks وThird Parties |
| هل المشكلة فقط للمستخدم المسجل؟ | Uncached dynamic path | DB، Object Cache، Plugins |
| هل المشكلة فقط في WooCommerce؟ | Commerce-specific | Queries، Filters، Sessions، Scheduler |
| هل wp-admin أبطأ من الواجهة؟ | Admin hooks/DB/tasks | autoload، cron، plugins |
أخطاء تجعل التشخيص غير موثوق
- اختبار صفحة واحدة فقط.
- مقارنة Mobile test بـDesktop test وكأنهما نفس السيناريو.
- تغيير Cache وCDN والصور وJS معًا ثم الادعاء بمعرفة سبب التحسن.
- استخدام نتيجة Lighthouse واحدة كحقيقة عن كل المستخدمين.
- اختبار Production أثناء حملة إعلانية ثم مقارنته بوقت هادئ.
- تجاهل المستخدمين المسجلين وCheckout لأن الصفحة الرئيسية سريعة.
- حذف بيانات Database قبل معرفة الإضافة التي أنشأتها.
متى تنتقل من التشخيص إلى التنفيذ؟
انتقل عندما تستطيع كتابة نتيجة بهذا الشكل: «صفحات المقالات العامة لديها TTFB جيد، لكن LCP يتأخر لأن Hero image يبدأ تحميله بعد CSS»، أو «المستخدمون المسجلون يعانون من TTFB مرتفع مع Queries متكررة، بينما Page Cache يخفي المشكلة للزوار». عندها لديك Hypothesis قابلة للاختبار، وليست قائمة نصائح عامة.
بعد تحديد السبب، طبق الإصلاح من خطة تسريع WordPress الشاملة، ثم أعد نفس الاختبار للمقارنة.
أسئلة شائعة عن تشخيص بطء WordPress
كيف أعرف هل الاستضافة هي سبب البطء؟
إذا كان TTFB مرتفعًا في صفحات بسيطة، أو الأداء ينهار مع الحمل، أو PHP workers وCPU تصل حدودها، فالاستضافة أو إعداد الخادم مرشح قوي. لكن افحص Queries والإضافات أيضًا قبل ترقية الخطة؛ لأن خادمًا أقوى قد يخفي كودًا غير فعال بدل إصلاحه.
هل كثرة الإضافات تعني أن الموقع بطيء؟
ليس بالضرورة. المهم ما الذي تنفذه الإضافات على الصفحة الحالية. قِس Queries وScripts وHTTP calls بدل العد فقط.
لماذا الموقع سريع للزائر وبطيء داخل wp-admin؟
لأن Page Cache يحسن الصفحات العامة بينما wp-admin ديناميكي. هنا افحص قاعدة البيانات وautoload والمهام المجدولة والإضافات التي تضيف Admin hooks.
هل يمكن أن تكون نتيجة PageSpeed ضعيفة والموقع مقبول فعليًا؟
نعم، لأن اختبار المختبر سيناريو اصطناعي. قارن النتائج بField Data، لكن لا تتجاهل التحذيرات؛ استخدمها لتحديد أين تبحث.
الخلاصة
تشخيص بطء ووردبريس يعني تحويل الشكوى «الموقع بطيء» إلى مشكلة محددة قابلة للقياس. افصل Backend عن Frontend، والتحميل عن التفاعل، والصفحات العامة عن المستخدمين المسجلين، وWordPress العام عن WooCommerce. عندما تحدد طبقة الاختناق، يصبح التسريع أقل خطورة وأكثر قابلية لإثبات النتيجة.
9 تعليقات