«حذف بازسازی کامل سایت»؛ دستاورد جدید لایه‌ی حافظه پنهان در لبه

اگر برای هر بازدید کاربر از صفحات پویا، هزینه پردازش CPU می‌پردازید، زمان آن رسیده است که معماری خود را تغییر دهید. در تاریخ ۶ ژوئیه ۲۰۲۶، کلاودفلر ابزار Workers Cache را عرضه کرد؛ یک لایه‌ی حافظه پنهان لایه‌بندی شده (Tiered Caching) که در صورت وجود یک پاسخ به‌روز، از اجرای کامل کد شما جلوگیری می‌کند. طبق اعلام کلاودفلر در وبلاگ مهندسی این شرکت، این قابلیت معماری را به گونه‌ای تغییر می‌دهد که حافظه پنهان (Cache) به جای قرارگیری در پشتِ Worker، دقیقاً در مقابل آن قرار می‌گیرد. این تغییر استراتژیک به شما اجازه می‌دهد صفحات را با هزینه پردازش CPU صفر (Zero CPU Cost) سرو کنید.

برای سال‌ها، مدل رایانش لبه (Edge Computing) بر این فرض استوار بود که Workerها صرفاً واسطه‌هایی هستند که درخواست‌ها را پیش از رسیدن به سرور اصلی (Origin) تغییر می‌دهند یا تبدیل می‌کنند. اما با تکامل فریم‌ورک‌هایی مثل Next.js، Remix، SvelteKit، Astro و TanStack Start، خودِ Worker به سرور اصلی تبدیل شد. در این ساختار، هر درخواست منفرد باعث اجرای کامل کد می‌شد. این موضوع یک «مالیات عملکردی» در قالب تأخیر (Latency) و صورت‌حساب پردازش CPU ایجاد می‌کرد، حتی زمانی که محتوا برای همه کاربران کاملاً یکسان بود.

چرخش در معماری

Workers Cache تضاد میان تولید سایت استاتیک (SSG) و رندرینگ آنی (On-demand rendering) را از بین می‌برد. در روش سنتی SSG، سرعت بارگذاری بسیار بالا بود اما هر تغییر کوچک در محتوا، بازسازی کامل سایت را می‌طلبید که فرآیندی بسیار کند بود. برای یک سایت مستندات با چند هزار صفحه، این عملیات بیلد می‌توانست ۵ تا ۱۰ دقیقه زمان ببرد؛ برای سایت‌های بزرگ تجارت الکترونیک، وضعیت حتی بدتر بود و هر بار که هر تغییری ایجاد می‌شد، کل فرآیند بیلد باید از ابتدا اجرا می‌گردد.

در مقابل، رندرینگ در لحظه (On-demand) محتوا را همواره تازه نگه می‌داشت، اما هر بازدیدکننده را مجبور می‌کرد هزینه پردازشی رندر و تأخیر شبکه را بپردازد. رویکرد جدید کلاودفلر اجازه می‌دهد رندرینگ در لحظه انجام شود و سپس نتیجه در سطح جهانی کش شود. در این مدل، اولین درخواست باعث تحریک رندر می‌شود و هر درخواست بعدی، تا زمان انقضای حافظه، دقیقاً به عنوان یک دارایی استاتیک (Static Asset) سرو می‌شود.

این سازوکار، ماشینات پیچیده و خاص هر فریم‌ورک مانند بازسازی استاتیک افزایشی (ISR) را با استانداردهای ساده‌ی کشینگ HTTP جایگزین می‌کند. نتیجه نهایی، دسترسی به سرعت یک سایت استاتیک بدون تحمل زمان بیلد طولانی، و تازگی رندرینگ سرور بدون پرداخت هزینه‌های تکراری پردازش است.

پیکربندی و راه‌اندازی

راه‌اندازی Workers Cache برای مینیمالیسم طراحی شده است تا هیچ اصطکاکی برای توسعه‌دهنده ایجاد نکند. این قابلیت تنها با افزودن یک بلوک ساده در فایل تنظیمات wrangler.jsonc (یا wrangler.toml) فعال می‌شود. یک پیکربندی نمونه به این شکل است:

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

