بهینه‌سازی زمان دریافت اولین بایت (TTFB): راهنمای ساده برای بهبود عملکرد وب‌سایت

زمان دریافت اولین بایت (TTFB) یکی از معیارهای کلیدی عملکرد وب است که بر سایر معیارهای تجربه کاربری مانند First Contentful Paint (FCP) و Largest Contentful Paint (LCP) تأثیر می‌گذارد. TTFB نشان‌دهنده زمانی است که از لحظه شروع درخواست یک صفحه تا دریافت اولین بایت پاسخ از سرور طول می‌کشد. در این مقاله، به زبان ساده توضیح می‌دهیم که TTFB چیست، چگونه آن را اندازه‌گیری کنید و چه راهکارهایی برای بهینه‌سازی آن وجود دارد.

TTFB چیست؟

TTFB مدت زمانی است که مرورگر منتظر می‌ماند تا اولین بایت داده از سرور دریافت شود. این معیار شامل:

  • زمان جستجوی DNS: یافتن آدرس سرور.
  • زمان اتصال: برقراری ارتباط TCP و مذاکره TLS (برای HTTPS).
  • زمان ریدایرکت: تغییر مسیرها (مثل HTTP به HTTPS).
  • پردازش سرور: زمانی که سرور برای تولید پاسخ نیاز دارد.

چرا مهم است؟ TTFB بالا باعث تأخیر در بارگذاری صفحه و معیارهای بعدی مانند FCP و LCP می‌شود. این موضوع به‌ویژه برای برنامه‌های تک‌صفحه‌ای (SPA) که به جاوااسکریپت برای رندر وابسته‌اند، حیاتی است.

TTFB خوب چیست؟

برای تجربه کاربری خوب:

  • TTFB باید ۰.۸ ثانیه یا کمتر باشد (در صدک ۷۵ کاربران، برای موبایل و دسکتاپ).
  • TTFB ضعیف: بیشتر از ۱.۸ ثانیه.
  • نیاز به بهبود: بین ۰.۸ تا ۱.۸ ثانیه.

نمودار مقادیر TTFB توضیح تصویر: نموداری که مقادیر خوب (≤۰.۸ ثانیه)، نیاز به بهبود (۰.۸–۱.۸ ثانیه) و ضعیف (>۱.۸ ثانیه) را نشان می‌دهد.

نکته کلیدی: TTFB جزو Core Web Vitals نیست، اما تأثیر زیادی بر معیارهای دیگر دارد. برای سایت‌های رندر شده در سمت سرور، TTFB ممکن است بالاتر باشد اما FCP و LCP بهتری داشته باشند، در حالی که برای SPAها، TTFB پایین‌تر حیاتی است.

چگونه TTFB را اندازه‌گیری کنیم؟

برای بهینه‌سازی TTFB، ابتدا باید آن را در جهان واقعی (Field) و آزمایشگاه (Lab) اندازه‌گیری کنید. داده‌های واقعی شامل ریدایرکت‌ها هستند، اما ابزارهای آزمایشگاهی معمولاً URL نهایی را تست می‌کنند و ممکن است تأخیرهای ریدایرکت را نادیده بگیرند.

ابزارهای اندازه‌گیری

ابزارهای واقعی (Field)

داده‌های واقعی PageSpeed Insights توضیح تصویر: بخشی از PageSpeed Insights که TTFB واقعی کاربران را نشان می‌دهد.

ابزارهای آزمایشگاهی (Lab)

  • Lighthouse: زمان پاسخ سرور (زیرمجموعه TTFB) را بررسی می‌کند.
  • Chrome DevTools: پارامتر TTFB را در تب Network نمایش می‌دهد.
  • PageSpeed Insights: برای تست‌های آزمایشگاهی نیز قابل استفاده است.

ممیزی زمان پاسخ سرور در Lighthouse توضیح تصویر: گزارش Lighthouse که زمان پاسخ سرور را نشان می‌دهد (به‌جز زمان DNS و ریدایرکت).

نکته: ممیزی Lighthouse زمان DNS و ریدایرکت را شامل نمی‌شود، بنابراین تنها بخشی از TTFB را نشان می‌دهد.

