घड्याळाच्या पलीकडे: वेब परफॉर्मन्स API ला वास्तविक वापरकर्ता अनुभवाशी जोडणे

डिजिटल अर्थव्यवस्थेत, वेग हे केवळ एक वैशिष्ट्य नाही; तर तो वापरकर्त्याच्या अनुभवाचा आधार आहे. स्लो वेबसाइटमुळे वापरकर्ते नाराज होऊ शकतात, बाऊन्स रेट वाढू शकतो आणि महसुलावर थेट परिणाम होतो. अनेक वर्षांपासून, डेव्हलपर्स कार्यक्षमता मोजण्यासाठी window.onload सारख्या टाइमिंग मेट्रिक्सवर अवलंबून आहेत. परंतु जलद लोड होणारा वेळ खरोखरच आनंदी वापरकर्त्याच्या बरोबरीचा आहे का? याचे उत्तर बहुतेक वेळा नाही असे असते.

एखादे वेबपेज एका सेकंदाच्या आत त्याचे सर्व तांत्रिक रिसोर्सेस लोड करणे पूर्ण करू शकते, तरीही ते वेबपेज सुस्त आणि वापरण्यास अयोग्य वाटते. हे वेब डेव्हलपमेंटमधील एका महत्त्वपूर्ण बदलावर प्रकाश टाकते: तांत्रिक वेळेचे मापन करण्यापासून मानवी अनुभवाचे प्रमाण निश्चित करण्याकडे कल. आधुनिक वेब परफॉर्मन्स ही दोन दृष्टिकोनांची कथा आहे: वेब परफॉर्मन्स API द्वारे प्रदान केलेला ग्रॅन्युलर, लो-लेव्हल डेटा आणि Google च्या कोअर वेब व्हायटल्ससारखे उच्च-स्तरीय, वापरकर्ता-केंद्रित मेट्रिक्स.

हे सर्वसमावेशक मार्गदर्शक त्यातील अंतर कमी करेल. आम्ही वेब परफॉर्मन्स API च्या शक्तिशाली सूटचा शोध घेणार आहोत, जे आमचे डायग्नोस्टिक टूल्स म्हणून काम करतात. मग, आम्ही आधुनिक वापरकर्ता अनुभव मेट्रिक्सचा अभ्यास करू, जे कार्यक्षमता कशी *वाटते* हे सांगतात. सर्वात महत्त्वाचे म्हणजे, आम्ही गोष्टी एकमेकांशी जोडून दाखवू, म्हणजेच तुमच्या जागतिक प्रेक्षकांसाठी खराब वापरकर्ता अनुभवाची मूळ कारणे शोधण्यासाठी आणि त्यांचे निराकरण करण्यासाठी लो-लेव्हल टाइमिंग डेटाचा वापर कसा करायचा.

आधारस्तंभ: वेब परफॉर्मन्स API समजून घेणे

वेब परफॉर्मन्स API हे स्टँडर्डाइज्ड ब्राउझर इंटरफेसचा एक संच आहे, जो डेव्हलपर्सना वेब पेजच्या नेव्हिगेशन आणि रेंडरिंगशी संबंधित अत्यंत तपशीलवार आणि अचूक टाइमिंग डेटा एक्सेस करण्याची परवानगी देतो. ते कार्यक्षमतेच्या मापनाचा आधार आहेत, जे आम्हाला साध्या स्टॉपवॉचच्या पलीकडे जाण्यास आणि नेटवर्क रिक्वेस्ट्स, पार्सिंग आणि रेंडरिंगचे गुंतागुंतीचे नृत्य समजून घेण्यास मदत करतात.

नेव्हिगेशन टाइमिंग API: पेजचा प्रवास

नेव्हिगेशन टाइमिंग API मुख्य डॉक्युमेंट लोड होण्यासाठी लागणाऱ्या वेळेचे तपशीलवार विश्लेषण पुरवते. वापरकर्ता नेव्हिगेशन सुरू करतो (जसे की लिंकवर क्लिक करणे) त्या क्षणापासून ते पेज पूर्णपणे लोड होईपर्यंतचे टप्पे हे API कॅप्चर करते. पेज लोड होण्याच्या प्रक्रियेतील हे आपले पहिले आणि सर्वात मूलभूत दृश्य आहे.

तुम्ही हे डेटा एका साध्या JavaScript कॉलने एक्सेस करू शकता:

