TTFB چیست؟ راه های بهبود TTFB یا Time to First Byte

هیچکس سایت‌های کند را دوست ندارد! با استناد به مقاله‌ای در سایت Blogging wizard، در کاربرانی که از آن‌ها نظرسنجی‌ شده است، ۸۲ درصد گفته‌اند سرعت کند سایت می‌تواند در تصمیم آن‌ها مبنی بر خرید تاثیر بگذارد! یکی از پارامترهایی که برای سنجش سرعت سایت و سرور به کار گرفته می‌شود، TTFB نام دارد. متریکی که بحث‌های زیادی پیرامون خوب یا بد بودنش وجود دارد. فارغ از اینکه واقعا کاربردی است یا خیر، آنقدری اهمیت داشت که تصمیم گرفتیم مقاله‌ای دربارۀ آن بنویسیم. در ادامه، همه‌چیز را راجع‌به این موضوع یاد خواهید گرفت. می‌فهمید که TTFB چیست و چطور با بهبود آن سرعت سایت را بهبود ببخشید. اگر موافق باشید شروع کنیم.

TTFB چیست؟ به زبان ساده

TTFB مخفف Time to First Byte است. اگر بخواهیم به دور از هرگونه پیچیدگی معنای آن را بگوییم، یعنی مدت‌زمانی که طول می‌کشد تا اولین بایت از پاسخ سرور به سیستم کاربر درخواست‌کننده برسد. بگذارید قضیه را کمی باز کنیم. یکی از مهم‌ترین کارایی‌های TTFB این است که کند بودن بیش‌ازحد سرور را معلوم می‌کند.

وقتی کاربری درخواستی را به سرور شما می‌فرستد، مدتی طول می‌کشد تا درخواست پردازش شود و پاسخ ایجاد‌شده در مرورگر کاربر نمایش داده شود. مثلاً وقتی کاربر آدرس URL سایتتان را در نوار مرورگرش می‌نویسد، در واقع درخواست دیدن صفحه را دارد. به مجموع زمانی که طول می‌کشد تا کاربر صفحه را در مرورگرش ببیند، Time to First Byte یا TTFB می‌گویند.

بسیاری این پارامتر را حیاتی می‌دانند، در حالی که عده دیگری ارزش چندانی برای آن قائل نیستند.

TTFB جزو پارامترهای Core Web Vitals به حساب نمی‌آید؛ به همین خاطر، خیلی‌ها بهینه‌سازی آن را غیرضروری می‌دانند. همچنین، این عده می‌گویند از آنجا که این متریک وابستگی زیادی به کاربر نهایی دارد، چندان قابل اتکا نیست؛ یعنی متغیرهای زیادی وجود دارند که همه تحت کنترل شما نیستند! بنابراین، تلاش برای پایین آوردن عدد آن کار چندان سودآوری هم نیست.

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

از نظر ما، TTFB جایی بین این دو قرار می‌گیرد؛ نه بی‌فایده است و نه به‌تنهایی خیلی کاربرد دارد؛ اما وقتی با متریک‌های دیگر ترکیب می‌شود، می‌تواند اطلاعات خوبی دربارۀ سرعت سایت ارائه کند.

این پارامتر مجموع زمان‌های زیر است:

• مدت‌زمان ریدایرکت؛
• مدت‌زمان بالا آمدن Service Worker؛
• مدت‌زمان بررسی DNS؛
• مدت‌زمان اتصال و بررسی TLS؛
• مدت‌زمان رسیدن اولین بایت از پاسخ.

هرکدام از این مراحل ممکن است تاخیری خواسته یا ناخواسته داشته باشند که به بالا رفتن زمان TTFB منجر شوند.

چه مراحلی روی TTFB تاثیر می‌گذارد؟

از نگاهی دیگر، TTFB از ۳ مرحله تأثیر می‌گیرد:

۱. ارسال درخواست کاربر به سرور

پارامترهای زیادی در این مرحله دخیل هستند. مثل بررسی DNS، سرعت شبکه کاربر، فاصله با سرور و هر مزاحمتی که در اتصال وجود داشته باشد. صاحب سرور یا سایت، کنترلی روی اتصال کاربر و سرور ندارد، اما همین فاکتور هم روی TTFB اثرگذار است!

۲. پردازش درخواست توسط سرور

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

۳. ارسال پاسخ از سرور به کاربر

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

احتمالاً خیلی‌ها Time to First Byte را با Server Response Time یکی بدانند، اما این دو فاکتور با هم تفاوت دارند.

تفاوت TTFB و Server Response Time در چیست؟

