วิธีที่ redBus ปรับปรุงการโต้ตอบกับ Next Paint (INP) ของเว็บไซต์และเพิ่มยอดขาย 7%

การเพิ่มประสิทธิภาพ INP ช่วยให้ RedBus เพิ่มยอดขายได้ประมาณ 7%

Saurabh Rajpal
Saurabh Rajpal

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

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

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

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

เป้าหมายสูงสุด

เมื่อ RedBus ต้องการเพิ่มประสิทธิภาพ INP ของเว็บไซต์ พวกเขามีเป้าหมาย 3 ประการดังนี้

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

การเดินทาง

redBus จัดหมวดหมู่เวลาในการตอบสนองของการโต้ตอบได้ 2 วิธี ดังนี้

  1. เวลาในการตอบสนองของการโต้ตอบที่เกิดจากการบล็อก JavaScript ในไคลเอ็นต์ เมื่อการโต้ตอบใช้ JavaScript มากเกินไปซึ่งบล็อกเทรดหลัก การแสดงผลจะล่าช้าและจะส่งผลต่อ INP ของหน้าเว็บ
  2. เวลาในการตอบสนองของเครือข่ายที่เกิดจากการเรียก API แม้ว่ากิจกรรมในเครือข่ายจะไม่ใช่สิ่งที่ INP วัด แต่การโต้ตอบที่ขึ้นอยู่กับการเรียก API ระยะไกลอาจดูช้าลงเมื่อใช้เครือข่ายที่ช้า หรือหากคำขอส่งผลให้มีการตอบสนองจำนวนมาก

ในตอนแรก redBus ค่อนข้างมั่นใจว่า INP ของเว็บไซต์จะดี แต่ข้อมูลการตรวจสอบผู้ใช้จริง (RUM) สำหรับเมตริกนี้ที่เปอร์เซ็นไทล์ที่ 95 กลับบอกเล่าเรื่องราวที่แตกต่างออกไป

วิธีที่ RedBus วัด INP

redBus ใช้ไลบรารี JavaScript web-vitals ที่สร้างโดย Google ในการติดตามเมตริกประสบการณ์ผู้ใช้ที่สำคัญทั้งหมดสำหรับหน้าเว็บทุกหน้าในเว็บไซต์ นอกเหนือจากไลบรารี JavaScript web-vitals แล้ว redBus ยังใช้ ELK เพื่อวิเคราะห์ข้อมูล INP ที่รวบรวมในส่วนหน้า

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

เมื่อ RedBus มีระบบสำหรับติดตาม INP แล้ว พวกเขาก็สามารถวิเคราะห์ข้อมูลเพื่อให้เข้าใจได้ดีขึ้นว่าส่วนไหนที่มีการโต้ตอบช้า

ภาพหน้าจอของระบบการบันทึก ELK ที่รายงานค่า INP สำหรับการวิเคราะห์
ภาพหน้าจอของระบบการบันทึกที่ RedBus ใช้เพื่อวิเคราะห์ค่า INP ที่รวบรวมจากช่อง (คลิกเพื่อดูรูปภาพเวอร์ชันความละเอียดที่สูงขึ้น)

Use Case

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

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

ลักษณะการทำงานแบบ Lazy Loading ที่ใช้สำหรับการโหลดค่าโดยสารเพิ่มเติมจาก API เมื่อเลื่อน (คลิกเพื่อดูเวอร์ชันความละเอียดสูงของวิดีโอนี้)

วิธีที่ RedBus เพิ่มประสิทธิภาพ INP สำหรับหน้าค้นหา

ในการปรับปรุง INP ของหน้าการค้นหา RedBus ได้เพิ่มประสิทธิภาพหลายอย่าง:

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

นอกจากนี้ ยังมีการเพิ่มประสิทธิภาพต่อไปนี้เพิ่มเติมในหน้าผลการค้นหา:

  • มีการดึงข้อมูลผลการค้นหากลุ่มใหม่ในการ์ดที่ 2 ถึงการ์ดสุดท้ายในหน้าผลการค้นหา เพื่อปรับปรุงประสบการณ์ของผู้ใช้และประสิทธิภาพด้านภาพโดยเรียกใช้การโหลดแบบ Lazy Loading ให้เร็วขึ้น
  • มีการดึงข้อมูลผลลัพธ์น้อยลงในการเรียกเครือข่ายแต่ละครั้งระหว่างการโหลดแบบ Lazy Loading เมื่อลดการดึงข้อมูลจากผลลัพธ์ 30 ถึง 10 รายการ ระบบจึงพบการลดช่วง INP ที่ 870 ถึง 900 เหลือ 350 ถึง 370 รายการ
ลักษณะการโหลดแบบ Lazy Loading ที่ใช้ในการโหลดค่าโดยสารเพิ่มเติมจาก API ขณะเลื่อน (คลิกเพื่อดูเวอร์ชันความละเอียดสูงของวิดีโอนี้)

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

รายงานค่า INP ในคอนโซลขณะที่ผู้ใช้พิมพ์ในช่องป้อนข้อมูล ค่า INP ที่ได้เป็น 344 ที่พบในการตั้งค่าห้องทดลองอยู่ในเกณฑ์ "ต้องปรับปรุง" (คลิกเพื่อดูเวอร์ชันความละเอียดสูงของวิดีโอนี้)

เพื่อเพิ่มประสิทธิภาพการโต้ตอบนี้ RedBus ได้จัดการสถานะของคอมโพเนนต์อินพุตภายในเครื่องและซิงค์กับ Store Redux เฉพาะเมื่อเหตุการณ์ blur ของอินพุตเริ่มทํางานเท่านั้น การเปลี่ยนแปลงนี้ลดจำนวนการแสดงผลซ้ำและขจัดการแสดงผลซ้ำที่ไม่พึงประสงค์ของอินเทอร์เฟซผู้ใช้ โดยการเรียกใช้ตัวลดความถี่น้อยลง

ปรับปรุง INP เนื่องจากเรียกใช้ตัวลดความถี่น้อยลงเมื่อเปลี่ยนช่องป้อนข้อมูล (คลิกเพื่อดูเวอร์ชันความละเอียดสูงของวิดีโอนี้)

การเปลี่ยนแปลงนี้ทำให้ INP ของหน้าเว็บเพิ่มขึ้น 72% ทำให้ผู้ใช้ได้รับประสบการณ์ของผู้ใช้ที่รวดเร็วและลื่นไหลมากขึ้น ซึ่งมีแนวโน้มที่จะมีส่วนร่วมมากขึ้น

ผลลัพธ์ทางธุรกิจ

ความสัมพันธ์ระหว่างสถานภาพธุรกิจกับประสิทธิภาพของหน้าเว็บนั้นเป็นที่รู้จักกันดี แม้ว่า INP จะเป็นเมตริกที่ค่อนข้างใหม่เมื่อเทียบกับ Core Web Vitals อื่นๆ แต่ redBus สังเกตเห็นผลลัพธ์ทางธุรกิจที่ดีขึ้นโดยมุ่งเน้นการปรับปรุงเมตริกประสิทธิภาพที่สำคัญที่เน้นผู้ใช้เป็นหลักนี้ ผลที่ได้คือยอดขายโดยรวมเพิ่มขึ้น 7%

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