با نحوه بهینه‌سازی برای سنجه «زمان تا اولین بایت» آشنا شوید.
تاریخ انتشار: ۱۹ ژانویه ۲۰۲۳، آخرین به‌روزرسانی: ۲۸ نوامبر ۲۰۲۵
زمان تا اولین بایت (TTFB) یک سنجه عملکرد وب بنیادی است که قبل‌از هر سنجه تجربه کاربری معنادار دیگری مانند اولین نقاشی دارای محتوا (FCP) و بزرگ‌ترین نقاشی دارای محتوا (LCP) قرار می‌گیرد. این یعنی مقادیر بالای TTFB به سنجه‌هایی که پس‌از آن می‌آیند زمان اضافه می‌کند.
توصیه می‌شود سرورتان به‌اندازه کافی سریع به درخواست‌های پیمایش پاسخ دهد تا صدک ۷۵ کاربران FCP را در آستانه «خوب» تجربه کنند. به‌عنوان یک راهنمای کلی، اکثر سایت‌ها باید تلاش کنند تا «زمان رسیدن اولین بایت» ۰٫۸ ثانیه یا کمتر داشته باشند.
نحوه اندازه‌گیری TTFB
قبل‌از اینکه بتوانید TTFB را بهینه‌سازی کنید، باید مشاهده کنید که چگونه بر کاربران وب‌سایت شما تأثیر می‌گذارد. باید به داده‌های میدانی به‌عنوان منبع اصلی مشاهده TTFB تکیه کنید زیرا تحت‌تأثیر تغییرمسیرها قرار می‌گیرد، درحالی‌که ابزارهای آزمایشگاهی اغلب بااستفاده از نشانی وب نهایی اندازه‌گیری می‌شوند و بنابراین این تأخیر اضافی را ازدست می‌دهند.
اطلاعات آماری PageSpeed یکی از راه‌های دریافت اطلاعات میدانی و آزمایشگاهی برای وب‌سایت‌های عمومی است که در گزارش تجربه کاربری Chrome دردسترس است.
TTFB برای کاربران واقعی در بخش بالایی ببینید کاربران واقعی شما چه چیزی را تجربه می‌کنند نشان داده می‌شود:
برای داده‌های آزمایشگاهی، مشکلات TTFB در اطلاعات آماری تأخیر در درخواست سند نشان داده می‌شود:
برای آشنایی با روش‌های بیشتر اندازه‌گیری TTFB در محیط واقعی و آزمایشگاه، به صفحه سنجه TTFB مراجعه کنید.
درک تفاوت‌های بین TTFB میدانی و آزمایشگاهی
TTFB آزمایشگاهی و میدانی ممکن است به‌دلایل مختلفی متفاوت باشند و وقتی متفاوت هستند، مهم است که دلیل آن را درک کنید تا بتوانید به‌طور مؤثر از داده‌های آزمایشگاهی برای بهبود تجربه‌های کاربری خود استفاده کنید.
وقتی TTFB آزمایشگاهی بسیار بزرگ‌تر از TTFB میدانی باشد، این نشان می‌دهد که محیط آزمایشگاهی محدودتر از تجربه‌های معمول کاربر است. این لزوماً مشکل نیست، زیرا نتایج و توصیه‌های آزمایشگاهی همچنان معتبر هستند، اما ممکن است تأثیر و بهبود را اغراق‌آمیز نشان دهد.
وقتی TTFB میدانی بسیار بزرگ‌تر از TTFB آزمایشگاهی باشد، این نشان‌دهنده مشکلاتی است که در اجرای آزمایشگاهی آشکار نیستند، مانند استفاده از حافظه پنهان سمت سرور، تغییر مسیرها، یا تفاوت‌های شبکه. دراین‌صورت، نتایج و توصیه‌های آزمایشگاهی ممکن است کمتر مفید باشند، زیرا یکی از مشکلات اصلی را ازدست می‌دهند.
برای اینکه ببینید آیا ذخیره مؤقت سمت سرور بر TTFB آزمایشگاهی تأثیر می‌گذارد یا نه، صفحه‌های کمتر رایج را آزمایش کنید یا از پارامترهای نشانی وب مختلف برای دریافت محتوای ذخیره‌نشده استفاده کنید تا ببینید آیا TTFB بیشتر با TTFB میدانی مطابقت دارد یا نه. همچنین اگر بتوانید با پارامتر نشانی وب خاصی حافظه پنهان سمت سرور را دور بزنید، می‌تواند مفید باشد. بخش محتوای ذخیره‌شده در حافظه نهان را ببینید.
برای تغییرمسیرها و تفاوت‌های شبکه، تجزیه‌وتحلیل نحوه ورود ترافیک به سایت ما و منبع آن می‌تواند برای تشخیص اینکه آیا این موارد مشکلات احتمالی هستند یا نه مفید باشد.
اشکال‌زدایی کردن TTFB بالا در فیلد با Server-Timing
از Server-Timingسرایند پاسخ می‌توان در پسای برنامه برای اندازه‌گیری فرایندهای متمایز پسا که می‌توانند در تأخیر بالا نقش داشته باشند استفاده کرد. ساختار مقدار سرصفحه انعطاف‌پذیر است و حداقل یک دسته را که شما تعریف می‌کنید می‌پذیرد. مقادیر اختیاری شامل مقدار مدت (ازطریق dur)، و همچنین شرح اختیاری قابل‌خواندن برای انسان (ازطریق desc) است.
از Serving-Timing می‌توان برای اندازه‌گیری بسیاری از فرایندهای پس‌زمینه برنامه استفاده کرد، اما برخی‌از آن‌ها ممکن است نیاز به توجه ویژه داشته باشند:
- پُرسمان‌های پایگاه داده
- زمان پرداز زدن سمت سرور، درصورت وجود
- جستجوهای دیسک
- موفقیت یا عدم موفقیت حافظه پنهان سرور لبه (درصورت استفاده از CDN)
همه بخش‌های ورودی Server-Timing با دونقطه از هم جدا می‌شوند و ورودی‌های متعدد را می‌توان با کاما از هم جدا کرد:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
سرصفحه را می‌توان بااستفاده از زبان انتخابی پسای برنامه تنظیم کرد. برای مثال، در PHP می‌توانید سرصفحه را به‌صورت زیر تنظیم کنید:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
وقتی این سرصفحه تنظیم شود، اطلاعاتی را نشان می‌دهد که می‌توانید هم در آزمایشگاه و هم در محیط واقعی استفاده کنید.
در این فیلد، هر صفحه‌ای که سرایند پاسخ Server-Timing برای آن تنظیم شده باشد، ویژگی serverTiming را در Navigation Timing API پر می‌کند:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
در آزمایشگاه، داده‌های سرصفحه پاسخ Server-Timing در پانل زمان‌بندی‌ها در برگه شبکه در Chrome DevTools تجسم می‌شود:
در اینجا، از Server-Timing برای اندازه‌گیری اینکه آیا درخواست منبع به حافظه نهان CDN رسیده است یا نه و اینکه چقدر طول می‌کشد تا درخواست به سرور لبه CDN و سپس به مبدأ برسد استفاده می‌شود.
زمان‌بندی‌های سرور همچنین در قطعه «شبکه» پانل عملکرد در Chrome DevTools نمایش داده می‌شوند:
وقتی با تجزیه‌وتحلیل داده‌های دردسترس تشخیص دادید که TTFB مشکل‌ساز دارید، می‌توانید برای رفع مشکل اقدام کنید.
روش‌های بهینه‌سازی TTFB
چالش‌برانگیزترین جنبه بهینه‌سازی TTFB این است که، درحالی‌که پشته پیش‌نمای وب همیشه HTML، CSS، و JavaScript است، پشته‌های پس‌نما می‌توانند به‌طور قابل‌توجهی متفاوت باشند. پشته‌های باطن و محصولات پایگاه داده متعددی وجود دارد که هرکدام تکنیک‌های بهینه‌سازی خاص خود را دارند. بنابراین، این راهنما بر آنچه برای اکثر معماری‌ها اعمال می‌شود تمرکز دارد، نه اینکه صرفاً بر راهنمایی‌های خاص پشته تمرکز کند.
راهنمایی مختص پلاتفرم
پلاتفرمی که برای وب‌سایتتان استفاده می‌کنید می‌تواند تأثیر زیادی بر TTFB داشته باشد. برای مثال، عملکرد WordPress تحت‌تأثیر تعداد و کیفیت افزایه‌ها یا زمینه‌های مورداستفاده قرار می‌گیرد. وقتی پلاتفرم سفارشی‌سازی می‌شود، پلاتفرم‌های دیگر نیز به‌طور مشابه تحت‌تأثیر قرار می‌گیرند. برای دریافت توصیه‌های خاص فروشنده که مکمل توصیه‌های عمومی‌تر عملکرد در این پست است، باید به اسناد پلاتفرم خود مراجعه کنید. اطلاعات آماری Lighthouse همچنین شامل برخی راهنمایی‌های محدود مختص پشته است.
میزبانی، میزبانی، میزبانی
پیش‌از اینکه حتی به رویکردهای دیگر بهینه‌سازی فکر کنید، میزبانی باید اولین چیزی باشد که درنظر می‌گیرید. در اینجا راهنمایی خاصی نمی‌توان ارائه داد، اما یک قانون کلی این است که مطمئن شوید میزبان وب‌سایت شما قادر به مدیریت ترافیکی است که به آن ارسال می‌کنید.
میزبانی مشترک معمولاً کندتر است. اگر وب‌سایت شخصی کوچکی را اجرا می‌کنید که بیشتر فایل‌های ایستا ارائه می‌دهد، احتمالاً این کار مشکلی ندارد. از برخی‌از تکنیک‌های بهینه‌سازی زیر استفاده کنید تا به شما کمک کند TTFB خود را تا حد امکان کاهش دهید.
بااین‌حال، اگر برنامه بزرگ‌تری را با کاربران زیادی اجرا می‌کنید که شامل شخصی‌سازی، پرسمان پایگاه داده، و سایر عملیات فشرده سمت سرور است، انتخاب میزبانی شما برای کاهش TTFB در این زمینه حیاتی می‌شود.
هنگام انتخاب ارائه‌دهنده خدمات میزبانی وب، این موارد را باید درنظر بگیرید:
- چه مقدار حافظه به نمونه برنامه شما اختصاص داده شده است؟ اگر برنامه شما حافظه کافی نداشته باشد، دچار مشکل می‌شود و نمی‌تواند صفحه‌ها را با بیشترین سرعت ممکن ارائه دهد.
- آیا ارائه‌دهنده خدمات میزبانی وب شما پشته باطن شما را به‌روز نگه می‌دارد؟ با انتشار نسخه‌های جدید زبان‌های پس‌زمینه برنامه، پیاده‌سازی‌های HTTP، و نرم‌افزار پایگاه داده، عملکرد آن نرم‌افزار به‌مرور زمان بهبود می‌یابد. مهم است که با ارائه‌دهنده خدمات میزبانی وبی شریک شوید که این نوع نگهداری حیاتی را در اولویت قرار می‌دهد.
- اگر الزامات برنامه بسیار خاصی دارید و می‌خواهید به پایین‌ترین سطح فایل‌های پیکربندی سرور دسترسی داشته باشید، بپرسید که آیا سفارشی‌سازی زیرینه نمونه برنامه خودتان منطقی است یا نه.
ارائه‌دهندگان خدمات میزبانی وب زیادی وجود دارند که این موارد را برای شما انجام می‌دهند، اما اگر حتی در ارائه‌دهندگان خدمات میزبانی وب اختصاصی نیز مقادیر TTFB طولانی مشاهده می‌کنید، ممکن است نشانه‌ای از این باشد که باید قابلیت‌های ارائه‌دهنده خدمات میزبانی وب فعلی خود را مجدداً ارزیابی کنید تا بتوانید بهترین تجربه کاربری ممکن را ارائه دهید.
استفاده از «شبکه توزیع محتوا» (CDN)
موضوع استفاده از CDN موضوعی بسیار قدیمی است، اما دلیل خوبی دارد: ممکن است باطن برنامه بسیار بهینه‌سازی‌شده‌ای داشته باشید، اما کاربرانی که دور از سرور مبدأ شما قرار دارند ممکن است همچنان TTFB بالایی را در میدان تجربه کنند.
شبکه‌های توزیع محتوا مشکل نزدیکی کاربر به سرور مبدأ شما را بااستفاده از شبکه توزیع‌شده‌ای از سرورها حل می‌کنند که منابع را در سرورهایی که ازنظر فیزیکی به کاربران شما نزدیک‌تر هستند ذخیره می‌کنند. این سرورها سرورهای لبه نامیده می‌شوند.
ارائه‌دهندگان CDN ممکن است مزایایی فراتر از سرورهای لبه نیز ارائه دهند:
- ارائه‌دهندگان CDN معمولاً زمان‌های وضوح ساناد بسیار سریعی ارائه می‌دهند.
- یک CDN احتمالاً محتوای شما را از سرورهای لبه بااستفاده از پروتکل‌های مدرن مانند HTTP/2 یا HTTP/3 ارائه می‌دهد.
- به‌ویژه HTTP/3 بااستفاده از پروتکل UDP مشکل مسدود کردن سرخط را که در TCP (که HTTP/2 به آن متکی است) وجود دارد حل می‌کند.
- یک CDN احتمالاً نسخه‌های مدرن TLS را ارائه می‌دهد که تأخیر مربوط به زمان مذاکره TLS را کاهش می‌دهد. به‌ویژه TLS 1.3 به‌گونه‌ای طراحی شده است که مذاکره TLS را تا حد امکان کوتاه نگه دارد.
- برخی‌از ارائه‌دهندگان CDN ویژگی‌ای ارائه می‌دهند که اغلب «edge worker» نامیده می‌شود و از میانای برنامه‌سازی کاربردی مشابه میانای برنامه‌سازی کاربردی Service Worker برای رهگیری درخواست‌ها، مدیریت برنامه‌نویسی‌شده پاسخ‌ها در حافظه‌های پنهان edge، یا بازنویسی کامل پاسخ‌ها استفاده می‌کند.
- ارائه‌دهندگان CDN در بهینه‌سازی برای فشرده‌سازی بسیار خوب عمل می‌کنند. فشرده‌سازی به‌تنهایی دشوار است و ممکن است در برخی موارد با نشانه‌گذاری تولیدشده پویا که باید در لحظه فشرده شود، منجر به زمان پاسخ‌دهی کندتر شود.
- همچنین، ارائه‌دهندگان CDN به‌طور خودکار پاسخ‌های فشرده‌شده را برای منابع ایستا ذخیره می‌کنند که منجر به بهترین ترکیب نسبت فشرده‌سازی و زمان پاسخ می‌شود.
درحالی‌که اتخاذ CDN شامل تلاش‌های متفاوتی از جزئی تا قابل‌توجه است، اگر وب‌سایت شما قبلاً از آن استفاده نمی‌کند، باید اولویت بالایی برای بهینه‌سازی TTFB شما داشته باشد.
درصورت امکان، از محتوای ذخیره‌شده در حافظه نهان استفاده کنید
شبکه‌های توزیع محتوا اجازه می‌دهند محتوا در سرورهای لبه‌ای که ازنظر فیزیکی به بازدیدکنندگان نزدیک‌تر هستند ذخیره موقت شود، مشروط بر اینکه محتوا با Cache-Controlسرایندهای HTTP مناسب پیکربندی شده باشد. اگرچه این روش برای محتوای شخصی‌سازی‌شده مناسب نیست، اما الزام به بازگشت کامل به مبدأ می‌تواند بخش زیادی از ارزش CDN را ازبین ببرد.
برای سایت‌هایی که محتوایشان را به‌طور مکرر به‌روز می‌کنند، حتی زمان کوتاه ذخیره‌سازی در حافظه نهان می‌تواند منجر به بهبود قابل‌توجه عملکرد برای سایت‌های شلوغ شود، زیرا فقط اولین بازدیدکننده در آن زمان تأخیر کامل بازگشت به سرور مبدأ را تجربه می‌کند، درحالی‌که همه بازدیدکنندگان دیگر می‌توانند از منبع ذخیره‌شده در حافظه نهان از سرور لبه استفاده مجدد کنند. برخی‌از شبکه‌های توزیع محتوا امکان نامعتبر کردن حافظه پنهان را در نسخه‌های منتشرشده سایت فراهم می‌کنند که بهترین حالت ممکن را ایجاد می‌کند—زمان‌های طولانی حافظه پنهان، اما به‌روزرسانی‌های فوری درصورت نیاز.
حتی در مواردی که حافظه پنهان به‌درستی پیکربندی شده باشد، می‌توان بااستفاده از پارامترهای رشته پُرسمان یکتا برای سنجش تجزیه‌وتحلیل، از این موضوع صرف‌نظر کرد. این‌ها ممکن است برای CDN محتوای متفاوتی به‌نظر برسند، هرچند که یکسان هستند، بنابراین از نسخه ذخیره‌شده در حافظه نهان استفاده نخواهد شد.
محتوای قدیمی‌تر یا محتوایی که کمتر بازدید شده است نیز ممکن است در حافظه نهان ذخیره نشود، که می‌تواند منجر به مقادیر TTFB بالاتر در برخی صفحه‌ها نسبت به صفحه‌های دیگر شود. افزایش زمان ذخیره‌سازی موقت می‌تواند تأثیر این موضوع را کاهش دهد، اما توجه داشته باشید که با افزایش زمان ذخیره‌سازی موقت، احتمال ارائه محتوای بالقوه قدیمی بیشتر می‌شود.
تأثیر محتوای ذخیره‌شده در حافظه نهان فقط بر کسانی که از CDN استفاده می‌کنند تأثیر نمی‌گذارد. وقتی محتوای ذخیره‌شده در حافظه نهان قابل‌استفاده مجدد نباشد، ممکن است زیرساخت سرور نیاز به تولید محتوا از جستجوهای پرهزینه پایگاه داده داشته باشد. داده‌هایی که بیشتر دردسترس قرار می‌گیرند یا صفحه‌هایی که ازقبل در حافظه نهان ذخیره شده‌اند اغلب عملکرد بهتری دارند.
از هدایت چند صفحه جلوگیری می‌کند
یکی از عوامل رایج در بالا بودن TTFB تغییر مسیرها است. تغییر مسیر زمانی اتفاق می‌افتد که درخواست پیمایش برای یک سند پاسخی دریافت می‌کند که به مرورگر اطلاع می‌دهد منبع در مکان دیگری وجود دارد. یک تغییرمسیر قطعاً می‌تواند تأخیر ناخواسته به درخواست پیمایش اضافه کند، اما اگر آن تغییرمسیر به منبع دیگری اشاره کند که منجر به تغییرمسیر دیگری شود، قطعاً می‌تواند بدتر شود—و به همین ترتیب. این امر به‌ویژه می‌تواند بر سایت‌هایی تأثیر بگذارد که حجم بالایی از بازدیدکنندگان را ازطریق تبلیغات یا خبرنامه‌ها دریافت می‌کنند، زیرا این سایت‌ها اغلب برای اهداف سنجش ازطریق سرویس‌های تجزیه‌وتحلیل تغییرمسیر می‌دهند. حذف تغییرمسیرهای تحت کنترل مستقیم شما می‌تواند به دستیابی به TTFB خوب کمک کند.
دو نوع تغییر مسیر وجود دارد:
- بازهدایت‌های هم‌مبدأ، که در آن بازهدایت به‌طور کامل در وب‌سایت شما اتفاق می‌افتد.
- بازهدایت‌های میان‌مبدئی، که در آن بازهدایت ابتدا در مبدأ دیگری رخ می‌دهد—مثلاً از سرویس کوتاه‌سازی نشانی وب رسانه‌های اجتماعی—قبل‌از اینکه به وب‌سایت شما برسد.
روی حذف کردن تغییرمسیرهای هم‌مبدأ تمرکز کنید، زیرا این چیزی است که کنترل مستقیم روی آن دارید. این کار شامل بررسی پیوندهای وب‌سایت شما می‌شود تا ببینید آیا هیچ‌کدام از آن‌ها منجر به کد پاسخ 302 یا 301 می‌شوند یا نه. اغلب این مشکل می‌تواند ناشی از عدم درج طرح https:// (بنابراین مرورگرها به‌طور پیش‌فرض به http:// می‌روند که سپس تغییرمسیر می‌دهد) یا به‌دلیل عدم درج یا حذف مناسب خط مورب پایانی در نشانی وب باشد.
بازهدایت‌های میان‌مبدئی پیچیده‌تر هستند زیرا اغلب خارج از کنترل شما هستند، اما سعی کنید درصورت امکان از بازهدایت‌های متعدد اجتناب کنید—برای مثال، بااستفاده از چندین کوتاه‌کننده پیوند هنگام هم‌رسانی پیوندها. مطمئن شوید نشانی وبی که به آگهی‌دهندگان یا خبرنامه‌ها ارائه می‌شود نشانی وب نهایی صحیح باشد تا تغییر مسیر دیگری به تغییر مسیرهای استفاده‌شده توسط آن سرویس‌ها اضافه نشود.
منبع مهم دیگر زمان تغییرمسیر می‌تواند از تغییرمسیرهای HTTP به HTTPS باشد. یکی از راه‌هایی که می‌توانید این مشکل را حل کنید استفاده از سرصفحه Strict-Transport-Security (HSTS) است که در اولین بازدید از مبدأ، HTTPS را اعمال می‌کند و سپس به مرورگر می‌گوید که در بازدیدهای بعدی فوراً ازطریق طرح HTTPS به مبدأ دسترسی پیدا کند.
وقتی خط‌مشی HSTS خوبی داشته باشید، می‌توانید در اولین بازدید از مبدأ با افزودن سایتتان به فهرست پیش‌بارگذاری HSTS، سرعت را افزایش دهید.
جاری‌سازی نشان‌گذاری به مرورگر
مرورگرها برای پردازش کارآمد نشانه‌گذاری هنگام جاری‌سازی بهینه‌سازی شده‌اند، به این معنی که نشانه‌گذاری به‌صورت تکه‌تکه هنگام دریافت از سرور مدیریت می‌شود. این امر در مواردی که با حجم زیادی از داده‌های نشانه‌گذاری سروکار داریم بسیار حیاتی است، زیرا به این معنی است که مرورگر می‌تواند بخش‌های نشانه‌گذاری را به‌صورت تدریجی تجزیه کند، به‌جای اینکه منتظر بماند تا کل پاسخ دریافت شود و سپس تجزیه را آغاز کند.
اگرچه مرورگرها در مدیریت نشانه‌گذاری جاری‌سازی عالی هستند، اما بسیار مهم است که هر کاری می‌توانید انجام دهید تا آن جاری‌سازی ادامه یابد تا آن بیت‌های اولیه نشانه‌گذاری در اسرع وقت در راه باشند. اگر باطن باعث تأخیر شود، این یک مشکل است. ازآنجایی‌که پشته‌های پس‌زمینه متعدد هستند، پوشش دادن تک‌تک پشته‌ها و مشکلاتی که ممکن است در هریک از آن‌ها ایجاد شود فراتر از محدوده این راهنما است.
برای مثال، React و چارچوب‌های دیگری که می‌توانند نشانه‌گذاری را درصورت درخواست در سرور ارائه کنند، از رویکرد همگام برای ارائه سمت سرور استفاده کرده‌اند. بااین‌حال، نسخه‌های جدیدتر React روش‌های سرور را برای نشانه‌گذاری جاری‌سازی درحین رندر شدن پیاده‌سازی کرده‌اند. این یعنی لازم نیست منتظر بمانید تا روش React server API کل پاسخ را قبل‌از ارسال شدن رندر کند.
راه دیگر برای اطمینان از اینکه نشان‌گذاری به‌سرعت به مرورگر جاری می‌شود، تکیه بر پرداز ثابت است که فایل‌های HTML را درطول زمان ساخت تولید می‌کند. با دردسترس بودن فوری فایل کامل، سرورهای وب می‌توانند بلافاصله ارسال فایل را شروع کنند و ماهیت ذاتی HTTP منجر به نشانه‌گذاری جاری‌سازی می‌شود. اگرچه این رویکرد برای همه صفحه‌ها در همه وب‌سایت‌ها مناسب نیست (مثلاً صفحه‌هایی که به‌عنوان بخشی از تجربه کاربر به پاسخ پویا نیاز دارند)، می‌تواند برای صفحه‌هایی که به نشان‌گذاری شخصی‌سازی‌شده برای کاربر خاصی نیاز ندارند مفید باشد.
استفاده از عامل خدماتی
Service Worker API می‌تواند تأثیر زیادی بر TTFB هم برای اسناد و هم برای منابعی که بار می‌کنند داشته باشد. دلیل این امر این است که یک کارگر سرویس به‌عنوان یک پروکسی بین مرورگر و سرور عمل می‌کند—اما اینکه آیا تأثیری بر TTFB وب‌سایت شما دارد یا نه، بستگی به نحوه راه‌اندازی کارگر سرویس شما دارد و اینکه آیا این راه‌اندازی با الزامات برنامه شما همسو است یا نه.
- از استراتژی stale-while-revalidate برای دارایی‌ها استفاده کنید. اگر دارایی در حافظه نهان عامل خدماتی باشد، چه سند باشد یا منبعی که سند به آن نیاز دارد، راهبرد stale-while-revalidate آن منبع را ابتدا از حافظه نهان ارائه می‌دهد، سپس آن دارایی را در پس‌زمینه بارگیری می‌کند و آن را از حافظه نهان برای تعاملات آینده ارائه می‌دهد.
- اگر منابع سندی دارید که اغلب تغییر نمی‌کنند، استفاده از استراتژی stale-while-revalidate می‌تواند TTFB صفحه را تقریباً فوری کند. اما اگر وب‌سایت شما نشان‌گذاری تولیدشده به‌صورت پویا ارسال کند (مثلاً نشان‌گذاری‌ای که براساس اصالت‌سنجی شدن یا نشدن کاربر تغییر می‌کند)، این روش چندان خوب کار نمی‌کند. در چنین مواردی، همیشه می‌خواهید ابتدا به شبکه دسترسی پیدا کنید تا سند تا حد امکان جدید باشد.
- اگر سند شما منابع غیربحرانی را بار می‌کند که با فرکانس خاصی تغییر می‌کنند، اما واکشی منبع قدیمی تأثیر زیادی بر تجربه کاربر نخواهد داشت (مانند تصاویر انتخابی یا منابع دیگری که بحرانی نیستند)، TTFB برای آن منابع می‌تواند بااستفاده از استراتژی stale-while-revalidate به‌طور قابل‌توجهی کاهش یابد.
- از مدل پوسته برنامه برای برنامه‌هایی که در سمت کارخواه پرداز می‌شوند استفاده کنید. این مدل برای برنامه‌های تک‌صفحه‌ای (SPA) که در آن‌ها «پوسته» صفحه می‌تواند فوراً از حافظه نهان عامل خدماتی ارائه شود و محتوای پویای صفحه بعداً در چرخه حیات صفحه پر و ارائه شود، بهترین گزینه است.
استفاده از 103 Early Hints برای منابع مهم برای پردازش
مهم نیست که باطن برنامه شما چقدر خوب بهینه‌سازی شده باشد، هنوز ممکن است مقدار قابل‌توجهی کار وجود داشته باشد که سرور باید برای آماده‌سازی پاسخ انجام دهد، ازجمله کار پایگاه داده پرهزینه (اما ضروری) که پاسخ پیمایش را از رسیدن به همان سرعتی که می‌تواند به تأخیر می‌اندازد. تأثیر احتمالی این امر این است که برخی‌از منابع بعدی که برای رندر کردن حیاتی هستند ممکن است به‌تأخیر بیفتند، مانند CSS یا (در برخی موارد) جاوا اسکریپت که نشانه‌گذاری را در سمت کارخواه رندر می‌کند.
103 Early Hintsسرصفحه یک کد پاسخ اولیه است که سرور می‌تواند به مرورگر ارسال کند، درحالی‌که زیرینه مشغول آماده‌سازی نشانه‌گذاری است. از این سرصفحه می‌توان برای اشاره به مرورگر استفاده کرد که منابع مهمی برای پردازش وجود دارد که صفحه باید بارگیری آن‌ها را درحین آماده‌سازی نشانه‌گذاری شروع کند. برای مرورگرهای پشتیبانی‌کننده، این تأثیر می‌تواند به‌صورت پرداز سریع‌تر سند (CSS) و بار شدن سریع‌تر صفحه باشد.
یکی‌از معایب «نکات اولیه ۱۰۳» این است که مانند ذخیره‌سازی موقت، می‌تواند TTFB «واقعی» سایت را پنهان کند. اگر زیرساخت سرور کند باشد (به‌دلیل کم‌توان بودن یا نیاز به بهینه‌سازی کد)، این موضوع هنگام استفاده از «نکات اولیه ۱۰۳» کمتر آشکار می‌شود زیرا TTFB سریع به‌نظر می‌رسد. سایت‌هایی که از «103 Early Hints» استفاده می‌کنند باید اندازه‌گیری زمان واقعی سرور را مدنظر قرار دهند (ازطریق Server-Timing یا finalResponseHeadersStart از PerformanceNavigationTiming API).
نتیجه‌گیری
ازآنجایی‌که ترکیب‌های بسیار زیادی از پشته‌های برنامه پس‌زمینه وجود دارد، هیچ مقاله واحدی وجود ندارد که بتواند همه کارهایی را که می‌توانید برای کاهش TTFB وب‌سایتتان انجام دهید دربرگیرد. بااین‌حال، این‌ها گزینه‌هایی هستند که می‌توانید برای امتحان کردن و سرعت بخشیدن به کارها در سمت سرور کاوش کنید.
همانند بهینه‌سازی هر سنجه، رویکرد تا حد زیادی مشابه است: TTFB خود را در میدان اندازه‌گیری کنید، از ابزارهای آزمایشگاهی برای بررسی دقیق علل استفاده کنید، و سپس بهینه‌سازی‌ها را درصورت امکان اعمال کنید. اگرچه ممکن است برخی‌از تکنیک‌ها برای وضعیت شما مناسب نباشند، اما احتمالاً برخی‌از آن‌ها مناسب هستند. مثل همیشه، باید داده‌های میدانی‌تان را به‌دقت زیرنظر داشته باشید و درصورت نیاز اصلاحات لازم را انجام دهید تا سریع‌ترین تجربه کاربری ممکن را تضمین کنید.