const navigationEntry = performance.getEntriesByType('navigation')[0]; console.log(navigationEntry.toJSON());

हे टाइमस्टॅम्पने भरलेली ऑब्जेक्ट रिटर्न करते. काही प्रमुख गुणधर्म:

• fetchStart: ब्राउझर डॉक्युमेंट फेच करणे कधी सुरू करते.
• responseStart: ब्राउझरला सर्व्हरकडून रिस्पॉन्सचा पहिला बाइट कधी मिळतो. fetchStart आणि responseStart मधील वेळेला बहुतेक वेळा टाइम टू फर्स्ट बाइट (TTFB) म्हटले जाते.
• domContentLoadedEventEnd: स्टाइलशीट, इमेजेस आणि सबफ्रेम्स लोड होण्याची प्रतीक्षा न करता, इनिशियल HTML डॉक्युमेंट पूर्णपणे लोड आणि पार्स कधी होते.
• loadEventEnd: पेजसाठी असलेले सर्व रिसोर्सेस (इमेजेस, CSS, इत्यादी) पूर्णपणे लोड कधी होतात.

खूप काळापासून, loadEventEnd हे गोल्ड स्टँडर्ड होते. तथापि, त्याची मर्यादा गंभीर आहे: वापरकर्त्याला अर्थपूर्ण कंटेंट कधी *दिसतो* किंवा तो पेजबरोबर कधी *इंटरॅक्ट* करू शकतो याबद्दल ते काहीही सांगत नाही. हे एक तांत्रिक माइलस्टोन आहे, मानवी नाही.

रिसोर्स टाइमिंग API: घटकांचे विघटन

वेब पेज क्वचितच एक सिंगल फाइल असते. हे HTML, CSS, JavaScript, इमेजेस, फॉन्ट आणि API कॉल्सचे असेंब्ली आहे. रिसोर्स टाइमिंग API तुम्हाला या प्रत्येक इंडिव्हिज्युअल रिसोर्सेससाठी नेटवर्क टाइमिंग तपासण्याची परवानगी देते.

बॉटलनेक ओळखण्यासाठी हे खूपच उपयुक्त आहे. दुसर्‍या खंडातून कंटेंट डिलिव्हरी नेटवर्कमधील (CDN) मोठी, अनऑप्टिमाइज्ड हीरो इमेज इनिशियल रेंडरला स्लो करते का? थर्ड-पार्टी ॲनालिटिक्स स्क्रिप्ट मुख्य थ्रेडला ब्लॉक करत आहे का? रिसोर्स टाइमिंग तुम्हाला या प्रश्नांची उत्तरे देण्यास मदत करते.

तुम्ही याप्रमाणे सर्व रिसोर्सेसची लिस्ट मिळवू शकता:

const resourceEntries = performance.getEntriesByType('resource'); resourceEntries.forEach(resource => { if (resource.duration > 200) { // 200ms पेक्षा जास्त वेळ लागलेले रिसोर्सेस शोधा console.log(`स्लो रिसोर्स: ${resource.name}, कालावधी: ${resource.duration}ms`); } });

name (रिसोर्सचा URL), initiatorType (रिसोर्स लोड होण्याचे कारण, उदा. 'img', 'script') आणि duration (ते फेच करण्यासाठी लागणारा एकूण वेळ) यांचा प्रमुख गुणधर्मांमध्ये समावेश आहे.

यूजर टाइमिंग API: तुमच्या ॲप्लिकेशनच्या लॉजिकचे मापन

कधीकधी, कार्यक्षमतेतील अडथळा ॲसेट लोड करण्यात नसतो, तर क्लायंट-साइड कोडमध्ये असतो. API कडून डेटा मिळाल्यानंतर तुमच्या सिंगल-पेज ॲप्लिकेशनला (SPA) कॉम्प्लेक्स कंपोनेंट रेंडर करण्यासाठी किती वेळ लागतो? यूजर टाइमिंग API तुम्हाला कस्टम, ॲप्लिकेशन-स्पेसिफिक मापन तयार करण्याची परवानगी देतो.

हे दोन मुख्य पद्धतींनी कार्य करते:

• performance.mark(name): परफॉर्मन्स बफरमध्ये नेमड टाइमस्टॅम्प तयार करते.
• performance.measure(name, startMark, endMark): दोन मार्कमधील कालावधीची गणना करते आणि नेमड मापन तयार करते.

उदाहरण: प्रॉडक्ट लिस्ट कंपोनेंटच्या रेंडर वेळेचे मापन.

// तुम्ही डेटा फेच करणे सुरू करता तेव्हा performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // फेच केल्यानंतर, रेंडर करण्यापूर्वी performance.mark('product-list-render-start'); renderProductList(data); // रेंडरिंग पूर्ण झाल्यानंतर लगेच performance.mark('product-list-render-end'); // मापन तयार करा performance.measure( 'प्रॉडक्ट लिस्ट रेंडर टाइम', 'product-list-render-start', 'product-list-render-end' ); });

हे तुम्हाला तुमच्या ॲप्लिकेशनच्या त्या भागांचे मापन करण्यासाठी अचूक कंट्रोल देते जे वापरकर्त्याच्या वर्कफ्लोसाठी सर्वात महत्वाचे आहेत.

परफॉर्मन्सऑब्झर्व्हर: आधुनिक, कार्यक्षम दृष्टिकोन

सतत performance.getEntriesByType() ला पोल करणे कार्यक्षम नाही. PerformanceObserver API परफॉर्मन्स एंट्रीज ऐकण्याचा एक चांगला मार्ग पुरवतो. तुम्ही विशिष्ट एंट्री प्रकारांसाठी सबस्क्राइब करता आणि ब्राउझर रेकॉर्ड केल्यानुसार तुमच्या कॉलबॅक फंक्शनला asynchronously सूचित करतो. तुमच्या ॲप्लिकेशनवर ओव्हरहेड न वाढवता परफॉर्मन्स डेटा गोळा करण्याचा हा शिफारस केलेला मार्ग आहे.

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(`एंट्री प्रकार: ${entry.entryType}, नाव: ${entry.name}`); } }); observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });

हा ऑब्झर्व्हर केवळ वरील पारंपरिक मेट्रिक्स गोळा करण्याचीच किल्ली नाही, तर आधुनिक, वापरकर्ता-केंद्रित मेट्रिक्स गोळा करण्याची देखील किल्ली आहे, ज्यावर आपण पुढे चर्चा करणार आहोत.

वापरकर्ता-केंद्रिततेकडे बदल: कोअर वेब व्हायटल्स

एखादे पेज 2 सेकंदात लोड झाले हे उपयुक्त आहे हे जाणून घेणे, परंतु ते महत्त्वाच्या प्रश्नांची उत्तरे देत नाही: त्या 2 सेकंदांसाठी वापरकर्ता रिकाम्या स्क्रीनकडे टक लावून बघत होता का? ते पेजबरोबर इंटरॅक्ट करू शकत होते, की ते गोठलेले होते? वाचण्याचा प्रयत्न करत असताना कंटेंट अनपेक्षितपणे इकडे-तिकडे उडी मारत होता का?

या समस्येचे निराकरण करण्यासाठी, Google ने कोअर वेब व्हायटल्स (CWV) सादर केले, जे तीन प्रमुख डायमेन्शनमध्ये पेजच्या रिअल-वर्ल्ड यूजर अनुभवाचे मापन करण्यासाठी डिझाइन केलेले मेट्रिक्सचा संच आहे: लोडिंग, इंटरॅक्टिव्हिटी आणि व्हिज्युअल स्टॅबिलिटी.

लार्जेस्ट कंटेंटफुल पेंट (LCP): परसिप्ड लोडिंगचे मापन

LCP व्ह्यूपोर्टमध्ये दिसणार्‍या सर्वात मोठ्या इमेज किंवा टेक्स्ट ब्लॉकच्या रेंडर वेळेचे मापन करते. वापरकर्त्याला पेजचा मुख्य कंटेंट लोड झाल्याचे केव्हा वाटते यासाठी हे उत्कृष्ट आहे. हे थेट वापरकर्त्याच्या प्रश्नाचे उत्तर देते: "हे पेज अजून उपयुक्त आहे का?"

• चांगले: 2.5 सेकंदांपेक्षा कमी
• सुधारणेची आवश्यकता: 2.5s आणि 4.0s च्या दरम्यान
• खराब: 4.0 सेकंदांपेक्षा जास्त

loadEventEnd च्या विपरीत, LCP वापरकर्त्याला प्रथम काय दिसते यावर लक्ष केंद्रित करते, ज्यामुळे ते परसिप्ड लोड स्पीडचे अधिक अचूक प्रतिबिंब बनते.