تفاوت‌های TTFB واقعی و آزمایشگاهی

  • TTFB آزمایشگاهی بیشتر از واقعی: نشان‌دهنده محدودیت‌های محیط آزمایشگاهی است. نتایج همچنان معتبرند، اما ممکن است تأثیر مشکلات را بیش از حد نشان دهند.
  • TTFB واقعی بیشتر از آزمایشگاهی: نشان‌دهنده مشکلاتی مانند کش سرور، ریدایرکت‌ها یا تفاوت‌های شبکه است. در این حالت، آزمایش‌های آزمایشگاهی ممکن است مشکلات اصلی را نشان ندهند.

راهکار: برای بررسی کش سرور، صفحات کمتر بازدیدشده یا پارامترهای URL متفاوت را تست کنید. برای ریدایرکت‌ها، تحلیل کنید که ترافیک از کجا می‌آید.

اشکال‌زدایی TTFB بالا با Server-Timing

هدر Server-Timing به شما امکان می‌دهد فرآیندهای سمت سرور را که باعث تأخیر می‌شوند، اندازه‌گیری کنید. این هدر شامل نام، مدت زمان (dur) و توضیح اختیاری (desc) است.

مثال:

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

تنظیم هدر در PHP:

<?php
// زمان شروع پرس‌وجو از پایگاه داده
$dbReadStartTime = hrtime(true);

// اجرای پرس‌وجو
// ...

// زمان پایان پرس‌وجو
$dbReadEndTime = hrtime(true);

// محاسبه زمان (تبدیل نانوثانیه به میلی‌ثانیه)
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;

// تنظیم هدر Server-Timing
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

دسترسی در جاوااسکریپت (واقعی):

performance.getEntriesByType('navigation')[0].serverTiming.forEach(entry => {
  console.log(entry.name, entry.description, entry.duration);
});

در آزمایشگاه: هدرهای Server-Timing در تب Network مرورگر کروم (Chrome DevTools) نمایش داده می‌شوند.

هدر Server-Timing در Chrome DevTools توضیح تصویر: نمایش هدر Server-Timing که وضعیت کش CDN و زمان دسترسی به سرور را نشان می‌دهد.

جایگزین: اگر استفاده از Server-Timing ممکن نیست، از ابزارهای Application Performance Monitoring (APM) برای تشخیص مشکلات عملکرد سرور استفاده کنید.

راه‌های بهینه‌سازی TTFB

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

۱. راهنمای خاص پلتفرم

پلتفرم سایت شما (مثل وردپرس) روی TTFB تأثیر می‌گذارد. برای مثال، در وردپرس، تعداد و کیفیت افزونه‌ها یا قالب‌ها مهم است. مستندات پلتفرم خود را بررسی کنید و از راهنمای خاص فناوری در Lighthouse استفاده کنید.

۲. انتخاب هاست مناسب

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

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

  • حافظه کافی برای برنامه شما تخصیص داده شده باشد.

  • هاست از نسخه‌های به‌روز فناوری‌های سرور (مانند HTTP/3، TLS 1.3) پشتیبانی کند.
  • امکان دسترسی به تنظیمات سرور برای سفارشی‌سازی فراهم باشد.

منبع: برای مقایسه عملکرد هاست‌ها، از ismyhostfastyet.com استفاده کنید.

۳. استفاده از شبکه تحویل محتوا (CDN)

CDNها با استفاده از سرورهای لبه (Edge Servers) که به کاربران نزدیک‌تر هستند، TTFB را کاهش می‌دهند. مزایا:

  • رفع مشکل فاصله جغرافیایی: محتوای کش‌شده را از سرورهای نزدیک به کاربر ارائه می‌دهد.
  • DNS سریع: زمان جستجوی DNS را کاهش می‌دهد.
  • پروتکل‌های مدرن: مانند HTTP/3 (بر پایه UDP) و TLS 1.3 برای کاهش تأخیر.
  • Edge Workers: امکان مدیریت درخواست‌ها در سرورهای لبه.
  • فشرده‌سازی بهینه: کاهش حجم پاسخ‌ها.

