सर्विस वर्कर की परफ़ॉर्मेंस पर पड़ने वाले असल असर को मापना

Philip Walton

सर्विस वर्कर (परफ़ॉर्मेंस के नज़रिए से देखें) का सबसे बड़ा फ़ायदा यह है कि वे ऐसेट को कैश मेमोरी में सेव करने की सुविधा को अपने-आप कंट्रोल कर पाते हैं. एक ऐसा वेब ऐप्लिकेशन जो अपने सभी ज़रूरी संसाधनों को कैश मेमोरी में सेव कर सकता है, वह लौटने वाले लोगों के लिए तेज़ी से लोड होना चाहिए. लेकिन, असली उपयोगकर्ताओं को ये फ़ायदे असल में कैसे मिलते हैं? और यहां तक कि आप इसका आकलन कैसे करते हैं?

Google I/O वेब ऐप्लिकेशन (IOWA) एक प्रोग्रेसिव वेब ऐप्लिकेशन है, जिसमें सर्विस वर्कर की ओर से दी जाने वाली ज़्यादातर नई सुविधाओं का इस्तेमाल, उपयोगकर्ताओं को ऐप्लिकेशन जैसा बेहतरीन अनुभव देने के लिए किया गया है. इसने Google Analytics का इस्तेमाल करके, अपनी बड़ी और अलग-अलग तरह की उपयोगकर्ताओं से मिलने वाले परफ़ॉर्मेंस के डेटा और इस्तेमाल के पैटर्न को भी इकट्ठा किया.

यह केस स्टडी बताती है कि कैसे IOWA ने परफ़ॉर्मेंस से जुड़े अहम सवालों के जवाब देने के लिए, Google Analytics का इस्तेमाल करके सेवा देने वालों के असल ज़िंदगी पर पड़ने वाले असर की रिपोर्ट दी.

सवालों से शुरुआत करें

किसी वेबसाइट या ऐप्लिकेशन में आंकड़े लागू करते समय, सबसे पहले यह पता करना ज़रूरी है कि जिस डेटा को इकट्ठा किया जा रहा है उससे जुड़े सवालों के जवाब देने की कोशिश करें.

इस केस स्टडी के लिए, हम आपके कई सवालों के जवाब देना चाहते थे. चलिए, अब हम दो ज़्यादा दिलचस्प सवालों पर बात करते हैं.

1. क्या सभी ब्राउज़र में उपलब्ध एचटीटीपी कैश मेमोरी में डेटा सेव करने के मौजूदा तरीकों की तुलना में, सर्विस वर्कर कैश मेमोरी में ज़्यादा बेहतर तरीके से काम कर रहा है?

हमें उम्मीद है कि नए विज़िटर के मुकाबले, आपकी साइट पर लौटने वाले लोगों के लिए पेज ज़्यादा तेज़ी से लोड होंगे, क्योंकि ब्राउज़र अनुरोधों को कैश मेमोरी में डाल देते हैं और बार-बार होने वाली विज़िट पर उन्हें तुरंत पूरा कर सकते हैं.

सर्विस वर्कर, कैश मेमोरी की वैकल्पिक सुविधाएं ऑफ़र करते हैं. इनसे डेवलपर को यह कंट्रोल मिलता है कि कैश मेमोरी में कौनसा डेटा सेव किया जा सकता है और कैसे किया जा सकता है. IOWA में, हमने अपने सर्विस वर्कर को लागू करने के तरीके को ऑप्टिमाइज़ किया, ताकि हर ऐसेट को कैश मेमोरी में सेव किया जा सके. इससे, वेबसाइट पर वापस आने वाले लोग ऐप्लिकेशन को पूरी तरह ऑफ़लाइन इस्तेमाल कर सकते हैं.

लेकिन क्या यह प्रयास ब्राउज़र में पहले से डिफ़ॉल्ट रूप से किए जाने वाले से बेहतर होगा? अगर हां, तो कितना बेहतर है? 1

2. सर्विस वर्कर, साइट लोड होने के अनुभव पर कैसे असर डालते हैं?

दूसरे शब्दों में, साइट लोड होने के समय यह कितनी तेज़ी से लगता है, भले ही पारंपरिक पेज लोड मेट्रिक के हिसाब से लोड होने में लगने वाले असल समय कुछ भी हों?

किसी अनुभव को कैसा महसूस होता है, इस बारे में सवालों के जवाब देना बेशक आसान काम नहीं है. ऐसी कोई भी मेट्रिक ऐसी भावनात्मक भावना को पूरी तरह नहीं दिखा सकती है. हालांकि, कुछ मेट्रिक ऐसी होती हैं जो दूसरों के मुकाबले बेहतर होती हैं. इसलिए, सही मेट्रिक चुनना बहुत ज़रूरी है.

सही मेट्रिक चुनना

Google Analytics, डिफ़ॉल्ट रूप से, किसी साइट के 1% विज़िटर के लिए, पेज लोड होने में लगने वाले समय (नेविगेशन टाइमिंग एपीआई के ज़रिए) को ट्रैक करता है. साथ ही, उस डेटा को औसत पेज लोड समय जैसी मेट्रिक के ज़रिए उपलब्ध कराता है.

औसत पेज लोड समय हमारे पहले सवाल का जवाब देने के लिए एक अच्छी मेट्रिक है, लेकिन यह दूसरे सवाल का जवाब देने के लिए खास तौर पर अच्छी मेट्रिक नहीं है. यह ज़रूरी नहीं है कि load इवेंट, उस समय से जुड़ा हो जब उपयोगकर्ता असल में ऐप्लिकेशन के साथ इंटरैक्ट कर सकता है. इसके अलावा, एक ही लोड अवधि वाले दो ऐप्लिकेशन के लोड होने में लगने वाला समय अलग-अलग हो सकता है. उदाहरण के लिए, स्प्लैश स्क्रीन या लोड होने वाले इंडिकेटर वाली साइट को, उस साइट की तुलना में ज़्यादा तेज़ी से लोड होने वाला लग सकता है जिसमें कई सेकंड तक खाली पेज दिखाया जाता है.

IOWA में, हमने स्प्लैश स्क्रीन का काउंटडाउन ऐनिमेशन दिखाया. मेरी राय में, यह ऐनिमेशन में उपयोगकर्ता के मनोरंजन के लिए बहुत काम किया गया, जबकि बाकी के ऐप्लिकेशन बैकग्राउंड में लोड हो रहे थे. इस वजह से, स्प्लैश स्क्रीन को दिखने में लगने वाला समय ट्रैक करने से, लोड होने की अनुमानित परफ़ॉर्मेंस का आकलन किया जा सकता है. यह वैल्यू पाने के लिए, हमने मेट्रिक को पहली बार पेंट करने का समय चुना है.

हमने जिन सवालों के जवाब देने थे और उन्हें जवाब देने के लिए मददगार मेट्रिक की पहचान कर ली, उसके बाद हमने Google Analytics को लागू करके आकलन शुरू कर दिया.

