आपके वेब ऐप्लिकेशन के लिए, App Hosting की सहायता का एक अहम हिस्सा Cloud CDN है. आपके बैकएंड पर कि��ा जाने वाला हर अनुरोध, पहले Cloud CDN से होकर जाता है. सीडीएन में पहले से कैश मेमोरी में सेव कॉन्टेंट, उपयोगकर्ता को तुरंत दिखाया जाता है. इससे, आपके वेब ऐप्लिकेशन के सर्वर कोड को चलाने वाली Cloud Run सेवा पर जाने की ज़रूरत नहीं पड़ती. web.dev पर जाकर, सीडीएन के सामान्य फ़ायदों के बारे में ज़्यादा जानें.
Cloud का बुनियादी सीडीएन कॉन्फ़िगरेशन, App Hosting सेट करता है और उसमें बद��ाव ��हीं ����या जा स�����ा. हालांकि, पेज लोड होने की स्पीड बढ़ाने, बिना कैश मेमोरी में सेव किए गए कॉन्टेंट के लिए बिलिंग कम करने, और Cloud Run पर आने वाले ट्रैफ़िक को कम करने के लिए, कैश मेमोरी को ऑप्टिमाइज़ करने के कई तरीके हैं.
कैश मेमोरी में सेव किया जा सकने वाला कॉन्टेंट
Cloud CDN, जवाबों को कैश मेमोरी में तब सेव करता है, जब ये सभी शर्तें पूरी होती हैं:
अनुरोध, GET है
रिस्पॉन्स में स्टेटस कोड
200
,203
,204
,206
,300
,301
,302
,307
,308
,404
,405
,410
,421
,451
या501
है.रिस्पॉन्स में
max-age
याs-maxage
निर्देश वालाCache-Control
हेडर है या आने वाले समय में टाइमस्टैंप वालाExpires
हेडर है.रिस्पॉन्स में
Age
हेडर याCache-Control
हेडर हो, जिसमें साफ़ तौर परpublic
डायरेक्टिव हो.रिस्पॉन्स का साइज़ 10 एमबी से कम या उसके बराबर हो.
साथ ही, इनमें से कोई भी बात सही नहीं है:
रिस्पॉन्स में
Set-Cookie
हेडर हैरिस्पॉन्स में
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
से अलग है.रिस्पॉन्स में
no-store
याprivate
के साथCache-Control
हेडर है.अनुरोध में
no-store
डायरेक्टिव वालाCache-Control
हेडर है.अनुरोध में
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 - आउटगोइंग बैंडविड्थ" ग्राफ़ से, कैश मेमोरी में सेव किए गए और सेव नहीं किए गए बाइट दिखते हैं. साथ ही, हर रोल आउट के लिए एक मार्क होता है. इस ग्राफ़ का इस्तेमाल करके, कैश मेमोरी को ऑप्टिमाइज़ करने के अपने प्रयासों के असर को मेज़र किया जा सकता है.