TTFB مدت انتظار تا دریافت نخستین بایت پاسخ است، نه زمان کامل نمایش صفحه. اگر HTML دیر شروع می‌شود، کوچک کردن تصویر hero شاید حجم دانلود را کم کند اما لزوماً TTFB را تغییر نمی‌دهد. این زمان می‌تواند در DNS، اتصال و TLS، CDN، صف وب‌سرور، اجرای PHP، query دیتابیس یا API خارجی مصرف شود.
پاسخ سریع: یک URL ثابت را از چند موقعیت و چند بار اندازه بگیرید، cache hit و miss را جدا ثبت کنید و زمان request را با access log و application timing تطبیق دهید. سپس کندترین لایه را اصلاح کنید. یک عدد عمومی و ثابت برای «TTFB خوب» جای baseline واقعی و نیاز کاربران شما را نمی‌گیرد.
TTFB شامل چه بخش‌هایی است؟
- حل DNS و برقراری TCP
- مذاکره TLS در HTTPS
- مسیر شبکه تا CDN یا origin
- انتظار در صف reverse proxy یا PHP-FPM
- اجرای وردپرس، افزونه‌ها و قالب
- queryهای MySQL و تماس با سرویس‌های خارجی
- زمان تولید و ارسال اولین بخش پاسخ
ابزارهای مختلف ممکن است مرز و location متفاوتی داشته باشند. نتیجه مرورگر تهران را مستقیم با probe اروپا یا درخواست گرم سرور مقایسه نکنید.
اندازه‌گیری قابل تکرار
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}
' https://example.com/pageدامنه نمونه را جایگزین کنید. چند بار آزمایش کنید و redirect، cookie، فشرده‌سازی و location را ثابت نگه دارید. خروجی time_starttransfer همه اجزای پیش از بایت اول را جمع می‌کند و به تنهایی زمان PHP نیست.
Cache hit و miss را جدا کنید
یک صفحه عمومی ممکن است در CDN یا page cache پاسخ داده شود، در حالی که کاربر واردشده، جستجو و checkout به origin می‌رسند. headerهای cache را ثبت و درخواست نخست پس از purge را با درخواست گرم قاطی نکنید. hit rate پایین، bypass ناخواسته یا purge مداوم می‌تواند میانگین را خراب کند.
cache کردن پاسخ شخصی یا سبد خرید خطر افشای داده و رفتار اشتباه دارد. rule را بر اساس cookie، path و method واقعی طراحی و با دو نشست مستقل آزمایش کنید.
اگر زمان در شبکه یا TLS است
DNS chain، فاصله جغرافیایی، packet loss، redirectهای HTTP/HTTPS و certificate chain را بررسی کنید. CDN می‌تواند فاصله محتوای cacheشده را کم کند، اما dynamic miss همچنان به origin وابسته است. تغییر DNS یا گواهی را با TTL و rollback برنامه‌ریزی کنید؛ خاموش کردن اعتبارسنجی TLS راه‌حل performance نیست.
اگر درخواست در صف PHP-FPM می‌ماند
active/idle worker، صف، duration و مصرف حافظه را هنگام کندی ببینید. افزایش worker فقط وقتی مفید است که CPU و RAM ظرفیت داشته باشند. روی CPU اشباع، worker بیشتر می‌تواند رقابت را شدیدتر کند؛ روی RAM محدود خطر swap و OOM دارد. timeout بلند نیز صف را درمان نمی‌کند.
اگر هم‌زمان CPU بالا است، راهنمای تشخیص CPU وردپرس را دنبال کنید. slowlog کنترل‌شده PHP-FPM می‌تواند stack درخواست طولانی را نشان دهد، ولی باید دسترسی فایل و overhead آن مدیریت شود.
زمان اجرای وردپرس
افزونه یا قالب ممکن است query زیاد، پردازش تکراری یا HTTP call همگام اجرا کند. در staging با Query Monitor یا profiler، hook، caller و مدت را ثبت کنید. تعداد افزونه یا query معیار کافی نیست؛ مدت، فراوانی و مسیر درخواست اهمیت دارد.
صفحه‌ای که فقط برای مدیر کند است باید جدا از صفحه عمومی بررسی شود. کندی wp-admin معمولاً با page cache عمومی حل نمی‌شود.
دیتابیس و query
slow query log، plan و rowهای بررسی‌شده را ببینید. یک query بدون index یا lock می‌تواند بقیه request را منتظر بگذارد. پاک کردن option و transient یا ساخت index بدون شناخت schema خطر دارد؛ ابتدا backup و clone داشته باشید و اثر write هر index را هم بسنجید.
API و سرویس خارجی
فونت، license، CRM، قیمت، پیامک یا سرویس امنیتی ممکن است در مسیر تولید صفحه صدا زده شود. timeout و retry می‌تواند TTFB را چند برابر کند. تماس غیرضروری را async یا cache کنید فقط اگر منطق تازگی داده اجازه می‌دهد. خاموش کردن TLS verification یا hard-code کردن IP راه پایدار نیست.
فرایند اصلاح از کم‌ریسک تا پیشرفته
- redirect اضافی و خطای واضح cache را رفع کنید.
- صفحات عمومی مناسب را با policy صحیح cache کنید.
- HTTP call و job غیرضروری را از request تعاملی خارج کنید.
- query کند و autoload نامناسب را بر اساس شواهد اصلاح کنید.
- PHP-FPM و OPcache را با workload و منابع هماهنگ کنید.
- در صورت اثبات محدودیت، ظرفیت یا معماری hosting را تغییر دهید.
اشتباه‌های رایج
- استفاده از یک تست و یک location
- یکی دانستن TTFB با Core Web Vitals یا زمان کامل صفحه
- cache کردن endpointهای شخصی و تراکنشی
- افزایش worker بدون محاسبه RAM و CPU
- پاک کردن دیتابیس برای کاهش عدد بدون یافتن query
- نادیده گرفتن redirect و cache status
پس از تغییر چه چیزهایی را بسنجیم؟
median و صدک‌های بالاتر را در چند URL و حالت hit/miss مقایسه کنید. error rate، CPU، queue PHP و زمان query نباید برای کاهش ظاهری TTFB بدتر شده باشند. checkout، login و کاربران واردشده را در smoke test نگه دارید.
چه زمانی بررسی تخصصی لازم است؟
اگر TTFB متناوب، وابسته به load یا متفاوت میان edge و origin است، یک تغییر عمومی پاسخگو نیست. سرویس افزایش سرعت وردپرس می‌تواند زمان را بین شبکه، cache، PHP و MySQL تفکیک و نتیجه قبل و بعد را مستند کند.
پرسش‌های متداول
آیا CDN همیشه TTFB را کم می‌کند؟
برای cache hit نزدیک کاربر معمولاً کمک می‌کند؛ dynamic miss یا origin کند همچنان نیاز به اصلاح دارد.
آیا تصویر روی TTFB اثر دارد؟
معمولاً بیشتر روی دانلود و رندر اثر دارد، مگر تولید یا پردازش آن در request سرور انجام شود.
چرا اولین درخواست کندتر است؟
DNS، TLS، اتصال و cache سرد ممکن است نقش داشته باشند؛ با چند اجرای برچسب‌خورده مقایسه کنید.