पहले निर्णय तय करें, फिर टूल चुनें
कुछ भी चलाने से पहले उस पृष्ठ, दर्शक, और खतरे में पड़े कार्य का नाम लें: मोबाइल प्रोडक्ट पेज, चेकआउट, या लीड फॉर्म। फिर सबूत के प्रकार का चयन करें। लैब डेटा नियंत्रित परीक्षण है जो पुनरुत्पादन योग्य डिबगिंग के लिए है। फील्ड डेटा वास्तविक-उपयोगकर्ता अनुभव का समेकित संकेत है जो प्राथमिकता तय करने में मदद करता है। ब्राउज़र ट्रेस स्थानीय रनटाइम काम समझाने में मदद करता है। ये परस्पर पूरक हैं, एक-दूसरे के विकल्प नहीं।
यह पूछें कि क्या रोक रहा है कि विज़िटर एक महत्वपूर्ण कार्य पूरा करे, न कि कैसे स्कोर प्राप्त किया जाए।
अधिक उत्पाद जोड़ने से पहले एक ऑडिट, उपलब्ध फील्ड डेटा, और एक निदान टूल का उपयोग करें।
एक परिणाम परीक्षण किए गए URL, स्थितियों, या सैंपल पर लागू होता है; यह हर विज़िटर पर फैसला नहीं देता।
रिपीटेबल पेज-लोड ऑडिट के लिए Lighthouse और PageSpeed Insights का उपयोग करें
Lighthouse एक ओपन-सोर्स स्वचालित ऑडिट है जो Chrome DevTools में, कमांड लाइन से, या सतत एकीकरण में चलाया जा सकता है। यह परफ़ॉर्मेंस, पहुंचयोग्यता, SEO, और अधिक का ऑडिट करता है। PageSpeed Insights किसी URL के लिए Lighthouse डायग्नोस्टिक्स चलाता है और उपलब्ध होने पर रियल-यूज़र डेटा प्रस्तुत करता है। किसी प्रतिनिधि पृष्ठ का बेसलाइन लेने, फेल हुए ऑडिट्स की जाँच करने, और परिभाषित बदलाव के बाद नियंत्रित रीटेस्ट की तुलना करने के लिए किसी भी एक का उपयोग करें।
टेस्ट सेटअप में ऑडिट किए गए पृष्ठ का व्यवहार और कौन से ऑडिट्स जांच के लायक हैं।
एक अच्छा Lighthouse स्कोर अनिवार्य रूप से असली-यूज़र अनुभव को अच्छा नहीं बनाता; Google दस्तावेज़ करता है कि लैब और फील्ड परिणाम भिन्न हो सकते हैं।
किसी बदलाव के बाद उसी पृष्ठ और सेटिंग्स को रीटेस्ट करें; इसे एक-बार का गेट न बनाएं।
वास्तविक-उपयोगकर्ता अनुभव प्राथमिकता देने के लिए फील्ड डेटा का उपयोग करें
PageSpeed Insights का फील्ड डेटा Chrome User Experience Report से आता है और पिछली 28-दिन की अवधि को कवर करता है। यह Largest Contentful Paint, Interaction to Next Paint, और Cumulative Layout Shift सहित माप रिपोर्ट करता है। जब आपको एक URL के बजाय पृष्ठों के समूह की ज़रूरत हो तो Search Console की Core Web Vitals रिपोर्ट मददगार है। फील्ड डेटा यह तय करने में उपयोग करें कि कौन सा टेम्पलेट, डिवाइस समूह, या मुद्दा पहले ध्यान का पात्र है।
जांचें कि परिणाम पृष्ठ-स्तरीय है या ऑरिजिन-स्तरीय और क्या URL के पास पर्याप्त डेटा था।
फील्ड डेटा ऐतिहासिक और प्राइवेसी-एग्रीगेटेड होता है, इसलिए यह किसी रिलीज़ के प्रभाव की तुरंत पुष्टि नहीं कर सकता।
Google LCP के लिए 2.5 सेकंड के भीतर, INP 200 मिलीसेकंड से नीचे, और CLS 0.1 से नीचे की सिफारिश करता है।
किसी ऑडिट को समझाने के लिए Chrome DevTools का उपयोग करें
जब कोई ऑडिट या फील्ड पैटर्न धीमे लोडिंग, देरी वाली इंटरैक्शन, या विज़ुअल मूवमेंट की ओर इशारा करे, तो Chrome DevTools Performance में यात्रा रिकॉर्ड करें। यह CPU प्रोफाइल रिकॉर्ड करता है और स्थानीय LCP, CLS, और इंटरैक्शन के बाद INP दिखा सकता है। इसका टाइमलाइन डेवलपर को सिफारिशों की सूची से अनुमान लगाने के बजाय ब्राउज़र काम की जाँच करने में मदद करती है।
उस viewport, CPU, और नेटवर्क कंडीशन का उपयोग करें जो प्रभावित ऑडियंस की सूरत हाल के अनुरूप हो।
एक ट्रेस उस डिवाइस, कनेक्शन, कैश स्थिति, और रिकॉर्ड की गई यात्रा को प्रतिबिंबित करता है। सामान्यीकरण करने से पहले प्रासंगिक यात्राओं को पुनरुत्पादित करें।
संभावित कारण, किया गया बदलाव, और अपेक्षित विज़िटर प्रभाव रिकॉर्ड करें।
स्वचालित पहुँचयोग्यता जाँच को योग्य मानव मूल्यांकन के साथ जोड़ें
एक पहुँचयोग्यता मूल्यांकन टूल का उपयोग मशीन-टेस्टेबल समस्याओं को जल्दी और बार-बार पकड़ने के लिए करें। W3C WAI उपकरणों की सूची और चयन मार्गदर्शन बनाए रखता है, पर कहता है कि कोई भी टूल अकेले यह निर्धारित नहीं कर सकता कि साइट पहुँचयोग्यता मानकों को पूरा करती है। स्वचालित निष्कर्षों का उपयोग समीक्षा कतार बनाने के लिए करें, फिर प्रतिनिधि पृष्ठों, कीबोर्ड संचालन, फोकस व्यवहार, त्रुटि हैंडलिंग, और सामग्री की योग्य समीक्षकों के साथ निरीक्षण करें।
तेज़ खोज और दोहराए जा सकने वाले दोषों की रोकथाम।
यह पूर्ण पहुँचयोग्यता अनुपालन निर्धारित नहीं कर सकता और मानव मूल्यांकन का स्थान नहीं ले सकता।
स्वचालित परिणाम को कानूनी अनुपालन के रूप में प्रचारित न करें; जब मायने रखता है तो योग्य पहुँचयोग्यता और कानूनी समीक्षा प्राप्त करें।
फ़ोकस्ड सुरक्षा टूल्स को सावधानी से और अधिकरण के भीतर उपयोग करें
Mozilla’s HTTP Observatory HTTP हेडर्स और अन्य प्रमुख सुरक्षा कॉन्फ़िगरेशन की जांच करता है, सार्वजनिक-आधारित हेडर हाइजीन के लिए प्रशासकों को एक शुरुआती बिंदु देता है। प्रस्तावित हेडर परिवर्तनों को प्रोडक्शन के बाहर मान्य करें क्योंकि नीतियाँ स्क्रिप्ट्स, एम्बेडेड सर्विसेज़, और यूज़र फ्लोज़ को प्रभावित कर सकती हैं। यह सुरक्षा का एक हिस्सा आकलन करता है, हर एप्लिकेशन जोखिम नहीं।
OWASP ZAP ट्रैफ़िक का पैसिव स्कैन कर सकता है और सक्रिय रूप से एप्लिकेशन पर परीक्षण कर सकता है, पर केवल उन्हीं सिस्टम्स का परीक्षण करें जिनका आपको अधिकरण (authorization) प्राप्त है।
ZAP कहता है कि सक्रिय स्कैनिंग एक वास्तविक हमला है जो लक्ष्यों को जोखिम में डाल सकता है। पैसिव स्कैनिंग प्राधिकृत या अनदेखे क्षेत्रों को मिस कर सकती है।
पैमেন্ট, प्रमाणीकरण, संवेदनशील डेटा, या महत्वपूर्ण निष्कर्षों के लिए योग्य सुरक्षा पेशेवरों को शामिल करें।
टूल आउटपुट को SIU रेमेडिएशन में बदलें, न कि स्कोर-चेसिंग में
एक टिकाऊ लूप का उपयोग करें: एक बेसलाइन कैप्चर करें, एक संभावित कारण पहचानें, सबसे छोटा सुरक्षित परिवर्तन करें, उसी पथ को रीटेस्ट करें, और पर्याप्त समय के बाद फील्ड ट्रेंड का निरीक्षण करें। विज़िटर कार्य को केंद्रीय रखें। एक अवरोधक संपत्ति को कम करना तभी मूल्यवान है जब वह उपयोगी अनुभव में सुधार करे बिना खरीद, साइन-इन, पहुँचयोग्यता, सहमति, या एनालिटिक्स व्यवहार को तोड़े।
फील्ड प्रभाव, पुनरुत्पादित ट्रेस, या स्पष्ट यूज़र-फेसिंग दोष से समर्थित बदलावों को प्राथमिकता दें।
स्टेजिंग का उपयोग करें, एक मालिक, स्वीकृति मापदंड, और रोलबैक योजना रखें। SIU अनावश्यक अनुभव गिरावट को रोकता है।
परिवर्तन रिकॉर्ड में केवल स्कोर ही नहीं बल्कि मेट्रिक, टेस्ट शर्तें, और पूरा किया गया विज़िटर कार्य शामिल रखें।