प्रदर्शन बजट

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

यह समस्या ऑप्टिमाइज़ेशन के बजाय रिग्रेशन से संबंधित है। वेबसाइटें किसी एक निर्णय से धीमी नहीं होतीं; बल्कि कई छोटे-छोटे बदलावों से धीमी हो जाती हैं, जो देखने में इतने छोटे लगते हैं कि चिंता का कारण नहीं बनते। एक नया फ़ीचर, एक अतिरिक्त ट्रैकिंग स्क्रिप्ट, एक बड़ी हीरो इमेज, एक अलग फ़ॉन्ट साइज़ और एक कंपोनेंट लाइब्रेरी अपग्रेड, ये सभी बदलाव कुछ सेकंड का समय बढ़ाते हैं, और दो साल बाद वेबसाइट बिना किसी स्पष्ट कारण के काफ़ी धीमी हो जाती है। बजट के कारण हर बदलाव की एक सीमा होती है।

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

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

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

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

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

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