First Input Delay (FID)

Philip Walton

การรองรับเบราว์เซอร์

  • Chrome: 76
  • Edge: 79
  • Firefox: 89
  • Safari: ไม่รองรับ

แหล่งที่มา

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

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

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

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

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

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

FID คืออะไร

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

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

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

ค่า FID ที่ดีคือ 2.5 วินาทีหรือน้อยกว่า ค่าที่ไม่ดีคือมากกว่า 4.0 วินาที และค่าที่อยู่ตรงกลางนั้นต้องปรับปรุง

รายละเอียด FID

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

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

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

ตัวอย่างการติดตามการโหลดหน้าเว็บ

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

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

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

ตัวอย่างการติดตามการโหลดหน้าเว็บที่มี FCP และ TTI

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

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

ตัวอย่างการติดตามการโหลดหน้าเว็บที่มี FCP, TTI และ FID

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

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

วัด 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 เมื่อมีการกู้คืนหน้าเว็บจากแคชย้อนกลับ/ไปข้างหน้า แต่ควรวัด 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