TTFB چیست؟ اندازه‌گیری زمان پاسخ اولیه و تشخیص گلوگاه
TTFB را با زمان بارگذاری کامل اشتباه نگیرید؛ روش اندازه‌گیری با مرورگر و curl، تفکیک شبکه و برنامه و چک‌لیست گزارش کندی سایت را بخوانید.
هاستلینو۴ دقیقه مطالعه
فهرست مطالب
TTFB یا زمان دریافت اولین بایت، فاصله شروع درخواست تا رسیدن نخستین بخش پاسخ است؛ با زمان کامل بازشدن صفحه یکی نیست. اگر سایت دیر شروع به نمایش می‌کند، این عدد یک سرنخ است، نه حکم قطعی برای تعویض هاست. مسیر شبکه، برقراری اتصال، ریدایرکت، کش و اجرای برنامه میتوانند در تأخیر نقش داشته باشند.
هدف این راهنما اندازه‌گیری قابل تکرار است: ابتدا بدانیم چه صفحه‌ای، از کدام شبکه و در چه وضعیتی کند است؛ بعد بین مشکل ارتباط، پاسخ برنامه و بارگذاری تصویر یا جاوااسکریپت تفکیک کنیم.
TTFB با سرعت کامل صفحه چه تفاوتی دارد؟
ممکن است پاسخ اولیه سریع برسد، اما تصویر اصلی یا کدهای مرورگر دیر آماده شوند. برعکس، پاسخ اولیه کمی دیرتر برسد ولی محتوای قابل استفاده زود نمایش داده شود. بنابراین TTFB را کنار تجربه نمایش محتوا و معیارهایی مثل LCP ببینید؛ خود TTFB جزو Core Web Vitals نیست.
تعریف و مرزهای اندازه‌گیری ابزارها هم اهمیت دارد؛ برای نمونه پاسخ اولیه ۱۰۳ یا ارسال زودهنگام هدر می‌تواند عدد را از زمان آماده‌شدن پاسخ نهایی جدا کند. عدد دو ابزار را بدون شناخت روششان مستقیماً مقایسه نکنید.
قبل از اندازه‌گیری این پنج مورد را ثبت کنید
- URL نهایی و نوع صفحه: خانه، نوشته، محصول یا تسویه‌حساب.
- زمان آزمون، محل و شبکه آزمایش؛ ابزار روی سرور خارجی الزاماً تجربه کاربر ایران نیست.
- ورود یا خروج از حساب و وجود کوکی؛ پاسخ کاربر واردشده ممکن است کش عمومی نداشته باشد.
- وضعیت قابل مشاهده کش: HIT، MISS یا نامعلوم، فقط اگر هدر یا گزارش معتبر داریم.
- خطا، ریدایرکت، تغییر کد یا کمپین هم‌زمان با آزمون.
صرف پاک‌کردن کش مرورگر ثابت نمی‌کند کش CDN یا سرور هم خالی است. درخواست دوم را هم بدون شواهد «کش گرم» ننامید. برای مقایسه، چند درخواست سبک با فاصله بفرستید؛ ابزار سنجش را به تست فشار روی سایت زنده تبدیل نکنید.
روش اول: زمان‌بندی درخواست در مرورگر
در ابزار توسعه مرورگر، Network را باز کنید، صفحه را بارگذاری کنید و درخواست سند HTML را پیدا کنید. بخش Timing کمک می‌کند انتظار برای پاسخ را از DNS، اتصال و انتقال داده جدا ببینید. یک تصویر یا درخواست API را به‌اشتباه به‌جای سند اصلی انتخاب نکنید.
صفحه عمومی را در حالت خروج از حساب بررسی کنید. اگر مشکل فقط در مدیریت یا پرداخت است، همان مسیر را جدا بسنجید؛ نتیجه صفحه خانه به درخواست‌های شخصی‌سازی‌شده تعمیم ندارد. برای پرداخت، از روش آزمایشی مجاز استفاده کنید و اطلاعات مشتری را در گزارش عمومی نگذارید.
روش دوم: اندازه‌گیری سبک با curl
این دستور را در ترمینال لینوکس یا macOS با URL نهایی سایت خود اجرا کنید. از GET استفاده می‌کند؛ خروجی پاسخ ذخیره نمی‌شود و سقف زمان دارد:
curl -sS -o /dev/null --max-time 20 -w 'http=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' 'https://example.com/'متغیرهای زمانی این خروجی بر حسب ثانیه‌اند و نقاط زمانی تجمعی هستند، نه پنج هزینه مستقل که با هم جمع شوند. برای HTTPS، زمان tls نقطه پایان برقراری TLS است؛ first زمان تا آغاز پاسخ را نشان میدهد. تفاضل first و tls نیز زمان خالص PHP یا دیتابیس نیست؛ رفت‌وبرگشت شبکه و لایه‌های واسط در آن نقش دارند.
این فرمان ریدایرکت را دنبال نمی‌کند. اگر http برابر ۳۰۱ یا ۳۰۸ است، فعلاً پاسخ انتقال را سنجیده‌اید؛ URL نهایی را جدا تست کنید. افزودن دنبال‌کردن ریدایرکت بدون ثبت تعداد و زمان آن، مقایسه را مبهم می‌کند.
نتیجه را چگونه به اقدام تبدیل کنیم؟
| الگوی مشاهده‌شده | بررسی بعدی |
|---|---|
| DNS یا اتصال در یک شبکه دیر است | از شبکه و موقعیت دیگری مقایسه کنید؛ پیش از تغییر وردپرس مسیر ارتباط را بررسی کنید. |
| صفحه عمومی سریع، مسیر واردشده کند است | تفاوت کش و اجرای پویا را بسنجید؛ سریع‌بودن خانه کیفیت تمام درخواست‌ها را ثابت نمی‌کند. |
| شروع پاسخ دیر و مصرف منابع بالا است | زمان خطا و گزارش CPU، حافظه و محدودیت‌ها را کنار درخواست کند بگذارید. |
| شروع پاسخ مناسب ولی نمایش تصویر اصلی دیر است | تحویل تصویر، فونت، CSS و جاوااسکریپت را بررسی کنید؛ مسئله الزاماً از پاسخ سرور نیست. |
برای مورد منابع، راهنمای مصرف بالای CPU وردپرس و در صورت برخورد با سقف هم‌زمانی، بررسی خطای ۵۰۸ هاست مسیر مکمل‌اند. پیش از دست‌کاری افزونه‌ها، بک‌آپ و محیط آزمایشی داشته باشید.
TTFB مناسب چند است؟
web.dev مقدار ۰٫۸ ثانیه یا کمتر را راهنمای تقریبی خوب و بیش از ۱٫۸ ثانیه را ضعیف معرفی می‌کند. این مرزها تضمین تجربه یا معیار خرید یک پلن نیستند. توزیع تجربه کاربران، نوع صفحه، موقعیت، کش و روش ابزار را کنار عدد ببینید؛ یک اجرای آزمایشگاهی جای داده میدانی را نمی‌گیرد.
چه گزارشی برای پشتیبانی بفرستیم؟
- دو یا سه نمونه URL کند با ساعت و منطقه زمانی.
- نتیجه چند اجرای همشرایط، نه فقط بهترین یا بدترین عدد.
- محل آزمون، ورود/خروج از حساب و وضعیت کش در صورت معلوم‌بودن.
- گزارش منابع و آخرین تغییر، بدون رمز، توکن یا داده شخصی کاربران.
از بررسی اولیه سایت برای شروع شناخت وضعیت بیرونی استفاده کنید. اگر شواهد به اجرای داخلی برنامه اشاره دارد، در درخواست پشتیبانی وردپرس همان نمونه‌ها را توضیح دهید. خرید پلن قوی‌تر بدون شناسایی گلوگاه، راه‌حل قطعی نیست.
منابع فنی
اول نشانه کندی را پیدا کنید
از بررسی اولیه وضعیت بیرونی سایت شروع کنید؛ برای تشخیص داخلی، نمونه URL و زمان کندی را هم ثبت کنید.
پرسش‌های متداول
آیا TTFB همان زمان کامل لود صفحه است؟
خیر. این معیار رسیدن اولین بخش پاسخ را نشان میدهد؛ تصویر، فونت و اجرای کد مرورگر ممکن است پس از آن زمان بیشتری بگیرند. آن را کنار تجربه نمایش محتوا و LCP بررسی کنید.
TTFB بالا یعنی باید هاست را عوض کنیم؟
نه لزوماً. ریدایرکت، شبکه، کش، کد برنامه و منابع میتوانند اثر داشته باشند. چند آزمون همشرایط و گزارش مصرف لازم است تا گلوگاه مشخص شود؛ یک عدد برای تصمیم خرید کافی نیست.
