ऐप्लिकेशन का कॉन्टेंट कैश करना

Cloud CDN, आपके वेब ऐप्लिकेशन के लिए App Hosting की सहायता का एक अहम हिस्सा है. आपके बैकएंड पर किया जाने वाला हर अनुरोध, पहले Cloud CDN से होकर गुज़रता है. सीडीएन में पहले से कैश मेमोरी में सेव किया गया कॉन्टेंट, उपयोगकर्ता को तुरंत वापस भेज दिया जाता है. इससे, आपके वेब ऐप्लिकेशन के सर्वर कोड को चलाने वाली Cloud Run सेवा को स्किप कर दिया जाता है. web.dev पर जाकर, सीडीएन के सामान्य फ़ायदों के बारे में ज़्यादा जानें.

Cloud CDN का बुनियादी कॉन्फ़िगरेशन App Hosting सेट करता है. इसे बदला नहीं जा सकता. हालांकि, कैश मेमोरी को ऑप्टिमाइज़ करने के लिए कई काम किए जा सकते हैं. इससे पेज लोड होने की स्पीड बढ़ाई जा सकती है, कैश मेमोरी में सेव न किए गए कॉन्टेंट के लिए बिल कम किया जा सकता है, और Cloud Run पर ट्रैफ़िक कम किया जा सकता है.

कैश मेमोरी में सेव किया जा सकने वाला कॉन्टेंट

Cloud CDN, कैश मेमोरी में जवाब तब सेव करता है, जब यहां दी गई सभी शर्तें पूरी होती हैं:

  1. अनुरोध, GET है

  2. जवाब में 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 या 501 का स्टेटस कोड है.

  3. रिस्पॉन्स में Cache-Control हेडर के साथ max-age या s-maxage डायरेक्टिव हो या Expires हेडर के साथ आने वाले समय का टाइमस्टैंप हो.

  4. रिस्पॉन्स में Age हेडर या Cache-Control हेडर के साथ साफ़ तौर पर public डायरेक्टिव मौजूद हो.

  5. जवाब का साइज़ 10 MiB या इससे कम हो.

साथ ही, इनमें से कोई भी बात सही नहीं है:

  1. जवाब में Set-Cookie हेडर है

  2. जवाब में Vary हेडर है. इसकी वैल्यू Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin, RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch या Next-Url नहीं है.

  3. रिस्पॉन्स में Cache-Control हेडर के साथ no-store या private डायरेक्टिव मौजूद हो.

  4. अनुरोध में no-store डायरेक्टिव वाला Cache-Control हेडर है.

  5. अनुरोध में Authorization हेडर होता है. हालांकि, अगर रिस्पॉन्स में साफ़ तौर पर कैश मेमोरी कंट्रोल करने का डायरेक्टिव मौजूद है, तो ऐसा नहीं होता.

कैश मेमोरी कंट्रोल करने वाले डायरेक्टिव की मदद से, कैश मेमोरी के व्यवहार को पसंद के मुताबिक बनाना

Next.js

Next.js, कई फ़ैक्टर के आधार पर, कैश मेमोरी को कंट्रोल करने वाले डायरेक्टिव को साफ़ तौर पर सेट करता है. हालांकि, अपनी next.config.js फ़ाइल में हेडर को मैन्युअल तरीके से सेट करके, इन्हें बदला जा सकता है. उदाहरण के लिए, यह पक्का करने के लिए कि कोई पेज Cloud CDN में कैश मेमोरी में सेव न हो:

  /** @type {import('next').NextConfig} */
  const nextConfig = {
      headers: async () => [{
          source: "/YOUR_PRIVATE_PAGE",
          headers: [{
              key: "Cache-Control",
              value: "private"
          }],
      }],
  };

Angular

Angular SSR, कैश मेमोरी को कंट्रोल करने वाले डायरेक्टिव को साफ़ तौर पर सेट नहीं करता. अपने सर्वर रूट में कैश मेमोरी कंट्रोल हेडर तय करके, अपना हेडर जोड़ा जा सकता है. उदाहरण के लिए, Cloud CDN को सभी पेजों को एक घंटे के लिए कैश मेमोरी में सेव करने की अनुमति देने के लिए:

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  {
    path: '**',
    renderMode: RenderMode.Prerender,
    headers: {
      'Cache-Control': 'public, max-age=3600',
    }
  }
];

इसके अलावा, यह पक्का करने के लिए कि किसी खास पेज को कैश मेमोरी में सेव न किया जाए:

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // ... other routes
  {
    path: 'YOUR_PRIVATE_PAGE',
    renderMode: RenderMode.Server,
    headers: {
      'Cache-Control': 'private',
    }
  }
];

ध्यान में रखे गए डायरेक्टिव

Firebase App Hosting का Cloud CDN इंस्टेंस, कैश मेमोरी को कंट्रोल करने वाले इन निर्देशों का पालन करता है:

डायरेक्टिव अनुरोध जवाब
no-store अनुरोध में मौजूद होने पर, जवाब को कैश मेमोरी में सेव नहीं किया जाएगा. no-store वाले रिस्पॉन्स को कैश मेमोरी में सेव नहीं किया जाता.
no-cache no-cache अनुरोध डायरेक्टिव को अनदेखा कर दिया जाता है, ताकि क्लाइंट को ओरिजनल सर्वर पर फिर से पुष्टि करने की प्रोसेस शुरू करने या इसके लिए मजबूर करने से रोका जा सके. no-cache वाले रिस्पॉन्स को कैश मेमोरी में सेव किया जाता है. हालांकि, इसे इस्तेमाल करने से पहले, मूल सर्वर से इसकी फिर से पुष्टि की जानी चाहिए.
public लागू नहीं कैश मेमोरी में सेव करने के लिए, इस डायरेक्टिव की ज़रूरत नहीं होती. हालांकि, ऐसे कॉन्टेंट के लिए इसे शामिल करना सबसे सही तरीका है जिसे प्रॉक्सी को कैश मेमोरी में सेव करना चाहिए.
private लागू नहीं private डायरेक्टिव वाले रिस्पॉन्स को Cloud CDN कैश मेमोरी में सेव नहीं करता. भले ही, रिस्पॉन्स को कैश मेमोरी में सेव किया जा सकता हो. हालांकि, क्लाइंट (जैसे कि ब्राउज़र) अब भी नतीजे को कैश मेमोरी में सेव कर सकते हैं. रिस्पॉन्स को कैश मेमोरी में सेव होने से रोकने के लिए, no-store का इस्तेमाल करें.
max-age=SECONDS max-age अनुरोध डायरेक्टिव को अनदेखा कर दिया जाता है. कैश मेमोरी में सेव किया गया रिस्पॉन्स इस तरह दिखाया जाता है, जैसे कि अनुरोध में यह हेडर शामिल न किया गया हो. max-age डायरेक्टिव वाला रिस्पॉन्स, तय किए गए सेकंड तक कैश मेमोरी में सेव रहता है.
s-maxage=SECONDS लागू नहीं s-maxage डायरेक्टिव वाला रिस्पॉन्स, तय किए गए सेकंड तक कैश मेमोरी में सेव रहता है. अगर max-age और s-maxage, दोनों मौजूद हैं, तो Cloud CDN, s‑maxage का इस्तेमाल करता है. इस डायरेक्टिव वाले रिस्पॉन्स, पुराने नहीं होते. s-max-age (दो हाइफ़न) का इस्तेमाल, कैश मेमोरी में सेव करने के लिए नहीं किया जा सकता.
max-stale=SECONDS max-stale अनुरोध डायरेक्टिव, ज़्यादा से ज़्यादा स्टेलनेस (सेकंड में) तय करता है, जिसे क्लाइंट स्वीकार करने के लिए तैयार है. Cloud CDN इसका पालन करता है और कैश मेमोरी में सेव किया गया पुराना जवाब सिर्फ़ तब दिखाता है, जब जवाब की समयसीमा max-stale डायरेक्टिव से कम हो. ऐसा न होने पर, अनुरोध को पूरा करने से पहले, यह फिर से पुष्टि करता है. लागू नहीं
stale-while-revalidate=SECONDS लागू नहीं क्लाइंट को stale-while-revalidate के साथ जवाब, SECONDS तक दिया जाता है. इस दौरान, फिर से पुष्टि करने की प्रोसेस एसिंक्रोनस तरीके से होती है.
must-revalidate लागू नहीं must-revalidate वाले रिस्पॉन्स की समयसीमा खत्म होने के बाद, मूल सर्वर से उसकी फिर से पुष्टि की जाती है. इस डायरेक्टिव वाले रिस्पॉन्स, पुराने नहीं होते.
proxy-revalidate proxy-revalidate वाले रिस्पॉन्स की समयसीमा खत्म होने के बाद, मूल सर्वर से उसकी फिर से पुष्टि की जाती है. इस डायरेक्टिव वाले रिस्पॉन्स, पुराने नहीं होते.
no-transform लागू नहीं Cloud CDN, इमेज में कोई बदलाव नहीं करता.

कैश मेमोरी में सेव किए गए और सेव नहीं किए गए ट्रैफ़िक को मेज़र करना

Firebase कंसोल में, App Hosting > इस्तेमाल टैब में, "Cloud CDN - आउटगोइंग बैंडविड्थ" ग्राफ़, कैश मेमोरी में सेव किए गए और कैश मेमोरी में सेव नहीं किए गए बाइट दिखाता है. साथ ही, इसमें हर रोलआउट के लिए एक निशान होता है. इस ग्राफ़ का इस्तेमाल करके, कैश मेमोरी को ऑप्टिमाइज़ करने की अपनी कोशिशों के असर को मेज़र किया जा सकता है.

रूट के हिसाब से मॉनिटर करने की सुविधा की मदद से, अपने वेब ऐप्लिकेशन में खास रूट के लिए कैश मेमोरी हिट रेट भी देखा जा सकता है.