การวัดผลลัพธ์ด้านประสิทธิภาพในชีวิตจริงของผู้ปฏิบัติงานบริการ

Philip Walton

ประโยชน์ที่สำคัญที่สุดอย่างหนึ่งของโปรแกรมทำงานของบริการ (อย่างน้อยก็ในมุมมองด้านประสิทธิภาพ) คือความสามารถในการควบคุมการแคชชิ้นงานในเชิงรุก เว็บแอปพลิเคชันที่สามารถแคชทรัพยากรที่จำเป็นทั้งหมดควรโหลดได้เร็วขึ้นมากสำหรับผู้เข้าชมที่กลับมา แต่จริงๆ แล้วกำไรเหล่านี้มีลักษณะอย่างไรต่อผู้ใช้จริง แล้วคุณจะวัดผลอย่างไร

เว็บแอป Google I/O (เรียกสั้นๆ ว่า IOWA) เป็นเว็บแอปแบบโปรเกรสซีฟที่ใช้ประโยชน์จากความสามารถใหม่ส่วนใหญ่ที่ Service Worker มีให้เพื่อมอบประสบการณ์ที่สมจริงเหมือนแอปให้แก่ผู้ใช้ นอกจากนี้ยังใช้ Google Analytics เพื่อรวบรวมข้อมูลประสิทธิภาพที่สำคัญและรูปแบบการใช้งานจากกลุ่มเป้าหมายของผู้ใช้กลุ่มใหญ่ที่หลากหลาย

กรณีศึกษานี้สำรวจวิธีที่ IOWA ใช้ Google Analytics เพื่อตอบคำถามสำคัญเกี่ยวกับประสิทธิภาพและรายงานผลกระทบที่เกิดขึ้นจริงของผู้ปฏิบัติงานบริการ

เริ่มต้นที่คำถาม

เมื่อใดก็ตามที่คุณใช้ Analytics ในเว็บไซต์หรือแอปพลิเคชัน คุณควรเริ่มต้นด้วยการระบุคำถามที่คุณพยายามจะตอบจากข้อมูลที่คุณจะเก็บรวบรวม

ในขณะที่เรามีคำถามหลายข้อที่อยากจะตอบ แต่เพื่อวัตถุประสงค์ของกรณีศึกษานี้ เราจะขอโฟกัสที่คำถาม 2 ข้อที่น่าสนใจกว่า

1. การแคชของโปรแกรมทำงานของบริการมีประสิทธิภาพมากกว่ากลไกการแคช HTTP ที่มีอยู่ในเบราว์เซอร์ทั้งหมดหรือไม่

เราคาดว่าหน้าเว็บสำหรับผู้เข้าชมที่กลับมาจะโหลดเร็วกว่าผู้เข้าชมใหม่ๆ อยู่แล้ว เนื่องจากเบราว์เซอร์สามารถแคชคำขอและแสดงได้ทันทีเมื่อมีการเข้าชมซ้ำ

Service Worker เสนอความสามารถในการแคชทางเลือกซึ่งช่วยให้นักพัฒนาซอฟต์แวร์ควบคุมงานและวิธีการแคชได้อย่างละเอียด เราเพิ่มประสิทธิภาพในการติดตั้งใช้งาน Service Worker ใน IOWA ให้มีการแคชชิ้นงานทั้งหมด เพื่อให้ผู้เข้าชมที่กลับมาใช้แอปได้แบบออฟไลน์โดยสมบูรณ์

แต่ความพยายามนี้จะดีกว่าสิ่งที่เบราว์เซอร์ทำโดยค่าเริ่มต้นหรือไม่ และหากได้ จะยิ่งดีเท่าไหร่ 1

2. Service Worker ส่งผลต่อประสบการณ์การโหลดเว็บไซต์อย่างไร

กล่าวคือ เว็บไซต์รู้สึกโหลดเร็วเพียงใด โดยไม่คำนึงถึงเวลาในการโหลดจริงที่วัดโดยเมตริกการโหลดหน้าเว็บแบบดั้งเดิม

การตอบคำถามเกี่ยวกับความรู้สึกของประสบการณ์นั้นไม่ใช่เรื่องง่าย และไม่มีเมตริกใดที่สะท้อนความรู้สึกของตนเองได้อย่างสมบูรณ์แบบ อย่างไรก็ตาม แน่นอนว่ามีเมตริกบางรายการที่ดีกว่ารายการอื่นๆ ดังนั้นการเลือกเมตริกที่เหมาะสมจึงเป็นสิ่งสำคัญ

การเลือกเมตริกที่เหมาะสม

โดยค่าเริ่มต้น Google Analytics จะติดตามเวลาในการโหลดหน้าเว็บ (ผ่าน Navigation Timing API) ของผู้เข้าชมเว็บไซต์ 1% และทำให้ข้อมูลดังกล่าวพร้อมใช้งานผ่านเมตริก เช่น เวลาในการโหลดหน้าเว็บเฉลี่ย

เวลาเฉลี่ยในการโหลดหน้าเว็บเป็นเมตริกที่ดีสำหรับการตอบคำถามแรก แต่ก็ไม่ใช่เมตริกที่ดีในการตอบคำถาม 2 ด้วยเหตุผลหนึ่งที่เหตุการณ์ load ไม่จำเป็นต้องสอดคล้องกับช่วงเวลาที่ผู้ใช้โต้ตอบกับแอปได้จริงๆ ยิ่งไปกว่านั้น แอป 2 แอปที่มีเวลาที่ใช้ในการโหลดเท่ากันอาจรู้สึกเหมือนการโหลดที่ไม่เหมือนกันอย่างมาก ตัวอย่างเช่น เว็บไซต์ที่มีหน้าจอแนะนำหรือสัญญาณบอกสถานะการโหลดอาจรู้สึกว่าโหลดได้เร็วกว่าเว็บไซต์ที่แสดงหน้าว่างเป็นเวลาหลายวินาที

