شرح TTFB: كيف تقيس وقت استجابة السيرفر وتحسّنه

وقت تحميل صفحتك يتكوّن من خطوات كثيرة. لكن هناك مقياس واحد يقع في بداية السلسلة كلها ويؤثر على كل ما يأتي بعده: Time to First Byte، أو اختصاراً TTFB.

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

إليك ما يسبب بطء TTFB، وكيف تقيسه بدقة، وما الذي يجب فعله حيال ذلك بالضبط.

ما الذي يقيسه TTFB فعلاً؟

TTFB هو الوقت الذي يمر بين إرسال المتصفح لطلب HTTP واستلامه أول byte من الاستجابة. يشمل هذا ثلاثة أشياء تحدث بالتسلسل:

• DNS lookup — تحويل اسم النطاق إلى عنوان IP
• TCP connection + TLS handshake — إنشاء اتصال آمن بالسيرفر
• Server processing time — وقت السيرفر في توليد الاستجابة وبدء إرسالها

تصنّف إرشادات Google's Core Web Vitals قيمة TTFB بأنها جيدة إذا كانت أقل من 800ms، وتحتاج إلى تحسين بين 800ms و1800ms، وضعيفة إذا تجاوزت 1800ms. لكن واقعياً، يجب أن تستهدف أقل من 200ms لمعظم الصفحات، وأقل من 500ms حتى للمحتوى الديناميكي الذي يعتمد على قاعدة البيانات.

كيف تقيس TTFB بشكل صحيح

قياس TTFB مرة واحدة والاكتفاء بذلك سيقودك إلى استنتاجات خاطئة. الطلب الأول بعد إعادة تشغيل السيرفر يكون بارداً — الـ caches فارغة، والاتصالات لم تُنشأ بعد. تحتاج إلى التمييز بين TTFB البارد والدافئ.

Browser DevTools

افتح Chrome DevTools، اذهب إلى تبويب Network، أعد تحميل الصفحة، وانقر على طلب المستند الرئيسي. تحت تبويب Timing، ستجد TTFB مُسمّىً بـ "Waiting (TTFB)". كرّر هذا عدة مرات ولاحظ كلاً من التحميل الأول والتحميلات اللاحقة.

WebPageTest

WebPageTest هو أكثر أداة مجانية تفصيلاً متاحة. شغّل اختباراً من موقع قريب من مستخدميك الفعليين. انظر إلى مخطط الـ waterfall — الشريط الأخضر المائل للزرقة الخاص بمستند HTML يُظهر TTFB بوضوح. شغّل 3 اختبارات على الأقل واستخدم النتيجة الوسيطة.

curl للقياس الدقيق

للقياس الدقيق القابل للتكرار بدون الحمل الزائد من المتصفح، استخدم curl:

curl -o /dev/null -s -w \ "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \ https://yourdomain.com

هذا يُفصّل كل مرحلة. إذا كانت time_namelookup مرتفعة (أكثر من 100ms)، فالـ DNS هو نقطة الاختناق. إذا كانت time_appconnect ناقص time_connect مرتفعة، فإعدادات TLS تحتاج إلى مراجعة. أما إذا كانت هذه المراحل طبيعية ولا يزال TTFB بطيئاً، فالمشكلة على مستوى السيرفر.

أكثر أسباب ارتفاع TTFB شيوعاً

1. غياب Page Caching

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

الصفحة المُخزَّنة في الـ cache تُقدَّم في أقل من 10ms. أما صفحة WordPress غير المُخزَّنة على سيرفر معقول، فتستغرق عادةً 200-800ms. وعلى سيرفر مشغول أو ضعيف الموارد، يمكن أن يتجاوز ذلك ثانيتين.

بالنسبة لـ WordPress، تعمل إضافات مثل W3 Total Cache وWP Super Cache وLiteSpeed Cache بشكل جيد. أما الـ caching على مستوى السيرفر (عبر Nginx FastCGI cache أو Varnish) فهو أسرع لأنه يتجاوز PHP كلياً.

2. استعلامات قاعدة البيانات البطيئة

حتى مع الـ caching، بعض الصفحات ديناميكية ولا يمكن تخزينها — لوحات تحكم المستخدمين، وصفحات الدفع، ونتائج البحث. هنا يتحكم أداء قاعدة البيانات في TTFB.

فعّل MySQL slow query log للعثور على المشكلات:

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

ثم استخدم EXPLAIN على الاستعلامات البطيئة للتحقق من استخدام الـ indexes. الـ indexes المفقودة على الأعمدة المستخدمة في WHERE أو JOIN أو ORDER BY هي سبب شائع جداً لاستعلامات تستغرق ثوانٍ بدلاً من ميلي ثانية.

3. إعدادات PHP و OPcache

