کش در زمان اجرا به افزودن تدریجی پاسخ‌ها به حافظه نهان اشاره دارد. در حالی که کش در زمان اجرا به قابلیت اطمینان درخواست فعلی کمک نمی کند، می تواند به اطمینان بیشتر درخواست های آینده برای همان URL کمک کند.
کش HTTP مرورگر نمونه ای از کش در زمان اجراست. فقط پس از درخواست برای یک URL معین پر می شود. اما سرویس‌کاران به شما اجازه می‌دهند که کش در زمان اجرا را اجرا کنید که فراتر از آن چیزی است که کش HTTP به تنهایی می‌تواند ارائه دهد.
استراتژیک گرفتن
برخلاف precaching (که همیشه سعی می‌کند مجموعه‌ای از فایل‌های از پیش تعریف‌شده را از حافظه پنهان ارائه کند)، کش در زمان اجرا می‌تواند دسترسی شبکه و حافظه پنهان را به روش‌های مختلف ترکیب کند. هر ترکیبی به طور کلی به عنوان یک استراتژی ذخیره سازی نامیده می شود. استراتژی های کلیدی ذخیره سازی عبارتند از:
- شبکه-اول
- ابتدا حافظه پنهان
- قدیمی-در حالی که-تأیید مجدد
شبکه-اول
در این رویکرد، کارمند خدمات شما ابتدا سعی می کند یک پاسخ را از شبکه بازیابی کند. اگر درخواست شبکه موفق شد، عالی است! پاسخ به برنامه وب شما برگردانده می‌شود و یک کپی از پاسخ با استفاده از API حافظه پنهان ذخیره می‌شود—یا یک ورودی جدید ایجاد کنید یا ورودی قبلی را برای همان URL به‌روزرسانی کنید.
اگر درخواست شبکه به طور کامل شکست بخورد، یا برای بازگرداندن یک پاسخ خیلی طول بکشد ، در عوض آخرین پاسخ از حافظه پنهان بازگردانده می شود.
ابتدا حافظه پنهان
یک استراتژی cache-first عملاً مخالف شبکه-اول است. در این رویکرد، زمانی که سرویس‌کار شما درخواستی را رهگیری می‌کند، ابتدا از API ذخیره‌سازی حافظه پنهان استفاده می‌کند تا ببیند آیا پاسخ ذخیره‌سازی شده موجود است یا خیر. اگر وجود داشته باشد، آن پاسخ به برنامه وب برگردانده می شود.
با این حال، اگر حافظه پنهان وجود نداشته باشد، سرویس‌کار به شبکه می‌رود و سعی می‌کند پاسخی را در آنجا بازیابی کند. با فرض موفقیت آمیز بودن درخواست شبکه، به برنامه وب شما برگردانده می شود و یک کپی در حافظه پنهان ذخیره می شود. این کپی ذخیره شده برای دور زدن شبکه دفعه بعد که درخواستی برای همان URL ها انجام شد استفاده می شود.
قدیمی-در حالی که-تأیید مجدد
Stale-while-Revalidate چیزی شبیه ترکیبی است. هنگام استفاده از آن، کارمند خدمات شما فوراً پاسخ ذخیره شده را بررسی می کند و در صورت یافتن پاسخ، آن را به برنامه وب شما بازگرداند.
در این میان، صرف نظر از اینکه آیا تطبیق حافظه پنهان وجود داشته است یا خیر، کارگر سرویس شما نیز یک درخواست شبکه را برای دریافت پاسخ «تازه» انجام می‌دهد. این پاسخ برای به روز رسانی هر پاسخی که قبلاً در حافظه پنهان شده است استفاده می شود. اگر بررسی اولیه حافظه پنهان اشتباه بود، یک کپی از پاسخ شبکه نیز به برنامه وب شما ارسال می شود.
چرا باید از Workbox استفاده کنید؟
این استراتژی‌های ذخیره‌سازی شامل دستور العمل‌هایی است که معمولاً باید در سرویس‌کار خود بازنویسی کنید، بارها و بارها. به جای متوسل شدن به آن، Workbox آنها را به عنوان بخشی از کتابخانه استراتژی‌های خود بسته‌بندی می‌کند و آماده است تا شما به کارمند خدمات خود مراجعه کنید.
Workbox همچنین پشتیبانی از نسخه‌سازی را ارائه می‌کند، به شما این امکان را می‌دهد که ورودی‌های ذخیره‌شده را به‌طور خودکار منقضی کنید ، یا زمانی که به‌روزرسانی ورودی‌های ذخیره‌شده قبلی رخ می‌دهد، برنامه وب خود را مطلع کنید.
کدام یک از دارایی های شما باید با کدام استراتژی ذخیره شود؟
کش در زمان اجرا را می توان به عنوان مکملی برای پیش کش در نظر گرفت. اگر همه دارایی‌های شما قبلاً در حال ذخیره‌سازی هستند، کار شما تمام شده است—هیچ چیزی در زمان اجرا نیاز به ذخیره‌سازی در حافظه پنهان وجود ندارد. این احتمال وجود دارد که برای هر برنامه وب نسبتاً پیچیده، شما همه چیز را پیش کش نکنید.
فایل‌های رسانه‌ای بزرگ‌تر، دارایی‌هایی که از یک میزبان شخص ثالث مانند CDN یا پاسخ‌های API ارائه می‌شوند، تنها نمونه‌هایی از انواع دارایی‌هایی هستند که نمی‌توانند به طور موثر پیش کش شوند. از پنل Network در DevTools برای شناسایی درخواست‌هایی که در این دسته قرار می‌گیرند استفاده کنید و برای هر یک از آنها، به این فکر کنید که چه معاوضی از تازگی در مقابل قابلیت اطمینان مناسب است.
از stale-while-revalidate برای اولویت دادن به قابلیت اطمینان بر تازگی استفاده کنید
از آنجایی که یک استراتژی کهنه در حالی که اعتبار مجدد دارد تقریباً بلافاصله یک پاسخ ذخیره شده در حافظه پنهان را برمی‌گرداند - پس از اینکه حافظه پنهان از طریق اولین درخواست پر شد - در نهایت هنگام استفاده از این استراتژی، عملکرد سریع قابل اعتمادی را مشاهده خواهید کرد. این با مبادله بازیابی داده های پاسخ است که می تواند در مقایسه با آنچه که از شبکه بازیابی می شود، کهنه باشد. استفاده از این استراتژی برای دارایی‌هایی مانند تصاویر نمایه کاربر یا پاسخ‌های اولیه API که برای پر کردن یک نما استفاده می‌شوند، بهترین کار را دارد، زمانی که می‌دانید نمایش فوری چیزی کلیدی است، حتی اگر مقدار قدیمی‌تری باشد.
ابتدا از شبکه برای اولویت دادن به تازگی بر قابلیت اطمینان استفاده کنید
به نوعی، استفاده از استراتژی شبکه اول اعتراف به شکست در نبرد شما در برابر شبکه است - اولویت داده شده است، اما عدم اطمینان در مورد قابلیت اطمینان را به همراه دارد. برای انواع خاصی از دارایی ها، دیدن یک پاسخ تازه به بازگرداندن اطلاعات قدیمی ارجحیت دارد. به عنوان مثال، ممکن است هنگام درخواست API برای متن مقاله ای که اغلب به روز می شود، تازگی را ترجیح دهید.
با استفاده از یک استراتژی شبکه اول در داخل یک سرویس دهنده، به جای اینکه مستقیماً در مقابل شبکه قرار بگیرید، از این مزیت برخوردار هستید که می توانید به چیزی بازگردید، حتی اگر یک پاسخ بالقوه قدیمی باشد. شما به طور قابل اعتماد سریع نخواهید بود، اما حداقل در حالت آفلاین قابل اعتماد خواهید بود.
از cache-first برای URL های نسخه شده استفاده کنید
در استراتژی cache-first، هنگامی که یک ورودی در حافظه پنهان ذخیره می شود، هرگز به روز نمی شود. به همین دلیل، مطمئن شوید که از آن فقط برای دارایی هایی استفاده می کنید که احتمال تغییر آن ها بعید است. به ویژه، برای URLهایی که حاوی اطلاعات نسخه‌سازی هستند بهترین کار را دارد - همان نوع URLهایی که باید با یک Cache-Control: max-age=31536000 هدر پاسخ.