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

การลด TBT ลง 30 เท่าและการย้ายข้อมูลไปยัง Next.js ช่วยให้ The 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 อย่างมีประสิทธิภาพ สิ่งที่สร้างความยากลำบากมากขึ้นคือการขาดการสนับสนุนจากชุมชน รวมไปถึงผู้ให้บริการ Real User Monitoring (RUM) ส่วนใหญ่ที่ยังไม่รองรับ แต่เรามีเครื่องมือต่างๆ ของ Google RUM เช่น รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ไลบรารี JavaScript ของ web-vitals และเครื่องมืออื่นๆ ที่รองรับ ซึ่งช่วยให้เราทราบจุดที่เรายืนอยู่ขณะประเมินเส้นทางข้างหน้า INP ของเราใกล้เคียงกับ 1,000 มิลลิวินาทีที่ระดับต้นทางตอนที่เราเริ่มต้น

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

TBT คืออะไรและเราทำอะไรบ้างเพื่อปรับปรุง

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

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

• งาน A ใช้เวลา 80 มิลลิวินาที (30 มิลลิวินาทีมากกว่า 50 มิลลิวินาที)
• งาน B ใช้เวลา 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 โหนด
• อย่างที่ 2 เราโหลดวิดเจ็ตที่ไม่สำคัญมากนัก

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

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

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