ใน IOWA เราแสดงภาพเคลื่อนไหวนับถอยหลังสู่หน้าจอเริ่มต้น (ในความคิดของผม) ซึ่งประสบความสำเร็จอย่างมากเพื่อมอบความบันเทิงแก่ผู้ใช้ในขณะที่ส่วนที่เหลือของแอปโหลดอยู่เบื้องหลัง ดังนั้น การติดตามระยะเวลาที่ใช้ก่อนที่หน้าจอแนะนำจะปรากฏจึงเหมาะสมมากสำหรับการวัดประสิทธิภาพการโหลดที่รับรู้ได้ เราเลือกเมตริก time to first Paint จึงได้ค่านี้

เมื่อเราตัดสินใจเลือกคำถามที่ต้องการตอบและระบุเมตริกที่จะเป็นประโยชน์ในการตอบคำถามแล้ว ก็ถึงเวลานำ 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 แบบไม่พร้อมกัน

ส่วนที่อยู่ตรงกลางประกอบด้วย 2 บรรทัดนี้

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

คำสั่งทั้งสองนี้จะติดตามว่าผู้ที่เข้าชมเว็บไซต์ของคุณเข้าชมหน้าใดบ้าง แต่ไม่ได้มากกว่านี้ หากต้องการติดตามการโต้ตอบเพิ่มเติมของผู้ใช้ คุณต้องดำเนินการด้วยตนเอง

สำหรับ IOWA เราต้องการติดตามข้อมูลเพิ่มเติม 2 ประการ:

• เวลาที่ผ่านไประหว่างเวลาที่หน้าเว็บเริ่มโหลดครั้งแรกกับเวลาที่พิกเซลปรากฏบนหน้าจอ
• มี Service Worker ควบคุมหน้าเว็บอยู่หรือไม่ ข้อมูลนี้ช่วยให้เราแบ่งกลุ่มรายงานเพื่อเปรียบเทียบผลลัพธ์ที่มีและไม่มี Service Worker ได้

กำลังบันทึกเวลาที่จะลงสีครั้งแรก

บางเบราว์เซอร์จะบันทึกเวลาที่แน่นอนในการลงสีพิกเซลแรกลงบนหน้าจอ และจะแสดงเวลาดังกล่าวให้นักพัฒนาซอฟต์แวร์ใช้งาน ค่าดังกล่าวเมื่อเทียบกับค่า navigationStart ที่แสดงผ่าน Navigation Timing API ช่วยให้เราทราบว่าระยะเวลาผ่านไประหว่างที่ผู้ใช้ขอหน้าเว็บครั้งแรกกับเวลาที่ผู้ใช้เห็นหน้าเว็บเป็นครั้งแรกเมื่อใด

อย่างที่ได้กล่าวไปแล้วว่า Time to First Paint เป็นเมตริกที่สำคัญในการวัด เนื่องจากนี่เป็นจุดแรกที่ผู้ใช้พบความเร็วในการโหลดของเว็บไซต์ เพราะเป็นความประทับใจแรกที่ผู้ใช้ได้รับ และความประทับใจแรกที่ดีก็ส่งผลดีต่อประสบการณ์การใช้งานส่วนที่เหลือของผู้ใช้ได้2

เราสร้างฟังก์ชันยูทิลิตี getTimeToFirstPaintIfSupported เพื่อรับค่า Paint แรกในเบราว์เซอร์ที่แสดงค่าดังกล่าว

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 ที่อ้างอิงในฟังก์ชันข้างต้นเป็นส่วนหนึ่งของ API เฉพาะผู้ให้บริการ โฆษณาเหล่านี้ที่ไม่เป็นไปตามมาตรฐานและอาจมีการเปลี่ยนแปลง (หรือการนำออก) ได้ทุกเมื่อ เราเลือกใช้โซลูชันเหล่านี้ใน 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();

โปรดทราบว่าพิกเซลข้างต้นอาจทำงานหรือยังไม่มีการแสดงผลบนหน้าจอ ทั้งนี้ขึ้นอยู่กับเวลาที่โค้ดข้างต้นทำงาน เราได้เลื่อนการเรียกใช้โค้ดไปยัง sendTimeToFirstPaint() ไปจนกระทั่งหลังกิจกรรม load เสร็จสิ้นลง เพื่อให้มั่นใจว่าเราจะเรียกใช้โค้ดนี้หลังเกิดการแสดงผลครั้งแรกเสมอ อันที่จริง เราตัดสินใจเลื่อนการส่งข้อมูลการวิเคราะห์ทั้งหมดออกไปจนกระทั่งมีการโหลดหน้าเว็บ เพื่อไม่ให้คำขอเหล่านั้นแข่งขันกับการโหลดทรัพยากรอื่นๆ

// 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 ครั้ง แต่นี่เป็นเพียงครึ่งทางเท่านั้น เรายังจำเป็นต้องติดตามสถานะของ Service Worker มิฉะนั้นเราจะไม่สามารถเปรียบเทียบเวลาการแสดงผลครั้งแรกของหน้าที่ควบคุมโดย Service Worker กับหน้าที่ไม่มีการควบคุมได้

การระบุสถานะของ Service Worker

ในการพิจารณาสถานะปัจจุบันของ Service Worker เราได้สร้างฟังก์ชันยูทิลิตีที่ส่งคืนค่าใดค่าหนึ่งจาก 3 ค่าดังนี้

• ควบคุม: มีโปรแกรมทำงานของบริการควบคุมหน้าเว็บ ในกรณีของ IOWA นั่นหมายถึงมีการแคชเนื้อหาทั้งหมดไว้และหน้าเว็บทำงานแบบออฟไลน์ได้
• รองรับ: เบราว์เซอร์รองรับ Service Worker แต่ Service Worker ยังไม่ได้ควบคุมหน้าเว็บ นี่คือสถานะที่คาดหวังสำหรับผู้เข้าชมครั้งแรก
• ไม่รองรับ: เบราว์เซอร์ของผู้ใช้ไม่รองรับ Service Worker