پس از فعال‌سازی، کدِ Worker به سطح پیکربندی تبدیل می‌شود. توسعه‌دهندگان کنترل کش را با استفاده از همان هدرهای Cache-Control که پیش‌تر می‌شناختند و با آن‌ها آشنا هستند، انجام می‌دهند. برای مثال، یک پاسخ می‌تواند با هدرهای زیر بازگردانده شود:

return new Response(body, { headers: { "Cache-Control": "public, max-age=300, stale-while-revalidate=3600", "Cache-Tag": "products,product:123", }, });

در این مدل، هیچ ناحیه (Zone) جداگانه‌ای برای پیکربندی وجود ندارد، نیازی به تنظیم موتور قوانین (Rules Engine) نیست و کاربر مجبور نیست وارد پنل محصول دوم شود. حافظه پنهان، Worker را در تمام محیط‌ها دنبال می‌کند: در دامنه‌های سفارشی، دامنه‌های workers.dev، پیوندهای سرویس (Service Bindings)، محیط‌های پیش‌نمایش (Previews) و حتی در مستاجران Workers for Platforms.

سازوکار Stale-While-Revalidate

نقطه کلیدی این تجربه، دستور stale-while-revalidate است. این قابلیت به کلاودفلر اجازه می‌دهد پاسخی که کمی قدیمی شده را فوراً به کاربر بدهد (به جای اینکه کاربر منتظر رندر بماند) و هم‌زمان در پس‌زمینه، Worker را برای به‌روزرسانی محتوا اجرا کند. کلاودفلر پشتیبانی کامل از این دستور را در اوایل سال جاری عرضه کرد تا سایت‌های کش‌شده حسی کاملاً شبیه به سایت‌های استاتیک داشته باشند.

بر اساس تحلیل‌های مهندسی، این فرآیند سه پنجره زمانی مجزا دارد:

• پنجره تازه (max-age): پاسخ از حافظه سرو می‌شود؛ در این حالت Worker اصلاً اجرا نمی‌شود و هزینه CPU صفر است.
• پنجره قدیمی (stale-while-revalidate): پاسخ قدیمی (stale) فوراً با هدر Cf-Cache-Status: UPDATING سرو شده و Worker در پس‌زمینه برای به‌روزرسانی کش اجرا می‌شود. در این حالت هیچ کاربری منتظر نمی‌ماند و تأخیری حس نمی‌کند.
• پنجره منقضی: پاسخ کاملاً منقضی شده است؛ در این حالت Worker اجرا می‌شود و کاربر باید منتظر رندر جدید بماند.

برای مثال، در یک کاتالوگ محصول، تنظیماتی مانند max-age=300, stale-while-revalidate=3600 تضمین می‌کند که بازدیدکنندگان تقریباً هرگز منتظر نمانند، در حالی که Worker هنوز به اندازه کافی اجرا می‌شود تا محتوا تازه باقی بماند. برای یک آرشیو وبلاگ، تنظیماتی مثل max-age=86400, stale-while-revalidate=2592000 به این معناست که Worker برای هر صفحه تنها یک بار در روز اجرا می‌شود و بقیه درخواست‌ها از کش پاسخ می‌گیرند.

توزیع جهانی و حافظه لایه‌بندی‌شده

کلاودفلر برای به حداکشدن نرخ اصابت (Hit Ratio)، یک سامانه دو لایه (Two-tier system) را به‌صورت پیش‌فرض پیاده کرد. این توپولوژی به‌طور خودکار روی هر Workerی که کش فعال دارد اعمال می‌شود و هیچ نیازی به پیکربندی دستی توسط کاربر ندارد. این ساختار دقیقاً مشابه توپولوژی Tiered Cache است که در حال حاضر برای Zoneها استفاده می‌شود.

• لایه پایین (Lower Tier): در نزدیک‌ترین مرکز داده کلاودفلر به کاربر قرار دارد. هر مرکز داده‌ای که ترافیکی برای Worker دریافت می‌کند، کش لایه پایین مخصوص خود را دارد.
• لایه بالا (Upper Tier): یک لایه تجمیعی است که با کل شبکه مشورت می‌کند. تعداد این لایه‌ها کمتر است و لایه‌های پایین در صورت نبود پاسخ (Miss)، ابتدا به اینجا مراجعه می‌کنند.

