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

Cloud CDN, App Hosting के वेब ऐप्लिकेशन के लिए अहम है. आपके बैकएंड को भेजे जाने वाले हर अनुरोध को सबसे पहले Cloud CDN से होकर गुज़रना पड़ता है. 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 के अलावा कोई और वैल्यू है.

  3. जवाब में no-store या private डायरेक्टिव वाला Cache-Control हेडर मौजूद है.

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

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

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

Next.js

Next.js, cache-control डायरेक्टिव को कई फ़ैक्टर के आधार पर अपने-आप सेट करता है. हालांकि, 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 डायरेक्टिव वाले रिस्पॉन्स को, तय किए गए SECONDS तक कैश मेमोरी में सेव किया जाता है.
s-maxage=SECONDS लागू नहीं s-maxage डायरेक्टिव वाले रिस्पॉन्स को, तय किए गए SECONDS तक कैश मेमोरी में सेव किया जाता है. अगर 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 - आउटगोइंग बैंडविड्थ" ग्राफ़ में, कैश किए गए और कैश नहीं किए गए बाइट दिखाए जाते हैं. साथ ही, इसमें हर रोलआउट के लिए एक मार्क होता है. इस ग्राफ़ का इस्तेमाल करके, कैश मेमोरी को ऑप्टिमाइज़ करने के लिए किए गए प्रयासों के असर का आकलन किया जा सकता है.

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