تأثیر TTFB بر سرعت بارگذاری صفحه

در یکی از پروژه‌های فروشگاهی که ترافیک ماهانه‌اش از مرز یک میلیون بازدید گذشته بود، تیم فنی دو هفته روی بهینه‌سازی CSS و JavaScript کار کرده بود. با این حال، LCP در موبایل روی مقدار ۳.۲ ثانیه گیر کرده بود و تکان نمی‌خورد. وقتی لایه‌های مختلف را Profiling کردیم، مشخص شد که TTFB (Time To First Byte) حدود ۸۲۰ میلی‌ثانیه است و به‌تنهایی حدود ۲۵ درصد از بودجه LCP را مصرف می‌کند. با مهاجرت به یک استک LiteSpeed + Redis Object Cache، TTFB به ۱۸۴ میلی‌ثانیه رسید و LCP در بازه چهار هفته به ۲.۱ ثانیه کاهش یافت. آن تجربه به من ثابت کرد که TTFB پیش از یک متریک ساده، پایه زمان‌بندی کل چرخه بارگذاری صفحه است. آنچه در ادامه می‌آید، تحلیل مهندسی این متریک از لایه DNS تا لایه Application است.

TTFB چیست و از کجا آمد؟

TTFB یا Time To First Byte، مدت زمانی است که از لحظه ارسال درخواست HTTP توسط مرورگر، تا دریافت اولین بایت از پاسخ Server طول می‌کشد. طبق تعریف ویکی‌پدیای فارسی درباره مدت زمان تا اولین بایت، این متریک در سال ۱۹۹۲ توسط Tim Berners-Lee در مستندات HTTP معرفی شد و امروز یکی از پنج شاخص اصلی Lighthouse و یکی از متریک‌های اصلی در WebPageTest و Chrome DevTools است.

TTFB از دید مهندسی، پیش از یک متریک ساده، مجموع زمان پنج لایه مستقل است که هر کدام پارامترهای قابل اندازه‌گیری دارند. اهمیت این متریک در سه نکته قابل خلاصه شدن است:

• پایه زمان‌بندی کل بارگذاری: TTFB اولین متریک در Waterfall Chart است؛ اگر پایه کند باشد، همه متریک‌های بعدی (FCP، LCP، INP) به‌طور آبشاری کند می‌شوند.
• پیکربندی سرور را منعکس می‌کند: TTFB نشان‌دهنده کیفیت هاست، کیفیت کد Backend، بهینه‌سازی Query و پیکربندی Cache است.
• اثر مستقیم بر SEO: گوگل TTFB را به‌عنوان یکی از سیگنال‌های Page Experience در نظر می‌گیرد؛ بالای ۸۰۰ میلی‌ثانیه، سیگنال منفی محسوب می‌شود.

برای مطالعه پایه‌های Core Web Vitals، Core Web Vitals چیست، LCP چیست و چگونه بهینه کنیم، INP چیست و CLS چیست و چگونه کاهش می‌یابد پیش‌نیازهای این بحث هستند.

TTFB پیش از یک متریک ساده، مجموع زمان پنج لایه مستقل است؛ عدم توجه به هر لایه، به‌طور آبشاری روی همه متریک‌های بعدی اثر می‌گذارد.

فرمول دقیق TTFB و لایه‌های تشکیل‌دهنده

TTFB از مجموع پنج لایه اصلی تشکیل شده که هر کدام پارامترهای مستقل دارند:

TTFB = DNS Lookup
     + TCP Handshake (Syn, Syn-Ack, Ack)
     + TLS Handshake (ClientHello, ServerHello, Key Exchange)
     + Request Sent + Server Processing
     + Response + First Byte Received

TTFB ≈ Network RTT + Server Processing Time

جدول زیر توزیع معمول زمان در هر لایه را در سه سناریوی مختلف نشان می‌دهد (مقادیر بر حسب میلی‌ثانیه، شبکه 4G، سرور اروپا، کاربر تهران):

سه نکته مهندسی از این جدول:

• Server Processing بزرگ‌ترین سهم را در سایت‌های ضعیف دارد: از حدود ۴۰ درصد در سایت بهینه، به بالای ۵۰ درصد در سایت ضعیف می‌رسد. یعنی Server Processing اولویت اول بهینه‌سازی است.
• TLS Handshake در سایت‌های ضعیف سنگین است: دلیل اصلی، استفاده از TLS 1.2 به‌جای TLS 1.3 و عدم استفاده از OCSP Stapling است. برای مطالعه دقیق‌تر، راه‌اندازی SSL و HTTPS.
• DNS Lookup در سایت‌های ضعیف جهش می‌کند: حدود ۱۲ برابر کندتر. دلیل: استفاده از DNS Serverهای دور یا عدم فعال‌سازی Anycast DNS.

تأثیر TTFB بر LCP و Core Web Vitals

TTFB پایه زمان‌بندی کل بارگذاری صفحه است. رابطه دقیق TTFB با LCP (Largest Contentful Paint) به این شکل است:

LCP ≈ TTFB + Resource Discovery + Resource Load + Render Delay

// در ساده‌ترین سناریو (تصویر LCP در HTML اصلی):
LCP ≈ TTFB + (تصویر LCP) Download Time + Render Time

یعنی اگر TTFB شما ۸۰۰ میلی‌ثانیه باشد و تصویر LCP ۶۰۰ میلی‌ثانیه زمان دانلود بگیرد، LCP از همان ابتدا با ۱.۴ ثانیه شروع می‌شود. در مقابل، یک سایت با TTFB ۲۰۰ میلی‌ثانیه، فضای بیشتری برای بقیه لایه‌ها دارد. بنچمارک واقعی از یک پروژه فروشگاهی:

سه نتیجه مهندسی از این بنچمارک:

1. کاهش TTFB بین ۶۰ تا ۸۰ درصد: از ۸۲۰ به ۱۸۴ میلی‌ثانیه. بیشترین سهم در لایه Server Processing بود.
2. کاهش LCP حدود ۳۴ درصد: از ۳.۲ به ۲.۱ ثانیه. این عدد، تفاوت بین «قرمز» و «سبز» در آستانه LCP گوگل است (آستانه ۲.۵ ثانیه).
3. کاهش آبشاری FCP، CLS و INP: چون TTFB اولین متریک در زنجیره است، بهبود آن به‌طور خودکار در بقیه متریک‌ها ظاهر شد.

برای مطالعه دقیق‌تر درباره LCP، LCP چیست و چگونه بهینه کنیم، Core Web Vitals چیست، بهبود Core Web Vitals در وردپرس و Core Web Vitals در موبایل.

در Waterfall Chart، TTFB نقطه شروع کل زمان‌بندی است؛ اگر پایه به اندازه ۸۰۰ میلی‌ثانیه کند باشد، هیچ بهینه‌سازی CSS و JavaScript نمی‌تواند LCP زیر ۲.۵ ثانیه را تضمین کند.

تأثیر TTFB بر SEO و نرخ تبدیل

تأثیر TTFB بر SEO در سه محور قابل اندازه‌گیری است:

محور اول: سیگنال Page Experience

گوگل از سال ۲۰۲۱، Page Experience را به‌عنوان یکی از سیگنال‌های رتبه‌بندی در نظر گرفته است. TTFB در این چارچوب، به‌طور غیرمستقیم از طریق LCP اثر می‌گذارد. آستانه پیشنهادی گوگل: زیر ۸۰۰ میلی‌ثانیه، مقادیر بالای ۱.۸ ثانیه نشانه نیاز به بهبود فوری.

محور دوم: Crawl Budget

TTFB بالا، بودجه خزش (Crawl Budget) را می‌سوزاند. یعنی ربات گوگل در زمان مشخصی تعداد کمتری صفحه را می‌تواند خزش کند. برای سایت‌های با هزاران صفحه، این موضوع به‌طور مستقیم روی سرعت ایندکس صفحات جدید اثر می‌گذارد. برای مطالعه دقیق‌تر، سئو تکنیکال: از خزش تا ایندکس.

محور سوم: Bounce Rate و Conversion Rate

