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

دریابید که چگونه سرور شما می تواند نکاتی را در مورد منابع فرعی مهم به مرورگر ارسال کند.

نکات اولیه چیست؟

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

تصویر نشان دهنده فاصله زمانی فکری سرور 200 میلی ثانیه بین بارگذاری صفحه و بارگذاری منابع دیگر.
بدون نکات اولیه: همه چیز روی سرور مسدود شده و نحوه پاسخگویی به منبع اصلی را تعیین می کند.

Early Hints یک کد وضعیت HTTP ( 103 Early Hints ) است که برای ارسال یک پاسخ HTTP اولیه قبل از پاسخ نهایی استفاده می شود. این به سرور اجازه می‌دهد تا نکاتی را درباره منابع فرعی مهم (به عنوان مثال، شیوه نامه برای صفحه، جاوا اسکریپت مهم) یا مبداهایی که احتمالاً توسط صفحه استفاده می‌شوند، به مرورگر ارسال کند، در حالی که سرور مشغول تولید منبع اصلی است. مرورگر می تواند از این نکات برای گرم کردن اتصالات و درخواست منابع فرعی در حالی که منتظر منبع اصلی است استفاده کند. به عبارت دیگر، نکات اولیه به مرورگر کمک می‌کند تا با انجام برخی کارها از قبل، از چنین «زمان فکری سرور» استفاده کند و در نتیجه سرعت بارگذاری صفحه را افزایش دهد.

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

در برخی موارد، بهبود عملکرد به بزرگترین رنگ محتوا می‌تواند از چند صد میلی‌ثانیه، همانطور که توسط Shopify و Cloudflare مشاهده شد، و تا یک ثانیه سریع‌تر باشد، همانطور که در این مقایسه قبل/بعد مشاهده می‌شود:

مقایسه دو سایت
قبل و بعد از مقایسه نکات اولیه در یک وب سایت آزمایشی با WebPageTest (Moto G4 - DSL)

پیاده سازی نکات اولیه

قبل از پرداختن به موضوع، لطفاً توجه داشته باشید که اگر سرور شما بتواند فوراً 200 (یا سایر پاسخ‌های نهایی) را ارسال کند، نکات اولیه مفید نیستند. در عوض، در چنین شرایطی، از پیوند معمولی link rel=preload یا link rel=preconnect در پاسخ اصلی ( هدر لینک rel HTTP )، یا در پاسخ اصلی ( عناصر <link> ) استفاده کنید. برای مواردی که سرور شما برای تولید پاسخ اصلی به زمان کمی نیاز دارد، به ادامه مطلب بروید!

اولین قدم برای استفاده از نکات اولیه شامل شناسایی صفحات فرود برتر است، یعنی صفحاتی که کاربران شما معمولاً هنگام بازدید از وب سایت شما از آنجا شروع می کنند. اگر تعداد زیادی کاربر از وب‌سایت‌های دیگر دارید، این می‌تواند صفحه اصلی یا صفحات فهرست محصولات محبوب باشد. دلیل اهمیت این نقاط ورودی بیشتر از سایر صفحات این است که مفید بودن Early Ints با پیمایش کاربر در وب سایت شما کاهش می یابد (یعنی احتمال دارد مرورگر تمام منابع فرعی مورد نیاز خود را در دومین یا سومین پیمایش بعدی داشته باشد) . همچنین همیشه ایده خوبی است که یک برداشت اول عالی ارائه دهید!

اکنون که این فهرست اولویت‌بندی‌شده از صفحات فرود را دارید، گام بعدی شامل شناسایی منابع یا منابع فرعی است که می‌توانند به عنوان اولین تقریب، نامزدهای خوبی برای راهنمایی‌های پیش‌اتصال یا بارگذاری اولیه باشند. به طور معمول، این منابع و منابع فرعی هستند که بیشترین کمک را به معیارهای کلیدی کاربر مانند Largest Contentful Paint یا First Contentful Paint دارند. به طور دقیق تر، به دنبال منابع فرعی مسدودکننده رندر مانند جاوا اسکریپت همزمان، شیوه نامه ها یا حتی فونت های وب باشید. به طور مشابه، به دنبال منابعی باشید که میزبان منابع فرعی هستند که سهم زیادی در معیارهای کلیدی کاربر دارند. توجه: اگر منابع اصلی شما قبلاً از <link rel=preconnect> یا <link rel=preload> استفاده می‌کنند، می‌توانید این منابع یا منابع را در میان نامزدهای Early Hints در نظر بگیرید. برای جزئیات بیشتر به این مقاله مراجعه کنید.

