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

Philip Walton

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

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

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

เริ่มจากคำถาม

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

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

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

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

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

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

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

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

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

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

โดยค่าเริ่มต้น Google Analytics จะติดตามเวลาในการโหลดหน้าเว็บ (ผ่าน น่าสนใจ 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');

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

สำหรับ IOWA เราต้องการติดตาม 2 สิ่งต่อไปนี้เพิ่มเติม

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

กำลังจับภาพเวลาในการแสดงผลครั้งแรก

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

อย่างที่ได้กล่าวไปแล้ว Time to first Paint เป็นเมตริกสําคัญในการวัด เนื่องจากนี่เป็นจุดแรกที่ผู้ใช้ประสบกับความเร็วในการโหลดของเว็บไซต์ ประสบการณ์ของผู้ใช้คือความประทับใจแรกที่ผู้ใช้จะได้รับ และความประทับใจแรกที่ดีก็ส่งผลดีต่อประสบการณ์ที่เหลือของผู้ใช้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;
    }
  }
}

ในตอนนี้ เราสามารถเขียนอีกฟังก์ชันหนึ่งที่ส่งเหตุการณ์ที่ไม่มีการโต้ตอบ โดยมีค่า Time to first Paint เป็นค่าต่อไปนี้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
    });
  }
}

หลังจากเขียนทั้ง 2 ฟังก์ชันแล้ว โค้ดติดตามของเราจะมีลักษณะดังนี้

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

// 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

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

• controlled: มี Service Worker กำลังควบคุมหน้านี้ ในกรณีของ IOWA หมายความว่าเนื้อหาทั้งหมดได้รับการแคชไว้และหน้าเว็บทำงานแบบออฟไลน์ได้
• รองรับ: เบราว์เซอร์รองรับ 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 เป็นข้อมูลที่อาจมีประโยชน์เมื่อทราบการโต้ตอบ ดังนั้น คุณจึงควรรวมส่วนนี้ไว้กับข้อมูลทั้งหมดที่ส่งไปยัง 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 Status ให้กับทุก Hit จะทำให้เราสามารถใช้มิติข้อมูลนี้เมื่อรายงานเกี่ยวกับเมตริกใดก็ได้

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

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

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

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

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

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

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

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

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

"...การเข้าชมแอปของเราเมื่อมีการควบคุมโดย Service Worker จะโหลดเร็วกว่าการเข้าชมที่ไม่มีการควบคุมเล็กน้อย..."

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

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

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

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

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

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

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

ผลการค้นหาภาษาอังกฤษง่ายๆ มีความหมายดังนี้

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

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

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

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

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

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

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

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

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

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

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

ต่อไปนี้คือลักษณะของสิ่งต่างๆ บนอุปกรณ์เคลื่อนที่

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

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

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

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

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

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

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

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

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

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

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

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

ข้อความ Push

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

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

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

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

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

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

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

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

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

3. ให้โปรแกรมทำงานของบริการรายงานสถานะออนไลน์/ออฟไลน์

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

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

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

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

สิ่งสำคัญบางส่วนจากการศึกษาของ IOWA มีดังนี้

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

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

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

เชิงอรรถ

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