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

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

App Hosting Cloud CDN का बुनियादी कॉन्फ़िगरेशन सेट करता है. इसमें बदलाव नहीं किया जा सकता. हालांकि, कैश मेमोरी को ऑप्टिमाइज़ करने के लिए, कई काम किए जा सकते हैं. इससे, पेज लोड होने की स्पीड बढ़ाई जा सकती है, कैश न किए गए कॉन्टेंट के लिए बिलिंग कम की जा सकती है, और 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. रिस्पॉन्स में Cache-Control हेडर के साथ, no-store या private डायरेक्टिव हो.

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

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

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