इंटरॅक्शन टू नेक्स्ट पेंट (INP): रिस्पॉन्सिव्हनेसचे मापन

INP हे फर्स्ट इनपुट डिले (FID) चे उत्तराधिकारी आहे आणि मार्च 2024 मध्ये अधिकृत कोअर वेब व्हायटल बनले. FID ने केवळ *पहिल्या* इंटरॅक्शनमधील डिले मोजला, तर INP पेजच्या लाइफसायकलमध्ये *सर्व* यूजर इंटरॅक्शन (क्लिक, टॅप, की प्रेस) च्या लेटन्सीचे मापन करते. हे सर्वात लांब इंटरॅक्शन रिपोर्ट करते, ज्यामुळे वापरकर्त्याला येणाऱ्या सर्वात वाईट रिस्पॉन्सिव्हनेसला प्रभावीपणे ओळखता येते.

INP यूजरच्या इनपुटपासून ते पुढील फ्रेम पेंट होईपर्यंतचा संपूर्ण वेळ मोजतो, जे व्हिज्युअल फीडबॅक दर्शवते. हे वापरकर्त्याच्या प्रश्नाचे उत्तर देते: "जेव्हा मी हे बटण क्लिक करतो, तेव्हा पेज त्वरित प्रतिसाद देतो का?"

• चांगले: 200 मिलीसेकंदांपेक्षा कमी
• सुधारणेची आवश्यकता: 200ms आणि 500ms च्या दरम्यान
• खराब: 500ms पेक्षा जास्त

उच्च INP सहसा व्यस्त मुख्य थ्रेडमुळे होतो, जिथे लांब-काळ चालणारे JavaScript कार्य ब्राउझरला यूजर इनपुटला प्रतिसाद देण्यास प्रतिबंधित करतात.

क्युमुलेटिव्ह लेआउट शिफ्ट (CLS): व्हिज्युअल स्टॅबिलिटीचे मापन

CLS पेजच्या व्हिज्युअल स्टॅबिलिटीचे मापन करते. लोडिंग प्रक्रियेदरम्यान स्क्रीनवर किती कंटेंट अनपेक्षितपणे फिरतो हे ते निर्धारित करते. उच्च CLS स्कोअर हे यूजर फ्रस्ट्रेशनचे एक सामान्य कारण आहे, जसे की तुम्ही एखाद्या बटणावर क्लिक करण्याचा प्रयत्न करता, परंतु त्याऐवजी एक ॲड त्याच्या वर लोड होते, ज्यामुळे बटण खाली सरकते आणि तुम्ही त्या ॲडवर क्लिक करता.

CLS वापरकर्त्याच्या प्रश्नाचे उत्तर देते: "मी हे पेज इकडे-तिकडे उड्या मारणाऱ्या घटकांशिवाय वापरू शकतो का?"

• चांगले: 0.1 पेक्षा कमी
• सुधारणेची आवश्यकता: 0.1 आणि 0.25 च्या दरम्यान
• खराब: 0.25 पेक्षा जास्त

उच्च CLS ची सामान्य कारणे म्हणजे डायमेन्शन नसलेल्या इमेजेस किंवा आयफ्रेम, वेब फॉन्ट उशिरा लोड होणे किंवा कंटेंटसाठी जागा रिझर्व्ह न करता डायनॅमिकपणे पेजमध्ये इंजेक्ट करणे.

अंतर कमी करणे: खराब वापरकर्ता अनुभवाचे निदान करण्यासाठी API चा वापर करणे

येथे सर्व काही एकत्र येते. कोअर वेब व्हायटल्स आम्हाला सांगतात की वापरकर्त्याने *काय* अनुभवले (उदा. स्लो LCP). वेब परफॉर्मन्स API आम्हाला सांगतात की ते *का* घडले. या दोघांना एकत्र करून, आम्ही केवळ कार्यक्षमतेचे निरीक्षण करण्याऐवजी सक्रियपणे त्याचे निदान आणि निराकरण करतो.

स्लो LCP चे निदान करणे

कल्पना करा की तुमचे रिअल यूजर मॉनिटरिंग (RUM) टूल विशिष्ट प्रदेशातील वापरकर्त्यांसाठी 4.5 सेकंदांचा खराब LCP रिपोर्ट करते. तुम्ही ते कसे ठीक कराल? तुम्हाला LCP वेळेला त्याच्या घटकांमध्ये विभाजित करणे आवश्यक आहे.