आंकड़ों को लागू करने का तरीका

अगर आपने पहले Google Analytics का इस्तेमाल किया है, तो शायद आप सुझाई गई JavaScript ट्रैकिंग स्निपेट के बारे में जानते होंगे. ऐसा लग सकता है:

<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src="https://www.google-analytics.com/analytics.js"></script>

ऊपर दिए गए कोड की पहली लाइन, ग्लोबल ga() फ़ंक्शन (अगर यह पहले से मौजूद न हो) शुरू करती है और आखिरी लाइन analytics.js लाइब्रेरी को एसिंक्रोनस तरीके से डाउनलोड करती है.

बीच वाले हिस्से में ये दो लाइनें हैं:

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');

ये दो निर्देश यह ट्रैक करते हैं कि आपकी साइट पर आने वाले लोग किन पेजों पर जाते हैं. हालांकि, इससे ज़्यादा नहीं. अगर आपको उपयोगकर्ता के अन्य इंटरैक्शन को ट्रैक करना है, तो आपको यह काम खुद करना होगा.

IOWA के लिए, हम दो अतिरिक्त चीज़ों को ट्रैक करना चाहते हैं:

  • पेज के पहली बार लोड होना शुरू होने और स्क्रीन पर पिक्सल दिखने के बीच लगने वाला समय.
  • कोई सर्विस वर्कर, पेज को कंट्रोल कर रहा है या नहीं. इस जानकारी की मदद से, हम अपनी रिपोर्ट को अलग-अलग सेगमेंट में बांट सकते हैं, ताकि सर्विस वर्कर के साथ और उसके बिना मिलने वाले नतीजों की तुलना की जा सके.

पहली बार पेंट करने का समय तय हो रहा है

कुछ ब्राउज़र वह सटीक समय रिकॉर्ड करते हैं जब स्क्रीन पर पहले पिक्सल को पेंट किया जाता है और वे उस समय को डेवलपर को उपलब्ध कराते हैं. इस वैल्यू की तुलना, नेविगेशन टाइमिंग एपीआई से मिली navigationStart वैल्यू से की जाती है. इससे हमें इस बात का सटीक हिसाब मिलता है कि उपयोगकर्ता के पेज के लिए अनुरोध करने और पहली बार कुछ देखने के बीच कितना समय लगा.

जैसा कि मैंने पहले बताया है, 'पहली बार पेंट करने का समय' इसे मापने के लिए एक अहम मेट्रिक है. ऐसा इसलिए, क्योंकि इसी पॉइंट पर उपयोगकर्ता को आपकी साइट लोड होने की स्पीड का अनुभव होता है. यह उपयोगकर्ताओं को मिलने वाला पहला इंप्रेशन होता है और एक अच्छा पहला इंप्रेशन उपयोगकर्ता अनुभव के बाकी अनुभव पर अच्छा असर डाल सकता है.2

अगर ब्राउज़र में यह वैल्यू दिखनी चाहिए, तो सबसे पहले पेंट की गई वैल्यू पाने के लिए, हमने getTimeToFirstPaintIfSupported यूटिलिटी फ़ंक्शन बनाया है:

function getTimeToFirstPaintIfSupported() {
  // Ignores browsers that don't support the Performance Timing API.
  if (window.performance && window.performance.timing) {
    var navTiming = window.performance.timing;
    var navStart = navTiming.navigationStart;
    var fpTime;

    // If chrome, get first paint time from `chrome.loadTimes`.
    if (window.chrome && window.chrome.loadTimes) {
      fpTime = window.chrome.loadTimes().firstPaintTime * 1000;
    }
    // If IE/Edge, use the prefixed `msFirstPaint` property.
    // See http://msdn.microsoft.com/ff974719
    else if (navTiming.msFirstPaint) {
      fpTime = navTiming.msFirstPaint;
    }

    if (fpTime && navStart) {
      return fpTime - navStart;
    }
  }
}

इससे, अब हम एक और फ़ंक्शन लिख सकते हैं जो नॉन-इंटरैक्शन इवेंट भेज सकता है. यह इवेंट, इसकी वैल्यू के तौर पर पहली बार पेंट करने का समय होगा:3

function sendTimeToFirstPaint() {
  var timeToFirstPaint = getTimeToFirstPaintIfSupported();

  if (timeToFirstPaint) {
    ga('send', 'event', {
      eventCategory: 'Performance',
      eventAction: 'firstpaint',
      // Rounds to the nearest millisecond since
      // event values in Google Analytics must be integers.
      eventValue: Math.round(timeToFirstPaint)
      // Sends this as a non-interaction event,
      // so it doesn't affect bounce rate.
      nonInteraction: true
    });
  }
}

ये दोनों फ़ंक्शन लिखने के बाद, हमारा ट्रैकिंग कोड ऐसा दिखता है:

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Sends a pageview for the initial pageload.
ga('send', 'pageview');

// Sends an event with the time to first paint data.
sendTimeToFirstPaint();

ध्यान दें कि ऊपर दिए गए कोड के चलने के समय के आधार पर, हो सकता है कि स्क्रीन पर पिक्सल को पहले से ही पेंट किया गया हो या नहीं. यह पक्का करने के लिए कि पहला रंग ट्रिगर होने के बाद हम कोड को हमेशा चलाएं, हमने load इवेंट खत्म होने तक इस कॉल को sendTimeToFirstPaint() पर आगे बढ़ा दिया है. दरअसल, हमने आंकड़ों से जुड़ा सारा डेटा, पेज के लोड होने तक टाल दिया था. ऐसा इसलिए किया गया, ताकि यह पक्का किया जा सके कि ये अनुरोध अन्य रिसॉर्स को लोड होने से रोकने में हमारी मदद करेंगे.

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
  // Sends a pageview for the initial pageload.
  ga('send', 'pageview');

  // Sends an event with the time to first paint data.
  sendTimeToFirstPaint();
});

ऊपर दिया गया कोड Google Analytics को firstpaint बार रिपोर्ट करता है, लेकिन यह पूरी जानकारी नहीं है. हमें अब भी सर्विस वर्कर की स्थिति को ट्रैक करना पड़ता था. ऐसा न करने पर, हम सर्विस वर्कर से कंट्रोल किए जाने वाले पेज और बिना कंट्रोल वाले पेज के पहले पेंट समय की तुलना नहीं कर पाएंगे.

सर्विस वर्कर की स्थिति का पता लगाना

