TTFB فقط «سرعت سرور» نیست. شامل ریدایرکت‌ها، پیدا کردن IP (DNS)، برقراری اتصال و رمزنگاری HTTPS و در نهایت زمانی است که سرور صرف ساختن صفحه می‌کند.
چه عددی خوب است؟
راهنمای web.dev گوگل TTFB تا حدود ۰.۸ ثانیه را خوب و بیش از ۱.۸ ثانیه را ضعیف می‌داند. چون LCP خوب باید زیر ۲.۵ ثانیه باشد، TTFB بالا عملاً فرصتی برای بقیه‌ی مراحل باقی نمی‌گذارد.
چرا TTFB در وردپرس بالا می‌رود؟
- نبود کش صفحه: هر بازدید باعث اجرای PHP و ده‌ها کوئری دیتابیس می‌شود.
- افزونه‌های زیاد و سنگین که روی هر درخواست کار می‌کنند.
- دیتابیس حجیم و نامرتب: جدول‌های بزرگ، گزینه‌های autoload زیاد.
- هاست ضعیف یا شلوغ و نسخه‌ی قدیمی PHP.
- فاصله‌ی جغرافیایی بین سرور و کاربر.
- زنجیره‌ی ریدایرکت قبل از رسیدن به صفحه‌ی نهایی.
مثال واقعی
در همین سایت، دیتابیس به خاطر ثبت‌نام بیش از ۱۵۵ هزار حساب ربات به حدود ۵۲۰ مگابایت رسیده بود. بعد از پاک‌سازی حساب‌های اسپم و جدول‌های افزونه‌های حذف‌شده، حجم دیتابیس به حدود ۶۰ مگابایت و حجم تنظیمات autoload که در هر درخواست بارگذاری می‌شود تقریباً به نصف رسید؛ کاری که مستقیم روی زمان پاسخ سرور اثر دارد.
راه‌های کاهش TTFB
- کش کامل صفحه (روی سرورهای لایت‌اسپید، افزونه‌ی LiteSpeed Cache)؛
- کش آبجکت مثل Redis برای سایت‌های پویا؛
- PHP نسخه‌ی ۸ به بالا؛
- پاک‌سازی دیتابیس و کم کردن افزونه‌ها؛
- هاست مناسب با محل مخاطبان و در صورت نیاز CDN؛
- حذف ریدایرکت‌های اضافه.
چطور بررسی کنیم؟
PageSpeed Insights در داده‌ی میدانی TTFB را جداگانه نشان می‌دهد. در کروم، زبانه‌ی Network و بخش Timing هر درخواست، «Waiting for server response» همان زمان پردازش سرور است. در سرچ کنسول هم گزارش Crawl stats میانگین زمان پاسخ به Googlebot را نشان می‌دهد؛ عددی که روی بودجه خزش اثر دارد.