08 अक्टू॰ 2025·8 मिनट
प्रदर्शन बजट जो काम करते हैं: तेज़ वेब ऐप्स के लिए व्यावहारिक सीमाएँ
प्रदर्शन बजट वेब ऐप्स को तेज़ रखने में मदद करते हैं: लोड समय, JS साइज और Core Web Vitals पर साफ़ सीमाएँ, साथ में त्वरित ऑडिट और फिक्स‑फ़र्स्ट नियम।
प्रदर्शन बजट वेब ऐप्स को तेज़ रखने में मदद करते हैं: लोड समय, JS साइज और Core Web Vitals पर साफ़ सीमाएँ, साथ में त्वरित ऑडिट और फिक्स‑फ़र्स्ट नियम।
प्रदर्शन बजट ऐसे साफ़ सीमाएँ हैं जिन पर आप बिल्ड शुरू करने से पहले सहमति बनाते हैं। ये समय की सीमा हो सकती है (पेज कितना तेज़ महसूस होता है), आकार की सीमा हो सकती है (कितना कोड भेजते हैं), या सरल कैप हो सकता है (रिक्वेस्ट्स, इमेजेस, थर्ड‑पार्टी स्क्रिप्ट)। अगर आप सीमा पार कर गए तो इसे "बाद में ठीक कर लेंगे" की बजाय एक टूटे हुए आवश्यकता की तरह माना जाता है।
स्पीड खराब इसलिए होती है क्योंकि शिपिंग जोड़ती चली जाती है। हर नया विजेट JavaScript, CSS, फॉन्ट्स, इमेजेज़, API कॉल और ब्राउज़र के लिए और काम जोड़ता है। छोटे‑छोटे बदलाव जमा होते हैं और ऐप भारी महसूस करने लगता है, खासकर मिड‑रेंज फोन और धीमे नेटवर्क पर जहां ज़्यादातर असली यूज़र्स होते हैं।
रायें आपके बचाव नहीं करेंगी। कोई कहेगा “मेरे लैपटॉप पर ठीक लगता है,” तो कोई कहेगा “धीमा है,” और टीम बहस में पड़ जाएगी। एक बजट बहस खत्म कर देता है और प्रदर्शन को मापने और लागू करने योग्य उत्पाद सीमा बना देता है।
यहाँ Addy Osmani की सोच फिट बैठती है: प्रदर्शन को डिज़ाइन सीमाओं और सुरक्षा नियमों की तरह ट्रीट करें। आप "कोशिश" नहीं करते कि सुरक्षित रहें या "आशा" नहीं करते कि लेआउट सही दिखे। आप मानक सेट करते हैं, उन्हें लगातार चेक करते हैं, और बदलावों को रोकते हैं जो उन्हें तोड़ते हैं।
बजट कई व्यावहारिक समस्याओं को एक साथ हल करते हैं। वे ट्रेडऑफ़ स्पष्ट करते हैं (एक फीचर जोड़ने का मतलब कहीं और भुगतान करना), वे रेग्रेशन जल्दी पकड़ते हैं (जब फिक्स सस्ते होते हैं), और सबको "पर्याप्त तेज़" की एक ही परिभाषा देते हैं। वे लॉन्च के ठीक पहले आने वाली दहशत को भी कम करते हैं।
उदाहरण के लिए: आप एक डैशबोर्ड के लिए रिच चार्टिंग लाइब्रेरी जोड़ते हैं। यह सभी यूज़र्स तक पहुंच जाती है, मेन बंडल बढ़ाता है, और पहला मायने रखता स्क्रीन देर हो जाती है। बिना बजट के यह छूट जाता क्योंकि फीचर "काम करता है"। बजट के साथ टीम को चुनना होगा: चार्ट को lazy-load करें, लाइब्रेरी बदलें, या व्यू को सरल बनाएं।
यह और भी ज़रूरी है जब टीम तेजी से ऐप जनरेट और इटरेट कर सकती है, जैसे चैट‑ड्रिवन बिल्ड वर्कफ़्लो Koder.ai के साथ। स्पीड अच्छी है, लेकिन यह आसानी से अतिरिक्त डिपेंडेंसी और UI निखार बिना ध्यान दिए भेजना आसान बनाती है। बजट तेज़ इटरेशन को धीमे उत्पाद में बदलने से रोकते हैं।
प्रदर्शन का काम तब फेल होता है जब आप सब कुछ मापते हैं और किसी के पास स्वामित्व नहीं होता। एक पेज फ्लो चुनें जो असली यूज़र्स के लिए मायने रखता हो, और उसे अपने बजट के लिए एंकर मानें।
एक अच्छा शुरुआत बिंदु वह प्राथमिक जर्नी है जहाँ स्पीड कन्वर्ज़न या दैनिक काम को प्रभावित करती है, जैसे "होम से साइनअप", "लॉगिन के बाद डैशबोर्ड का पहला लोड", या "चेकआउट और पेमेंट कन्फर्मेशन"। कुछ प्रतिनिधि और बार‑बार होने वाला चुनें, एज केस नहीं।
आपका ऐप आपके लैपटॉप पर नहीं चलता। एक बजट जो तेज़ मशीन पर ठीक लगता है, मिड‑रेंज फोन पर धीमा महसूस हो सकता है।
एक डिवाइस क्लास और एक नेटवर्क प्रोफ़ाइल चुनें। सरल रखें और इसे एक वाक्य में लिखें जिसे हर कोई दोहरा सके।
उदाहरण: पिछले 2–3 साल का एक मिड‑रेंज Android फोन, 4G पर चलते‑फिरते (ऑफिस Wi‑Fi नहीं), ठंडे लोड और फिर एक मुख्य नेविगेशन को मापते हुए, उसी रीजन में जहाँ ज़्यादातर यूज़र्स हैं।
यह सबसे खराब केस चुनने के बारे में नहीं है। यह एक सामान्य केस चुनने के बारे में है जिसे आप वास्तव में ऑप्टिमाइज़ कर सकते हैं।
नंबर तभी मायने रखते हैं जब वे तुलनात्मक हों। अगर एक रन "Chrome में एक्सटेंशंस के साथ MacBook" और अगला "थ्रॉटल्ड मोबाइल" है, आपकी ट्रेंड लाइन शोर बन जाएगी।
एक बेसलाइन एनवायरनमेंट चुनें और बजट चेक के लिए उसी पर टिके रहें: वही ब्राउज़र वर्शन, वही थ्रॉटलिंग सेटिंग, वही टेस्ट पाथ, और वही कैश स्टेट (cold या warm)। अगर आप रियल डिवाइसेज़ उपयोग करते हैं, तो वही डिवाइस मॉडल रखें।
अब यह परिभाषित करें कि "पर्याप्त तेज़" व्यवहार के हिसाब से क्या है, न कि परफ़ेक्ट डेमो के हिसाब से। उदाहरण: "यूज़र्स जल्दी सामग्री पढ़ना शुरू कर सकते हैं" या "लॉगिन के बाद डैशबोर्ड रिस्पोंसिव महसूस होता है।" इसे एक या दो मेट्रिक्स में अनुवाद करें और इनके चारों ओर बजट सेट करें।
बजट सबसे अच्छा तभी काम करते हैं जब वे उपयोगकर्ता के अनुभव और टीम के नियंत्रण दोनों को कवर करें। अच्छा सेट अनुभव मेट्रिक्स ("क्या यह तेज़ लगा?") के साथ संसाधन और CPU सीमाएं ("धीमा क्यों हुआ?") मिलाता है।
ये ट्रैक करते हैं कि पेज असली लोगों के लिए कैसा व्यवहार करता है। सबसे उपयोगी वे हैं जो सीधे Core Web Vitals से मैप होते हैं:
टाइमिंग बजट आपका नॉर्थ स्टार होते हैं क्योंकि वे यूज़र की फ़्रस्ट्रेशन से मिलते हैं। लेकिन ये हमेशा यह नहीं बतातें कि क्या ठीक करना है, इसलिए आपको नीचे दिए अन्य बजट भी चाहिए।
ये बिल्ड्स और रिव्यूज़ में लागू करना आसान हैं क्योंकि ये ठोस होते हैं।
वेट बजट कुल JavaScript, कुल CSS, इमेज वेट और फॉन्ट वेट जैसी चीज़ों को कैप करते हैं। रिक्वेस्ट बजट कुल रिक्वेस्ट काउंट और थर्ड‑पार्टी स्क्रिप्ट्स को सीमित करते हैं, जो नेटवर्क ओवरहेड और टैग्स/विजेट्स/ट्रैकर से आने वाले सरप्राइज़ काम को कम करते हैं। रनटाइम बजट लम्बे टास्क्स, मेन‑थ्रेड समय, और हाइड्रेशन टाइम (खासकर React के लिए) को सीमित करते हैं, जो अक्सर बताते हैं कि पेज मिड‑रेंज फोन पर "क्यों" धीमा लगता है।
एक व्यावहारिक React उदाहरण: बंडल साइज ठीक लग सकता है, लेकिन एक नया कैरोसेल भारी क्लाइंट‑साइड रेंडरिंग जोड़ देता है। पेज लोड हो जाता है, फिर भी फ़िल्टर्स टैप करने पर चिपचिपा महसूस होता है क्योंकि हाइड्रेशन मेन थ्रेड को ब्लॉक कर रही है। एक रनटाइम बजट जैसे "स्टार्टअप के दौरान no long tasks X ms से अधिक नहीं" या "मिड‑टियर डिवाइस पर हाइड्रेशन Y सेकंड में पूरा हो" इस मुद्दे को पकड़ सकता है जब वेट बजट नहीं पकड़ते।
सबसे मजबूत दृष्टिकोण इन सबको एक सिस्टम की तरह ट्रीट करता है: अनुभव बजट सफलता परिभाषित करते हैं, और आकार/रिक्वेस्ट/रनटाइम बजट रिलीज़ को ईमानदार रखते हैं और यह बताना आसान बनाते हैं कि “कया बदला?”
अगर आप बहुत सारी सीमाएँ सेट कर देंगे, लोग ध्यान देना बंद कर देंगे। 3–5 बजट चुनें जो उपयोगकर्ता के अनुभव से मेल खाते हों और जिन्हें आप हर PR या रिलीज़ पर माप सकें।
एक व्यावहारिक शुरुआती सेट (बाद में नंबर ट्यून करें):
दो थ्रेशहोल्ड चीज़ों को समझदार बनाते हैं। “Warn” बताता है कि आप ड्रिफ्ट कर रहे हैं। “Fail” रिलीज़ को ब्लॉक करता है या एग्ज़ेप्शन के लिए स्पष्ट अप्रूवल माँगता है। इससे सीमा असली बनती है बिना हर बार पैनिक पैदा किए।
बजट को एक साझा जगह पर लिख दें ताकि किसी व्यस्त रिलीज़ के दौरान बहस न हो। संक्षेप और स्पष्ट रखें: कौन से पेज या फ्लोज़ कवर हैं, माप कहाँ चलते हैं (लोकल ऑडिट, CI, स्टेज्ड बिल्ड), कौन सा डिवाइस और नेटवर्क प्रोफ़ाइल उपयोग होता है, और मेट्रिक्स कैसे परिभाषित हैं (field बनाम lab, gzip बनाम raw, route‑level बनाम whole app)।
एक रिपीटेबल बेसलाइन से शुरू करें। एक या दो मुख्य पेज चुनें और हर बार उन्हीं डिवाइस प्रोफ़ाइल और नेटवर्क पर टेस्ट करें। टेस्ट कम से कम तीन बार चलाएँ और मीडियन रिकॉर्ड करें ताकि एक अजीब रन आपकी दिशा न तय करे।
एक साधारण बेसलाइन शीट में एक यूज़र मेट्रिक और एक बिल्ड मेट्रिक दोनों शामिल करें। उदाहरण: पेज के लिए LCP और INP, साथ में बिल्ड के लिए कुल JavaScript साइज और कुल इमेज बाइट्स। इससे बजट असली महसूस होंगे क्योंकि आप देख सकते हैं कि ऐप ने क्या शिप किया, न कि केवल लैब रन का अनुमान।
बजट को आज की तुलना में थोड़ा बेहतर सेट करें, काल्पनिक नंबर नहीं। एक ठोस नियम है कि वर्तमान मीडियन में 5–10% सुधार से शुरू करें। अगर आपकी बेसलाइन पर LCP 3.2s है, सीधे 2.0s पर न जाएँ। 3.0s से शुरू करें, फिर जब आप इसे बनाए रख सकें तो कड़ा करें।
हर रिलीज़ से पहले एक त्वरित चेक जोड़ें ताकि यूज़र्स से पहले यह हो जाए। इसे इतना तेज रखें कि लोग इसे स्किप न करें। एक सरल वर्ज़न: सहमत पेज पर एक सिंगल‑पेज ऑडिट चलाएँ, अगर JavaScript या इमेजेज़ बजट से अधिक हों तो बिल्ड फेल करें, कमिट के लिए परिणाम स्टोर करें ताकि पता चले कि कब बदलाव आया, और हमेशा वही URL पैटर्न टेस्ट करें (कोई रैंडम डेटा नहीं)।
ब्रिचेस की साप्ताहिक समीक्षा करें, न कि केवल तब जब कोई शिकायत करे। ब्रिच को एक बग की तरह ट्रीट करें: किस चेंज ने इसे किया यह पहचानें, तय करें क्या अभी फिक्स करना है और क्या शेड्यूल करना है। धीरे‑धीरे टाइटन करें, केवल तब जब आप कुछ रिलीज़ के लिए इसे बनाए रख सकें।
जब प्रोडक्ट स्कोप बदलता है, बजट सावधानी से अपडेट करें। यदि आप नया एनालिटिक्स टूल या कोई भारी फीचर जोड़ते हैं, लिखें कि क्या बढ़ा (साइज़, रिक्वेस्ट, रनटाइम), आप बाद में क्या करके इसकी भरपाई करेंगे, और बजट कब वापस सामान्य होगा।
एक बजट तभी मदद करता है जब आप उसे जल्दी चेक कर सकें। 10 मिनट के ऑडिट का उद्देश्य परफेक्ट नंबर साबित करना नहीं है, बल्कि यह देखना है कि पिछली अच्छी बिल्ड से क्या बदला और पहले क्या फिक्स करना चाहिए।
एक पेज से शुरू करें जो असली उपयोग को दर्शाता है। फिर हर बार वही त्वरित चेक चलाएँ:
दो व्यूज़ अक्सर मिनटों में जवाब देती हैं: नेटवर्क वॉटरफॉल और मेन‑थ्रेड टाइमलाइन।
वॉटरफॉल में देखें कि क्या कोई रिक्वेस्ट क्रिटल पाथ को डॉमिनेट कर रही है: एक विशाल स्क्रिप्ट, ब्लॉकिंग फॉन्ट, या देर से शुरू होने वाली इमेज। अगर LCP रिसोर्स जल्दी रिक्वेस्ट नहीं हो रहा, तो पेज LCP बजट कभी नहीं पकड़ पाएगा चाहे सर्वर कितना भी तेज़ हो।
टाइमलाइन में लम्बे टास्क (50 ms या उससे अधिक) देखें। स्टार्टअप के आस‑पास लंबे टास्क का क्लस्टर अक्सर बताता है कि पहले लोड पर बहुत सारा JavaScript है। एक बड़ा चंक आमतौर पर राउटिंग इशू या किसी साझा बंडल के बढ़ने का संकेत होता है।
त्वरित ऑडिट फेल करते हैं जब हर रन अलग हो। कुछ बेसिक्स कैप्चर करें ताकि परिवर्तन स्पष्ट हों: पेज URL और बिल्ड/वर्शन, टेस्ट डिवाइस और नेटवर्क प्रोफ़ाइल, LCP एलिमेंट का वर्णन, आप जो मुख्य नंबर ट्रैक करते हैं (उदाहरण LCP, कुल JS बाइट्स, रिक्वेस्ट काउंट), और सबसे बड़े अपराधी पर एक छोटा नोट।
क्विक फीडबैक और PR चेक्स के लिए डेस्कटॉप टेस्टिंग ठीक है। जब आप बजट के करीब हों, पेज जंकी लगे, या आपके यूज़र्स मोबाइल होंगे तो रियल डिवाइस उपयोग करें। मोबाइल CPUs लंबे टास्क्स को स्पष्ट करते हैं, और वहीं कई "मेरे लैपटॉप पर ठीक है" रिलीज़ असफल हो जाती हैं।
जब बजट फेल हो, सबसे खराब कदम है “सब कुछ ऑप्टिमाइज़ करो।” एक दोहराने योग्य ट्रायज़ ऑर्डर उपयोग करें ताकि हर फिक्स का स्पष्ट फायदा हो।
यूज़र्स को सबसे ज़्यादा जो परेशान करता है उससे शुरू करें, फिर धीरे‑धीरे ठीक‑ठाक ट्यूनिंग की ओर जाएँ:
एक टीम ने नया डैशबोर्ड शिप किया और अचानक LCP बजट मिस होने लगा। केश हेडर इमेज को छोटा करके, लाइटर फॉर्मेट सर्व करके, और केवल जरूरी चीज़ों को पहले लोड करके उन्होंने LCP जल्दी वापस लाई। फिर उन्हें पता चला कि एक बड़ा चार्टिंग लाइब्रेरी हर रूट पर लोड हो रही है। उन्होंने उसे केवल analytics पेज पर लोड किया और थर्ड‑पार्टी सपोर्ट विजेट को पहले इंटरैक्शन के बाद डिलэй किया। एक दिन में डैशबोर्ड बजट के भीतर वापस आ गया।
सबसे बड़ा फेलियर मोड है बजट को एक बार लिख दिया दस्तावेज़ समझ लेना। बजट तभी काम करते हैं जब वे चेक करना आसान हों, अनदेखा करना कठिन हों, और आपकी शिपिंग प्रक्रिया से जुड़े हों।
अधिकतर टीमें कुछ जालों में फंस जाती हैं:
एक सामान्य पैटर्न है एक "छोटा" फीचर जो नई लाइब्रेरी खींच लाता है। बंडल बढ़ता है, LCP एक सेकंड धीमा हो जाता है धीमे नेटवर्क पर, और तब तक कोई नहीं देखता जब तक सपोर्ट टिकट न आ जाएं। बजट इसी बदलाव को रिव्यू के समय दिखाने के लिए होते हैं।
सरल से शुरू करें और चेक्स सुसंगत रखें। 2–4 बजट चुनें जो यूज़र अनुभव से जुड़े हों और धीरे‑धीरे उन्हें टाइट करें। अपना टेस्ट सेटअप लॉक करें और लिख दें। यदि संभव हो तो कम से कम एक रियल‑यूज़र सिग्नल ट्रैक करें, और लैब टेस्ट्स का इस्तेमाल “क्यों” बताने के लिए करें, बहस जीतने के लिए नहीं। जब कोई डिपेंडेंसी मायने रखती है तो एक छोटा नोट ज़रूरी करें: इसकी लागत क्या है, क्या बदल रही है, और क्यों यह जरूरी है। सबसे महत्वपूर्ण बात, बजट चेक को सामान्य रिलीज़ पाथ पर रखें।
अगर बजट निरंतर friction लग रहे हैं, तो वे आमतौर पर आज के लिए अवास्तविक हैं, या वे वास्तविक निर्णयों से जुड़े नहीं हैं। पहले इन दोनों चीज़ों को ठीक करें।
एक छोटी टीम ने एक React analytics डैशबोर्ड एक हफ्ते में शिप किया। शुरुआत में यह तेज़ लगा, पर हर शुक्रवार की रिलीज़ के साथ यह थोड़ा‑थोड़ा भारी होता गया। एक महीने के बाद यूज़र्स कहने लगे कि पहली स्क्रीन "हैंग" करती है और फिल्टर्स स्लो लगते हैं।
उन्होंने “काफी तेज़” पर बहस बंद की और उपयोगकर्ता के अनुभव से जुड़े बजट लिख दिए:
पहली विफलता दो जगहों पर दिखी। इनिशियल JS बंडल चार्ट्स, डेट लाइब्रेरीज़, और UI किट जोड़ने से बढ़ा। साथ ही, डैशबोर्ड हेडर इमेज बड़ी फाइल से बदल दी गई, जिससे LCP लिमिट पार हो गया। INP खराब हुआ क्योंकि हर फ़िल्टर चेंज ने मेन‑थ्रेड पर भारी रेंडर और महंगी कैलकुलेशन ट्रिगर किए।
उन्होंने इसे एक क्रम में फिक्स किया जो तेज़ जीत देता और रेग्रेशन रोकता:
LCP को लाइन के भीतर लाने के लिए इमेजेस रिसाइज़ और कंप्रेस किए, स्पष्ट इमेज डायमेंशंस सेट किए, और ब्लॉकिंग फॉन्ट लोड से बचा।
इनिशियल JS काटा: अनयूज़्ड लाइब्रेरी निकाली, नॉन‑क्रिटिकल राउट्स स्प्लिट किए, और चार्ट्स को lazy-load किया।
INP सुधारा: महंगे कंपोनेंट्स को memoize किया, टाइपिंग फिल्टर्स को debounce किया, और भारी वर्क को हॉट पाथ से हटाया।
हर रिलीज़ पर बजट चेक जोड़ा ताकि अगर कोई मेट्रिक टूटे तो रिलीज़ रुके।
दो रिलीज़ के बाद, वही टेस्ट डिवाइस पर LCP 3.4s से घटकर 2.3s हो गया, और INP लगभग 350ms से नीचे आकर 180ms के आसपास हो गया।
बजट तभी मदद करता है जब लोग हर बार एक ही तरीके से इसे फॉलो कर सकें। इसे छोटा रखें, लिखें, और शिपिंग का हिस्सा बनाइए।
कुछ मेट्रिक्स चुनें जो आपके ऐप से मेल खाते हों, "warn vs fail" थ्रेशहोल्ड सेट करें, और ठीक से डॉक्युमेंट करें कि आप कैसे टेस्ट करते हैं (डिवाइस, ब्राउज़र, नेटवर्क, पेज/फ्लो)। वर्तमान बेस्ट रिलीज़ से एक बेसलाइन रिपोर्ट सेव करें और उसे स्पष्ट रूप से लैबल करें। तय करें कि वैध एक्सेप्शन क्या गिने जाएंगे और क्या नहीं।
हर रिलीज़ से पहले वही ऑडिट चलाएँ और बेसलाइन से तुलना करें। अगर कुछ रेग्रेशन हुआ तो उसे बग ट्रैकिंग में लॉग करें और इसे एक टूटी हुई चेकआउट स्टेप की तरह ट्रीट करें, "बाद में" टास्क की तरह नहीं। अगर आप एक्सेप्शन के साथ शिप करते हैं तो एक ओनर और एक्सपायरी डेट रिकॉर्ड करें (अक्सर 1–2 स्प्रिंट)। अगर एक्सेप्शन बार‑बार नवीनीकृत होता है, तो बजट पर असली चर्चा चाहिए।
बजट को प्लानिंग और एस्टीमेट्स में पहले से शामिल करें: “यह स्क्रीन चार्ट लाइब्रेरी जोड़ती है, तो हमें कुछ और हटाना या इसे lazy-load करना होगा।” अगर आप Koder.ai (koder.ai) के साथ बना रहे हैं, तो आप ये constraints Planning Mode में पहले से लिख सकते हैं, फिर छोटे स्लाइस में इटरेट करें और स्नैपशॉट/रोलबैक यूज़ करें जब कोई चेंज आपके कैप को पार करे। मुद्दा टूल नहीं, आदत है: हर नया फीचर अपने वजन का भुगतान करे, वरना वह शिप नहीं होगा।
A performance budget is a set of hard limits (time, size, requests, CPU work) that your team agrees to before building.
If a change exceeds the limit, treat it like a broken requirement: fix it, reduce scope, or explicitly approve an exception with an owner and an expiry date.
Because performance gets worse gradually. Each feature adds JavaScript, CSS, images, fonts, API calls, and third‑party tags.
Budgets stop the slow creep by forcing a tradeoff: if you add weight or work, you must pay it back (lazy-load, split a route, simplify UI, remove a dependency).
Pick one real user journey and one consistent test setup.
A good starter is something frequent and business-critical, like:
Avoid edge cases at first; you want a flow you can measure every release.
Start with one target that matches typical users, for example:
Write it down and keep it stable. If you change device, network, cache state, or the path you test, your trend becomes noise.
Use a small set that covers both what users feel and what teams can control:
A practical starter set is:
Use two thresholds:
This avoids constant fire drills while still making the limits real when you cross the line.
Do this in order:
Not always. Bundle size can be fine while the page still feels slow because the main thread is busy.
Common React causes:
Add a runtime budget (for example, limit long tasks during startup or set a hydration time cap) to catch this class of issues.
Fast generation and iteration can quietly add dependencies, UI flourishes, and third-party scripts that ship to everyone.
The fix is to make budgets part of the workflow:
This keeps fast iteration from turning into a slow product.
Timing metrics show the pain; size and runtime limits help you quickly find what caused it.
Pick 3–5 budgets first. Tune later based on your baseline and release history.
Treat the breach like a bug: identify the commit, fix or scope-reduce, and prevent repeats.