วิธีที่ 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 สําหรับเว็บไซต์จะดี แต่ข้อมูล Real User Monitoring (RUM) สําหรับเมตริกนี้ที่เปอร์เซ็นต์ไทล์ 95 กลับให้ผลลัพธ์ที่แตกต่างออกไป

วิธีวัด INP ของ redBus

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

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

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

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

กรณีการใช้งาน

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

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

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

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

redBus ได้ทำการปรับปรุงหลายอย่างเพื่อปรับปรุง INP ของหน้าค้นหา ดังนี้

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

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

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

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

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

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

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

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

ผลกระทบทางธุรกิจ

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

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