Service Workers ابزاری قدرتمند برای اجازه دادن به وب‌سایت‌ها برای کار آفلاین و ایجاد قوانین ذخیره‌سازی تخصصی برای خود هستند. یک سرویس‌گر fetch هر درخواست را از صفحه‌ای که کنترل می‌کند، می‌بیند و می‌تواند تصمیم بگیرد که آیا می‌خواهد پاسخی به آن از حافظه پنهان سرویس‌دهنده ارائه دهد یا حتی URL را بازنویسی کند تا یک پاسخ کاملاً متفاوت را واکشی کند—مثلاً بر اساس محلی. تنظیمات کاربر
با این حال، زمانی که یک صفحه برای اولین بار پس از مدتی بارگیری می شود و کارگر خدمات کنترل در حال حاضر در حال اجرا نیست، ممکن است هزینه عملکردی برای کارکنان خدمات وجود داشته باشد. از آنجایی که همه واکشی‌ها باید از طریق سرویس‌دهنده انجام شوند، مرورگر باید منتظر بماند تا سرویس‌کار راه‌اندازی شود و اجرا شود تا بداند چه محتوایی باید بارگیری شود. این هزینه راه‌اندازی می‌تواند برای توسعه‌دهندگانی که از کارگران خدماتی برای بهبود عملکرد از طریق استراتژی‌های کش استفاده می‌کنند، کوچک، اما قابل توجه باشد.
پیش‌بارگذاری ناوبری یکی از روش‌های حل مشکل است - اجازه می‌دهد درخواست‌های ناوبری از طریق شبکه به موازات راه‌اندازی سرویس‌کار انجام شود - اما به درخواست‌های ناوبری اولیه محدود می‌شود و همچنان سرویس‌کار را در مسیر بحرانی شامل می‌شود. از زمانی که پیش‌بارگذاری ناوبری راه‌اندازی شد، تلاش‌های متعددی برای ایجاد راه‌حل کلی‌تر برای فضای مشکل، از جمله راه‌هایی برای مسدود نشدن برخی از درخواست‌ها در راه‌اندازی سرویس‌کار انجام شده است.
Service Worker Static Routing API
با شروع در Chrome 116، API آزمایشی Service Worker Static Routing برای آزمایش اولین گام برای چنین راه حلی در دسترس است. هنگامی که یک Service Worker نصب می شود، می تواند از Service Worker Static Routing API برای بیان اینکه چگونه مسیرهای منبع خاصی باید واکشی شوند، به طور شفاف بیان کند.
در نسخه اولیه API، مسیرها را می‌توان به گونه‌ای اعلام کرد که همیشه از شبکه ارائه می‌شوند، نه از سرویس‌کار. وقتی یک URL کنترل‌شده بعداً بارگیری می‌شود، مرورگر می‌تواند واکشی منابع را از آن مسیرها قبل از اینکه کارمند سرویس شروع به کار کند شروع کند. با این کار سرویس‌کار از مسیرهایی که می‌دانید نیازی به سرویس‌کار ندارند حذف می‌کند.
برای استفاده از API، سرویس‌کار با مجموعه‌ای از قوانین event.registerRouter را در رویداد install فرا می‌خواند:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
هر قانون به طور کلی دو ویژگی دارد:
condition: مشخص می کند که چه زمانی این قانون با استفاده از URL Pattern API برای مطابقت با مسیرهای منبع اعمال می شود. این ویژگی می‌تواند یک نمونهURLPatternیا یک شیء ساده معادل داشته باشد که با انتقال به سازندهURLPatternسازگار است (به عنوان مثال،new URLPattern({pathname: '*.jpg'})یا فقط{pathname: '*.jpg'}).انعطاف پذیری الگوهای URL به این معنی است که این قانون می تواند چیزی به سادگی هر منبعی را تحت یک مسیر، با شرایط بسیار خاص و دقیق مطابقت دهد. الگوها عموماً باید برای کاربران کتابخانه های مسیریابی محبوب آشنا باشند.
source: نحوه بارگیریconditionتطبیق منابع را مشخص می کند. امروزه فقط مقدار'network'پشتیبانی می‌شود (با دور زدن سرویس‌کار برای بارگیری مستقیم منبع از طریق شبکه)، اما برنامه این است که این مقدار را به مقادیر دیگر در آینده گسترش دهیم .
موارد استفاده کنید
همانطور که توضیح داده شد، نسخه اولیه API اساساً یک دریچه فرار از کنترل کارکنان سرویس برای برخی از مسیرها است. جایی که استفاده از آن منطقی است بستگی به نحوه استفاده شما از سرویس دهنده و نحوه عبور کاربران از سایت شما دارد.
یک مثال ممکن است این باشد که سایت شما از یک استراتژی cache-first استفاده کند (بازگشت به شبکه)، اما محتوایی وجود دارد که آنقدر به ندرت بازدید می شود که هیچ ارزشی برای ورود به حافظه پنهان ندارد (مانند محتوای آرشیو شده یا فیدهای RSS). محدود کردن این مسیرها برای واکشی فقط از شبکه می‌تواند در سرویس‌کار راه‌اندازی شود، اما سرویس‌کار همچنان باید راه‌اندازی و اجرا شود تا تصمیم بگیرد که چگونه این درخواست‌ها را مدیریت کند.
در مقابل، API مسیریابی استاتیک، با چند خط اعلامی، سرویس‌کار را به‌طور کامل دور می‌زند:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
همانطور که Service Worker Static Routing API در حال تکامل است، برنامه این است که این پیکربندی انعطاف‌پذیرتر شود و از سناریوهای بیشتری پشتیبانی کند، مانند مسابقه اعلامی واکشی شبکه و راه‌اندازی کارگر سرویس. برای جزئیات بیشتر ، کاوش توضیح دهنده مشخصات یک "فرم نهایی" بالقوه API را ببینید.
در حال آزمایش سرویس Worker Static Routing API
Service Worker Static Routing API در کروم در نسخه 116 در پشت نسخه آزمایشی اصلی موجود است که به توسعه دهندگان اجازه می دهد API را در سایت خود با کاربران واقعی آزمایش کنند تا تأثیر را اندازه گیری کنند. برای اطلاعات پس‌زمینه آزمایش‌های مبدأ، به «شروع کار با آزمایش‌های مبدا» مراجعه کنید.
برای آزمایش محلی، Service Worker Static Routing API را می‌توان با یک پرچم در chrome://flags/#service-worker-static-router یا با اجرای Chrome از دستوری مانند --enable-features=ServiceWorkerStaticRouter فعال کرد.
بازخورد و مسیرهای آینده
Service Worker Static Routing API به طور فعال در حال توسعه است و هنوز در حال شکل گیری است. اگر به نظر می رسد می تواند برای شما مفید باشد، لطفاً آن را از طریق نسخه آزمایشی اصلی امتحان کنید و بازخورد خود را در مورد API، پیاده سازی و عملکرد موجود ارائه دهید .