تشخيص بطء TTFB في ووردبريس طبقة بطبقة

أداة القياس قالتلك إن الـ ووردبريس للمحتوى المؤرخ مثل التدوينات والأخبار والشروحات. تُرتّب زمنيًا وتُنظَّم بالتصنيفات والوسوم وتظهر في الأرشيف وخلاصات RSS، بخلاف الصفحات الثابتة.">الصفحة ووصول أول بايت من السيرفر. إذا تجاوز 600 مللي ثانية فغالباً تُبنى الصفحة من قاعدة البيانات مع كل زيارة، والحل يبدأ بالكاش…">TTFB عندك 1.8 ثانية، وخلاص. طيب وبعدين؟ الرقم ده لوحده مش بيقولك تعمل إيه — ممكن يكون اسم النطاق مثل arabcms.com إلى عنوان IP السيرفر الذي يستضيف الموقع. أي تعديل في سجلاته قد يحتاج ساعات…">DNS، وممكن يكون استعلام واحد غبي في قاعدة البيانات. أغلب الناس بتبدأ تجرب حاجات عشوائية وتخسر يومين. الترتيب اللي جاي بيوفّر عليك الوقت ده.

الرقم إشارة، مش تشخيص

زمن أول بايت (TTFB) هو المدة بين طلب المتصفح للصفحة ووصول أول بايت من الرد. المشكلة أن هذه المدة تجمع داخلها مراحل مختلفة تماماً: البحث عن الدومين، فتح الاتصال، تفاوض TLS، ثم عمل السيرفر نفسه.

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

القاعدة العملية: لا تبدأ بالإصلاح قبل أن تحدد الطبقة. الترتيب في هذا الدليل مقصود — كل خطوة تستبعد احتمالات قبل الانتقال للتالية.

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

الطبقة الأولى: اصنع قياساً قابلاً للتكرار

قياس واحد لا يعني شيئاً. تحتاج رقماً تستطيع تكراره قبل التعديل وبعده، وإلا فلن تعرف هل تحسّن الموقع فعلاً أم أن الشبكة كانت مزدحمة لحظتها.

استخدم curl لتفكيك الزمن إلى مراحله:

curl -sS -o /dev/null 
  -w 'dns=%{time_namelookup}nconnect=%{time_connect}ntls=%{time_appconnect}nttfb=%{time_starttransfer}ntotal=%{time_total}n' 
  https://example.com/

كرّر الأمر خمس مرات على الأقل وسجّل النتائج. إذا كان dns وحده يستهلك جزءاً كبيراً من الزمن، فالمشكلة عند مزوّد الـ DNS ولا علاقة لها بووردبريس من الأساس.

لفحص ترويسات الرد ومعرفة هل وصلتك نسخة مخزّنة أم لا:

curl -I https://example.com/

ابحث في الناتج عن ترويسات مثل x-cache أو cf-cache-status. وجود HIT يعني أن الرد جاء من الكاش ولم يلمس PHP إطلاقاً.

الطبقة الثانية: قارن الزيارة المخزّنة بغير المخزّنة

هذه أهم مقارنة في الدليل كله، لأنها تفصل بين مشكلة في التطبيق ومشكلة في البنية التحتية.

اطلب الصفحة مرتين: مرة عادية، ومرة بإضافة معامل عشوائي للرابط لتجاوز الكاش (مثل ?nocache=123). ثم قارن.

الجدول أعلاه يختصر أغلب الحالات. استخدمه لتضييق دائرة البحث قبل أن تفتح أي ملف.

الطبقة الثالثة: هل السيرفر مخنوق أصلاً؟

قبل اتهام إضافة بعينها، تأكد أن المورد نفسه متاح. راقب استهلاك المعالج والذاكرة وقرص التخزين، والأهم: عمال PHP (PHP Workers).

عامل PHP هو عملية واحدة تنفّذ طلباً واحداً في وقت واحد. إذا كان لديك أربعة عمال ووصلت خمسة طلبات، فالطلب الخامس ينتظر في الصف — ويظهر لك كـ TTFB مرتفع رغم أن الكود سليم تماماً.

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

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

الطبقة الرابعة: إصدار PHP و OPcache

تحقق من أمرين: أن إصدار PHP حديث، وأن OPcache مفعّل فعلاً.

OPcache يحتفظ بنسخة مترجمة من ملفات PHP في الذاكرة بدلاً من إعادة ترجمتها مع كل طلب. تعطيله يضاعف زمن التنفيذ بلا سبب.

php -i | grep -i 'opcache.enable|opcache.memory_consumption|opcache.validate_timestamps'

إذا ظهرت القيمة opcache.enable => Off، فقد وجدت مكسباً سريعاً. وإذا كانت memory_consumption صغيرة على موقع كبير، فالذاكرة تمتلئ ويُطرد الكود منها باستمرار.

الطبقة الخامسة: قاعدة البيانات والخيارات التلقائية

