تازه نگه داشتن چیزها با قدیمی-در حالی که- اعتبار مجدد

یک ابزار اضافی برای کمک به شما در ایجاد تعادل بین فوریت و تازگی در هنگام ارائه برنامه وب.

جف پوسنیک

چه چیزی ارسال شد؟

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 در نهایت اعمال می‌شود.

بیشتر بدانید

تصویر قهرمان از ساموئل زلر.