การทดลองใช้ First Input Delay ในรายงาน UX ของ Chrome

เป้าหมายของรายงานประสบการณ์ของผู้ใช้ Chrome คือช่วยให้ชุมชนเว็บเข้าใจถึงการกระจายและวิวัฒนาการของประสิทธิภาพจริงของผู้ใช้ จนถึงตอนนี้ เรามุ่งเน้นที่เมตริกการแสดงผลและการโหลดหน้าเว็บ เช่น First Contentful Paint (FCP) และ Onload (OL) ซึ่งช่วยให้เราเข้าใจประสิทธิภาพของเว็บไซต์ด้วยภาพสำหรับผู้ใช้ ตั้งแต่รุ่นเดือนมิถุนายน 2018 เป็นต้นไป เราจะเริ่มทดสอบเมตริกใหม่ที่เน้นผู้ใช้เป็นหลักซึ่งมุ่งเน้นที่การโต้ตอบของหน้าเว็บ ได้แก่ First Input Delay (FID) เมตริกใหม่นี้จะช่วยให้เราเข้าใจได้ดียิ่งขึ้นว่าเว็บไซต์ต่างๆ ตอบสนองต่อข้อมูลจากผู้ใช้อย่างไร

เมื่อเร็วๆ นี้ FID เพิ่งเปิดให้ใช้งานใน Chrome เป็นแบบช่วงทดลองใช้จากต้นทาง ซึ่งหมายความว่าเว็บไซต์จะเลือกทดลองใช้ฟีเจอร์แพลตฟอร์มเว็บใหม่นี้ได้ ในทำนองเดียวกัน FID จะมีอยู่ในรายงาน UX ของ Chrome เป็นเมตริกทดลอง ซึ่งหมายความว่าจะพร้อมใช้ตลอดระยะเวลาของช่วงทดลองใช้จากต้นทางภายในเนมสเปซ "ทดลอง" ที่แยกกัน

วิธีวัด FID

แล้ว FID คืออะไร ตามคำอธิบายในบล็อกโพสต์ประกาศ First Input Delay

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

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

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

การสำรวจ FID ในรายงาน UX ของ Chrome

ข้อมูล FID จากหลายเดือนจากหลายล้านแหล่งทำให้มีข้อมูลเชิงลึกที่น่าสนใจมากมายรอสำรวจอยู่ มาดูคำค้นหาบางส่วนที่สาธิตวิธีดึงข้อมูลเชิงลึกเหล่านี้จากรายงาน UX ของ Chrome ใน BigQuery กัน

มาเริ่มด้วยการค้นหาเปอร์เซ็นต์ของประสบการณ์ FID ที่รวดเร็วสำหรับ developers.google.com เราสามารถกำหนดประสบการณ์แบบรวดเร็วให้เป็นแบบที่ FID น้อยกว่า 100 มิลลิวินาที ตามคำแนะนำของ RAIL หากความล่าช้าคือ 100 มิลลิวินาทีขึ้นไป ผู้ใช้จะรู้สึกได้ทันที

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
  origin = 'https://developers.google.com'

ผลลัพธ์แสดงให้เห็นว่าประสบการณ์การใช้งาน FID ในต้นทาง 95% นี้รับรู้เป็นสถานการณ์ทันที ก็ดูดีมากเลย แต่เปรียบเทียบกับต้นทางทั้งหมดในชุดข้อมูลแล้วเป็นอย่างไร

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid

ผลการค้นหานี้แสดงให้เห็นว่า 84% ของประสบการณ์การใช้งาน FID ใช้เวลาไม่ถึง 100 มิลลิวินาที ดังนั้น developer.google.com จึงสูงกว่าค่าเฉลี่ย

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

SELECT
  form_factor.name AS form_factor,
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
  form_factor
form_factor fast_fid
เดสก์ท็อป 96.02%
หมายเลขโทรศัพท์ 79.90%
แท็บเล็ต 76.48%

ซึ่งผลลัพธ์นี้ยืนยันสมมติฐานของเรา เดสก์ท็อปมีความหนาแน่นสะสมของการใช้งาน FID ที่รวดเร็วกว่ารูปแบบของอุปกรณ์โทรศัพท์และแท็บเล็ต การทำความเข้าใจสาเหตุที่มีความแตกต่างเหล่านี้ เช่น ประสิทธิภาพของ CPU จะต้องผ่านการทดสอบ A/B ที่อยู่นอกขอบเขตของรายงาน UX ของ Chrome

