साइट-वाइड औसत नहीं, यात्राओं (journeys) से शुरू करें
ऐसी 3 से 5 यात्राओं (journeys) की सूची बनाइए जहाँ देरी का स्पष्ट ग्राहक या संचालन लागत हो: कैंपेन पेज पर लैंड करना, प्रोडक्ट ढूँढना, लीड फॉर्म सबमिट करना, साइन-इन करना, या सपोर्ट रिक्वेस्ट पूरा करना। प्रत्येक के लिए शुरुआत, उपयोगी परिणाम, मुख्य डिवाइस क्लास, और वह पेज या इंटरैक्शन लिखें जिसे अच्छी तरह काम करना चाहिए।
हर यात्रा के लिए अलग बजट रो बनाइए। एक डैशबोर्ड में सार्वजनिक आर्टिकल की तुलना में अधिक कोड हो सकता है, पर उसके फ़िल्टर क्रिया को उत्तरदायित्व (responsiveness) लक्ष्य की जरूरत है। एक मीडिया-रिच प्रोडक्ट पेज बड़े इमेज स्वीकार कर सकता है, पर मुख्य दिखाई देने वाली इमेज के लिए सीमा चाहिए। इससे यह रोका जाता है कि एक कमजोर क्रिटिकल पाथ मूल-स्रोत (origin) के औसत में गायब हो जाए।
उस क्षण का नाम दें जिसे विज़िटर देख या कर सकता है, जैसे ऑफ़र पढ़ना, परिणाम देखना, या फॉर्म की पुष्टि मिलना।
कैशिंग संपत्तियों की लागत को भिन्न कर सकती है, इसलिए रिकॉर्ड करें कि बजट पहली विज़िट, पुनरावृत्ति विज़िट, या दोनों को कवर करता है।
परिणाम और नियंत्रित इनपुट चुनें
परिणामी मैट्रिक्स और इनपुट लिमिट दोनों का उपयोग करें। Google Largest Contentful Paint (LCP) को लोडिंग प्रदर्शन के रूप में, Interaction to Next Paint (INP) को इंटरैक्शन उत्तरदायित्व के रूप में, और Cumulative Layout Shift (CLS) को विज़ुअल स्थिरता के रूप में वर्णित करता है। इनके सुझाए गए अच्छे थ्रेशोल्ड हैं: LCP ≤ 2.5 सेकंड, INP ≤ 200 मिलीसेकंड, और CLS ≤ 0.1 — ये 75वाँ पर्सेंटाइल पर मोबाइल और डेस्कटॉप के लिए अलग से माने जाते हैं।
ऐसी सीमाएँ जोड़ें जो कारण को जल्दी दिखाएँ: प्रारंभिक JavaScript, मुख्य सामग्री से पहले आवश्यक इमेज, रूट के लिए कुल ट्रांसफ़र, थर्ड-पार्टी अनुरोध, और कोई ज्ञात महंगा विजेट। संपीड़ित (compressed) ट्रांसफ़र साइज को सुसंगत रूप से ट्रैक करें। Time to First Byte जैसी डायग्नोस्टिक मदद कर सकती है धीमे लोडिंग की जाँच में, पर यह स्वयं ग्राहक परिणाम नहीं है।
जब यात्रा मुख्य सामग्री के दिखाई देने पर निर्भर हो तो LCP का उपयोग करें।
सर्च, फ़िल्टरिंग, मेनु, और चेकआउट के लिए फील्ड INP का उपयोग करें; फील्ड डेटा न होने पर केवल लेब प्रोक्सी इस्तेमाल करें।
प्रारंभिक रूट और सबसे बड़े योगदानकर्ताओं को कैप करें ताकि ओनर्स जान सकें कि बैरिच होने पर क्या बदलना होगा।
अपनी बेसलाइन से संख्याएँ तय करें
प्रत्येक यात्रा की बेसलाइन पकड़ें। PageSpeed Insights में Chrome User Experience Report (CrUX) फील्ड डेटा, जो वास्तविक Chrome-उपयोगकर्ता अनुभवों का संकलन है, और Lighthouse लेब डेटा, जो नियंत्रित परीक्षण है, को अलग रखें। फील्ड डेटा उपयोगकर्ताओं तक पहुँच रहे अनुभव की जांच करता है; लेब टेस्ट रिलीज़ से पहले बदलाव को पुनरुत्पाद्य बनाते हैं।
कम से कम मोबाइल और डेस्कटॉप के अनुसार सेगमेंट करें और जहाँ संभव हो, क्रिटिकल टेम्पलेट या URL के अनुसार भी। PageSpeed Insights URL डेटा से ओरिजिन डेटा पर बैकअप कर सकता है, और कुछ पृष्ठों के पास कोई CrUX डेटा नहीं होता। उस स्थिति को लेब बेसलाइन के रूप में लेबल करें और महत्वपूर्ण यात्राओं के लिए वास्तविक-यूजर मापन जोड़ें। प्रत्येक बेसलाइन के साथ टेस्ट URL, डिवाइस और नेटवर्क प्रोफ़ाइल, कैश स्टेट, तारीख, और टूल संस्करण रखें।
एक ऐसा लक्ष्य चुनें जो बेसलाइन की योजनाबद्ध रूप से सुधार करे, फिर उसे प्रतिनिधि परिस्थितियों पर टेस्ट करें। एक बजट जो सामान्य रिलीज़ों को ब्लॉक कर देता है उसे बाइपास कर दिया जाएगा; जो आज के अनुभव से ऊपर है वह किसी की सुरक्षा नहीं करता।
75वाँ पर्सेंटाइल वह मान है जिसके बराबर या उससे कम 75% अवलोकित अनुभव आते हैं; यह औसत नहीं है।
बजट को रिलीज़ नियम बनाएं
बजट को कोड या रिलीज़ चेकलिस्ट के पास संस्करण-नियंत्रित, समीक्षा योग्य स्थान में रखें। प्रत्येक रो में यात्रा, मैट्रिक, टेस्ट प्रोफ़ाइल या पॉपुलेशन, चेतावनी थ्रेशोल्ड, त्रुटि थ्रेशोल्ड, ओनर, मापन विधि, और अपवाद मार्ग होना चाहिए। MDN चेतावनी और त्रुटि स्तरों की सिफारिश करता है: चेतावनी प्रासंगिक योजना का समर्थन करती है, जबकि त्रुटि एक ऊपरी सीमा है जिसका ग्राहकों पर नोटिसेबल नकारात्मक प्रभाव पड़ता है।
विश्वसनीय चेक स्वचालित करें। एक बंडलर किसी अत्यधिक आकार की संपत्ति या प्रारंभिक एंट्री-पॉइंट को अस्वीकार कर सकता है; webpack अधिकतम एसेट और एंट्री-पॉइंट सीमाओं और प्रोडक्शन त्रुटि हिंट्स का समर्थन करता है। प्रभावित यात्रा के लिए पुल रिक्वेस्ट्स या रिलीज़ कैंडिडेट्स में पुनरुत्पाद्य लेब टेस्ट चलाएँ। पोस्ट-रिलीज़ सत्यापन और प्राथमिकता के लिए फील्ड मैट्रिक्स रखें; इन्हें एक अविश्वसनीय बिल्ड गेट के रूप में न लें।
जब कोई सीमा फेल हो, तो किसी एसेट को कम करें, गैर-ज़रूरी कोड स्थगित करें, अनुभव बदलें, रिलीज़ को विभाजित करें, या अपवाद मंज़ूर करें। बिल्ड पास कराने के लिए थ्रेशोल्ड को चुपचाप बढ़ाएँ नहीं।
रिलीज़ से पहले एक प्रोडक्ट और तकनीकी ओनर, ग्राहक प्रभाव, समाप्ति तिथि, और रेमेडिएशन टास्क रिकॉर्ड करें।
एक प्रोटेक्टेड यात्रा पर पुनरुत्पाद्य त्रुटि थ्रेशोल्ड को ब्लॉक करें; चेतावनी थ्रेशोल्ड पर सूचित करें और जाँच करें।
लॉन्च के बाद सत्यापित करें और रेमेडिएट करें
पेज वेट पूर्ण अनुभव की भविष्यवाणी नहीं करता। रिक्वेस्ट ऑर्डर, रेंडर-ब्लॉकिंग वर्क, डिवाइस क्षमता, नेटवर्क शर्तें, कैशिंग, और थर्ड-पार्टी भी मायने रखते हैं। इनपुट सीमाएँ विकास को पकड़ने के लिए रखें और परिणाम-मीट्रिक्स यह परीक्षा करें कि पाथ उपयोग योग्य है या नहीं। गहराई से डायग्नोस्टिक्स के लिए W3C Resource Timing इंटरफ़ेस रिसोर्स टाइमिंग और ट्रांसफ़र, एन्कोडेड और डिकोडेड साइज प्रदर्शित करता है। क्रॉस-ऑरिजिन टाइमिंग विवरण timing permissions द्वारा प्रतिबंधित हो सकता है, इसलिए अधूरा वॉटरफ़ॉल यह सिद्ध नहीं करता कि कोई थर्ड-पार्टी लागत नहीं है।
महत्वपूर्ण टेम्पलेट, प्लेटफ़ॉर्म, मार्केटिंग-टैग, या ट्रैफ़िक परिवर्तनों के बाद फील्ड परिणामों की समीक्षा करें। यदि LCP बिगड़ता है तो सर्वर रिस्पॉन्स, LCP रिसोर्स, और रेंडर-ब्लॉकिंग कार्य की जांच करें। यदि INP बिगड़ता है तो वास्तविक इंटरैक्शन की जाँच करें; Lighthouse INP को माप नहीं सकता क्योंकि उसमें यूज़र इनपुट नहीं होता, हालाँकि Total Blocking Time लेब प्रॉक्सी है। SIU की सक्रिय ऑप्टिमाइज़ेशन वर्कफ़्लो का उपयोग कर एक ब्रिच का ट्रायैज करें, क्रिटिकल पाथ को स्थिर करें, और उसी मापन संदर्भ में फिक्स को सत्यापित करें।
समाप्त हो चुके अपवाद तेज़ी से उस अस्थायी प्रदर्शन ऋण को उजागर करते हैं जो स्थायी बन गया था।