زمان تا اولین بایت را بهینه کنید

با نحوه بهینه سازی متریک Time to First Byte آشنا شوید.

Jeremy Wagner

Barry Pollard

زمان تا اولین بایت (TTFB) یک معیار عملکرد اساسی وب است که قبل از هر معیار تجربه کاربری معنی‌داری مانند First Contentful Paint (FCP) و Largest Contentful Paint (LCP) است. این بدان معنی است که مقادیر بالای TTFB زمان را به معیارهایی که به دنبال آن هستند اضافه می کند.

توصیه می شود که سرور شما به درخواست های ناوبری به اندازه کافی سریع پاسخ دهد تا صدک 75 کاربران یک FCP را در آستانه "خوب" تجربه کنند. به عنوان یک راهنمای تقریبی، اکثر سایت ها باید تلاش کنند تا TTFB 0.8 ثانیه یا کمتر داشته باشند.

نقطه کلیدی:

TTFB یک معیار Core Web Vitals نیست، بنابراین کاملاً ضروری نیست که سایت‌ها آستانه "خوب" TTFB را داشته باشند، مشروط بر اینکه مانع از توانایی آنها برای کسب امتیاز خوب در معیارهای مهم نشود.

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

برعکس، یک سایت رندر شده توسط سرور که نیازی به کار در سمت مشتری ندارد، می تواند TTFB بالاتری داشته باشد، اما مقادیر FCP و LCP بهتری نسبت به یک تجربه کاملاً ارائه شده توسط مشتری دارد. به همین دلیل است که آستانه های TTFB یک "راهنمای تقریبی" هستند و باید با نحوه ارائه محتوای اصلی سایت شما سنجیده شوند.

نحوه اندازه گیری TTFB

قبل از اینکه بتوانید TTFB را بهینه کنید، باید مشاهده کنید که چگونه بر کاربران وب سایت شما تأثیر می گذارد. شما باید به داده های میدانی به عنوان منبع اصلی مشاهده TTFB تکیه کنید زیرا تحت تأثیر تغییر مسیرها قرار می گیرد، در حالی که ابزارهای مبتنی بر آزمایشگاه اغلب با استفاده از URL نهایی اندازه گیری می شوند بنابراین این تاخیر اضافی را از دست می دهند.

PageSpeed ​​Insights یک راه ساده برای دریافت اطلاعات میدانی و آزمایشگاهی برای وب‌سایت‌های عمومی است که در گزارش تجربه کاربر Chrome موجود است.

TTFB برای کاربران واقعی در بخش کشف آنچه کاربران واقعی شما تجربه می‌کنند نشان داده شده است:

زیر مجموعه ای از TTFB در ممیزی زمان پاسخ سرور نشان داده می شود:

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

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

درک TTFB بالا با Server-Timing

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

توجه: اگر اندازه‌گیری تأخیر باطن با Server-Timing امکان‌پذیر نیست، یک جایگزین مناسب ممکن است تکیه بر نظارت بر عملکرد برنامه (APM) برای شناسایی و تشخیص مشکلات عملکرد باطن باشد.

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 - $dbReadStarTime) / 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 مشاهده می‌شود:

سرصفحه‌های پاسخ Server-Timing در برگه شبکه Chrome DevTools تجسم شده‌اند. در اینجا، Server-Timing برای اندازه‌گیری اینکه آیا یک درخواست برای یک منبع به حافظه پنهان CDN رسیده است یا خیر، و اینکه چقدر طول می‌کشد تا درخواست به سرور لبه CDN و سپس مبدا برسد، استفاده می‌شود.

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

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

چالش برانگیزترین جنبه بهینه سازی TTFB این است که، در حالی که پشته ظاهری وب همیشه HTML، CSS و جاوا اسکریپت خواهد بود، پشته های پشتیبان می توانند به طور قابل توجهی متفاوت باشند. پشته های پشتیبان و محصولات دیتابیس متعددی وجود دارد که هر کدام تکنیک های بهینه سازی خاص خود را دارند. بنابراین، این راهنما به جای تمرکز صرفاً بر روی راهنمایی های خاص پشته، بر روی آنچه برای اکثر معماری ها اعمال می شود، تمرکز خواهد کرد.

راهنمایی ویژه پلتفرم

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

میزبانی، میزبانی، میزبانی

حتی قبل از اینکه سایر رویکردهای بهینه سازی را در نظر بگیرید، میزبانی باید اولین چیزی باشد که در نظر می گیرید. راهنمايي خاصي وجود ندارد كه بتوان در اينجا ارائه كرد، اما يك قانون كلي اين است كه اطمينان حاصل شود كه هاست وب سايت شما قادر به اداره ترافيكي است كه شما به آن ارسال مي كنيد.

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

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

