यह आलेख उत्तरदायी, तेज़ उपयोगकर्ता इंटरफ़ेस को लागू करने के लिए फ्रंट-एंड एप्लिकेशन लोड करने की गति बढ़ाने के लिए कुछ विधियों का वर्णन करता है।

हम सामने वाले के सामान्य आर्किटेक्चर पर चर्चा करेंगे, आवश्यक संसाधनों को कैसे प्रीलोड करें और संभावना है कि वे कैश में हैं। हम एक छोटी सी चर्चा करेंगे कि बैकएंड से संसाधनों को कैसे दिया जाए और जब एक इंटरैक्टिव क्लाइंट एप्लिकेशन के बजाय खुद को स्थिर पृष्ठों तक सीमित करना संभव हो।

डाउनलोड प्रक्रिया को तीन चरणों में विभाजित किया गया है। प्रत्येक चरण के लिए, हम उत्पादकता बढ़ाने के लिए सामान्य रणनीति बनाते हैं:

प्रारंभिक प्रतिपादन : उपयोगकर्ता को कम से कम कुछ देखने में कितना समय लगता है
- ब्लॉकिंग अनुरोधों को कम करना
- अनुक्रमिक श्रृंखलाओं से बचें
- सर्वर कनेक्शन का पुन: उपयोग करें
- त्वरित प्रतिपादन के लिए सेवा कर्मी
: ,
- . .
- ,
:
- ,

प्रारंभिक प्रतिपादन तक, उपयोगकर्ता स्क्रीन पर कुछ भी नहीं देखता है। इस प्रतिपादन के लिए हमें क्या चाहिए? न्यूनतम पर, एक HTML दस्तावेज़ अपलोड करें, और ज्यादातर मामलों में अतिरिक्त संसाधन, जैसे सीएसएस और जावास्क्रिप्ट फाइलें। एक बार जब वे उपलब्ध हो जाते हैं, तो ब्राउज़र किसी तरह का प्रतिपादन शुरू कर सकता है।

इस आलेख में WebPageTest चार्ट प्रदान किए गए हैं । आपकी साइट के लिए क्वेरी अनुक्रम संभवतः कुछ इस तरह दिखाई देगा।

HTML दस्तावेज़ अतिरिक्त फ़ाइलों का एक गुच्छा लोड करता है, और डाउनलोड किए जाने के बाद पृष्ठ प्रदान किया जाता है। कृपया ध्यान दें कि सीएसएस फाइलें एक दूसरे के समानांतर लोड की जाती हैं, इसलिए प्रत्येक अतिरिक्त अनुरोध महत्वपूर्ण देरी नहीं जोड़ता है।

(नोट: स्क्रीनशॉट में, gov.uk एक उदाहरण है जहां HTTP / 2 अब सक्षम हैताकि संसाधन डोमेन किसी मौजूदा कनेक्शन का पुन: उपयोग कर सके। सर्वर कनेक्शन के लिए नीचे देखें।)

ब्लॉकिंग अनुरोधों को कम करना

शैली पत्रक और (डिफ़ॉल्ट रूप से) स्क्रिप्ट उनके नीचे किसी भी सामग्री के प्रतिपादन को अवरुद्ध करते हैं।

इसे ठीक करने के लिए कई विकल्प हैं:

स्क्रिप्ट टैग को शरीर के निचले भाग में ले जाएं
अतुल्यकालिक मोड का उपयोग करके स्क्रिप्ट डाउनलोड करें async
यदि JS या CSS को क्रमिक रूप से लोड किया जाना चाहिए, तो उन्हें छोटे स्निपेट के साथ एम्बेड करना बेहतर होता है

अनुक्रमिक अनुरोधों के साथ वार्तालाप से बचें जो प्रतिपादन प्रदान करते हैं

साइट को रेंडर करने में देरी जरूरी नहीं है कि बड़ी संख्या में अनुरोधों को ब्लॉक करने के साथ जुड़ा हो। अधिक महत्वपूर्ण प्रत्येक संसाधन का आकार है, साथ ही इसके डाउनलोड का प्रारंभ समय भी है। यही है, वह क्षण जब ब्राउज़र को अचानक पता चलता है कि इस संसाधन को डाउनलोड करने की आवश्यकता है।

यदि ब्राउज़र किसी अन्य अनुरोध को पूरा करने के बाद ही फ़ाइल डाउनलोड करने की आवश्यकता का पता लगाता है, तो अनुरोधों की एक श्रृंखला है। यह विभिन्न कारणों से बन सकता है:

