अनुकूलन से पहले मापें: Paul Irish का स्पीड वर्कफ़्लो

क्यों पहले अनुकूलन अक्सर समय बर्बाद कर देता है

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

सबसे बड़ा जोखिम गलत चीज़ को अनुकूलित करना है। अगर पेज धीमा है क्योंकि मुख्य थ्रेड JavaScript से ब्लॉक हो रहा है, तो तस्वीरों को घंटों कंप्रेस करने से बेहतरी कम ही होगी। या आप कुछ तेज़ कर सकते हैं जिसे उपयोगकर्ता नोट ही नहीं करते जबकि असल देरी किसी लंबी API कॉल, बार-बार रिफ्लो होने वाले लेआउट, या एक ब्लॉकिंग स्क्रिप्ट के कारण हो।

एक और जाल है “फील” से आंकना। “ज़्यादा तेज़ लगता है” प्लेसबो बदलावों (जैसे स्पिनर) या अलग नेटवर्क, डिवाइस, या समय पर टेस्ट करने से आ सकता है। “वास्तव में तेज़ है” का मतलब है वही एक्शन, वही शर्तें, बेहतर नंबर्स दिए।

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

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

Paul Irish और पहले मापने की आदत

Paul Irish वेब परफ़ॉर्मेंस की सबसे जानी-मानी आवाज़ों में से हैं। ब्राउज़र टूलिंग और परफ़ॉर्मेंस गाइडेंस पर उनके काम के ज़रिए उन्होंने एक सीधी सोच लोकप्रिय की: आपकी पहली नौकरी यह अनुमान लगाना नहीं कि क्या धीमा है, बल्कि यह साबित करना है कि क्या धीमा है।

यह माइंडसेट टीम डायनामिक्स बदल देता है। “इमेज हमेशा समस्या हैं” या “शायद फ्रेमवर्क है” जैसी आदतों से तर्क करने के बजाय आप साक्ष्य से शुरू करते हैं। जब आप टाइमलाइन, धीमी क्वेरी, या लंबा टास्क दिखा सकते हैं, तो चर्चा दोष लगाने से हटकर समाधान की दिशा में चली जाती है।

“अनुकूलन से पहले मापें” बहसों को ठंडा भी कर देता है क्योंकि यह साझा नियम बनाता है: कौन सी चीज़ माप रहे हैं, “बेहतर” का क्या अर्थ है, और केवल तभी जश्न मनाएँ जब संख्याएँ बदलें।

यह छोटे साइट्स और बड़े ऐप्स दोनों पर काम करता है। एक एकल बेसलाइन मार्केटिंग पेज पर यादृच्छिक माइक्रो-ऑप्टिमाइज़ेशन रोक सकती है। बड़े प्रोडक्ट पर लगातार माप परफ़ॉर्मेंस को कभी न खत्म होने वाले टू-डू लिस्ट में बदलने से रोकती है।

इसे वास्तविक बनाने का एक सरल तरीका परफ़ॉर्मेंस को एक बग रिपोर्ट की तरह ट्रीट करना है: पुनरुत्पादित करने के स्पष्ट चरण, आपने जो मापा वह मेट्रिक, और एक बदलाव जो एक नतीजे से जुड़ा हो। अगर दो लोग असहमत हों, तो माप फिर चलाएँ और डेटा को फैसला करने दें।

परफ़ॉर्मेंस को पहले इंस्ट्रूमेंटेशन की समस्या मानें

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

इंस्ट्रूमेंटेशन शानदार होने की ज़रूरत नहीं है। यह कुछ सिग्नल लगातार एक ही जगहों से इकट्ठा करना है ताकि आप बुनियादी सवालों का जवाब दे सकें:

• क्या धीमा लगता है?
• समय कहाँ जाता है?
• क्या हमारे बदलाव से मदद मिली?

आम तौर पर आपको दो तरह के डेटा चाहिए।

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

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