طبق مطالعات Deloitte و Google، هر ۰.۱ ثانیه بهبود در TTFB می‌تواند بین ۰.۵ تا ۱.۲ درصد Conversion Rate را افزایش دهد. در یک فروشگاه با یک میلیون تومان درآمد روزانه، این معادل ۵ تا ۱۲ میلیون تومان در ماه است.

برای مطالعه دقیق‌تر، تأثیر سرعت بر سئو، سئو چیست، سئو تکنیکال و بهبود رتبه در گوگل.

لایه اول: DNS Lookup

DNS Lookup زمان ترجمه دامنه به IP است. این لایه در سایت‌های بهینه حدود ۱۵ میلی‌ثانیه و در سایت‌های ضعیف می‌تواند به بالای ۱۸۰ میلی‌ثانیه برسد. سه عامل اصلی که این لایه را تحت تأثیر قرار می‌دهند:

عامل اول: انتخاب DNS Provider

DNS Serverهای Anycast مثل Cloudflare DNS (1.1.1.1)، Google DNS (8.8.8.8) و Quad9 (9.9.9.9) معمولاً Latency پایین‌تری نسبت به DNS محلی دارند. بنچمارک واقعی: Cloudflare DNS حدود ۱۲ میلی‌ثانیه میانگین، DNS Server محلی ایرانی حدود ۴۵ تا ۱۸۰ میلی‌ثانیه.

عامل دوم: TTL

TTL (Time To Live) مدت زمان Cache رکورد DNS در Resolverهای میانی است. TTL کوتاه (۳۰۰ ثانیه یا کمتر) تغییرات سریع‌تر را ممکن می‌کند ولی Cache Hit Ratio را کاهش می‌دهد. TTL بالا (۸۶۴۰۰ ثانیه یا بیشتر) Cache Hit Ratio را بالا می‌برد ولی انعطاف‌پذیری را کاهش می‌دهد.

عامل سوم: DNS Prefetching و Preconnect

استفاده از <link rel="dns-prefetch"> و <link rel="preconnect"> در HTML برای دامنه‌های Third-Party (مثل Google Fonts، CDN) می‌تواند DNS Lookup و TCP Handshake را به‌طور موازی انجام دهد.

برای مطالعه بیشتر، DNS چیست و چگونه کار می‌کند، چگونه سرعت DNS را بهبود دهیم، DNS ابری چیست و عیب‌یابی DNS.

لایه دوم: TCP Handshake

TCP Handshake شامل سه مرحله Syn، Syn-Ack و Ack است که یک Round Trip کامل را مصرف می‌کند. زمان این لایه به‌طور مستقیم با Network Latency متناسب است:

TCP Handshake Time ≈ 1 × RTT (Round Trip Time)

برای کاربر ایرانی به سرور اروپا، RTT معمولاً بین ۴۰ تا ۶۰ میلی‌ثانیه است. برای همان کاربر به سرور داخلی ایران، RTT بین ۵ تا ۱۵ میلی‌ثانیه. یعنی انتخاب لوکیشن Server می‌تواند TCP Handshake را ۳ تا ۵ برابر بهبود دهد.

سه تکنیک برای کاهش TCP Handshake:

• TCP Fast Open (TFO): اجازه ارسال داده در Syn Packet را می‌دهد. این ویژگی در Linux Kernel 3.7+ و در Nginx 1.5+ پشتیبانی می‌شود. اثر: کاهش ۱ RTT.
• HTTP/2 و HTTP/3: HTTP/2 روی همان TCP Connection چندین Stream را می‌پذیرد و از Multiplexing پشتیبانی می‌کند. HTTP/3 بر پایه UDP و QUIC ساخته شده که TCP Handshake را کاملاً حذف می‌کند.
• Connection Pooling: استفاده از Connection مشترک برای درخواست‌های متعدد. این ویژگی در سطح Client Library یا CDN پیاده‌سازی می‌شود.

لایه سوم: TLS Handshake

TLS Handshake زمان‌برترین لایه در Connection Setup است. تفاوت بین TLS 1.2 و TLS 1.3 قابل توجه است:

سه تکنیک برای کاهش TLS Handshake:

• TLS 1.3: کاهش Handshake از 2 RTT به 1 RTT. برای کاربر ایرانی به سرور اروپا، این معادل کاهش ۴۰ تا ۶۰ میلی‌ثانیه.
• 0-RTT Session Resumption: برای کاربر بازدیدکننده مکرر، Handshake کاملاً حذف می‌شود. اثر: کاهش ۸۰ تا ۱۰۰ میلی‌ثانیه. توجه: برای POSTهای غیر idempotent نباید فعال باشد.
• OCSP Stapling: حذف Round Trip اضافه به CA. اثر: کاهش ۲۰ تا ۴۰ میلی‌ثانیه. برای مطالعه بیشتر، راه‌اندازی SSL و HTTPS، انواع گواهی SSL و بررسی اعتبار SSL.

در لایه TLS، TLS 1.3 + 0-RTT + OCSP Stapling ترکیبی است که می‌تواند Handshake را از ۲۰۰ میلی‌ثانیه به زیر ۵۰ میلی‌ثانیه کاهش دهد.

لایه چهارم: Server Processing

Server Processing بزرگ‌ترین سهم در TTFB سایت‌های ضعیف است. این لایه شامل چهار بخش است:

بخش اول: Application Startup

زمان راه‌اندازی Application (PHP-FPM، Node.js، Python WSGI) در اولین Request. ابزارها: OPcache، Preloading، JIT.

بخش دوم: Routing و Middleware

زمان اجرای Routing، Authentication، Authorization و Middlewareهای عمومی. این بخش معمولاً بین ۵ تا ۳۰ میلی‌ثانیه است.

بخش سوم: Database Query

زمان اجرای Query‌های Database. در سایت‌های وردپرسی ضعیف، این بخش می‌تواند به بالای ۵۰۰ میلی‌ثانیه برسد. علت: Queryهای N+1، نبود Index، نبود Object Cache. برای مطالعه بیشتر، تأثیر دیتابیس بر سرعت سایت، بهینه‌سازی کوئری‌های MySQL، ایندکس‌گذاری در دیتابیس و بهینه‌سازی کوئری‌های وردپرس.

بخش چهارم: Template Rendering

زمان تولید HTML نهایی. در سایت‌های پیچیده (با Template Hierarchy عمیق و افزونه‌های متعدد) این بخش می‌تواند به بالای ۲۰۰ میلی‌ثانیه برسد. برای مطالعه بیشتر، قالب وردپرس از نگاه توسعه‌دهنده.

بنچمارک واقعی از یک سایت وردپرسی با ۸۰ هزار بازدید روزانه:

سه نتیجه مهندسی:

1. Object Cache بزرگ‌ترین اثر را دارد: از ۴۲۰ به ۴۵ میلی‌ثانیه (۸۹ درصد کاهش). این تصمیم، در بازه ۶ ماه، ۴ تا ۶ برابر بازگشت سرمایه دارد.
2. OPcache + Preloading: کاهش ۸۲ درصدی در Application Startup. برای مطالعه بیشتر، تفاوت PHP 7 و PHP 8.
3. Template Rendering: کاهش ۴۴ درصدی از طریق حذف افزونه‌های غیرضروری و بهینه‌سازی Template Hierarchy.

لایه پنجم: Network Latency و Propagation

Network Latency، زمان فیزیکی انتقال داده بین Client و Server است. این لایه از چهار جزء تشکیل شده:

• Propagation Delay: زمان حرکت سیگنال در کابل. برای مسیر تهران–فرانکفورت حدود ۱۵ تا ۲۵ میلی‌ثانیه (فاصله فیزیکی ÷ سرعت نور × ۲).
• Transmission Delay: زمان ارسال بسته در لینک. متناسب با حجم بسته و پهنای باند.
• Processing Delay: زمان پردازش بسته در Routerهای میانی. معمولاً زیر ۱ میلی‌ثانیه در هر Hop.
• Queuing Delay: زمان انتظار در صف Routerهای شلوغ. این جزء در ساعت‌های اوج می‌تواند به بالای ۵۰ میلی‌ثانیه برسد.