اگر در لایه پایین پاسخی یافت نشود، ابتدا لایه بالا چک می‌شود و تنها در صورتی که هر دو لایه Miss شوند، Worker فراخوانی می‌گردد. از آنجا که اولین درخواست در هر نقطه از جهان، لایه بالا را پر می‌کند، هر درخواست بعدی از هر مرکز داده دیگر می‌تواند از لایه بالا سرو شود. این موضوع نرخ اصابت را در مقایسه با یک لایه کش تخت (Flat)، به‌شدت افزایش می‌دهد.

این سیستم با Smart Placement ترکیب می‌شود: ابتدا لایه‌های کش بررسی می‌شوند و تنها در صورتی که هر دو لایه Miss شوند، Smart Placement اجرای کد را به نزدیک‌ترین نقطه به سرور اصلی (Origin) هدایت می‌کند تا تأخیر داده‌ها به حداقل برسد.

ترکیب پیشرفته و چندمستاجری

یکی از مهم‌ترین دستاوردها این است که حافظه اکنون به نقطه ورود (Entrypoint) متصل است، نه به Zone. این سیستم قوانین کش سطح Zone، Page Rules و لیست پسوندهای فایل را کاملاً نادیده می‌گیرد. حافظه پنهان هر کجا که Worker اجرا شود، آن را دنبال می‌کند؛ خواه در یک دامنه سفارشی باشد، خواه در workers.dev یا در یک پیش‌نمایش (که هر پیش‌نمایش کش ایزوله خود را دارد) و یا در یک مستاجر Workers for Platforms (که هر Worker کاربر یک کش کاملاً جداگانه دارد).

این قابلیت به توسعه‌دهندگان اجازه می‌دهد Workerها را با استفاده از Service Bindings به صورت زنجیره‌ای متصل کنند و کش را به عنوان یک درز (Seam) بین آن‌ها قرار دهند. یک معماری را می‌توان به دو بخش مجزا تقسیم کرد:

• Worker A (نزدیک کاربر): احراز هویت، محدودیت نرخ (Rate Limiting)، مسیریابی و رندر کردن پوسته خارجی HTML را مدیریت می‌کند. این Worker در فاصله ۵۰ میلی‌ثانیه‌ای ۹۵٪ کاربران جهان اجرا می‌شود.
• Worker B (نزدیک داده): از Smart Placement یا Placement Hints استفاده می‌کند تا در نزدیکی پایگاه داده برای انجام تبدیل‌های سنگین و واکشی داده‌ها اجرا شود.

چون کش در مقابل Worker B قرار دارد، هزینه دسترسی به داده‌ها و اجرای کد فقط در صورت Cache Miss پرداخت می‌شود. مسیر درخواست به این شکل می‌شود: کاربر ← Worker A ← اصابت کش برای Worker B ← پاسخ.

برای حل چالش کش کردن داده‌های احراز شده (Authenticated Data)، کلاودفلر قابلیت ctx.props را معرفی کرد. با گنجاندن شناسه کاربر یا مستاجر در کلید کش از طریق ctx.props فراخوان، سیستم تضمین می‌کند که کاربر A هرگز پاسخ کش‌شده‌ی کاربر B را نبیند و امنیت داده‌ها حفظ شود.

در جزئیات پیاده‌سازی امنیتی چندمستاجری، الگوی رایج به این صورت است:

• احراز هویت درگاه (Gateway Authentication): یک Worker درگاه ابتدا درخواست را احراز هویت کرده و صحت آن را می‌سنجد.
• حذف هدر (Header Stripping): هدر Authorization حذف می‌شود تا جلوی بای‌پس (Bypass) خودکار کلاودفلر (که معمولاً در حضور این هدر کش را نادیده می‌گیرد) گرفته شود.
• انتقال هویت (Identity Passing): شناسه کاربر احراز شده به ctx.props برای Worker بک‌اند پاس داده می‌شود.
• کلیدهای ایزوله (Isolated Keys): بک‌اند از this.ctx.props.userId برای بارگذاری داده‌ها استفاده کرده و هدر Cache-Control: public را تنظیم می‌کند. چون ctx.props بخشی از کلید کش است، فراخوانی‌هایی با Props متفاوت، ورودی‌های کش جداگانه‌ای دریافت می‌کنند.

