Prompt और लागू होने वाले परिदृश्य
एक ई-कॉमर्स चेकआउट पेज हिस्ट्री नेविगेशन के दौरान अलग-अलग व्यवहार करता है। कभी-कभी Back बटन दबाने पर सटीक DOM, फ़ॉर्म मान, स्क्रॉल पोज़ीशन और JavaScript heap लगभग तुरंत रिस्टोर हो जाते हैं। वह रिस्टोर किया गया स्नैपशॉट एक पुराना कार्ट टोटल या किसी अन्य टैब में साइन-आउट हो चुका सेशन दिखा सकता है। अन्य समयों पर, Back एक नया डॉक्यूमेंट बनाता है और सामान्य लोडिंग पथ चलाता है। टीम इन सभी परिणामों का वर्णन करने के लिए "ब्राउज़र कैश" शब्द का उपयोग कर रही है और विश्व स्तर पर कैशिंग को अक्षम करने पर विचार कर रही है।
समझाएं कि back/forward cache, या bfcache, HTTP कैश और SPA router कैश से किस प्रकार भिन्न है। फिर एक लाइफ़साइकिल और डिबगिंग योजना डिज़ाइन करें जो:
- सामान्य डॉक्यूमेंट लोड से अलग एक पुष्ट bfcache रिस्टोर का पता लगाती है;
- कोई भी परिणामी कार्रवाई करने की अनुमति देने से पहले प्रमाणीकरण, कार्ट और अन्य संवेदनशील स्टेट को पुनः सत्यापित करती है;
- पेज छिपे होने के दौरान संसाधनों को रिलीज़ करती है और रिस्टोर के बाद उन्हें केवल एक बार पुनः कनेक्ट करती है;
- पेज, चाइल्ड फ़्रेम और थर्ड-पार्टी कोड में पात्रता अवरोधकों (eligibility blockers) को खोजती है;
- ब्राउज़र वर्ज़न के आधार पर हिस्ट्री ट्रैवर्सल, पुष्ट रिस्टोर, misses और ब्लॉकिंग कारणों को मापती है;
- जब यह उत्पाद की सुरक्षा नीति के साथ संगत हो, तो परफ़ॉर्मेंस लाभ को बनाए रखती है।
यह प्रश्न सीनियर फ़्रंटएंड, वेब परफ़ॉर्मेंस, ब्राउज़र प्लेटफ़ॉर्म और फ़्रंटएंड आर्किटेक्चर इंटरव्यू पर लागू होता है। यह परीक्षण करता है कि क्या उम्मीदवार केवल कैश हेडर याद करने के बजाय एक रोके गए (paused) डॉक्यूमेंट के बारे में तर्क कर सकता है।
इंटरव्यूअर क्या मूल्यांकन करता है
पहला, उम्मीदवार को तीन अलग-अलग तंत्रों को स्पष्ट करना चाहिए। HTTP कैश पुन: प्रयोज्य प्रतिक्रियाओं (responses) को संग्रहीत करता है और अनुरोध, ताजगी और पुनः सत्यापन नियम लागू करता है। bfcache मेमोरी में पूरे क्रॉस-डॉक्यूमेंट पेज को उसके DOM और JavaScript heap सहित सुरक्षित रख सकता है, फिर सेशन-हिस्ट्री ट्रैवर्सल के लिए इसे रोक (pause) और फिर से शुरू (resume) कर सकता है। क्लाइंट राउटर ब्राउज़र-प्रबंधित डॉक्यूमेंट को बनाए या रिस्टोर किए बिना सॉफ्ट नेविगेशन के लिए एप्लिकेशन डेटा या UI को सुरक्षित रख सकता है। एक कैश को साफ़ करना दूसरों के लिए निदान नहीं है।
दूसरा, उम्मीदवार को लाइफ़साइकिल साक्ष्य को समझना चाहिए। pageshow प्रारंभिक लोड पर भी सक्रिय होता है, इसलिए केवल यह इवेंट प्रमाण नहीं है। एक pageshow इवेंट जिसका persisted मान true है, पुष्टि करता है कि डॉक्यूमेंट को bfcache जैसे कैश से रिस्टोर किया गया था। pagehide पर, persisted: true का अर्थ है कि ब्राउज़र पेज को संरक्षित करने का इरादा रखता है; यह गारंटी नहीं देता कि पेज कैश में रहेगा या बाद में रिस्टोर किया जाएगा।
तीसरा, एक मजबूत उत्तर रिस्टोरेशन को शुद्धता की सीमा (correctness boundary) के रूप में मानता है। टाइमर और इन-मेमोरी मान पहले के क्षण से फिर से शुरू होते हैं। ऑथराइजेशन अभी भी सर्वर पर निर्भर करता है, और संवेदनशील स्टेट को एक पुष्ट रिस्टोर पर पुनः सत्यापित किया जाना चाहिए। लाइव कनेक्शन, डेटाबेस हैंडल, ऑब्जर्वर और लॉक को नेविगेशन से पहले बंद या डिस्कनेक्ट करने और वापस आने के बाद फिर से खोलने की आवश्यकता हो सकती है। पुनः कनेक्शन कोड idempotent होना चाहिए।
चौथा, उम्मीदवार को सार्वभौमिक अवरोधक सूची के बजाय साक्ष्य के साथ डिबग करना चाहिए। पात्रता ब्राउज़र, वर्ज़न, फ़्रेम, API, रिस्पॉन्स नीति, मेमोरी दबाव और नेविगेशन परिदृश्य के अनुसार बदलती है। Chrome DevTools एक अलग bfcache परीक्षण चला सकता है और अवरोधकों को वर्गीकृत कर सकता है। जहां समर्थित हो, PerformanceNavigationTiming.notRestoredReasons फ़ील्ड साक्ष्य और एक फ़्रेम ट्री जोड़ता है, लेकिन इसके कारण स्ट्रिंग्स बदल सकते हैं और क्रॉस-ऑरिजिन विवरण छिपाए (masked) जा सकते हैं।
अंत में, उम्मीदवार को एक मापने योग्य परिणाम को परिभाषित करना चाहिए। back_forward के रूप में रिपोर्ट किया गया हिस्ट्री ट्रैवर्सल अपने आप में bfcache हिट का प्रमाण नहीं है। पुष्ट हिट pageshow.persisted से आते हैं। Misses हिस्ट्री ट्रैवर्सल के माध्यम से पहुंचे नए डॉक्यूमेंट लोड हैं, और उनके कारणों का अनुमान लगाने के बजाय उन्हें विभाजित (segmented) किया जाना चाहिए। लक्ष्य बिना किसी पुरानी-सेशन कार्रवाई, डुप्लिकेट कनेक्शन या विकृत एनालिटिक्स के उच्च सुरक्षित रिस्टोर कवरेज प्राप्त करना है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- इसमें कौन सा नेविगेशन शामिल है? क्या यह एक पूर्ण-डॉक्यूमेंट नेविगेशन है, एक सॉफ्ट SPA रूट परिवर्तन है, एक रीलोड है, एक फिर से खोला गया टैब है, या उसी टैब में एक वास्तविक Back/Forward ट्रैवर्सल है?
- क्या सुरक्षित रूप से जीवित रह सकता है? फ़ॉर्म ड्राफ़्ट और स्क्रॉल स्थिति वांछनीय हो सकती है; प्रमाणीकरण, मूल्य, इन्वेंट्री, अनुमतियाँ और वन-टाइम टोकन के लिए एक आधिकारिक ताजगी नियम की आवश्यकता होती है।
- रिस्पॉन्स नीति को क्या चाहिए? कुछ पेजों में ऐसा डेटा होता है जिसे उत्पाद नीति पेज स्नैपशॉट में रखने से मना करती है। यह आवश्यकता हिट दर से अधिक प्राथमिकता लेती है।
- कौन से संसाधन सक्रिय रहते हैं? इन्वेंटरी WebSockets, IndexedDB कनेक्शन, Web Locks, मीडिया कैप्चर, ऑब्जर्वर और थर्ड-पार्टी स्क्रिप्ट शुद्धता या पात्रता को प्रभावित कर सकते हैं।
- कौन से ब्राउज़र और वर्ज़न मायने रखते हैं? DevTools आउटपुट और
notRestoredReasonsएक पोर्टेबल अनुबंध नहीं हैं। वास्तविक हिस्ट्री नेविगेशन के साथ समर्थित ब्राउज़र मैट्रिक्स का परीक्षण करें। - क्या चाइल्ड फ़्रेम मौजूद हैं? एक सेम-ऑरिजिन चाइल्ड एक विस्तृत अवरोधक ट्री प्रदर्शित कर सकता है। एक क्रॉस-ऑरिजिन फ़्रेम केवल छिपी हुई जानकारी दिखा सकता है, जिसके लिए विक्रेता अलगाव (vendor isolation) या न्यूनतम पुनरुत्पादन (minimal reproduction) की आवश्यकता होती है।
- "Stale" का क्या अर्थ है? अधिकतम स्वीकार्य आयु और उस कार्रवाई को परिभाषित करें जो पुनः सत्यापन विफल होने के दौरान ब्लॉक की जाती है।
- एनालिटिक्स की गणना कैसे की जाती है? तय करें कि क्या रिस्टोर किया गया पेज एक पेज व्यू है, एक नेविगेशन है, या दोनों, फिर एक रिस्टोर को डुप्लिकेट इवेंट उत्सर्जित करने से रोकें।
- सफलता का पैमाना (success gate) क्या है? अवलोकनीय हिस्ट्री ट्रैवर्सल के बीच पुष्ट रिस्टोर अनुपात, मिस कारणों, रिस्टोर विलंबता, पुनः सत्यापन विफलता, बासी-कार्रवाई रोकथाम और डुप्लिकेट-संसाधन गणना को ट्रैक करें।
30-सेकंड उत्तर रूपरेखा
"मैं bfcache को HTTP और राउटर कैश से अलग करता हूँ: यह ब्राउज़र-प्रबंधित हिस्ट्री नेविगेशन के लिए एक डॉक्यूमेंट को रोकता है। मैं केवल pageshow.persisted के साथ हिट की पुष्टि करता हूँ, रिस्टोरेशन को माने बिना idempotent क्लीनअप के लिए pagehide का उपयोग करता हूँ। रिस्टोर पर, मैं संवेदनशील कार्रवाइयों से पहले सेशन, कार्ट, मूल्य और अनुमतियों को पुनः सत्यापित करता हूँ, फिर संसाधनों को एक बार पुनः कनेक्ट करता हूँ। मैं समर्थित ब्राउज़रों में misses को पुनरुत्पादित करता हूँ, Chrome के bfcache पैनल और उपलब्ध notRestoredReasons डेटा का उपयोग करता हूँ, और ब्राउज़र और रूट द्वारा फ़ील्ड मेट्रिक्स को विभाजित करता हूँ। मैं सर्वर ऑथराइजेशन और नो-स्नैपशॉट नीतियों को आधिकारिक रखते हुए सुरक्षित पेजों को अनुकूलित करता हूँ।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: चार अवलोकनीय पथों को मॉडल करें
हेडर के बजाय परिणामों से शुरुआत करें:
| पथ | नया डॉक्यूमेंट? | मुख्य साक्ष्य | आवश्यक हैंडलिंग |
|---|---|---|---|
| प्रारंभिक या लिंक नेविगेशन | हाँ | pageshow.persisted === false; नेविगेशन प्रकार आमतौर पर navigate | स्टेट और संसाधनों को इनिशियलाइज़ करें |
| रीलोड | हाँ | pageshow.persisted === false; नेविगेशन प्रकार reload | सामान्य लोड पथ चलाएं |
| रीलोड के साथ हिस्ट्री ट्रैवर्सल | हाँ | pageshow.persisted === false; नेविगेशन प्रकार back_forward | एक bfcache मिस रिकॉर्ड करें और कारणों का निरीक्षण करें |
| पुष्ट bfcache रिस्टोर | नहीं | pageshow.persisted === true | संवेदनशील स्टेट को पुनः सत्यापित करें और सुरक्षित रूप से फिर से शुरू करें |
नेविगेशन प्रकार बताता है कि एक नए डॉक्यूमेंट तक कैसे पहुंचा गया था। यह bfcache हिट की पुष्टि नहीं कर सकता क्योंकि हिट पुराने डॉक्यूमेंट को फिर से शुरू करता है। हालांकि, यह हिस्ट्री ट्रैवर्सल के कारण होने वाले नए लोड की पहचान कर सकता है और इसलिए मिस भाजक (miss denominator) में योगदान दे सकता है। ब्राउज़र पुनरारंभ, टैब डुप्लिकेशन और फिर से खोलने के फ़्लो इस सिग्नल को धुंधला कर सकते हैं, इसलिए फ़ील्ड मेट्रिक्स में जहां उपलब्ध हो ब्राउज़र, वर्ज़न, रूट और परिदृश्य शामिल होना चाहिए।
bfcache भी HTTP पुनः सत्यापन से भिन्न है। रिस्टोर पर, ब्राउज़र इन-मेमोरी पेज को फिर से शुरू करता है; Cache-Control: no-cache पिक्सेल दिखाई देने से पहले नेटवर्क सत्यापन को बाध्य नहीं करता है। यदि रिस्टोर की गई सामग्री को ताज़ा होना चाहिए, तो एप्लिकेशन pageshow के बाद एक लक्षित जांच करता है। एक SPA सॉफ्ट नेविगेशन उसी डॉक्यूमेंट के अंदर हिस्ट्री और UI को बदलता है; bfcache तब प्रासंगिक हो जाता है जब वह डॉक्यूमेंट स्वयं छोड़ दिया जाता है और बाद में रिस्टोर किया जाता है।
चरण 2: लाइफ़साइकिल कार्य को idempotent और रिस्टोर-सुरक्षित बनाएं
कनेक्शन के स्वामित्व को केंद्रीकृत करें। क्लीनअप के बाद एक नया डॉक्यूमेंट आ सकता है, एक रिस्टोर हो सकता है, या कोई वापसी नहीं हो सकती है। सेटअप प्रारंभिक लोड के बाद और कई रिस्टोर के बाद चल सकता है, इसलिए दोनों परिचालनों को पुनरावृत्ति को सहन करना चाहिए।
let liveSocket = null;
function connectLiveUpdates() {
if (liveSocket) return;
liveSocket = new WebSocket("wss://shop.example/live-cart");
}
function disconnectLiveUpdates() {
liveSocket?.close();
liveSocket = null;
}
async function revalidateSensitiveState() {
const response = await fetch("/api/session-snapshot", {
cache: "no-store",
credentials: "same-origin",
});
if (response.status === 401) {
location.replace("/login");
return false;
}
if (!response.ok) {
showRetryState();
return false;
}
renderSessionState(await response.json());
return true;
}
window.addEventListener("pagehide", disconnectLiveUpdates);
window.addEventListener("pageshow", async (event) => {
reportNavigation(event.persisted ? "bfcache_restore" : "document_load");
if (event.persisted && !(await revalidateSensitiveState())) return;
connectLiveUpdates();
});नमूने का सर्वर एंडपॉइंट प्राधिकारी बना हुआ है। जब रिस्टोर की गई संवेदनशील स्थिति की जांच की जा रही हो, तो UI को चेकआउट अक्षम कर देना चाहिए, और एक असफल जांच को स्नैपशॉट पर चुपचाप भरोसा करने के बजाय पुनः प्रयास की स्थिति दिखानी चाहिए। सर्वर-साइड चेकआउट अनुरोध को अभी भी उपयोगकर्ता को पुनः प्रमाणित करना चाहिए और मूल्य व इन्वेंट्री की पुनर्गणना करनी चाहिए।
महत्वपूर्ण क्लीनअप के लिए unload का उपयोग न करें। यह अविश्वसनीय है और कुछ ब्राउज़रों में पेजों को अयोग्य बना सकता है। पेज-लाइफ़साइकिल क्लीनअप के लिए pagehide को प्राथमिकता दें और जब आवश्यकता नेविगेशन के बजाय विजिबिलिटी हो तो visibilitychange का उपयोग करें। केवल Chromium वाले freeze और resume को एकमात्र शुद्धता पथ बनाने से बचें।
चरण 3: स्थानीय पुनरुत्पादन से स्वामित्व तक मिस का निदान करें
एक नियतात्मक अनुक्रम के साथ एक रूट को पुनरुत्पादित करें: इसे सीधे खोलें, प्रासंगिक स्थिति स्थापित करें, दूसरे डॉक्यूमेंट के लिए एक सामान्य लिंक का पालन करें, फिर ब्राउज़र के Back बटन का उपयोग करें। नियंत्रण रन में एक्सटेंशन और विकास टूलिंग से बचें क्योंकि वे लाइफ़साइकिल व्यवहार को बदल सकते हैं। प्रोडक्शन रिस्पॉन्स हेडर और थर्ड-पार्टी स्क्रिप्ट के साथ दोहराएं।
Chrome में, एप्लिकेशन पैनल का Back/forward cache परीक्षण चलाएं। रिकॉर्ड करें कि परिणाम कार्रवाई योग्य है, ब्राउज़र समर्थन लंबित है, या कार्रवाई योग्य नहीं है, और फ़्रेम एट्रिब्यूशन का विस्तार करें। यदि कोई unload श्रोता दिखाई देता है, तो पता लगाएं कि क्या फ़र्स्ट-पार्टी या विक्रेता कोड ने इसे पंजीकृत किया है। यदि कोई रिस्पॉन्स नीति, खुला कनेक्शन, सक्रिय लेनदेन, लॉक, मीडिया API, या फ़्रेम दिखाई देता है, तो इसे सबसे छोटी वास्तविक सुविधा तक सीमित करें जो परिणाम को पुनरुत्पादित करती है।
जहां समर्थित हो, छूटे हुए हिस्ट्री ट्रैवर्सल के माध्यम से पहुंचे नए डॉक्यूमेंट पर notRestoredReasons का निरीक्षण करें। लौटाए गए पदानुक्रम और कारण मानों को नैदानिक डेटा के रूप में सुरक्षित रखें, एप्लिकेशन तर्क के रूप में नहीं। सटीक कारण स्ट्रिंग्स को हार्ड-कोड न करें, यह न मानें कि प्रत्येक ब्राउज़र प्रॉपर्टी को उजागर करता है, या केवल null को पुष्ट हिट के रूप में व्याख्यायित न करें। गोपनीयता के लिए क्रॉस-ऑरिजिन चाइल्ड विवरण को छिपाया जा सकता है; एम्बेडेड विक्रेता का अलग से परीक्षण करें या कार्य-कारण स्थापित करने के लिए इसे एक नियंत्रित प्रयोग में हटा दें।
एक समय में एक स्वामी को ठीक करें, पृथक परीक्षण को फिर से चलाएं, फिर पूरे रूट को सत्यापित करें। pagehide पर IndexedDB कनेक्शन या WebSocket को बंद करना, unload हैंडलर को हटाना, और थर्ड-पार्टी फ़्रेम को बाधित करना परिकल्पनाओं के उदाहरण हैं; ब्राउज़र का परिणाम तय करता है कि क्या परिवर्तन वास्तव में पात्रता को प्रभावित करता है।
चरण 4: फ़ील्ड में शुद्धता और परफ़ॉर्मेंस सत्यापित करें
प्रत्येक pageshow के लिए एक इवेंट उत्सर्जित करें। persisted: true एक पुष्ट रिस्टोर है। नए डॉक्यूमेंट लोड के लिए, Navigation Timing प्रकार संलग्न करें; back_forward एक अवलोकनीय हिस्ट्री ट्रैवर्सल की पहचान करता है जो bfcache से चूक गया था। उन इवेंट्स को परस्पर अनन्य रखें। निजी पेज सामग्री को रिकॉर्ड किए बिना रूट फ़ैमिली, ब्राउज़र, वर्ज़न, प्रमाणीकरण स्थिति और प्रयोग कॉहोर्ट जोड़ें।
कम से कम मापें:
- ब्राउज़र और रूट द्वारा विभाजित, अवलोकनीय हिस्ट्री ट्रैवर्सल से विभाजित पुष्ट रिस्टोर;
- मिस गणना और समर्थित ब्लॉकिंग-कारण फ़ैमिली, जिसमें छिपे हुए और अनुपलब्ध मामले शामिल हैं;
- रिस्टोर-टू-नेक्स्ट-पेंट और रिस्टोर-टू-इंटरएक्टिव-संवेदनशील-स्टेट विलंबता;
- सेशन, अनुमति, कार्ट, मूल्य और इन्वेंट्री पुनः सत्यापन विफलताएं;
- रिस्टोर की गई स्थिति असत्यापित होने के दौरान ब्लॉक किए गए चेकआउट प्रयास;
- बार-बार Back/Forward चक्रों के बाद डुप्लिकेट सॉकेट, ऑब्जर्वर, एनालिटिक्स और टाइमर साइड इफेक्ट्स;
- मेमोरी प्रतिगमन और उपयोगकर्ता-दृश्यमान विफलताएं, क्योंकि हिट दर को अधिकतम करना ही एकमात्र उद्देश्य नहीं है।
बार-बार हिस्ट्री चक्र चलाएं, दूसरे टैब में साइन आउट करें, कार्ट को कहीं और बदलें, वन-टाइम टोकन समाप्त करें, पुनः सत्यापन एंडपॉइंट को विफल करें, और क्रॉस-ऑरिजिन फ़्रेम का उपयोग करें। दायरे में Chrome, Firefox और Safari वर्ज़न का परीक्षण करें। एक स्थानीय Chrome पैनल एक नियंत्रित मामले को साबित करता है; प्रोडक्शन टेलीमेट्री वितरण को साबित करती है, और उत्पाद दावे सुरक्षा साबित करते हैं।
उच्च-गुणवत्ता वाला नमूना उत्तर
"त्वरित पथ bfcache है: ब्राउज़र ने संपूर्ण चेकआउट डॉक्यूमेंट और इसके JavaScript heap को संरक्षित किया, इसे रोका, और सेशन-हिस्ट्री नेविगेशन के दौरान इसे फिर से शुरू किया। HTTP कैश केवल रिस्पॉन्स संग्रहीत करता है, जबकि क्लाइंट राउटर एक लाइव डॉक्यूमेंट के भीतर सॉफ्ट नेविगेशन को संभालता है। मैं पहले पथों को लेबल करूंगा। pageshow.persisted === true एक रिस्टोर की पुष्टि करता है। एक नया डॉक्यूमेंट जिसका Navigation Timing प्रकार back_forward है, एक हिस्ट्री ट्रैवर्सल का प्रतिनिधित्व करता है जिसने इस पेज को bfcache से रिस्टोर नहीं किया। pagehide.persisted === true केवल कैश करने का ब्राउज़र का इरादा है, इसलिए मैं इसे हिट रिकॉर्ड के रूप में उपयोग नहीं करूंगा।"
"pagehide पर, मैं उन संसाधनों को बंद करता हूँ जिन्हें लाइव नहीं रहना चाहिए, जैसे कार्ट सॉकेट और कोई भी खुला लेनदेन, idempotent क्लीनअप का उपयोग करके। प्रत्येक pageshow पर, मैं सुनिश्चित करता हूँ कि संसाधन ठीक एक बार जुड़े हों। एक पुष्ट रिस्टोर के लिए, मैं अस्थायी रूप से चेकआउट को ब्लॉक करता हूँ, एक आधिकारिक सेशन और कार्ट स्नैपशॉट प्राप्त करता हूँ, UI को अपडेट करता हूँ, और लॉगआउट पर रीडायरेक्ट करता हूँ। चेकआउट API अभी भी ऑथराइजेशन, वर्तमान मूल्य और इन्वेंट्री की जांच करता है, इसलिए एक फिर से शुरू किया गया हीप कभी भी खरीदारी को अधिकृत नहीं कर सकता है। मैं सभी प्रारंभिक-लोड प्रभावों को फिर से चलाने के बजाय एनालिटिक्स के लिए एक बार रिस्टोर की गणना करता हूँ।"
"Misses के लिए, मैं प्रोडक्शन हेडर और विक्रेताओं के साथ सटीक पूर्ण-डॉक्यूमेंट पथ को पुनरुत्पादित करता हूँ। Chrome में मैं एप्लिकेशन पैनल bfcache परीक्षण चलाता हूँ, फ़्रेम स्वामित्व का विस्तार करता हूँ, और एक समय में एक कार्रवाई योग्य कारणों को ठीक करता हूँ। समर्थित Chromium वर्ज़न पर मैं छूटे हुए हिस्ट्री लोड के लिए notRestoredReasons एकत्र करता हूँ, छिपे हुए और अज्ञात मामलों को संरक्षित करता हूँ और कारण टेक्स्ट पर कभी भी उत्पाद व्यवहार को विभाजित नहीं करता हूँ। फिर मैं समर्थित Chrome, Firefox और Safari मैट्रिक्स का परीक्षण करता हूँ क्योंकि पात्रता कार्यान्वयन और परिदृश्य के अनुसार बदलती है।"
"लॉन्च गेट कम रिटर्न विलंबता के साथ एक उच्च पुष्ट रिस्टोर अनुपात है, जबकि परीक्षणों में बासी-सेशन क्रियाएं, डुप्लिकेट कनेक्शन और एनालिटिक्स दोहराव शून्य रहते हैं। मैं रूट और ब्राउज़र द्वारा misses और पुनः सत्यापन विफलताओं को विभाजित करता हूँ। यदि नीति कहती है कि विशेष निजी डेटा वाले पेज को कभी भी स्नैपशॉट नहीं किया जाना चाहिए, तो मैं उस प्रतिबंध को बनाए रखता हूँ और हिट दर के लिए सुरक्षा का व्यापार करने के बजाय आसपास के पेजों को अनुकूलित करता हूँ।"
सामान्य गलतियाँ और सुधार
- हर रिटर्न पथ को "ब्राउज़र कैश" कहना → HTTP प्रतिक्रियाएं, संपूर्ण-डॉक्यूमेंट स्नैपशॉट और राउटर स्थिति विभिन्न नियमों का पालन करते हैं → तंत्र का नाम बताएं और तंत्र-विशिष्ट साक्ष्य एकत्र करें।
- प्रमाण के रूप में अकेले
pageshowका उपयोग करना → यह प्रारंभिक डॉक्यूमेंट लोड पर भी सक्रिय होता है → पुष्ट रिस्टोर के लिएevent.persisted === trueकी आवश्यकता रखें। pagehide.persistedको भविष्य के हिट के रूप में मानना → ब्राउज़र बाद में पेज को हटा सकता है या दूसरा पथ चुन सकता है → सुरक्षित क्लीनअप का मार्गदर्शन करने के लिए केवल इसका उपयोग करें; रिस्टोर पर हिट रिकॉर्ड करें।- मानना कि
back_forwardका अर्थ bfcache है → यह हिस्ट्री ट्रैवर्सल द्वारा लोड किए गए एक नए डॉक्यूमेंट का वर्णन कर सकता है → misses के लिए नेविगेशन प्रकार को हिट के लिएpageshow.persistedके साथ संयोजित करें। - बासी UI को ठीक करने के लिए सभी कैशिंग को अक्षम करना → यह लाइफ़साइकिल बग को छुपाता है और त्वरित नेविगेशन का त्याग करता है → संवेदनशील फ़ील्ड को पुनः सत्यापित करें और सर्वर प्राधिकरण को आधिकारिक रखें।
- प्रत्येक रिस्टोर किए गए पेज को रीलोड करना → एकमुश्त रीलोड ऑप्टिमाइज़ेशन को खारिज कर देता है और विफलता पर लूप कर सकता है → केवल आधिकारिक स्थिति को रीफ़्रेश करें, एक परिभाषित अमान्य स्थिति के लिए रीलोड या रीडायरेक्ट आरक्षित रखें।
- एक स्थायी अवरोधक सूची याद रखना → इंजन और वर्ज़न में पात्रता और कारण के नाम बदलते हैं → ब्राउज़र परीक्षण, फ़ीचर डिटेक्शन और फ़ील्ड साक्ष्य का उपयोग करें।
unloadमें क्लीनअप डालना → यह इवेंट अविश्वसनीय है और पात्रता को रोक सकता है →pagehideका उपयोग करें, साथ ही विजिबिलिटी इवेंट जब उत्पाद की आवश्यकता विजिबिलिटी हो।- प्रत्येक लाइफ़साइकिल इवेंट पर पुनः कनेक्ट करना →
pageshow,resume, और फ़्रेमवर्क प्रभाव डुप्लिकेट सॉकेट या ऑब्जर्वर बना सकते हैं → प्रत्येक संसाधन को एक idempotent स्वामी दें। - एकल DevTools पास पर भरोसा करना → यह वास्तविक विक्रेताओं, मेमोरी दबाव, ब्राउज़रों, या सेशन परिवर्तनों को कवर नहीं करता है → नियंत्रित परीक्षणों, एक ब्राउज़र मैट्रिक्स, RUM और प्रतिकूल उत्पाद प्रवाह को संयोजित करें।
फ़ॉलो-अप प्रश्न
क्या Cache-Control: no-cache bfcache रिस्टोर से पहले सत्यापन को बाध्य करता है?
नहीं। एक bfcache रिस्टोर HTTP कैश के माध्यम से अपने संसाधन अनुरोधों को पूरा करने के बजाय एक इन-मेमोरी डॉक्यूमेंट को फिर से शुरू करता है, इसलिए रिस्टोर किए गए पेज को प्रदर्शित करने से पहले HTTP पुनः सत्यापन निर्देश नहीं चलते हैं। लक्षित ताजगी जांच शुरू करने के लिए pageshow.persisted का उपयोग करें। यदि नीति पेज स्नैपशॉट को बनाए रखने से पूरी तरह से मना करती है, तो उचित रिस्पॉन्स और ब्राउज़र नीति लागू करें, यह स्वीकार करते हुए कि पात्रता कार्यान्वयन के अनुसार भिन्न हो सकती है।
क्या PerformanceNavigationTiming.type === "back_forward" एक हिट सिग्नल है?
नहीं। यह एक नए बनाए गए डॉक्यूमेंट को बताता है कि यह हिस्ट्री ट्रैवर्सल के माध्यम से पहुंचा था। एक पुष्ट bfcache रिस्टोर एक मौजूदा डॉक्यूमेंट को फिर से शुरू करता है और pageshow.persisted === true के साथ पहचाना जाता है। नए back_forward लोड को अवलोकनीय misses के रूप में गिनें, ब्राउज़र की विशिष्टताओं जैसे पुनरारंभ या फिर से खोले गए टैब परिदृश्यों के अधीन, और टेलीमेट्री को तदनुसार विभाजित करें।
क्या होगा यदि notRestoredReasons गायब है, null है, या छिपा हुआ (masked) है?
लापता को असमर्थित के रूप में, null को अपने आप में अपर्याप्त के रूप में, और मास्क किए गए को गोपनीयता-संरक्षण नैदानिक श्रेणी के रूप में मानें। पेज ट्रांज़िशन इवेंट के साथ हिट की पुष्टि करें। Misses के लिए, स्थानीय रूप से पुनरुत्पादित करें, उपलब्ध DevTools आउटपुट का निरीक्षण करें, चाइल्ड फ़्रेम और थर्ड-पार्टी स्क्रिप्ट को अलग करें, और कोई कारण गढ़ने के बजाय एक अज्ञात बकेट बनाए रखें।
एनालिटिक्स को रिस्टोर किए गए पेज को कैसे संभालना चाहिए?
पहले एक उत्पाद परिभाषा चुनें। यदि एक रिस्टोर को पेज व्यू के रूप में गिना जाता है, तो pageshow.persisted से एक इवेंट उत्सर्जित करें और प्रारंभिक-लोड इंस्ट्रूमेंटेशन को रीप्ले करने से बचें। एक नेविगेशन-प्रकार फ़ील्ड शामिल करें ताकि विश्लेषक डॉक्यूमेंट लोड को रिस्टोर से अलग कर सकें। जहां उपयुक्त हो, विज़िट-स्कोप्ड परफ़ॉर्मेंस एक्यूमुलेटर को रीसेट करें, और दोहराव के लिए बार-बार Back/Forward चक्रों का परीक्षण करें।
क्या एक प्रमाणित चेकआउट पेज को bfcache का उपयोग करना चाहिए?
केवल तभी जब सुरक्षा नीति पेज स्नैपशॉट की अनुमति देती है और रिस्टोर पथ को सुरक्षित बनाया जा सकता है। रिस्टोर पर, सेशन और परिणामी डेटा को पुनः सत्यापित करें, जांच पूरी होने तक संवेदनशील कार्रवाइयों को ब्लॉक करें, और सर्वर-साइड ऑथराइजेशन और मूल्य सत्यापन को अनिवार्य रखें। यदि निजी सामग्री हिस्ट्री में पुनर्प्राप्त करने योग्य नहीं रहनी चाहिए, तो उस नीति को लागू करें और कम संवेदनशील रूटों पर bfcache ऑप्टिमाइज़ेशन केंद्रित करें।