प्रदर्शन उपयोगकर्ता अनुभव क्यों है? (Performance Is User Experience)

प्रदर्शन UX क्यों है

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

एक धीमा इंटरफ़ेस हर चरण में घर्षण पैदा करता है:

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

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

प्रदर्शन गुणवत्ता दर्शाता है

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

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

उपयोगकर्ता-केंद्रित प्रदर्शन रणनीति में ये प्रश्न पूछे जाने चाहिए:

1. सार्थक सामग्री कब दिखाई देती है? केवल अंतिम लोड समय ही नहीं, बल्कि प्रतीक्षा अनुभव को भी अनुकूलित करें।
2. उपयोगकर्ता कब बातचीत कर सकता है? एक पृष्ठ जो तैयार दिखता है लेकिन इनपुट को अनदेखा करता है वह अभी भी टूटा हुआ लगता है।
3. इंटरफ़ेस कितना स्थिर है? सामग्री, विज्ञापन, चित्र या फ़ॉन्ट लोड करते समय अप्रत्याशित हलचल को रोकें।
4. बातचीत कितनी तरल है? स्क्रॉल करना, टाइप करना, मेनू खोलना और नेविगेट करना निरंतर महसूस होना चाहिए, झटकेदार नहीं।

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

इस खंड में आवर्ती अवधारणाएँ```text

📦 Kullanıcının algıladığı performans Deneyimin laboratuvar skorundan değil; kullanıcının hissettiği hız ve güvenilirlik.

📦 Algılanan bekleme süresi Gecikmenin duygusal süresi; çoğu zaman memnuniyeti saat süresinden daha çok etkiler.

📦 Core Web Vitals LCP, INP ve CLS—gerçek kullanıcıların 75. yüzdeliğinde ölçülen yükleme, yanıt ve görsel kararlılık.

📦 Saha verisi ile laboratuvar verisi Gerçek kullanıcı ölçümü ile kontrollü, tekrarlanabilir teşhis testleri.

📦 RAIL Response, Animation, Idle, Load—kullanıcı eylemlerine göre performans hedefleri.

📦 Performans bütçesi “Yeterince hızlı”yı tasarım kısıtı haline getiren ağırlık, gecikme ve kararlılık limitleri.

## सुस्ती की कीमत

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

उपयोगकर्ता उम्मीद करते हैं कि सामग्री शीघ्रता से प्रदर्शित होगी और बातचीत प्रतिक्रियाशील होगी। जैसे-जैसे देरी बढ़ती है, धैर्य कम होता जाता है; वे पृष्ठ छोड़ सकते हैं, कार्रवाई दोहरा सकते हैं, या उत्पाद में कम विश्वास के साथ छोड़ सकते हैं। एमडीएन परित्याग, कम प्रतिधारण, कम रूपांतरण और कम संतुष्टि के कारण के रूप में खराब प्रदर्शन की पहचान करता है। [एमडीएन](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/why_web_performance)

### पहला प्रभाव इंस्टालेशन के दौरान बनता है

भले ही पेज तकनीकी रूप से तैयार न हो, लोडिंग अनुभव इंटरफ़ेस का हिस्सा है:

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

यह पहली बार आने वाले आगंतुकों के लिए विशेष रूप से महत्वपूर्ण है जिन्होंने अभी तक विश्वास जमा नहीं किया है। Google की प्रदर्शन मार्गदर्शिका नोट करती है कि धीमी साइटें जुड़ाव और प्रतिधारण पर कम प्रभावी होती हैं, और ऐसे उदाहरण जहां अतिरिक्त लोड समय के परिणामस्वरूप मापने योग्य उपयोगकर्ता मंथन होता है। [वेब.देव](https://web.dev/learn/performance/why-speed-matters)

###सन्तोष एकत्रित होता है

एक भी देरी बर्दाश्त की जा सकती है; लेकिन पूरे सत्र में बार-बार देरी होती रहती है। उपयोगकर्ता उत्पाद पहले पृष्ठ, फिर मेनू, फिर खोज परिणाम की प्रतीक्षा कर रहा है, यह लक्ष्य तक पहुंचने का आसान रास्ता नहीं है; बाधाओं की एक शृंखला के रूप में रहता है।प्रदर्शन भावनात्मक स्थिति को भी प्रभावित करता है। वेब.डेव पर सारांशित शोध पृष्ठ गति में देरी को बढ़े हुए तनाव से जोड़ता है; अर्थात्, धीमा अनुभव अकेले इसकी अवधि से अधिक भारी लग सकता है। समय के साथ, यह निराशा विश्वास, जुड़ाव, वापस लौटने की इच्छा और उत्पाद की अनुशंसा करने की संभावना को कम कर देती है। [वेब.देव](https://web.dev/learn/performance/why-speed-matters)

### व्यापार पर प्रभाव

"धीमेपन की कीमत" परस्पर जुड़े हुए रूपों में प्रकट होती है:

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

व्यावहारिक सबक सरल है: गति उत्पाद की पहली छाप और उसके बाद की प्रत्येक बातचीत का हिस्सा है। एक तेज़ साइट न केवल समय बचाती है - यह उपयोगकर्ता के ध्यान के प्रति सम्मान का संचार करती है और अनुभव को अधिक भरोसेमंद बनाती है।

## इंतज़ार का मनोविज्ञान

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

सेवा अनुभव अनुसंधान से पता चलता है कि **कथित प्रतीक्षा समय** अक्सर वस्तुनिष्ठ प्रतीक्षा की तुलना में संतुष्टि को अधिक मजबूती से प्रभावित करता है। यदि प्रतीक्षा खाली, अस्पष्ट, अनिश्चित या उपयोगकर्ता के नियंत्रण से परे हो तो यह और भी बुरा लगता है; बातचीत, ज्ञान और दृश्यमान प्रगति उसी अवधि को अधिक प्रबंधनीय बना सकती है। [इरास्मस अनुसंधान](https://repub.eur.nl/pub/12176/)

### डिजिटल प्रतीक्षा दर्दनाक क्यों है

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

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

### बेहतर प्रतीक्षा डिज़ाइन करना

सबसे अच्छा समाधान अच्छा प्रदर्शन है; लेकिन अपरिहार्य प्रतीक्षाएँ जानबूझकर डिज़ाइन की जानी चाहिए:

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

प्रगति संकेतक वस्तुनिष्ठ रूप से प्रक्रिया को गति नहीं देता है; यह अनिश्चितता को कम करता है और संकेत देता है कि सिस्टम काम कर रहा है। लक्ष्य निष्क्रिय प्रतीक्षा को जागरूक प्रगति में बदलना है: उपयोगकर्ता को पता होना चाहिए कि कुछ हो रहा है, क्यों हो रहा है, और यदि संभव हो तो यह कितने समय तक चल सकता है।

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

### कोर वेब वाइटल्स

Google का कोर वेब वाइटल्स तीन उपयोगकर्ता-सामना वाले आयामों पर केंद्रित है: लोडिंग, प्रतिक्रियाशीलता और दृश्य स्थिरता। अनुशंसित "अच्छी" सीमाएँ वास्तविक उपयोगकर्ता अनुभवों के 75वें प्रतिशतक पर मापी जाती हैं। [Google सर्च सेंट्रल](https://developers.google.com/search/docs/appearance/core-web-vitals)

| मीट्रिक | क्या उपाय | अच्छा लक्ष्य |
|---|---|---|
| सबसे बड़ा कंटेंटफुल पेंट (एलसीपी) | जब मुख्य सामग्री दिखाई दे | ≤ 2.5 सेकंड |
| नेक्स्ट पेंट (आईएनपी) से इंटरेक्शन | इंटरफ़ेस कितनी तेजी से उपयोगकर्ता इनपुट पर प्रतिक्रिया करता है | ≤ 200ms |
| संचयी लेआउट शिफ्ट (सीएलएस) | पेज अप्रत्याशित रूप से कितना हिलता है | ≤ 0.1 |

ये मेट्रिक्स तीन बुनियादी सवालों के जवाब देते हैं: *क्या वे महत्वपूर्ण सामग्री देख सकते हैं? क्या वे प्रतीक्षा किए बिना बातचीत कर सकते हैं? क्या इंटरफ़ेस यथावत रहता है?*

### उत्पाद और उपलब्धता मेट्रिक्स

तकनीकी मेट्रिक्स का वास्तविक उपयोगकर्ता परिणामों से मिलान होना चाहिए:

- **कार्य सफलता दर:** कार्य को सही ढंग से पूरा करने वाले उपयोगकर्ताओं का प्रतिशत।
- **कार्य अवधि:** किसी लक्ष्य को पूरा करने के लिए आवश्यक समय।
- **त्रुटि दर:** त्रुटि की आवृत्ति, दोहराव वाली कार्रवाई या विफलता।
- **परित्याग दर:** प्रवाह पूरा होने से पहले परित्याग की आवृत्ति।
- **संतुष्टि:** सीएसएटी, कार्योत्तर प्रश्न या साक्षात्कार।
- **प्रतिधारण और रूपांतरण:** क्या बेहतर प्रदर्शन से रूपांतरण, खरीदारी, सदस्यता या अन्य मूल्यवान कार्रवाई होती है।ये मेट्रिक्स दिखाते हैं कि क्या प्रदर्शन सुधार केवल बेहतर डायग्नोस्टिक स्कोर या सार्थक यूएक्स सुधार उत्पन्न करते हैं। [यूएक्स आर्मी](https://uxarmy.com/blog/how-to-measure-ux-performance/)

### फ़ील्ड डेटा और प्रयोगशाला डेटा

**फ़ील्ड डेटा** वास्तविक उपयोगकर्ताओं के वास्तविक उपकरणों, ब्राउज़रों, नेटवर्क और स्थानों से आता है। यह उपयोगकर्ताओं को वास्तव में मिलने वाले अनुभव को समझने का सबसे अच्छा तरीका है; कोर वेब वाइटल्स रिपोर्ट भी इस प्रकार के वास्तविक-विश्व डेटा का उपयोग करती है। [Google सर्च कंसोल सहायता](https://support.google.com/webmasters/answer/9205520?hl=en)

**प्रयोगशाला डेटा** नियंत्रित उपकरणों और दोहराए जाने योग्य परीक्षण स्थितियों से आता है। प्रतिगमन निकालने और परिवर्तनों की तुलना करने के लिए उपयोगी; लेकिन यह वास्तविक दुनिया के प्रत्येक उपकरण या नेटवर्क स्थिति का प्रतिनिधित्व नहीं कर सकता।

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

### यात्राओं को मापें, सिर्फ पन्नों को नहीं

पृष्ठ-स्तरीय स्कोर उपयोगी होते हैं; लेकिन उपयोगकर्ता **प्रवाह** का अनुभव करते हैं: खोजना, लॉग इन करना, भुगतान करना, फ़ाइल अपलोड करना, या फ़ॉर्म भरना। उपयोगकर्ता के दृष्टिकोण से इन यात्राओं के प्रदर्शन को मापें:

1. उपयोगकर्ता प्रारंभ होने तक का समय.
2. प्रत्येक महत्वपूर्ण बातचीत के बाद विलंब।
3. गलतियाँ और दोहराव वाले कार्य।
4. समापन और परित्याग.
5. कार्योत्तर संतुष्टि.

इसलिए सबसे सार्थक प्रदर्शन लक्ष्य केवल "एलसीपी कम करना" या "आईएनपी में सुधार करना" नहीं है। यह है: **उपयोगकर्ताओं को महत्वपूर्ण कार्यों को शीघ्रता से, सुरक्षित रूप से और अनावश्यक प्रयास के बिना पूरा करने में मदद करना।**

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

### बेसलाइन के लिए डिज़ाइन

धीमे उपयोगकर्ताओं को बाहरी मानने के बजाय, न्यूनतम उचित क्षमता से शुरुआत करें:

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

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

### संसाधनों को समझदारी से अपनाएं

ब्राउज़र को डिवाइस में आवश्यकता से अधिक डेटा या गणना प्राप्त नहीं करनी चाहिए। प्रतिक्रियाशील छवियां `srcset` और `sizes` के साथ उचित आकार का चयन कर सकती हैं; नीचे की ओर मुड़ी हुई छवियों को आलस्य से लोड किया जा सकता है ताकि दृश्य सामग्री के लिए बैंडविड्थ आरक्षित रहे। [एमडीएन](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images)

अनुकूली लोडिंग हर किसी को तेज़ कोर अनुभव दे सकती है और जब डिवाइस और नेटवर्क इसका समर्थन करते हैं तो उच्च गुणवत्ता वाले मीडिया, जटिल एनीमेशन या गैर-आवश्यक स्क्रिप्ट जोड़ सकते हैं। धीमे कनेक्शन पर यह छोटी छवि और वीडियो; इसका मतलब कम हार्डवेयर पर कम एनिमेशन और सस्ती गणना हो सकता है। [वेब.देव](https://web.dev/articles/adaptive-loading-cds-2019)### दोषपूर्ण कनेक्शन का समर्थन करें

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

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

एक इंटरफ़ेस जो व्यवधान को शालीनता से संभालता है वह केवल आदर्श परिस्थितियों में तेज़ इंटरफ़ेस की तुलना में अधिक विश्वसनीय लगता है।

### वास्तविक स्थितियों का परीक्षण करें

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

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

## प्रदर्शन-पहला डिज़ाइन

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

### मूल अनुभव से शुरुआत करेंउपयोगकर्ता के प्राथमिक लक्ष्य की पहचान करके और उसके लिए सबसे छोटा विश्वसनीय पथ डिज़ाइन करके प्रारंभ करें:

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

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

### दृश्य चयन जिम्मेदारीपूर्वक करें

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

उचित आकार की प्रतिक्रियाशील छवियां, हल्के संसाधन, संयमित एनीमेशन और उत्तरोत्तर प्रस्तुत करने योग्य घटक चुनें।

### कथित प्रदर्शन के लिए डिज़ाइन

उपयोगकर्ताओं को प्रतिक्रिया के साथ-साथ गति की भी आवश्यकता होती है। एक प्रतिक्रियाशील इंटरफ़ेस:

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

फीडबैक ईमानदार होना चाहिए: लोडिंग एनीमेशन को अटके हुए अनुरोध को छिपाना नहीं चाहिए; ढांचे को उस सामग्री से मिलता जुलता होना चाहिए जिसका वह प्रतिनिधित्व करता है और झूठी उम्मीदें पैदा नहीं करनी चाहिए।

### प्रक्रिया में प्रदर्शन एम्बेड करें

प्रदर्शन-प्रथम डिज़ाइन एक सामान्य वर्कफ़्लो के रूप में सबसे अच्छा काम करता है:

1. पृष्ठ भार, लोडिंग, प्रतिक्रियाशीलता और स्थिरता के लिए प्रदर्शन बजट परिभाषित करें।2. डिज़ाइन समीक्षाओं में धीमे डिवाइस और नेटवर्क को शामिल करें।
3. न केवल आदर्श अंतिम स्क्रीन; प्रोटोटाइप लोडिंग, त्रुटि और संक्रमण स्थितियाँ।
4. प्रयोगशाला और क्षेत्र स्थितियों में यथार्थवादी उपयोगकर्ता यात्राओं का परीक्षण करें।
5. प्रकाशन के बाद कोर वेब वाइटल्स और कार्य परिणामों की निगरानी करें।
6. जब नई सुविधाएँ उपलब्ध बजट का उपभोग कर लें तो डिज़ाइन पर दोबारा गौर करें।

केंद्रीय सिद्धांत सरल है: **केवल वही नहीं जो आदर्श प्रोटोटाइप में दिखाई देता है; उस अनुभव को डिज़ाइन करें जिसे उपयोगकर्ता वास्तव में प्राप्त कर सकें।**

## रेल मॉडल

रेल वेब प्रदर्शन को एकल पृष्ठ लोड गणना के रूप में परिभाषित नहीं करता है; यह उपयोगकर्ता कार्यों के अनुक्रम के संदर्भ में सोचने के लिए एक उपयोगकर्ता-केंद्रित ढांचा है। अनुभव को **प्रतिक्रिया, एनीमेशन, निष्क्रिय और लोड** में विभाजित करता है; यह प्रत्येक संदर्भ को इस आधार पर एक व्यावहारिक लक्ष्य देता है कि लोग देरी को कैसे समझते हैं। [वेब.देव](https://web.dev/articles/rail)

| सिद्धांत | उपयोगकर्ता अनुभव | व्यावहारिक लक्ष्य |
|---|---|---|
| **प्रतिक्रिया** | क्लिक, टैप, टाइप और अन्य इनपुट की पुष्टि करें | 100 एमएस के भीतर उत्तर दें |
| **एनीमेशन** | स्वाइप करना, खींचना और तरल पदार्थ बदलना जारी रखें | प्रत्येक फ़्रेम को लगभग 16 एमएस में बनाएं |
| **निष्क्रिय** | भविष्य की बातचीत को अवरुद्ध किए बिना पृष्ठभूमि समय का उपयोग करें | छोटे टुकड़ों में काम करें, आदर्श रूप से 50 एमएस से कम |
| **लोड** | उपयोगी सामग्री और सहभागिता शीघ्रता से उपलब्ध कराएं | लगभग 5 सेकंड में इंटरैक्टिव सामग्री लोड करें |

###प्रतिक्रिया

जब उपयोगकर्ता एक बटन पर क्लिक करता है, तो इंटरफ़ेस को लगभग तुरंत कार्रवाई की पुष्टि करनी चाहिए - भले ही पूरी प्रक्रिया में अधिक समय लगे। पहली प्रतिक्रिया को राज्य, स्पिनर, आशावादी अद्यतन या नेविगेशन टॉगल दबाया जा सकता है; इसका उद्देश्य यह आश्वासन देना है कि इनपुट प्राप्त हो गया है।लंबे जावास्क्रिप्ट कार्य मुख्य थ्रेड को अवरुद्ध कर सकते हैं और इस फीडबैक में देरी कर सकते हैं। महंगे काम को छोटे टुकड़ों में तोड़ने से ब्राउज़र को उपयोगकर्ता को अधिक बार नियंत्रण वापस करने की अनुमति मिलती है। [एमडीएन](https://developer.mozilla.org/en-US/docs/Glosary/RAIL)

### एनीमेशन

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

पारंपरिक रेल लक्ष्य 60 एफपीएस के लिए लगभग 16 मिलीसेकंड प्रति फ्रेम है। व्यवहार में, टीमों को तरलता को प्राथमिकता देनी चाहिए जहां आंदोलन स्थिति को समझने या सामग्री में हेरफेर करने में मदद करता है; प्रसंस्करण शक्ति की खपत करने वाले अनावश्यक एनीमेशन से बचना चाहिए।

### निष्क्रिय

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

रेल खाली काम को छोटी इकाइयों में विभाजित करने की सिफारिश करता है ताकि बातचीत को प्राथमिकता मिल सके। यह कम-शक्ति वाले उपकरणों पर विशेष रूप से महत्वपूर्ण है जहां समान गणना में अधिक समय लगता है। [वेब.देव](https://web.dev/articles/rail)

###लोड

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

रेल-आधारित लोडिंग रणनीति इसलिए प्राथमिकता देती है:

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

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

उदाहरण के लिए, एक उत्पाद टीम को पता चल सकता है कि लैंडिंग पृष्ठ का लोड स्वीकार्य है लेकिन खोज फ़िल्टर में 600ms का समय लगता है। रेल उस इंटरैक्शन पर ध्यान केंद्रित करती है क्योंकि घर्षण का वास्तविक स्रोत केवल प्रारंभिक लोडिंग नहीं है; उत्तर है. केंद्रीय सिद्धांत यह है: **उन क्षणों को अनुकूलित करें जब उपयोगकर्ता कार्य करते हैं, प्रतीक्षा करें और पता लगाएं कि क्या हो रहा है।**

## शुरुआत से डिजाइनिंग प्रदर्शन

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

### लक्ष्य जल्दी निर्धारित करें

विस्तृत स्क्रीन बनाने से पहले, परिभाषित करें कि सबसे महत्वपूर्ण उपयोगकर्ता यात्राओं के लिए "पर्याप्त तेज़" का क्या अर्थ है:

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

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

### पहले उच्च प्रभाव वाले विकल्प चुनें

सबसे बड़ा लाभ अक्सर कार्यान्वयन से पहले लिए गए निर्णयों से होता है:

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

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

### वास्तविक अनुभव का प्रोटोटाइप

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

- धीमी प्रारंभिक लोडिंग।
- विलंबित एपीआई प्रतिक्रियाएँ।
- खाली और कंकाल अवस्थाएँ।
- प्रगति संकेतक.
- ऑफ़लाइन या गिराए गए कनेक्शन।
- त्रुटि और पुनः प्रयास व्यवहार।
- कम अंत डिवाइस प्रतिबंध।
- कीबोर्ड, स्पर्श और अभिगम्यता इंटरैक्शन।

यह प्रदर्शन-संबंधित यूएक्स समस्याओं का परिचय देता है जबकि उन्हें अभी भी सस्ते में बदला जा सकता है।

### लगातार मापें

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

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

## सबसे अधिक बार भ्रमित होने वाली जोड़ियां```text
❌ Performans UX’ten ayrıdır
✓ Performans, UX’in en görünür boyutlarından biridir