هنگام انتخاب یک ارائه دهنده هاست، موارد زیر را باید رعایت کنید:

• نمونه برنامه شما چقدر حافظه اختصاص داده است؟ اگر برنامه شما حافظه کافی نداشته باشد، تراشه می کند و برای ارائه هرچه سریعتر صفحات با مشکل مواجه می شود.
• آیا ارائه دهنده هاست شما پشته پشتیبان شما را به روز نگه می دارد؟ با انتشار نسخه‌های جدید زبان‌های پشتیبان برنامه، پیاده‌سازی HTTP و نرم‌افزار پایگاه داده، عملکرد آن نرم‌افزار در طول زمان بهبود می‌یابد. شراکت با یک ارائه دهنده میزبانی که این نوع تعمیر و نگهداری حیاتی را در اولویت قرار می دهد، بسیار مهم است.
• اگر الزامات برنامه بسیار خاصی دارید و می‌خواهید به فایل‌های پیکربندی سرور در پایین‌ترین سطح دسترسی داشته باشید، بپرسید که آیا منطقی است که Backend نمونه برنامه خود را سفارشی کنید.

توجه: اگر مطمئن نیستید که عملکرد TTFB کاربر واقعی ارائه دهنده میزبانی شما در برابر رقبا چگونه است، ismyhostfastyet.com مکان خوبی برای دریافت این اطلاعات است.

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

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

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

CDN ها مشکل نزدیکی کاربر به سرور اصلی شما را با استفاده از یک شبکه توزیع شده از سرورها حل می کنند که منابع را روی سرورهایی که از نظر فیزیکی به کاربران شما نزدیک تر هستند، ذخیره می کند. این سرورها سرورهای لبه نامیده می شوند.

ارائه دهندگان CDN همچنین ممکن است مزایایی فراتر از سرورهای لبه ارائه دهند:

• ارائه‌دهندگان CDN معمولاً زمان‌های وضوح DNS بسیار سریعی را ارائه می‌کنند.
• یک CDN احتمالاً محتوای شما را از سرورهای لبه با استفاده از پروتکل‌های مدرن مانند HTTP/2 یا HTTP/3 ارائه می‌کند.
• HTTP/3 به طور خاص مشکل مسدود کردن سر خط موجود در TCP (که HTTP/2 به آن متکی است) را با استفاده از پروتکل UDP حل می کند.
• یک CDN احتمالاً نسخه‌های مدرن TLS را نیز ارائه می‌کند که تأخیر مربوط به زمان مذاکره TLS را کاهش می‌دهد. TLS 1.3 به طور خاص طراحی شده است تا مذاکرات TLS را تا حد امکان کوتاه نگه دارد.
• برخی از ارائه‌دهندگان CDN ویژگی‌ای را ارائه می‌کنند که اغلب به نام "edge worker" نامیده می‌شود، که از API مشابه API Service Worker برای رهگیری درخواست‌ها، مدیریت برنامه‌نویسی پاسخ‌ها در حافظه پنهان لبه یا بازنویسی پاسخ‌ها استفاده می‌کند.
• ارائه دهندگان CDN در بهینه سازی برای فشرده سازی بسیار خوب هستند. فشرده سازی به تنهایی کار دشواری است و ممکن است در موارد خاص با نشانه گذاری پویا ایجاد شده به زمان پاسخ آهسته تر منجر شود، که باید در همان لحظه فشرده شود.
• ارائه دهندگان CDN همچنین به طور خودکار پاسخ های فشرده شده را برای منابع استاتیک ذخیره می کنند که منجر به بهترین ترکیب نسبت فشرده سازی و زمان پاسخ می شود.

در حالی که اتخاذ یک CDN مستلزم تلاش های متفاوتی از بی اهمیت تا قابل توجه است، اگر وب سایت شما از قبل از آن استفاده نمی کند، باید اولویت بالایی برای بهینه سازی TTFB خود داشته باشید.

در صورت امکان از محتوای کش استفاده می شود

CDN ها اجازه می دهند محتوا در سرورهای لبه ای که از نظر فیزیکی نزدیک تر به بازدیدکنندگان قرار دارند، ذخیره شود، مشروط بر اینکه محتوا با هدرهای HTTP Cache-Control مناسب پیکربندی شده باشد. در حالی که این برای محتوای شخصی سازی شده مناسب نیست، نیاز به یک سفر کامل به مبدا می تواند مقدار زیادی از ارزش CDN را نفی کند.