सर्विस वर्कर की मौजूदा स्थिति तय करने के लिए, हमने एक यूटिलिटी फ़ंक्शन बनाया है जो तीनों में से कोई एक वैल्यू दिखाता है:

  • कंट्रोल किया गया: सर्विस वर्कर, पेज को कंट्रोल कर रहा है. IOWA के मामले में, इसका यह भी मतलब है कि सभी एसेट को कैश मेमोरी में सेव किया गया है और पेज ऑफ़लाइन काम करता है.
  • समर्थित: ब्राउज़र सर्विस वर्कर का समर्थन करता है, लेकिन सर्विस वर्कर अभी तक पेज को नियंत्रित नहीं कर रहा है. पहली बार वेबसाइट पर आने वाले लोगों के लिए यह स्थिति उम्मीद के मुताबिक है.
  • unsupported: उपयोगकर्ता का ब्राउज़र सर्विस वर्कर का समर्थन नहीं करता है.
function getServiceWorkerStatus() {
  if ('serviceWorker' in navigator) {
    return navigator.serviceWorker.controller ? 'controlled' : 'supported';
  } else {
    return 'unsupported';
  }
}

इस फ़ंक्शन को हमारे लिए सर्विस वर्कर की स्थिति मिली; अगला चरण इस स्थिति को उस डेटा से जोड़ना था जिसे हम Google Analytics को भेज रहे थे.

कस्टम डाइमेंशन के साथ कस्टम डेटा ट्रैक करना

Google Analytics, डिफ़ॉल्ट तौर पर आपके कुल ट्रैफ़िक को उपयोगकर्ता, सेशन या इंटरैक्शन के एट्रिब्यूट के आधार पर कई ग्रुप में बांटने के कई तरीके उपलब्ध कराता है. इन एट्रिब्यूट को डाइमेंशन कहा जाता है. वेब डेवलपर जिन सामान्य डाइमेंशन के बारे में जानना चाहते हैं उनमें ब्राउज़र, ऑपरेटिंग सिस्टम या डिवाइस कैटगरी जैसी चीज़ें शामिल हैं.

सर्विस वर्कर की स्थिति Google Analytics द्वारा डिफ़ॉल्ट रूप से दिया गया कोई डाइमेंशन नहीं है. हालांकि, Google Analytics आपको अपने कस्टम डाइमेंशन बनाने और उन्हें अपने हिसाब से तय करने की सुविधा देता है.

IOWA के लिए, हमने सर्विस वर्कर की स्थिति नाम का एक कस्टम डाइमेंशन बनाया है और उसका स्कोप हिट (जैसे कि हर इंटरैक्शन) पर सेट किया है.4 Google Analytics में बनाए जाने वाले हर कस्टम डाइमेंशन को उस प्रॉपर्टी में एक यूनीक इंडेक्स दिया जाता है. साथ ही, आपके ट्रैकिंग कोड में, उस डाइमेंशन को इंडेक्स के ज़रिए इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर हमने अभी-अभी बनाए गए डाइमेंशन का इंडेक्स 1 था, तो सर्विस वर्कर की स्थिति शामिल करने के लिए, firstpaint इवेंट भेजने के लिए हम अपने लॉजिक को इस तरह अपडेट कर सकते हैं:

ga('send', 'event', {
  eventCategory: 'Performance',
  eventAction: 'firstpaint',
  // Rounds to the nearest millisecond since
  // event values in Google Analytics must be integers.
  eventValue: Math.round(timeToFirstPaint)
  // Sends this as a non-interaction event,
  // so it doesn't affect bounce rate.
  nonInteraction: true,

  // Sets the current service worker status as the value of
  // `dimension1` for this event.
  dimension1: getServiceWorkerStatus()
});

यह काम करता है, लेकिन इससे सिर्फ़ सर्विस वर्कर की स्थिति इस खास इवेंट से जुड़ी होगी. सर्विस वर्कर स्टेटस ऐसी चीज़ है जो किसी भी इंटरैक्शन के लिए काम की साबित हो सकती है. इसलिए, Google Analytics को भेजे गए सभी डेटा के साथ इसे शामिल करना सबसे अच्छा होता है.

इस जानकारी को सभी हिट (जैसे कि सभी पेज व्यू, इवेंट वगैरह) में शामिल करने के लिए, हम Google Analytics को कोई भी डेटा भेजने से पहले, ट्रैकर ऑब्जेक्ट पर ही कस्टम डाइमेंशन वैल्यू सेट करते हैं.

ga('set', 'dimension1', getServiceWorkerStatus());

सेट होने पर, यह वैल्यू मौजूदा पेजलोड के लिए बाद के सभी हिट के साथ भेजी जाती है. अगर उपयोगकर्ता इस पेज को बाद में लोड करता है, तो getServiceWorkerStatus() फ़ंक्शन से एक नई वैल्यू मिलने की संभावना है और वह वैल्यू ट्रैकर ऑब्जेक्ट पर सेट हो जाएगी.

कोड को समझने और उसे पढ़ने में आसान जानकारी: ऐसा हो सकता है कि इस कोड को देखने वाले दूसरे लोगों को यह पता न हो कि dimension1 का मतलब क्या है. इसलिए, सबसे बेहतर तरीका यह है कि आप एक ऐसा वैरिएबल बनाएं जो काम के डाइमेंशन के नामों को analytics.js की मदद से मैप करे.

// Creates a map between custom dimension names and their index.
// This is particularly useful if you define lots of custom dimensions.
var customDimensions = {
  SERVICE_WORKER_STATUS: 'dimension1'
};

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Sets the service worker status on the tracker,
// so its value is included in all future hits.
ga('set', customDimensions.SERVICE_WORKER_STATUS, getServiceWorkerStatus());

// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
  // Sends a pageview for the initial pageload.
  ga('send', 'pageview');

  // Sends an event with the time to first paint data.
  sendTimeToFirstPaint();
});

जैसा कि मैंने बताया था, हर हिट के साथ सर्विस वर्कर स्टेटस डाइमेंशन भेजने से, हमें किसी भी मेट्रिक पर रिपोर्ट करते समय उसका इस्तेमाल करने में मदद मिलती है.

जैसा कि आपको दिख सकता है कि IOWA के सभी पेज व्यू में से करीब 85% पेज व्यू, सर्विस वर्कर के साथ काम करने वाले ब्राउज़र से मिले थे.

नतीजे: हमारे सवालों के जवाब देना

अपने सवालों के जवाब देने के लिए डेटा इकट्ठा करना शुरू करने के बाद, हम नतीजे देखने के लिए उस डेटा को रिपोर्ट कर सकते हैं. (ध्यान दें: Google Analytics का यहां दिखाया गया सारा डेटा, 16 से 22 मई, 2016 के बीच IOWA साइट पर आने वाले असल वेब ट्रैफ़िक की जानकारी देता है).

हमारा पहला सवाल यह था कि: क्या सभी ब्राउज़र में उपलब्ध एचटीटीपी कैश मेमोरी में सेव करने के मौजूदा तरीकों की तुलना में, सर्विस वर्कर कैश मेमोरी में ज़्यादा बेहतर तरीके से काम करता है?