❌ Yeşil Core Web Vitals panosu ürünün iyi hissettirdiği anlamına gelir
✓ Metrikler gerçek sürtünme ve görev sonuçlarını temsil ettiğinde işe yarar

❌ Bekleme yalnızca saat süresidir
✓ Algılanan bekleme; geri bildirim, kesinlik ve kontrolle şekillenir

❌ Geliştirici laptopunda hızlı olmak “yeterince hızlı”dır
✓ Kapsayıcı performans sıradan cihazlar ve zor ağlardan başlar

❌ Lansmandan sonra optimize edin
✓ Performansı sola kaydırın: bütçe, prototip ve “bitti” tanımı ilk günden

चेकलिस्ट: प्रदर्शन को उत्पाद UX के रूप में मानें

1. पांच उच्चतम मूल्य वाली यात्राओं की सूची बनाएं (बाज़ार में: खोज, उत्पाद विवरण, कार्ट में जोड़ें, चेकआउट, खाता पुनर्प्राप्ति)।
2. प्रत्येक यात्रा के लिए, "टूटी हुई" भावना को सरल भाषा में लिखें - खाली स्क्रीन, मूक स्पर्श, लेआउट उछाल, बार-बार क्लिक करना।
3. सार्थक सामग्री, इंटरैक्शन तत्परता, प्रतिक्रिया विलंबता और लेआउट स्थिरता के लिए लक्ष्य निर्धारित करें।
4. न केवल आदर्श स्क्रीन; डिज़ाइन स्टैंडबाय, त्रुटि, ऑफ़लाइन और पुनर्प्राप्ति स्थिति।
5. कार्य की सफलता, कार्यकाल, विफलता, परित्याग और संतुष्टि के लिए कोर वेब वाइटल्स (फ़ील्ड + लैब) को मैप करें।
6. उन प्रमुख उपकरणों और नेटवर्कों की पहचान करें जिन्हें रिलीज़ को "पूर्ण" मानने से पहले माइग्रेट करना होगा।
7. रेल लेंस लगाएं: कौन सी देरी प्रतिक्रिया, एनीमेशन, निष्क्रिय या लोड को सबसे अधिक नुकसान पहुंचाती है?
8. उत्तरों को डिज़ाइन और इंजीनियरिंग के संयुक्त स्वामित्व वाले प्रदर्शन बजट में बदलें।

