ภารกิจ Economic Times เพื่อแก้ไข INP

การลด TBT ลง 30 เท่าและการย้ายข้อมูลไปยัง Next.js ช่วยให้ The Economic Times ลด INP ได้เกือบ 4 เท่า ซึ่งส่งผลให้อัตราตีกลับลดลง 50% และการดูหน้าเว็บเพิ่มขึ้น 43%

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

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

ค่า INP ที่ดีคือ 200 มิลลิวินาทีหรือน้อยกว่า ค่าที่ไม่ดีคือมากกว่า 500 มิลลิวินาที และค่าที่อยู่ตรงกลางต้องได้รับการปรับปรุง

จุดเริ่มต้นที่ไม่ชัดเจน

เมื่อ Google เปิดตัว INP เป็นครั้งแรกในฐานะเมตริกทดลองที่มีศักยภาพที่จะพัฒนาไปเป็นเมตริก Core Web Vitals รายการใดรายการหนึ่ง ทีม Economic Times ได้ตอบรับความท้าทายในการแก้ไขเมตริกนี้ก่อนที่จะพัฒนาไปเป็นเมตริกดังกล่าว เนื่องจากมอบประสบการณ์การใช้งานระดับโลกเป็นสิ่งสำคัญต่อคุณค่าหลักทางธุรกิจของเรา

INP เป็นหนึ่งในเมตริกที่แก้ไขได้ยากที่สุดเท่าที่เคยมีมา ในช่วงแรก วิธีการวัด INP อย่างมีประสิทธิภาพนั้นยังไม่ชัดเจน แต่สิ่งที่ทำให้เป็นเรื่องยากขึ้นคือการขาดการสนับสนุนจากชุมชน ซึ่งรวมถึงผู้ให้บริการตรวจสอบผู้ใช้จริง (RUM) ส่วนใหญ่ที่ยังไม่รองรับบริการนี้ อย่างไรก็ตาม เรามีเครื่องมือ RUM ของ Google เช่น รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX), web-vitals ไลบรารี JavaScript และอื่นๆ ที่รองรับ ซึ่งช่วยให้เราทราบถึงจุดยืนของเราขณะประเมินเส้นทางข้างหน้า INP ของเราอยู่ที่เกือบ 1,000 มิลลิวินาทีที่ระดับต้นทางเมื่อเราเริ่มต้น

สิ่งที่พบขณะแก้ไข INP ในภาคสนามคือเมตริกการทดสอบที่ควรกำหนดเป้าหมายอาจเป็นระยะเวลาทั้งหมดในการบล็อก (TBT) ซึ่ง TBT นั้นได้รับการบันทึกไว้เป็นอย่างดีและได้รับการสนับสนุนจากชุมชนแล้ว แม้ว่าจะเป็นไปตามเกณฑ์ของ Core Web Vitals แล้ว แต่เรายังทำได้ไม่ดีนักในด้าน TBT เนื่องจากมีค่ามากกว่า 3 วินาทีเมื่อเริ่มต้น

TBT คืออะไร และเราดำเนินการอย่างไรเพื่อปรับปรุงเทคโนโลยีนี้

TBT เป็นเมตริกในเวอร์ชันทดลองที่วัดการตอบสนองของหน้าเว็บต่ออินพุตของผู้ใช้ระหว่างการโหลดหน้าเว็บ งานที่ใช้เวลานานกว่า 50 มิลลิวินาทีในการดำเนินการถือเป็นงานที่ใช้เวลานาน และเวลาหลังจากเกณฑ์ 50 มิลลิวินาทีจะเรียกว่าการบล็อก

TBT คำนวณโดยใช้เวลาการบล็อกของงานที่ใช้เวลานานทั้งหมดในระหว่างการโหลดหน้าเว็บ ตัวอย่างเช่น หากมีงานที่ใช้เวลานาน 2 รายการระหว่างการโหลด ระบบจะกำหนดเวลาการบล็อกดังนี้

  • งาน A ใช้เวลา 80 มิลลิวินาที (30 มิลลิวินาทีมากกว่า 50 มิลลิวินาที)
  • งาน ข ใช้เวลา 100 มิลลิวินาที (มากกว่า 50 มิลลิวินาที 50 มิลลิวินาที)

TBT ของหน้าเว็บจะเป็น 80 มิลลิวินาที (30 + 50) ยิ่ง TBT ต่ำเท่าไรก็ยิ่งดี และ TBT ก็สัมพันธ์กับ INP ได้ดีเช่นกัน

ต่อไปนี้เป็นการเปรียบเทียบ TBT ของเราในเวอร์ชันก่อนและหลังดำเนินการปรับปรุง

