دریابید که سرور شما چگونه میتواند در مورد زیرمنابع حیاتی به مرورگر سرنخ ارسال کند.
منتشر شده: ۲۳ ژوئن ۲۰۲۲، آخرین بهروزرسانی: ۱۰ ژوئیه ۲۰۲۶
نکات اولیه چیست؟
وبسایتها با گذشت زمان پیچیدهتر شدهاند. به همین دلیل، غیرمعمول نیست که یک سرور برای تولید HTML صفحه درخواستی، نیاز به انجام کارهای غیرمهم (مثلاً دسترسی به پایگاههای داده یا CDNهایی که به سرور مبدا دسترسی دارند) داشته باشد. متأسفانه، این «زمان تفکر سرور» منجر به تأخیر اضافی قبل از شروع رندر صفحه توسط مرورگر میشود. در واقع، اتصال تا زمانی که سرور پاسخ را آماده کند، عملاً غیرفعال میماند.

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

در برخی موارد، بهبود عملکرد در Largest Contentful Paint میتواند از چند صد میلیثانیه، همانطور که توسط Shopify و Cloudflare مشاهده شده است، تا یک ثانیه سریعتر باشد، همانطور که در این مقایسه قبل و بعد مشاهده میشود:

نحوه استفاده از نکات اولیه
اولین قدم برای استفاده از Early Hints شناسایی صفحات فرود برتر است، یعنی صفحاتی که کاربران شما معمولاً هنگام بازدید از وبسایت شما از آنجا شروع میکنند. این صفحات میتوانند صفحه اصلی یا صفحات محبوب فهرست محصولات باشند، اگر کاربران زیادی از وبسایتهای دیگر آمده باشند. دلیل اهمیت بیشتر این نقاط ورودی نسبت به سایر صفحات این است که با پیمایش کاربر در وبسایت شما، سودمندی Early Hints کاهش مییابد (یعنی، مرورگر احتمالاً تمام منابع فرعی مورد نیاز خود را در پیمایش دوم یا سوم بعدی دارد). همچنین همیشه ایده خوبی است که یک برداشت اولیه عالی ارائه دهید!
حالا که این لیست اولویتبندیشده از صفحات فرود را دارید، قدم بعدی این است که مشخص کنید کدام منابع اصلی یا فرعی میتوانند کاندیداهای خوبی برای نکات preconnect یا preload باشند. معمولاً این منابع اصلی و فرعی، منابعی هستند که بیشترین سهم را در معیارهای کلیدی کاربر مانند Largest Contentful Paint یا First Contentful Paint دارند. بهطور مشخصتر، به دنبال منابع فرعی مسدودکننده رندر مانند جاوا اسکریپت همزمان، stylesheets یا حتی فونتهای وب باشید. بهطور مشابه، به دنبال منابع اصلی باشید که میزبان منابع فرعی هستند که سهم زیادی در معیارهای کلیدی کاربر دارند.
همچنین توجه داشته باشید که اگر منابع اصلی شما از قبل preconnect یا preload استفاده میکنند، میتوانید این منابع یا منابع را در میان کاندیداهای Early Hints در نظر بگیرید. برای جزئیات بیشتر به نحوه بهینهسازی LCP مراجعه کنید. با این حال، کپی کردن سادهلوحانه دستورالعملهای preconnect و preload از HTML به Early Hints ممکن است بهینه نباشد .
هنگام استفاده از این موارد در HTML، معمولاً میخواهید منابعی را که اسکنر Preload در HTML کشف نمیکند، preconnect یا preload - برای مثال، فونتها یا تصاویر پسزمینه که در غیر این صورت دیر کشف میشوند. برای Early Hints، HTML را نخواهید داشت، بنابراین ممکن است بخواهید به جای آن به دامنههای حیاتی از preconnect یا منابع حیاتی را که شاید در غیر این صورت در اوایل HTML کشف میشدند، از قبل preload - برای مثال، main.css یا app.js را از قبل بارگذاری کنید. علاوه بر این، همه مرورگرها preload برای Early Hints پشتیبانی نمیکنند - به پشتیبانی مرورگر مراجعه کنید.
مرحله دوم شامل به حداقل رساندن خطر استفاده از Early Hints در منابع یا منابعی است که ممکن است منسوخ شده باشند یا دیگر توسط منبع اصلی استفاده نشوند. به عنوان مثال، منابعی که مرتباً بهروزرسانی و نسخهبندی میشوند (به عنوان مثال، example.com/css/main.fa231e9c.css ) ممکن است بهترین انتخاب نباشند. توجه داشته باشید که این نگرانی مختص Early Hints نیست، بلکه در مورد هرگونه preload یا preconnect در هر کجا که ممکن است وجود داشته باشند، صدق میکند. این نوع جزئیاتی است که به بهترین وجه با اتوماسیون یا قالببندی قابل حل است (به عنوان مثال، یک فرآیند دستی احتمالاً منجر به عدم تطابق هش یا نسخه URLها بین 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">
به طور کلی، منابع و ریشههایی را هدف قرار دهید که نسبتاً پایدار باشند و تا حد زیادی مستقل از نتیجه منبع اصلی باشند. در صورت لزوم، میتوانید منابع کلیدی خود را به دو بخش تقسیم کنید: یک بخش پایدار که برای استفاده با Early Hints طراحی شده است، و یک بخش پویاتر که پس از دریافت منبع اصلی توسط مرورگر، برای دریافت باقی میماند:
<html>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.css">
<link rel="stylesheet" href="/experimental.3eab3290.css">
در نهایت، در سمت سرور، به دنبال درخواستهای منبع اصلی ارسال شده توسط مرورگرهایی باشید که از Early Hints پشتیبانی میکنند و بلافاصله با 103 Early Hints پاسخ دهید. در پاسخ 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 ارسال شوند، در هر مرورگر متفاوت است:
پشتیبانی پیش اتصال:
Browser Support
پشتیبانی از پیش بارگذاری:
Browser Support
Chrome DevTools همچنین از 103 Early Hints پشتیبانی میکند و هدرهای Link را میتوان در منابع سند مشاهده کرد:

Link در Chrome DevTools نمایش داده میشوند. توجه داشته باشید که برای استفاده از منابع Early Hints، Disable cache نباید در DevTools تیک خورده باشد زیرا Early Hints از حافظه پنهان مرورگر استفاده میکند. برای منابع از پیش بارگذاری شده، Initiator به صورت Early-hints و Size به صورت (Disk cache) نشان داده میشود:

early-hints هستند و از حافظه پنهان دیسک بارگذاری میشوند.این همچنین به یک گواهی معتبر برای آزمایش HTTPS نیاز دارد.
فایرفاکس به طور صریح از 103 Early Hints به عنوان یک آغازگر در DevTools پشتیبانی نمیکند، اما منابعی که با استفاده از Early Hints بارگذاری میشوند، در ستون Transferred به صورت cached نمایش داده میشوند و وقتی روی آنها کلیک میشود، یک هدر درخواست HTTP با عنوان X-Moz: early hint دارند.
پشتیبانی سرور
در اینجا خلاصهای سریع از سطح پشتیبانی از Early Hints در بین نرمافزارهای متنباز محبوب و نرمافزارهای سرور HTTP ارائه شده است:
- آپاچی: با استفاده از mod_http2 پشتیبانی میشود .
- H2O: پشتیبانی میشود .
- NGINX: پشتیبانی میشود .
- گره: برای http و http2 پشتیبانی میشود
فعال کردن Early Hints به روشی آسانتر
اگر از یکی از CDNها یا پلتفرمهای زیر استفاده میکنید، ممکن است نیازی به پیادهسازی دستی Early Hints نداشته باشید. برای اطلاع از پشتیبانی آن از Early Hints، به مستندات آنلاین ارائهدهندهی راهکار خود مراجعه کنید، یا به فهرست ناقص اینجا مراجعه کنید:
چگونه از بروز مشکلات برای کلاینتهایی که از Early Hints پشتیبانی نمیکنند، جلوگیری کنیم؟
پاسخهای HTTP اطلاعاتی در محدوده ۱۰۰ بخشی از استاندارد HTTP هستند، اما برخی از کلاینتها یا رباتهای قدیمیتر ممکن است با این موارد مشکل داشته باشند زیرا قبل از راهاندازی ۱۰۳ نکته اولیه، آنها به ندرت برای مرور وب عمومی استفاده میشدند.
فقط انتشار 103 راهنمایی اولیه در پاسخ به کلاینتهایی که هدر درخواست HTTP با عنوان sec-fetch-mode: navigate ارسال میکنند، باید چنین راهنماییهایی را فقط برای کلاینتهای جدیدتری ارسال کند که میدانند باید منتظر پاسخ بعدی بمانند. علاوه بر این، از آنجایی که راهنماییهای اولیه فقط در درخواستهای ناوبری پشتیبانی میشوند (به محدودیتهای فعلی مراجعه کنید)، این مزیت اضافی را دارد که از ارسال غیرضروری این موارد در درخواستهای دیگر جلوگیری میکند.
علاوه بر این، توصیه میشود Early Hints فقط از طریق اتصالات HTTP/2 یا HTTP/3 ارسال شوند و اکثر مرورگرها فقط آنها را از طریق این پروتکلها میپذیرند.
الگوی پیشرفته
اگر نکات اولیه را به طور کامل در صفحات فرود کلیدی خود اعمال کردهاید و به دنبال فرصتهای بیشتری هستید، ممکن است به الگوی پیشرفته زیر علاقهمند باشید.
برای بازدیدکنندگانی که به عنوان بخشی از یک سفر کاربری معمولی، در صفحه nام خود درخواست دارند، ممکن است بخواهید پاسخ Early Hints را با محتوایی که در پایین و عمق صفحه قرار دارد، تطبیق دهید، به عبارت دیگر از Early Hints روی منابع با اولویت پایینتر استفاده کنید. این ممکن است با توجه به اینکه ما توصیه کردیم روی زیرمنابع یا ریشههای با اولویت بالا و مسدودکننده رندر تمرکز کنید، متناقض به نظر برسد. با این حال، زمانی که یک بازدیدکننده مدتی در صفحه پیمایش کرده باشد، به احتمال زیاد مرورگر او از قبل تمام منابع حیاتی را در اختیار دارد. از آنجا به بعد، منطقی است که توجه خود را به سمت منابع با اولویت پایینتر معطوف کنید. به عنوان مثال، این میتواند به معنای استفاده از Early Hints برای بارگذاری تصاویر محصول یا JS/CSS اضافی باشد که فقط برای تعاملات کاربری کمتر رایج مورد نیاز هستند.
محدودیتهای فعلی
محدودیتهای Early Hints که در کروم پیادهسازی شدهاند، به شرح زیر است:
- فقط برای درخواستهای ناوبری (یعنی منبع اصلی برای سند سطح بالا) در دسترس است.
- فقط
preconnectوpreloadپشتیبانی میکند (یعنیprefetchپشتیبانی نمیکند). - هشدارهای اولیه (Early Hints) و به دنبال آن تغییر مسیر بین مبدا (cross-origin redirect) در پاسخ نهایی، باعث میشود مرورگرها منابع و اتصالاتی را که با استفاده از هشدارهای اولیه (Early Hints) به دست آوردهاند، حذف کنند.
- منابعی که با استفاده از Early Hints از قبل بارگذاری میشوند، در حافظه پنهان HTTP ذخیره میشوند و بعداً توسط صفحه از آنجا بازیابی میشوند. بنابراین، فقط منابع قابل ذخیره میتوانند با استفاده از Early Hints از قبل بارگذاری شوند، در غیر این صورت منبع دو بار (یک بار توسط Early Hints و بار دیگر توسط سند) فراخوانی میشود. در کروم، حافظه پنهان HTTP برای گواهینامههای HTTPS غیرقابل اعتماد غیرفعال است (حتی اگر به بارگذاری صفحه ادامه دهید).
- پیش بارگذاری تصاویر واکنشگرا (با استفاده از
imagesrcset،imagesizesیاmedia) ممکن است با استفاده از هدرهای HTTP<link>پشتیبانی نشود، زیرا viewport تا زمان ایجاد سند تعریف نمیشود. در بهترین حالت، آنها تا زمان دریافت سند منتظر میمانند و مزایای اصلی 103 Early Hints را خنثی میکنند.
مرورگرهای دیگر محدودیتهای مشابهی دارند و همانطور که قبلاً اشاره شد ، برخی دیگر 103 نکته اولیه را فقط به preconnect محدود میکنند.
ارتباط با H2/Push
اگر با ویژگی منسوخشدهی HTTP2/Push آشنا باشید، ممکن است از خود بپرسید که Early Hints چه تفاوتی با آن دارد. در حالی که Early Hints برای شروع واکشی زیرمنابع حیاتی توسط مرورگر، به یک رفت و برگشت نیاز دارد، با HTTP2/Push سرور میتواند در کنار پاسخ، زیرمنابع را نیز ارسال کند. اگرچه این موضوع شگفتانگیز به نظر میرسد، اما منجر به یک نقطه ضعف ساختاری کلیدی شد: با HTTP2/Push، اجتناب از ارسال زیرمنابعی که مرورگر از قبل داشت، بسیار دشوار بود. این اثر «ارسال بیش از حد» منجر به استفادهی کمتر کارآمد از پهنای باند شبکه شد که به طور قابل توجهی مانع از مزایای عملکرد شد. به طور کلی، دادههای کروم نشان داد که HTTP2/Push در واقع یک عامل منفی برای عملکرد در سراسر وب بوده است.
در مقابل، Early Hints در عمل عملکرد بهتری دارد زیرا قابلیت ارسال پاسخ اولیه را با راهنماییهایی ترکیب میکند که مرورگر را مسئول دریافت یا اتصال به آنچه واقعاً نیاز دارد، قرار میدهد. اگرچه Early Hints تمام موارد استفادهای را که HTTP2/Push میتواند در تئوری پوشش دهد، پوشش نمیدهد، ما معتقدیم که Early Hints یک راه حل عملیتر برای سرعت بخشیدن به پیمایشها است.
تصویر کوچک از پیر بامین .