function getServiceWorkerStatus() {
  if ('serviceWorker' in navigator) {
    return navigator.serviceWorker.controller ? 'controlled' : 'supported';
  } else {
    return 'unsupported';
  }
}

ฟังก์ชันนี้รับสถานะของ Service Worker ให้กับเรา ขั้นตอนถัดไปคือการเชื่อมโยงสถานะนี้กับข้อมูลที่เราส่งไปยัง Google Analytics

การติดตามข้อมูลที่กําหนดเองด้วยมิติข้อมูลที่กําหนดเอง

โดยค่าเริ่มต้น Google Analytics มีวิธีมากมายในการแบ่งย่อยการเข้าชมทั้งหมดออกเป็นกลุ่มๆ ตามแอตทริบิวต์ของผู้ใช้ เซสชัน หรือการโต้ตอบ แอตทริบิวต์เหล่านี้เรียกว่ามิติข้อมูล มิติข้อมูลที่นักพัฒนาเว็บมักให้ความสนใจ ได้แก่ เบราว์เซอร์ ระบบปฏิบัติการ หรือหมวดหมู่อุปกรณ์

สถานะของโปรแกรมทำงานของบริการไม่ใช่มิติข้อมูลที่ Google Analytics กำหนดให้โดยค่าเริ่มต้น อย่างไรก็ตาม Google Analytics ให้คุณสามารถสร้างมิติข้อมูลที่กำหนดเองของคุณเอง และกำหนดมิติข้อมูลได้ตามต้องการ

สำหรับ IOWA เราได้สร้างมิติข้อมูลที่กำหนดเองชื่อ Service Worker Status และกำหนดขอบเขตเป็น Hit (กล่าวคือ ต่อการโต้ตอบ)4 มิติข้อมูลที่กำหนดเองแต่ละรายการที่คุณสร้างใน Google Analytics จะได้รับดัชนีที่ไม่ซ้ำกันภายในพร็อพเพอร์ตี้ดังกล่าว และในโค้ดติดตาม คุณจะอ้างอิงมิติข้อมูลนั้นได้โดยใช้ดัชนี เช่น หากดัชนีของมิติข้อมูลที่เพิ่งสร้างคือ 1 เราอาจอัปเดตตรรกะดังนี้เพื่อส่งเหตุการณ์ firstpaint เพื่อรวมสถานะของ Service Worker ไว้ด้วยได้

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()
});

วิธีนี้ได้ผล แต่จะเชื่อมโยงสถานะของ Service Worker กับเหตุการณ์นี้เท่านั้น เนื่องจากสถานะ Service Worker เป็นสิ่งที่น่าจะมีประโยชน์เมื่อทราบการโต้ตอบทุกครั้ง จึงควรระบุสถานะดังกล่าวไว้กับข้อมูลทั้งหมดที่ส่งไปยัง Google Analytics

เพื่อรวมข้อมูลนี้ใน Hit ทั้งหมด (เช่น การดูหน้าเว็บ เหตุการณ์ทั้งหมด ฯลฯ) เราได้ตั้งค่ามิติข้อมูลที่กำหนดเองในออบเจ็กต์เครื่องมือติดตามเองก่อนส่งข้อมูลไปยัง Google Analytics

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

เมื่อตั้งค่าแล้ว ระบบจะส่งค่านี้พร้อมกับ Hit ที่ตามมาทั้งหมดสำหรับการโหลดหน้าเว็บปัจจุบัน หากผู้ใช้โหลดหน้าเว็บอีกครั้งในภายหลัง ค่าใหม่ก็มีแนวโน้มที่จะส่งคืนจากฟังก์ชัน 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();
});

อย่างที่ได้กล่าวไปแล้ว การส่งมิติข้อมูลสถานะ Service Worker พร้อมกับ Hit ทั้งหมดช่วยให้เราสามารถใช้มิติข้อมูลนี้เมื่อรายงานเกี่ยวกับเมตริกใดก็ได้

คุณจะเห็นได้ว่า 85% ของการดูหน้าเว็บทั้งหมดของ IOWA มาจากเบราว์เซอร์ที่รองรับ Service Worker

ผลลัพธ์: การตอบคำถามของเรา

เมื่อเราเริ่มรวบรวมข้อมูลเพื่อตอบคำถามของเราแล้ว เราก็สามารถรายงานข้อมูลนั้นเพื่อดูผลลัพธ์ได้ (หมายเหตุ: ข้อมูล Google Analytics ทั้งหมดที่แสดงที่นี่แสดงการเข้าชมเว็บที่เกิดขึ้นจริงในเว็บไซต์ IOWA ตั้งแต่วันที่ 16-22 พฤษภาคม 2016)

คำถามแรกคือการแคชโปรแกรมทำงานของบริการมีประสิทธิภาพมากกว่ากลไกการแคช HTTP ที่มีอยู่ในเบราว์เซอร์ทั้งหมดหรือไม่

เพื่อตอบคำถามดังกล่าว เราจึงสร้างรายงานที่กำหนดเองที่พิจารณาเมตริกเวลาในการโหลดหน้าเว็บเฉลี่ยในมิติข้อมูลต่างๆ เมตริกนี้เหมาะที่จะตอบคำถามนี้ เนื่องจากเหตุการณ์ load จะเริ่มทํางานหลังจากดาวน์โหลดทรัพยากรเริ่มต้นทั้งหมดแล้วเท่านั้น ดังนั้นจึงแสดงถึงเวลาโหลดรวมสำหรับทรัพยากรที่สำคัญทั้งหมดของเว็บไซต์โดยตรง5

ขนาดที่เราเลือกคือ

