เฟรมเวิร์กสมัยใหม่ทำงานเป็นอย่างไรในเมตริก INP ใหม่

ทําความเข้าใจว่าเมตริก INP ใหม่ส่งผลต่อประสบการณ์การใช้งานเว็บไซต์ที่สร้างขึ้นโดยใช้เฟรมเวิร์กและไลบรารี JavaScript อย่างไร

Leena Sohoni

Addy Osmani

Keen Yee Liau

เมื่อเร็วๆ นี้ Chrome ได้เปิดตัวเมตริกการตอบสนองเวอร์ชันทดลองใหม่ในรายงาน Chrome UX Report เมตริกนี้ซึ่งปัจจุบันเรียกว่า Interaction to Next Paint (INP) จะวัดการตอบสนองโดยรวมต่อการโต้ตอบของผู้ใช้ในหน้าเว็บ วันนี้เราต้องการแชร์ข้อมูลเชิงลึกเกี่ยวกับตําแหน่งของเว็บไซต์ที่สร้างโดยใช้เฟรมเวิร์ก JavaScript สมัยใหม่เมื่อเทียบกับเมตริกนี้ เราต้องการพูดคุยถึงเหตุผลที่ INP เกี่ยวข้องกับเฟรมเวิร์ก และวิธีที่ Aurora และเฟรมเวิร์กทํางานเพื่อเพิ่มประสิทธิภาพการตอบสนอง

ฉากหลัง

Chrome ใช้ First Input Delay (FID) เป็นส่วนหนึ่งของ Core Web Vitals (CWV) เพื่อวัดการตอบสนองในการโหลดของเว็บไซต์ FID จะวัดเวลารอตั้งแต่การโต้ตอบครั้งแรกของผู้ใช้จนถึงเวลาที่เบราว์เซอร์ประมวลผลตัวแฮนเดิลเหตุการณ์ที่เชื่อมโยงกับการโต้ตอบได้ โดยไม่รวมเวลาในการประมวลผลตัวแฮนเดิลเหตุการณ์ ประมวลผลการโต้ตอบที่ตามมาในหน้าเดียวกัน หรือวาดเฟรมถัดไปหลังจากการเรียกเหตุการณ์ซ้ำทำงาน อย่างไรก็ตาม การตอบสนองเป็นปัจจัยสําคัญต่อประสบการณ์ของผู้ใช้ตลอดอายุการใช้งานของหน้าเว็บ เนื่องจากผู้ใช้ใช้เวลาประมาณ 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 ใช้ในการโหลดและเวลาในการทำให้สมบูรณ์ นอกจากนี้ยังอาจทําให้หน้าเว็บดูเหมือนเป็นแบบอินเทอร์แอกทีฟทั้งที่ไม่ใช่ บ่อยครั้งที่การไฮเดรตจะเกิดขึ้นโดยอัตโนมัติระหว่างการโหลดหน้าเว็บหรือแบบล่าช้า (เช่น ในการโต้ตอบของผู้ใช้) และอาจส่งผลต่อ INP หรือเวลาในการประมวลผลเนื่องจากการกำหนดเวลางาน ในไลบรารีอย่าง React คุณสามารถใช้ useTransition เพื่อให้การเรนเดอร์คอมโพเนนต์บางส่วนอยู่ในเฟรมถัดไป และแสดงผลผลข้างเคียงที่มีค่าใช้จ่ายสูงในเฟรมต่อๆ ไป ด้วยเหตุนี้ การอัปเดตในช่วงเปลี่ยนผ่านที่ทําให้เกิดอัปเดตเร่งด่วนมากขึ้น เช่น การคลิก จึงอาจเป็นรูปแบบที่เหมาะกับ INP

• การเรียกข้อมูลล่วงหน้า: การเรียกข้อมูลล่วงหน้าอย่างสม่ำเสมอสำหรับทรัพยากรที่จําเป็นสําหรับการนําทางในภายหลังอาจช่วยเพิ่มประสิทธิภาพได้หากทําอย่างถูกต้อง อย่างไรก็ตาม หากคุณทำการเตรียมข้อมูลล่วงหน้าและแสดงผลเส้นทาง SPA แบบซิงค์กัน อาจส่งผลเสียต่อ INP เนื่องจากการแสดงผลที่เสียค่าใช้จ่ายทั้งหมดนี้พยายามที่จะเสร็จสมบูรณ์ในเฟรมเดียว เปรียบเทียบกับกรณีที่ไม่ได้ทำการเตรียมเส้นทางล่วงหน้า แต่เริ่มทำงานที่จำเป็น (เช่น fetch()) และเลิกบล็อกสี เราขอแนะนําให้ตรวจสอบอีกครั้งว่าแนวทางของเฟรมเวิร์กในการโหลดล่วงหน้าให้ UX ที่ดีที่สุด และผลกระทบที่อาจเกิดขึ้นกับ INP (หากมี)

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

Aurora และเฟรมเวิร์กจัดการปัญหา INP อย่างไร