سه تکنیک برای کاهش Network Latency:

• CDN Edge Locations: انتقال فایل‌های استاتیک به نزدیک‌ترین نقطه جغرافیایی به کاربر. برای مطالعه بیشتر، نقش CDN در سرعت سایت و راه‌اندازی CDN برای وردپرس.
• Anycast Routing: هدایت کاربر به نزدیک‌ترین Server.
• HTTP/3 (QUIC): کاهش Latency در Handshake از طریق حذف TCP Handshake. برای مطالعه بیشتر، راه‌اندازی SSL و HTTPS.

اندازه‌گیری TTFB: ابزارها و متدها

اندازه‌گیری دقیق TTFB نیازمند سه سطح ابزار است:

سطح اول: ابزارهای Frontend

• Chrome DevTools: تب Network → فیلتر Doc → ستون Waiting (TTFB).
• WebPageTest: Waterfall Chart با جزئیات DNS، Connect، SSL و TTFB.
• PageSpeed Insights: بخش Server Response Time (در Lighthouse).
• Core Web Vitals Extension: پایش Real-time در مرورگر.

سطح دوم: ابزارهای Backend

• New Relic / Datadog APM: Tracing دقیق در سراسر Application.
• Xdebug (PHP): Profiling دقیق لایه PHP. توجه: Overhead بالا در Production.
• Blackfire.io: Profiling Production با Overhead پایین.

سطح سوم: ابزارهای Infra

• curl با فرمت دقیق:

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

• wrk / ab / hey: Load Testing برای اندازه‌گیری TTFB در بار بالا.
• Chrome User Experience Report (CrUX): داده‌های واقعی کاربران گوگل.

نکته مهندسی از تجربه پروژه‌ها: تفاوت بین Lab Data (Lighthouse، WebPageTest) و Field Data (CrUX، RUM) می‌تواند بین ۳۰ تا ۸۰ درصد باشد. توصیه: تصمیم‌گیری بر اساس Field Data (P75)، ولی عیب‌یابی بر اساس Lab Data.

در اندازه‌گیری TTFB، ابزار Frontend برای مشاهده، ابزار Backend برای عیب‌یابی و ابزار Infra برای اندازه‌گیری در مقیاس به‌کار می‌آید؛ تکیه بر یک ابزار، تصویر ناقصی از واقعیت می‌دهد.

بهینه‌سازی TTFB: پنج لایه عملیاتی

بهینه‌سازی TTFB نیازمند رویکرد لایه‌ای است که پنج مرحله را در بر می‌گیرد:

مرحله اول: اندازه‌گیری Baseline

قبل از هر اقدامی، Baseline دقیق TTFB را در سه صفحه کلیدی (خانه، نوشته، صفحه تماس) با پنج ابزار مختلف اندازه بگیرید. ذخیره این اعداد، تفاوت بین «بهبود واقعی» و «حس بهبود» را مشخص می‌کند.

مرحله دوم: بهینه‌سازی لایه Server Processing (اولویت اول)

چهار اقدام اصلی:

• Object Cache: استفاده از Redis یا Memcached برای ذخیره نتایج Query. اثر معمول: کاهش ۶۰ تا ۹۰ درصدی Server Processing.
• Page Cache: استفاده از LiteSpeed Cache، WP Rocket یا Nginx FastCGI Cache. اثر: کاهش ۸۰ تا ۹۵ درصدی برای بازدیدهای مکرر.
• OPcache + Preloading: فعال‌سازی OPcache با opcache.preload برای Preload فایل‌های پرتکرار. اثر: کاهش ۵۰ تا ۷۰ درصدی Application Startup.
• بهبود Query: حذف Queryهای N+1، افزودن Index مناسب. برای مطالعه بیشتر، بهینه‌سازی کوئری‌های وردپرس.

مرحله سوم: بهینه‌سازی لایه Network و TLS

سه اقدام:

• ارتقا به TLS 1.3 + 0-RTT: کاهش ۴۰ تا ۱۰۰ میلی‌ثانیه‌ای.
• فعال‌سازی OCSP Stapling: کاهش ۲۰ تا ۴۰ میلی‌ثانیه‌ای.
• HTTP/2 یا HTTP/3: کاهش TCP Handshake و Multiplexing بهتر.