• มิติข้อมูลสถานะ Service Worker ที่กำหนดเองของเรา
• ประเภทผู้ใช้ ซึ่งระบุว่านี่เป็นการเข้าชมเว็บไซต์ครั้งแรกของผู้ใช้หรือกลับมาอีกครั้ง (หมายเหตุ: ผู้เข้าชมใหม่จะไม่ได้แคชแหล่งข้อมูลใดๆ ไว้ แต่ผู้เข้าชมที่กลับมาอาจ)
• หมวดหมู่อุปกรณ์ ซึ่งทำให้เราเปรียบเทียบผลลัพธ์ในอุปกรณ์เคลื่อนที่และเดสก์ท็อปได้

เราจึงจำกัดการค้นหาให้รวมเฉพาะเบราว์เซอร์ที่รองรับ Service Worker เท่านั้น เพื่อควบคุมความเป็นไปได้ที่ปัจจัยที่ไม่ได้เกี่ยวข้องกับพนักงานบริการจะบิดเบือนผลลัพธ์ของเวลาที่ใช้ในการโหลด

ดังที่คุณเห็น การเข้าชมแอปของเราเมื่อควบคุมโดย Service Worker จะโหลดเร็วกว่าการเข้าชมที่ไม่มีการควบคุมเล็กน้อย แม้แต่การเข้าชมที่มาจากผู้ใช้ที่กลับมาซึ่งน่าจะเป็นการแคชทรัพยากรส่วนใหญ่ของหน้า เป็นเรื่องที่น่าสนใจเช่นกันว่า โดยเฉลี่ยแล้ว ผู้เข้าชมบนอุปกรณ์เคลื่อนที่ที่มีโปรแกรมทำงานของบริการพบว่าโหลดเร็วกว่าผู้เข้าชมบนเดสก์ท็อปรายใหม่

"...การเข้าชมแอปเมื่อควบคุมโดยโปรแกรมทำงานของบริการซึ่งโหลดเร็วกว่าการเข้าชมที่ไม่มีการควบคุม..."

คุณสามารถดูรายละเอียดเพิ่มเติมได้ใน 2 ตารางต่อไปนี้

เวลาในการโหลดหน้าเว็บเฉลี่ย (เดสก์ท็อป)
สถานะ Service Worker	ประเภทของผู้ใช้	เวลาในการโหลดหน้าเว็บเฉลี่ย (มิลลิวินาที)	ขนาดตัวอย่าง
ควบคุม	ผู้เข้าชมที่กลับมาใหม่	2568	30860
รองรับ	ผู้เข้าชมที่กลับมาใหม่	3612	1289
รองรับ	ผู้เข้าชมใหม่	4664	21991

เวลาในการโหลดหน้าเว็บเฉลี่ย (อุปกรณ์เคลื่อนที่)
สถานะ Service Worker	ประเภทของผู้ใช้	เวลาในการโหลดหน้าเว็บเฉลี่ย (มิลลิวินาที)	ขนาดตัวอย่าง
ควบคุม	ผู้เข้าชมที่กลับมาใหม่	3760	8162
รองรับ	ผู้เข้าชมที่กลับมาใหม่	4843	676
รองรับ	ผู้เข้าชมใหม่	6158	5779

คุณอาจสงสัยว่าจะเป็นไปได้อย่างไรที่ผู้เข้าชมที่กลับมาซึ่งมีเบราว์เซอร์ที่รองรับ Service Worker จะอยู่ในสถานะที่ไม่มีการควบคุม คำอธิบายที่เป็นไปได้สำหรับเรื่องนี้มีดังนี้

• ผู้ใช้ออกจากหน้าเว็บในการเข้าชมครั้งแรกก่อนที่โปรแกรมทำงานของบริการจะมีโอกาสดำเนินการเริ่มต้นให้เสร็จสิ้น
• ผู้ใช้ถอนการติดตั้ง Service Worker ผ่านเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

ทั้ง 2 สถานการณ์นี้เกิดขึ้นไม่บ่อยนัก เราจะเห็นได้จากข้อมูลนี้โดยดูที่ค่าตัวอย่างการโหลดหน้าเว็บในคอลัมน์ที่ 4 โปรดสังเกตว่าแถวกลางมีตัวอย่างน้อยกว่าอีก 2 แถวมาก

คำถามที่ 2 คือ Service Worker ส่งผลต่อประสบการณ์การโหลดเว็บไซต์อย่างไร

เพื่อตอบคำถามนี้ เราได้สร้างรายงานที่กำหนดเองอีกฉบับสำหรับเมตริกมูลค่าเหตุการณ์เฉลี่ย และกรองผลลัพธ์ให้รวมเฉพาะเหตุการณ์ firstpaint ของเราเท่านั้น เราใช้มิติข้อมูลหมวดหมู่อุปกรณ์และมิติข้อมูลสถานะ Service Worker ที่กำหนดเองของเรา

ในทางตรงข้ามกับที่คาดไว้ โปรแกรมทำงานของบริการบนอุปกรณ์เคลื่อนที่นั้นสร้างผลกระทบต่อเวลาที่ใช้ในการแสดงผลครั้งแรกได้น้อยกว่ามากในการโหลดหน้าเว็บโดยรวม

"...Service Worker ในอุปกรณ์เคลื่อนที่มีผลกระทบต่อเวลาที่ใช้ในการแสดงผลครั้งแรกน้อยกว่ามากเมื่อเทียบกับการโหลดหน้าเว็บโดยรวม"

เราต้องตรวจสอบข้อมูลดังกล่าวให้ละเอียดขึ้นเพื่อค้นหาสาเหตุ ค่าเฉลี่ยอาจเหมาะสำหรับภาพรวมทั่วไปและกราฟกว้างๆ แต่หากต้องการเห็นภาพคร่าวๆ ว่าตัวเลขเหล่านี้แบ่งออกเป็นผู้ใช้กลุ่มต่างๆ อย่างไร เราจะต้องดูการกระจายเป็น 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 ยังไม่มีวิธีแสดงภาพการกระจายค่าเมตริกที่กำหนดเอง แต่ด้วยความช่วยเหลือจาก API การรายงานหลักของ Google Analytics และไลบรารี Google Charts เราสามารถค้นหาผลลัพธ์ที่เป็นข้อมูลดิบแล้วสร้างฮิสโตแกรมด้วยตนเอง

