कोड बदलने से पहले एक ग्राहक जर्नी प्रोफाइल करें
एक महत्वपूर्ण रूट और इंटरैक्शन चुनें, जैसे नेविगेशन खोलना, परिणाम फ़िल्टर करना, या फॉर्म सबमिट करना। Chrome DevTools Performance पैनल में इसे साफ़ ब्राउज़र स्थिति से रिकॉर्ड करें। क्रिया को दोहराएँ और एक थ्रोटल्ड-CPU रन के साथ-साथ डेवलपमेंट-मशीन रन भी कैप्चर करें; डेस्कटॉप ट्रेस कम पॉवर्ड फोन पर डिसरप्टिव काम छुपा सकते हैं।
ट्रेस का उपयोग एक संकुचित हाइपोथेसिस परीक्षण के लिए करें, न कि बंडल रिपोर्ट से किसी कंपोनेंट को दोष देने के लिए। Main फ्लेम चार्ट में, चौड़े बार अधिक समय लेते हैं और स्टैक्ड बार कॉल स्टैक दिखाते हैं। किसी Task पर लाल त्रिकोण एक संभावित long task को दर्शाता है; उसे चुनकर initiating-code लिंक का पालन करें। सार्थक परिवर्तन के लिए पहले और बाद के ट्रेसेस सहेजें।
क्रिया से ठीक पहले रिकॉर्ड करें और दृश्यमान परिणाम के बाद रोकें।
रूट, अकाउंट स्थिति और क्रिया क्रम को सुसंगत रखें।
प्रत्येक शीर्ष लागत को उसे बदल सकने वाली टीम या वेंडर के लिए असाइन करें।
ट्रेस को काम की कतार के रूप में पढ़ें
एक long task जाँच का थ्रेशोल्ड है, पूर्ण निदान नहीं। W3C Long Tasks specification 50 मिलीसेकंड या उससे अधिक समय वाले टास्क की रिपोर्ट करती है। एक टास्क के नीचे JavaScript मूल्यांकन, इवेंट हैंडलर, स्टाइल पुनर्गणना, लेआउट, या पेंट देखिए। कॉल स्टैक यह पहचानता है कि कहाँ से शुरू करना है; टाइमिंग दिखाती है कि समस्या कोड, रेंडरिंग, या तीसरे-पक्ष frame में है।
मूल्यवान इंटरैक्शन के दौरान जो लागत बार-बार आती है उसे प्राथमिकता दें। एक छोटा हैंडलर तब भी धीमा महसूस हो सकता है जब वह लेआउट ट्रिगर करे या पहले किए गए काम के पीछे इंतजार करे। ट्रेस एक लैब माप है, इसलिए बदलाव की पुष्टि प्रतिनिधि डिवाइसों पर और जहाँ उपलब्ध हो, गोपनीयता-सचेत फ़ील्ड टेलीमेट्री के साथ करें।
स्टार्टअप पार्सिंग के लिए अलग उपचार चाहिए बनाम पोस्ट-टैप हैंडलर के लिए।
रिफ़ैक्टर करने से पहले बार-बार होने वाले style-write और layout-read पैटर्न खोजें।
ट्रेस, परिदृश्य, और शीर्ष लागत को वर्क आइटम के साथ अटैच करें।
ज़रूरी समय पर कम कोड शिप करें
रूट और उद्देश्य के अनुसार स्क्रिप्ट्स की सूची बनाएं। अनुपयोगी पैकेज, डुप्लिकेट, बंद किए जा चुके एक्सपेरिमेंट और समाप्त फ़ीचर का कोड हटाएँ। फिर रूट-विशिष्ट या कम इस्तेमाल होने वाले फ़ीचर्स को इस तरह विभाजित करें कि वे प्रारंभिक लोड पथ में नहीं, आवश्यकता होने पर लोड हों। डाइनैमिक लोडिंग स्टार्टअप का काम घटा सकती है, लेकिन उपयोगकर्ता को तुरंत फ़ीचर चाहिए हो तो यह दिखाई देने वाली देरी पैदा कर सकती है।
सोचें कि क्या किसी कंपोनेंट को पूरा क्लाइंट-साइड फ़्रेमवर्क चाहिए, क्या कोई यूटिलिटी मौजूदा क्षमता को डुप्लिकेट करती है, और क्या स्टैटिक HTML + छोटा एनहांसमेंट काम कर देगा। देरी किए गए मॉड्यूल की फॉलबैक स्थिति का परीक्षण करें। पेज वैकल्पिक क्षमता को सुंदरता से स्थगित करे, न कि एक मृत कंट्रोल दिखाए।
दस्तावेज़ करें कि किसी रूट पर कौन सी स्क्रिप्ट्स की अनुमति है और क्यों।
इसे वैकल्पिक एडिटर्स, मानचित्र, प्लेयर, या रिपोर्टिंग व्यूज़ के लिए विचार करें।
प्रमाणीकरण, पहुंच, भुगतान, और फॉर्म पूर्णता का परीक्षण करें; जहाँ कंट्रोल प्रभावित हों वहां योग्य समीक्षा लें।
काम को तोड़ें ताकि ब्राउज़र जवाब दे सके
छोटी फंक्शन का नामकरण करने से वे अलग ब्राउज़र टास्क नहीं बनते जब वे सिंक्रोनस तरीके से चलते हैं। किसी लंबे लूप के लिए, काम को बैच करें, तत्काल उपयोगकर्ता-दृश्यमान स्थिति अपडेट करें, फिर जारी रखने से पहले yield दें। इससे ब्राउज़र बैचों के बीच इनपुट और रेंडरिंग प्रक्रिया कर सकेगा।
जहाँ समर्थित हो, scheduler.yield() मेन थ्रेड को नियंत्रण लौटाता है और बाद में काम जारी रखता है; इसे फीचर-डिटेक्ट करें और असमर्थ ब्राउज़रों के लिए फॉलबैक उपयोग करें। हर छोटे ऑपरेशन के बाद yield न करें: इसका ओवरहेड होता है और यह समापन समय बढ़ा सकता है। माप के आधार पर सीमाएँ चुनें, रद्द करने की क्षमता बरकरार रखें, और पुराने परिणामों को नए स्टेट की जगह लेने से रोकें।
नॉनविजिबल फॉलो-अप से पहले स्वीकृति या प्रगति दिखाएँ।
हर आइटम के बाद नहीं, बल्कि मापी गई समय-सीमा पार होने से पहले yield करें।
वर्तमान web.dev मार्गदर्शन isInputPending() पर आधारित नई रणनीति की सलाह नहीं देता।
कंप्यूट को वर्कर पर ले जाएँ, इंटरफ़ेस को नहीं
एक Web Worker एक बैकग्राउंड थ्रेड पर स्क्रिप्ट चलाता है जो मुख्य निष्पादन थ्रेड से अलग होता है। यह महंगी पार्सिंग, डेटा ट्रांसफ़ॉर्मेशन, खोज इंडेक्सिंग, और ऐसी अन्य गणनाओं के लिए उपयुक्त है जिन्हें सीधे इंटरफ़ेस एक्सेस की आवश्यकता नहीं होती। एक परिभाषित इनपुट भेजें, परिभाषित परिणाम लौटाएँ, और रेंडरिंग तथा दृश्य राज्य परिवर्तन मेन थ्रेड पर रखें।
वर्कर्स सार्वभौमिक नहीं हैं। वे सीधे DOM को नहीं बदल सकते और Window का उपयोग नहीं कर सकते, और सामान्य संदेश संचार में डेटा कॉपी होता है। वर्कर निर्माण, डेटा मूवमेंट, और एरर समन्वय एक छोटी गणना पर लागत बढ़ा सकते हैं। पूरे इंटरैक्शन को मापें, अनावश्यक वर्कर्स को समाप्त करें, और यदि वर्कर काम विफल हो तो फॉलबैक डिज़ाइन करें।
ऐसे गणना से शुरू करें जिनका इनपुट और आउटपुट सीरियलाइज़ेबल और टैस्टेबल हो।
पुराने फ़िल्टर, रूट, या क्रिया के लिए बनाए गए परिणामों को अस्वीकार करें।
सामान्य इंटरफ़ेस के माध्यम से सार्थक प्रगति संप्रेषित करें।
तीसरे-पक्ष JavaScript को प्रोडक्शन निर्भरता की तरह गवर्न करें
Analytics, विज्ञापन, एक्सपेरिमेंट्स, सोशल एम्बेड्स, वीडियो प्लेयर्स, और सपोर्ट विजेट रिक्वेस्ट्स, JavaScript मूल्यांकन, iframes, और निर्भरताएँ जोड़ सकते हैं। एक वेंडर स्क्रिप्ट आवश्यक हो सकती है, लेकिन यह एप्लिकेशन टीम के प्रत्यक्ष नियंत्रण के बाहर है और प्रदर्शन, गोपनीयता, सुरक्षा, और निरंतरता को प्रभावित कर सकती है। इसके उद्देश्य, रूट्स, लोडिंग कंडीशन, अनुमोदक, सहमति आवश्यकता, और हटाने के मालिक का इन्वेंटरी बनाएं।
जहाँ परिस्थितियाँ और अनुबंध अनुमति दें, एक प्रतिनिधि पेज की तुलना एक तीसरे-पक्ष ओरिजिन के साथ और बिना करके करें। प्रदर्शन टूल महंगे मूल्यांकन, पेलोड्स, और long-task attribution को उजागर कर सकते हैं। केवल तब एक हल्का या देरी किया हुआ इंटीग्रेशन रखें जब उसके दस्तावेजीकृत मूल्य से मापी गई लागत न्यायोचित हो। जब कोई वैकल्पिक निर्भरता धीमी या अनुपस्थित हो, तो कोर कंटेंट और प्राथमिक ट्रांज़ैक्शन काम की पुष्टि करें।
एक टैग केवल उन रूट्स और स्थितियों पर लोड करें जिन्हें इसकी आवश्यकता है।
टैग-मैनेजर परिवर्तन में प्रदर्शन, गोपनीयता, सुरक्षा, और रोलबैक समीक्षा शामिल करें।
किसी नॉन-क्रिटिकल इंटीग्रेशन को कैसे अक्षम करें इसे दस्तावेज़ और टेस्ट करें।
प्रतिक्रिया क्षमता को रिलीज़ सुरक्षा-चेक बनायें
महत्वपूर्ण जर्नी के लिए उस सफल ट्रेस को हल्के रिग्रेशन चेक में बदलें। शामिल इंटरैक्शन, डिवाइस या CPU सीमाएँ, अपेक्षित प्रतिक्रिया और समीक्षक निर्धारित करें। इसे बंडल और तीसरे-पक्ष की इन्वेंटरी की समीक्षा के साथ जोड़ें, ताकि कोई नया पैकेज या टैग चुपचाप मेन-थ्रेड का काम फिर से न जोड़ दे।
Status Is UP इस साक्ष्य का उपयोग सक्रिय अनुकूलन और सुरक्षित सुधार के लिए करता है, न कि लाइव उपलब्धता मॉनिटरिंग की जगह लेने के लिए। उच्च-जोखिम परिवर्तन से पहले रोलबैक तैयार रखें और रिलीज़ के बाद महत्वपूर्ण फ़्लो सत्यापित करें। परिणाम डिवाइस, नेटवर्क, ब्राउज़र, सामग्री, और अकाउंट स्थिति के अनुसार भिन्न होते हैं; थ्रेशोल्ड को गार्डरेल समझें, गारंटी नहीं।
साझा नेविगेशन, चेकआउट, खोज, या बड़े बंडलों के लिए पहले और बाद के ट्रेसेस की आवश्यकता रखें।
उस फ़ीचर फ़्लैग, टैग सेटिंग या डिप्लॉयमेंट वर्ज़न की पहचान रखें जो पहले से सही सिद्ध हुए व्यवहार को बहाल कर सके।
बड़े रिलीज़, वेंडर परिवर्तन, या डिवाइस-मिक्स शिफ्ट के बाद पुनः प्रोफाइल करें।