این مدل، APIهای احراز شده را از وضعیت «غیر قابل کش»، به «کش‌شده به‌ازای هر کاربر با امنیت کامل» تبدیل می‌کند و مرزهای دسترسی را در عین حفظ عملکرد لبه، حفظ می‌کند. این مدل تضمین می‌کند که فراخوان‌هایی با ویژگی‌های متفاوت، ورودی‌های کش مجزایی داشته باشند و پاسخ یک کاربر هرگز به کاربر دیگر نشت نکند.

کنترل برنامه‌ریزی‌شده و ادغام

توسعه‌دهندگان کنترل کش را با استفاده از هدرهای استاندارد HTTP انجام می‌دهند. هدر Vary اجازه می‌دهد یک URL واحد، چندین نسخه کش‌شده برای ترکیب‌های مختلف هدرهای درخواست ذخیره کند.

برای مثال، یک Worker می‌تواند Vary: Accept را برگرداند تا برای مرورگرهای پشتیبانی‌کننده تصویر WebP و برای سایرین JPEG سرو کند. هر دو نسخه به‌طور جداگانه کش شده و بدون اجرای مجدد Worker سرو می‌شوند. این رفتار کاملاً از استانداردهای RFC 9110 و 9111 پیروی می‌کند و هیچ لیست سفید محدودی برای هدرها وجود ندارد. تنها مقدار Vary: * باعث غیرفعال شدن کامل کش می‌شود.

پاک‌سازی (Purging) به‌صورت برنامه‌ریزی شده از طریق دستور await ctx.cache.purge({ tags: ["product:123"] }) یا استفاده از پیشوندهای مسیر انجام می‌شود. این به Workerها اجازه می‌دهد در لحظه تغییر داده، حافظه خود را ابطال کنند. پاک‌سازی‌ها محدود به نقطه ورود Worker هستند؛ یعنی purgeEverything: true تنها کش آن نقطه ورود خاص را پاک می‌کند و تأثیری روی کل Zone ندارد.

