ภารกิจ 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 อย่างมีประสิทธิภาพนั้นยังไม่ชัดเจน สิ่งที่ทําให้เรื่องยากขึ้นคือการสนับสนุนจากชุมชน ซึ่งรวมถึงผู้ให้บริการ Real User Monitoring (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 รายการระหว่างการโหลด ระบบจะกำหนดเวลาการบล็อกดังนี้

  • งาน ก ใช้เวลา 80 มิลลิวินาที (มากกว่า 50 มิลลิวินาที 30 มิลลิวินาที)
  • งาน ข ใช้เวลา 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 ซึ่งช่วยให้เราระบุได้ว่าจะต้องใช้ Tree Shaking ตรงจุดไหนเพื่อส่งโค้ดน้อยลงในระหว่างการโหลดหน้าเว็บ และลดขนาดแพ็กเกจเริ่มต้นของแอปพลิเคชัน

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

ลดขนาด DOM

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

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

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

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

ความพยายามทั้งหมดนี้ช่วยให้เราลด 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 ค่าที่อยู่ภายในเกณฑ์ "แย่" และ "ต้องปรับปรุง" ลดลงเล็กน้อย ขณะที่ค่าที่อยู่ภายในเกณฑ์ "ดี" เพิ่มขึ้น

การวิเคราะห์ TBT ของ Akamai mPulse

เราใช้ 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 ได้อย่างครอบคลุม ซึ่งพิสูจน์แล้วว่าเป็นหนึ่งในเมตริกที่มีประสิทธิภาพมากที่สุดในการส่งผลเชิงบวกต่อผลลัพธ์ทางธุรกิจ ตัวเลขที่น่าพอใจซึ่งเราได้รับจากผลลัพธ์ของความพยายามนี้ทำให้เรามีแรงจูงใจที่จะขยายการเพิ่มประสิทธิภาพไปยังส่วนอื่นๆ ของเว็บไซต์และรับประโยชน์เพิ่มเติม