เช่น มีการใช้การกำหนดค่าคำขอ API ต่อไปนี้เพื่อรับการกระจายค่า firstpaint ในเดสก์ท็อปด้วย Service Worker ที่ไม่มีการควบคุม

{
  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'
    }
  ]
}

คำขอ API นี้จะแสดงผลอาร์เรย์ของค่าที่มีลักษณะดังนี้ (หมายเหตุ: ผลลัพธ์เหล่านี้เป็นเพียงผลลัพธ์ 5 รายการแรก) ผลลัพธ์จะจัดเรียงจากเล็กสุดไปใหญ่ที่สุด ดังนั้นแถวเหล่านี้จึงแสดงเวลาที่เร็วที่สุด

ผลการตอบกลับจาก API (5 แถวแรก)
ga:dimension2	ga:totalEvents
4	3
5	2
6	10
7	8
8	10

ผลการค้นหาเหล่านี้แปลว่าอะไรในภาษาอังกฤษง่ายๆ

• มี 3 เหตุการณ์ที่มีค่า firstpaint เท่ากับ 4 มิลลิวินาที
• มี 2 เหตุการณ์ที่มีค่า firstpaint เท่ากับ 5 มิลลิวินาที
• มีเหตุการณ์ 10 รายการที่มีค่า firstpaint เป็นเวลา 6 มิลลิวินาที
• มี 8 เหตุการณ์ที่มีค่า firstpaint เท่ากับ 7 มิลลิวินาที
• มี 10 เหตุการณ์ที่ firstpaint value เป็นเวลา 8 มิลลิวินาที
• อื่นๆ

จากผลลัพธ์เหล่านี้ เราสามารถประมาณค่า firstpaint สำหรับเหตุการณ์แต่ละรายการและสร้างฮิสโตแกรมของการแจกแจง เราทำเช่นนี้กับการสืบค้นข้อมูลแต่ละรายการที่เราทำ

การกระจายบนเดสก์ท็อปที่มี Service Worker ที่ไม่มีการควบคุม (แต่รองรับ) จะมีลักษณะดังนี้

เวลามัธยฐานของ firstpaint สำหรับการกระจายข้างต้นคือ 912 มิลลิวินาที

รูปร่างของเส้นโค้งนี้ค่อนข้างปกติของการแจกแจงเวลาที่ใช้ในการโหลด ตรงข้ามกับฮิสโตแกรมด้านล่างซึ่งแสดงการกระจายเหตุการณ์การแสดงผลครั้งแรกสำหรับการเข้าชมที่ Service Worker ควบคุมหน้า

โปรดสังเกตว่าเมื่อ Service Worker กำลังควบคุมหน้าเว็บ ผู้เข้าชมจำนวนมากเห็นการแสดงผลครั้งแรกเกือบจะทันที โดยมีค่ามัธยฐาน 583 มิลลิวินาที

"...ในขณะที่พนักงานบริการได้ควบคุมหน้าเว็บ ผู้เข้าชมจำนวนมากได้พบการทาสีครั้งแรกเกือบจะทันที..."

แผนภูมิถัดไปจะแสดงมุมมองแบบรวมของการแจกแจงทั้ง 2 แบบเพื่อให้เข้าใจได้ดียิ่งขึ้น ฮิสโตแกรมที่แสดงการเข้าชมของ Service Worker ที่ไม่มีการควบคุมจะวางซ้อนอยู่ด้านบนของฮิสโตแกรมที่แสดงการเข้าชมที่ควบคุม และทั้ง 2 จุดซ้อนทับบนฮิสโตแกรมที่แสดงทั้ง 2 จุด

สิ่งหนึ่งที่ผมพบว่าน่าสนใจเกี่ยวกับผลลัพธ์เหล่านี้คือการกระจายกับ Service Worker ที่มีการควบคุมยังคงมีเส้นโค้งรูประฆังหลังจากการเพิ่มขึ้นในช่วงแรก ผมคาดหวังว่าจะมีการเพิ่มขึ้นอย่างมากในช่วงแรก แล้วค่อยๆ ลดลง ผมไม่คิดว่าจะมีจุดสูงสุดเป็นอันดับ 2 ในเส้นโค้ง

เมื่อตรวจสอบสาเหตุที่เป็นไปได้ของปัญหานี้ เราพบว่าแม้โปรแกรมทำงานของบริการจะสามารถควบคุมหน้าเว็บได้ แต่เทรดของหน้าเว็บจะไม่ทำงาน เบราว์เซอร์จะดำเนินการนี้เพื่อบันทึกทรัพยากร ซึ่งแน่นอนว่าไม่จำเป็นต้องเป็นโปรแกรมทำงานของ Service Worker สำหรับทุกๆ เว็บไซต์ที่คุณเคยเข้าชมให้มาทำงานและพร้อมใช้งานได้ทันที ข้อมูลนี้จะอธิบายส่วนท้ายของการแจกแจง อาจมีความล่าช้าสำหรับผู้ใช้บางรายที่เทรด Service Worker เริ่มทำงาน

อย่างที่คุณเห็นจากการกระจาย แม้ว่าความล่าช้าในระยะแรกนี้ เบราว์เซอร์ที่มี Service Worker จะส่งเนื้อหาได้เร็วกว่าเบราว์เซอร์ที่เดินทางผ่านเครือข่าย

สิ่งที่เห็นบนอุปกรณ์เคลื่อนที่มีดังนี้

