1. परिणाम और सीमा परिभाषित करें
एक ऑडिट टूल खोलने से पहले एक मालिक नामित करें और परिणाम लिखें। दर्शक, यात्रा, पृष्ठ या रूट, समय विंडो, और वह निर्णय बताइए जिसे यह कार्य समर्थन करेगा। एक उपयोगी लक्ष्य किसी टास्क का वर्णन करता है, जैसे मोबाइल पर उत्पाद-से-कार्ट फ्लो पूरा करना, न कि साइट को "तेज़" बनाने की अस्पष्ट इच्छा।
अनिवार्य शर्तों की सूची बनाएं: खरीद या पूछताछ का काम करने वाला फ़्लो, खाता पहुँच, सहमति का व्यवहार, पहुँचनीयता, खोज के लिए क्रॉल किए जाने की क्षमता और अनुमोदित सामग्री। यदि कोई फ़ॉर्म विफल हो जाए, सामग्री खोज से छिप जाए या कीबोर्ड का उपयोग कठिन हो जाए, तो सिंथेटिक स्कोर में वृद्धि को सफलता नहीं माना जा सकता।
एक वाक्य में प्रारंभ पृष्ठ, उपयोगकर्ता क्रिया, और सफल समाप्ति स्थिति लिखें।
ऐसा परिणाम चुनें जो बिगड़ना नहीं चाहिए, जैसे सफल सबमिशन या कोई नया पहुँचनीयता ब्लॉकर न आना।
2. तुलनीय बेसलाइन कैप्चर करें
कोड, सामग्री, कॉन्फ़िगरेशन, या टैग बदलने से पहले URL सूची, तारीख, टेस्ट कंडीशन, रिलीज़ वर्शन, रिपोर्ट या ट्रेस, और मैनुअल टास्क परिणाम सहेज लें। web.dev कई पृष्ठ प्रकारों का परीक्षण करने और परिवर्तनों से पहले साइट स्टेट रिकॉर्ड करने की सलाह देता है; सिंगल-पेज एप्लिकेशन (SPA) के लिए, केवल पहली लोड के बजाय रूट्स, कॉम्पोनेन्ट और फ्लो शामिल करें।
एक से अधिक लेंस का उपयोग करें। Lighthouse स्वचालित प्रदर्शन, पहुँचनीयता, SEO और अन्य ऑडिट देता है। क्लियर स्टोरेज या क्लीन प्रोफ़ाइल के साथ पहली लोड का परीक्षण करें, फिर लक्ष्य टास्क को पूरा करें। जहाँ पर्याप्त वास्तविक-उपयोगकर्ता डेटा उपलब्ध है, महत्वपूर्ण पेज समूहों और डिवाइस वर्गों की तुलना करें। Core Web Vitals क्षेत्रीय माप हैं: LCP लोडिंग को कवर करता है, INP इंटरएक्टिविटी, और CLS दृश्य स्थिरता।
फ़ील्ड डेटा वास्तविक विज़िट दर्शाता है; लैब परीक्षण समस्या को पुन: उत्पन्न करना आसान बनाता है। उपलब्ध होने पर दोनों का उपयोग करें।
एक सिमुलेटेड लोड INP को माप नहीं सकता क्योंकि कोई उपयोगकर्ता इनपुट नहीं होता; लैब का Total Blocking Time केवल एक प्रॉक्सी है।
3. यात्रा को एंड-टू-एंड ऑडिट करें
निष्कर्षों को यात्रा और तंत्र के द्वारा समूहित करें। पृष्ठ एसेट्स और थर्ड-पार्टी के लिए रिक्वेस्ट आकार, समय और निर्भरताओं की समीक्षा करें। मोबाइल व्यूपोर्ट, कीबोर्ड पाथ, दृश्य फोकस, लेबल, एरर, हेडिंग्स, लिंक का उद्देश्य, ज़ूम, और क्या होता है अगर कोई इमेज, स्क्रिप्ट, या सहमति-आधारित सेवा धीमी या अनुपलब्ध हो, जांचें।
स्वचालित पहुँचनीयता आउटपुट को ट्रायज के रूप में मानें। W3C कहता है कि कोई भी टूल अकेले यह निर्धारित नहीं कर सकता कि कोई साइट पहुँचनीयता मानकों को पूरा करती है; जानकार मानव मूल्यांकन आवश्यक है। खोज के लिए, यह सुनिश्चित करें कि महत्वपूर्ण रेंडर्ड संसाधन क्रॉलर्स के लिए और उपयोगकर्ताओं के लिए उपलब्ध रहें। जब परिवर्तन उनके प्रभाव में हों तो रीडायरेक्ट्स, कैनोनिकल्स, आंतरिक लिंक, robots निर्देश, साइटमैप और संरचित डेटा शामिल करें।
टैग मैनेजर्स, एनालिटिक्स, चैट, भुगतान, फ़ॉन्ट्स, CDN, API, और सहमति टूल की सूची बनाएं जिन पर यह टास्क निर्भर करता है।
भुगतान, प्रमाणीकरण, उपयोगकर्ता डेटा, हेडर, या सुरक्षा कंट्रोल्स के लिए योग्य सुरक्षा और भुगतान समीक्षा प्राप्त करें।
4. एक रैंक्ड बैकलॉग बनाएं
हर आइटम के लिए एक संक्षिप्त परिकल्पना लिखें: इस पृष्ठ या फ़्लो में इस तंत्र को बदलें, क्योंकि साक्ष्य से संकेत मिलता है कि यही समस्या का कारण है; अपेक्षित परिणाम को मापें और निर्धारित गार्डरेल की रक्षा करें। अवलोकन और निदान को अलग रखें। सहेजा गया ट्रेस दिखा सकता है कि कोई बड़ी इमेज सामग्री में देरी कर रही है, लेकिन समाधान के लिए फिर भी डिज़ाइन और सामग्री की समीक्षा आवश्यक है।
आइटमों को प्रभाव, निदान पर विश्वास, प्रयास और जोखिम के आधार पर रैंक करें। प्रभाव वह प्राथमिक यात्रा है जिस पर असर होता है। निदान पर विश्वास से आशय है कि लैब, फ़ील्ड और मैन्युअल साक्ष्य सहमत हैं या नहीं। प्रयास में केवल कोड नहीं, समन्वय भी शामिल है। जोखिम में निर्भरताएँ, सुरक्षा, रिलीज़ की जटिलता और बदलाव को पूर्ववत करने की क्षमता शामिल हैं। गंभीर कार्यात्मक या सुरक्षा जोखिम इस मॉडल से ऊपर प्राथमिकता पा सकते हैं और उनके लिए विशेषज्ञ ट्रायज की आवश्यकता होती है।
मालिक, साक्ष्य लिंक, परिकल्पना, पृष्ठ, माप, गार्डरेल, निर्भरताएँ, रिलीज़ विधि, और रोलबैक ट्रिगर रखें।
जब तक सुरक्षा आवश्यक न बनाये, एक मापनीय परिवर्तन में असंबंधित रिफ़ैक्टर्स को बंडल न करें।
5. सुरक्षित रूप से रिलीज़ करें और वापसी का रास्ता रखें
डिप्लॉयमेंट से पहले यह रिकॉर्ड करें कि क्या बदलेगा, अनुमोदक कौन है, रिलीज़ विंडो, सत्यापन मालिक, सफलता शर्त, रोलबैक ट्रिगर, और पुनर्स्थापना विधि। जहाँ संभव हो प्रतिनिधि नॉन-प्रोडक्शन वातावरण में परीक्षण करें, जिसमें सामग्री, अनुमतियाँ, इंटीग्रेशन, रीडायरेक्ट, सहमति विकल्प, और सामान्य विफलता पथ शामिल हों। प्रोडक्शन तब भी अलग हो सकता है क्योंकि डेटा, कैश, कॉन्फ़िगरेशन, और थर्ड-पार्टी भिन्न होते हैं।
प्लेटफ़ॉर्म सपोर्ट होने पर छोटा रोलआउट, फीचर फ़्लैग, वर्जन्ड एसेट, या उलटने योग्य कॉन्फ़िगरेशन का उपयोग करें। तुलना करने से पहले कैश और CDN व्यवहार की पुष्टि करें। OWASP कॉन्फ़िगरेशन और डिप्लॉयमेंट प्रबंधन को सुरक्षा-टेस्टिंग क्षेत्र मानता है; हेडर्स, अनुमतियाँ, फ़ाइल एक्सपोज़र, और डोमेन/क्लाउड सेटिंग्स को सामान्य अनुकूलन परिवर्तनों की तरह हल्के में न लें।
एक स्पष्ट रूप से पहचाना जा सकने वाला ट्रिगर परिभाषित करें, जैसे विफल चेकआउट, टूटा हुआ नेविगेशन, अप्रत्याशित क्लाइंट त्रुटि, या पहुँचनीयता रिग्रेशन।
एक रोलबैक योजना रिकवरी समय घटा सकती है पर सभी जोखिमों को दूर नहीं कर सकती; भरोसा करने से पहले पुनर्स्थापन का परीक्षण करें।
6. सत्यापित करें, निर्णय लें, और दोहराएँ
रिलीज़ के बाद बेसलाइन फ़ंक्शनल चेक्स और तुलनीय लैब परीक्षण दोहराएँ। संबंधित डिवाइस, ब्राउज़र, स्टेट्स, और इंटीग्रेशन फिर से जाँचें। समान-से-समान की तुलना करें: URL, कैश स्टेट, डिवाइस क्लास, क्षेत्र जहाँ संभव हो, और मापन विंडो। लक्ष्य मीट्रिक के साथ-साथ गार्डरेल की पुष्टि करें।
साक्ष्य को परिपक्व होने का समय दें। Google नोट करता है कि खोज परिवर्तन कई घंटों से महीनों तक दिखाई दे सकते हैं और यह सुझाव देता है कि यह मूल्यांकन करने के लिए हफ्तों तक प्रतीक्षा करें कि क्या वे मददगार रहे। वास्तविक-उपयोगकर्ता प्रदर्शन डेटा समेकित साक्ष्य है, न कि तात्कालिक रिलीज़ निर्णय। यह रिकॉर्ड करें कि रखें, संशोधित करें, जांचें, या रोलबैक करें, फिर सार्थक टेम्पलेट, प्लेटफ़ॉर्म, टैग, सामग्री, या निर्भरता परिवर्तनों के बाद फिर से बेसलाइन बनाएं।
अपेक्षित यात्रा परिणाम में सुधार होता है और सहमति प्राप्त गार्डरेल अखंड रहते हैं।
जब फ़ील्ड या टास्क साक्ष्य लैब परिणाम से टकराएं, या कोई महत्वपूर्ण गार्डरेल रिग्रेस करे तो कार्रवाई करें।