First Input Delay (FID)

Philip Walton

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

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

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

แม้ว่าการวัดว่าผู้ใช้ชอบการออกแบบเว็บไซต์ด้วย Web API มากน้อยเพียงใดได้ยาก แต่การวัดความเร็วและการตอบสนองนั้นไม่ง่ายอย่างที่คิด

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

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

FID คืออะไร

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

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

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

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

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

เหตุใดจึงควรพิจารณาเฉพาะอินพุตแรก

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

• ความล่าช้าในการป้อนข้อมูลครั้งแรกจะเป็นความประทับใจแรกของผู้ใช้เกี่ยวกับความตอบสนองของเว็บไซต์ และการแสดงผลครั้งแรกเป็นสิ่งสําคัญในการสร้างภาพรวมเกี่ยวกับคุณภาพและความน่าเชื่อถือของเว็บไซต์
• ปัญหาการโต้ตอบที่ใหญ่ที่สุดที่เราพบบนเว็บในปัจจุบันเกิดขึ้นระหว่างการโหลดหน้าเว็บ ดังนั้น เราเชื่อว่าการมุ่งความสนใจไปที่การปรับปรุงการโต้ตอบของผู้ใช้ครั้งแรกของเว็บไซต์จะส่งผลกระทบต่อการปรับปรุงการโต้ตอบโดยรวมของเว็บมากที่สุด
• โซลูชันที่แนะนำสำหรับวิธีที่เว็บไซต์ควรแก้ไขความล่าช้าในอินพุตครั้งแรกสูง (การแยกโค้ด การโหลด 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)
• web-vitals ไลบรารี JavaScript

วัด 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 เพื่อวัดค่าที่เหมาะสม เฟรมย่อยสามารถใช้ API เพื่อรายงานรายการ first-input ไปยังเฟรมหลักเพื่อรวบรวมข้อมูล

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

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

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

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

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

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

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

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

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

หากมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ โปรดแสดงความคิดเห็นในกลุ่ม Google สำหรับ Web Vitals Feedback