اقدام: اگر سایت شما از CDN استفاده نمی‌کند، اولویت‌بندی کنید.

۴. استفاده از کش

کش کردن محتوا در سرورهای لبه CDN یا سرور اصلی، TTFB را کاهش می‌دهد:

  • کش برای محتوای استاتیک: با تنظیم هدرهای Cache-Control، محتوای استاتیک را کش کنید.
  • کش کوتاه‌مدت: حتی برای سایت‌هایی با به‌روزرسانی مداوم، کش چندثانیه‌ای می‌تواند مؤثر باشد.
  • هشدار: کش ممکن است TTFB واقعی را مخفی کند. با پارامتر URL کش را دور بزنید تا عملکرد واقعی سرور را ببینید.

۵. کاهش ریدایرکت‌ها

ریدایرکت‌ها TTFB را افزایش می‌دهند:

  • ریدایرکت‌های هم‌منبع (Same-Origin): لینک‌های سایت خود را بررسی کنید تا از ریدایرکت‌های غیرضروری (مثل HTTP به HTTPS یا عدم وجود اسلش پایانی) جلوگیری شود.
  • ریدایرکت‌های غیرهم‌منبع (Cross-Origin): مانند لینک‌های کوتاه‌شده در شبکه‌های اجتماعی یا تبلیغات. URL نهایی را به تبلیغ‌کنندگان بدهید.
  • هدر HSTS: با استفاده از Strict-Transport-Security، HTTPS را اجباری کنید و در بازدیدهای بعدی ریدایرکت را حذف کنید. سایت خود را به HSTS Preload List اضافه کنید.

۶. استریم کردن نشانه‌گذاری (Markup)

ارسال نشانه‌گذاری به‌صورت تکه‌تکه (Streaming) به مرورگر کمک می‌کند تا پردازش را سریع‌تر شروع کند:

  • رندر سمت سرور (SSR): فریم‌ورک‌هایی مثل React از روش‌های استریم مانند React server methods پشتیبانی می‌کنند.
  • رندر استاتیک: برای صفحاتی که نیازی به محتوای پویا ندارند، HTML را در زمان ساخت تولید کنید.
  • نکته: همه runtimeها (مثل Deno و Node.js) از استریم پشتیبانی می‌کنند، اما برخی پلتفرم‌ها ممکن است نیاز به ارتقا داشته باشند.

۷. استفاده از Service Worker

Service Worker API می‌تواند TTFB را بهبود دهد:

  • استراتژی Stale-While-Revalidate: منابع کش‌شده را فوراً ارائه می‌دهد و در پس‌زمینه به‌روزرسانی می‌کند. برای منابع غیرحیاتی یا صفحاتی که تغییر کمی دارند مناسب است.
  • مدل App Shell: برای SPAها، پوسته صفحه را از کش ارائه می‌دهد و محتوای پویا بعداً بارگذاری می‌شود.

۸. استفاده از 103 Early Hints

هدر 103 Early Hints به مرورگر اجازه می‌دهد منابع حیاتی (مثل CSS) را زودتر دانلود کند، در حالی که سرور مشغول آماده‌سازی پاسخ است. این برای سایت‌های با پردازش سنگین سمت سرور مفید است.

هشدار: Early Hints ممکن است TTFB واقعی را مخفی کند. از Server-Timing یا PerformanceNavigationTiming برای اندازه‌گیری زمان واقعی سرور استفاده کنید.

نتیجه‌گیری

بهینه‌سازی TTFB به دلیل تنوع در فناوری‌های سمت سرور پیچیده است، اما با تمرکز بر هاستینگ مناسب، استفاده از CDN، کش، کاهش ریدایرکت‌ها، استریم نشانه‌گذاری، Service Worker و Early Hints، می‌توانید عملکرد سایت خود را بهبود دهید. ابتدا TTFB را در جهان واقعی اندازه‌گیری کنید، با ابزارهای آزمایشگاهی مشکلات را شناسایی کنید و بهینه‌سازی‌ها را اعمال کنید. نظارت مداوم بر داده‌های واقعی به شما کمک می‌کند تا تجربه کاربری سریع‌تری ارائه دهید.