‏حالا Worker می‌تونه کش مخصوص خودش رو داشته باشه

کلادفلر از Workers Cache رونمایی کرده؛ یه کش لایه‌ای (tiered cache) که جلوی Worker تو می‌شینه و به گفته نویسنده‌ها فقط با یه خط کانفیگ Wrangler و همون هدرهای Cache-Control که از قبل می‌شناسی پیکربندی می‌شه.

منطق کار ساده‌ست: وقتی Workers Cache فعاله، هر درخواست قابل‌کش اول به کش کلادفلر می‌خوره. اگه یه پاسخ تازه توی کش باشه، کلادفلر مستقیم برمی‌گردونتش و Worker تو اصلاً اجرا نمی‌شه، یعنی بابت زمان CPU پول نمی‌دی. اگه کش miss بشه، Worker اجرا می‌شه و اگه پاسخش قابل‌کش باشه، کلادفلر برای درخواست بعدی ذخیره‌اش می‌کنه؛ درخواست بعدی از هر جای دنیا می‌تونه مستقیم از کش سرو بشه.

فعال‌کردنش فقط یه بلوک کانفیگه:

{
  "name": "my-worker",
  "main": "src/index.ts",
  "cache": { "enabled": true }
}

بعد از اون، کش رو دقیقاً همون‌طوری که HTTP همیشه می‌خواسته کنترل می‌کنی: با ست‌کردن هدرهایی مثل Cache-Control و Cache-Tag روی پاسخ‌هات. وقتی محتوا عوض شد، خود Worker می‌تونه کش خودش رو با تگ purge کنه. به گفته نویسنده‌ها، کل API همینه؛ نه zone‌ای برای پیکربندی هست، نه موتور قوانینی، نه محصول دومی که بخوای واردش بشی.

نکته جالب اینه که کش دنبال Worker می‌ره، هر جا که اجرا بشه — روی دامنه سفارشی، روی workers.dev، پشت یه service binding، توی preview یا توی یه tenant از Workers for Platforms. یه Worker، یه کش، یه بار پیکربندی.

نویسنده‌ها می‌گن زیر این سطح ساده کلی چیز هست: کش لایه‌ای در سرتاسر شبکه کلادفلر، پشتیبانی کامل از stale-while-revalidate تا پاسخ‌های کهنه هیچ‌وقت جلوی کاربر رو نگیرن، مذاکره محتوا با Vary، کلیدهای کش امنِ چندمستأجری، و purge برنامه‌ریزی‌شده بر اساس تگ یا پیشوند مسیر.

نکات کلیدی:

• Workers Cache یه کش لایه‌ای جلوی Worker می‌ذاره که با یه خط کانفیگ فعال می‌شه
• روی کش hit، Worker اجرا نمی‌شه و بابت CPU هزینه‌ای نمی‌دی
• کنترل با همون هدرهای Cache-Control و Cache-Tag آشنا انجام می‌شه
• کش هر جا که Worker اجرا بشه دنبالش می‌ره (دامنه سفارشی، workers.dev، preview و...)
• پشتیبانی از stale-while-revalidate، Vary و purge بر اساس تگ یا مسیر