برای سایت‌هایی که مکرراً محتوای خود را به‌روزرسانی می‌کنند، حتی یک زمان کش کوتاه می‌تواند منجر به افزایش عملکرد قابل‌توجه برای سایت‌های پرمشغله شود، زیرا تنها اولین بازدیدکننده در این مدت زمان تأخیر کامل را به سرور اصلی تجربه می‌کند، در حالی که همه بازدیدکنندگان دیگر می‌توانند از منبع ذخیره‌شده مجددا استفاده کنند. از سرور لبه برخی از CDN‌ها امکان باطل کردن حافظه پنهان را در نسخه‌های سایت فراهم می‌کنند که بهترین‌ها را در هر دو جهان امکان‌پذیر می‌سازد - زمان‌های کش طولانی، اما به‌روزرسانی‌های فوری در صورت نیاز.

حتی در جایی که کش به درستی پیکربندی شده است، می توان از طریق استفاده از پارامترهای رشته کوئری منحصر به فرد برای اندازه گیری تحلیلی، این موضوع را نادیده گرفت. اینها ممکن است علیرغم یکسان بودن محتوای متفاوتی با CDN به نظر برسند، بنابراین از نسخه کش استفاده نخواهد شد.

همچنین ممکن است محتوای قدیمی‌تر یا کمتر بازدید شده در حافظه پنهان ذخیره نشود، که می‌تواند منجر به مقادیر بالاتر TTFB در برخی از صفحات نسبت به سایرین شود. افزایش زمان کش می تواند تأثیر این امر را کاهش دهد، اما توجه داشته باشید که با افزایش زمان کش، امکان بیشتری برای ارائه محتوای بالقوه قدیمی وجود دارد.

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

از تغییر مسیرهای چند صفحه ای خودداری کنید

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

دو نوع تغییر مسیر وجود دارد:

• ریدایرکت های با همان مبدا ، جایی که تغییر مسیر به طور کامل در وب سایت شما انجام می شود.
• تغییر مسیرهای متقاطع ، که در آن تغییر مسیر ابتدا در مبدأ دیگری رخ می دهد - مثلاً از یک سرویس کوتاه کردن URL رسانه های اجتماعی - قبل از رسیدن به وب سایت شما.

شما می خواهید روی حذف تغییر مسیرهای یکسان تمرکز کنید، زیرا این چیزی است که شما مستقیماً روی آن کنترل خواهید داشت. این شامل بررسی پیوندهای موجود در وب سایت شما می شود تا ببینید آیا هر یک از آنها منجر به کد پاسخ 302 یا 301 می شود. اغلب این می تواند نتیجه عدم گنجاندن طرح https:// باشد (بنابراین مرورگرها به طور پیش فرض روی http:// هستند که سپس هدایت می شوند) یا به این دلیل که اسلش های انتهایی به طور مناسب در URL گنجانده نشده یا حذف شده اند.

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

منبع مهم دیگر زمان تغییر مسیر می تواند از تغییر مسیرهای HTTP به HTTPS باشد. یکی از راه‌هایی که می‌توانید از این موضوع دور شوید، استفاده از هدر Strict-Transport-Security (HSTS) است که HTTPS را در اولین بازدید از یک مبدا اعمال می‌کند و سپس به مرورگر می‌گوید که فوراً از طریق طرح HTTPS در آینده به مبدا دسترسی پیدا کند. بازدید می کند.

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

احتیاط: هنگام اجرای HSTS بسیار مراقب باشید، زیرا تنظیم یک خط مشی خیلی تهاجمی بدون آزمایش کافی می تواند وب سایت شما را خراب کند .

نشان‌گذاری جریان به مرورگر

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

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

به عنوان مثال، React - و سایر فریم ورک‌هایی که می‌توانند نشانه‌گذاری بر اساس تقاضا را در سرور ارائه دهند - از یک رویکرد همزمان برای رندر سمت سرور استفاده کرده‌اند. با این حال، نسخه‌های جدیدتر React روش‌های سرور را برای نشانه‌گذاری استریم در حین رندرینگ پیاده‌سازی کرده‌اند. این بدان معناست که لازم نیست منتظر بمانید تا یک متد API سرور React قبل از ارسال کل پاسخ را ارائه کند.

توجه: زمان اجرا هر زبانی نمی تواند از رندر سمت سرور استفاده کند. زمان‌های اجرا جاوا اسکریپت مانند Deno و Node.js از این قابلیت پشتیبانی می‌کنند، اما پلتفرم‌های دیگر ممکن است از آن پشتیبانی نکنند. بررسی کنید که آیا این مورد برای شما صادق است یا خیر، و ببینید چه کاری می توانید برای ارتقا یا تغییر زمان اجرا برای عملکرد بهتر رندر سمت سرور انجام دهید.

