ทำความเข้าใจว่าเมตริก INP ใหม่ส่งผลต่อประสบการณ์การใช้งานเว็บไซต์ที่สร้างขึ้นโดยใช้เฟรมเวิร์กและไลบรารี JavaScript อย่างไร
เมื่อเร็วๆ นี้ Chrome ได้เปิดตัวเมตริกการตอบสนองเวอร์ชันทดลองใหม่ในรายงานรายงาน UX ของ Chrome เมตริกนี้ ซึ่งตอนนี้เราเรียกว่าการโต้ตอบกับ Next Paint (INP) จะวัดการตอบสนองโดยรวมต่อการโต้ตอบของผู้ใช้ในหน้าเว็บ วันนี้เราต้องการแชร์ข้อมูลเชิงลึกเกี่ยวกับจุดยืนของเว็บไซต์ที่สร้างขึ้นโดยใช้เฟรมเวิร์ก JavaScript สมัยใหม่ เราต้องการหารือว่าเหตุใด INP ถึงเกี่ยวข้องกับเฟรมเวิร์ก และ Aurora และเฟรมเวิร์กทำงานอย่างไรเพื่อเพิ่มประสิทธิภาพการตอบสนอง
ข้อมูลเบื้องต้น
Chrome ใช้ First Input Delay (FID) เป็นส่วนหนึ่งของ Core Web Vitals (CWV) เพื่อวัดการตอบสนองในการโหลดของเว็บไซต์ FID จะวัดระยะเวลาที่รอตั้งแต่การโต้ตอบครั้งแรกของผู้ใช้ไปจนถึงช่วงเวลาที่เบราว์เซอร์ประมวลผลเครื่องจัดการเหตุการณ์ที่เชื่อมต่อกับการโต้ตอบได้ โดยไม่รวมเวลาในการประมวลผลเครื่องจัดการเหตุการณ์ ประมวลผลการโต้ตอบที่ตามมาในหน้าเดียวกัน หรือระบายสีเฟรมถัดไปหลังจากที่เรียกใช้ Callback ของเหตุการณ์แล้ว อย่างไรก็ตาม การตอบสนองมีความสำคัญต่อประสบการณ์ของผู้ใช้ตลอดวงจรของหน้า เนื่องจากผู้ใช้ใช้เวลาทั้งหมดประมาณ 90% บนหน้าเว็บหลังจากที่หน้าเว็บนั้นโหลดแล้ว
INP วัดระยะเวลาที่หน้าเว็บใช้ในการตอบสนองการโต้ตอบของผู้ใช้ ตั้งแต่ตอนที่ผู้ใช้เริ่มการโต้ตอบไปจนถึงเวลาการแสดงเฟรมถัดไปบนหน้าจอ เราหวังว่า INP จะช่วยให้สามารถวัดผลโดยรวมสำหรับเวลาในการตอบสนองที่รับรู้ของการโต้ตอบทั้งหมดในวงจรของหน้าเว็บ เราเชื่อว่า INP จะให้ค่าประมาณการที่แม่นยำมากขึ้นสำหรับหน้าเว็บ การตอบสนองของการโหลดและรันไทม์
เนื่องจาก FID วัดเฉพาะความล่าช้าในการป้อนข้อมูลของการโต้ตอบแรก มีแนวโน้มว่านักพัฒนาเว็บจะไม่ได้เพิ่มประสิทธิภาพการโต้ตอบที่เกิดขึ้นตามมาโดยเป็นส่วนหนึ่งของกระบวนการปรับปรุง CWV ของตน เว็บไซต์ โดยเฉพาะเว็บไซต์ที่มีการโต้ตอบในระดับสูง จึงต้องเริ่มต้นทำงานหนักเพื่อให้สามารถทำงานกับเมตริกนี้ได้ดี
บทบาทของเฟรมเวิร์ก
เนื่องจากเว็บไซต์จำนวนมากใช้ JavaScript ในการตอบสนอง คะแนน INP จึงได้รับผลกระทบจากจำนวน JavaScript ที่ประมวลผลในเทรดหลักเป็นหลัก เฟรมเวิร์ก JavaScript เป็นส่วนสำคัญของการพัฒนาเว็บฟรอนท์เอนด์สมัยใหม่ และช่วยให้นักพัฒนาซอฟต์แวร์มีบทคัดย่อที่มีค่าสำหรับการกำหนดเส้นทาง การจัดการเหตุการณ์ และการจัดแบ่งโค้ด JavaScript ด้วยเหตุนี้จึงมีบทบาทสำคัญในการเพิ่มประสิทธิภาพการตอบสนองและประสบการณ์ของผู้ใช้เว็บไซต์ที่ใช้การตอบสนองเหล่านั้น
เฟรมเวิร์กอาจดำเนินการปรับปรุงการตอบสนองที่ดีขึ้นโดยการปรับปรุง FID สำหรับเว็บไซต์ก่อนหน้านี้ อย่างไรก็ตาม ในตอนนี้ทางทีมจะต้องวิเคราะห์ข้อมูลเมตริกการตอบกลับที่พร้อมใช้งาน และดำเนินการแก้ไขช่องโหว่ใดๆ ที่ระบุไว้ โดยทั่วไปแล้ว INP มักจะมีอัตราการผ่านต่ำกว่า และความแตกต่างในกระบวนการวัดผลจำเป็นต้องมีการเพิ่มประสิทธิภาพโค้ดเพิ่มเติม ตารางต่อไปนี้จะสรุปสาเหตุ
ทีม Aurora ใน Chrome ทำงานร่วมกับเฟรมเวิร์กเว็บแบบโอเพนซอร์สเพื่อช่วยให้นักพัฒนาซอฟต์แวร์ปรับปรุงประสบการณ์ของผู้ใช้ในด้านต่างๆ รวมถึงประสิทธิภาพและเมตริก CWV เมื่อมีการเปิดตัว INP เราต้องการเตรียมพร้อมสำหรับการเปลี่ยนแปลงเมตริก CWV สำหรับเว็บไซต์ที่ใช้เฟรมเวิร์ก เราได้รวบรวมข้อมูลตามเมตริกการตอบสนองแบบทดลองในรายงาน CrUX เราจะแชร์ข้อมูลเชิงลึกและรายการการทำงานเพื่อช่วยให้การเปลี่ยนไปใช้เมตริก INP สำหรับเว็บไซต์ที่ใช้เฟรมเวิร์กง่ายขึ้น
ข้อมูลเมตริกการปรับเปลี่ยนตามอุปกรณ์แบบทดลอง
INP ที่ต่ำกว่าหรือเท่ากับ 200 มิลลิวินาทีหมายถึงการตอบสนองที่ดี ข้อมูลในรายงาน CrUX และรายงานเทคโนโลยี CWV ประจำเดือนมิถุนายน 2023 ให้ข้อมูลต่อไปนี้เกี่ยวกับการตอบสนองสำหรับเฟรมเวิร์ก JavaScript ยอดนิยม
ตารางจะแสดงเปอร์เซ็นต์ของต้นทางในแต่ละเฟรมเวิร์กที่มีคะแนนการตอบกลับที่ดี ตัวเลขเหล่านี้ช่วยได้มาก แต่อย่าลืมว่ายังมีสิ่งที่พัฒนาได้อีกมาก
JavaScript ส่งผลต่อ INP อย่างไร
ค่า INP ในฟิลด์นั้นสัมพันธ์กับเวลาทั้งหมดในการบล็อกโดยรวม (TBT) ที่สังเกตการณ์ในห้องทดลอง ซึ่งอาจหมายความว่าสคริปต์ใดๆ ที่บล็อกเทรดหลักเป็นเวลานานจะส่งผลเสียต่อ INP การเรียกใช้ JavaScript ปริมาณมากหลังการโต้ตอบอาจบล็อกเทรดหลักเป็นเวลานานและทําให้การตอบสนองต่อการโต้ตอบนั้นล่าช้า สาเหตุทั่วไปบางประการที่ทำให้เกิดการบล็อกสคริปต์มีดังนี้
JavaScript ที่ไม่ได้เพิ่มประสิทธิภาพ: โค้ดที่ซ้ำซ้อนหรือกลยุทธ์การแยกโค้ดและการโหลดที่ไม่ดีอาจทำให้ JavaScript ทำงานหนักเกินไปและบล็อกเทรดหลักเป็นเวลานาน การแยกโค้ด การโหลดแบบโพรเกรสซีฟ และการแยกงานที่ใช้เวลานานช่วยปรับปรุงเวลาในการตอบกลับได้อย่างมาก
สคริปต์ของบุคคลที่สาม: สคริปต์ของบุคคลที่สามซึ่งบางครั้งไม่จำเป็นต้องประมวลผลการโต้ตอบ (เช่น สคริปต์โฆษณา) อาจบล็อกเทรดหลักและทำให้เกิดความล่าช้าโดยไม่จำเป็น การให้ความสำคัญกับสคริปต์ที่สำคัญจะช่วยลดผลกระทบเชิงลบของสคริปต์ของบุคคลที่สามได้
ตัวแฮนเดิลเหตุการณ์หลายตัว: ตัวแฮนเดิลเหตุการณ์หลายตัวที่เชื่อมโยงกับทุกการโต้ตอบแต่ละครั้ง โดยแต่ละตัวจะเรียกใช้สคริปต์ที่แตกต่างกัน อาจรบกวนกันและกันและรวมกันทำให้เกิดความล่าช้านาน งานบางอย่างอาจไม่ใช่งานสำคัญและอาจตั้งเวลาไว้ใน Web Worker หรือเมื่อไม่มีการใช้งานเบราว์เซอร์
โอเวอร์เฮดของเฟรมเวิร์กในการจัดการเหตุการณ์: เฟรมเวิร์กอาจมีฟีเจอร์/ไวยากรณ์เพิ่มเติมสำหรับการจัดการเหตุการณ์ ตัวอย่างเช่น Vue ใช้ v-on เพื่อแนบ Listener เหตุการณ์กับองค์ประกอบ ในขณะที่ Angular จะรวมตัวแฮนเดิลเหตุการณ์ของผู้ใช้ การติดตั้งใช้งานฟีเจอร์เหล่านี้จำเป็นต้องมีโค้ดเฟรมเวิร์กเพิ่มเติมที่สูงกว่า JavaScript ประเภทวานิลลา
การชุ่มน้ำ: เมื่อใช้เฟรมเวิร์ก JavaScript เซิร์ฟเวอร์จะสร้าง HTML เริ่มต้นสำหรับหน้าเว็บ ซึ่งจะต้องเสริมด้วยเครื่องจัดการเหตุการณ์และสถานะแอปพลิเคชันเพื่อให้โต้ตอบได้ในเว็บเบราว์เซอร์ เราเรียกกระบวนการนี้ว่าน้ำที่ดื่ม ขั้นตอนนี้อาจมีงานหนักระหว่างการโหลด ขึ้นอยู่กับว่า JavaScript ใช้เวลาโหลดนานเท่าใดและต้องใช้เวลาจนหมด และยังทำให้หน้าเว็บดูเหมือนมีการโต้ตอบเมื่อไม่ได้โต้ตอบด้วย ภาวะน้ำในร่างกายมักเกิดขึ้นโดยอัตโนมัติระหว่างการโหลดหน้าเว็บหรือแบบ Lazy Loading (เช่น เมื่อมีการโต้ตอบของผู้ใช้) และอาจส่งผลต่อ INP หรือเวลาในการประมวลผลเนื่องจากการวางกำหนดเวลางาน ในไลบรารีต่างๆ เช่น React คุณสามารถใช้ประโยชน์จาก
useTransitionเพื่อให้การแสดงภาพคอมโพเนนต์บางส่วนอยู่ในเฟรมถัดไป และเหลือผลกระทบข้างเคียงที่มีค่าใช้จ่ายสูงไว้ในเฟรมในอนาคต ด้วยเหตุนี้ การอัปเดตในช่วงการเปลี่ยนผ่านที่มีผลต่อการอัปเดตที่เร่งด่วนมากขึ้น เช่น การคลิก อาจเป็นรูปแบบที่ส่งผลดีต่อ INPการดึงข้อมูลล่วงหน้า: การดึงข้อมูลทรัพยากรที่จำเป็นสำหรับการนำทางครั้งต่อๆ ไปในเชิงรุกอาจทำให้ประสิทธิภาพการทำงานดีขึ้นเมื่อทำถูกแล้ว อย่างไรก็ตาม หากคุณดึงข้อมูลล่วงหน้าและแสดงผลเส้นทาง SPA แบบพร้อมกัน คุณอาจได้รับผลเสียต่อ INP เนื่องจากการพยายามแสดงผลราคาแพงนี้ทั้งหมดให้เสร็จสิ้นในเฟรมเดียว ตรงข้ามกับให้ไม่ต้องดึงข้อมูลเส้นทางของคุณล่วงหน้า แต่เริ่มทำงานที่จำเป็น (เช่น
fetch()) แล้วเลิกบล็อกการแสดงผล เราขอแนะนำให้ตรวจสอบอีกครั้งว่าวิธีการดึงข้อมูลล่วงหน้าของเฟรมเวิร์กของคุณช่วยส่ง UX ที่ดีที่สุดหรือไม่ และอาจส่งผลต่อ INP อย่างไรบ้าง (หรือไม่ได้เลย)
จากนี้ไป นักพัฒนาซอฟต์แวร์จะต้องมุ่งเน้นที่การตรวจสอบโค้ดที่ทำงานหลังการโต้ตอบทุกครั้งบนหน้าเว็บ และเพิ่มประสิทธิภาพกลยุทธ์การแยกส่วน การเติมน้ำ การโหลด และขนาดของการอัปเดต Render() แต่ละครั้งสำหรับสคริปต์ของบุคคลที่หนึ่งและบุคคลที่สาม เพื่อให้ได้คะแนน INP ที่ดี
Aurora และเฟรมเวิร์กแก้ไขปัญหา INP อย่างไร
Aurora ทำงานร่วมกับเฟรมเวิร์กโดยนำแนวทางปฏิบัติแนะนำมาใช้เพื่อมอบโซลูชันที่ครบวงจรสำหรับปัญหาที่พบได้ทั่วไป เราทำงานร่วมกับ Next.js, Nuxt.js, Gatsby และ Angular ในโซลูชันที่มีค่าเริ่มต้นที่ดีภายในเฟรมเวิร์กเพื่อเพิ่มประสิทธิภาพ ไฮไลต์ในงานของเราในบริบทนี้มีดังต่อไปนี้
รีแอ็กชันและ Next.js: คอมโพเนนต์สคริปต์ Next.js จะช่วยแก้ไขปัญหาที่เกิดจากการโหลดสคริปต์ของบุคคลที่สามได้อย่างไม่มีประสิทธิภาพ มีการนำการแยกส่วนแบบละเอียดมาใช้ใน Next.js เพื่ออนุญาตให้มีส่วนเล็กๆ สำหรับโค้ดที่แชร์ วิธีนี้จะช่วยลดปริมาณโค้ดทั่วไปที่ไม่ได้ใช้ซึ่งดาวน์โหลดในทุกหน้า นอกจากนี้ เรายังทำงานกับ Next.js เพื่อทำให้ข้อมูล INP พร้อมใช้งานเป็นส่วนหนึ่งของบริการ Analytics
Angular: Aurora ทำงานร่วมกับทีม Angular เพื่อสำรวจการปรับปรุงการแสดงผลและการเติมน้ำในฝั่งเซิร์ฟเวอร์ นอกจากนี้ เรายังวางแผนที่จะตรวจสอบการปรับแต่งในการจัดการเหตุการณ์และการตรวจจับการเปลี่ยนแปลงเพื่อปรับปรุง INP อีกด้วย
Vue และ Nuxt.js: เรากำลังสำรวจช่องทางสำหรับการทำงานร่วมกัน ซึ่งส่วนใหญ่เกี่ยวข้องกับการโหลดและการแสดงผลสคริปต์
เฟรมเวิร์กมีความคิดอย่างไรเกี่ยวกับการปรับปรุง INP
React และ Next.js
time slicing ของ React.js ซึ่งติดตั้งใช้งานผ่าน startTransition และ Suspense จะช่วยให้คุณเลือกใช้น้ำที่ไหลแบบเลือกหรือแบบโพรเกรสซีฟได้ ซึ่งหมายความว่าปริมาณน้ำที่ดื่มไม่ได้เป็นบล็อกแบบซิงโครนัส โดยจะเป็นชิ้นส่วนเล็กๆ ที่ขัดจังหวะได้ทุกเมื่อ
วิธีนี้ควรช่วยปรับปรุง INP และช่วยให้คุณตอบสนองต่อการกดแป้นพิมพ์ เอฟเฟกต์เมื่อวางเมาส์ระหว่างการเปลี่ยน และการคลิกได้อย่างรวดเร็วยิ่งขึ้น นอกจากนี้ ยังช่วยให้แอป React ตอบสนองได้ดีแม้ในการเปลี่ยนขนาดใหญ่ เช่น การเติมข้อความอัตโนมัติ
Next.js ได้ใช้เฟรมเวิร์กการกำหนดเส้นทางใหม่ที่ใช้ startTransition โดยค่าเริ่มต้นสำหรับการเปลี่ยนเส้นทาง วิธีนี้จะช่วยให้เจ้าของเว็บไซต์ Next.js สามารถใช้การแบ่งเวลาของ React และปรับปรุงการตอบสนองของการเปลี่ยนเส้นทาง
Angular
ทีม Angular กำลังสำรวจแนวคิดต่างๆ ที่อาจช่วยเกี่ยวกับ INP ได้เช่นกัน:
- Zoneless: ลดขนาดแพ็กเกจเริ่มต้นและโค้ดที่จำเป็นซึ่งต้องโหลดก่อนที่แอปจะแสดงผลได้
- การขาดน้ำ: การดื่มน้ำแบบเกาะเพื่อจำกัดปริมาณการตื่นของแอปในการโต้ตอบ
- ลดค่าใช้จ่ายของ CD: ตัวอย่างเช่น ทำให้การตรวจหาการเปลี่ยนแปลงราคาถูกลง หาวิธีตรวจสอบแอปให้น้อยลง และใช้ประโยชน์จากสัญญาณเชิงรับเกี่ยวกับสิ่งที่มีการเปลี่ยนแปลง
- การแยกโค้ดที่ละเอียดยิ่งขึ้น: ทำให้แพ็กเกจเริ่มต้นมีขนาดเล็กลง
- การสนับสนุนที่ดีขึ้นสำหรับตัวบ่งชี้การโหลด: ตัวอย่างเช่น ระหว่างการแสดงผล SSR อีกครั้ง ระหว่างการนำทางเส้นทาง และการดำเนินการโหลดแบบ Lazy Loading
- เครื่องมือการทำโปรไฟล์: เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่ดีขึ้นซึ่งจะช่วยให้เข้าใจต้นทุนของการโต้ตอบ โดยเฉพาะเรื่องต้นทุนในการตรวจจับการเปลี่ยนแปลงสำหรับการโต้ตอบที่เฉพาะเจาะจง
การปรับปรุงเหล่านี้ช่วยให้เราแก้ปัญหาต่างๆ ซึ่งนำไปสู่การตอบสนองที่ไม่ดีและประสบการณ์ของผู้ใช้ รวมถึงเพิ่มเมตริก CWV และเมตริก INP ใหม่สำหรับเว็บไซต์ที่ใช้เฟรมเวิร์ก
บทสรุป
เราคาดว่าคะแนน INP จะเป็นแนวทางที่ดียิ่งขึ้นสำหรับเว็บไซต์ในการปรับปรุงการตอบสนองและประสิทธิภาพในอนาคต เราจะต่อยอดจากคู่มือ INP ที่มีอยู่เพื่อให้เคล็ดลับที่นําไปใช้ได้จริงเพิ่มเติมสําหรับนักพัฒนาเฟรมเวิร์กในปี 2023 เราหวังที่จะบรรลุเป้าหมายนี้โดย:
- การสร้างช่องสำหรับการเข้าถึงข้อมูลภาคสนามใน INP สำหรับเฟรมเวิร์กและนักพัฒนาเว็บได้ง่ายๆ
- ทำงานกับเฟรมเวิร์กเพื่อสร้างฟีเจอร์ที่จะปรับปรุง INP โดยค่าเริ่มต้น
เรายินดีรับฟังความคิดเห็นจากผู้ใช้เฟรมเวิร์กเมื่อเริ่มเส้นทางการเพิ่มประสิทธิภาพ INP