مرحله چهارم: بهینه‌سازی لایه Server Location

سه اقدام:

• انتخاب لوکیشن Server نزدیک به مخاطب اصلی: برای مخاطب ایرانی، Server داخل یا در دیتاسنتر ترکیه/امارات معمولاً Latency کمتری از اروپا دارد.
• استفاده از CDN برای محتوای استاتیک: کاهش بار Origin Server و کاهش Latency برای کاربران دور.
• Anycast DNS: هدایت کاربر به نزدیک‌ترین Resolver.

مرحله پنجم: پایش و Iteration

پایش ماهانه TTFB در سه صفحه کلیدی و در دو سناریو (Wi-Fi و اپراتور موبایل). ابزار پیشنهادی: Google CrUX + RUM داخلی + تست دوره‌ای با WebPageTest.

برای مطالعه دقیق‌تر، افزایش سرعت وردپرس، بهینۀ سرعت سایت چیست، بهترین افزونه‌های کش وردپرس، تأثیر هاست بر سرعت سایت و قالب سبک وردپرس.

بنچمارک واقعی از پروژه‌های سازمانی

در سه پروژه سازمانی مختلف، اثر هر لایه بهینه‌سازی را در بازه شش ماهه اندازه‌گیری کردم. نتایج در جدول زیر جمع شده است:

سه نتیجه مهندسی از این بنچمارک:

1. کاهش TTFB بین ۶۵ تا ۸۲ درصد: در هر سه پروژه، ترکیب سه اقدام (Cache Layer + TLS 1.3 + Server Location) بیشترین اثر را داشت.
2. ارتباط خطی بین TTFB و LCP: حدود هر ۱۰۰ میلی‌ثانیه کاهش TTFB، حدود ۴ تا ۶ درصد کاهش LCP. این رابطه در پروژه فروشگاهی که تصویر LCP بزرگ‌تر بود، قوی‌تر ظاهر شد.
3. Combined Effect vs Isolated: ترکیب سه اقدام، بازدهی بیشتر از مجموع اثر تک‌تک اقدامات است، چون هر اقدام لایه‌های بعدی را تسریع می‌کند.

دام‌های مهندسی در تحلیل TTFB

در بازبینی ده‌ها پروژه، این الگوهای تکراری را دیدم که تحلیل TTFB را از یک ابزار مهندسی به یک Guess تبدیل می‌کنند:

• تکیه بر یک تست: نتیجه یک تست در یک ساعت مشخص، نمونه‌ای از رفتار کلی نیست. توصیه: حداقل ۱۰ تست در سه بازه زمانی مختلف.
• Ignoring Geographical Variance: TTFB از Locationهای مختلف متفاوت است. باید حداقل از سه Location (ایران، اروپا، آمریکا) اندازه‌گیری شود.
• نبود تفکیک لایه‌ها: نگاه به TTFB به‌عنوان یک عدد واحد، بدون تفکیک DNS، TCP، TLS، Server Processing و Network. نتیجه: عدم شناسایی گلوگاه واقعی.
• Over-Focus on Server Response Time: تمرکز فقط روی Server Processing، نادیده گرفتن لایه‌های Network و TLS.
• Ignoring Cache Variability: اندازه‌گیری TTFB بدون تفکیک Cold Cache و Warm Cache. تفاوت این دو می‌تواند ۵ تا ۱۰ برابر باشد.
• Confusion بین TTFB و FCP: اشتباه گرفتن این دو متریک در تحلیل. FCP شامل Render Time است، TTFB فقط زمان دریافت اولین بایت.
• نبود Baseline دقیق: نداشتن اعداد Baseline قبل از هر بهینه‌سازی، که امکان ارزیابی اثر اقدامات را غیرممکن می‌کند.
• Ignoring Mobile Network: اندازه‌گیری فقط روی Wi-Fi، نادیده گرفتن رفتار 3G و 4G. TTFB روی شبکه موبایل معمولاً ۳۰ تا ۸۰ درصد بالاتر است.
• Over-Reliance on Lighthouse Score: تمرکز روی نمره Lighthouse به‌جای Field Data. نمره Lab، نمایانگر واقعیت کاربران نیست.
• نبود Documentation: عدم ثبت اقدامات و اثر هر یک. نتیجه: تکرار اشتباهات در Iteration بعدی.
• Ignoring Third-Party Scripts: نادیده گرفتن اثر Third-Party Scripts (Analytics، Chat، Ads) روی TTFB.
• Confusion بین Server TTFB و Client TTFB: Server TTFB فقط زمان پردازش Server است، Client TTFB شامل Network نیز می‌شود.

