การลด TBT ลง 30 ครั้งและการเปลี่ยนไปใช้ Next.js ช่วยให้ Ecomonic Times ลด INP ได้เกือบ 4 เท่า ส่งผลให้อัตราตีกลับลดลง 50% และการดูหน้าเว็บเพิ่มขึ้น 43%
การโต้ตอบกับ 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 ก่อนและหลังทำตามขั้นตอนเพื่อปรับปรุง
![รูปภาพประกอบของงานที่ใช้เวลานานในช่วงเริ่มต้น ดังที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และรายงานเมตริกของหน้าเว็บ เทรดหลักถูกบล็อกระหว่างการโหลดหน้าเว็บเป็นเวลา 3,260 มิลลิวินาที](https://web.dev/static/case-studies/economic-times-inp/image/a-composite-image-long-t-f7ec3934a2a4a.png?authuser=7&hl=th)
![รูปภาพประกอบของงานที่ใช้เวลานานในช่วงเริ่มต้น ดังที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และรายงานเมตริกของหน้าเว็บ เทรดหลักถูกบล็อกระหว่างการโหลดหน้าเว็บเป็นเวลา 120 มิลลิวินาที](https://web.dev/static/case-studies/economic-times-inp/image/a-composite-image-long-t-6e22c16464729.png?authuser=7&hl=th)
ลดการทำงานของเทรดหลัก
เทรดหลักของเบราว์เซอร์จะจัดการทุกอย่างตั้งแต่การแยกวิเคราะห์ 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 ส่วนที่ไม่ได้ใช้งานในระหว่างการโหลดหน้าเว็บ](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-the-coverag-d292288b0d4e6.png?authuser=7&hl=th)
ลดขนาด DOM
ต่อ Lighthouse ขนาด DOM ขนาดใหญ่จะใช้หน่วยความจำเพิ่มขึ้น ทำให้การคำนวณรูปแบบใหม่นานขึ้น และสร้างการจัดเรียงการออกแบบใหม่ซึ่งมีค่าใช้จ่ายสูง
![ภาพหน้าจอของการตรวจสอบขนาด DOM ใน Lighthouse จํานวนองค์ประกอบ DOM ที่รายงานคือ 2,706 องค์ประกอบ](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-the-dom-siz-5ae84c7581768.png?authuser=7&hl=th)
เราลดจำนวนโหนด DOM ได้ 2 วิธี ดังนี้
- ขั้นแรก เราแสดงรายการในเมนูตามคำขอของผู้ใช้ (เมื่อคลิก) ซึ่งช่วยลดขนาด DOM ลงประมาณ 1,200 โหนด
- อย่างที่สอง เราโหลดวิดเจ็ตที่สำคัญน้อยกว่า
จากความพยายามทั้งหมดที่กล่าวมานี้ เราจึงลดจำนวน TBT ลงได้อย่างมาก และ INP ของเราก็ลดลงตามมาเกือบ 50%
![ภาพหน้าจอของการตรวจสอบ INP ใน CrUX INP ของหน้าเว็บคือ 539 มิลลิวินาที ซึ่งเกินค่า "แย่"](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-the-inp-aud-2faf213b950a4.png?authuser=7&hl=th)
ณ จุดนี้ เราแทบจะได้ผลลัพธ์ง่ายๆ เพื่อที่จะลด 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 มิลลิวินาที ซึ่งอยู่ในช่วง "ต้องปรับปรุง" ขั้นต่ำ](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-the-inp-aud-2cea28af9782c.png?authuser=7&hl=th)
แนวโน้ม INP CrUX
การเข้าชมที่ได้รับในหน้าหัวข้อแสดงถึงการเข้าชมโดยรวมที่น้อยกว่ามาก ดังนั้นจึงเป็นสถานที่ที่เหมาะสำหรับการทดลอง ผลลัพธ์ของ CrUX รวมถึงผลลัพธ์ทางธุรกิจให้กำลังใจเป็นอย่างมาก และช่วยให้เราขยายความพยายามทั่วทั้งเว็บไซต์เพื่อให้ได้รับผลประโยชน์มากขึ้น
![ภาพหน้าจอของการแจกแจง INP ตามที่แสดงใน CrUX ในระยะเวลา 4 เดือน โดยเริ่มตั้งแต่เดือนกรกฎาคม 2022 และสิ้นสุดในเดือนตุลาคม 2022 ค่าที่อยู่ในคอลัมน์ "poor" และ "ต้องปรับปรุง" เกณฑ์ลดลงบางส่วน ในขณะที่ค่าภายในเกณฑ์ "ดี" เพิ่มขึ้น](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-inp-distrib-44656d248acd2.png?authuser=7&hl=th)
การวิเคราะห์ Akamai mPulse (TBT)
เราใช้ Akamai mPulse เป็นโซลูชัน RUM ซึ่งจะวัด TBT ในช่อง เราสังเกตเห็นจำนวน TBT ที่ลดลงอย่างสม่ำเสมอ โดยแสดงให้เห็นผลลัพธ์ของความพยายามในการลด INP อย่างชัดเจน ดังที่เห็นในภาพหน้าจอด้านล่าง ในที่สุดค่า TBT จะลดลงจากประมาณ 5 วินาทีเป็นประมาณ 200 มิลลิวินาทีในฟิลด์
![ภาพหน้าจอของแผนภูมิใน Akamai mPulse ซึ่งแสดงการลดลงของ TBT ตลอดช่วง 1 เดือนโดยประมาณ](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-a-chart-ak-a1f0ba83edd4b.png?authuser=7&hl=th)
ผลลัพธ์ทางธุรกิจ
โดยรวมแล้ว ความพยายามของเราที่จะลดจำนวน TBT ลง 30 ครั้ง พร้อมกับการเปลี่ยนไปใช้ Next.js ช่วยให้เราลด INP ได้เกือบ 4 เท่า ซึ่งสุดท้ายแล้วส่งผลให้อัตราตีกลับลดลง 50% และการดูหน้าเว็บหัวข้อเพิ่มขึ้น 43%
![ภาพหน้าจอของ Google Analytics ที่เปรียบเทียบการดูหน้าเว็บกับอัตราตีกลับ เนื่องจากการเพิ่มประสิทธิภาพ INP บนเว็บไซต์ The Economic Times ทำให้อัตราตีกลับลดลง 50% และการดูหน้าเว็บเพิ่มขึ้น 43%](https://web.dev/static/case-studies/economic-times-inp/image/a-screenshot-google-anal-5a13666518332.png?authuser=7&hl=th)
บทสรุป
กล่าวโดยสรุป INP ได้ช่วยระบุปัญหาด้านประสิทธิภาพรันไทม์ในส่วนต่างๆ ของเว็บไซต์ Economic Times อย่างกว้างขวาง เมตริกนี้พิสูจน์ให้เห็นแล้วว่าเป็นหนึ่งในเมตริกที่มีประสิทธิภาพมากที่สุดซึ่งส่งผลดีต่อผลลัพธ์ทางธุรกิจ ด้วยจำนวนที่มากมายซึ่งเราได้สังเกตเห็นจากความพยายามนี้ เราจึงมีแรงจูงใจที่จะปรับขนาดความพยายามเพิ่มประสิทธิภาพของเราไปยังส่วนอื่นๆ ของเว็บไซต์ของเรา และเก็บเกี่ยวประโยชน์เพิ่มเติม