1. टाइम टू फर्स्ट बाइट (TTFB): सर्व्हरला प्रतिसाद देण्यासाठी वेळ लागतो का? नेव्हिगेशन टाइमिंग API वापरा. responseStart - requestStart चा कालावधी तुम्हाला अचूक TTFB देतो. जर हे जास्त असेल, तर समस्या तुमच्या बॅकएंड, सर्व्हर कॉन्फिगरेशन किंवा डेटाबेसमध्ये आहे, फ्रंटएंडमध्ये नाही.
2. रिसोर्स लोड डिले आणि टाइम: LCP एलिमेंट लोड होण्यासाठी वेळ लागतो का? प्रथम, LCP एलिमेंट ओळखा (उदा. हीरो इमेज). तुम्ही एलिमेंट मिळवण्यासाठी 'largest-contentful-paint' साठी PerformanceObserver वापरू शकता. त्यानंतर, त्या एलिमेंटच्या URL साठी एंट्री शोधण्यासाठी रिसोर्स टाइमिंग API वापरा. त्याच्या टाइमलाइनचे विश्लेषण करा: connectStart ते connectEnd (स्लो नेटवर्क) पर्यंत जास्त वेळ होता का? responseStart ते responseEnd जास्त होता (खूप मोठी फाइल साइज)? CSS किंवा JavaScript सारख्या इतर रेंडर-ब्लॉकिंग रिसोर्समुळे त्याचा fetchStart उशीर झाला होता का?
3. एलिमेंट रेंडर डिले: रिसोर्स लोड होणे पूर्ण झाल्यानंतर ते प्रत्यक्षात स्क्रीनवर पेंट होईपर्यंतचा हा वेळ आहे. हे मुख्य थ्रेड इतर कार्यांमध्ये व्यस्त असल्यामुळे होऊ शकते, जसे की मोठे JavaScript बंडल एक्झिक्युट करणे.

नेव्हिगेशन आणि रिसोर्स टाइमिंगचा वापर करून, तुम्ही हे निश्चित करू शकता की स्लो LCP स्लो सर्व्हरमुळे, रेंडर-ब्लॉकिंग स्क्रिप्टमुळे किंवा मोठ्या, अनऑप्टिमाइज्ड इमेजमुळे आहे.

खराब INP ची तपासणी करणे

तुमचे वापरकर्ते तक्रार करत आहेत की "ॲड टू कार्ट" बटणावर क्लिक केल्यावर ते लॅगी वाटते. तुमचा INP मेट्रिक "खराब" रेंजमध्ये आहे. हे जवळजवळ नेहमीच मुख्य थ्रेडची समस्या असते.

1. लांब टास्क ओळखा: लांब टास्क API हे तुमचे प्राथमिक साधन आहे. हे मुख्य थ्रेडवरील 50ms पेक्षा जास्त वेळ घेणारे कोणतेही कार्य रिपोर्ट करते, कारण जास्त वेळ घेतल्यास वापरकर्त्याला लक्षणीय डिलेचा धोका असतो. 'longtask' एंट्रीज ऐकण्यासाठी PerformanceObserver सेट करा.
2. वापरकर्त्याच्या ॲक्शनशी सहसंबंध जोडा: लांब टास्क ही एक समस्या आहे, परंतु ती तेव्हाच उद्भवते जेव्हा वापरकर्ता इंटरॅक्ट करण्याचा प्रयत्न करत असतो. तुम्ही 'event' प्रकारावरील PerformanceObserver द्वारे निरीक्षण केलेल्या INP इव्हेंटच्या startTime ला त्याच वेळी घडलेल्या कोणत्याही लांब टास्कच्या टाइमिंगशी जोडू शकता. हे तुम्हाला नक्की सांगते की कोणत्या JavaScript फंक्शनने वापरकर्त्याच्या इंटरॅक्शनला ब्लॉक केले.
3. विशिष्ट हँडलरचे मापन करा: आणखी ग्रॅन्युलर होण्यासाठी यूजर टाइमिंग API वापरा. तुमच्या क्रिटिकल इव्हेंट हँडलरला (जसे की "ॲड टू कार्ट" साठी 'क्लिक' हँडलर) performance.mark() आणि performance.measure() ने रॅप करा. हे तुम्हाला अचूकपणे सांगेल की तुमचा स्वतःचा कोड एक्झिक्युट होण्यासाठी किती वेळ घेत आहे आणि ते लांब टास्कचे कारण आहे की नाही.