ถึงแม้ว่าเราจะยังวาดรูปครั้งแรกได้แบบเกือบฉับพลันได้มากขึ้น แต่หางก็ค่อนข้างใหญ่และยาวขึ้นมาก ซึ่งอาจเป็นเพราะในอุปกรณ์เคลื่อนที่ การเริ่มเทรด Service Worker ที่ไม่มีการใช้งานบนอุปกรณ์เคลื่อนที่ใช้เวลานานกว่าบนเดสก์ท็อป ทั้งยังอธิบายสาเหตุที่ความแตกต่างระหว่างเวลา firstpaint เฉลี่ยไม่มากอย่างที่คาดไว้ (กล่าวถึงข้างต้น)

"... ในอุปกรณ์เคลื่อนที่ การเริ่มเทรด Service Worker ที่ไม่มีการใช้งานจะใช้เวลานานกว่าในเดสก์ท็อป"

รายละเอียดจากค่ามัธยฐานของเวลาการแสดงผลครั้งแรกในอุปกรณ์เคลื่อนที่และเดสก์ท็อปที่จัดกลุ่มตามสถานะของ Service Worker มีดังนี้

ค่ามัธยฐานของเวลาในการแสดงผลครั้งแรก (มิลลิวินาที)
สถานะ Service Worker	เดสก์ท็อป	อุปกรณ์เคลื่อนที่
ควบคุม	583	1634
รองรับ (ไม่มีการควบคุม)	912	1933

ขณะที่การสร้างภาพแสดงการกระจายเหล่านี้ใช้เวลาและความพยายามมากกว่าการสร้างรายงานที่กำหนดเองใน Google Analytics อยู่เล็กน้อย ทำให้เราเข้าใจได้ดีขึ้นว่าโปรแกรมทำงานของบริการส่งผลต่อประสิทธิภาพของเว็บไซต์ของเราอย่างไรมากกว่าการใช้ค่าเฉลี่ยเพียงอย่างเดียว

ผลกระทบอื่นๆ จาก Service Worker

นอกจากผลกระทบด้านประสิทธิภาพแล้ว โปรแกรมทำงานของบริการยังส่งผลต่อประสบการณ์ของผู้ใช้ด้วยวิธีอื่นๆ อีกหลายวิธีที่ Google Analytics วัดผลได้

การเข้าถึงแบบออฟไลน์

Service Worker ช่วยให้ผู้ใช้โต้ตอบกับเว็บไซต์ของคุณขณะออฟไลน์ได้ และแม้ว่าการสนับสนุนแบบออฟไลน์บางอย่างจะมีความสำคัญสำหรับ Progressive Web App แต่การพิจารณาความสําคัญของการใช้งานในกรณีของคุณนั้นส่วนใหญ่จะขึ้นอยู่กับปริมาณการใช้งานที่เกิดขึ้นแบบออฟไลน์ แต่เราจะวัดได้อย่างไร

การส่งข้อมูลไปยัง Google Analytics ต้องใช้การเชื่อมต่ออินเทอร์เน็ต แต่ไม่ได้กำหนดให้ต้องส่งในเวลาที่แน่นอนที่มีการโต้ตอบ Google Analytics รองรับการส่งข้อมูลการโต้ตอบหลังจากดำเนินการแล้วโดยระบุการชดเชยเวลา (ผ่านพารามิเตอร์ qt)

ในช่วง 2 ปีที่ผ่านมา IOWA ใช้สคริปต์โปรแกรมทำงานบริการซึ่งตรวจหา Hit ที่ล้มเหลวไปยัง Google Analytics เมื่อผู้ใช้ออฟไลน์และเล่นซ้ำในภายหลังด้วยพารามิเตอร์ qt

หากต้องการติดตามว่าผู้ใช้ออนไลน์หรือออฟไลน์ เราได้สร้างมิติข้อมูลที่กําหนดเองชื่อออนไลน์ แล้วกําหนดให้มีค่าเป็น navigator.onLine จากนั้นรอฟังเหตุการณ์ online และ offline และอัปเดตมิติข้อมูลตามนั้น

และเพื่อทำความเข้าใจว่าผู้ใช้ออฟไลน์ขณะใช้ IOWA เกิดขึ้นมากน้อยเพียงใด เราจึงสร้างกลุ่มที่กำหนดเป้าหมายผู้ใช้ที่มีการโต้ตอบแบบออฟไลน์อย่างน้อย 1 ครั้ง ซึ่งผลปรากฏว่าเกือบ 5% ของผู้ใช้ทั้งหมด

ข้อความ Push

โปรแกรมทำงานของบริการอนุญาตให้ผู้ใช้เลือกรับข้อความ Push ได้ ผู้ใช้ใน IOWA ได้รับแจ้งเมื่อเซสชันในกำหนดการของตนกำลังจะเริ่ม

เช่นเดียวกับการแจ้งเตือนทุกรูปแบบ สิ่งสำคัญคือต้องหาจุดสมดุลระหว่างการมอบคุณค่าให้กับผู้ใช้และการสร้างความรำคาญ เพื่อให้เข้าใจถึงสิ่งที่เกิดขึ้นได้ดียิ่งขึ้น สิ่งสำคัญคือต้องติดตามว่าผู้ใช้เลือกที่จะรับการแจ้งเตือนเหล่านี้หรือไม่ มีส่วนร่วมเมื่อเข้ามาหรือไม่ และผู้ใช้ที่เคยเลือกใช้ก่อนหน้านี้ได้เปลี่ยนค่ากำหนดและเลือกไม่รับหรือไม่

ใน IOWA เราส่งการแจ้งเตือนที่เกี่ยวข้องกับกำหนดการที่ปรับเปลี่ยนในแบบของผู้ใช้เท่านั้น ซึ่งเป็นสิ่งที่ผู้ใช้ที่เข้าสู่ระบบสร้างขึ้นเท่านั้น ซึ่งจะจำกัดกลุ่มผู้ใช้ที่สามารถรับการแจ้งเตือนสำหรับผู้ใช้ที่ลงชื่อเข้าสู่ระบบ (ติดตามผ่านมิติข้อมูลที่กำหนดเองชื่อลงชื่อเข้าใช้) ซึ่งมีเบราว์เซอร์ที่รองรับข้อความ Push (ติดตามผ่านมิติข้อมูลที่กำหนดเองอื่นที่ชื่อว่าสิทธิ์การแจ้งเตือน)

