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

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

Cloud का बुनियादी सीडीएन कॉन्फ़िगरेशन 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 एमबी से कम या उसके बराबर हो.

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

  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, कैश-कंट्रोल डायरेक्टिव को कई बातों के आधार पर अपने-आप सेट करता है. हालांकि, अपनी 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 के साथ जवाब, क्लाइंट को सेकंड तक दिया जाता है, जबकि फिर से पुष्टि करने की प्रोसेस असिंक्रोनस तरीके से होती है.
must-revalidate लागू नहीं must-revalidate वाले रिस्पॉन्स की समयसीमा खत्म होने के बाद, ऑरिजिन सर्वर से फिर से पुष्टि की जाती है. इस डायरेक्टिव के साथ मिले जवाब, पुराने नहीं होते.
proxy-revalidate proxy-revalidate वाले रिस्पॉन्स की समयसीमा खत्म होने के बाद, ऑरिजिन सर्वर से फिर से पुष्टि की जाती है. इस डायरेक्टिव के साथ मिले जवाब, पुराने नहीं होते.
no-transform लागू नहीं Cloud CDN कोई ट्रांसफ़ॉर्मेशन लागू नहीं करता.

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

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