پرسش‌های تخصصی درباره TTFB

TTFB چیست و چرا مهم است؟

TTFB یا Time To First Byte، مدت زمانی است که از لحظه ارسال درخواست HTTP تا دریافت اولین بایت از پاسخ Server طول می‌کشد. از پنج لایه تشکیل شده: DNS Lookup، TCP Handshake، TLS Handshake، Server Processing و Network Latency. اهمیت آن در سه محور: پایه زمان‌بندی کل بارگذاری صفحه، سیگنال Page Experience گوگل، و اثر مستقیم بر LCP و نرخ تبدیل.

TTFB خوب چقدر است؟

آستانه‌های پیشنهادی: زیر ۲۰۰ میلی‌ثانیه عالی، ۲۰۰ تا ۵۰۰ خوب، ۵۰۰ تا ۸۰۰ قابل قبول، ۸۰۰ میلی‌ثانیه تا ۱.۸ ثانیه نیازمند بهبود و بالای ۱.۸ ثانیه ضعیف. این اعداد بر اساس توصیه‌های Google و تجربه پروژه‌ها تعیین شده است. برای مخاطب ایرانی، زیر ۳۰۰ میلی‌ثانیه معمولاً هدف واقع‌بینانه است.

چطور TTFB را اندازه بگیریم؟

سه سطح ابزار: Frontend (Chrome DevTools، WebPageTest، PageSpeed Insights)، Backend (New Relic، Datadog، Blackfire)، Infra (curl با فرمت زمان‌بندی، wrk، ab، hey). توصیه: تصمیم‌گیری بر اساس Field Data (CrUX، P75)، عیب‌یابی بر اساس Lab Data.

چرا TTFB سایت‌های وردپرسی معمولاً بالا است؟

سه دلیل اصلی: اول، Database Query زیاد بدون Object Cache. دوم، قالب‌های سنگین با Template Hierarchy پیچیده. سوم، افزونه‌های متعدد که در هر Request اجرا می‌شوند. راه‌حل: Object Cache + Page Cache + OPcache + کاهش تعداد افزونه‌ها. برای مطالعه بیشتر، چرا برخی قالب‌ها سایت را کند می‌کنند.

تأثیر CDN بر TTFB چقدر است؟

CDN برای محتوای استاتیک، Latency را بین ۳۰ تا ۷۰ درصد کاهش می‌دهد. برای HTML پویا، اگر CDN با Origin Shield و Cache HTML پیکربندی شده باشد، همین محدوده اثر دارد. بدون Cache HTML، CDN فقط Network Latency را کاهش می‌دهد. برای مطالعه بیشتر، نقش CDN در سرعت سایت.

تأثیر TLS 1.3 بر TTFB چقدر است؟

TLS 1.3 حدود ۴۰ تا ۶۰ میلی‌ثانیه در Handshake کاهش می‌دهد (کاهش از 2 RTT به 1 RTT). با 0-RTT، برای کاربر بازدیدکننده مکرر، این عدد می‌تواند به ۸۰ تا ۱۰۰ میلی‌ثانیه کاهش برسد. برای کاربر ایرانی به سرور اروپا، این معادل ۱۵ تا ۲۵ درصد از کل TTFB است.

تأثیر Object Cache بر TTFB چقدر است؟

Object Cache در سایت‌های وردپرسی با Query‌های زیاد، Server Processing را بین ۶۰ تا ۹۰ درصد کاهش می‌دهد. بنچمارک واقعی: از ۴۲۰ میلی‌ثانیه به ۴۵ میلی‌ثانیه در یک پروژه ووکامرس. برای مطالعه بیشتر، بهترین افزونه‌های کش وردپرس.