विशेषज्ञ न होने पर भी आप पेज लोड 마इलस्टोन्स (जैसे पहला कंटेंट दिखना), लंबे टास्क और मुख्य-थ्रेड ब्लॉकिंग, धीमी नेटवर्क रिक्वेस्ट्स, महंगा रेंडरिंग काम (लेआउट, स्टाइल, पेंट), और सर्वर रिस्पॉन्स टाइम माप सकते हैं।

ये संकेत आम तौर पर कुछ जगहों में रहते हैं: लैब प्रोफाइलिंग के लिए ब्राउज़र डेवलपर टूल्स, बैकएंड के समय के लिए सर्वर लॉग और ट्रेसेस, और वास्तविक उपयोगकर्ता डेटा के लिए analytics या RUM डैशबोर्ड। उदाहरण के लिए, अगर चेकआउट धीमा लगता है, DevTools दिखा सकता है कि ब्राउज़र एक बड़े कार्ट UI को रेंडर करने में व्यस्त है जबकि सर्वर लॉग API को तेज दिखाते हैं। बिना इंस्ट्रूमेंटेशन के आप बैकएंड ऑप्टिमाइज़ कर सकते हैं और असली समस्या कभी ठीक नहीं होगी।

चरण 1: एक दोहराने योग्य बेसलाइन सेट करें

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

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

फिर उस यात्रा के लिए 1–3 मेट्रिक्स चुनें। पेज व्यू के लिए एक आम जोड़ी है LCP (मुख्य कंटेंट कितनी जल्दी दिखता है) और TTFB (सर्वर कितनी जल्दी जवाब देता है)। चेकआउट जैसे फ्लो के लिए आप पहले स्टेप को पूरा करने का समय और पेमेंट कॉल के लिए API रिस्पॉन्स समय ट्रैक कर सकते हैं। बहुत सारे मेट्रिक्स चॉइस-छंटनी को आसान बना देते हैं।

टेस्ट सेटअप लिखें ताकि कोई और इसे बाद में दोहरा सके। छोटी-छोटी अलगताएँ भी परिणाम बदल सकती हैं:

• डिवाइस और ब्राउज़र (वर्शन सहित)
• नेटवर्क (wifi बनाम 4G, थ्रॉटलिंग ऑन/ऑफ)
• कैश स्थिति (cold बनाम warm)
• लोकेशन और टेस्ट डेटा (रीजन, अकाउंट टाइप, कार्ट साइज)
• रन की संख्या (उदाहरण के लिए, 5 रन और मीडियन लें)

अंत में, अपने दर्शकों के लिए “पर्याप्त अच्छा” परिभाषित करें। उदाहरण: “मध्यम-श्रेणी के फोन पर 4G पर LCP 2.5s से कम।” अगर आप Koder.ai का उपयोग करते हैं, तो परीक्षण से पहले स्नैपशॉट लेने से आपकी बेसलाइन एक ज्ञात वर्शन से जुड़ी रहती है।

चरण 2: धीमापन को जानबूझकर दोहराएँ

किसी चीज़ को प्रोफाइल करने से पहले समस्या को फिर से मांग पर पैदा करें। अगर आप इसे दोहरा नहीं सकते, तो नतीजे पर भरोसा नहीं कर सकते।

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

एक तेज़ रन करें ताकि पुष्टि हो सके कि धीमापन असल है और दोहराने योग्य है। बाकी सबकुछ वही रखें: वही पेज, वही डिवाइस, वही नेटवर्क अगर संभव हो। फिर ट्रिगर और ठीक वह पल लिखें जब यह धीमा लगता है, जैसे “Pay पर क्लिक करने के बाद बटन एक सेकंड के लिए फ्रीज़ हो जाता है” या “स्क्रोलिंग तब अटकती है जब प्रोडक्ट लिस्ट दिखाई देती है।”

दोहराने में मदद करने के लिए एक छोटा स्क्रिप्ट उपयोगी होता है: पेज एक नया टैब से खोलें, वही लैग्गी एक्शन करें, वह सटीक पॉइंट नोट करें जहाँ यह धीमा होता है, फिर एक बार दोहराएँ ताकि पुष्टि हो जाए।