इस सवाल का जवाब देने के लिए, हमने एक कस्टम रिपोर्ट बनाई है. इस रिपोर्ट में, अलग-अलग डाइमेंशन के लिए पेज लोड होने में लगने वाले औसत समय की मेट्रिक देखी गई है. यह मेट्रिक इस सवाल का जवाब देने में मददगार है, क्योंकि load इवेंट सिर्फ़ तब ट्रिगर होता है, जब सभी शुरुआती संसाधन डाउनलोड हो जाते हैं. इस तरह से यह सीधे तौर पर साइट के सभी ज़रूरी संसाधनों के लोड होने में लगने वाले कुल समय को दिखाता है.5

हमने ये डाइमेंशन चुने:

  • हमारा कस्टम सर्विस वर्कर स्टेटस डाइमेंशन.
  • उपयोगकर्ता टाइप, जिससे पता चलता है कि यह उपयोगकर्ता के पहली बार साइट पर आने वाला है या नहीं. (ध्यान दें: किसी नए विज़िटर के पास कोई भी संसाधन कैश मेमोरी में सेव नहीं होगा; लौटने वाले विज़िटर को ऐसा हो सकता है.)
  • डिवाइस कैटगरी, जिसकी मदद से हम मोबाइल और डेस्कटॉप पर मिले नतीजों की तुलना कर सकते हैं.

इसकी संभावना को नियंत्रित करने के लिए कि गैर-सेवा कर्मचारी से संबंधित कारक हमारे लोड समय के परिणामों को बाधित कर रहे थे, हमने अपनी क्वेरी को केवल सर्विस वर्कर का समर्थन करने वाले ब्राउज़र को शामिल करने तक सीमित कर दिया.

जैसा कि आपको दिख रहा है कि किसी सर्विस वर्कर से कंट्रोल होने पर हमारे ऐप्लिकेशन पर होने वाली विज़िट, बिना किसी कंट्रोल वाली विज़िट की तुलना में बहुत तेज़ी से लोड हुई. यहां तक कि लौटने वाले उपयोगकर्ताओं की विज़िट, जिनके पेज के ज़्यादातर संसाधन कैश मेमोरी में सेव किए गए थे, काफ़ी तेज़ी से लोड हुए. यह भी दिलचस्प बात है कि सर्विस वर्कर वाले मोबाइल पर, वेबसाइट पर आने वाले नए लोगों की तुलना में, वेबसाइट पर आने वाले लोगों ने औसतन ज़्यादा रफ़्तार लोड की.

"...हमारे ऐप्लिकेशन पर तब करता है, जब किसी सर्विस वर्कर से कंट्रोल किया जाता है. यह बिना कंट्रोल वाली विज़िट की तुलना में बहुत तेज़ी से लोड होता है..."

ज़्यादा जानकारी के लिए, इन दो टेबल में जाएं:

औसत पेज लोड समय (डेस्कटॉप)
सर्विस वर्कर की स्थिति उपयोगकर्ता टाइप औसत पेज लोड समय (मि.से.) सैंपल का साइज़
नियंत्रित किया वेबसाइट पर पहले भी आ चुका व्यक्ति 2568 30860
इनकी अनुमति है वेबसाइट पर पहले भी आ चुका व्यक्ति 3612 1289
इनकी अनुमति है वेबसाइट पर आने वाला नया व्यक्ति 4664 21991
औसत पेज लोड समय (मोबाइल)
सर्विस वर्कर की स्थिति उपयोगकर्ता टाइप औसत पेज लोड समय (मि.से.) सैंपल का साइज़
नियंत्रित किया वेबसाइट पर पहले भी आ चुका व्यक्ति 3760 8162
इनकी अनुमति है वेबसाइट पर पहले भी आ चुका व्यक्ति 4843 676
इनकी अनुमति है वेबसाइट पर आने वाला नया व्यक्ति 6158 5779

आप सोच रहे होंगे कि जिस विज़िटर का ब्राउज़र सर्विस वर्कर की सहायता करता है, वह हमेशा अनियंत्रित स्थिति में रह सकता है. इसके कुछ संभावित वजहें हो सकती हैं:

  • सर्विस वर्कर को शुरू करने का मौका मिलने से पहले ही उपयोगकर्ता ने शुरुआती विज़िट पर पेज छोड़ दिया.
  • उपयोगकर्ता ने डेवलपर टूल का इस्तेमाल करके सर्विस वर्कर को अनइंस्टॉल कर दिया है.

ये दोनों स्थितियां बहुत कम होती हैं. हम चौथे कॉलम में मौजूद पेज लोड सैंपल की वैल्यू देखकर, इसे डेटा में देख सकते हैं. ध्यान दें कि बीच की पंक्तियों में, अन्य दो पंक्तियों की तुलना में बहुत छोटा सैंपल है.

हमारा दूसरा सवाल यह था: सर्विस वर्कर, साइट लोड होने के अनुभव पर कैसे असर डालता है?

इस सवाल का जवाब देने के लिए, हमने औसत इवेंट वैल्यू मेट्रिक के लिए एक और कस्टम रिपोर्ट बनाई. साथ ही, नतीजों को फ़िल्टर करके, सिर्फ़ अपने firstpaint इवेंट शामिल किए. हमने डिवाइस कैटगरी डाइमेंशन और कस्टम सर्विस वर्कर स्टेटस डाइमेंशन का इस्तेमाल किया.

मैंने अपनी उम्मीद के उलट, मोबाइल पर सर्विस वर्कर पर पहली बार पेंट करने के समय का असर, पूरे पेज लोड की तुलना में बहुत कम दिया था.

"...कुल पेज लोड की तुलना में, मोबाइल पर सर्विस वर्कर ने पहली बार पेंट करने में कम समय लगा दिया."

ऐसा क्यों किया गया है, यह जानने के लिए हमें डेटा को गहराई से समझना होगा. औसत, सामान्य खास जानकारी और ब्रॉड स्ट्रोक के लिए अच्छे हो सकते हैं, लेकिन असल में यह समझने के लिए कि अलग-अलग उपयोगकर्ताओं के लिए ये संख्याएं कैसे अलग-अलग होती हैं, हमें firstpaint बार का डिस्ट्रिब्यूशन देखना होगा.

Google Analytics में मेट्रिक का डिस्ट्रिब्यूशन पाना

firstpaint के डिस्ट्रिब्यूशन के लिए, हमें हर इवेंट के अलग-अलग नतीजों के ऐक्सेस की ज़रूरत होती है. माफ़ करें, Google Analytics इस प्रक्रिया को आसान नहीं बना सकता.

Google Analytics की मदद से, रिपोर्ट को अपनी पसंद के किसी भी डाइमेंशन के हिसाब से बांटा जा सकता है. हालांकि, यह मेट्रिक के हिसाब से रिपोर्ट को अलग-अलग नहीं करने देता. इसे नामुमकिन नहीं कहा जा सकता, बल्कि इसका मतलब है कि हमें मनचाहा नतीजा पाने के लिए, लागू करने की प्रोसेस को थोड़ा और कस्टमाइज़ करना पड़ा.

