رفتار حافظه پنهان را مدیریت کنید

Firebase Hosting از یک CDN جهانی قدرتمند برای افزایش سرعت سایت شما استفاده می‌کند.

هر محتوای استاتیک درخواستی به طور خودکار در CDN ذخیره می‌شود . اگر محتوای سایت خود را مجدداً مستقر کنید، Firebase Hosting به طور خودکار تمام محتوای ذخیره شده شما را در CDN تا درخواست بعدی پاک می‌کند.

با این حال، از آنجا که سرویس‌های Cloud Functions و Cloud Run محتوا را به صورت پویا تولید می‌کنند، محتوای یک URL مشخص می‌تواند بر اساس مواردی مانند ورودی کاربر یا هویت کاربر متفاوت باشد. برای در نظر گرفتن این موضوع، درخواست‌هایی که توسط کد backend مدیریت می‌شوند، به طور پیش‌فرض در CDN ذخیره نمی‌شوند .

با این حال، می‌توانید رفتار ذخیره‌سازی را برای محتوای پویا پیکربندی کنید . برای مثال، اگر یک تابع فقط به صورت دوره‌ای محتوای جدید تولید می‌کند، می‌توانید با ذخیره‌سازی محتوای تولید شده برای حداقل یک دوره زمانی کوتاه، سرعت برنامه خود را افزایش دهید.

شما می‌توانید به طور مشابه رفتار ذخیره‌سازی را پیکربندی کنید تا هزینه‌های اجرای تابع را به طور بالقوه کاهش دهید، زیرا محتوا از CDN به جای یک تابع فعال‌شده ارائه می‌شود. برای اطلاعات بیشتر در مورد بهینه‌سازی اجرای تابع و خدمات، به مستندات Cloud Functions و Cloud Run مراجعه کنید.

استثنا درخواست‌هایی هستند که خطای ۴۰۴ برمی‌گردانند. CDN پاسخ ۴۰۴ سرویس شما به یک URL ناموجود را به مدت ۱۰ دقیقه ذخیره می‌کند، به طوری که درخواست‌های بعدی برای آن URL از CDN ارائه می‌شوند. اگر سرویس خود را تغییر دهید تا محتوا اکنون در این URL وجود داشته باشد، CDN به ارائه هرگونه خطای ۴۰۴ ذخیره شده به مدت حداکثر ۱۰ دقیقه (حداکثر) ادامه می‌دهد و سپس محتوا را از آن URL به طور عادی ارائه می‌دهد.

اگر یک پاسخ ۴۰۴ از قبل حاوی هدرهای ذخیره‌سازی تنظیم‌شده توسط Cloud Functions یا سرویس Cloud Run شما باشد، آن‌ها پیش‌فرض ۱۰ دقیقه را لغو می‌کنند و رفتار ذخیره‌سازی CDN را به‌طور کامل تعیین می‌کنند.

برای کسب اطلاعات بیشتر در مورد رفتار ذخیره‌سازی در حافظه پنهان، به مستندات توسعه‌دهندگان وب گوگل مراجعه کنید.

تنظیم کنترل حافظه پنهان

ابزار اصلی که برای مدیریت حافظه پنهان برای محتوای پویا استفاده می‌کنید، هدر Cache-Control است. با پیکربندی این هدر، می‌توانید هم به مرورگر و هم به CDN اطلاع دهید که محتوای شما چه مدت می‌تواند ذخیره شود. در تابع خود، Cache-Control به این صورت تنظیم می‌کنید:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

در این مثال هدر، دستورالعمل‌ها سه کار انجام می‌دهند:

• public - پاسخ را به صورت public علامت‌گذاری می‌کند. این بدان معناست که هم مرورگر و هم حافظه‌های پنهان میانی (از جمله CDN برای Firebase Hosting ) می‌توانند محتوا را ذخیره کنند.

• max-age — تعیین می‌کند که یک پاسخ چند ثانیه می‌تواند قدیمی باشد تا دوباره با سرور مبدا اعتبارسنجی شود. این در مورد مرورگرها صدق می‌کند؛ اگر هدر s-maxage وجود نداشته باشد، در مورد همه حافظه‌های پنهان دیگر (از جمله CDN) نیز صدق می‌کند.