รายงานต่อไปนี้อิงตามเมตริกผู้ใช้และมิติข้อมูลที่กำหนดเองของสิทธิ์การแจ้งเตือน ซึ่งแบ่งกลุ่มตามผู้ใช้ที่ลงชื่อเข้าใช้ในบางจุดและมีเบราว์เซอร์ที่รองรับข้อความ Push

เป็นเรื่องดีที่ผู้ใช้ที่ลงชื่อเข้าใช้มากกว่าครึ่งของเราเลือกรับข้อความ Push

แบนเนอร์เพื่อการติดตั้งแอป

หากเว็บแอปของความคืบหน้าเป็นไปตามเกณฑ์และมีผู้ใช้ใช้งานบ่อยครั้ง ผู้ใช้นั้นอาจเห็นแบนเนอร์การติดตั้งแอปเพื่อแจ้งให้ผู้ใช้เพิ่มแอปไปยังหน้าจอหลัก

ใน 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 ในปีนี้มีค่ามาก แต่การมองการณ์ไกลมักจะนำมาซึ่งช่องว่างและโอกาสในการปรับปรุงสิ่งต่างๆ ในครั้งต่อไป หลังจากสิ้นสุดการวิเคราะห์ของปีนี้แล้ว เรามี 2 สิ่งที่เราอยากจะทำที่แตกต่างออกไป ซึ่งผู้อ่านที่คิดจะใช้กลยุทธ์ที่คล้ายกันนี้อาจต้องพิจารณาดังนี้

1. ติดตามเหตุการณ์เพิ่มเติมที่เกี่ยวข้องกับประสบการณ์การโหลด

เราได้ติดตามหลายเหตุการณ์ที่สอดคล้องกับเมตริกทางเทคนิค (เช่น HTMLImportsLoaded, WebComponentsReady เป็นต้น) แต่เนื่องจากการโหลดส่วนใหญ่เกิดขึ้นแบบไม่พร้อมกัน เหตุการณ์ที่เหตุการณ์เหล่านี้เริ่มทำงานจึงไม่จำเป็นต้องตรงกับช่วงเวลาหนึ่งๆ ในการโหลดโดยรวม

เหตุการณ์เกี่ยวกับการโหลดหลักที่เราไม่ได้ติดตาม (แต่เราอยากให้มี) คือจุดที่หน้าจอแนะนำหายไปและผู้ใช้จะเห็นเนื้อหาของหน้านั้น

2. จัดเก็บรหัสไคลเอ็นต์ของ Analytics ใน IndexedDB

โดยค่าเริ่มต้น analytics.js จะจัดเก็บช่องรหัสไคลเอ็นต์ในคุกกี้ของเบราว์เซอร์ ดังนั้นสคริปต์ของ Service Worker จะเข้าถึงคุกกี้ไม่ได้

ซึ่งทำให้เราเกิดปัญหาขณะที่เราพยายามใช้การติดตามการแจ้งเตือน เราต้องการส่งเหตุการณ์จาก Service Worker (ผ่าน Measurement Protocol) ทุกครั้งที่มีการส่งการแจ้งเตือนไปยังผู้ใช้ จากนั้นติดตามความสำเร็จในการกลับมามีส่วนร่วมของการแจ้งเตือนนั้นหากผู้ใช้คลิกและกลับเข้ามาในแอป

แม้ว่าเราจะติดตามความสำเร็จของการแจ้งเตือนโดยทั่วไปผ่านพารามิเตอร์แคมเปญ utm_source ได้ แต่เราก็ไม่สามารถเชื่อมโยงเซสชันการมีส่วนร่วมซ้ำที่เจาะจงกับผู้ใช้บางรายได้

สิ่งที่เราทําได้เพื่อแก้ปัญหาข้อจํากัดนี้คือการจัดเก็บรหัสไคลเอ็นต์ผ่าน IndexedDB ในโค้ดติดตาม จากนั้นสคริปต์ Service Worker จะสามารถเข้าถึงค่านั้นได้

3. ให้ Service Worker รายงานสถานะออนไลน์/ออฟไลน์

การตรวจสอบ navigator.onLine จะช่วยให้คุณทราบว่าเบราว์เซอร์เชื่อมต่อกับเราเตอร์หรือเครือข่าย LAN ได้ แต่อาจไม่ทราบว่าคุณเชื่อมต่อผู้ใช้จริงหรือไม่ และเนื่องจากสคริปต์โปรแกรมทำงานของบริการการวิเคราะห์แบบออฟไลน์ของเราเพียงแค่เล่น Hit ที่ล้มเหลวซ้ำ (โดยไม่แก้ไขหรือทำเครื่องหมายว่าล้มเหลว) เราอาจรายงานการใช้งานออฟไลน์ต่ำกว่าความเป็นจริง

ในอนาคต เราควรติดตามทั้งสถานะของ navigator.onLine และขึ้นอยู่กับว่าโปรแกรมทำงานของบริการเล่น Hit ซ้ำเนื่องจากเครือข่ายล้มเหลวหรือไม่ในตอนแรก วิธีนี้จะช่วยให้เราเห็นภาพการใช้งานแบบออฟไลน์ที่แท้จริงได้อย่างถูกต้องมากขึ้น

ใกล้จะเสร็จแล้ว