หลังจากได้เห็นวิธีระบุว่าต้นทางนั้นมีประสบการณ์ FID ที่รวดเร็วหรือไม่ เรามาลองดู 2 ต้นทางที่มีประสิทธิภาพดีจริงๆ กัน

ตัวอย่างที่ 1: http://secretlycanadian.com

แถบฟิล์ม WebPageTest ของ secretlycanadian.com

ต้นทางนี้มี FID 98% ของประสบการณ์ FID ต่ำกว่า 100 มิลลิวินาที พวกเขาทำงานอย่างไร เมื่อวิเคราะห์วิธีสร้างใน WebPageTest แล้ว เราเห็นว่าเป็นหน้า WordPress ที่เน้นรูปภาพเป็นหลัก แต่ก็มี JavaScript ขนาด 168 KB ที่ทำงานได้ภายในเวลาประมาณ 500 มิลลิวินาทีในเครื่องห้องทดลองของเรา ซึ่งไม่ใช่ JavaScript มากนักตามที่เก็บถาวรของ HTTP ซึ่งทำให้หน้านี้อยู่ในเปอร์เซ็นไทล์ที่ 28

Waterfall ของ AWebPageTest ของ secretlycanadian.com

แถบสีชมพูที่ยาว 2.7 ถึง 3.0 วินาทีคือระยะแยกวิเคราะห์ HTML ระหว่างนี้ หน้าจะไม่มีการโต้ตอบและดูไม่สมบูรณ์ (ดู “3.0 วินาที” ในแถบฟิล์มด้านบน) หลังจากนั้น ระบบจะแบ่งงานที่ใช้เวลานานซึ่งต้องได้รับการประมวลผล เพื่อดูแลให้เทรดหลักยังคงไม่มีการเคลื่อนไหว เส้นสีชมพูในแถวที่ 11 แสดงถึงวิธีการแพร่กระจายของ JavaScript อย่างฉับพลัน

ตัวอย่างที่ 2: https://www.wtfast.com

แถบฟิล์ม WebPageTest ของ wtfast.com

ต้นทางนี้ได้รับประสบการณ์ FID ทันที 96% โดยโหลด JavaScript ขนาด 267 KB (เปอร์เซ็นไทล์ที่ 38 ใน HTTP Archive) และประมวลผลเป็นเวลา 900 มิลลิวินาทีในเครื่องห้องทดลอง แถบแสดงตัวอย่างรูปภาพแสดงให้เห็นว่าหน้าใช้เวลาประมาณ 5 วินาทีเพื่อระบายสีพื้นหลัง และอีกประมาณ 2 วินาทีเพื่อระบายสีเนื้อหา

WebPageTest Waterfall ของ wtfast.com

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

เริ่มสำรวจ

คุณดูข้อมูลเพิ่มเติมเกี่ยวกับ FID ได้ใน The State of the Web ตอนของสัปดาห์นี้

การมี FID ในรายงาน UX ของ Chrome ช่วยให้เราสร้างพื้นฐานประสบการณ์การโต้ตอบได้ ด้วยการใช้เกณฑ์พื้นฐานนี้ เราสามารถสังเกตเห็นการเปลี่ยนแปลงใน การเผยแพร่ในอนาคตหรือการเปรียบเทียบต้นทางแต่ละรายการ หากต้องการเริ่มรวบรวม FID ในการวัดผลในเว็บไซต์ของคุณเอง ให้ลงชื่อสมัครใช้ช่วงทดลองใช้จากต้นทางโดยไปที่ bit.ly/event-timing-ot แล้วเลือกฟีเจอร์ระยะเวลาของเหตุการณ์ และแน่นอนว่า ให้เริ่มสำรวจชุดข้อมูลเพื่อดูข้อมูลเชิงลึกที่น่าสนใจเกี่ยวกับสถานะการโต้ตอบในเว็บ เมตริกนี้ยังคงเป็นเมตริกทดลอง ดังนั้นโปรดแสดงความคิดเห็นและแชร์การวิเคราะห์ในกลุ่มสนทนาเกี่ยวกับรายงาน UX ของ Chrome หรือ @ChromeUX Report ใน Twitter