بارز‌ترین تفاوت بین این دو، این است که در Server Response Time مشخص نمی‌شود که پاسخ چه زمانی به کاربر می‌رسد! فقط مدت‌زمانی که طول می‌کشد تا سرور پاسخ را پردازش و ایجاد کند زیر ذره‌بین می‌رود. در حالی که در TTFB، مهم‌ترین قسمت زمانی است اولین بایت از جواب توسط سیستم کاربر دانلود می‌شود.

همچنین در Server Response Time، فاکتور تاخیر شبکه که نقش مهمی در تجربۀ کاربری دارد محاسبه نمی‌شود؛ در حالی که TTFB این مورد را هم لحاظ می‌کند.

برویم سراغ عدد مناسب برای TTFB.

---

پیشنهاد خواندن: CLS چیست؟ راه های بهبود CLS

---

عدد خوب برای TTFB چند است؟

احتمالاً تا الان متوجه شده باشید! در رابطه با TTFB، هرقدر عدد پایین‌تر باشد بهتر است؛ چراکه معمولاً نشان‌دهنده سرعت بالاتر سایت است.

وب‌سایت‌ها به شکل‌های مختلفی محتوا را به دستگاه کاربر می‌فرستند؛ یکی از لازمه‌ها برای اینکه این محتوا در سریع‌ترین زمان ممکن به کاربر برسد، داشتن TTFB پایین است.

در رابطه با وب‌سایت‌های SPA، محتوای اولیه به‌سرعت به کاربر می‌رسد، اما وقتی پای جاوااسکریپت برای محتواهای داینامیک صفحه وسط می‌آید، کار کمی پیچیده‌تر می‌شود. در چنین شرایطی، با داشتن FTTB مناسب می‌توانید کاری کنید تا سیستم کاربر سریع‌تر محتوای شما را دریافت کند.

البته خوب است بدانید نحوه عرضه محتوا توسط سایت هم مهم است. ممکن است سایتی که بیشتر کارهایش در سمت سرور انجام می‌شود، TTFB بالایی داشته باشد، اما از آنجایی که سرور صفحه را به‌صورت کامل به مرورگر کاربر می‌فرستد، سرعت مناسبی از خود نشان دهد.

در طرف مقابل، سروری که بیشتر کارهایش در سمت کاربر انجام می‌شود، TTFB پایینی خواهد داشت! اولین بایت پاسخ خیلی سریع به سیستم کاربر می‌رسد؛ اما برای اینکه صفحه تکمیل شود، مدت‌زمان بیشتری لازم خواهد بود.

بنابراین، همان‌طور که در بخش قبلی گفتیم، TTFB به‌تنهایی متریک تعیین‌کننده‌ای نخواهد بود و باید در ترکیب با دیگر متریک‌ها از آن استفاده شود.

به‌ هر حال، اجازه دهید یک استاندارد کلی از عدد خوب برای TTFB خدمتتان ارائه کنیم:

• کمتر از ۸۰۰ میلی‌ثانیه: عالی!
• بین ۸۰۰ تا ۱۸۰۰ میلی‌ثانیه: قابل‌قبول!
• بیشتر از ۱۸۰۰ میلی‌ثانیه: ضعیف!

چطور می‌توان این عدد را به دست آورد؟ در بخش بعدی به این پرسش پاسخ خواهیم داد.

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

متریک TTFB می‌تواند هم در حالت آزمایشگاهی (Lab) و هم در حالت واقعی (Field) اندازه‌گیری شود. حالت اول، همان‌طور که از نامش مشخص است، در یک شرایط ایزوله و آزمایشگاهی سعی می‌کنند به عددی ایدئال دست پیدا کند.

در حالت دوم، اوضاع کمی متفاوت است. در اندازه‌گیری‌های Field، پارامترها واقعی هستند و به همین خاطر، عدد به دست آمده بیشتر قابل استناد است. ساده بگوییم، عدد به دست آمده در حالت دوم به واقعیت نزدیک‌تر است.

با توجه به آنچه تا اینجا گفته‌ایم، می‌توانید حدس بزنید راه‌های بسیاری برای محاسبه TTFB وجود دارند. ما در این مقاله به دو مورد از آن‌ها خواهیم پرداخت.

اندازه گیری TTFB در جاوااسکریپت

شما می‌توانید زمان‌ TTFB مربوط به Navigation Requests را در مرورگر خود به‌وسیله Navigation Timing API اندازه بگیرید. تکه کد زیر نشان می‌دهد که چطور می‌توانید به‌منظور رصد ورودی‌های Navigation یک PerformanceObserver بسازید و آن را به کنسول وصل کنید:

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType(‘navigation’);

