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

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

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

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

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

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

ตอนที่ 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 ก่อนและหลังทำตามขั้นตอนเพื่อปรับปรุง

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

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

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

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

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

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

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

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

แนวโน้ม INP CrUX

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

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

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