وقتی کاربر آدرس یک صفحه را در مرورگر وارد می‌کند، مرورگر بلافاصله محتوای صفحه را دریافت نمی‌کند. ابتدا باید درخواست به سرور برسد، ارتباط لازم برقرار شود، سرور درخواست را پردازش کند و سپس اولین بخش از پاسخ را برای مرورگر ارسال کند.
مدت زمانی که از شروع درخواست تا دریافت اولین بایت پاسخ طی می‌شود، TTFB یا Time to First Byte نام دارد. به زبان ساده، TTFB نشان می‌دهد سرور و زیرساخت سایت چقدر سریع می‌توانند پاسخ به یک درخواست را آغاز کنند.
برای مثال فرض کنید وارد یک فروشگاه فیزیکی می‌شوید و از فروشنده یک محصول را درخواست می‌کنید. اگر فروشنده ۱۰ ثانیه هیچ واکنشی نشان ندهد، حتی اگر بعد از آن محصول را خیلی سریع تحویل دهد، تجربه شما از خدمات فروشگاه چندان مناسب نخواهد بود.
TTFB نیز تا حدودی همین بخش از تجربه را در فضای وب اندازه‌گیری می‌کند؛ یعنی چه مدت طول می‌کشد تا پاسخ سرور شروع شود.
TTFB چگونه محاسبه می‌شود؟
TTFB فقط زمان پردازش PHP یا تولید HTML توسط سرور نیست. این معیار می‌تواند چند مرحله از درخواست را دربر بگیرد؛ از جمله زمان Redirect، جستجوی DNS، برقراری اتصال، مذاکره TLS و زمانی که سرور برای پردازش درخواست صرف می‌کند.
به شکل ساده می‌توان مسیر را این‌گونه تصور کرد:
درخواست کاربر → DNS → برقراری اتصال → ارسال درخواست → پردازش سرور → شروع پاسخ → اولین بایت
بنابراین اگر یکی از این مراحل زمان زیادی ببرد، مقدار TTFB نیز افزایش پیدا می‌کند.
البته در شرایط واقعی، نحوه اندازه‌گیری TTFB به ابزار و نوع درخواست بستگی دارد و برای تحلیل دقیق باید مشخص باشد که ابزار مورد استفاده دقیقاً کدام بخش از فرآیند را اندازه‌گیری می‌کند.
TTFB خوب چقدر است؟
طبق راهنمای web.dev، به‌عنوان یک راهنمای تقریبی، بیشتر سایت‌ها بهتر است برای TTFB به عدد ۸۰۰ میلی‌ثانیه یا کمتر برسند. مقادیر بالاتر از حدود ۱.۸ ثانیه در دسته ضعیف قرار می‌گیرند و بازه بین این دو مقدار نیازمند بهبود است.
اما نباید این اعداد را به‌عنوان یک قانون مطلق در نظر گرفت.
نکته مهم این است که TTFB یکی از Core Web Vitals نیست. بنابراین داشتن TTFB بالاتر از ۸۰۰ میلی‌ثانیه به‌تنهایی به این معنی نیست که سایت شما عملکرد نامناسبی دارد. باید آن را در کنار معیارهایی مانند FCP و LCP و همچنین نحوه ارائه محتوای اصلی سایت بررسی کرد.
برای مثال ممکن است یک سایت TTFB نسبتاً بالایی داشته باشد، اما به دلیل معماری مناسب و بهینه بودن بخش‌های دیگر، محتوای اصلی را سریع نمایش دهد. در مقابل، پایین آوردن TTFB به تنهایی تضمین نمی‌کند که تمام مشکلات سرعت سایت برطرف شده‌اند.
چرا TTFB برای سرعت سایت مهم است؟
TTFB یکی از معیارهای ابتدایی در مسیر بارگذاری صفحه است. تا زمانی که پاسخ HTML از سمت سرور شروع نشود، مرورگر نمی‌تواند بسیاری از مراحل بعدی نمایش صفحه را آغاز کند.
به همین دلیل، TTFB بالا می‌تواند روی معیارهای دیگری که بعد از آن قرار می‌گیرند نیز اثر بگذارد. web.dev نیز توضیح می‌دهد که TTFB قبل از معیارهایی مانند FCP و LCP قرار می‌گیرد و افزایش آن می‌تواند زمان لازم برای این مراحل بعدی را افزایش دهد.
فرض کنید یک رستوران سفارش مشتری را با تأخیر زیادی دریافت و پردازش کند. حتی اگر آشپز غذا را پس از شروع کار خیلی سریع آماده کند، تأخیر اولیه همچنان روی زمان نهایی تحویل اثر گذاشته است.
در سایت نیز شرایط مشابهی وجود دارد. اگر سرور دیر پاسخ دهد، مرورگر برای شروع بخش‌هایی از فرآیند بارگذاری باید بیشتر منتظر بماند.
چه عواملی باعث افزایش TTFB می‌شوند؟
بالا بودن TTFB معمولاً یک علت واحد ندارد و باید مرحله‌ای که بیشترین تأخیر را ایجاد می‌کند شناسایی شود.
۱. هاست یا سرور ضعیف
یکی از اولین مواردی که هنگام بررسی TTFB باید بررسی شود، زیرساخت میزبانی است.
اگر منابع پردازشی سرور محدود باشند یا سرور تحت فشار زیادی قرار داشته باشد، پردازش درخواست‌ها می‌تواند با تأخیر انجام شود. البته صرفاً خرید هاست گران‌تر همیشه مشکل را حل نمی‌کند؛ ابتدا باید مشخص شود که محدودیت واقعاً از منابع سرور ناشی می‌شود یا از برنامه و نحوه پردازش درخواست.
۲. پردازش سنگین سمت سرور
گاهی مشکل از خود سرور نیست، بلکه برنامه‌ای که روی آن اجرا می‌شود برای تولید پاسخ زمان زیادی نیاز دارد.
برای مثال فرض کنید یک سایت فروشگاهی هنگام باز شدن صفحه محصول، اطلاعات متعددی را از پایگاه داده دریافت کند، چند محاسبه انجام دهد و سپس صفحه را تولید کند. اگر این فرآیند بهینه نشده باشد، زمان پاسخ افزایش پیدا می‌کند.
۳. کوئری‌های سنگین پایگاه داده
پایگاه داده بخش مهمی از بسیاری از سایت‌های امروزی است. جستجوی نامناسب، کوئری‌های پیچیده، حجم بالای داده یا نبود ایندکس مناسب می‌تواند زمان پردازش درخواست را افزایش دهد.
در چنین شرایطی نصب یک افزونه کش بدون بررسی پایگاه داده ممکن است مشکل اصلی را برطرف نکند.
۴. نبود کش مناسب
کش کردن باعث می‌شود در بسیاری از درخواست‌ها سرور مجبور نباشد همه مراحل تولید صفحه را از ابتدا انجام دهد.
اگر صفحه‌ای قابلیت کش شدن داشته باشد، ارائه نسخه ذخیره‌شده آن می‌تواند زمان پاسخ را کاهش دهد. البته نوع کش باید متناسب با معماری سایت انتخاب شود؛ زیرا برای صفحات پویا، حساب کاربری، سبد خرید و برخی بخش‌های شخصی‌سازی‌شده نمی‌توان بدون بررسی از یک سیاست کش ساده استفاده کرد.
۵. تعداد زیاد Redirect
Redirectهای غیرضروری نیز می‌توانند به مسیر درخواست اضافه کنند. برای مثال اگر یک آدرس ابتدا به URL دیگری و سپس به URL نهایی هدایت شود، بخشی از زمان درخواست صرف همین انتقال‌ها خواهد شد.
به همین دلیل بهتر است زنجیره‌های ریدایرکت غیرضروری شناسایی و تا حد امکان حذف شوند.
۶. فاصله جغرافیایی کاربر و سرور
موقعیت جغرافیایی نیز می‌تواند روی زمان ارتباط اثر داشته باشد. وقتی کاربر از فاصله زیادی نسبت به محل سرور درخواست ارسال می‌کند، مسیر شبکه و زمان برقراری ارتباط می‌تواند متفاوت باشد.
شبکه توزیع محتوا یا CDN در برخی معماری‌ها می‌تواند با نزدیک‌تر کردن بخشی از محتوا به کاربران، به کاهش تأخیر شبکه کمک کند؛ البته CDN برای همه بخش‌های TTFB راه‌حل مستقیم نیست و عملکرد آن به نحوه پیکربندی و نوع محتوای سایت بستگی دارد.
پیشنهاد مطالعه : Cumulative Layout Shift (CLS) چیست؟
چگونه TTFB سایت را اندازه‌گیری کنیم؟
برای بررسی TTFB ابزارهای مختلفی وجود دارد و بهتر است فقط به یک تست آزمایشگاهی اکتفا نکنید.
بررسی TTFB با Chrome DevTools
یکی از روش‌های ساده این است که در مرورگر Chrome روی صفحه موردنظر کلیک راست کرده و وارد Inspect شوید. سپس در بخش Network، درخواست اصلی صفحه را بررسی کنید.
در جزئیات Timing می‌توان زمان‌های مختلف درخواست را مشاهده کرد و متوجه شد تأخیر بیشتر در کدام بخش اتفاق افتاده است. این روش برای عیب‌یابی اولیه بسیار کاربردی است، زیرا به جای اینکه فقط یک عدد مشاهده کنید، می‌توانید فرآیند درخواست را نیز بررسی کنید.
استفاده از WebPageTest
WebPageTest یکی دیگر از ابزارهایی است که می‌تواند اطلاعات دقیق‌تری درباره فرآیند بارگذاری و زمان پاسخ ارائه کند. برای تحلیل عملکرد، بهتر است تست را از موقعیت‌ها و شرایط مختلف انجام دهید و به یک اجرای منفرد وابسته نباشید.
داده‌های واقعی کاربران
TTFB را می‌توان در داده‌های واقعی کاربران نیز بررسی کرد. Chrome UX Report یا CrUX شامل داده‌های میدانی مرتبط با TTFB است و برای بررسی عملکرد واقعی سایت در بین کاربران قابل استفاده است.
این موضوع اهمیت زیادی دارد؛ زیرا ممکن است یک سایت در کامپیوتر مدیر سایت سریع باشد، اما کاربران با اینترنت، دستگاه یا موقعیت جغرافیایی متفاوت تجربه دیگری داشته باشند.
چگونه TTFB را کاهش دهیم؟
برای کاهش TTFB نباید به سراغ یک راهکار ثابت برای همه سایت‌ها رفت. ابتدا باید علت تأخیر مشخص شود و سپس راهکار مناسب اجرا شود.
سرور و هاست را بررسی کنید
اگر منابع سرور دائماً درگیر هستند یا زمان پردازش درخواست‌ها بالاست، باید وضعیت CPU، RAM، I/O و محدودیت‌های هاست بررسی شود. در سایت‌های پرترافیک، ارتقای زیرساخت ممکن است ضروری باشد؛ اما قبل از آن بهتر است مشخص شود که افزایش منابع واقعاً مشکل را حل می‌کند یا خیر.
سیستم کش را به‌درستی پیاده‌سازی کنید
کش یکی از روش‌های مهم برای کاهش پردازش‌های تکراری است. در یک سایت محتوایی، بسیاری از صفحات تغییرات لحظه‌ای ندارند و می‌توان آنها را با سیاست مناسبی از کش ارائه کرد.
در سایت‌های فروشگاهی یا سامانه‌های پویا، کش باید با دقت بیشتری تنظیم شود تا اطلاعات شخصی و داده‌های لحظه‌ای کاربران اشتباهاً از نسخه ذخیره‌شده نمایش داده نشوند.
پایگاه داده را بهینه کنید
اگر بررسی‌ها نشان دهد زمان زیادی صرف پردازش دیتابیس می‌شود، باید کوئری‌ها، ایندکس‌ها و ساختار داده بررسی شوند.
در یک فروشگاه مواد غذایی برای مثال، اگر سیستم برای پیدا کردن هر محصول مجبور باشد هر بار هزاران رکورد غیرمرتبط را بررسی کند، طبیعی است که پاسخ دیرتر آماده شود. طراحی بهتر جستجو و استفاده مناسب از ایندکس‌ها می‌تواند چنین فرآیندی را سریع‌تر کند.
تعداد Redirectها را کاهش دهید
بهتر است کاربر تا حد امکان مستقیماً به URL نهایی هدایت شود.
اگر چند Redirect پشت سر هم وجود دارد، زنجیره را بررسی کنید و در صورت امکان آن را به یک Redirect مستقیم تبدیل کنید.
کدهای سمت سرور را بررسی کنید
اگر سایت از PHP، Node.js، Python یا فناوری دیگری در سمت سرور استفاده می‌کند، عملکرد کدها می‌تواند روی زمان پاسخ تأثیر داشته باشد.
گاهی یک تابع یا درخواست خارجی که در هر بار بارگذاری صفحه اجرا می‌شود، عامل اصلی تأخیر است. بنابراین قبل از نصب ابزارهای بیشتر، بهتر است فرآیند تولید پاسخ بررسی و گلوگاه اصلی شناسایی شود.
از CDN در جای مناسب استفاده کنید
CDN می‌تواند برای کاهش برخی تأخیرهای شبکه و ارائه سریع‌تر منابع از نقاط نزدیک‌تر به کاربر مفید باشد، اما نباید تصور کرد که استفاده از CDN تمام مشکلات TTFB را حل می‌کند.
اگر سرور برای تولید HTML زمان زیادی صرف می‌کند، قرار دادن CDN به تنهایی لزوماً این مشکل پردازشی را از بین نمی‌برد.
پیشنهاد مطالعه»: inp چیست ؟
تفاوت TTFB با سرعت کامل بارگذاری صفحه چیست؟
TTFB فقط بخشی از فرآیند بارگذاری را اندازه‌گیری می‌کند.
برای مثال تصور کنید TTFB یک صفحه ۶۰۰ میلی‌ثانیه باشد. این عدد نشان می‌دهد پاسخ اولیه نسبتاً سریع آغاز شده، اما هنوز مشخص نیست محتوای اصلی صفحه چه زمانی نمایش داده می‌شود.
پس از دریافت اولین بایت، مرورگر باید HTML را پردازش کند، فایل‌های CSS و JavaScript و تصاویر را دریافت کند و عناصر صفحه را نمایش دهد.
به همین دلیل ممکن است یک سایت TTFB مناسبی داشته باشد ولی همچنان به دلیل تصاویر سنگین، JavaScript زیاد یا مشکلات مربوط به رندر، کند احساس شود.
از طرف دیگر، TTFB بالا می‌تواند از همان ابتدای مسیر برای معیارهایی مانند FCP و LCP زمان اضافه ایجاد کند.
TTFB را باید یکی از اجزای عملکرد سایت بدانید، نه معادل سرعت کلی سایت.
آیا TTFB روی سئو تأثیر دارد؟
پاسخ دقیق این است که نباید TTFB را یک فاکتور مستقل رتبه‌بندی معرفی کرد.
TTFB یک معیار عملکردی است که برای تشخیص سرعت پاسخ‌گویی سرور اهمیت دارد و روی مسیر بارگذاری صفحه اثر می‌گذارد. از طرف دیگر، TTFB خودش یکی از Core Web Vitals نیست.
بنابراین بهتر است به جای اینکه صرفاً با هدف رسیدن به یک عدد خاص، TTFB را کاهش دهید، عملکرد کلی صفحه و تجربه واقعی کاربر را بررسی کنید.
اگر TTFB بالا باشد، پیدا کردن علت آن همچنان اهمیت زیادی دارد؛ زیرا تأخیر در پاسخ اولیه می‌تواند روی مراحل بعدی بارگذاری نیز اثر بگذارد.
آیا باید حتماً TTFB را به کمتر از ۸۰۰ میلی‌ثانیه برسانیم؟
عدد ۸۰۰ میلی‌ثانیه یک راهنمای تقریبی است، نه قانونی که تمام سایت‌ها مجبور باشند دقیقاً آن را رعایت کنند.
web.dev نیز صراحتاً اشاره می‌کند که TTFB یک Core Web Vital نیست و این آستانه باید با توجه به نحوه ارائه محتوای سایت و سایر معیارهای عملکرد تفسیر شود.
بنابراین اگر TTFB سایت شما مثلاً ۹۰۰ میلی‌ثانیه است، نباید بدون بررسی سایر داده‌ها نتیجه بگیرید که سایت حتماً مشکل جدی دارد. ابتدا باید مشخص کنید آیا این تأخیر روی FCP، LCP و تجربه واقعی کاربران اثر قابل‌توجهی گذاشته است یا خیر.
یک روش عملی برای عیب‌یابی TTFB
اگر TTFB سایت شما بالاست، بهتر است این مسیر را دنبال کنید:
۱. مقدار TTFB را در چند نوبت اندازه‌گیری کنید.
یک تست منفرد برای تصمیم‌گیری کافی نیست.
۲. تست را از شرایط مختلف انجام دهید.
موقعیت جغرافیایی، نوع اتصال و شرایط شبکه می‌توانند روی نتیجه اثر بگذارند.
۳. بخش Timing درخواست را بررسی کنید.
مشخص کنید تأخیر بیشتر مربوط به اتصال، Redirect، پردازش سرور یا بخش دیگری است.
۴. وضعیت سرور را بررسی کنید.
مصرف منابع و محدودیت‌های هاست را بررسی کنید.
۵. کش و CDN را بررسی کنید.
مطمئن شوید سیاست کش درست اجرا می‌شود و CDN نیز متناسب با ساختار سایت پیکربندی شده است.
۶. اگر مشکل باقی ماند، کد و دیتابیس را بررسی کنید.
در این مرحله باید مشخص شود آیا کوئری‌های سنگین، افزونه‌ها، APIهای خارجی یا پردازش‌های سمت سرور باعث ایجاد تأخیر شده‌اند.
این رویکرد بسیار بهتر از آن است که بدون پیدا کردن علت، چند افزونه بهینه‌سازی روی سایت نصب شود.
جمع‌بندی؛ TTFB چیست و چه کاری برای بهبود آن انجام دهیم؟
TTFB یا Time to First Byte مدت زمانی است که از شروع درخواست تا آغاز دریافت اولین بایت پاسخ طی می‌شود. این معیار یکی از شاخص‌های مهم برای بررسی سرعت پاسخ‌گویی سرور و زیرساخت سایت است.
TTFB بالا می‌تواند دلایل مختلفی داشته باشد؛ از هاست و شبکه گرفته تا پردازش‌های سمت سرور، پایگاه داده، Redirectهای اضافی و تنظیمات نامناسب کش. به همین دلیل، کاهش TTFB با نصب یک افزونه یا تغییر یک تنظیم خاص برای همه سایت‌ها امکان‌پذیر نیست.
به‌عنوان یک راهنمای تقریبی، web.dev پیشنهاد می‌کند بیشتر سایت‌ها برای TTFB حدود ۰.۸ ثانیه یا کمتر را هدف قرار دهند؛ با این حال، این عدد باید در کنار سایر معیارهای عملکرد و تجربه واقعی کاربران تفسیر شود.
اگر قصد دارید سرعت سایت را به شکل اصولی بهبود دهید، بهتر است به جای تمرکز روی یک عدد، مسیر کامل بارگذاری صفحه را بررسی کنید و ابتدا عامل اصلی تأخیر را پیدا کنید. در بسیاری از پروژه‌ها، همین مرحله تشخیص است که مشخص می‌کند مشکل واقعاً از سرور است یا از کد، پایگاه داده، کش، شبکه یا نحوه ارائه محتوا. از همین جهت می توانید با کارشناسان بخش سئو سایت در مجموعه دیجیتال مارکتینگ پرشیا وب در ارتباط باشید.