รูปภาพแบบคอมโพสิตของงานที่ใช้เวลานานระหว่างการเริ่มต้นตามที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และรายงานเมตริกหน้าเว็บ เทรดหลักถูกบล็อกระหว่างการโหลดหน้าเว็บเป็นเวลา 3,260 มิลลิวินาที
ชุดข้อความหลักระหว่างการเริ่มต้นก่อนที่จะเพิ่มประสิทธิภาพ TBT TBT คือ 3,260 มิลลิวินาที
รูปภาพประกอบของงานที่ใช้เวลานานในช่วงเริ่มต้น ดังที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และรายงานเมตริกของหน้าเว็บ เทรดหลักถูกบล็อกระหว่างการโหลดหน้าเว็บเป็นเวลา 120 มิลลิวินาที
เทรดหลักระหว่างการเพิ่มประสิทธิภาพ TBT TBT คือ 120 มิลลิวินาที

ลดงานในเทรดหลัก

เทรดหลักของเบราว์เซอร์จะจัดการทุกอย่างตั้งแต่การแยกวิเคราะห์ HTML, การสร้าง DOM, การแยกวิเคราะห์ CSS และการใช้สไตล์ รวมถึงการประเมินและเรียกใช้ JavaScript และเธรดหลักยังจัดการการโต้ตอบของผู้ใช้ด้วย เช่น การคลิก การแตะ และการกดแป้นพิมพ์ หากเธรดหลักไม่ว่างเนื่องจากมีงานอื่นๆ อยู่ อาจไม่ตอบสนองต่อข้อมูลจากผู้ใช้อย่างมีประสิทธิภาพ และอาจทําให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่สะดุด

นี่เป็นงานที่ยากที่สุดสำหรับเรา เนื่องจากเรามีอัลกอริทึมเป็นของตัวเองในการตรวจหาตัวตนของผู้ใช้เพื่อแสดงโฆษณาตามสถานะการสมัครใช้บริการและสคริปต์ของบุคคลที่สามสำหรับการทดสอบ A/B การวิเคราะห์ และอีกมากมาย

เราเริ่มต้นด้วยขั้นตอนเล็กๆ น้อยๆ เช่น ลดความสำคัญของการโหลดชิ้นงานทางธุรกิจที่ไม่สำคัญมาก ประการที่ 2 เราใช้ requestIdleCallback สำหรับงานที่ไม่ใช่งานสำคัญ ซึ่งช่วยในการลด TBT ได้

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

เราขอแนะนำให้ระบุการหมดเวลาเมื่อใช้ requestIdleCallback เนื่องจากจะช่วยให้มั่นใจได้ว่าหากเวลาที่กำหนดผ่านไปแล้วและยังไม่ได้เรียกใช้การเรียกกลับ ระบบจะเรียกใช้การเรียกกลับทันทีหลังจากหมดเวลา

ลดเวลาในการประเมินสคริปต์

นอกจากนี้ เรายังใช้ Lazy Loading กับไลบรารีของบุคคลที่สามโดยใช้คอมโพเนนต์ที่โหลดได้ นอกจากนี้ เรายังนำ JavaScript และ CSS ที่ไม่ได้ใช้ออกโดยการทำโปรไฟล์หน้าเว็บด้วยเครื่องมือการครอบคลุมในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome วิธีนี้ช่วยให้เราระบุพื้นที่ที่จำเป็นต้องมีการสั่นสะเทือนของต้นไม้เพื่อให้จัดส่งโค้ดน้อยลงในระหว่างการโหลดหน้าเว็บ จึงลดขนาดแพ็กเกจเริ่มต้นของแอปพลิเคชันลง

ภาพหน้าจอของเครื่องมือความครอบคลุมในเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome ในส่วนนี้ เครื่องมือจะแสดงส่วนที่ไม่ได้ใช้ของไฟล์ JavaScript และ CSS ระหว่างการโหลดหน้าเว็บ

ลดขนาด DOM

ต่อ Lighthouse ขนาด DOM ขนาดใหญ่จะเพิ่มการใช้งานหน่วยความจำ ทำให้การคำนวณรูปแบบใหม่นานขึ้น และสร้างการจัดเรียงการออกแบบใหม่ซึ่งมีค่าใช้จ่ายสูง

ภาพหน้าจอของการตรวจสอบขนาด DOM ใน Lighthouse จํานวนองค์ประกอบ DOM ที่รายงานคือ 2,706 องค์ประกอบ

เราลดจำนวนโหนด DOM ได้ 2 วิธีดังนี้

  • ก่อนอื่น เราจะแสดงผลรายการเมนูตามคำขอของผู้ใช้ (เมื่อคลิก) ซึ่งทำให้ DOM มีขนาดลดลงประมาณ 1,200 โหนด
  • อย่างที่สอง เราโหลดวิดเจ็ตที่สำคัญน้อยกว่า

