การลด TBT ลง 30 เท่าและการย้ายข้อมูลไปยัง Next.js ช่วยให้ The Economic Times ลด INP ได้เกือบ 4 เท่า ซึ่งส่งผลให้อัตราตีกลับลดลง 50% และการดูหน้าเว็บเพิ่มขึ้น 43%
Interaction to Next Paint (INP) คือเมตริกที่ประเมินการตอบสนองของเว็บไซต์ต่ออินพุตของผู้ใช้ การตอบสนองที่ดีหมายความว่าหน้าเว็บตอบสนองต่อการโต้ตอบของผู้ใช้อย่างรวดเร็ว ยิ่ง INP ของหน้าเว็บต่ำ หน้าเว็บก็จะยิ่งตอบสนองต่อการโต้ตอบของผู้ใช้ได้ดียิ่งขึ้น
จุดเริ่มต้นที่ไม่ชัดเจน
เมื่อ 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 ของเราในเวอร์ชันก่อนและหลังดำเนินการปรับปรุง
ลดงานในเทรดหลัก
เทรดหลักของเบราว์เซอร์จะจัดการทุกอย่างตั้งแต่การแยกวิเคราะห์ 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 วิธีนี้ช่วยให้เราระบุพื้นที่ที่จำเป็นต้องมีการสั่นสะเทือนของต้นไม้เพื่อให้จัดส่งโค้ดน้อยลงในระหว่างการโหลดหน้าเว็บ จึงลดขนาดแพ็กเกจเริ่มต้นของแอปพลิเคชันลง
ลดขนาด DOM
ต่อ Lighthouse ขนาด DOM ขนาดใหญ่จะเพิ่มการใช้งานหน่วยความจำ ทำให้การคำนวณรูปแบบใหม่นานขึ้น และสร้างการจัดเรียงการออกแบบใหม่ซึ่งมีค่าใช้จ่ายสูง
เราลดจำนวนโหนด DOM ได้ 2 วิธีดังนี้
- ก่อนอื่น เราจะแสดงผลรายการเมนูตามคำขอของผู้ใช้ (เมื่อคลิก) ซึ่งทำให้ DOM มีขนาดลดลงประมาณ 1,200 โหนด
- อย่างที่สอง เราโหลดวิดเจ็ตที่สำคัญน้อยกว่า
ความพยายามทั้งหมดนี้ช่วยให้เราลด TBT ได้อย่างมาก และ INP ก็ลดลงเกือบ 50% ตามไปด้วย
ณ จุดนี้ เราแทบจะได้ผลลัพธ์ง่ายๆ เพื่อที่จะลด 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 มิลลิวินาที
แนวโน้ม CrUX ของ INP
การเข้าชมที่ได้รับในหน้าหัวข้อคิดเป็นสัดส่วนน้อยกว่ามากของการเข้าชมโดยรวม จึงเป็นพื้นที่ที่เหมาะสําหรับการทดสอบ ผลลัพธ์ของ CrUX รวมถึงผลลัพธ์ทางธุรกิจมีกำลังใจอย่างมาก และช่วยให้เราขยายความพยายามทั่วทั้งเว็บไซต์เพื่อให้ได้รับผลประโยชน์มากขึ้น
การวิเคราะห์ Akamai mPulse (TBT)
เราใช้ Akamai mPulse เป็นโซลูชัน RUM ซึ่งจะวัด TBT ในพื้นที่ เราพบว่า TBT ลดลงอย่างต่อเนื่อง ซึ่งสอดคล้องกับผลลัพธ์ของความพยายามของเราในการลด INP ดังที่เห็นในภาพหน้าจอด้านล่าง ค่า TBT ลดลงจากประมาณ 5 วินาทีในสนามเป็นประมาณ 200 มิลลิวินาทีในท้ายที่สุด
ผลลัพธ์ทางธุรกิจ
โดยรวมแล้ว ความพยายามของเราที่จะลด TBT ลง 30 ครั้ง พร้อมกับการเปลี่ยนไปใช้ Next.js ช่วยให้เราลด INP ได้เกือบ 4 เท่า ซึ่งสุดท้ายคืออัตราตีกลับลดลง 50% และการดูหน้าเว็บหัวข้อเพิ่มขึ้น 43%
บทสรุป
โดยสรุปแล้ว INP ช่วยระบุปัญหาด้านประสิทธิภาพรันไทม์ในบางส่วนของเว็บไซต์ Economic Times ได้อย่างครอบคลุม ซึ่งพิสูจน์แล้วว่าเป็นหนึ่งในเมตริกที่มีประสิทธิภาพมากที่สุดในการส่งผลเชิงบวกต่อผลลัพธ์ทางธุรกิจ ตัวเลขที่น่าพอใจซึ่งเราได้รับจากผลลัพธ์ของความพยายามนี้ทำให้เรามีแรงจูงใจที่จะขยายการเพิ่มประสิทธิภาพไปยังส่วนอื่นๆ ของเว็บไซต์และรับประโยชน์เพิ่มเติม