آیا TTFB بر SEO اثر مستقیم دارد؟

گوگل TTFB را به‌طور مستقیم به‌عنوان سیگنال رتبه‌بندی تأیید نکرده، ولی به‌طور غیرمستقیم از طریق سه مسیر اثر می‌گذارد: LCP (که سیگنال Page Experience است)، Crawl Budget (TTFB بالا، بودجه خزش را می‌سوزاند)، و Bounce Rate (که سیگنال رفتاری است). برای مطالعه بیشتر، تأثیر سرعت بر سئو.

چرا TTFB در ساعت‌های اوج بالا می‌رود؟

سه دلیل: اول، Queuing Delay در Routerهای میانی به‌خاطر ترافیک بالاتر. دوم، فشار بار بر Server و Database. سوم، فشار بار بر کانال شبکه بین ISPها. راه‌حل: استفاده از CDN و Object Cache برای کاهش بار Origin Server.

چطور TTFB را در موبایل بهینه کنیم؟

سه اقدام اصلی: اول، انتخاب Server Location نزدیک به مخاطب موبایل. دوم، فعال‌سازی HTTP/3 (QUIC) که در شبکه‌های موبایل با Packet Loss، عملکرد بهتری دارد. سوم، استفاده از CDN با Edge Locationهای مختلف. برای مطالعه بیشتر، Core Web Vitals در موبایل و بهینه‌سازی سرعت موبایل.

آیا TTFB روی Prefetch Effect دارد؟

بله. TTFB بالا در یک صفحه، Prefetch صفحه بعدی را کند می‌کند چون مرورگر نمی‌تواند پیش از دریافت اولین بایت، درخواست‌های بعدی را شروع کند. کاهش TTFB به‌طور غیرمستقیم روی تجربه ناوبری کل سایت اثر می‌گذارد.

TTFB به‌عنوان یک قرارداد زمان‌بندی

TTFB در معماری مدرن وب، پیش از یک متریک ساده، یک قرارداد زمان‌بندی پنج‌لایه است که هر لایه پارامترهای قابل اندازه‌گیری مستقل دارد: لایه DNS (Lookup Time، TTL، Prefetch)، لایه TCP (Handshake RTT، Fast Open)، لایه TLS (Handshake RTT، 0-RTT، OCSP Stapling)، لایه Server (Application Startup، Routing، Database Query، Template Rendering) و لایه Network (Propagation Delay، Queuing Delay). در هر لایه، پارامترهای مشخصی تصمیم‌گیری را از سطح سلیقه به سطح مهندسی منتقل می‌کنند: Latency P75، Cache Hit Ratio، Query Count، و TLS Version. سه اصل که در پروژه‌های سازمانی به آن‌ها پایبندم: اول، TTFB را در سه صفحه کلیدی و در سه بازه زمانی مختلف اندازه بگیرید؛ نتیجه یک تست در یک ساعت مشخص، نمونه‌ای از رفتار کلی نیست. دوم، از لایه Server Processing شروع کنید، نه از لایه Network؛ در بنچمارک‌های واقعی، Object Cache و Page Cache بین ۶۰ تا ۹۰ درصد از TTFB را حذف می‌کنند، درحالی‌که CDN فقط ۳۰ تا ۷۰ درصد. سوم، بعد از هر اقدام بهینه‌سازی، حداقل ۴۸ ساعت پایش کنید تا اثر واقعی در بار Production مشخص شود. تجربه‌های خود از بهینه‌سازی TTFB در پروژه‌های واقعی، از بنچمارک‌های کاهش TTFB و LCP، از الگوهای Cache که به آن‌ها رسیده‌اید، یا از Trade-off بین Cost، Latency و Complexity در بهینه‌سازی، را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر در پروژه‌ای به گلوگاه غیرمنتظره در TTFB برخورده‌اید، آن تجربه‌ها برای مهندسان وب بعدی از هر توصیه کلی ارزشمندتر است.