مرحله دوم شامل به حداقل رساندن خطر استفاده از نکات اولیه در منابع یا مبداهایی است که ممکن است منسوخ شده باشند یا دیگر توسط منبع اصلی استفاده نشوند. به عنوان مثال، منابعی که اغلب به روز می شوند و نسخه می شوند (به عنوان مثال، example.com/css/main.fa231e9c.css ) ممکن است بهترین انتخاب نباشند. توجه داشته باشید که این نگرانی مختص Early Hints نیست، بلکه برای هر پیوند rel=preload یا rel=preconnect در هر جایی که ممکن است وجود داشته باشد، اعمال می شود. این جزییاتی است که به بهترین وجه در مورد اتوماسیون یا قالب‌بندی پرداخته می‌شود (به عنوان مثال، یک فرآیند دستی به احتمال زیاد منجر به هش یا آدرس‌های اینترنتی نسخه‌ای ناهمخوان بین link rel=preload و تگ HTML واقعی با استفاده از منبع می‌شود).

به عنوان مثال، جریان زیر را در نظر بگیرید:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

سرور پیش‌بینی می‌کند که main.abcd100.css مورد نیاز خواهد بود، و پیشنهاد می‌کند آن را از طریق Early Hints از قبل بارگیری کنید:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

چند لحظه بعد، صفحه وب، از جمله CSS پیوند داده شده ارائه می شود. متأسفانه، این منبع CSS اغلب به روز می شود و منبع اصلی در حال حاضر پنج نسخه ( abcd105 ) از منبع پیش بینی شده CSS ( abcd100 ) جلوتر است.

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

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

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