रिपोर्ट के नतीजों को सिर्फ़ डाइमेंशन के हिसाब से बांटा जा सकता है. इसलिए, हमें इवेंट पर मेट्रिक वैल्यू को कस्टम डाइमेंशन के तौर पर सेट करना पड़ता था. इस मामले में, firstpaint बार. ऐसा करने के लिए, हमने मेट्रिक वैल्यू नाम का एक और कस्टम डाइमेंशन बनाया है. साथ ही, firstpaint ट्रैकिंग लॉजिक को इस तरह अपडेट किया है:

var customDimensions = {
  SERVICE_WORKER_STATUS: 'dimension1',
  <strong>METRIC_VALUE: 'dimension2'</strong>
};

// ...

function sendTimeToFirstPaint() {
  var timeToFirstPaint = getTimeToFirstPaintIfSupported();

  if (timeToFirstPaint) {
    var fields = {
      eventCategory: 'Performance',
      eventAction: 'firstpaint',
      // Rounds to the nearest millisecond since
      // event values in Google Analytics must be integers.
      eventValue: Math.round(timeToFirstPaint)
      // Sends this as a non-interaction event,
      // so it doesn't affect bounce rate.
      nonInteraction: true
    }

    <strong>// Sets the event value as a dimension to allow for breaking down the
    // results by individual metric values at reporting time.
    fields[customDimensions.METRIC_VALUE] = String(fields.eventValue);</strong>

    ga('send', 'event', fields);
  }
}

फ़िलहाल, Google Analytics के वेब इंटरफ़ेस में आर्बिट्ररी मेट्रिक वैल्यू के डिस्ट्रिब्यूशन को विज़ुअलाइज़ नहीं किया जा सकता. हालांकि, Google Analytics Core Reporting API और Google Charts लाइब्रेरी की मदद से, हम रॉ नतीजों के लिए क्वेरी कर सकते हैं और फिर खुद हिस्टोग्राम बना सकते हैं.

उदाहरण के लिए, नीचे दिए गए एपीआई अनुरोध के कॉन्फ़िगरेशन का इस्तेमाल, बिना कंट्रोल किए गए सर्विस वर्कर के साथ डेस्कटॉप पर firstpaint वैल्यू का डिस्ट्रिब्यूशन पाने के लिए किया गया था.

{
  dateRanges: [{startDate: '2016-05-16', endDate: '2016-05-22'}],
  metrics: [{expression: 'ga:totalEvents'}],
  dimensions: [{name: 'ga:dimension2'}],
  dimensionFilterClauses: [
    {
      operator: 'AND',
      filters: [
        {
          dimensionName: 'ga:eventAction',
          operator: 'EXACT',
          expressions: ['firstpaint']
        },
        {
          dimensionName: 'ga:dimension1',
          operator: 'EXACT',
          expressions: ['supported']
        },
        {
          dimensionName: 'ga:deviceCategory',
          operator: 'EXACT',
          expressions: ['desktop']
        }
      ],
    }
  ],
  orderBys: [
    {
      fieldName: 'ga:dimension2',
      orderType: 'DIMENSION_AS_INTEGER'
    }
  ]
}

यह एपीआई अनुरोध, इस तरह दिखने वाली वैल्यू का कलेक्शन दिखाता है (ध्यान दें: ये सिर्फ़ पहले पांच नतीजे हैं). नतीजों को सबसे छोटे से सबसे बड़े के क्रम में लगाया जाता है, ताकि इन पंक्तियों में सबसे तेज़ समय का पता चले.

एपीआई से मिले रिस्पॉन्स के नतीजे (पहली पांच लाइनें)
ga:डाइमेंशन2 ga:totalEvents
4 3
5 2
6 10
7 8
8 10

यहां सरल अंग्रेज़ी में इन परिणामों का मतलब बताया गया है:

  • ऐसे 3 इवेंट थे जिनमें firstpaint की वैल्यू 4 मि॰से॰ थी
  • दो इवेंट थे जिनमें firstpaint की वैल्यू 5 मि॰से॰ थी
  • 10 इवेंट ऐसे थे जिनमें firstpaint की वैल्यू 6 मि॰से॰ थी
  • 8 इवेंट ऐसे थे जिनमें firstpaint की वैल्यू 7 मि॰से॰ थी
  • ऐसे 10 इवेंट थे जिनमें firstpaint value 8 मि॰से॰ था
  • वगैरह

इन नतीजों से, हम हर एक इवेंट के लिए firstpaint वैल्यू का अनुमान लगा सकते हैं और डिस्ट्रिब्यूशन का हिस्टोग्राम बना सकते हैं. हमने यह अपनी हर क्वेरी के लिए किया.

यहां बताया गया है कि गैर-कंट्रोल किए गए (लेकिन काम करने वाले) सर्विस वर्कर के साथ, डेस्कटॉप पर डिस्ट्रिब्यूशन कैसा दिखता है:

डेस्कटॉप पर पहली बार पेंट डिस्ट्रिब्यूशन का समय (यह सुविधा काम करती है)

ऊपर दिए गए डिस्ट्रिब्यूशन के लिए, firstpaint का मीडियन समय 912 मि॰से॰ है.

इस कर्व का आकार, लोड होने में लगने वाले समय के वितरण जैसा है. इसके उलट, नीचे दिए गए हिस्टोग्राम में उन विज़िट के पहले पेंट इवेंट का डिस्ट्रिब्यूशन दिखाया गया है जिनमें सर्विस वर्कर पेज को कंट्रोल कर रहा था.

डेस्कटॉप पर पहली बार पेंट डिस्ट्रिब्यूशन का समय (कंट्रोल किया गया)

ध्यान दें कि जब कोई सर्विस वर्कर पेज को कंट्रोल कर रहा होता था, तब कई लोगों को कुछ ही समय में फ़र्स्ट पेंट, 583 मि॰से॰ के मीडियन के साथ दिखता था.

"...जब कोई सर्विस वर्कर पेज को कंट्रोल कर रहा होता था, तब कई लोगों को करीब-करीब पहली बार पेंट किया जाता था..."

इस बारे में बेहतर जानकारी पाने के लिए कि इन दोनों डिस्ट्रिब्यूशन की तुलना एक-दूसरे से कैसे की जाती है, अगले चार्ट में दोनों का मर्ज किया गया व्यू दिखाया गया है. कंट्रोल नहीं किए गए सर्विस वर्कर की विज़िट को दिखाने वाला हिस्टोग्राम, हिस्टोग्राम के ऊपर ओवरले किया गया है. साथ ही, कंट्रोल किए गए विज़िट को दिखाने के लिए, दोनों को हिस्टोग्राम के ऊपर दिखाया गया है.