उच्च CLS ला सामोरे जाणे

वापरकर्ते रिपोर्ट करतात की त्यांच्या मोबाइल डिव्हाइसवर लेख वाचत असताना टेक्स्ट इकडे-तिकडे उडी मारतो. तुमचा CLS स्कोअर 0.3 आहे.

1. लेआउट शिफ्टचे निरीक्षण करा: 'layout-shift' एंट्रीज ऐकण्यासाठी PerformanceObserver वापरा. प्रत्येक एंट्रीमध्ये value (CLS स्कोअरमधील त्याचे योगदान) आणि sources ची लिस्ट असेल, जे DOM एलिमेंट आहेत जे फिरले. हे तुम्हाला सांगते की *काय* फिरले.
2. गुन्हेगार रिसोर्स शोधा: पुढचा प्रश्न आहे की ते *का* फिरले. याचे एक सामान्य कारण म्हणजे रिसोर्स उशिरा लोड झाल्यामुळे इतर कंटेंट खाली ढकलला जातो. तुम्ही रिसोर्स टाइमिंग API मधील एंट्रीजच्या responseEnd वेळेसह layout-shift एंट्रीच्या startTime सहसंबंध जोडू शकता. जर ॲड स्क्रिप्ट किंवा मोठी इमेज लोड झाल्यानंतर लगेच लेआउट शिफ्ट झाल्यास, तुम्हाला तुमचा गुन्हेगार सापडला आहे.
3. ॲक्टिव्ह सोल्यूशन्स: बहुतेक वेळा इमेजेस आणि ॲड्ससाठी डायमेन्शन प्रदान करणे (<img width="1000" height="600">) किंवा डायनॅमिक कंटेंट लोड होण्यापूर्वी पेजवर जागा रिझर्व्ह करणे समाविष्ट आहे. रिसोर्स टाइमिंग तुम्हाला ओळखण्यास मदत करते की कोणत्या रिसोर्सबद्दल तुम्हाला ॲक्टिव्ह असणे आवश्यक आहे.

प्रॅक्टिकल इम्प्लिमेंटेशन: ग्लोबल मॉनिटरिंग सिस्टम तयार करणे

या API ला समजून घेणे एक गोष्ट आहे; तुमच्या जागतिक यूजर बेसच्या अनुभवाचे निरीक्षण करण्यासाठी त्यांना डिप्लॉय करणे हे पुढील पाऊल आहे. हे रिअल यूजर मॉनिटरिंगचे (RUM) डोमेन आहे.

PerformanceObserver सह सर्व काही एकत्र ठेवणे

तुम्ही हा सर्व महत्त्वाचा डेटा गोळा करण्यासाठी एकच, शक्तिशाली स्क्रिप्ट तयार करू शकता. ध्येय हे मेट्रिक्स आणि त्यांचा संदर्भ मोजण्याचा प्रयत्न करत असलेल्या कार्यक्षमतेवर परिणाम न करता गोळा करणे आहे.

येथे मजबूत ऑब्झर्व्हर सेटअपचा एक संकल्पनात्मक स्निपेट आहे:

const collectedMetrics = {}; const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'largest-contentful-paint') { collectedMetrics.lcp = entry.startTime; } else if (entry.entryType === 'layout-shift') { collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value; } else if (entry.entryType === 'event') { // हे INP गणनेचे सरलीकृत दृश्य आहे const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... आणि 'longtask' सारख्या इतर एंट्री प्रकारांसाठी } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

डेटा विश्वसनीयपणे पाठवणे

एकदा तुम्ही तुमचा डेटा गोळा केला की, तुम्हाला तो स्टोरेज आणि ॲनालिसिससाठी ॲनालिटिक्स बॅकएंडला पाठवणे आवश्यक आहे. पेज अनलोड होण्यास विलंब न करता किंवा त्यांचे टॅब लवकर बंद करणाऱ्या वापरकर्त्यांकडून डेटा न गमावता हे करणे महत्त्वाचे आहे.

navigator.sendBeacon() API यासाठी योग्य आहे. हे सर्व्हरला थोड्या प्रमाणात डेटा पाठवण्याचा एक विश्वसनीय, असynchronized मार्ग पुरवते, जरी पेज अनलोड होत असेल तरीही. हे प्रतिसादाची अपेक्षा करत नाही, ज्यामुळे ते लाईटवेट आणि नॉन-ब्लॉकिंग बनते.

window.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { const payload = JSON.stringify(collectedMetrics); navigator.sendBeacon('/api/performance-analytics', payload); } });