در نهایت، در سمت سرور، به دنبال درخواست‌های منبع اصلی ارسال شده توسط مرورگرهایی باشید که از نکات اولیه پشتیبانی می‌کنند و بلافاصله با 103 نکات اولیه پاسخ دهید. در پاسخ 103، نکات مربوط به پیش اتصال و پیش بارگذاری را درج کنید. پس از آماده شدن منبع اصلی، پاسخ معمول را دنبال کنید (مثلاً 200 OK در صورت موفقیت آمیز بودن). برای سازگاری با عقب، تمرین خوبی است که هدرهای Link HTTP را نیز در پاسخ نهایی اضافه کنید، شاید حتی با منابع مهمی که به عنوان بخشی از تولید منبع اصلی آشکار شد (به عنوان مثال، بخش دینامیک یک منبع کلیدی اگر دنبال کنید " تقسیم به دو» پیشنهاد). این چیزی است که به نظر می رسد:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

چند لحظه بعد:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

پشتیبانی از مرورگر

اگرچه 103 Early Hints در همه مرورگرهای اصلی پشتیبانی می‌شود، دستورالعمل‌هایی که می‌توان در Early Hint ارسال کرد در هر مرورگر متفاوت است:

پشتیبانی از پیش اتصال:

پشتیبانی مرورگر

  • 103
  • 103
  • 120
  • 17

پشتیبانی از پیش بارگذاری:

پشتیبانی مرورگر

  • 103
  • 103
  • 123
  • ایکس

پشتیبانی سرور

در اینجا خلاصه ای سریع از سطح پشتیبانی از Early Hints در میان نرم افزارهای محبوب سرور OSS HTTP آورده شده است:

فعال کردن نکات اولیه، راه آسان

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

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

پاسخ‌های اطلاعاتی HTTP در محدوده 100 بخشی از استاندارد HTTP هستند، اما برخی از مشتریان یا ربات‌های قدیمی ممکن است با این موارد مشکل داشته باشند، زیرا قبل از راه‌اندازی 103 Early Hints، به ندرت برای مرور وب عمومی استفاده می‌شدند.

فقط ارسال 103 راهنمایی اولیه در پاسخ به کلاینت هایی که sec-fetch-mode: navigate هدر درخواست HTTP باید اطمینان حاصل کند که چنین نکاتی فقط برای مشتریان جدیدتر ارسال می شود که می دانند منتظر پاسخ بعدی هستند. علاوه بر این، از آنجایی که نکات اولیه فقط در درخواست‌های ناوبری پشتیبانی می‌شوند ( محدودیت‌های فعلی را ببینید)، این مزیت اضافه‌ای را دارد که از ارسال بیهوده آنها در سایر درخواست‌ها جلوگیری می‌کند.

به‌علاوه، توصیه‌های اولیه توصیه می‌شود که فقط از طریق اتصالات HTTP/2 یا HTTP/3 ارسال شوند .

الگوی پیشرفته

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

برای بازدیدکنندگانی که به عنوان بخشی از یک سفر معمولی کاربر، درخواست صفحه n خود را دارند، ممکن است بخواهید پاسخ نکات اولیه را با محتوای پایین‌تر و عمیق‌تر در صفحه تطبیق دهید، به عبارت دیگر از نکات اولیه در منابع با اولویت پایین‌تر استفاده کنید. این ممکن است با توجه به اینکه ما تمرکز بر منابع فرعی یا مبداهای دارای اولویت بالا و مسدودکننده رندر را توصیه می‌کنیم، غیر شهودی به نظر برسد. با این حال، زمانی که یک بازدیدکننده برای مدتی پیمایش کرده است، به احتمال بسیار زیاد مرورگر آنها از قبل تمام منابع حیاتی را در اختیار دارد. از آنجا به بعد، ممکن است منطقی باشد که توجه خود را به سمت منابع با اولویت پایین تر معطوف کنید. به عنوان مثال، این می تواند به معنای استفاده از نکات اولیه برای بارگیری تصاویر محصول یا JS/CSS اضافی باشد که فقط برای تعاملات کمتر معمول با کاربر مورد نیاز است.

محدودیت های فعلی

در اینجا محدودیت‌های Early Hints که در Chrome پیاده‌سازی شده‌اند، آمده است:

  • فقط برای درخواست های ناوبری (یعنی منبع اصلی برای سند سطح بالا) در دسترس است.
  • فقط از preconnect و preload اولیه پشتیبانی می کند (یعنی prefetch پشتیبانی نمی شود).
  • Early Hint و به دنبال آن یک تغییر مسیر متقاطع در پاسخ نهایی باعث می شود کروم منابع و اتصالاتی را که از طریق Early Hints به دست آورده است حذف کند.

سایر مرورگرها محدودیت‌های مشابهی دارند و 103 راهنمایی اولیه را فقط برای preconnect محدود می‌کنند.

بعدش چی؟

بسته به علاقه جامعه، ممکن است اجرای Early Hints را با قابلیت‌های زیر تقویت کنیم:

  • نکات اولیه در مورد درخواست های منابع فرعی ارسال می شود.
  • نکات اولیه در مورد درخواست های منبع اصلی iframe ارسال می شود.
  • پشتیبانی از واکشی اولیه در Early Hints.

ما از نظرات شما در مورد اینکه کدام جنبه ها باید اولویت بندی شوند و نحوه بهبود بیشتر نکات اولیه استقبال می کنیم.

ارتباط با H2/Push

اگر با ویژگی منسوخ HTTP2/Push آشنا هستید، ممکن است تعجب کنید که Early Hints چگونه متفاوت است. در حالی که Early Early Ints به یک سفر رفت و برگشت نیاز دارد تا مرورگر شروع به واکشی منابع فرعی حیاتی کند، با HTTP2/Push سرور می‌تواند منابع فرعی را در کنار پاسخ فشار دهد. اگرچه این شگفت‌انگیز به نظر می‌رسد، اما منجر به یک نقطه ضعف ساختاری کلیدی شد: با HTTP2/Push، اجتناب از فشار دادن منابع فرعی که مرورگر قبلاً داشت، بسیار سخت بود. این اثر "فشار بیش از حد" منجر به استفاده کمتر کارآمد از پهنای باند شبکه شد که به طور قابل توجهی مانع از مزایای عملکرد شد. به طور کلی، داده‌های کروم نشان داد که HTTP2/Push در واقع یک منفی خالص برای عملکرد در سراسر وب است.

در مقابل، Early Hints در عمل عملکرد بهتری دارد زیرا توانایی ارسال یک پاسخ اولیه را با نکاتی ترکیب می‌کند که مرورگر را مسئول واکشی یا اتصال به چیزی است که واقعاً به آن نیاز دارد. در حالی که Early Hints تمام موارد استفاده‌ای را که HTTP2/Push می‌تواند در تئوری به آن بپردازد را پوشش نمی‌دهد، ما معتقدیم که Early Hints راه‌حل عملی‌تری برای افزایش سرعت ناوبری است.

تصویر کوچک توسط پیر بامین .