डेस्कटॉप पर पहली बार पेंट डिस्ट्रिब्यूशन का समय

इन नतीजों के बारे में मुझे एक बात दिलचस्प लगी. यह थी कि शुरुआती बढ़ोतरी के बाद भी, कंट्रोल किए गए सर्विस वर्कर के साथ डिस्ट्रिब्यूशन में घंटी के आकार का कर्व मौजूद था. मुझे उम्मीद थी कि शुरुआत में शुरुआत में यह बढ़ोतरी होगी और फिर धीरे-धीरे मंज़िल धीरे-धीरे बढ़ जाएगी. मुझे यह उम्मीद नहीं थी कि यह वापसी होगी.

जब मैंने इसकी वजह देखी, तो मुझे पता चला कि सर्विस वर्कर किसी पेज को कंट्रोल कर सकता है, लेकिन उसका थ्रेड बंद हो सकता है. ब्राउज़र ऐसा संसाधनों को सेव करने के लिए करता है - साफ़ तौर पर आपको यह ज़रूरी नहीं कि हर उस साइट के लिए हर सर्विस वर्कर की ज़रूरत न पड़े जो पहले से ऐक्टिव हो और उसी समय सूचना देने के लिए तैयार हो. यह डिस्ट्रिब्यूशन के आखिरी हिस्से के बारे में बताता है. कुछ उपयोगकर्ताओं के लिए, सर्विस वर्कर थ्रेड शुरू होने में देरी हुई.

जैसा कि डिस्ट्रिब्यूशन से पता चलता है कि इस शुरुआती देरी के बावजूद भी, सर्विस वर्कर वाले ब्राउज़र, नेटवर्क में जाने वाले ब्राउज़र की तुलना में कॉन्टेंट को तेज़ी से डिलीवर करते हैं.

यहां बताया गया है कि चीज़ें मोबाइल पर कैसी दिखती हैं:

मोबाइल पर पहली बार पेंट डिस्ट्रिब्यूशन का समय

हालांकि, पेंटिंग बनाने का समय करीब-करीब थोड़ा बढ़ गया था, लेकिन पूंछ बहुत बड़ी और बड़ी थी. इसकी वजह यह हो सकती है कि मोबाइल पर, काम न करने वाले सर्विस वर्कर थ्रेड को शुरू करने में डेस्कटॉप की तुलना में ज़्यादा समय लगता है. इसमें यह भी बताया गया है कि firstpaint के औसत समय के बीच का अंतर, मेरी उम्मीद के मुताबिक क्यों नहीं था (ऊपर चर्चा की गई है).

"...मोबाइल पर, किसी काम न करने वाले सर्विस वर्कर थ्रेड को शुरू करने में डेस्कटॉप की तुलना में ज़्यादा समय लगता है."

यहां मोबाइल और डेस्कटॉप पर पेंट करने के समय के मीडियन के इन वैरिएशन से जुड़ी जानकारी दी गई है, जिन्हें सर्विस वर्कर की स्थिति के हिसाब से ग्रुप में बांटा गया है:

पहली बार पेंट करने में लगने वाला मीडियन समय (मिलीसेकंड)
सर्विस वर्कर की स्थिति डेस्कटॉप मोबाइल
नियंत्रित किया 583 1634
इस्तेमाल किए जा सकते हैं (कंट्रोल नहीं किया गया है) 912 1933

Google Analytics में कस्टम रिपोर्ट बनाने की तुलना में, इन डिस्ट्रिब्यूशन विज़ुअलाइज़ेशन को बनाने में थोड़ा ज़्यादा समय और मेहनत लगती है. इससे हमें इस बारे में बेहतर जानकारी मिलती है कि सेवा कर्मचारी, औसत के बजाय हमारी साइट की परफ़ॉर्मेंस पर किस तरह असर डालते हैं.

सर्विस वर्कर का असर

परफ़ॉर्मेंस के साथ-साथ, सर्विस वर्कर भी उपयोगकर्ता अनुभव पर कई ऐसे तरीकों से असर डालते हैं जिन्हें Google Analytics की मदद से मेज़र किया जा सकता है.

बिना इंटरनेट के इस्तेमाल

सर्विस वर्कर, ऑफ़लाइन होने पर उपयोगकर्ताओं को आपकी साइट से इंटरैक्ट करने की सुविधा देते हैं, जबकि किसी भी प्रोग्रेसिव वेब ऐप्लिकेशन के लिए, किसी तरह का ऑफ़लाइन सपोर्ट अहम हो सकता है. इससे, यह तय किया जा सकता है कि आपके मामले में यह कितना ज़रूरी है, यह काफ़ी हद तक इस बात पर निर्भर करता है कि कितना ऑफ़लाइन इस्तेमाल हो रहा है. लेकिन हम इसका आकलन कैसे करते हैं?

Google Analytics को डेटा भेजने के लिए इंटरनेट कनेक्शन की ज़रूरत होती है. हालांकि, इंटरैक्शन के समय पर डेटा भेजने की ज़रूरत नहीं होती. Google Analytics, qt पैरामीटर के ज़रिए टाइम ऑफ़सेट तय करके, तथ्य के बाद इंटरैक्शन डेटा भेजने की सुविधा देता है.

पिछले दो सालों से IOWA एक सर्विस वर्कर स्क्रिप्ट का इस्तेमाल कर रहा है, जो उपयोगकर्ता के ऑफ़लाइन होने पर, Google Analytics को मिले असफल हिट का पता लगाता है और बाद में qt पैरामीटर की मदद से उसे फिर से चलाता है.

यह ट्रैक करने के लिए कि उपयोगकर्ता ऑनलाइन था या ऑफ़लाइन, हमने ऑनलाइन नाम का एक कस्टम डाइमेंशन बनाया और उसकी वैल्यू navigator.onLine पर सेट की. इसके बाद, हमने online और offline इवेंट सुने और डाइमेंशन को उसी हिसाब से अपडेट किया.

यह जानने के लिए कि IOWA का इस्तेमाल करते समय किसी उपयोगकर्ता का ऑफ़लाइन होना कितना सामान्य है, हमने एक ऐसा सेगमेंट बनाया जिसमें कम से कम एक ऑफ़लाइन इंटरैक्शन वाले उपयोगकर्ताओं को टारगेट किया गया था. यानी कि करीब 5% उपयोगकर्ता थे.

पुश नोटिफ़िकेशन

सर्विस वर्कर, उपयोगकर्ताओं को पुश नोटिफ़िकेशन पाने के लिए ऑप्ट-इन करने की अनुमति देते हैं. IOWA में, उपयोगकर्ताओं को तब सूचना दी गई, जब उनके शेड्यूल में एक सेशन शुरू होने वाला था.