@importसीएसएस नियम
CSS फ़ाइल द्वारा संदर्भित वेब फोंट
डाउनलोड करने योग्य जावास्क्रिप्ट या स्क्रिप्ट टैग

इस उदाहरण पर एक नज़र डालें:

इस साइट पर सीएसएस फ़ाइलों में से एक नियम के माध्यम से Google फ़ॉन्ट लोड करती है @import। इसका अर्थ है कि ब्राउज़र को निम्नलिखित अनुरोधों को पूरा करना होगा:

HTML डॉक्यूमेंट
सीएसएस अनुप्रयोगों
Google फ़ॉन्ट्स के लिए सीएसएस
Google फ़ॉन्ट Woff फ़ाइल (आरेख में नहीं दिखाया गया है)

इसे ठीक करने के लिए, पहले Google फ़ॉन्ट्स सीएसएस अनुरोध को टैग @importसे लिंक करके HTML दस्तावेज़ में ले जाएं। इसलिए हम एक लिंक द्वारा चेन को छोटा करते हैं।

आगे भी चीजों को गति देने के लिए, Google फ़ॉन्ट्स CSS को सीधे अपने HTML या CSS फ़ाइल में एम्बेड करें।

(ध्यान रखें कि Google फ़ॉन्ट्स सर्वर से सीएसएस प्रतिक्रिया उपयोगकर्ता एजेंट लाइन पर निर्भर करती है। यदि आप IE8 का उपयोग करके अनुरोध करते हैं, तो सीएसएस ईओटी फ़ाइल को संदर्भित करेगा, IE11 ब्राउज़र को woff फ़ाइल प्राप्त होगी, और आधुनिक ब्राउज़र को woff2 फ़ाइल प्राप्त होगी। यदि आप सहमत हैं। पुराने ब्राउज़र सिस्टम फोंट तक सीमित होंगे, आप बस CSS फ़ाइल की सामग्री को स्वयं कॉपी और पेस्ट कर सकते हैं)।

रेंडरिंग की शुरुआत के बाद भी, उपयोगकर्ता पेज के साथ बातचीत करने में सक्षम होने की संभावना नहीं है, क्योंकि पाठ को प्रदर्शित करने के लिए फ़ॉन्ट को लोड करने की आवश्यकता होती है। यह एक अतिरिक्त नेटवर्क देरी है जिससे मैं बचना चाहूंगा। स्वैप पैरामीटर यहां उपयोगी है , यह आपको font-displayGoogle फ़ॉन्ट्स के साथ उपयोग करने की अनुमति देता है , और स्थानीय रूप से फ़ॉन्ट संग्रहीत करता है।

कभी-कभी क्वेरी श्रृंखला को हल नहीं किया जा सकता है। ऐसे मामलों में, आप प्रीलोड या प्री-कनेक्ट टैग पर विचार करना चाह सकते हैं । उदाहरण के लिए, ऊपर दिए गए उदाहरण में वेबसाइट fonts.googleapis.comवास्तविक CSS अनुरोध आने से पहले कनेक्ट हो सकती है।

अनुरोधों को गति देने के लिए सर्वर कनेक्शन का पुन: उपयोग करना

सर्वर में एक नया कनेक्शन स्थापित करने के लिए, आमतौर पर ब्राउज़र और सर्वर के बीच तीन पैकेट एक्सचेंजों की आवश्यकता होती है:

डीएनएस लुकअप
एक टीसीपी कनेक्शन स्थापित करें
एक SSL कनेक्शन स्थापित करें

कनेक्शन स्थापित होने के बाद, अनुरोध भेजने और प्रतिक्रिया प्राप्त करने के लिए कम से कम एक और पैकेट विनिमय की आवश्यकता होती है।

नीचे दिया गया चार्ट है कि हम चार अलग-अलग सर्वर के साथ एक कनेक्शन आरंभ: hostgator.com, optimizely.com, googletagmanager.com, और googelapis.com।

हालाँकि, बाद के सर्वर अनुरोध मौजूदा कनेक्शन का पुन: उपयोग कर सकते हैं । डाउनलोड base.cssया तो index1.cssतेजी से होता है क्योंकि वे उसी सर्वर पर स्थित होते हैं hostgator.comजिसके साथ एक कनेक्शन पहले ही स्थापित हो चुका है।