console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
type: ‘navigation’,
buffered: true
});

نکته: همه مرورگرها از PerformanceObserver پشتیبانی نمی‌کنند! برای اینکه بتوانید نهایت کارآمدی مرورگر را داشته باشید، باید از یک کتابخانه جاوااسکریپت با نام Web-vitals استفاده کنید.

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

import {onTTFB} from ‘web-vitals’;

// Measure and log TTFB as soon as it’s available.
onTTFB(console.log);

اندازه‌گیری درخواست منابع

TTFB فقط مختص Navigation Requests نیست و شامل هرگونه درخواستی می‌شود. به‌طور مشخص، فرستادن درخواست به سرورهای دیگر درون شبکه، می‌تواند به تاخیر و افزایش TTFB منجر شود.

به‌منظور محاسبه TTFB برای منابع، از Resource Timing API در یک PerformanceObserver استفاده کنید.

new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();

for (const entry of entries) {
// Some resources may have a responseStart value of 0, due
// to the resource being cached, or a cross-origin resource
// being served without a Timing-Allow-Origin header set.
if (entry.responseStart > ۰) {
console.log(`TTFB: ${entry.responseStart}`, entry.name);
}
}
}).observe({
type: ‘resource’,
buffered: true
});

تکه کد بالا شبیه کدی است که برای Navigation Request مورد استفاده قرار می‌گیرد و بالاتر به آن اشاره کردیم. فقط به‌جای دنبال ورودی‌های ‘navigation’ گشتن، دنبال ورودی‌های ‘resources’ می‌گردد.

حالا که چگونگی محاسبه را یاد گرفتیم، بیایید ببینیم چطور می‌توان عدد آن را تا حد ممکن پایین آورد.

آموزش کامل بهینه‌سازی TTFB

همان‌طور که در خلال متن اشاره کردیم، بهینه سازی فاکتور TTFB سایت خیلی هم ضروری نیست! اما اگر دوست دارید تجربه کاربری خوبی برای بازدیدکنندگان خلق کنید، خوب است برنامه‌ای برای پایین آوردن عدد آن داشته باشید.

این شما و این روش‌های بهینه‌سازی TTFB.

انتخاب هاستینگ مناسب

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

هاست‌های اشتراکی معمولاً سرعت پایینی دارند؛ اگر سایت سبکی دارید که ترافیک چندانی ندارد، استفاده از هاست اشتراکی معقول است. با به‌کارگیری چند تکنیک کلی که جلوتر خواهیم گفت، می‌توانید TTFB را تا حد ممکن پایین بیاورید.

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

قبل از خرید هاست سوال‌های زیر را از خودتان بپرسید:

• چقدر مموری به سایت اختصاص داده شده است؟ اگر میزان مموری کافی نباشد، سایت یا اپلیکیشن در ارائه سریع صفحات دچار مشکل خواهد شد.
• آیا هاستینگ شما نرم‌افزارها و فریمورک‌های بکند (back end) را به‌روز می‌کند؟ با آمدن نسخه‌های جدید زبان‌ها، پیاده‌سازی‌های HTTP و نرم‌افزارهای مرتبط با دیتابیس، استک بکند بهبود پیدا می‌کند؛ به همین دلیل، بسیار مهم است هاستینگ دائماً استک بکند را به‌روز کند.
• آیا امکان کاستومایز کردن back end سرور وجود دارد؟ گاهی ممکن است بخواهید اپلیکیشن‌های خاصی را به سرورتان اضافه کنید، مهم است که هاستینگ این قابلیت را ارائه کند.

مطابق دستورالعمل‌های پلتفرم سایت خود عمل کنید

اینکه از چه پلتفرمی برای سایت یا اپلیکیشن خود استفاده می‌کنید، تاثیر بسیاری روی TTFB خواهد گذاشت.

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

از CDN استفاده کنید

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

با استفاده از CDN، محتوای سرور اصلی روی سرورهایی که در نقاط مختلف دنیا قرار گرفته‌اند کش می‌شود؛ به این ترتیب، هر کاربر اطلاعات را از سروری که به او نزدیک‌تر است دریافت خواهد کرد. به این سرورها اصطلاحاً Edge Servers گفته می‌شود.

CDN می‌تواند فایده‌های زیادی برای شما داشته باشد:

• افزایش سرعت پاسخ‌دهی DNS؛
• ارائه محتوا با پروتکل‌های مدرن مثل HTTP/2 و HTTP/3؛
• استفاده از نسخه‌های جدید TLS که سریع‌تر هستند؛
• ارائه قابلیت Edge Worker که پاسخ را در سرورهای Edge ویرایش و آماده ارسال می‌کند.