• s-maxage — دستورالعمل max-age را برای حافظه‌های پنهان مشترک (مانند CDN) لغو می‌کند. وقتی CDN پاسخی قدیمی‌تر از s-maxage ثانیه پیدا کند، CDN آن را با سرور مبدا مجدداً اعتبارسنجی می‌کند. در هدر مثال، مرورگرها می‌توانند پاسخ را به مدت ۵ دقیقه ذخیره کنند، اما CDN و هر حافظه پنهان میانی دیگری می‌توانند آن را به مدت ۱۰ دقیقه ذخیره کنند.

برای max-age و s-maxage ، مقادیر آنها را روی طولانی‌ترین مدت زمانی که با دریافت محتوای قدیمی توسط کاربران مشکلی ندارید، تنظیم کنید. اگر صفحه‌ای هر چند ثانیه تغییر می‌کند، از مقدار زمانی کوچکی استفاده کنید. با این حال، انواع دیگر محتوا را می‌توان با خیال راحت برای ساعت‌ها، روزها یا حتی ماه‌ها ذخیره کرد.

اگر می‌خواهید از ذخیره سازی به طور کامل جلوگیری کنید (برای مثال، همیشه جدیدترین نسخه محتوای استاتیک را ارائه دهید)، می‌توانید این کار را در firebase.json با استفاده از تنظیمات headers پیکربندی کنید:

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

می‌توانید اطلاعات بیشتری در مورد هدر Cache-Control را در شبکه توسعه‌دهندگان موزیلا و مستندات توسعه‌دهندگان وب گوگل کسب کنید.

محتوای ذخیره شده چه زمانی ارائه می‌شود؟

مرورگر و CDN محتوای شما را بر اساس موارد زیر ذخیره می‌کنند:

• نام میزبان
• مسیر
• رشته پرس و جو
• محتوای هدرهای درخواست مشخص شده در هدر Vary

هدرهای متنوع

هدر Vary تعیین می‌کند که کدام هدرهای درخواست باید برای ارائه پاسخ مناسب استفاده شوند (آیا محتوای ذخیره شده معتبر است یا اینکه محتوا باید با سرور مبدا مجدداً اعتبارسنجی شود).

Firebase Hosting به طور خودکار یک هدر Vary مناسب را برای موقعیت‌های رایج روی پاسخ شما تنظیم می‌کند. اغلب اوقات، نیازی نیست نگران هدر Vary باشید. با این حال، در برخی موارد استفاده پیشرفته، ممکن است هدرهای دیگری داشته باشید که برای تأثیرگذاری روی حافظه پنهان نیاز دارید. در این صورت، می‌توانید هدر Vary را روی پاسخ خود تنظیم کنید. به عنوان مثال:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

در این حالت، مقدار هدر Vary برابر است با:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

با این تنظیمات، دو درخواست کاملاً یکسان با هدرهای X-My-Custom-Header متفاوت، جداگانه ذخیره می‌شوند. توجه داشته باشید که Hosting به طور پیش‌فرض، وقتی درخواستی برای محتوای پویا ارسال می‌شود، Cookie و Authorization به هدر Vary اضافه می‌کند. این تضمین می‌کند که هر هدر مجوز جلسه یا کوکی که استفاده می‌کنید، بخشی از کلید ذخیره سازی باشد که از نشت تصادفی محتوا جلوگیری می‌کند.

همچنین توجه داشته باشید:

• فقط درخواست‌های GET و HEAD می‌توانند ذخیره شوند. درخواست‌های HTTPS که از روش‌های دیگر استفاده می‌کنند، هرگز ذخیره نمی‌شوند.

• هنگام اضافه کردن تنظیمات به هدر Vary مراقب باشید. هرچه تنظیمات بیشتری اضافه کنید، احتمال اینکه CDN بتواند محتوای ذخیره شده را ارائه دهد، کمتر می‌شود. همچنین به یاد داشته باشید که Vary بر اساس هدرهای درخواست است، نه هدرهای پاسخ .

استفاده از کوکی‌ها

هنگام استفاده از Firebase Hosting به همراه Cloud Functions یا Cloud Run ، کوکی‌ها معمولاً از درخواست‌های ورودی حذف می‌شوند. این کار برای عملکرد کارآمد حافظه پنهان CDN ضروری است. فقط کوکی با نام خاص __session مجاز به عبور از اجرای برنامه شما است.

در صورت وجود، کوکی __session به طور خودکار بخشی از کلید حافظه پنهان می‌شود، به این معنی که برای دو کاربر با کوکی‌های مختلف غیرممکن است که پاسخ ذخیره شده دیگری را دریافت کنند. فقط در صورتی از کوکی __session استفاده کنید که برنامه شما بسته به مجوز کاربر، محتوای متفاوتی را ارائه می‌دهد.