رسیدگی به درخواست‌های پیمایش

بااستفاده از سرویس‌کار، بدون منتظر ماندن برای شبکه، به درخواست‌های پیمایش پاسخ دهید.

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

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

در داخل گرداننده رویداد fetch مربوط به سرویس‌ورکر، می‌توانید با بررسی ویژگی request.mode در FetchEvent تعیین کنید که آیا درخواست از نوع پیمایش است یا نه. اگر روی 'navigate' تنظیم شده باشد، درخواست پیمایش است.

به‌عنوان یک قانون کلی، از Cache-Control headers با عمر طولانی برای ذخیره کردن پاسخ HTML در حافظه نهان برای درخواست پیمایش استفاده نکنید. این درخواست‌ها معمولاً باید ازطریق شبکه با Cache-Control: no-cache برآورده شوند تا اطمینان حاصل شود که HTML، همراه با زنجیره درخواست‌های شبکه بعدی، (به‌طور منطقی) تازه است. متأسفانه، رفتن به شبکه هر بار که کاربر به صفحه جدیدی پیمایش می‌کند، به این معنی است که هر پیمایش ممکن است کند باشد. حداقل این است که سرعت آن قابل‌اطمینان نخواهد بود.

رویکردهای مختلف برای معماری‌ها

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

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

سایت‌های ایستا کوچک

اگر برنامه وب شما از تعداد نسبتاً کمی (مثلاً چند ده) نشانی وب یکتا تشکیل شده است و هرکدام از این نشانی‌های وب با یک فایل HTML ایستا متفاوت مطابقت دارد، یک رویکرد مناسب این است که همه این فایل‌های HTML را در حافظه پنهان ذخیره کنید و به درخواست‌های پیمایش با HTML مناسب ذخیره‌شده در حافظه پنهان پاسخ دهید.

بااستفاده از پیش‌ذخیره‌سازی، می‌توانید HTML را ازقبل، به‌محض نصب شدن سرویس‌کار، ذخیره کنید و هربار که سایتتان را بازسازی می‌کنید و سرویس‌کارتان را دوباره مستقر می‌کنید، HTML ذخیره‌شده را به‌روز کنید.

یا اگر ترجیح می‌دهید از پیش‌ذخیره‌سازی همه HTML خود اجتناب کنید—شاید به این دلیل که کاربران معمولاً فقط به زیرمجموعه‌ای از نشانی‌های وب در سایت شما پیمایش می‌کنند—می‌توانید از یک stale-while-revalidate runtime caching استفاده کنید. بااین‌حال، درباره این رویکرد مراقب باشید، زیرا هر سند HTML جداگانه ذخیره و به‌روزرسانی می‌شود. استفاده از ذخیره‌سازی موقت زمان اجرا برای HTML زمانی مناسب‌تر است که تعداد کمی نشانی وب داشته باشید که توسط همان مجموعه کاربران به‌طور مکرر بازدید می‌شوند و اگر با اعتبارسنجی مجدد آن نشانی‌های وب به‌طور مستقل از یکدیگر مشکلی نداشته باشید.

برنامه‌های تک‌صفحه‌ای

معماری تک‌صفحه‌ای اغلب توسط برنامه‌های وب مدرن استفاده می‌شود. در این نوع، جاوا اسکریپت سمت کارخواه HTML را در پاسخ به کنش‌های کاربر اصلاح می‌کند. این مدل از History API برای اصلاح نشانی وب فعلی هنگام تعامل کاربر با برنامه وب استفاده می‌کند، که منجر به چیزی می‌شود که درواقع یک پیمایش «شبیه‌سازی‌شده» است. درحالی‌که پیمایش‌های بعدی ممکن است «جعلی» باشند، پیمایش اولیه واقعی است و هنوز مهم است که مطمئن شوید در شبکه مسدود نشده است.

خوشبختانه، اگر از معماری تک‌صفحه‌ای استفاده می‌کنید، الگوی ساده‌ای برای ارائه ناوبری اولیه از حافظه پنهان وجود دارد: پوسته برنامه. در این مدل، service worker شما با برگرداندن همان فایل HTML تکی که قبلاً پیش‌ذخیره شده است، به درخواست‌های پیمایش پاسخ می‌دهد—صرف‌نظر از نشانی وب درخواست‌شده. این HTML باید ساده باشد، و شاید شامل یک نشانگر بارگیری عمومی یا محتوای اسکلتی باشد. وقتی مرورگر این HTML را از حافظه نهان بار کرد، JavaScript سمت کارخواه موجود شما کنترل را به‌دست می‌گیرد و محتوای HTML صحیح را برای نشانی وب از درخواست پیمایش اصلی ارائه می‌کند.

Workbox ابزارهای لازم برای پیاده‌سازی این رویکرد را ارائه می‌دهد؛ navigateFallback option به شما امکان می‌دهد مشخص کنید از کدام سند HTML به‌عنوان پوسته برنامه استفاده شود، و همچنین یک فهرست مجاز و فهرست رد اختیاری برای محدود کردن این رفتار به زیرمجموعه‌ای از نشانی‌های وب شما ارائه می‌دهد.

برنامه‌های چندصفحه‌ای

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

اما برای زیرمجموعه خاصی از برنامه‌های چندصفحه‌ای، ممکن است بتوانید یک کارگر سرویس را پیاده‌سازی کنید که منطق استفاده‌شده در سرور وب شما را برای تولید HTML کاملاً تکرار کند. This works best if you can share routing and templating information between the server and service worker environments, and in particular, if your web server uses JavaScript (without relying on Node.js-specific features, like file system access).

اگر سرور وب شما در این دسته قرار می‌گیرد و می‌خواهید رویکردی را برای انتقال تولید HTML از شبکه به سرویس‌کار خود بررسی کنید، راهنمایی‌های موجود در فراتر از SPAs: معماری‌های جایگزین برای PWA شما می‌تواند به شما کمک کند.

سایر چیزها

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

Workbox یک کتابخانه کمکی ارائه می‌دهد که تشخیص می‌دهد آیا پیش‌بارگذاری پیمایش پشتیبانی می‌شود یا نه، و اگر پشتیبانی شود، فرایند دستور دادن به کارگر سرویس برای استفاده از پاسخ شبکه را ساده می‌کند.