Google I/O से जुड़े रहने के लिए धन्यवाद! मांग पर वीडियो देखें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

Philip Walton

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

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

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

सवालों से शुरू करना

किसी भी वेबसाइट या ऐप्लिकेशन में 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;
    }
  }
}

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

इसके साथ, अब हम एक और फ़ंक्शन लिख सकते हैं जो एक नॉन-इंटरैक्शन इवेंट भेजता है, जिसमें फ़र्स्ट पेंट करने के समय की वैल्यू इस तरह से दी जाती है: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 के मामले में, इसका यह भी मतलब है कि सभी एसेट कैश मेमोरी में सेव कर लिए गए हैं और पेज ऑफ़लाइन काम कर रहा है.
समर्थित: ब्राउज़र सर्विस वर्कर का समर्थन करता है, लेकिन सर्विस वर्कर अभी तक पेज को नियंत्रित नहीं कर रहा है. पहली बार आने वाले लोगों के लिए यह स्थिति है.
काम नहीं करता: उपयोगकर्ता का ब्राउज़र सर्विस वर्कर के साथ काम नहीं करता है.

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

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

ऐसे तीन इवेंट थे जिनमें firstpaint की वैल्यू 4 मि॰से॰ थी
दो इवेंट में firstpaint की वैल्यू 5 मि॰से॰ थी
ऐसे 10 इवेंट थे जिनमें firstpaint की वैल्यू 6 मि॰से॰ थी
ऐसे आठ इवेंट थे जिनमें 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. IndexedDB में Analytics क्लाइंट आईडी को स्टोर करना

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

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

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

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

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

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

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

खत्म हो रहा है

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

यहां IOWA अध्ययन के मुख्य बिंदु दिए गए हैं:

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

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

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

फ़ुटनोट

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