الخيارات التلقائية (الإضافات المحذوفة حتى تصل لميغابايتات تُبطئ كل صفحة في الموقع بما فيها صفحة الدفع نفسها.">Autoloaded Options) هي صفوف في جدول wp_options يقرأها ووردبريس مع كل طلب دون استثناء. الإضافات المحذوفة تترك خلفها بيانات هنا، فينتفخ الحجم بصمت.

قِس الحجم الكلي أولاً:

wp option list --autoload=on --format=total_bytes

ثم استخرج أكبر عشرين صفاً:

wp option list --autoload=on --fields=option_name,size_bytes 
  | sort -n -k 2 
  | tail -20

القاعدة المتعارف عليها: أقل من 800 كيلوبايت مقبول، وما فوق ذلك يستحق المراجعة. ابحث عن أسماء تخص إضافات لم تعد مثبتة — هذه أول ما تُنظَّف.

لتسجيل الاستعلامات نفسها، أضف هذا السطر إلى wp-config.php على بيئة الاختبار فقط:

define( 'SAVEQUERIES', true );

تنبيه: لا تترك SAVEQUERIES مفعّلاً على موقع حي. هو نفسه يستهلك ذاكرة ويبطئ الموقع.

الطبقة السادسة: الإضافات والقالب

الآن فقط — بعد استبعاد ما سبق — يأتي دور الإضافات. ابدأ بجرد ما هو مفعّل:

wp plugin list --status=active

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

بعد الانتهاء من الإضافات، بدّل القالب مؤقتاً إلى قالب افتراضي وقِس مجدداً — أحياناً يكون JetEngine تبني الاستعلامات بصريًا بمنشئ…">الاستعلام الثقيل في ملف functions.php وليس في إضافة.

في Elementor: القوالب المبنية بـ Elementor Pro و JetEngine تستدعي استعلامات عند العرض. لو كان قالب الأرشيف بطيئاً وحده بينما الصفحة الرئيسية سريعة، راجع إعدادات الـ Query Builder (منشئ الاستعلامات) في ذلك القالب تحديداً قبل أن تتهم الإضافات كلها.

الطبقة السابعة: الكرون والمهام الخلفية

ووردبريس ينفّذ مهامه المجدولة عبر wp-cron.php، الذي يعمل بشكل افتراضي عند زيارة الموقع. النتيجة: زائر عشوائي يتحمّل تكلفة تنفيذ مهمة ثقيلة، ويرى صفحة بطيئة بلا ذنب.

اعرض المهام المجدولة:

wp cron event list --fields=hook,next_run_relative,recurrence

ابحث عن مهام متراكمة أو متكررة كل دقيقة. الحل المعتاد: تعطيل الكرون الافتراضي وربطه بـ cron حقيقي على مستوى السيرفر كل خمس دقائق.

الطبقة الثامنة: استدعاءات API الخارجية

أي استدعاء متزامن لخدمة خارجية أثناء بناء الصفحة يضيف زمن استجابة تلك الخدمة إلى زمن صفحتك. حاسبة الشحن، مزامنة المخزون، عدّاد متابعين — كلها مرشحة.

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

زاوية إقليمية: المسافة ليست عذراً دائماً

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

عملياً: اختر داتا سنتر في فرانكفورت أو أوروبا لقرب أكبر من مصر والخليج، وضع Cloudflare أمام الموقع لتقصير المسافة على الأصول الثابتة. الاستضافة القريبة جرّب Hostinger توفّر لك عشرات الملي ثانية مجاناً قبل أي تحسين برمجي.

لكن انتبه: لو كان ttfb مرتفعاً بينما connect و tls منخفضان في قياس curl، فالمسافة ليست السبب — السيرفر نفسه بطيء، وتغيير الاستضافة الجغرافي لن يحل شيئاً.

الأسئلة الشائعة

س: ما هو الرقم الجيد لـ TTFB؟
ج: أقل من 200 مللي ثانية ممتاز، وحتى 500 مللي ثانية مقبول لموقع ديناميكي. ما فوق 800 مللي ثانية يستحق التشخيص. الأهم من الرقم المطلق هو ثباته عبر القياسات المتكررة.

س: هل إضافة الكاش تحل مشكلة TTFB؟
ج: تحلها للزوار غير المسجّلين فقط. الصفحات التي لا يمكن تخزينها — السلة، صفحة الدفع، لوحة العضو — تمر بـ PHP وقاعدة البيانات في كل مرة، فتظل بطيئة رغم الكاش.

س: كيف أعرف أن المشكلة من الاستضافة وليست من موقعي؟
ج: قارن زمن connect و tls بزمن ttfb في أمر curl. لو كان الاتصال سريعاً والانتظار طويلاً، فالبطء داخل السيرفر أو التطبيق وليس في الشبكة.

س: ما حجم الخيارات التلقائية الذي يُعتبر خطراً؟
ج: تجاوز 800 كيلوبايت يستحق المراجعة، وتجاوز 2 ميجابايت يعني تأثيراً ملموساً على كل طلب. نظّف أولاً البيانات التي تركتها إضافات لم تعد مثبتة.

س: هل يستحق الانتقال إلى VPS؟
ج: يستحق إذا أثبت التشخيص أن العمال أو الذاكرة هما القيد الفعلي. أما لو كان السبب استعلاماً ثقيلاً أو إضافة سيئة، فالـ VPS سينقل المشكلة معه إلى سيرفر أغلى.

الخلاصة

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

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

مرجع المقال (بالإنجليزية): A layer-by-layer workflow to find whether slow WordPress TTFB comes from DNS, caching, PHP workers, database queries, plugins, or cron jobs
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.