กรณีศึกษานี้แสดงให้เห็นว่าการใช้ Service Worker ได้ปรับปรุงประสิทธิภาพการโหลดของเว็บแอป Google I/O ในเบราว์เซอร์ เครือข่าย และอุปกรณ์ต่างๆ ได้อย่างแท้จริง ยังแสดงให้เห็นอีกว่าเมื่อดูการกระจายข้อมูลการโหลดในเบราว์เซอร์ เครือข่าย และอุปกรณ์ต่างๆ คุณจะเห็นข้อมูลเชิงลึกมากขึ้นว่าเทคโนโลยีนี้จัดการกับสถานการณ์ในโลกแห่งความเป็นจริงได้อย่างไร และได้พบคุณลักษณะด้านประสิทธิภาพที่คุณอาจคาดไม่ถึง

สิ่งสำคัญที่ได้เรียนรู้จากการศึกษาของ IOWA มีดังนี้

• โดยเฉลี่ยแล้ว หน้าเว็บโหลดได้ค่อนข้างเร็วกว่าเมื่อโปรแกรมทำงานของบริการควบคุมหน้าเว็บเมื่อเทียบกับตอนที่ไม่ได้ใช้ Service Worker สำหรับทั้งผู้เข้าชมใหม่และผู้เข้าชมที่กลับมา
• การเข้าชมหน้าเว็บที่ควบคุมโดย Service Worker จะโหลดผู้ใช้จำนวนมากแทบจะในทันที
• Service Worker จะใช้เวลาสักครู่ในการเริ่มต้นใหม่ เมื่อไม่มีการใช้งาน อย่างไรก็ตาม Service Worker ที่ไม่ได้ใช้งานจะยังคงมีประสิทธิภาพดีกว่าไม่มี Service Worker
• เวลาเริ่มต้นสำหรับ Service Worker ที่ไม่ได้ใช้งานบนอุปกรณ์เคลื่อนที่นานกว่าในเดสก์ท็อป

แม้ว่าประสิทธิภาพที่เพิ่มขึ้นซึ่งสังเกตได้ในแอปพลิเคชันหนึ่งๆ จะมีประโยชน์ในการรายงานต่อชุมชนนักพัฒนาซอฟต์แวร์ที่มีขนาดใหญ่ แต่สิ่งสำคัญที่ควรทราบคือผลลัพธ์เหล่านี้มีความเฉพาะเจาะจงสำหรับประเภทของเว็บไซต์ IOWA ที่เป็น (เว็บไซต์กิจกรรม) และประเภทของผู้ชมที่ IOWA มี (ส่วนใหญ่เป็นนักพัฒนาซอฟต์แวร์)

หากคุณใช้ Service Worker ในแอปพลิเคชันก็จะต้องใช้กลยุทธ์การวัดผลของตนเองเพื่อให้สามารถประเมินประสิทธิภาพของตนเองและป้องกันการถดถอยในอนาคตได้ หากเข้าร่วม โปรดแชร์ผลลัพธ์เพื่อให้ทุกคนได้รับประโยชน์

เชิงอรรถ

1. การเปรียบเทียบประสิทธิภาพในการใช้งานแคชของโปรแกรมทำงานของบริการกับประสิทธิภาพเว็บไซต์ของเราที่ใช้แคช HTTP เพียงอย่างเดียวนั้นไม่ยุติธรรมเลย เนื่องจากเราเพิ่มประสิทธิภาพ IOWA สำหรับ Service Worker จึงไม่ได้ใช้เวลาในการเพิ่มประสิทธิภาพแคช HTTP มากนัก หากเป็นเช่นนั้น ผลลัพธ์อาจแตกต่างออกไป หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพเว็บไซต์สำหรับแคช HTTP โปรดอ่านการเพิ่มประสิทธิภาพเนื้อหาอย่างมีประสิทธิภาพ
2. เป็นไปได้ว่าเบราว์เซอร์สามารถระบายสีก่อนที่เนื้อหาหรือสไตล์จะใช้งานได้ ทั้งนี้ขึ้นอยู่กับวิธีที่เว็บไซต์ของคุณโหลดรูปแบบและเนื้อหา ในกรณีดังกล่าว firstpaint อาจสอดคล้องกับหน้าจอว่างเปล่าสีขาว หากใช้ firstpaint คุณต้องตรวจสอบว่า URL ดังกล่าวตรงกับจุดที่มีความหมายในการโหลดทรัพยากรของเว็บไซต์
3. ในทางเทคนิค เราอาจส่ง Hit ที่เป็นระยะเวลา (ซึ่งไม่ใช่การโต้ตอบโดยค่าเริ่มต้น) เพื่อบันทึกข้อมูลนี้แทนเหตุการณ์ อันที่จริงแล้ว ระบบเพิ่ม Hit แบบช่วงเวลาไปยัง Google Analytics เพื่อติดตามเมตริกการโหลดเช่นนี้โดยเฉพาะ อย่างไรก็ตาม Hit ด้านเวลาจะได้รับการสุ่มตัวอย่างจำนวนมากในเวลาประมวลผล และค่าเหล่านี้จะใช้ไม่ได้ในกลุ่ม เนื่องด้วยข้อจำกัดในปัจจุบันเหล่านี้ เหตุการณ์ที่ไม่มีการโต้ตอบจึงเหมาะสมกว่า
4. เพื่อให้เข้าใจขอบเขตที่จะมอบมิติข้อมูลที่กำหนดเองใน Google Analytics ได้ดีขึ้น โปรดดูส่วนมิติข้อมูลที่กำหนดเองในศูนย์ช่วยเหลือของ Analytics นอกจากนี้คุณยังควรทำความเข้าใจโมเดลข้อมูลของ Google Analytics ซึ่งประกอบด้วยผู้ใช้ เซสชัน และการโต้ตอบ (Hit) ดูข้อมูลเพิ่มเติมได้ในบทเรียน Analytics Academy เรื่องโมเดลข้อมูลของ Google Analytics
5. ซึ่งไม่รวมถึงทรัพยากรที่โหลดแบบ Lazy Loading หลังจากเหตุการณ์การโหลด