उच्च-आवृत्ति प्रकाशन के युग में फ्रंट-एंड डिलीवरी को कैशिंग और संपीड़न सहयोग को फिर से डिज़ाइन करने की आवश्यकता है
जैसे-जैसे संसाधन अधिक से अधिक खंडित होते जाते हैं और संस्करण अधिक से अधिक बार होते जाते हैं, यह अक्सर संपीड़न दर नहीं होती है जो वास्तव में सबसे पहले नियंत्रण से बाहर हो जाती है, बल्कि कैश कुंजियों, शब्दकोश संस्करणों और वापसी-से-मूल लागतों की रिलीज़ लय होती है।
एक बार जब फ्रंट-एंड संसाधन उच्च-आवृत्ति रिलीज़ लय में प्रवेश कर जाते हैं, तो प्रदर्शन संबंधी समस्याएं जल्द ही “ब्रॉटली को चालू करना” जितनी सरल नहीं रह जाएंगी। पहली स्क्रीन धीमी हो जाती है, बैक-टू-ओरिजिन ट्रैफ़िक बढ़ जाता है, और एज नोड सीपीयू घबरा जाता है। सतह पर, ऐसा लगता है कि संपीड़न पर्याप्त आक्रामक नहीं है। गहराई से देखने पर, अक्सर कैशिंग और कम्प्रेशन को अलग-अलग अनुकूलित किया जाता है, और अंततः प्रकाशन लिंक पर एक-दूसरे को कमजोर कर देते हैं।
इस तरह की समस्या आम तौर पर पहले संस्करण में सामने नहीं आती है। शुरुआत में, टीम को केवल कुछ बिखरे हुए संकेत दिखाई देंगे: एक छोटे से बदलाव के कारण स्थैतिक संसाधनों की हिट दर में गिरावट आई, एक प्रमुख पदोन्नति की पूर्व संध्या पर एज संपीड़न सीपीयू में असामान्य वृद्धि हुई, और ग्रेस्केल चरण में रिटर्न पैकेट की मात्रा आधिकारिक ट्रैफ़िक से मेल नहीं खाती। यदि आप जांच करना जारी रखते हैं, तो सुराग आमतौर पर एक ही चीज़ पर एकत्रित होते हैं: हालांकि संसाधन सामग्री केवल थोड़ी सी बदल गई है, कैश कुंजी, चंक विभाजन और संपीड़ित इनपुट चीजों का एक अलग सेट बन गए हैं, और परिवहन परत पूरी लागत को फिर से निगलने के लिए मजबूर है।
जब तक संसाधन हैश स्थिर नहीं होता, संपीड़न लाभ बस अस्थिर हैं।
कई पृष्ठों, कई मार्गों और कई टीमों के साथ समानांतर में फ्रंट-एंड प्रोजेक्ट जारी होने के बाद, सबसे आसानी से अनदेखा किया जाने वाला पहलू फ़ाइल नाम स्थिरता है। जब तक खंड विभाजन थोड़ा कम हो जाता है, भले ही व्यवसाय कोड केवल एक बटन की प्रतिलिपि बदलता है, अंतिम उत्पाद सार्वजनिक बंडलों की श्रृंखला के हैश को भी फिर से लिख सकता है। कैशिंग सिस्टम जो देखता है वह बिल्कुल नई वस्तुओं का एक बैच है, और संपीड़न सिस्टम जो देखता है वह इनपुट का एक बैच है जो पहली बार दिखाई देता है।
इस समय, संपीड़न दर चाहे कितनी भी अधिक क्यों न हो, यह हिट दर को ढहने से नहीं बचा सकती है। पुरानी फ़ाइलें अभी भी किनारे के नोड्स में पड़ी हुई हैं, और नई फ़ाइलें फिर से कुंजीबद्ध कर दी गई हैं; ब्राउज़र का स्थानीय कैश पूरी तरह से अमान्य है, और सीडीएन को स्रोत को फिर से खींचना होगा, फिर से संपीड़ित करना होगा और फिर से वितरित करना होगा। एक छोटे व्यवसाय परिवर्तन को संपूर्ण ट्रांसमिशन लिंक के लिए बार-बार किए जाने वाले कार्य में बढ़ाया जाता है।
वास्तव में उपयोगी कार्रवाई आमतौर पर संपीड़न स्तर को समायोजित करना जारी रखना नहीं है, बल्कि पहले जारी उत्पाद की स्थिरता को नियंत्रित करना है:
- व्यावसायिक परिवर्तनों को कम करने और हैश को बदलने के लिए बुनियादी पैकेजों को एक साथ लाने के लिए सार्वजनिक निर्भरता को अलग-अलग परतों में काटा जाता है।
- टाइमस्टैम्प जैसे उच्च-आवृत्ति परिवर्तनों को मिश्रित करने से बचें और संख्याओं को सीधे उत्पाद सामग्री में बनाएं
- एक ही रूट के पास के कोड को हर बार संकलित होने पर फेरबदल करने के बजाय जितना संभव हो सके स्थिर टुकड़ों में गिरने दें।
केवल जब संसाधन पहचान स्थिर हो जाती है तो कैश का लगातार पुन: उपयोग किया जा सकता है और संपीड़न परिणामों का संचयी मूल्य होता है।
उच्च-आवृत्ति प्रेस कॉन्फ्रेंस संपीड़न समस्या को शब्दकोश संस्करण समस्या में फिर से लिखती है
जैसे-जैसे संसाधन अधिक से अधिक खंडित होते जा रहे हैं, एकल-फ़ाइल ब्रॉटली या जीज़िप अभी भी महत्वपूर्ण है, लेकिन यह अब सब कुछ नहीं है। वास्तविक लागत डुप्लिकेट टुकड़ों की ओर स्थानांतरित होने लगती है: फ्रेमवर्क रनटाइम कोड, स्टाइल टेम्प्लेट, इंटरफ़ेस प्रकार की घोषणाएं, पैकेजर्स द्वारा उत्पन्न पैकेजिंग परतें, अक्सर संस्करणों के बैचों के बीच अत्यधिक समान होती हैं। तेज़ रिलीज़ टेम्पो के साथ, इन रिफ़्स को बार-बार स्थानांतरित किया जाएगा।
समस्या यह है कि यदि रिलीज़ ताल के साथ इसे प्रबंधित नहीं किया जाता है तो संपीड़न शब्दकोश आसानी से अनुकूलन से व्यवधान में बदल सकता है। यदि शब्दकोश पहले से बदल दिया जाता है, तो पुराने पृष्ठ द्वारा संदर्भित नया शब्दकोश बेमेल हो जाएगा; शब्दकोश को बहुत सारे टुकड़ों में काट दिया गया है, और किनारे के नोड्स द्वारा बनाए जाने वाले संस्करणों की संख्या तेजी से बढ़ गई है; शब्दकोश अद्यतन ऑनलाइन संसाधन के साथ सिंक्रनाइज़ नहीं है, और जिन वस्तुओं को हिट किया जाना चाहिए था वे पूर्ण ट्रांसमिशन पर वापस आ जाते हैं।
यह हालिया फ्रंट-एंड डिलीवरी में एक बहुत ही व्यावहारिक बदलाव है: कैशिंग रणनीतियों और संपीड़न प्रोटोकॉल को अब अलग-अलग टीमों द्वारा बनाए नहीं रखा जा सकता है। संसाधन संस्करण, शब्दकोश संस्करण और कैश कुंजी स्थान अनिवार्य रूप से एक ही प्रकाशन समस्या हैं।
निम्नलिखित जैसा एक पदानुक्रमित दृष्टिकोण आमतौर पर “संपूर्ण साइट के लिए एकीकृत मजबूत संपीड़न” की तुलना में अधिक स्थिर होता है:
const policy = {
immutableAssets: 'public, max-age=31536000, immutable',
releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
sharedDictionary: 'versioned-by-release-train'
}
मुख्य बात इन तीन पंक्तियों का विन्यास नहीं है, बल्कि वे बाधाएं हैं जो इसे व्यक्त करती हैं: लंबे जीवन चक्र संसाधन, लघु जीवन चक्र सूची और संपीड़ित शब्दकोश संस्करण को एक ही रिलीज लय के अनुसार एक साथ विकसित होना चाहिए।
स्रोत पर लौटने का दबाव अक्सर यह नहीं होता है कि फ़ाइल बहुत बड़ी है, बल्कि यह है कि विफलता विधि बहुत कठिन है।
एक और बहुत ही सामान्य गलत निर्णय यह है कि बैंडविड्थ में वृद्धि का श्रेय सीधे पृष्ठ के वजन को दिया जाता है। पन्ने निश्चित रूप से भारी होते जा रहे हैं, लेकिन ऑनलाइन अधिक खतरनाक एम्प्स आमतौर पर जाने का रास्ता हैं।
यदि आप हर बार प्रकाशित होने पर निर्देशिका, उपसर्ग या यहां तक कि पूरी साइट को शुद्ध करते हैं, तो कैश परत तुरंत अपनी मेमोरी खो देगी। इस समय, भले ही फ़ाइल का आकार बढ़ना जारी न रहे, रिटर्न-टू-ओरिजिन शिखर मान अपने आप बढ़ जाएगा। जैसे ही स्रोत वापस आता है, किनारों को फिर से संपीड़ित किया जाता है, वस्तुओं को फिर से गर्म किया जाता है, और ब्राउज़र को फिर से डाउनलोड किया जाता है। प्रकाशन विंडो एक छोटे चरण के परिवर्तन से पूर्ण साइट स्थानांतरण में बदल जाएगी।
इस प्रकार के परिदृश्य में, सबसे मूल्यवान चीज़ नियंत्रणीय विफलता त्रिज्या है:
- केवल मेनिफेस्ट, HTML और परिवर्तनीय संसाधनों को अमान्य करें जो वास्तव में बदल गए हैं
- हैश के साथ स्थिर फ़ाइलों को शुद्ध न करने का प्रयास करें, और उन्हें प्राकृतिक स्विचिंग के लिए नए संदर्भों को सौंप दें।
- उन सभी को एक साथ साफ़ करने के बजाय रिलीज़ को “पहले नए संसाधन अपलोड करें, फिर संदर्भों को काटें, फिर पुराने संसाधनों को रीसायकल करें” के क्रम में विभाजित करें
स्थानांतरण लागत के बारे में वास्तव में संवेदनशील बात न केवल फ़ाइल का आकार है, बल्कि यह भी है कि सिस्टम यह कैसे तय करता है कि कौन सी सामग्री पुनः प्राप्त की जानी चाहिए।
लागू सीमा संसाधन पैमाने और रिलीज़ आवृत्ति के साथ निर्धारित की जाती है।
सह-डिज़ाइन का यह सेट सभी साइटों के लिए आवश्यक नहीं है। स्थिर पृष्ठों की कम संख्या, छोटे संसाधन पैकेज और साप्ताहिक या यहां तक कि मासिक रिलीज आवृत्ति वाली परियोजनाओं के लिए, पारंपरिक हैश फ़ाइल नामों के साथ-साथ ब्रॉटली पूर्व-संपीड़न का उपयोग आमतौर पर पर्याप्त स्थिर होता है।
एक बार ये विशेषताएँ लागू हो जाने पर कैशिंग और कम्प्रेशन मिलकर तेजी से एक डिलीवरी इंफ्रास्ट्रक्चर बन जाते हैं:
- ग्रेस्केल, रोलबैक या क्षेत्रीय लॉन्च के साथ दिन में कई बार रिलीज़ किया गया
- फ्रंट-एंड उत्पाद आकार में बड़ा है, इसमें कई सार्वजनिक निर्भरताएँ हैं, और इसमें जटिल खंड संबंध हैं।
- सीडीएन, ऑब्जेक्ट स्टोरेज, एज कंप्रेशन और ब्राउज़र कैशिंग एक साथ ट्रांसमिशन लिंक में भाग लेते हैं
- ट्रैफ़िक इतना अधिक है कि कैश हिट दर और रिटर्न-टू-ओरिजिन शिखर मूल्य सीधे लागत और स्थिरता को प्रतिबिंबित करेगा।
फ्रंट-एंड डिलीवरी के इस चरण में प्रवेश करने के बाद, संपीड़न अब केवल “फ़ाइलों को छोटा बनाना” नहीं है, और कैशिंग अब केवल “सामग्री की अधिक प्रतियां संग्रहीत करना” नहीं है। दोनों मिलकर क्या निर्णय लेते हैं: एक छोटे व्यवसाय में बदलाव के लिए, क्या यह सिर्फ एक और हिस्सा भेजना है, या क्या पूरे ट्रांसमिशन लिंक को फिर से चलाने की आवश्यकता है। आप जितनी अधिक बार प्रकाशित करेंगे, यह अंतर उतना ही महंगा होता जाएगा।
What to read next
Want more posts about Frontend?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #Frontend?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home