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

เป้าหมายของรายงานประสบการณ์ของผู้ใช้ Chrome คือการช่วยให้ชุมชนเว็บเข้าใจการกระจายและพัฒนาประสิทธิภาพจริงของผู้ใช้ จนถึงตอนนี้ เรามุ่งเน้นที่เมตริก Paint และการโหลดหน้าเว็บ เช่น 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 1 เดือนจากแหล่งที่มาหลายล้านแห่งมีข้อมูลเชิงลึกที่น่าสนใจมากมายให้คุณค้นพบ มาดูตัวอย่างการค้นหา 2-3 รายการที่แสดงวิธีดึงข้อมูลเชิงลึกเหล่านี้จากรายงาน 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'

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

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 มิลลิวินาที ดังนั้น developers.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 นอกขอบเขตของรายงาน Chrome UX

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

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

แถบแสดงตัวอย่างรูปภาพ WebPageTest ของ secretlycanadian.com

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

Waterfall WebPageTest ของ wtfast.com

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

เริ่มสำรวจ

ดูข้อมูลเพิ่มเติมเกี่ยวกับ FID ได้ในสถานะของเว็บตอนล่าสุด

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