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

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. जवाब में max-age या s-maxage डायरेक्टिव वाला Cache-Control हेडर मौजूद है. इसके अलावा, इसमें आने वाले समय का टाइमस्टैंप वाला 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, किसी भी तरह का ट्रांसफ़ॉर्मेशन लागू नहीं करता है.

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

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