با توجه به این قابلیت‌ها، استفاده از CDN یکی از بایدها برای بهینه‌سازی TTFB هر سایت و سرور است.

عدم استفاده از ریداریکت‌های متعدد

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

دو نوع ریداریکت داریم:

1. Same-origin: وقتی مقصد ریدایرکت داخل همان سایت مبداء باشد.
2. Cross-orgin: وقتی مقصد ریدایرکت جایی خارج از سایت باشد؛ مثلاً URL یک شبکه اجتماعی.

وقتی قصد کاهش ریدایرکت‌های دسته اول را داشته باشید، باید دنبال آن‌هایی بگردید که به کد ۳۰۲ یا ۳۰۱ ختم می‌شوند.

برای کاهش دسته دوم کار کمی پیچیده‌تر است؛ چراکه کنترل کامل در اختیار شما نیست. در هر صورت سعی کنید تا جای ممکن ریدایرکت‌های اضافی را که باعث افزایش زمان TTFB می‌شوند حذف کنید.

مورد دیگری که باید به آن توجه داشت، ریدایرکت از HTTP به HTTPS است. راهکار حل کردن مشکلات مربوط به چنین ریدایرکت‌هایی، استفاده از هدر Strict-Transport-Security است که به آن HSTS هم می‌گویند. البته ناگفته نماند که در استفاده از HSTS باید بسیار مراقب باشید، چراکه استفاده نادرست از آن می‌توان کل سایتتان را از بین ببرد.

ارسال بخش‌بخش پاسخ به مرورگر

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

بسیار مهم است که اطمینان حاصل کنید سرورتان تکه‌های پاسخ را تا تکمیل شدن پیش خود نگه نمی‌دارد؛ چراکه با این کار، TTFB هم افزایش پیدا خواهد کرد.

استفاده از Service Worker

داشتن Service worker API می‌تواند به کاهش زمان TTFB کمک بزرگی بکند.

به زبان ساده، Service Worker نوعی Web Worker است که در بکگراند مرورگر کار می‌کند و وظیفه رسیدگی به درخواست‌های سایت و اپلیکیشن را دارد.

می‌توان گفت Service Worker نقش پروکسی میان مرورگر و سرور را بازی می‌کند. اینکه آیا این پروکسی اثری روی TTFB می‌گذارد یا نه، به تنظیم‌بندی و همخوانی آن با نیازهای اپلیکیشن بستگی دارد.

با به کارگیری این تکنیک‌‌ها، می‌توانید زمان TTFB را تا حد ممکن کاهش دهید و آن را به مقدار ایدئال نزدیک کنید.

به پایان مقاله رسیدیم، اگر موافق باشید برویم سراغ جمع‌بندی.

---

سوالات متداول شما

---

TTFB .۱ چیست؟

TTFB یعنی مدت‌زمانی که طول می‌کشد تا اولین بایت از پاسخ سرور به سیستم کاربر درخواست‌کننده برسد.

۲. TTFB باید چه‌قدر باشد؟

اگر کمتر از ۸۰۰ میلی‌ثانیه: عالی، بین ۸۰۰ تا ۱۸۰۰ میلی‌ثانیه: قابل‌قبول! بیشتر از ۱۸۰۰ میلی‌ثانیه: ضعیف است!

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

شما می‌توانید زمان‌ TTFB مربوط به Navigation Requests را در مرورگر خود به‌وسیله Navigation Timing API اندازه بگیرید. برای آشنایی با سایر روش‌ها به مقاله مراجعه کنید.

TTFB: پارامتری که بهبود آن تجربه کاربری را ارتقا می‌دهد!

همان‌طور که در این مقاله خواندید، TTFB یا اگر بخواهیم آن را کامل بگوییم، Time to First Byte، نشان‌دهنده مدت‌زمانی است که طول می‌کشد اولین بایت از پاسخ به مرورگر کاربری که درخواست را ارسال کرده است، برسد.

بعد از بررسی چیستی این متریک، عدد ایدئال برای آن و چگونگی سنجشش را بررسی کردیم. در انتها هم راهکارهایی را ارائه کردیم که با استفاده از آن‌ها می‌توانید عدد آن را کاهش بدهید.

امیدواریم از خواندن این مقاله راضی بوده باشید، اگر همچنان پرسشی در این رابطه دارید، در قسمت نظرات برایمان بنویسید تا خیلی زود پاسختان را بدهیم.

منابع: Web.dev | Stackpath