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

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

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

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

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

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

استثنا درخواست هایی است که خطاهای 404 را برمی گرداند. CDN پاسخ 404 سرویس شما به یک URL موجود را به مدت 10 دقیقه در حافظه پنهان نگه می دارد، به طوری که درخواست های بعدی برای آن URL از CDN ارائه می شود. اگر سرویس خود را طوری تغییر دهید که محتوا اکنون در این URL وجود داشته باشد، CDN به ارائه 404 های کش شده به مدت 10 دقیقه (حداکثر) ادامه می دهد و سپس محتوا را از آن URL به طور معمول ارائه می دهد.

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

در اسناد برنامه‌نویس وب Google درباره رفتار ذخیره‌سازی در حافظه پنهان بیشتر بدانید.

Cache-Control را تنظیم کنید

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

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

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

• public - کش را به عنوان public علامت گذاری می کند. این بدان معنی است که هم مرورگر و هم سرورهای میانی (به معنای CDN برای Firebase Hosting ) می توانند محتوا را کش کنند.

  توجه: به طور پیش فرض، Cache-Control روی private تنظیم شده است. این بدان معنی است که اگر به طور صریح Cache-Control روی public تنظیم نکنید، فقط مرورگر کاربر درخواست کننده مجاز است محتوا را کش کند.

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

• s-maxage - دستور max-age را فقط برای حافظه پنهان CDN لغو می کند. به CDN می گوید که چند ثانیه می تواند محتوا را کش کند. هنگامی که زمان تعیین شده منقضی می شود، CDN باید محتوا را با سرور مبدا تأیید مجدد کند. در هدر مثال، ما تنظیمات max-age را فقط برای CDN لغو می‌کنیم و به CDN اجازه می‌دهیم محتوا را به مدت ده دقیقه کش کند.

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

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

محتوای کش چه زمانی ارائه می شود؟

مرورگر و 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 استفاده کنید که برنامه شما بسته به مجوز کاربر، محتوای متفاوتی را ارائه دهد.