เราต่างทราบกันดีว่าความประทับใจแรกที่ดีนั้นสำคัญเพียงใด เป็นสิ่งสำคัญ เมื่อพบปะผู้คนใหม่ๆ และสิ่งสำคัญอีกอย่างในการสร้างประสบการณ์ ผ่านเว็บได้
ความประทับใจแรกที่ดีบนเว็บสร้างความแตกต่างระหว่างผู้ใช้แต่ละคนได้ จนกลายเป็นผู้ใช้ที่ภักดี หรือพวกเขา จากไปและไม่กลับมาอีกเลย คำถามก็คือ สิ่งใดทำให้เกิดความประทับใจที่ดี และคุณจะวัดประเภทการแสดงผลได้อย่างไร ที่คุณจะได้รับจากผู้ใช้
บนเว็บ ความประทับใจแรกอาจมีหลายรูปแบบ ความประทับใจแรกต่อการออกแบบและรูปลักษณ์ ของเว็บไซต์ รวมถึง ของความเร็วและการตอบสนอง
แม้จะวัดว่าผู้ใช้ชอบการออกแบบเว็บไซต์ด้วย 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) และเวลาในการตอบสนอง (TTI) เนื่องจากหน้าเว็บมี แสดงผลเนื้อหาบางส่วน แต่ยังไม่โต้ตอบได้อย่างถูกต้อง เพื่อเป็นภาพประกอบ จึงได้เพิ่ม FCP และ TTI ลงในไทม์ไลน์ ดังนี้
คุณอาจสังเกตเห็นว่ามีระยะเวลาพอสมควร (รวมถึงระยะ งาน) ระหว่าง FCP และ TTI หากผู้ใช้พยายาม การโต้ตอบกับหน้าเว็บในระหว่างนั้น (ตัวอย่างเช่น การคลิกลิงก์) จะมี ความล่าช้าระหว่างเวลาที่ได้รับการคลิกและเวลาที่เทรดหลักทําได้ ตอบกลับ
ลองพิจารณาว่าจะเกิดอะไรขึ้นหากผู้ใช้พยายามโต้ตอบกับหน้าเว็บใกล้กับ จุดเริ่มต้นของงานที่ยาวที่สุด
เนื่องจากอินพุตนี้เกิดขึ้นขณะที่เบราว์เซอร์กำลังทำงาน งานนั้นจะต้องรอจนกระทั่งงานเสร็จสมบูรณ์ก่อน จึงจะตอบสนองต่ออินพุตได้ เวลาที่ต้องรอคือค่า FID สำหรับผู้ใช้รายนี้ในหน้านี้
จะเกิดอะไรขึ้นหากการโต้ตอบไม่มี Listener เหตุการณ์
FID จะวัดเดลต้าระหว่างเมื่อได้รับเหตุการณ์อินพุตและเมื่อเหตุการณ์อินพุตหลัก ชุดข้อความถัดไปจะไม่มีการใช้งาน ซึ่งหมายความว่าจะมีการวัด FID แม้ในกรณีที่เหตุการณ์ Listener ยังไม่ได้ลงทะเบียน เนื่องจากผู้ใช้มีการโต้ตอบหลายครั้ง ไม่จำเป็นต้องมี Listener เหตุการณ์ แต่ต้องกำหนดให้เทรดหลักไม่มีการใช้งานใน เพื่อให้ทำงาน
ตัวอย่างเช่น องค์ประกอบ HTML ต่อไปนี้ทั้งหมดจะต้องรอ งานที่อยู่ระหว่างดำเนินการในเทรดหลักที่ต้องทำให้เสร็จก่อนตอบกลับผู้ใช้ การโต้ตอบ:
- ช่องข้อความ ช่องทำเครื่องหมาย และปุ่มตัวเลือก (
<input>,<textarea>) - เลือกเมนูแบบเลื่อนลง (
<select>) - ลิงก์ (
<a>)
เหตุใดจึงควรพิจารณาเฉพาะอินพุตแรก
แม้ความล่าช้าจากข้อมูลใดก็ตามอาจทำให้ผู้ใช้ได้รับประสบการณ์ที่ไม่ดี แต่เรา เราขอแนะนำให้วัดความล่าช้าในการอินพุตครั้งแรกด้วยเหตุผล 2-3 ประการ
- ความล่าช้าในการป้อนข้อมูลครั้งแรกคือความประทับใจแรกของผู้ใช้ที่มีต่อ เว็บไซต์ของคุณ การตอบสนองและความประทับใจแรก จึงเป็นสิ่งสำคัญในการกำหนด คุณภาพและความน่าเชื่อถือของเว็บไซต์
- ปัญหาการโต้ตอบที่ใหญ่ที่สุดที่เราพบในเว็บทุกวันนี้เกิดขึ้นระหว่างหน้าเว็บ โหลด ดังนั้น เราเชื่อว่าในช่วงแรกจะมุ่งเน้นที่การปรับปรุงผู้ใช้รายแรกของเว็บไซต์ จะมีผลกระทบมากที่สุด ในการปรับปรุง การโต้ตอบของเว็บ
- โซลูชันที่แนะนำสำหรับวิธีที่เว็บไซต์ควรแก้ไขความล่าช้าในการอินพุตครั้งแรกสูง (การแยกโค้ด การโหลด JavaScript ล่วงหน้าน้อยลง ฯลฯ) อาจไม่จำเป็นเสมอไป โซลูชันเดียวกันสำหรับการแก้ไขความล่าช้าของอินพุตช้าหลังจากการโหลดหน้าเว็บ ด้วยการแยก เมตริกเหล่านี้จะช่วยให้เราแสดงประสิทธิภาพที่เฉพาะเจาะจงมากขึ้นได้ หลักเกณฑ์สำหรับนักพัฒนาเว็บ
สิ่งใดที่นับเป็นอินพุตแรก
FID เป็นเมตริกที่วัดการตอบสนองของหน้าเว็บระหว่างการโหลด ด้วยเหตุนี้จึงทำให้ โฟกัสเฉพาะเหตุการณ์การป้อนข้อมูลจากการดำเนินการที่แยกกันอย่างการคลิก การแตะ และการกดแป้น กด
การโต้ตอบอื่นๆ เช่น การเลื่อนและการซูม เป็นการทำงานแบบต่อเนื่องและมี และข้อจำกัดด้านประสิทธิภาพที่แตกต่างออกไปจากเดิมอย่างสิ้นเชิง (นอกจากนี้เบราว์เซอร์ยังสามารถ ซ่อนเวลาในการตอบสนองด้วยการเรียกใช้ในชุดข้อความแยกต่างหาก)
ในอีกแง่หนึ่ง FID จะโฟกัสที่ R (การตอบสนอง) ใน RAIL การแสดง โมเดล ขณะที่ การเลื่อนและการซูมมีความเกี่ยวข้องกับ A (ภาพเคลื่อนไหว) และประสิทธิภาพของการแสดงผลมากกว่า คุณควรประเมินคุณภาพแยกกัน
จะเกิดอะไรขึ้นหากผู้ใช้ไม่เคยโต้ตอบกับเว็บไซต์ของคุณเลย
ผู้ใช้บางรายจะไม่โต้ตอบกับเว็บไซต์ของคุณทุกครั้งที่เข้าชม และไม่ใช่ทั้งหมด การโต้ตอบเหล่านั้นเกี่ยวข้องกับ FID (ดังที่กล่าวไว้ในส่วนก่อนหน้า) ใน นอกจากนี้ การโต้ตอบครั้งแรกของผู้ใช้บางส่วนจะอยู่ในช่วงเวลาที่ไม่ดี (เมื่อ ชุดข้อความไม่ว่างเป็นเวลานาน) และผู้ใช้บางส่วนเป็นคนแรก การโต้ตอบจะเป็นไปในเวลาที่เหมาะเจาะ (เมื่อเทรดหลักไม่มีการใช้งานเลย)
ซึ่งหมายความว่าผู้ใช้บางรายจะไม่มีค่า FID ส่วนผู้ใช้บางรายจะมี FID ต่ำ และผู้ใช้บางรายอาจมีค่า FID สูง
วิธีติดตาม รายงาน และวิเคราะห์ FID อาจแตกต่างไปเล็กน้อย จากเมตริกอื่นๆ ที่คุณอาจคุ้นเคย ส่วนถัดไปจะอธิบายถึงสิ่งที่ควรทำ นี้
เหตุใดจึงควรพิจารณาแค่ความล่าช้าของอินพุต
ดังที่กล่าวไว้ข้างต้น FID จะวัดเฉพาะ “ความล่าช้า” เท่านั้น ในการประมวลผลเหตุการณ์ ใช่เลย ไม่ได้วัดระยะเวลาการประมวลผลเหตุการณ์ทั้งหมด หรือระยะเวลาที่ใช้ เบราว์เซอร์เพื่ออัปเดต UI หลังจากเรียกใช้เครื่องจัดการเหตุการณ์
แม้ว่าช่วงเวลานี้จะสำคัญต่อผู้ใช้และส่งผลต่อประสบการณ์การใช้งาน
เมตริกนี้ไม่ได้รวมอยู่ในเมตริกนี้ เนื่องจากอาจสร้างแรงจูงใจให้นักพัฒนาแอป
เพิ่มวิธีแก้ปัญหาเบื้องต้น
ซึ่งจะทำให้ประสบการณ์แย่ลง ซึ่งก็คือ
สามารถรวมตรรกะเครื่องจัดการเหตุการณ์ใน Callback แบบไม่พร้อมกัน (ผ่าน
setTimeout() หรือ requestAnimationFrame()) เพื่อแยกออกจาก
งานที่เชื่อมโยงกับเหตุการณ์ ผลลัพธ์คือเมตริกที่ดีขึ้น
แต่ตอบสนองช้าตามที่ผู้ใช้รับรู้
อย่างไรก็ตาม แม้ว่า FID จะวัดเฉพาะ “ความล่าช้า” ส่วนของเวลาในการตอบสนองของกิจกรรม หากต้องการติดตามวงจรเหตุการณ์เพิ่มเติม สามารถทำได้โดยใช้ระยะเวลาของเหตุการณ์ API ดูคู่มือเกี่ยวกับที่กำหนดเอง เมตริกเพื่อดูรายละเอียดเพิ่มเติม
วิธีวัด FID
FID เป็นเมตริกที่สามารถวัดได้ใน ฟิลด์ เพราะต้องมีฟิลด์ โต้ตอบกับหน้าเว็บของคุณ คุณวัด FID ได้โดยใช้เครื่องมือต่อไปนี้
เครื่องมือภาคสนาม
- ประสบการณ์ของผู้ใช้ Chrome รายงาน
- PageSpeed Insights
- Search Console (Core Web Vitals) รายงาน)
- ไลบรารี JavaScript
web-vitalsรายการ
วัด FID ใน JavaScript
หากต้องการวัด FID ใน JavaScript คุณสามารถใช้ระยะเวลาของเหตุการณ์ได้
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ไปยังเฟรมหลักสำหรับการรวม
แทนที่จะต้องคอยจดจำความแตกต่างเล็กๆ น้อยๆ เหล่านี้ นักพัฒนาซอฟต์แวร์สามารถใช้
ไลบรารี JavaScript web-vitals รายการเพื่อ
วัด FID ซึ่งจัดการความแตกต่างเหล่านี้ให้คุณ (หากเป็นไปได้ โปรดทราบว่าปัญหา iframe ไม่ครอบคลุม)
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
คุณสามารถดูซอร์สโค้ดสำหรับ
onFID()
เพื่อดูตัวอย่างที่สมบูรณ์เกี่ยวกับวิธีวัด FID ใน JavaScript
การวิเคราะห์และการรายงานข้อมูล FID
เนื่องจากความแปรปรวนที่คาดไว้ของค่า FID จึงจำเป็นอย่างยิ่งที่เมื่อมีการรายงานเกี่ยวกับ FID จะดูที่การกระจายของค่าและมุ่งเน้นไปที่เปอร์เซ็นต์ไทล์ที่สูงกว่า
ขณะที่ตัวเลือก เปอร์เซ็นไทล์ของทั้ง เกณฑ์ของ Core Web Vitals เป็นเกณฑ์ที่ 75 โดยสำหรับ FID นั้นเรายังคง ขอแนะนำให้ดูเปอร์เซ็นต์ไทล์ที่ 95-99 เนื่องจากจะสอดคล้องกับ โดยเฉพาะอย่างยิ่ง ประสบการณ์ครั้งแรกที่ไม่ดีซึ่งผู้ใช้เกิดกับเว็บไซต์ของคุณ และจะ จะแสดงด้านที่ต้องปรับปรุงมากที่สุด
และจะเป็นเช่นนี้เสมอแม้ว่าคุณจะแบ่งกลุ่มรายงานตามหมวดหมู่หรือประเภทอุปกรณ์ก็ตาม สำหรับ เช่น หากเรียกใช้รายงานในเดสก์ท็อปและอุปกรณ์เคลื่อนที่แยกกัน ค่า FID ที่คุณ ผู้ใช้เดสก์ท็อปควรอยู่ในเปอร์เซ็นไทล์ที่ 95-99 ของผู้ใช้เดสก์ท็อป และค่า FID ที่คุณสนใจมากที่สุดบนอุปกรณ์เคลื่อนที่ควรเป็นตัวเลขที่ 95-99 เปอร์เซ็นไทล์ของผู้ใช้อุปกรณ์เคลื่อนที่
วิธีปรับปรุง FID
คู่มือฉบับเต็มเกี่ยวกับการเพิ่มประสิทธิภาพ FID มีไว้เพื่อแนะนำเทคนิคในการปรับปรุงเมตริกนี้
บันทึกการเปลี่ยนแปลง
บางครั้งอาจพบข้อบกพร่องใน API ที่ใช้ในการวัดเมตริก และบางครั้งอาจพบข้อบกพร่องในคำจำกัดความของเมตริกเอง ด้วยเหตุนี้ บางครั้งจึงอาจต้องมีการเปลี่ยนแปลง และการเปลี่ยนแปลงเหล่านี้อาจแสดงเป็นการปรับปรุงหรือความถดถอยในรายงานภายในและแดชบอร์ดของคุณ
การเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับการใช้งานหรือคำจำกัดความของเมตริกเหล่านี้จะปรากฏในบันทึกการเปลี่ยนแปลงนี้เพื่อช่วยคุณจัดการเรื่องนี้
หากมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ ให้ระบุในกลุ่ม Google Web-vitals-feedback