Firebase Hosting از یک CDN جهانی قدرتمند برای افزایش سرعت سایت شما استفاده میکند.
Any requested static content is automatically cached on the CDN . If you redeploy your site's content, Firebase Hosting automatically clears all your cached content across the CDN until the next request.
با این حال، از آنجا که سرویسهای Cloud Functions و Cloud Run محتوا را به صورت پویا تولید میکنند، محتوای یک URL مشخص میتواند بر اساس مواردی مانند ورودی کاربر یا هویت کاربر متفاوت باشد. برای در نظر گرفتن این موضوع، درخواستهایی که توسط کد backend مدیریت میشوند، به طور پیشفرض در CDN ذخیره نمیشوند .
با این حال، میتوانید رفتار ذخیرهسازی را برای محتوای پویا پیکربندی کنید . برای مثال، اگر یک تابع فقط به صورت دورهای محتوای جدید تولید میکند، میتوانید با ذخیرهسازی محتوای تولید شده برای حداقل یک دوره زمانی کوتاه، سرعت برنامه خود را افزایش دهید.
شما میتوانید به طور مشابه رفتار ذخیرهسازی را پیکربندی کنید تا هزینههای اجرای تابع را به طور بالقوه کاهش دهید، زیرا محتوا از CDN به جای یک تابع فعالشده ارائه میشود. برای اطلاعات بیشتر در مورد بهینهسازی اجرای تابع و خدمات، به مستندات Cloud Functions و Cloud Run مراجعه کنید.
استثنا درخواستهایی هستند که خطای ۴۰۴ برمیگردانند. CDN پاسخ ۴۰۴ سرویس شما به یک URL ناموجود را به مدت ۱۰ دقیقه ذخیره میکند، به طوری که درخواستهای بعدی برای آن URL از CDN ارائه میشوند. اگر سرویس خود را تغییر دهید تا محتوا اکنون در این URL وجود داشته باشد، CDN به ارائه هرگونه خطای ۴۰۴ ذخیره شده به مدت حداکثر ۱۰ دقیقه (حداکثر) ادامه میدهد و سپس محتوا را از آن URL به طور عادی ارائه میدهد.
If a 404 response already contains caching headers set by your Cloud Functions or Cloud Run service, they override the default of 10 minutes and fully determine the caching behavior of the 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 automatically sets an appropriate Vary header on your response for common situations. Most of the time, you don't need to worry about the Vary header. However, in some advanced use cases, you might have other headers that you need to affect the cache. When that's the case, you can set the Vary header on your response. For example:
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 که از روشهای دیگر استفاده میکنند، هرگز ذخیره نمیشوند.Be careful when adding settings to the
Varyheader. The more settings that you add, the less likely it is that the CDN can serve cached content. Also remember thatVaryis based on request headers, not response headers.
استفاده از کوکیها
هنگام استفاده از Firebase Hosting به همراه Cloud Functions یا Cloud Run ، کوکیها معمولاً از درخواستهای ورودی حذف میشوند. این کار برای عملکرد کارآمد حافظه پنهان CDN ضروری است. فقط کوکی با نام خاص __session مجاز به عبور از اجرای برنامه شما است.
در صورت وجود، کوکی __session به طور خودکار بخشی از کلید حافظه پنهان میشود، به این معنی که برای دو کاربر با کوکیهای مختلف غیرممکن است که پاسخ ذخیره شده دیگری را دریافت کنند. فقط در صورتی از کوکی __session استفاده کنید که برنامه شما بسته به مجوز کاربر، محتوای متفاوتی را ارائه میدهد.