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

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

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

วิธีวัด FID

แล้ว FID คืออะไรกันแน่ คำนิยามของ URL ใน ความล่าช้าในการอินพุตครั้งแรก บล็อกโพสต์ประกาศ:

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-3 อย่างที่มีประสิทธิภาพดีกัน

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

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

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

Waterfall WebPageTest ของ wtfast.com

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

เริ่มสำรวจ

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับ FID ได้ในรายการ The State of the Web ประจำสัปดาห์นี้

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