یک ابزار اضافی برای کمک به شما در ایجاد تعادل بین فوریت و تازگی در هنگام ارائه برنامه وب.
چه چیزی ارسال شد؟
stale-while-revalidate
به توسعه دهندگان کمک می کند تا بین بی واسطه بودن – بارگیری فوری محتوای ذخیره شده در حافظه پنهان – و تازگی – تعادل برقرار کنند تا اطمینان حاصل شود که به روز رسانی های محتوای کش شده در آینده استفاده می شود . اگر یک سرویس وب شخص ثالث یا کتابخانه دارید که طبق یک برنامه منظم بهروزرسانی میشود، یا داراییهای شخص اول شما عمر کوتاهی دارند، ممکن است stale-while-revalidate
به سیاستهای ذخیرهسازی موجود شما افزوده شود.
پشتیبانی از تنظیم stale-while-revalidate
در کنار max-age
در سرصفحه پاسخ Cache-Control
در Chrome 75 و Firefox 68 موجود است.
مرورگرهایی که از stale-while-revalidate
پشتیبانی نمیکنند، بیصدا این مقدار پیکربندی را نادیده میگیرند و max-age
استفاده میکنند، همانطور که به زودی توضیح خواهم داد…
یعنی چی؟
بیایید stale-while-revalidate
را به دو بخش تقسیم کنیم: این ایده که یک پاسخ ذخیره شده در حافظه پنهان ممکن است کهنه باشد، و فرآیند اعتبارسنجی مجدد.
ابتدا، چگونه مرورگر متوجه میشود که یک پاسخ ذخیره شده در حافظه پنهان «بیات» است؟ یک سرصفحه پاسخ Cache-Control
که حاوی stale-while-revalidate
است نیز باید حاوی max-age
باشد، و تعداد ثانیه های مشخص شده از طریق max-age
همان چیزی است که بیات بودن را تعیین می کند. هر پاسخ ذخیره شده جدیدتر از max-age
، تازه در نظر گرفته می شود و پاسخ های ذخیره شده قدیمی تر کهنه می شوند.
اگر پاسخ ذخیرهشده محلی هنوز تازه باشد، میتوان آن را همانطور که هست برای انجام درخواست مرورگر استفاده کرد. از منظر stale-while-revalidate
، در این سناریو کاری برای انجام دادن وجود ندارد.
اما اگر پاسخ ذخیره شده در حافظه پنهان قدیمی باشد، بررسی مبتنی بر سن دیگری انجام می شود: آیا سن پاسخ ذخیره شده در حافظه پنهان در پنجره زمانی اضافی توسط تنظیمات stale-while-revalidate
ارائه شده است؟
اگر سن یک پاسخ قدیمی در این پنجره قرار گیرد، از آن برای انجام درخواست مرورگر استفاده می شود. در همان زمان، درخواست "تأیید مجدد" علیه شبکه به گونه ای انجام می شود که استفاده از پاسخ ذخیره شده را به تاخیر نیندازد. پاسخ برگشتی ممکن است حاوی همان اطلاعاتی باشد که قبلاً در حافظه پنهان شده بود، یا ممکن است متفاوت باشد. در هر صورت، پاسخ شبکه به صورت محلی ذخیره میشود، هر آنچه که قبلاً حافظه پنهان بود جایگزین میشود، و تایمر «تازه» مورد استفاده در هر مقایسه max-age
آینده را بازنشانی میکند.
با این حال، اگر پاسخ ذخیره شده در حافظه پنهان به اندازه کافی قدیمی باشد که در خارج از پنجره زمان stale-while-revalidate
قرار گیرد، در این صورت درخواست مرورگر را برآورده نخواهد کرد. مرورگر در عوض پاسخی را از شبکه بازیابی می کند و از آن برای انجام درخواست اولیه و همچنین پر کردن حافظه پنهان محلی با یک پاسخ جدید استفاده می کند.
مثال زنده
در زیر یک مثال ساده از یک API HTTP برای برگرداندن زمان فعلی - به طور خاص تر، تعداد دقیقه های فعلی از ساعت گذشته است.
در این سناریو، وب سرور از این هدر Cache-Control
در پاسخ HTTP خود استفاده می کند:
Cache-Control: max-age=1, stale-while-revalidate=59
این تنظیم به این معنی است که، اگر درخواستی برای زمان در 1 ثانیه آینده تکرار شود، مقدار ذخیره شده قبلی همچنان تازه خواهد بود، و همانطور که هست بدون هیچ گونه اعتبارسنجی مجدد استفاده می شود.
اگر درخواستی بین 1 تا 60 ثانیه بعد تکرار شود، مقدار ذخیره شده در حافظه پنهان بیات می شود، اما برای انجام درخواست API استفاده می شود. در همان زمان، «در پسزمینه»، یک درخواست اعتبارسنجی مجدد برای پر کردن حافظه پنهان با یک مقدار جدید برای استفاده در آینده انجام میشود.
اگر درخواستی پس از بیش از 60 ثانیه تکرار شود، از پاسخ قدیمی به هیچ وجه استفاده نمی شود، و هم انجام درخواست مرورگر و هم اعتبار سنجی مجدد حافظه پنهان به دریافت پاسخ از شبکه بستگی دارد.
در اینجا یک تفکیک از این سه حالت متمایز، همراه با پنجره زمانی که در آن هر یک از آنها برای مثال ما اعمال می شود، آورده شده است:
موارد استفاده رایج چیست؟
در حالی که مثال بالا برای سرویس API "دقایقی بعد از ساعت" ساخته شده است، مورد استفاده مورد انتظار را نشان می دهد - خدماتی که اطلاعاتی را ارائه می دهند که باید به روز شوند، اما درجاتی از کهنگی قابل قبول است.
نمونه های کمتر ساخته شده ممکن است یک API برای شرایط آب و هوای فعلی یا سرفصل های برتر خبری باشد که در ساعت گذشته نوشته شده اند.
به طور کلی، هر پاسخی که در یک بازه زمانی مشخص بهروزرسانی میشود، احتمالاً چندین بار درخواست میشود، و در آن بازه ثابت است، کاندیدای خوبی برای ذخیرهسازی کوتاهمدت از طریق max-age
است. استفاده از stale-while-revalidate
علاوه بر max-age
این احتمال را افزایش می دهد که درخواست های آینده را می توان از حافظه پنهان با محتوای تازه تر، بدون مسدود کردن پاسخ شبکه، برآورده کرد.
چگونه با کارگران خدماتی تعامل دارد؟
اگر stale-while-revalidate
احتمال دارد که در چارچوب دستور العملهایی باشد که در یک سرویسدهنده استفاده میشود.
استفاده از stale-while-revalidate از طریق هدر Cache-Control
شباهت هایی با استفاده از آن در یک سرویس دهنده دارد و بسیاری از ملاحظات مشابه در مورد مبادلات تازگی و حداکثر طول عمر اعمال می شود. با این حال، چند نکته وجود دارد که باید هنگام تصمیمگیری در مورد پیادهسازی یک رویکرد مبتنی بر سرویسکار، یا فقط به پیکربندی هدر Cache-Control
در نظر بگیرید.
از رویکرد کارگر خدماتی استفاده کنید اگر…
- شما در حال حاضر از یک سرویس دهنده در برنامه وب خود استفاده می کنید.
- شما به کنترل دقیقی بر روی محتویات حافظه پنهان خود نیاز دارید و می خواهید چیزی مانند سیاست انقضا که اخیراً استفاده شده است را پیاده سازی کنید. ماژول انقضای حافظه پنهان Workbox می تواند در این مورد کمک کند.
- هنگامی که یک پاسخ قدیمی در پسزمینه در مرحله اعتبارسنجی مجدد تغییر میکند، میخواهید به شما اطلاع داده شود. ماژول Broadcast Cache Update Workbox می تواند در این مورد کمک کند.
- شما در همه مرورگرهای مدرن به این رفتار
stale-while-revalidate
نیاز دارید.
از یک رویکرد Cache-Control استفاده کنید اگر…
- شما ترجیح می دهید با هزینه های استقرار و نگهداری یک سرویس دهنده برای برنامه وب خود مقابله نکنید.
- شما با اجازه دادن به مدیریت خودکار حافظه پنهان مرورگر مانع از بزرگ شدن حافظه پنهان محلی شما می شوید.
- با رویکردی که در حال حاضر در همه مرورگرهای مدرن پشتیبانی نمیشود، خوب هستید (از ژوئیه 2019، پشتیبانی ممکن است در آینده افزایش یابد).
اگر از یک سرویسکار استفاده میکنید و همچنین برای برخی از پاسخها از طریق هدر Cache-Control
stale-while-revalidate
فعال کردهاید، در این صورت، سرویسکار، به طور کلی، در پاسخ به درخواست «اولین کرک» خواهد داشت. اگر سرویسکار تصمیم بگیرد که پاسخ ندهد، یا اگر در فرآیند تولید پاسخ با استفاده از fetch()
درخواست شبکه کند، رفتار پیکربندیشده از طریق هدر Cache-Control
در نهایت اعمال میشود.
بیشتر بدانید
- پاسخ
stale-while-revalidate
در مشخصات Fetch API. - RFC 5861 ، مشخصات اولیه
stale-while-revalidate
را پوشش می دهد. - حافظه پنهان HTTP: اولین خط دفاعی شما ، از راهنمای «قابلیت اطمینان شبکه» در این سایت.
تصویر قهرمان از ساموئل زلر.