First Input Delay (FID)

Philip Walton

Browser Support

• 76
• 79
• 89
• 26.2

Source

คำเตือน: ความล่าช้าในการอินพุตครั้งแรก (FID) ไม่ใช่ Core Web Vitals อีกต่อไป และเมตริกการโต้ตอบกับ Next Paint (INP) ได้เข้ามาแทนที่แล้ว ด้วยเหตุนี้ การรองรับ FID จึงสิ้นสุดลง ในวันที่ 9 กันยายน 2024 ตอนนี้คุณควรให้ความสำคัญกับ INP

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

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

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

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

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

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

FID คืออะไร

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

คะแนน FID ที่ดีคือเท่าใด

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

หมายเหตุ: หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการวิจัยและวิธีการที่อยู่เบื้องหลังคำแนะนำนี้ โปรดดู: การกำหนดเกณฑ์เมตริก Core Web Vitals

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

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

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

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

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

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

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

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

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

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

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

หมายเหตุ: ในตัวอย่างนี้ ผู้ใช้โต้ตอบกับหน้าเว็บในช่วงเริ่มต้นของช่วงเวลาที่เธรดหลักทำงานมากที่สุด หากผู้ใช้โต้ตอบกับหน้าเว็บก่อนหน้านี้เพียงเล็กน้อย (ในช่วงเวลาที่ไม่มีการใช้งาน) เบราว์เซอร์จะตอบสนองได้ทันที ความแตกต่างของความล่าช้าในการอินพุตนี้เน้นย้ำถึงความสำคัญของการดูการกระจายค่า FID เมื่อรายงานเมตริก อ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในส่วนด้านล่างเกี่ยวกับการวิเคราะห์และการรายงานข้อมูล 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 จะวัดเฉพาะส่วน "ความล่าช้า" ของเวลาในการตอบสนองของเหตุการณ์ แต่หากนักพัฒนาแอป ที่ต้องการติดตามวงจรชีวิตของเหตุการณ์เพิ่มเติม ก็สามารถทำได้โดยใช้ Event Timing API ดูรายละเอียดเพิ่มเติมได้ในคู่มือเกี่ยวกับcustom metrics

วิธีวัด FID

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

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

ในตัวอย่างด้านบน ระบบจะวัดค่าความล่าช้าของรายการ 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 ไปยังเฟรมหลักเพื่อทำการรวบรวม

หมายเหตุ: ในบางกรณี (เช่น iframe ข้ามต้นทาง) คุณจะวัด 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