ความพยายามทั้งหมดนี้ช่วยให้เราลด TBT ได้อย่างมาก และ INP ก็ลดลงเกือบ 50% ตามไปด้วย

ภาพหน้าจอของการตรวจสอบ INP ใน CrUX INP ของหน้าเว็บคือ 539 มิลลิวินาที ซึ่งเกินเกณฑ์ "แย่"

ณ จุดนี้ เราแทบจะได้ผลลัพธ์ง่ายๆ เพื่อที่จะลด TBT ลงอีก (และ INP โดยพร็อกซี) แต่เรารู้ว่าเรามีสิ่งที่ต้องปรับปรุงอีกมาก ด้วยเหตุนี้ เราจึงตัดสินใจอัปเกรดไฟล์เริ่มต้นของ UI ที่กําหนดเองเป็น React เวอร์ชันล่าสุดพร้อมกับ Next.js เพื่อใช้ประโยชน์จาก hooks ได้ดียิ่งขึ้นและหลีกเลี่ยงการแสดงผลคอมโพเนนต์ซ้ำโดยไม่จําเป็น

เราเริ่มย้ายข้อมูลหน้าหัวข้อไปยัง Next.js เนื่องจากมีการอัปเดตบ่อยขึ้นและมีการเข้าชมน้อยกว่าเมื่อเทียบกับส่วนอื่นๆ ของเว็บไซต์ นอกจากนี้ เรายังใช้ PartyTown เพื่อส่งงานเพิ่มเติมในเธรดหลักไปยัง Web Worker รวมถึงเทคนิคต่างๆ เช่น requestIdleCallBack เพื่อเลื่อนงานที่ไม่สำคัญ

การปรับปรุง INP ช่วยให้ The Economic Times เกิดประโยชน์อย่างไรบ้าง

TBT และ INP ปัจจุบันจากต้นทาง

ตอนที่เผยแพร่โพสต์นี้ TBT ของต้นทางคือ 120 มิลลิวินาที ซึ่งลดลงจาก 3,260 มิลลิวินาทีเมื่อเราเริ่มเพิ่มประสิทธิภาพ ในทํานองเดียวกัน INP ของต้นทางของเราคือ 257 มิลลิวินาทีหลังจากการเพิ่มประสิทธิภาพ ซึ่งลดลงจากกว่า 1,000 มิลลิวินาที

ภาพหน้าจอของการตรวจสอบ INP ใน CrUX INP ของหน้าเว็บคือ 257 มิลลิวินาที ซึ่งอยู่ในเกณฑ์ "ต้องปรับปรุง"

แนวโน้ม CrUX ของ INP

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

ภาพหน้าจอของค่าการแจกแจง INP ที่แสดงเป็นภาพใน CrUX ในช่วง 4 เดือน ตั้งแต่เดือนกรกฎาคม 2022 ถึงเดือนตุลาคม 2022 ค่าที่อยู่ภายในเกณฑ์ "แย่" และ "ต้องปรับปรุง" ลดลงเล็กน้อย ขณะที่ค่าที่อยู่ภายในเกณฑ์ "ดี" เพิ่มขึ้น

การวิเคราะห์ Akamai mPulse (TBT)

เราใช้ Akamai mPulse เป็นโซลูชัน RUM ซึ่งจะวัด TBT ในพื้นที่ เราพบว่า TBT ลดลงอย่างต่อเนื่อง ซึ่งสอดคล้องกับผลลัพธ์ของความพยายามของเราในการลด INP ดังที่เห็นในภาพหน้าจอด้านล่าง ค่า TBT ลดลงจากประมาณ 5 วินาทีในสนามเป็นประมาณ 200 มิลลิวินาทีในท้ายที่สุด

ภาพหน้าจอของแผนภูมิใน Akamai mPulse ซึ่งแสดงการลดลงของ TBT ในระยะเวลาประมาณ 1 เดือน

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

โดยรวมแล้ว ความพยายามของเราที่จะลด TBT ลง 30 ครั้ง พร้อมกับการเปลี่ยนไปใช้ Next.js ช่วยให้เราลด INP ได้เกือบ 4 เท่า ซึ่งสุดท้ายคืออัตราตีกลับลดลง 50% และการดูหน้าเว็บหัวข้อเพิ่มขึ้น 43%

ภาพหน้าจอของ Google Analytics ที่เปรียบเทียบการดูหน้าเว็บกับอัตราตีกลับ เนื่องจากการเพิ่มประสิทธิภาพ INP ในเว็บไซต์ The Economic Times อัตราตีกลับลดลง 50% และการดูหน้าเว็บเพิ่มขึ้น 43%

บทสรุป

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