फ़ाइल का आकार कम करें और CDN का उपयोग करें

आप क्वेरी निष्पादन समय को प्रभावित करने वाले दो कारकों को नियंत्रित करते हैं: संसाधन फ़ाइलों का आकार और सर्वर का स्थान।

उपयोगकर्ता को यथासंभव कम डेटा भेजें और सुनिश्चित करें कि वे संकुचित हैं (उदाहरण के लिए, ब्रेटली या गज़िप का उपयोग करके)।

सामग्री वितरण नेटवर्क (सीडीएन) में दुनिया भर के सर्वर हैं। एक केंद्रीय सर्वर से कनेक्ट करने के बजाय, एक उपयोगकर्ता सीडीएन सर्वर से जुड़ सकता है जो करीब है। इस प्रकार, पैकेट विनिमय बहुत तेज होगा। यह सीएसएस, जावास्क्रिप्ट और छवियों जैसे स्थिर संसाधनों के लिए विशेष रूप से उपयुक्त है, क्योंकि वे सीडीएन के माध्यम से वितरित करना आसान है।

सेवा कर्मचारियों के साथ नेटवर्क विलंबता को समाप्त करें

सेवा कार्यकर्ता आपको नेटवर्क पर भेजने से पहले अनुरोधों को रोकना चाहते हैं। इसका मतलब है कि उत्तर लगभग तुरंत आता है !

बेशक, यह केवल तभी काम करता है जब आपको नेटवर्क से डेटा प्राप्त करने की आवश्यकता न हो। जवाब पहले से ही कैश होना चाहिए, इसलिए लाभ केवल दूसरे एप्लिकेशन डाउनलोड से दिखाई देगा।

पृष्ठ को रेंडर करने के लिए आवश्यक HTML और CSS को सेवा कार्यकर्ता नीचे देता है। जब एप्लिकेशन फिर से लोड होता है, तो यह स्वयं कैश्ड संसाधनों को जारी करने की कोशिश करता है - और नेटवर्क तक तभी पहुंचता है जब वे अनुपलब्ध हों।

self.addEventListener("install", async e => {
 caches.open("v1").then(function (cache) {
   return cache.addAll(["/app", "/app.css"]);
 });
});

self.addEventListener("fetch", event => {
 event.respondWith(
   caches.match(event.request).then(cachedResponse => {
     return cachedResponse || fetch(event.request);
   })
 );
});

