First Input Delay (FID)

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

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

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

แม้เราจะวัดว่าผู้ใช้ชื่นชอบการออกแบบของเว็บไซต์ด้วย Web API ได้ยากมากแค่ไหน แต่การวัดความเร็วและการตอบสนองก็ไม่ใช่เรื่องง่าย

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

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

FID คืออะไร

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

คะแนน FID ที่ดีคืออะไร

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

รายละเอียดเกี่ยวกับ FID

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

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

พิจารณาลำดับเวลาต่อไปนี้ของการโหลดหน้าเว็บทั่วไป

ภาพด้านบนแสดงหน้าเว็บที่ส่งคำขอเครือข่าย 2 รายการสำหรับทรัพยากร (ส่วนใหญ่เป็นไฟล์ CSS และ JS) และระบบจะประมวลผลทรัพยากรเหล่านั้นในเทรดหลักหลังจากที่ดาวน์โหลดทรัพยากรเหล่านั้นเสร็จแล้ว

เหตุการณ์นี้ส่งผลให้เกิดช่วงเวลาที่เทรดหลักไม่ว่างชั่วขณะ ซึ่งจะสังเกตได้จากบล็อกงานสีเบจ

โดยปกติแล้วความล่าช้าในการป้อนข้อมูลครั้งแรกนานๆ จะเกิดขึ้นระหว่าง First Contentful Paint (FCP) และ Time to Interactive (TTI) เนื่องจากหน้าเว็บแสดงเนื้อหาบางส่วนแล้วแต่ยังไม่เป็นแบบอินเทอร์แอกทีฟที่น่าเชื่อถือ เราได้เพิ่ม FCP และ TTI ลงในไทม์ไลน์เพื่อให้เห็นภาพว่าปัญหานี้เกิดขึ้นได้อย่างไร

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

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

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

จะเกิดอะไรขึ้นหากการโต้ตอบไม่มี Listener เหตุการณ์

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

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

• ช่องข้อความ ช่องทำเครื่องหมาย และปุ่มตัวเลือก (<input>, <textarea>)
• เลือกเมนูแบบเลื่อนลง (<select>)
• ลิงก์ (<a>)

ทำไมจึงควรพิจารณาเฉพาะอินพุตแรก

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

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

สิ่งใดที่นับเป็นอินพุตแรก

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

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

กล่าวอีกนัยหนึ่งคือ FID จะมุ่งเน้นที่ R (การตอบสนอง) ในโมเดลประสิทธิภาพ RAIL ขณะที่การเลื่อนและซูมจะเกี่ยวข้องกับ A (ภาพเคลื่อนไหว) มากกว่า และควรประเมินคุณภาพประสิทธิภาพแยกกัน

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

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

ซึ่งหมายความว่าผู้ใช้บางรายจะไม่มีค่า FID ผู้ใช้บางรายจะมีค่า FID ต่ำ และผู้ใช้บางคนอาจมีค่า FID สูง

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

เหตุใดจึงพิจารณาเฉพาะความล่าช้าของอินพุต

ดังที่กล่าวไว้ข้างต้น FID จะวัดเฉพาะ "ความล่าช้า" ในการประมวลผลเหตุการณ์เท่านั้น แต่จะไม่วัดเวลาประมวลผลเหตุการณ์เอง หรือเวลาที่เบราว์เซอร์ใช้ในการอัปเดต UI หลังจากเรียกใช้ตัวแฮนเดิลเหตุการณ์

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

อย่างไรก็ตาม แม้ว่า FID จะวัดเฉพาะส่วนที่ "ล่าช้า" ของเวลาในการตอบสนองเหตุการณ์เท่านั้น แต่นักพัฒนาแอปที่ต้องการติดตามวงจรเหตุการณ์มากขึ้นก็ทําได้โดยใช้ Event Timing API ดูรายละเอียดเพิ่มเติมในคำแนะนำเกี่ยวกับเมตริกที่กำหนดเอง

วิธีวัด FID

FID คือเมตริกที่วัดได้ในช่องเท่านั้น เนื่องจากต้องใช้ผู้ใช้จริงในการโต้ตอบกับหน้าเว็บ คุณวัด FID ได้ด้วยเครื่องมือต่อไปนี้

เครื่องมือภาคสนาม