فریم‌ورک Astro پیش از این این قابلیت را از طریق تامین‌کننده cacheCloudflare ادغام کرده است. در فایل astro.config.mjs توسعه‌دهندگان می‌توانند routeRules را با پارامترهای maxAge، swr و tags تعریف کنند (مثلاً برای مسیر /products/* با maxAge: 300 و تگ products). سپس اแดپتور مربوطه هدرها را مدیریت کرده، مقادیر Cache-Tag را برای ابطال متصل می‌کند و یک تابع کمکی cache.invalidate() برای مدیریت کش ارائه می‌دهد.

کنترل در سطح نقطه ورود

Workers Cache در مقابل هر نقطه ورود (Entrypoint) قرار می‌گیرد: خروجی پیش‌فرض (Default Export)، کلاس‌های نام‌گذاری شده WorkerEntrypoint و فراخوانی‌های ctx.exports. این امر اجازه می‌دهد یک Worker به عنوان زنجیره‌ای پیچیده از واحدهای ذخیره‌شده (Memoized) عمل کند.

با استفاده از نقشه exports در wrangler.jsonc توسعه‌دهندگان می‌توانند کش را برای هر نقطه ورود به صورت مجزا فعال یا غیرفعال کنند:

• نقطه ورود درگاه (Gateway): تنظیم cache: { enabled: false } تا احراز هویت و مسیریابی همیشه اجرا شوند و هیچ پاسخی کش نشوند.
• نقطه ورود بک‌اند (Backend): تنظیم cache: { enabled: true } برای ذخیره‌سازی نتایج خواندن‌های سنگین داده.

این ساختار الگوهای پیشرفته زیر را ممکن می‌سازد:

• کشینگ Durable Objects: قرار دادن یک DO پشت یک نقطه ورود به‌طوری که در صورت اصابت کش، درخواست‌ها دیگر به DO دسترسی نداشته باشند، در حالی که عملیات نوشتن، کش را از طریق تگ پاک می‌کند. در این حالت DO از وجود لایه کش بی‌اطلاع می‌ماند.
• نرمال‌سازی هدر: یک نقطه ورود بیرونی رمزگذاری اصلی را از request.cf.clientAcceptEncoding بازیابی کرده و سپس به نقطه ورود کش‌شده‌ای می‌فرستد که روی مقدار واقعی Vary می‌کند.
• یکسان‌سازی URL: حذف پارامترهای ردیابی اضافی (مانند ?utm_source=...) در نقطه ورود بیرونی یا استفاده از cf.cacheKey در فراخوانی ctx.exports تا نقطه ورود کش‌شده داخلی فقط یک فرم کانونی (Canonical) واحد را ببیند و نرخ اصابت کش افزایش یابد.

مدل هزینه‌ای و نظارت

مدل صورت‌حساب کلاودفلر هزینه CPU را برای اصابت‌های کش (Cache Hits) به‌طور کامل حذف می‌کند. در حالی که نرخ استاندارد درخواست‌ها همچنان اعمال می‌شود، زمان CPU صفر محاسبه می‌گردد و اصابت‌ها را بسیار ارزان‌تر از رندرهای کامل می‌کند.

نکته مهم: درخواست‌هایی که پیش از این رایگان بودند (مانند دارایی‌های استاتیک و فراخوانی‌های Worker-to-Worker)، اکنون با نرخ استاندارد درخواست محاسبه می‌شوند، زیرا برای پاسخگویی باید با حافظه کش مشورت کنند. با این حال، هیچ SKU جداگانه‌ای برای Workers Cache تعریف نشده و هیچ هزینه ذخیره‌سازی به‌ازای هر گیگابایت وجود ندارد.

قابلیت نظارت (Observability) در داشبورد Workers ادغام شده و نرخ اصابت کش و تفکیک دقیق Hits، Misses، Updates و Bypasses را نمایش می‌دهد. این به توسعه‌دهندگان کمک می‌کند تشخیص دهند آیا نرخ اصابت پایین به دلیل پاسخ‌های BYPASS (به دلیل وجود کوکی‌ها)، پاسخ‌های MISS (به دلیل تقسیم‌بندی بیش از حد کلید کش) یا پاسخ‌های UPDATING (به دلیل بازه‌های بسیار کوتاه max-age) است.

تغییر در رقابت

این پیشرفت، فرض بنیادی توابع بدون سرور در لبه را تغییر می‌دهد. با جاسازی کش درون واحد استقرار (Deployable Unit) به جای یک لایه شبکه جداگانه، کلاودفلر اجازه می‌دهد با کش به عنوان بخشی برنامه‌ریزی‌پذیر از منطق اپلیکیشن برخورد شود.

این سیستم در واقع CDN را به یک لایه ذخیره‌ساز (Memoization Layer) برای توابع توزیع‌شده تبدیل می‌کند. توانایی فعال‌سازی انتخابی کش در سطح هر نقطه ورود در یک استقرار واحد—که همگی از طریق یک خط در تنظیمات Wrangler و هدرهای استاندارد پیکربندی می‌شوند—قابلیتی است که در حال حاضر توسط سایر ارائه‌دهندگان بزرگ ابری ارائه نشده است.

نسخه‌های آینده

کلاودفلر در حال حاضر روی چندین بهبود کلیدی کار می‌کند:

• هم‌مکانی (Co-location) هوشمندتر: هماهنگ کردن کش لایه بالا و هدف Smart Placement برای اطمینان از اینکه یک Miss کامل تنها نیاز به یک سفر طولانی‌مدت داده داشته باشد، نه دو سفر مجزا.
• محدودیت‌های پاسخ: عبور از محدودیت فعلی ۵۱۲ مگابایت در زمان عرضه (که محدودیت پلن رایگان است) و اعمال محدودیت‌های کش استاندارد بر اساس سطح هر پلن.
• فریم‌ورک‌ها: افزودن ادغام‌های جدید برای TanStack Start و Next.js (از طریق Vinext).
• API ابطال: توسعه ctx.cache.invalidate() برای علامت‌گذاری پاسخ‌ها به عنوان «منقضی‌شده» به جای حذف کامل آن‌ها، تا stale-while-revalidate همچنان بتواند یک پاسخ قدیمی سریع را در حین به‌روزرسانی ارائه دهد.

گام بعدی شما

• اگر از Astro استفاده می‌کنید، همین امروز cacheCloudflare را برای کاهش هزینه‌های CPU تست کنید.
• استراتژی هدرهای Cache-Control خود را بازبینی کنید تا از stale-while-revalidate برای حذف تأخیر کاربر بهره ببرید.
• نقاط ورود Workerهای خود را تفکیک کنید تا فقط بخش‌های سنگین داده را کش کنید و احراز هویت را باز بگذارید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.