ग्लोबल दृश्याचे महत्त्व

लाइटहाऊससारखी लॅब टेस्टिंग टूल्स अमूल्य आहेत, परंतु ते नियंत्रित वातावरणात चालतात. या API मधून गोळा केलेला RUM डेटा तुम्हाला वेगवेगळ्या देश, नेटवर्क कंडिशन आणि डिव्हाइसमध्ये तुमच्या वापरकर्त्यांना काय अनुभव येतो याचे सत्य सांगतो.

तुमच्या डेटाचे विश्लेषण करताना, नेहमी त्याचे विभाजन करा. तुम्हाला असे आढळून येऊ शकते की:

• उत्तर अमेरिकेतील वापरकर्त्यांसाठी तुमचा LCP उत्कृष्ट आहे, परंतु ऑस्ट्रेलियातील वापरकर्त्यांसाठी खराब आहे कारण तुमचा प्राथमिक इमेज सर्व्हर यूएस मध्ये आधारित आहे.
• तुमचा INP मध्यम-श्रेणीच्या अँड्रॉइड डिव्हाइसवर जास्त आहे, जे उदयोन्मुख बाजारपेठेत लोकप्रिय आहेत, कारण तुमचे JavaScript त्यांच्यासाठी खूप CPU-इंटेंसिव्ह आहे.
• तुमचा CLS केवळ विशिष्ट स्क्रीन साइजवर एक समस्या आहे जिथे CSS मीडिया क्वेरीमुळे ॲड अयोग्यरित्या रीसाइज होते.

विभाजित केलेल्या माहितीचा हा स्तर तुम्हाला ऑप्टिमायझेशनला प्राधान्य देण्यास अनुमती देतो, ज्यामुळे तुमच्या वास्तविक यूजर बेसवर सर्वात महत्त्वपूर्ण परिणाम होईल, मग ते कोठेही असले तरी.

निष्कर्ष: मापनापासून प्रभुत्वापर्यंत

वेब परफॉर्मन्सची दुनिया विकसित झाली आहे. आम्ही साध्या तांत्रिक टाइमिंगपासून वापरकर्त्याच्या परसिप्ड अनुभवाच्या अत्याधुनिक समजाकडे वाटचाल केली आहे. या प्रवासात तीन प्रमुख टप्पे आहेत:

1. अनुभवाचे मापन करा: कोअर वेब व्हायटल्स (LCP, INP, CLS) गोळा करण्यासाठी PerformanceObserver वापरा. हे तुम्हाला सांगते की *काय* घडत आहे आणि वापरकर्त्याला *कसे वाटते*.
2. कारणाचे निदान करा: मूलभूत टाइमिंग API (नेव्हिगेशन, रिसोर्स, यूजर, लांब टास्क) वापरून अधिक खोलवर जा. हे तुम्हाला सांगते की अनुभव *खराब का* आहे.
3. अचूकतेने कृती करा: विशिष्ट यूजर सेगमेंटसाठी समस्येच्या मूळ कारणाचे निराकरण करणारे माहितीपूर्ण, लक्ष्यित ऑप्टिमायझेशन करण्यासाठी एकत्रित डेटा वापरा.

उच्च-स्तरीय यूजर मेट्रिक्स आणि लो-लेव्हल डायग्नोस्टिक API या दोन्हींमध्ये प्रभुत्व मिळवून, तुम्ही एक समग्र परफॉर्मन्स स्ट्रॅटेजी तयार करू शकता. तुम्ही अंदाज लावणे थांबवता आणि एक वेब अनुभव इंजिनीअर करणे सुरू करता जो केवळ तांत्रिकदृष्ट्या जलद नाही, तर प्रत्येक वापरकर्त्याला, प्रत्येक डिव्हाइसवर, जगातील प्रत्येक ठिकाणी जलद, प्रतिसाद देणारा आणि आनंददायी वाटतो.