ทำความเข้าใจว่าเมตริก INP ใหม่ส่งผลต่อประสบการณ์การใช้งานเว็บไซต์ที่สร้างขึ้นโดยใช้เฟรมเวิร์กและไลบรารี JavaScript อย่างไร
Chrome เพิ่งเปิดตัวเมตริกการตอบสนองในการทดสอบใหม่ในรายงานรายงาน UX ของ Chrome เมตริกนี้ซึ่งปัจจุบันเรารู้จักในชื่อ 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 ภาษาวานิลลา
Hydration: การใช้เฟรมเวิร์ก JavaScript ถือเป็นเรื่องปกติที่เซิร์ฟเวอร์จะสร้าง HTML เริ่มต้นสำหรับหน้าเว็บ ซึ่งจะต้องมีการปรับปรุงด้วยตัวแฮนเดิลเหตุการณ์และสถานะแอปพลิเคชันเพื่อให้โต้ตอบในเว็บเบราว์เซอร์ได้ เราเรียกกระบวนการนี้ว่า Hydration ซึ่งอาจเป็นกระบวนการที่หนักในระหว่างการโหลด ทั้งนี้ขึ้นอยู่กับระยะเวลาที่ JavaScript ใช้ในการโหลดและการทำให้ปริมาณน้ำเสร็จสิ้น และยังอาจทำให้หน้าเว็บดูเหมือนมีการโต้ตอบทั้งที่จริงๆ แล้วไม่ได้โต้ตอบด้วย ภาวะน้ำในปริมาณมากเกิดขึ้นโดยอัตโนมัติระหว่างการโหลดหน้าเว็บหรือการทำงานอย่างช้าๆ (เช่น เมื่อมีการโต้ตอบของผู้ใช้) และอาจส่งผลกระทบต่อ INP หรือเวลาในการประมวลผลเนื่องจากการกำหนดเวลางาน ในไลบรารี เช่น React คุณสามารถใช้ประโยชน์จาก
useTransitionเพื่อให้การแสดงผลคอมโพเนนต์บางส่วนอยู่ในเฟรมถัดไป และจะทำให้เกิดผลข้างเคียงที่มีต้นทุนสูงกับเฟรมในอนาคต ด้วยเหตุนี้ การอัปเดตในช่วงเปลี่ยนผ่านที่ทำให้เกิดการอัปเดตที่เร่งด่วนกว่า เช่น การคลิก อาจเป็นรูปแบบที่ดีสำหรับ INPการดึงข้อมูลล่วงหน้า: การดึงข้อมูลทรัพยากรล่วงหน้าที่ต้องใช้ในการนำทางครั้งต่อๆ ไปอาจมีประสิทธิภาพดีกว่าหากทำอย่างถูกต้อง อย่างไรก็ตาม หากคุณดึงข้อมูลล่วงหน้าและแสดงผลเส้นทาง SPA แบบพร้อมกัน อาจส่งผลเสียต่อ INP เนื่องจากการแสดงผลที่มีราคาแพงนี้พยายามจะทำให้เสร็จสมบูรณ์ในเฟรมเดียว ตรงข้ามกับวิธีนี้คือการไม่ดึงข้อมูลเส้นทางล่วงหน้า แต่เริ่มทำงานที่จำเป็น (เช่น
fetch()) และเลิกบล็อกสีแทน เราขอแนะนำให้ตรวจสอบอีกครั้งว่าการดึงข้อมูลล่วงหน้าของเฟรมเวิร์กของคุณมอบ UX ที่เหมาะสมที่สุดหรือไม่ และปัญหานี้อาจส่งผลต่อ INP อย่างไรบ้าง (หากมี)
จากนี้ไป จากนี้ไป เพื่อให้ได้คะแนน INP ที่ดี นักพัฒนาซอฟต์แวร์จะต้องมุ่งเน้นที่การตรวจสอบโค้ดที่ทำงานหลังการโต้ตอบแต่ละครั้งบนหน้า รวมถึงเพิ่มประสิทธิภาพการแบ่งส่วน การดึงเนื้อหา กลยุทธ์การโหลด และขนาดของการอัปเดตที่แสดงผล() แต่ละครั้งสำหรับทั้งสคริปต์ของบุคคลที่หนึ่งและสคริปต์บุคคลที่สาม
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 ช่วยให้คุณสามารถเลือกใช้ Hydration แบบเฉพาะหรือแบบ Progressive แบบเลือกส่วนได้ ซึ่งหมายความว่าน้ำจะไม่ใช่บล็อกซิงโครนัส โดยจะถูกแบ่งเป็นส่วนเล็กๆ ที่ขัดขวางได้ทุกเมื่อ
วิธีนี้น่าจะช่วยปรับปรุง INP และทำให้คุณตอบสนองต่อการกดแป้นพิมพ์ เอฟเฟ็กต์เมื่อวางเมาส์เหนือรายการ และการคลิกได้เร็วขึ้น นอกจากนี้ยังช่วยให้แอป React ตอบสนองอยู่เสมอแม้การเปลี่ยนผ่านขนาดใหญ่ เช่น การเติมข้อความอัตโนมัติ
Next.js ได้ใช้เฟรมเวิร์กการกำหนดเส้นทางใหม่ที่ใช้ startTransition โดยค่าเริ่มต้นสำหรับการเปลี่ยนเส้นทาง วิธีนี้จะช่วยให้เจ้าของเว็บไซต์ Next.js นำการแบ่งเวลาของ React ไปใช้และปรับปรุงการตอบสนองของการเปลี่ยนเส้นทางได้
Angular
ทีม Angular กำลังดำเนินการสำรวจแนวคิดต่างๆ ที่อาจเป็นประโยชน์ต่อ INP ด้วยเช่นกัน
- Zoneless: ลดขนาด Bundle เริ่มต้นและโค้ดที่จำเป็นซึ่งต้องโหลดก่อนที่แอปจะแสดงผลได้
- ความชุ่มชื้น: ความชุ่มชื้นแบบเกาะเพื่อจำกัดจำนวนแอปที่จะต้องตื่นสำหรับการโต้ตอบ
- ลดภาระการทำงานของ CD: เช่น ทำให้การตรวจจับการเปลี่ยนแปลงมีราคาถูกลง หาวิธีตรวจสอบแอปให้น้อยลง และใช้ประโยชน์จากสัญญาณเชิงรับเกี่ยวกับการเปลี่ยนแปลง
- การแยกโค้ดแบบละเอียดยิ่งขึ้น: ทำให้แพ็กเกจเริ่มต้นมีขนาดเล็กลง
- การรองรับตัวบ่งชี้การโหลดที่ดียิ่งขึ้น: เช่น ในระหว่างการแสดงผล SSR อีกครั้ง ระหว่างการนำทางในเส้นทาง และในการโหลดแบบ Lazy Loading
- เครื่องมือสร้างโปรไฟล์: เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่ช่วยให้เข้าใจต้นทุนการโต้ตอบได้ดียิ่งขึ้น โดยเฉพาะเรื่องต้นทุนการตรวจจับการเปลี่ยนแปลงสำหรับการโต้ตอบที่เฉพาะเจาะจง
การปรับปรุงเหล่านี้ช่วยให้เราแก้ไขปัญหาต่างๆ ที่ส่งผลให้การตอบสนองและประสบการณ์ของผู้ใช้แย่ลง รวมทั้งเพิ่มประสิทธิภาพเมตริก CWV และเมตริก INP ใหม่สำหรับเว็บไซต์ที่อิงตามเฟรมเวิร์ก
บทสรุป
เราคาดว่าคะแนน INP จะเป็นหลักเกณฑ์ที่ดีกว่าสำหรับเว็บไซต์เพื่อปรับปรุงการตอบสนองและประสิทธิภาพในอนาคต เราจะต่อยอดคู่มือ INP ที่มีอยู่เพื่อให้เคล็ดลับเพิ่มเติมสําหรับนักพัฒนาเฟรมเวิร์กในปี 2023 เราหวังว่าจะบรรลุเป้าหมายนี้ได้โดยทำดังนี้
- การสร้างแชแนลสำหรับการเข้าถึงข้อมูลภาคสนามบน INP สำหรับเฟรมเวิร์กและนักพัฒนาเว็บได้อย่างง่ายดาย
- ทำงานร่วมกับเฟรมเวิร์กเพื่อสร้างฟีเจอร์ที่จะปรับปรุง INP โดยค่าเริ่มต้น
เรายินดีรับฟังความคิดเห็นจากผู้ใช้เฟรมเวิร์กตั้งแต่เริ่มต้นเส้นทางการเพิ่มประสิทธิภาพ INP