यदि आप इन आठ प्रश्नों का उत्तर नहीं दे सकते, तो प्रदर्शन अभी भी एक बाद का विचार है; यह किसी उत्पाद की आवश्यकता नहीं है.

इस प्रकरण के मुख्य बिंदु

1. प्रदर्शन यूएक्स है: उपयोगकर्ता समय के साथ उत्पादों का अनुभव करते हैं - उपस्थिति, प्रतिक्रिया, स्थिरता और तरलता।
2. धीमेपन की कीमत विश्वास, रूपांतरण, प्रतिधारण और भावनात्मक ऊर्जा है; पहला इंतज़ार ही पहला प्रभाव है.
3. अनुमानित प्रतीक्षा अक्सर वस्तुनिष्ठ सेकंड से अधिक महत्वपूर्ण होती है; अपरिहार्य देरी में फीडबैक, प्रगति और नियंत्रण डिज़ाइन करें।
4. सिस्टम प्रदर्शन और उपयोगकर्ता परिणामों को एक साथ मापें; पेज वैनिटी स्कोर के बजाय यात्राएँ चुनें।
5. समावेशी और प्रदर्शन-प्रथम डिज़ाइन बेस डिवाइस, अपूर्ण नेटवर्क और शुरुआती बजट से शुरू होता है।
6. रेल उपयोगकर्ताओं की कार्रवाई और प्रतीक्षा क्षणों पर ध्यान रखता है; कोर वेब वाइटल्स इस कहानी के अंशों को डिजिटल बनाता है।

लक्ष्य बोर्ड को हरा करना नहीं है। लक्ष्य उपयोगकर्ताओं को महत्वपूर्ण कार्यों को शीघ्रता से, सुरक्षित रूप से और अनावश्यक प्रयास के बिना पूरा करने में मदद करना है।

अगला: हम उपयोगकर्ता को जो महसूस होता है उसे उपकरण द्वारा मापे जाने वाले माप से अलग कर देंगे - ताकि मेट्रिक्स निर्णय उपकरण बन जाए, न कि वैनिटी शीट।