एक या दो बेसलाइन रिकॉर्डिंग कैप्चर करें, दर्जनों नहीं। आप सिर्फ़ इतना साक्ष्य चाहते हैं कि कह सकें, “हाँ, यह धीमापन होता है, और यह यहीं होता है।”

चरण 3: मुख्य बॉटलनेक ढूँढने के लिए प्रोफाइल करें

एक बार जब आप धीमापन को दोहरा सकें, अनुमान लगाना बंद करें। प्रोफ़ाइलर खोलें (ज़्यादातर लोगों के लिए ब्राउज़र की Performance पैनल) और धीमी इंटरैक्शन का एक रन रिकॉर्ड करें। लक्ष्य हर समस्या ढूँढना नहीं है—यह जानना है कि समय कहाँ जाता है।

सबसे बड़े समय-खण्डों से शुरू करें। छोटे-बड़े स्पाइक्स असल हो सकते हैं, लेकिन अक्सर अकेले वह एक स्पष्ट देरी नहीं बताते।

रिकॉर्डिंग पढ़ने का एक उपयोगी तरीका समय को कुछ बकेट्स में बाँटना है: नेटवर्क और लोडिंग (रिक्वेस्ट्स का इंतज़ार), main-thread स्क्रिप्टिंग (लंबे JavaScript टास्क), रेंडरिंग और पेंट (लेआउट और स्टाइल काम), idle गैप्स (किसी और चीज़ का इंतज़ार), और दोहराया काम (वही महंगा कदम बार-बार होना)।

एक सामान्य गलती धीमे सर्वर रिस्पॉन्स को क्लाइंट वर्क से भ्रमित करना है। अगर टाइमलाइन में रिक्वेस्ट्स के दौरान लंबे गैप दिखते हैं, तो बॉटलनेक नेटवर्क या बैकएंड हो सकता है। अगर लंबे टास्क मुख्य थ्रेड पर दिखते हैं, तो फ्रंट-एंड समस्या है भले नेटवर्क तेज़ हो।

कुछ भी बदलने से पहले एक छोटा, टेस्ट-योग्य हाइपोथेसिस लिखें जो आपने देखा उसके आधार पर। उदाहरण: “पेज धीमा इसलिए लगता है क्योंकि API रिस्पॉन्स के तुरंत बाद JSON पार्सिंग मुख्य थ्रेड को ब्लॉक कर रही है।” वह वाक्य अगले कदम को सेट करता है।

चरण 4: जानबूझकर एक ही चीज़ बदलें

जब आपने संभावित बॉटलनेक पहचान लिया, तो सब कुछ ठीक करने के लिए उछलने का विरोध करें। एक चर बदलें ताकि आप कारण और प्रभाव जोड़ सकें।

बदलाव छोटा और आसान से undo किया जा सकने वाला रखें। बड़े री-राइट्स परिणाम को धुंधला कर देते हैं: अगर परफ़ॉर्मेंस बेहतर हुआ, तो आप नहीं जान पाएँगे क्यों। अगर खराब हुआ, तो रोलबैक जोखिम भरा होता है।

अच्छे “एक चीज़” बदलाव specific और टेस्टेबल होते हैं। उदाहरण: रेंडरिंग ब्लॉक करने वाला एक थर्ड-पार्टी स्क्रिप्ट डिफर या हटाना, धीमे पेज पर एक ओवरसाइज़्ड इमेज को कंप्रेस करना, एक महंगी DB क्वेरी पर कैश जोड़ना, एक भारी UI कंपोनेंट को विभाजित करना ताकि वह कम काम पहले करे, या प्रोफ़ाइल में दिखे हुए एक हॉट लूप का काम कम करना।