किसी भी अन्य सूचना की तरह, यह बेहद अहम है कि लोगों को उपलब्ध कराई जाने वाली सूचनाओं और उन्हें परेशान करने के बीच संतुलन बना रहे. यह समझने के लिए कि क्या हो रहा है, यह ट्रैक करना अहम है कि उपयोगकर्ता ये सूचनाएं पाने के लिए ऑप्ट-इन कर रहे हैं या नहीं, आने के समय वे उनसे जुड़ रहे हैं या नहीं, और क्या पहले ऑप्ट-इन कर चुके उपयोगकर्ता अपनी प्राथमिकता बदल रहे हैं और ऑप्ट-आउट कर रहे हैं.

IOWA में, हमने सिर्फ़ उपयोगकर्ता के मनमुताबिक बनाए गए शेड्यूल से जुड़ी सूचनाएं भेजी हैं. यह ऐसी चीज़ है जो सिर्फ़ लॉग इन किए हुए उपयोगकर्ता ही बना सकते हैं. इससे उन उपयोगकर्ताओं का ग्रुप सीमित हो गया जिन्हें लॉग-इन किए हुए उपयोगकर्ताओं (साइन इन नाम के कस्टम डाइमेंशन के ज़रिए ट्रैक किया जाता है) को सूचनाएं मिल सकती थीं, जिनके ब्राउज़र में पुश नोटिफ़िकेशन काम करते थे (जिन्हें सूचना की अनुमति नाम के दूसरे कस्टम डाइमेंशन के ज़रिए ट्रैक किया जाता है).

नीचे दी गई रिपोर्ट, उपयोगकर्ता मेट्रिक और सूचना की अनुमति वाले कस्टम डाइमेंशन पर आधारित है. इसे उन उपयोगकर्ताओं के हिसाब से सेगमेंट किया जाता है जिन्होंने कभी साइन इन किया और जिनके ब्राउज़र में पुश नोटिफ़िकेशन काम करते हों.

यह देखकर अच्छा लगता है कि साइन इन किए हुए आधे से ज़्यादा उपयोगकर्ताओं ने पुश नोटिफ़िकेशन पाने का विकल्प चुना है.

ऐप्लिकेशन इंस्टॉल करने के लिए बैनर

अगर कोई प्रोग्रेस वेब ऐप्लिकेशन ज़रूरी शर्तों को पूरा करता है और उसका इस्तेमाल बार-बार किया जाता है, तो उस उपयोगकर्ता को ऐप्लिकेशन इंस्टॉल करने का बैनर दिख सकता है. इस बैनर में, उससे ऐप्लिकेशन को होम स्क्रीन पर जोड़ने के लिए कहा जा सकता है.

IOWA में, हमने यह ट्रैक किया कि ये प्रॉम्प्ट उपयोगकर्ता को कितनी बार दिखाए गए (और वे स्वीकार किए गए या नहीं) इन कोड के साथ:

window.addEventListener('beforeinstallprompt', function(event) {
  // Tracks that the user saw a prompt.
  ga('send', 'event', {
    eventCategory: 'installprompt',
    eventAction: 'fired'
  });

  event.userChoice.then(function(choiceResult) {
    // Tracks the users choice.
    ga('send', 'event', {
      eventCategory: 'installprompt',
      // `choiceResult.outcome` will be 'accepted' or 'dismissed'.
      eventAction: choiceResult.outcome,
      // `choiceResult.platform` will be 'web' or 'android' if the prompt was
      // accepted, or '' if the prompt was dismissed.
      eventLabel: choiceResult.platform
    });
  });
});

ऐप्लिकेशन इंस्टॉल करने का बैनर देखने वाले उपयोगकर्ताओं में से, करीब 10% ने उसे अपनी होम स्क्रीन पर जोड़ने का विकल्प चुना.

संभावित ट्रैकिंग सुधार (अगली बार के लिए)

इस साल IOWA से आंकड़ों का जो डेटा इकट्ठा किया गया वह अहम था. हालांकि, छिपी हुई सोच की वजह से कमियां आती हैं और चीज़ों को अगली बार बेहतर बनाने के अवसर मिलते हैं. इस साल का विश्लेषण पूरा करने के बाद, हम इन दो चीज़ों के बारे में सोच रहे हैं. शायद हम इसे अलग तरीके से करें:

1. कॉन्टेंट लोड होने के अनुभव से जुड़े ज़्यादा इवेंट ट्रैक करना

हमने किसी तकनीकी मेट्रिक से जुड़े कई इवेंट ट्रैक किए (उदाहरण के लिए, HTMLImportsLoaded, WebComponentsReady वगैरह.) लेकिन ज़्यादातर लोड एसिंक्रोनस तरीके से किए गए थे. इसलिए, यह ज़रूरी नहीं है कि ये इवेंट जिस पॉइंट पर ट्रिगर हुए वह पूरे लोड अनुभव के किसी खास पल से मेल खाए.

लोड होने से जुड़े जिस मुख्य इवेंट को हमने ट्रैक नहीं किया (लेकिन हो सकता था अगर वह होता, तो) वह पॉइंट होता है जहां से स्प्लैश स्क्रीन गायब हो जाती है. साथ ही, उपयोगकर्ता को पेज का कॉन्टेंट भी दिखता है.

2. Analytics क्लाइंट आईडी को IndexedDB में स्टोर करना

डिफ़ॉल्ट रूप से, analytics.js ब्राउज़र की कुकी में क्लाइंट आईडी फ़ील्ड सेव करता है. माफ़ करें, सर्विस वर्कर स्क्रिप्ट, कुकी को ऐक्सेस नहीं कर सकतीं.

इसने हमारे लिए सूचना ट्रैकिंग को लागू करने का प्रयास करते समय एक समस्या पेश की. किसी उपयोगकर्ता को हर बार सूचना भेजने पर, हम मेज़रमेंट प्रोटोकॉल के ज़रिए सर्विस वर्कर से एक इवेंट भेजना चाहते थे. इसके बाद, हम उस सूचना पर क्लिक करने और ऐप्लिकेशन में वापस आने पर, उस सूचना की री-एंगेजमेंट सफलता को ट्रैक करना चाहते थे.

हम utm_source कैंपेन पैरामीटर के ज़रिए आम तौर पर सूचनाओं की सफलता को ट्रैक कर सकते थे, लेकिन हम किसी खास री-एंगेजमेंट सेशन को किसी खास उपयोगकर्ता से टैग नहीं कर सके.

इस सीमा से निपटने के लिए हम अपने ट्रैकिंग कोड में IndexedDB के ज़रिए Client-ID स्टोर कर सकते थे. इससे उस वैल्यू को सर्विस वर्कर स्क्रिप्ट तक ऐक्सेस किया जा सकता था.

3. सर्विस वर्कर को ऑनलाइन/ऑफ़लाइन स्थिति की रिपोर्ट करने दें

