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

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

Barun Kumar

Daya Ram Yadav

Saurabh Rajpal

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

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

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

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

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

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

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

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

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

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

ต่อไปนี้เป็นข้อมูลเปรียบเทียบคร่าวๆ ของ TBT ก่อนและหลังทำตามขั้นตอนเพื่อปรับปรุง

วันที่

เทรดหลักระหว่างเริ่มต้นใช้งานก่อนเพิ่มประสิทธิภาพ TBT TBT คือ 3,260 มิลลิวินาที

เทรดหลักระหว่างเริ่มต้นใช้งานหลังจากเพิ่มประสิทธิภาพ 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 เนื่องจากจะตรวจสอบว่าหากเลยเวลาที่ระบุไปแล้วและยังไม่มีการเรียกใช้ Callback ก็จะเรียกใช้ Callback ทันทีหลังระยะหมดเวลา

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

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

ลดขนาด DOM

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

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

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

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

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

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

การปรับปรุง INP ช่วย The Economic Times อย่างไร

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

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

แนวโน้ม INP CrUX

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

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

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

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

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

บทสรุป

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