कोड छुए बिना पहले लिख लें कि आपने क्या बदला, आपने इसे क्यों चुना, और आप क्या उम्मीद करते हैं कि सुधरेगा (उदाहरण: “main-thread समय घटेगा” या “DB समय आधा होगा”)।

अगर आपकी टीम Koder.ai जैसे प्लेटफ़ॉर्म का उपयोग करती है जो स्नैपशॉट और रोलबैक सपोर्ट करता है, तो बदलाव से ठीक पहले स्नैपशॉट लें ताकि “छोटा और reversible” केवल शब्द न रहे।

चरण 5: प्रभाव सत्यापित करें और शोर से बचें

आपने एक बदलाव किया। अब साबित करें कि इससे मदद मिली।

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

शोर सबसे आम कारण है कि टीमें परफ़ॉर्मेंस पर बहस करती हैं। वार्म बनाम कोल्ड कैश, एक्सटेंशन्स या बैकग्राउंड प्रोसेस, अलग नेटवर्क कंडीशंस या VPN सेटिंग्स, सर्वर वैरिएंस (ख़ामोश मिनट बनाम व्यस्त मिनट), और “डिप्लॉय के तुरंत बाद” और steady state के बीच का फर्क देखें।

अगर मीडियन सुधरता है पर worst-case खराब होता है, तो यह एक वास्तविक ट्रेडऑफ़ है। अपने उपयोगकर्ताओं के लिए क्या मायने रखता है, तय करें और फिर निर्णय दस्तावेज़ करें: परिवर्तन रखें, रोलबैक करें, या नई परिकल्पना लिखकर फिर टेस्ट करें।

सामान्य जाल जो परफ़ॉर्मेंस काम को असंभव बना देते हैं

परफ़ॉर्मेंस काम तब भ्रमित कर देता है जब आप गलत चीज़ मापते हैं या एक साथ बहुत कुछ बदल देते हैं। आप बहुत मेहनत बर्बाद कर सकते हैं बिना साफ़ जीत के, भले ही आपकी ऐप बेहतर हो रही हो।

एक आम गलती एक सिंगल स्कोर को लक्ष्य मान लेना है। स्कोर्स उपयोगी हो सकते हैं, पर उपयोगकर्ता "92" का अनुभव नहीं करते—वे अनुभव करते हैं "पेज 2 सेकंड में कंटेंट दिखाता है" या "Buy पर टैप करने पर तुरंत प्रतिक्रिया मिलती है"। एक उपयोगकर्ता-देखने योग्य आउटकम चुनें और उसे लगातार मापें।

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

भ्रम अक्सर इन पैटर्न्स से आता है: जो सबसे आसान है उसे सुधारना बजाय जो सबसे ज़्यादा समय लेता हो, कई ट्वीक एक साथ बंडल करना, हर बार टेस्ट पाथ बदलना, फिर से टेस्ट छोड़ना क्योंकि “फ़ील” बेहतर है, या बिना उसी बेसलाइन को दोहराए जीत घोषित कर देना।

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

एक त्वरित चेकलिस्ट जो आप हर बार उपयोग कर सकते हैं

अगर आप एक आदत बनाए रखें, तो यह रखें: अनुकूलन से पहले मापें। लक्ष्य अंतहीन डेटा नहीं है—यह एक दोहराने योग्य लूप है जिसपर आप भरोसा कर सकें।

उसी सटीक उपयोगकर्ता यात्रा का नाम रखें जिसके बारे में आप परवाह करते हैं। “होमपेज धीमा है” अस्पष्ट है। "प्रोडक्ट पेज से Buy क्लिक करके कन्फर्मेशन देखने तक" आपको एक क्लिक पाथ देता है जिसे आप दोहरा सकते हैं।

इस चेकलिस्ट का उपयोग करें:

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

परफ़ॉर्मेंस का शांत संस्करण सरल है: एक पाथ, एक सेटअप, एक बदलाव, एक सत्यापित परिणाम।

उदाहरण: बिना अनुमान के धीमे चेकआउट को ठीक करना

