یکی از ویژگی‌های سرویس‌کار این است که می‌توانند فایل‌ها را در حافظه پنهان هنگام نصب سرویس‌کار ذخیره کنند. این به عنوان "precaching" شناخته می شود. پیش کش این امکان را فراهم می کند تا فایل های کش شده را بدون رفتن به شبکه به مرورگر ارائه دهید. از پیش کش برای دارایی های حیاتی که سایت شما به آنها نیاز دارد حتی در حالت آفلاین استفاده کنید: صفحه اصلی، سبک ها، تصویر بازگشتی و اسکریپت های ضروری.
چرا باید از Workbox استفاده کنید؟
استفاده از Workbox برای پیش کش اختیاری است. شما می توانید کد خود را برای پیش کش کردن دارایی های حیاتی هنگام نصب سرویس دهنده بنویسید. مزیت اصلی استفاده از Workbox کنترل نسخه خارج از جعبه آن است. برای به‌روزرسانی دارایی‌های از پیش کش شده با استفاده از Workbox با مشکل کمتری مواجه خواهید شد تا اینکه مجبور باشید نسخه‌سازی و به‌روزرسانی این فایل‌ها را خودتان مدیریت کنید.
پیش کش آشکار می شود
پیش کش توسط لیستی از URL ها و اطلاعات مربوط به نسخه سازی برای هر URL هدایت می شود. روی هم، این اطلاعات به عنوان مانیفست پیش کش شناخته می شود. مانیفست «منبع حقیقت» برای وضعیت همه چیزهایی است که در پیش کش برای یک نسخه معین از یک برنامه وب قرار دارند. یک مانیفست پیش کش، در قالب استفاده شده توسط Workbox ، چیزی شبیه به:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
هنگامی که سرویس‌کار نصب می‌شود، سه ورودی حافظه پنهان برای هر یک از سه URL فهرست شده در حافظه پنهان ایجاد می‌شود. اولین دارایی دارای اطلاعات نسخه‌سازی است که قبلاً در URL آن گنجانده شده است ( app نام فایل واقعی است و .abcd1234 حاوی اطلاعات نسخه‌سازی است، درست قبل از پسوند فایل .js ). ابزارهای ساخت Workbox می‌توانند این را تشخیص دهند و یک فیلد تجدیدنظر را حذف کنند. دو دارایی دیگر هیچ اطلاعات نسخه‌سازی را در URLهای خود ندارند، بنابراین ابزارهای ساخت Workbox یک فیلد revision جداگانه ایجاد می‌کنند که حاوی هش از محتوای فایل محلی است.
ارائه منابع از پیش ذخیره شده
افزودن دارایی ها به حافظه نهان تنها بخشی از داستان پیش کش است – هنگامی که دارایی ها در حافظه پنهان ذخیره شدند، باید به درخواست های خروجی پاسخ دهند. این به یک شنونده رویداد fetch در سرویس‌کار شما نیاز دارد که بتواند بررسی کند کدام URLها از پیش ذخیره شده‌اند، و پاسخ‌های ذخیره‌شده را به‌طور قابل‌اعتماد بازگرداند و شبکه را در این فرآیند دور بزند. از آنجایی که کارمند سرویس کش را برای پاسخ‌ها بررسی می‌کند (و از آن‌هایی که قبل از شبکه استفاده می‌شود)، به این استراتژی cache-first گفته می‌شود.
به روز رسانی های کارآمد
مانیفست پیش کش نمایش دقیقی از حالت کش مورد انتظار را ارائه می دهد. اگر ترکیب URL/بازبینی در مانیفست تغییر کند، یک سرویس‌کار می‌داند که ورودی حافظه پنهان قبلی دیگر معتبر نیست و باید به‌روزرسانی شود. تنها به یک درخواست شبکه نیاز دارد که به‌طور خودکار توسط مرورگر به‌عنوان بخشی از بررسی به‌روزرسانی کارگر سرویس انجام می‌شود تا مشخص شود کدام URLهای پیش‌کش شده باید به‌روزرسانی شوند.
به روز رسانی منابع از پیش ذخیره شده
همانطور که نسخه‌های جدید برنامه وب خود را در طول زمان منتشر می‌کنید، باید URLهای از پیش ذخیره‌شده قبلی را به‌روز نگه دارید، دارایی‌های جدید را از پیش ذخیره کنید و ورودی‌های قدیمی را حذف کنید. تا زمانی که هر بار که سایت خود را بازسازی می کنید به تولید یک مانیفست کامل پیش کش ادامه دهید، آن مانیفست به عنوان "منبع حقیقت" برای وضعیت پیش کش شما در هر مقطع زمانی عمل می کند.
اگر یک URL موجود با یک فیلد ویرایش جدید وجود داشته باشد، یا هر نشانی اینترنتی اضافه شده یا از مانیفست حذف شده باشد، این نشانه ای برای سرویس دهنده شما است که به عنوان بخشی از install و activate کنترل کننده رویداد، باید به روز رسانی انجام شود. به عنوان مثال، اگر تغییراتی در سایت خود ایجاد کرده اید و آن را بازسازی کرده اید، ممکن است آخرین مانیفست پیش کش شما دچار تغییرات زیر شده باشد:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
هر یک از این تغییرات به کارمند خدمات شما می‌گوید که باید درخواست‌های جدیدی برای به‌روزرسانی ورودی‌های ذخیره‌شده قبلی ( 'offline.svg' و 'index.html' ) و ذخیره کردن URLهای جدید ( 'app.ffaa4455.js' ) و همچنین حذف برای پاک کردن URL هایی که دیگر استفاده نمی شوند ( 'app.abcd1234.js' ).
تجربه نصب واقعی "فروشگاه برنامه".
یکی دیگر از مزایای پیش کش این است که می توانید تجربه ای را به کاربران خود ارائه دهید که در غیر این صورت دستیابی به آن در خارج از نصب «اپ استور» دشوار خواهد بود. هنگامی که کاربر برای اولین بار از هر صفحه ای در برنامه وب شما بازدید می کند، می توانید به طور بالقوه تمام URL های مورد نیاز برای نمایش هر یک از نماهای برنامه وب خود را قبل از موعد، بدون نیاز به منتظر ماندن تا بازدید از هر نما، از قبل ذخیره کنید.
هنگامی که کاربر یک برنامه را نصب می کند، انتظار دارد همه قسمت ها به سرعت نمایش داده شوند، نه فقط نماهایی که در گذشته به آن ها رفته اند. پیش کش همان تجربه را برای برنامه های وب به ارمغان می آورد.
کدام یک از دارایی های شما باید precach شوند؟
برای دریافت تصویری خوب از اینکه کدام URL ها برای پیش کش کردن بیشتر منطقی هستند، به راهنمای شناسایی موارد در حال بارگیری مراجعه کنید. قاعده کلی این است که هر HTML، جاوا اسکریپت یا CSS را که در اوایل بارگذاری شده است و برای نمایش ساختار اصلی یک صفحه خاص بسیار مهم است، پیش کش کنید.
ترجیحاً از پیش کش کردن رسانه یا سایر دارایی هایی که بعداً بارگیری می شوند خودداری کنید (مگر اینکه برای عملکرد برنامه وب شما مهم باشد). در عوض، از یک استراتژی کش در زمان اجرا استفاده کنید تا اطمینان حاصل کنید که این دارایی‌ها به‌طور همزمان ذخیره می‌شوند.
همیشه به خاطر داشته باشید که پیش کش شامل استفاده از پهنای باند شبکه و فضای ذخیره سازی در دستگاه کاربر است (دقیقاً مانند نصب یک برنامه از یک فروشگاه برنامه). این به شما به‌عنوان توسعه‌دهنده بستگی دارد که با احتیاط اقدام به پیش کشی کنید و از مانیفست پیش کش متورم خودداری کنید.
ابزارهای ساخت Workbox با گفتن تعداد موارد موجود در مانیفست پیش کش و همچنین اندازه کل محموله پیش کش به شما کمک می کند.
بازدیدکنندگان مکرر برنامه وب شما در درازمدت از هزینه اولیه پیش کش سود می برند، زیرا توانایی آن برای جلوگیری از شبکه به سرعت در پهنای باند ذخیره شده در طول زمان هزینه می کند.