• รายงานประสบการณ์ของผู้ใช้ Chrome
• PageSpeed Insights
• Search Console (รายงาน Core Web Vitals)
• ไลบรารี JavaScript web-vitals รายการ

วัด FID ใน JavaScript

หากต้องการวัด FID ใน JavaScript ให้ใช้ Event Timing API ตัวอย่างต่อไปนี้แสดงวิธีสร้าง PerformanceObserver ที่รับข้อมูลรายการ first-input และบันทึกไว้ในคอนโซล

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

ในตัวอย่างข้างต้น ค่าความล่าช้าของรายการ first-input วัดโดยใช้เดลต้าระหว่างการประทับเวลา startTime กับ processingStart ของรายการ ในกรณีส่วนใหญ่ ค่านี้จะเป็นค่า FID แต่รายการ first-input บางรายการอาจใช้ไม่ได้กับการวัด FID

ส่วนต่อไปนี้แสดงความแตกต่างระหว่างรายงาน API และวิธีคำนวณเมตริก

ความแตกต่างระหว่างเมตริกกับ API

• API จะส่ง first-input รายการสำหรับหน้าที่โหลดในแท็บเบื้องหลัง แต่ระบบจะไม่สนใจหน้าเหล่านั้นเมื่อคำนวณ FID
• นอกจากนี้ API จะส่งรายการ first-input ไปให้หากหน้าเว็บอยู่ในเบื้องหลังก่อนที่จะมีอินพุตแรกเกิดขึ้น แต่ระบบจะไม่สนใจหน้าเว็บเหล่านั้นเมื่อคำนวณ FID (ระบบจะพิจารณาอินพุตก็ต่อเมื่อหน้าเว็บอยู่เบื้องหน้าตลอดเวลา)
• API ไม่รายงานรายการ first-input เมื่อกู้คืนหน้าจาก Back/Forward Cache แต่ควรวัด FID ในกรณีเหล่านี้เนื่องจากผู้ใช้พบว่าเป็นการเข้าชมหน้าเว็บที่ต่างกัน
• API จะไม่รายงานอินพุตที่เกิดขึ้นภายใน iframe แต่เมตริกดังกล่าวรายงานเนื่องจากเป็นส่วนหนึ่งของประสบการณ์ของผู้ใช้หน้าเว็บ ข้อมูลนี้แสดงให้เห็นถึงความแตกต่างระหว่าง CrUX กับ RUM คุณควรพิจารณา FID เพื่อวัด FID อย่างเหมาะสม เฟรมย่อยจะใช้ API เพื่อรายงานรายการ first-input ไปยังเฟรมหลักเพื่อการรวมได้

แทนที่จะจดจำความแตกต่างที่ลึกซึ้งเหล่านี้ทั้งหมด นักพัฒนาแอปสามารถใช้web-vitalsไลบรารี JavaScript เพื่อวัด FID ซึ่งจะจัดการกับความแตกต่างเหล่านี้ให้คุณ (หากทำได้ โปรดทราบว่าปัญหานี้ไม่ครอบคลุม iframe)

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

คุณสามารถดูตัวอย่างวิธีวัด FID ใน JavaScript ได้จากซอร์สโค้ดของ onFID()

การวิเคราะห์และการรายงานเกี่ยวกับข้อมูล FID

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

แม้ว่าตัวเลือกเปอร์เซ็นต์ไทล์สำหรับเกณฑ์ Core Web Vitals ทั้งหมดคืออันดับที่ 75 แต่สำหรับ FID เรายังคงขอแนะนำให้ดูที่เปอร์เซ็นไทล์ที่ 95-99 เนื่องจากตัวเลขเหล่านี้จะสอดคล้องกับประสบการณ์แรกที่ไม่ดีเป็นพิเศษที่ผู้ใช้เจอกับเว็บไซต์ของคุณ และจะแสดงจุดที่ต้องปรับปรุงมากที่สุด

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

วิธีปรับปรุง FID

คู่มือฉบับเต็มเกี่ยวกับการเพิ่มประสิทธิภาพ FID มีเพื่อแนะนำเทคนิคในการปรับปรุงเมตริกนี้

บันทึกการเปลี่ยนแปลง

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

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

หากคุณมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ คุณสามารถให้ข้อมูลไว้ในกลุ่ม Google web-vitals-feedback