एक आम शिकायत: ग्राहक "Pay" पर क्लिक करने के बाद चेकआउट धीमा लगता है। लोग अनुमान लगाना शुरू कर देते हैं (इमेज, फॉन्ट, बटन)। इसके बजाय इसे एक ऐसे टेस्ट की तरह ट्रीट करें जिसे आप दोहरा सकें।

एक बेसलाइन सेट करें जिसे आप फिर चला सकें। एक डिवाइस और एक पाथ चुनें (cart → checkout → Pay → confirmation)। नेटवर्क थ्रॉटलिंग चालू करें (उदाहरण के लिए, Fast 3G) और हर रन में इसे वही रखें। एक सरल नंबर मापें: Pay पर क्लिक करने से कन्फर्मेशन स्क्रीन दिखने तक का समय।

फिर उसी पल को प्रोफ़ाइल करें और देखें समय कहाँ जाता है। आप आमतौर पर तीन बकेट्स में निर्णय ले रहे होते हैं: नेटवर्क (लंबी रिक्वेस्ट या बहुत सारी रिक्वेस्ट्स), सर्वर (पेमेंट कॉल धीमा है जबकि ब्राउज़र idle है), या main thread (ब्राउज़र UI अपडेट नहीं कर पा रहा क्योंकि JavaScript व्यस्त है)।

कल्पना करें प्रोफ़ाइल दिखाए कि Pay पर क्लिक करने के बाद ब्राउज़र एक analytics रिक्वेस्ट और एक फ्रॉड-चेक स्क्रिप्ट फायर करता है, और पेमेंट रिक्वेस्ट इनके पीछे इंतज़ार कर रही है। यह “सब कुछ तेज़ करो” की समस्या नहीं है—यह एक ब्लॉकिंग स्टेप है।

जानबूझकर एक बदलाव करें। उदाहरण के लिए, पेमेंट रिक्वेस्ट को तुरंत शुरू करें, और analytics को कन्फर्मेशन स्क्रीन दिखने के बाद भेजें।

सत्यापित करें उसी सेटअप से: वही थ्रॉटलिंग, वही स्टेप्स, कई रन। अगर कन्फर्मेशन टाइम घटता है और एरर्स नहीं बढ़ते, तो आपके पास असली जीत है। साथ ही यह जांच लें कि आपने रिफंड्स, retries, या डबल-सबमिट सुरक्षा तो नहीं तोड़ी।

अगले कदम: वर्कफ़्लो को टीम की आदत बनाएं

जब यह एक रूटीन हो न कि बचाव मिशन, परफ़ॉर्मेंस संभालित रहती है। मापना डिफ़ॉल्ट एक्शन बनाएं, भले ही सब कुछ ठीक लगे।

एक छोटा सेट मेट्रिक्स चुनें जिन्हें आपकी टीम हमेशा ट्रैक करेगी। इसे स्थिर रखें ताकि ट्रेंड्स आसानी से दिखाई दें:

• पेज लोड: Largest Contentful Paint (LCP)
• इंटरैक्टिविटी: Interaction to Next Paint (INP)
• स्थिरता: Cumulative Layout Shift (CLS)
• API स्पीड: की एंडपॉइंट्स के लिए p95 रिस्पॉन्स टाइम
• एरर: क्लाइंट और सर्वर एरर रेट

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

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

अगर आप Koder.ai के साथ बनाते हैं, तो Planning Mode आपकी मदद कर सकता है कि आप बदलाव से पहले उपयोगकर्ता यात्रा और मेट्रिक लिख दें। फिर स्नैपशॉट और रोलबैक का उपयोग करके एक्सपेरिमेंट्स सुरक्षित रखें: स्नैपशॉट लें, एक बदलाव लागू करें, फिर से टेस्ट करें, और अगर परिणाम शोरदार या बदतर हो तो रोलबैक करें।

योजना या समीक्षा में एक सवाल संस्कृति को स्वस्थ रखता है: "हमने क्या मापा, और उसने क्या बदला?"