में इस गाइड, प्रीलोड और कैश संसाधनों के लिए सेवा workers` के उपयोग पर विस्तार से समझाया।

एप्लिकेशन डाउनलोड करें

इसलिए, उपयोगकर्ता स्क्रीन पर कुछ देखता है। एप्लिकेशन का उपयोग करने के लिए उसके लिए और क्या कदम आवश्यक हैं?

एप्लिकेशन कोड डाउनलोड करें (JS और CSS)
पृष्ठ के लिए आवश्यक डेटा डाउनलोड करें
अतिरिक्त डेटा और चित्र डाउनलोड करें

कृपया ध्यान दें कि न केवल नेटवर्क से डेटा डाउनलोड करने से रेंडरिंग में देरी हो सकती है। एक बार आपका कोड लोड हो जाने पर, ब्राउज़र को उसका विश्लेषण, संकलन और निष्पादन करना चाहिए।

केवल आवश्यक कोड डाउनलोड करें और कैश में हिट की संख्या को अधिकतम करें

"एक पैकेज को तोड़ें" का अर्थ है वर्तमान पृष्ठ के लिए आवश्यक कोड को डाउनलोड करना, न कि संपूर्ण एप्लिकेशन को। इसका मतलब यह भी है कि पैकेज के कुछ हिस्सों को कैश किया जा सकता है, भले ही अन्य भागों को बदल दिया गया हो और फिर से लोड करने की आवश्यकता हो।

एक नियम के रूप में, कोड को निम्नलिखित भागों में विभाजित किया गया है:

किसी विशिष्ट पृष्ठ (पृष्ठ-विशिष्ट) के लिए कोड
आम आवेदन कोड
तृतीय-पक्ष मॉड्यूल जो शायद ही कभी बदलते हैं (कैशिंग के लिए महान!)

वेबपैक स्वचालित रूप से इस अनुकूलन को कर सकता है, कोड को तोड़ सकता है, और समग्र भार को कम कर सकता है। कोड को ऑप्टिमाइज़ेशन का उपयोग करके टुकड़ों में तोड़ा जाता है ।plitChunks ऑब्जेक्ट । रनटाइम (रनटाइम) को एक अलग फाइल में अलग करें: इस तरह से आप दीर्घकालिक कैशिंग से लाभ उठा सकते हैं। इवान अकुलाव ने एक पैकेज को अलग-अलग फाइलों में तोड़ने और वेबपैक में कैशिंग पर एक विस्तृत गाइड लिखा ।

किसी विशिष्ट पृष्ठ के लिए कोड का स्वचालित रूप से चयन करना संभव नहीं है। आपको उन हिस्सों को मैन्युअल रूप से पहचानना होगा जिन्हें अलग से डाउनलोड किया जा सकता है। अक्सर यह एक विशिष्ट पथ या पृष्ठों का सेट होता है। इस कोड को लोड करने के लिए गतिशील आयात का उपयोग करें ।

समग्र पैकेज को भागों में विभाजित करने से आपके एप्लिकेशन को डाउनलोड करने के लिए अनुरोधों की संख्या बढ़ जाएगी। लेकिन यह एक बड़ी समस्या नहीं है अगर अनुरोधों को समानांतर में निष्पादित किया जाता है, खासकर यदि साइट HTTP / 2 प्रोटोकॉल का उपयोग करके लोड की जाती है। आप निम्न आरेख में पहले तीन प्रश्नों के लिए इसे देख सकते हैं:

हालाँकि, आरेख में लगातार दो प्रश्न भी दिखाई देते हैं। इन टुकड़ों की आवश्यकता केवल इस विशेष पृष्ठ के लिए होती है और इन्हें गतिशील रूप से लोड किया जाता है import()।

आप टैग प्रीलोड प्रीलोड डालकर समस्या को ठीक करने का प्रयास कर सकते हैं ।

लेकिन हम देखते हैं कि कुल पृष्ठ लोड समय बढ़ गया है।

संसाधन प्रीलोडिंग कभी-कभी उल्टा होता है क्योंकि यह अधिक महत्वपूर्ण फाइलों के लोडिंग में देरी करता है। पढ़ेंफोंट लोड करने के बारे में एंडी डेविस का लेख और यह प्रक्रिया पेज रेंडरिंग की शुरुआत को कैसे रोकती है ।

पृष्ठ के लिए डेटा लोड हो रहा है

आपके एप्लिकेशन को संभवतः कुछ डेटा दिखाना चाहिए। यहां कुछ युक्तियां दी गई हैं जिनका उपयोग करके आप अनावश्यक रेंडरिंग देरी के बिना इस डेटा को जल्दी डाउनलोड कर सकते हैं।

डेटा डाउनलोड करने से पहले पैकेज के पूर्ण डाउनलोड की प्रतीक्षा न करें

यहां अनुक्रमिक अनुरोधों की एक श्रृंखला का एक विशेष मामला है: आप पूरे एप्लिकेशन पैकेज को डाउनलोड करते हैं, और फिर यह कोड पृष्ठ के लिए आवश्यक डेटा का अनुरोध करता है।

इससे बचने के दो तरीके हैं:

एक HTML दस्तावेज़ में डेटा एम्बेड करें
दस्तावेज़ के अंदर अंतर्निहित स्क्रिप्ट का उपयोग करके डेटा अनुरोध चलाएँ

HTML में डेटा एम्बेड करना सुनिश्चित करता है कि एप्लिकेशन लोड होने का इंतजार नहीं करता है। यह सिस्टम की जटिलता को भी कम करता है, क्योंकि आपको बूट स्थिति को संभालने की आवश्यकता नहीं है।

हालांकि, यह एक अच्छा विचार नहीं है यदि ऐसी तकनीक प्रारंभिक प्रतिपादन में देरी करती है।

इस मामले में, साथ ही साथ यदि आप एक सेवा कार्यकर्ता के माध्यम से कैश्ड एचटीएमएल दस्तावेज़ जमा कर रहे हैं, तो आप इस डेटा को विकल्प के रूप में डाउनलोड करने के लिए अंतर्निहित स्क्रिप्ट का उपयोग कर सकते हैं। आप इसे एक वैश्विक वस्तु के रूप में उपलब्ध करा सकते हैं, यहाँ एक वादा है:

window.userDataPromise = fetch("/me")

यदि डेटा तैयार है, और ऐसी स्थिति में, एप्लिकेशन तुरंत रेंडर करना शुरू कर सकता है या तैयार होने तक प्रतीक्षा कर सकता है।

दोनों विधियों का उपयोग करते समय, आपको पहले से यह जानना होगा कि एप्लिकेशन रेंडर करने से पहले पेज क्या डेटा लोड करेगा। यह आमतौर पर उपयोगकर्ता-संबंधित डेटा (उपयोगकर्ता नाम, सूचनाएं, आदि) के लिए स्पष्ट है, लेकिन ऐसी सामग्री के साथ अधिक कठिन है जो किसी विशेष पृष्ठ के लिए विशिष्ट है। शायद यह सबसे महत्वपूर्ण पृष्ठों को उजागर करने और उनके लिए अपना तर्क लिखने के लिए समझ में आता है।

अप्रासंगिक डेटा की प्रतीक्षा करते हुए रेंडरिंग को ब्लॉक न करें

कभी-कभी, डेटा उत्पन्न करने के लिए, आपको बैकएंड पर धीमी गति से जटिल तर्क चलाने की आवश्यकता होती है। ऐसे मामलों में, आप पहले डेटा का एक सरल संस्करण डाउनलोड करने का प्रयास कर सकते हैं, यदि यह एप्लिकेशन को कार्यात्मक और इंटरैक्टिव बनाने के लिए पर्याप्त है।

उदाहरण के लिए, एक एनालिटिक्स टूल डेटा लोड करने से पहले सबसे पहले सभी चार्ट की सूची डाउनलोड कर सकता है। यह उपयोगकर्ता को तुरंत उसके लिए रुचि के आरेख की खोज करने की अनुमति देता है, और विभिन्न सर्वरों को बैकएंड अनुरोधों को वितरित करने में भी मदद करता है।

लगातार डेटा क्वेरी से बचें

यह पिछले पैराग्राफ के विपरीत हो सकता है कि गैर-जरूरी डेटा को अलग अनुरोध में रखना बेहतर है। इसलिए, यह स्पष्ट किया जाना चाहिए: अनुक्रमिक डेटा अनुरोधों के साथ जंजीरों से बचें, अगर प्रत्येक पूरा अनुरोध इस तथ्य को जन्म नहीं देता है कि उपयोगकर्ता को अन्य जानकारी दिखाई जाती है ।

पहले क्वेरी करने के बजाय जो उपयोगकर्ता लॉग इन किया गया है और फिर अपने समूहों की सूची का अनुरोध कर रहा है, तुरंत पहले क्वेरी में उपयोगकर्ता जानकारी के साथ समूहों की सूची वापस करें। आप इसके लिए ग्राफक्यूएल का उपयोग कर सकते हैं , लेकिन समापन बिंदु user?includeTeams=trueभी ठीक काम करता है।

सर्वर साइड प्रतिपादन

सर्वर-साइड रेंडरिंग का अर्थ है आवेदन को पूर्व-रेंडर करना, इसलिए क्लाइंट अनुरोध पर एक पूर्ण-पृष्ठ HTML वापस किया जाता है। ग्राहक अतिरिक्त कोड या डेटा लोड होने की प्रतीक्षा किए बिना पृष्ठ को पूरी तरह से प्रदान करता है!

चूंकि सर्वर क्लाइंट को सिर्फ स्थिर HTML भेजता है, इसलिए इस बिंदु पर एप्लिकेशन इंटरएक्टिव नहीं है। आपको एप्लिकेशन को स्वयं डाउनलोड करना होगा, रेंडरिंग लॉजिक शुरू करना होगा, फिर आवश्यक ईवेंट श्रोताओं को DOM से जोड़ना होगा।

यदि गैर-संवादात्मक सामग्री अपने आप में मूल्यवान है, तो सर्वर-साइड रेंडरिंग का उपयोग करें। सर्वर पर HTML को कैश करना भी अच्छा है और बिना किसी देरी के तुरंत इसे सभी उपयोगकर्ताओं को लौटा दें। उदाहरण के लिए, ब्लॉग पोस्ट प्रदर्शित करने के लिए रिएक्ट का उपयोग करते समय सर्वर-साइड रेंडरिंग महान है।

एटीमिखाइल यानशेख के इस लेख में सेवा श्रमिकों और सर्वर-साइड रेंडरिंग को संयोजित करने का तरीका बताया गया है।

अगला पृष्ठ

कुछ बिंदु पर, उपयोगकर्ता एक बटन दबाने और अगले पृष्ठ पर जाने वाला है। जिस क्षण से आप प्रारंभ पृष्ठ खोलते हैं, आप ब्राउज़र में क्या होता है, को नियंत्रित करते हैं, इसलिए आप अगली बातचीत के लिए तैयारी कर सकते हैं।

संसाधन प्रीलोडिंग

यदि आप अगले पृष्ठ के लिए आवश्यक कोड लोड करते हैं, तो उपयोगकर्ता के नेविगेशन शुरू करने में देरी गायब हो जाती है। प्रीफ़ैच टैग या webpackPrefetchडायनेमिक आयात के लिए उपयोग करें :

import(
    /* webpackPrefetch: true, webpackChunkName: "todo-list" */ "./TodoList"
)

ट्रैफ़िक और बैंडविड्थ के संदर्भ में उपयोगकर्ता पर किस तरह का भार है, इस पर विचार करें, खासकर अगर वह मोबाइल कनेक्शन के माध्यम से जुड़ा हुआ है। यदि कोई व्यक्ति साइट का मोबाइल संस्करण डाउनलोड करता है और डेटा स्टोरेज मोड सक्रिय है, तो कम आक्रामक तरीके से प्रीलोड करना उचित है।

रणनीतिक रूप से विचार करें कि उपयोगकर्ता को आवेदन के पहले किन हिस्सों की आवश्यकता होगी।

पहले से डाउनलोड किए गए डेटा का पुन: उपयोग

अपने एप्लिकेशन में स्थानीय रूप से डेटा कैश करें और भविष्य के अनुरोधों से बचने के लिए इसका उपयोग करें। यदि उपयोगकर्ता अपने समूहों की सूची से "संपादन समूह" पृष्ठ पर जाता है, तो आप समूह के बारे में पहले से डाउनलोड किए गए डेटा का पुन: उपयोग करते हुए, तुरंत संक्रमण कर सकते हैं।

कृपया ध्यान दें कि यह काम नहीं करेगा यदि ऑब्जेक्ट को अक्सर अन्य उपयोगकर्ताओं द्वारा संपादित किया जाता है और डाउनलोड किया गया डेटा पुराना हो सकता है। इन मामलों में, पहले अद्यतन किए गए डेटा के अनुरोध को निष्पादित करते समय मौजूदा रीड-ओनली डेटा दिखाने का विकल्प होता है।

निष्कर्ष

यह आलेख कई कारकों को सूचीबद्ध करता है जो लोडिंग प्रक्रिया के विभिन्न चरणों में आपके पृष्ठ को धीमा कर सकते हैं। Chrome DevTools , WebPageTest और Lighthouse जैसे टूल आपको यह पता लगाने में मदद करेंगे कि इनमें से कौन सा कारक आपके एप्लिकेशन को प्रभावित करता है।

व्यवहार में, शायद ही कभी अनुकूलन सभी दिशाओं में तुरंत जा रहा हो। हमें यह पता लगाने की आवश्यकता है कि उपयोगकर्ताओं पर सबसे अधिक प्रभाव क्या है, और इस पर ध्यान केंद्रित करें।

जब मैं लेख लिख रहा था, मुझे एक महत्वपूर्ण बात का एहसास हुआ: मुझे विश्वास था कि प्रदर्शन के लिए कई व्यक्तिगत सर्वर अनुरोध खराब थे। यह अतीत में ऐसा था, जब प्रत्येक अनुरोध के लिए एक अलग कनेक्शन की आवश्यकता होती थी, और ब्राउज़र प्रति डोमेन केवल कुछ कनेक्शन की अनुमति देते थे। लेकिन HTTP / 2 और आधुनिक ब्राउज़रों के साथ ऐसा नहीं है।

भागों में एप्लिकेशन को विभाजित करने (प्रश्नों को गुणा करने के साथ) के पक्ष में अच्छे तर्क हैं। यह आपको केवल आवश्यक संसाधन डाउनलोड करने की अनुमति देता है और कैश का उपयोग करना बेहतर होता है, क्योंकि केवल परिवर्तित फ़ाइलों को फिर से लोड करना होगा।

गति को बढ़ाता है। जब बहुत सारे सर्वर रिक्वेस्ट अच्छे होते हैं