navigator.onLine की जांच करने से आपको पता चल जाएगा कि आपका ब्राउज़र, राऊटर या लोकल एरिया नेटवर्क से कनेक्ट हो पा रहा है या नहीं. हालांकि, यह ज़रूरी नहीं है कि आपको यह पता चल जाए कि उपयोगकर्ता के पास असल कनेक्टिविटी है या नहीं. क्योंकि हमारी ऑफ़लाइन ऐनलिटिक्स सर्विस वर्कर स्क्रिप्ट ने पूरे न हो पाने वाले हिट को फिर से चलाया (उनमें कोई बदलाव किए बिना या उन्हें 'फ़ेल हो गया' के तौर पर मार्क किए बिना), इसलिए शायद हम ऑफ़लाइन इस्तेमाल के बारे में कम रिपोर्ट कर रहे थे.

आने वाले समय में, हमें navigator.onLine की स्थिति को ट्रैक करना होगा. साथ ही, यह भी ट्रैक करना होगा कि क्या शुरुआती नेटवर्क की गड़बड़ी की वजह से सर्विस वर्कर ने हिट को फिर से चलाया है या नहीं. इससे हमें ऑफ़लाइन इस्तेमाल के बारे में ज़्यादा सटीक जानकारी मिलेगी.

रैप कर रहा है

इस केस स्टडी से पता चला है कि सर्विस वर्कर का इस्तेमाल करने से, कई ब्राउज़र, नेटवर्क, और डिवाइसों पर Google I/O वेब ऐप्लिकेशन के लोड होने की परफ़ॉर्मेंस बेहतर हुई है. इससे यह भी पता चलता है कि जब कई तरह के ब्राउज़र, नेटवर्क, और डिवाइसों पर लोड किए गए डेटा के डिस्ट्रिब्यूशन को देखा जाता है, तो आपको इस बारे में ज़्यादा अहम जानकारी मिलती है कि यह टेक्नोलॉजी असल में कैसे काम करती है. साथ ही, आपको परफ़ॉर्मेंस से जुड़ी ऐसी विशेषताओं का पता चलता है जिनकी आपने उम्मीद भी नहीं की होगी.

IOWA पर की गई स्टडी से जुड़ी कुछ अहम बातें यहां दी गई हैं:

  • औसतन, जब कोई सर्विस वर्कर किसी नए और लौटने वाले विज़िटर के लिए पेज को कंट्रोल कर रहा होता है, तब पेज ज़्यादा तेज़ी से लोड होते हैं.
  • किसी सर्विस वर्कर के ज़रिए कंट्रोल होने वाले पेजों की विज़िट, कई उपयोगकर्ताओं के लिए करीब-करीब तुरंत लोड हो जाती हैं.
  • सर्विस वर्कर के निष्क्रिय होने पर, उन्हें शुरू होने में थोड़ा समय लगा. हालांकि, एक इनऐक्टिव सर्विस वर्कर ने अब भी किसी सर्विस वर्कर से बेहतर परफ़ॉर्म नहीं किया है.
  • किसी निष्क्रिय सर्विस वर्कर के लिए डेस्कटॉप की तुलना में मोबाइल पर स्टार्टअप समय ज़्यादा था.

हालांकि, किसी एक ऐप्लिकेशन में परफ़ॉर्मेंस में मिले फ़ायदे, आम तौर पर बड़े डेवलपर कम्यूनिटी को रिपोर्ट करने के लिए काम के होते हैं. हालांकि, इस बात पर ध्यान देना ज़रूरी है कि ये नतीजे, IOWA (एक इवेंट साइट) साइट के टाइप और IOWA की ऑडियंस (ज़्यादातर डेवलपर) के हिसाब से हैं.

अगर आपको अपने ऐप्लिकेशन में सर्विस वर्कर लागू करना है, तो यह ज़रूरी है कि आप मेज़रमेंट की अपनी रणनीति लागू करें, ताकि आप खुद की परफ़ॉर्मेंस का आकलन कर सकें और आने वाले समय में रिग्रेशन को रोक सकें. अगर आपने ऐसा किया है, तो अपने नतीजों को शेयर करें, ताकि सभी को फ़ायदा हो!

फ़ुटनोट

  1. हमारे सर्विस वर्कर कैशे लागू करने की परफ़ॉर्मेंस की तुलना हमारी साइट की परफ़ॉर्मेंस से सिर्फ़ एचटीटीपी कैश से करना सही नहीं है. हम IOWA को सर्विस वर्कर के लिए ऑप्टिमाइज़ कर रहे थे. इसलिए, हमने एचटीटीपी कैश को ऑप्टिमाइज़ करने में ज़्यादा समय नहीं लगाया. अगर हमने ऐसा किया होता, तो नतीजे अलग होते. अपनी साइट को एचटीटीपी कैश के लिए ऑप्टिमाइज़ करने के बारे में ज़्यादा जानने के लिए, कॉन्टेंट को बेहतर तरीके से ऑप्टिमाइज़ करना लेख पढ़ें.
  2. आपकी साइट अपनी स्टाइल और कॉन्टेंट कैसे लोड करती है, इसके आधार पर हो सकता है कि कॉन्टेंट या स्टाइल के उपलब्ध होने से पहले ब्राउज़र पेंट कर पाए. ऐसे मामलों में, firstpaint किसी खाली सफ़ेद स्क्रीन से जुड़ा हो सकता है. अगर firstpaint का इस्तेमाल किया जाता है, तो यह पक्का करना ज़रूरी है कि आपकी साइट के रिसॉर्स को लोड करते समय इसका कोई अहम पॉइंट दिखे.
  3. तकनीकी रूप से, हम किसी इवेंट के बजाय इस जानकारी को कैप्चर करने के लिए एक समय हिट (जो डिफ़ॉल्ट रूप से नॉन-इंटरैक्शन होते हैं) भेज सकते हैं. दरअसल, टाइमिंग हिट Google Analytics में खास तौर पर इस तरह की लोड मेट्रिक को ट्रैक करने के लिए जोड़े गए थे; हालांकि, प्रोसेसिंग के समय टाइमिंग हिट का बहुत ज़्यादा सैंपल लिया जाता है और उनकी वैल्यू का इस्तेमाल सेगमेंट में नहीं किया जा सकता. इन मौजूदा सीमाओं को देखते हुए, नॉन-इंटरैक्शन इवेंट बेहतर तरीके से काम करते हैं.
  4. Google Analytics में कस्टम डाइमेंशन देने का तरीका समझने के लिए, Analytics सहायता केंद्र के कस्टम डाइमेंशन सेक्शन पर जाएं. Google Analytics के डेटा मॉडल को समझना भी ज़रूरी है. इस डेटा मॉडल में उपयोगकर्ता, सेशन, और इंटरैक्शन (हिट) शामिल होते हैं. ज़्यादा जानने के लिए, Google Analytics डेटा मॉडल पर Analytics अकैडमी का लेसन देखें.
  5. यह, लोड इवेंट के बाद लेज़ी लोड होने वाले रिसॉर्स के लिए शामिल नहीं है.