راه دیگر برای اطمینان از پخش سریع نشانه‌گذاری به مرورگر، تکیه بر رندر استاتیک است که فایل‌های HTML را در طول زمان ساخت تولید می‌کند. با در دسترس بودن فایل کامل، سرورهای وب می توانند بلافاصله فایل را ارسال کنند و ماهیت ذاتی HTTP منجر به نشانه گذاری جریان می شود. در حالی که این رویکرد برای هر صفحه در هر وب سایت مناسب نیست - مانند صفحاتی که به پاسخ پویا به عنوان بخشی از تجربه کاربر نیاز دارند - می تواند برای آن دسته از صفحاتی که نیازی به نشانه گذاری برای شخصی سازی یک کاربر خاص ندارند، مفید باشد.

از یک کارگر خدماتی استفاده کنید

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

• برای دارایی ها از یک استراتژی کهنه در حالی استفاده کنید. اگر یک دارایی در حافظه نهان سرویس کارگر باشد - خواه یک سند باشد یا منبعی که سند به آن نیاز دارد - استراتژی stale-while-revalidate ابتدا به آن منبع از حافظه پنهان سرویس می دهد، سپس آن دارایی را در پس زمینه دانلود می کند و آن را از سرور ارائه می کند. حافظه پنهان برای تعاملات آینده
  • اگر منابع اسنادی دارید که اغلب تغییر نمی‌کنند، استفاده از یک استراتژی کهنه و اعتبار مجدد می‌تواند TTFB صفحه را تقریباً فوری کند. با این حال، اگر وب سایت شما نشانه گذاری ایجاد شده به صورت پویا ارسال کند، این کار چندان خوب نیست - مانند نشانه گذاری که بر اساس احراز هویت کاربر تغییر می کند. در چنین مواردی، همیشه می خواهید ابتدا وارد شبکه شوید، بنابراین سند تا حد امکان تازه باشد.
  • اگر سند شما منابع غیر مهمی را بارگیری می‌کند که با فرکانس خاصی تغییر می‌کنند، اما واکشی منبع قدیمی تأثیر زیادی بر تجربه کاربر نمی‌گذارد - مانند تصاویر انتخابی یا منابع دیگر که حیاتی نیستند - TTFB برای آن منابع می‌تواند تا حد زیادی کاهش یابد. با استفاده از یک استراتژی کهنه در حالی که اعتبار مجدد.
• در صورت امکان از معماری کارگر سرویس استریم استفاده کنید. این معماری سرویس‌کار از رویکردی استفاده می‌کند که در آن بخش‌هایی از یک منبع سند در حافظه پنهان سرویس‌کار ذخیره می‌شود و در طول درخواست ناوبری با بخش‌های محتوا ترکیب می‌شود. نتیجه استفاده از این الگوی کارگر این است که پیمایش شما بسیار سریع خواهد بود، در حالی که بارهای HTML کوچکتر از شبکه دانلود می شوند. در حالی که این الگوی کارگر سرویس برای هر وب سایتی کار نمی کند، زمان TTFB برای منابع سند می تواند برای سایت هایی که می توانند از آن استفاده کنند عملاً فوری باشد.
• از مدل پوسته برنامه برای برنامه های کاربردی ارائه شده توسط مشتری استفاده کنید. این مدل برای SPAها مناسب است، جایی که "پوسته" صفحه را می توان فوراً از کش سرویس دهنده تحویل داد، و محتوای پویا صفحه در چرخه عمر صفحه پر شده و ارائه می شود.

از 103 Early Hints برای منابع رندر بحرانی استفاده کنید

مهم نیست که برنامه کاربردی شما چقدر خوب بهینه شده است، سرور برای آماده کردن پاسخ باید مقدار قابل توجهی از کار انجام دهد، از جمله کارهای گران قیمت (در عین حال ضروری) پایگاه داده که رسیدن پاسخ ناوبری را به همان سرعتی که انجام می دهد به تاخیر می اندازد. میتوانست. تأثیر بالقوه این امر این است که برخی از منابع رندر حیاتی بعدی ممکن است به تأخیر بیفتند، مانند CSS یا - در برخی موارد - جاوا اسکریپت که نشانه گذاری را بر روی مشتری ارائه می کند.

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

توجه: اگر وب‌سایت شما برای آماده‌سازی نشانه‌گذاری (مثلاً سایت‌های استاتیک) پردازش‌های زیادی در پشتیبان انجام نمی‌دهد، احتمالاً 103 Early Hints چندان کمکی نخواهد کرد. این معمولاً برای سایت‌هایی که پیش از ارسال نشانه‌گذاری به کاربر زمان پشتیبان قابل‌توجهی دارند، بهترین کار را دارد.

نتیجه

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

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

تصویر قهرمان توسط تیلور ویک ، منبع آن از Unsplash.