PHP يجب أن يُحلّل ويُجمّع كود تطبيقك في كل طلب — إلا إذا كان لديك opcode cache. OPcache يحفظ الـ bytecode المُجمَّع في الذاكرة حتى تتخطى PHP خطوة التحليل كلياً.

تحقق مما إذا كان OPcache نشطاً:

php -r "echo opcache_get_status()['opcache_enabled'] ? 'Enabled' : 'Disabled';"

إذا كان مفعّلاً، تأكد من أن تخصيص الذاكرة كافٍ. القيمة الافتراضية الشائعة 128MB تنفد بسرعة على التطبيقات الكبيرة:

; php.ini opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0 ; Disable in production for max speed

4. البُعد الجغرافي عن السيرفر

الفيزياء لا تُفاوض. طلب من سيدني إلى سيرفر في فرانكفورت يقطع نحو 17,000 كيلومتر. حتى بسرعة الضوء، تلك الرحلة ذهاباً وإياباً تُضيف 100-150ms قبل أن يفعل السيرفر أي شيء. وعند إضافة نقاط التوجيه، يزداد هذا الرقم.

إذا كان جمهورك دولياً، يحل CDN هذه المشكلة بتقديم الاستجابات المُخزَّنة من نقاط edge قريبة من مستخدميك. Cloudflare وBunnyCDN وFastly كلها تعمل بشكل ممتاز لهذا الغرض. أما للتطبيقات الديناميكية العالمية حقاً، فستحتاج إلى التفكير في اختيار موقع سيرفر أقرب لجمهورك الرئيسي، أو بنية تقنية تُكرّر البيانات في مناطق متعددة.

5. التنافس على الموارد في Shared Hosting

في الـ shared hosting، CPU وذاكرة السيرفر مُقسَّمة بين عشرات أو مئات المواقع الأخرى. ارتفاع مفاجئ في حركة مرور موقع مجاور يمكن أن يرفع TTFB لديك من 200ms إلى 3 ثوانٍ دون أي تغيير من جانبك. هذه من أوضح الإشارات على أن الوقت قد حان للانتقال إلى VPS أو بيئة managed dedicated حيث تكون الموارد لك وحدك.

مكاسب سريعة يمكنك تطبيقها اليوم

• فعّل HTTP/2 أو HTTP/3. كلاهما يقلل بشكل كبير من تكاليف الاتصال عبر الـ multiplexing. تحقق بـ curl -I --http2 https://yourdomain.com — ابحث عن HTTP/2 200 في الاستجابة.
• استخدم مزود DNS سريعاً. انتقل من DNS الافتراضي لمسجّل النطاق إلى Cloudflare (1.1.1.1) أو Amazon Route 53. وقت DNS lookup ينخفض من 50-200ms إلى أقل من 10ms.
• فعّل Keep-Alive. الاتصالات الدائمة تُعيد استخدام TCP handshake للطلبات اللاحقة. في Nginx: keepalive_timeout 65;
• اضغط استجاباتك. فعّل Gzip أو Brotli على مستوى السيرفر. Brotli يضغط HTML وCSS وJS بنسبة أفضل بـ 15-20% مقارنةً بـ Gzip.
• اضبط PHP-FPM pool. إذا كانت pm.max_children منخفضة جداً، تتراكم الطلبات في قائمة الانتظار. راقب pm.status وزد حجم الـ pool إذا كنت تصطدم بالحد باستمرار.

كيف تعرف أنك أصلحت المشكلة

شغّل قياساً أساسياً كاملاً قبل أن تبدأ بتغيير أي شيء. سجّل TTFB لـ 5 روابط على الأقل — الصفحة الرئيسية، وصفحة تصنيف، وصفحة منتج أو مقال، وأي صفحات ديناميكية. قِس من مواقع متعددة باستخدام WebPageTest.

بعد كل تغيير، قِس من جديد. تحسينات TTFB تتراكم بسرعة: إصلاح OPcache قد يوفر 80ms، وإضافة page caching يوفر 400ms أخرى، والانتقال إلى DNS أسرع يوفر 60ms. وفجأة تجد نفسك قد انتقلت من 700ms إلى أقل من 200ms دون تعديل سطر واحد من كود التطبيق.

على سيرفر managed مُهيَّأ جيداً، يجب أن يكون TTFB للصفحات المُخزَّنة مريحاً دون 50ms. للصفحات الديناميكية غير المُخزَّنة، أقل من 300ms قابل للتحقيق لمعظم تطبيقات WordPress أو PHP. إذا كنت أعلى بكثير من هذه الأرقام بعد المرور على هذه القائمة، فنقطة الاختناق غالباً على مستوى البنية التحتية — موارد السيرفر، أو موقعه، أو إعداداته — وليس تطبيقك.