Aurora ทำงานร่วมกับเฟรมเวิร์กโดยรวมแนวทางปฏิบัติแนะนำเพื่อให้โซลูชันที่พร้อมใช้งานสำหรับปัญหาที่พบได้ทั่วไป เราได้ทํางานร่วมกับ Next.js, Nuxt.js, Gatsby และ Angular ในโซลูชันที่มีค่าเริ่มต้นที่มีประสิทธิภาพภายในเฟรมเวิร์กเพื่อเพิ่มประสิทธิภาพ ไฮไลต์ของงานของเราในบริบทนี้ ได้แก่

• React และ Next.js: คอมโพเนนต์สคริปต์ Next.js ช่วยแก้ไขปัญหาที่เกิดจากการโหลดสคริปต์ของบุคคลที่สามอย่างไม่มีประสิทธิภาพ การแบ่งออกเป็นหลายกลุ่มแบบละเอียดได้เปิดตัวใน Next.js เพื่ออนุญาตให้มีกลุ่มขนาดที่เล็กลงสำหรับโค้ดที่แชร์ ซึ่งจะช่วยลดจํานวนโค้ดทั่วไปที่ไม่ได้ใช้ซึ่งมีการดาวน์โหลดในทุกหน้า นอกจากนี้ เรายังทํางานร่วมกับ Next.js เพื่อให้ข้อมูล INP เป็นส่วนหนึ่งของบริการ Analytics ด้วย

• Angular: Aurora เป็นพาร์ทเนอร์กับทีม Angular เพื่อสำรวจการปรับปรุงการแสดงผลและการไฮเดรทฝั่งเซิร์ฟเวอร์ นอกจากนี้ เรายังมีแผนที่จะพิจารณาการปรับแต่งการจัดการเหตุการณ์และการตรวจหาการเปลี่ยนแปลงเพื่อปรับปรุง INP

• Vue และ Nuxt.js: เรากำลังสำรวจช่องทางต่างๆ สำหรับการทำงานร่วมกัน โดยเน้นที่การโหลดและการเรนเดอร์สคริปต์

เฟรมเวิร์กต่างๆ คิดอย่างไรเกี่ยวกับการปรับปรุง INP

React และ Next.js

การแบ่งเวลาของ React.js ซึ่งติดตั้งใช้งานผ่าน startTransition และ Suspense ช่วยให้คุณเลือกใช้การทำให้ชุ่มชื้นแบบเลือกสรรหรือแบบค่อยเป็นค่อยไปได้ ซึ่งหมายความว่าการไฮเดรตไม่ใช่บล็อกแบบซิงค์ โดยระบบจะดำเนินการเป็นขั้นตอนเล็กๆ ที่หยุดได้ทุกเมื่อ

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

Next.js ใช้เฟรมเวิร์กการกำหนดเส้นทางใหม่ที่ใช้ startTransition โดยค่าเริ่มต้นสำหรับการเปลี่ยนเส้นทาง ซึ่งช่วยให้เจ้าของเว็บไซต์ Next.js ใช้การแบ่งเวลาของ React และปรับปรุงการตอบสนองของการเปลี่ยนเส้นทางได้

Angular

ทีม Angular กำลังสำรวจแนวคิดหลายอย่างซึ่งน่าจะช่วยแก้ปัญหา INP ได้ด้วย

• ไม่มีโซน: ลดขนาด App Bundle เริ่มต้นและโค้ดที่จำเป็นซึ่งต้องโหลดก่อนที่แอปจะแสดงผลได้
• การเติมน้ำ: การเติมน้ำแบบเกาะเพื่อจำกัดปริมาณของแอปที่ต้องตื่นขึ้นมาเพื่อโต้ตอบ
• ลดค่าใช้จ่ายเพิ่มเติมของ CD: เช่น ทำให้การตรวจหาการเปลี่ยนแปลงมีต้นทุนถูกลง หาวิธีตรวจสอบแอปให้น้อยลง และใช้ประโยชน์จากสัญญาณแบบตอบสนองต่อสิ่งที่เปลี่ยนแปลง
• การแยกโค้ดที่ละเอียดยิ่งขึ้น: ทำให้กลุ่มเริ่มต้นมีขนาดเล็กลง
• รองรับสัญญาณบอกสถานะการโหลดได้ดียิ่งขึ้น: เช่น ในระหว่างการแสดงผล SSR อีกครั้ง ระหว่างการนําทางเส้นทาง และในการดําเนินการการโหลดแบบเลื่อนเวลา
• เครื่องมือโปรไฟล์: เครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ที่ดียิ่งขึ้นในการทําความเข้าใจต้นทุนการโต้ตอบ โดยเฉพาะต้นทุนการตรวจหาการเปลี่ยนแปลงสําหรับการโต้ตอบที่เฉพาะเจาะจง

การปรับปรุงเหล่านี้ช่วยให้เราจัดการปัญหาต่างๆ ที่ทําให้การตอบสนองและประสบการณ์ของผู้ใช้แย่ลง รวมถึงช่วยเพิ่มเมตริก CWV และเมตริก INP ใหม่สําหรับเว็บไซต์ที่ใช้เฟรมเวิร์ก

บทสรุป

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

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

เรายินดีรับฟังความคิดเห็นจากผู้ใช้เฟรมเวิร์กเมื่อเริ่มเส้นทางการเพิ่มประสิทธิภาพ INP