กรณีศึกษานี้อธิบายขั้นตอนการทำงานโดยละเอียดของการแก้ไขข้อบกพร่องและการปรับปรุง INP
ใน React ที่ Trendyol ใช้โดยการใช้เครื่องมือของ Google เช่น PageSpeed
Insights (PSI), Chrome DevTools และ scheduler.yield
API
องค์ประกอบสำคัญ 2 อย่างของเว็บไซต์อีคอมเมิร์ซ ได้แก่ หน้าข้อมูลผลิตภัณฑ์ที่แสดง (PLP) และหน้ารายละเอียดผลิตภัณฑ์ (PDP) การเข้าชมอีคอมเมิร์ซมักจะมาจาก ไม่ว่าจะผ่านแคมเปญอีเมล โซเชียลมีเดีย หรือ โฆษณา ด้วยเหตุนี้ คุณจึงต้องตรวจสอบว่าประสบการณ์การใช้งาน PLP นั้น ได้รับการออกแบบมาอย่างพิถีพิถันเพื่อลดระยะเวลาที่ใช้ในการซื้อ การจัดลำดับความสำคัญ คุณภาพประสบการณ์ของผู้ใช้เป็นสิ่งสำคัญในการประสบความสำเร็จ สิ่งพิมพ์งานวิจัย เช่น มิลลิวินาทีทำให้นับล้าน ได้เผยให้เห็นถึง ผลกระทบจากประสิทธิภาพเว็บที่มีต่อผู้บริโภค ความเต็มใจในการใช้เงินและดึงดูด กับแบรนด์ทางออนไลน์
Trendyol เป็นแพลตฟอร์มอีคอมเมิร์ซที่มีลูกค้าประมาณ 30 ล้านรายและ ผู้ขาย 240,000 ราย ซึ่งกระตุ้นให้เราเป็นธุรกิจแรกในตุรกี มีมูลค่ามากกว่า $1 หมื่นล้าน และเป็นหนึ่งในแพลตฟอร์มอีคอมเมิร์ซชั้นนำ โลก
เพื่อให้บรรลุเป้าหมายในการมอบประสบการณ์ที่ดีที่สุดแก่ผู้ใช้ในวงกว้าง ขณะที่ยังคงความยืดหยุ่นของเนื้อหา และการทำงานร่วมกับ React โดย Trendsol เน้นที่ Interaction to Next Paint (INP) เป็นเมตริกหลักในการ เพื่อปรับปรุง กรณีศึกษานี้อธิบายถึงเส้นทางการปรับปรุง INP ของ Trendsol ใน PLP ส่งผลให้ INP ลดลง 50% และการค้นหาเพิ่มขึ้น 1% ของเมตริกทางธุรกิจของผลลัพธ์
กระบวนการตรวจสอบ INP ของ Trendsol
INP จะวัดการตอบสนองของเว็บไซต์ต่อข้อมูลจากผู้ใช้ INP ที่ดีบ่งชี้ว่า เบราว์เซอร์สามารถตอบสนองต่อข้อมูลจากผู้ใช้ ได้อย่างรวดเร็วและเชื่อถือได้ ซ่อมแซมหน้าเว็บอีกครั้ง ซึ่งเป็นองค์ประกอบสำคัญที่จะช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดี
เส้นทางการปรับปรุง INP ของ Trendsol ใน PLP เริ่มต้นด้วยการวิเคราะห์อย่างละเอียดถี่ถ้วนเกี่ยวกับ ประสบการณ์ของผู้ใช้ก่อนทำการปรับปรุง อ้างอิงจากรายงาน PSI ประสบการณ์ของผู้ใช้จริง PLP มี INP 963 มิลลิวินาทีเมื่อวันที่ อุปกรณ์เคลื่อนที่ ดังที่แสดงในรูปถัดไป
เพื่อให้มีการตอบสนองที่ดี เจ้าของเว็บไซต์ควรตั้งเป้าหมาย INP ด้านล่างหรือที่ 200 มิลลิวินาที ซึ่งหมายความว่า ณ เวลานั้น INP ของ Trendsol อยู่ใน "แย่"
โชคดีที่ PSI ให้ข้อมูลทั้ง 2 ช่องของหน้าที่รวมอยู่ในผู้ใช้ Chrome
รายงานประสบการณ์การใช้งาน (CrUX) และข้อมูลการวินิจฉัยในห้องทดลองโดยละเอียด กำลังดูห้องทดลอง
การตรวจสอบเวลาในการดำเนินการกับ JavaScript ของ Lighthouse ได้แนะว่า
สคริปต์ search-result-v2
ใช้งานเทรดหลักเป็นเวลานานกว่าสคริปต์อื่นๆ
สคริปต์บนหน้าเว็บ
เราใช้แผงประสิทธิภาพใน Chrome เพื่อระบุจุดคอขวดในโลกแห่งความเป็นจริง เครื่องมือสำหรับนักพัฒนาเว็บเพื่อแก้ปัญหาประสบการณ์ PLP และระบุแหล่งที่มาของ ปัญหา การจำลองประสิทธิภาพบนอุปกรณ์เคลื่อนที่ซึ่งมีการชะลอตัวของ CPU ใน Chrome DevTools ถึง 4 เท่า แสดงงานที่ยาว 700-900 มิลลิวินาทีในชุดข้อความหลัก หากหน้าหลัก เทรดมีงานอื่นๆ เป็นนานกว่า 50 มิลลิวินาที ดังนั้น ไม่สามารถตอบกลับข้อมูลจากผู้ใช้ได้อย่างทันท่วงที ส่งผลให้ ประสบการณ์ของผู้ใช้
งานที่ยาวที่สุดเกิดจากการเรียกกลับ Intersection Observer API ใน สคริปต์ผลการค้นหาภายในคอมโพเนนต์ React จุดนี้เราเริ่ม คือการแบ่งงานยาวๆ ให้เป็นงานเล็กๆ เพื่อเพิ่ม ตอบสนองต่องานที่มีลําดับความสําคัญสูงกว่า ซึ่งรวมถึงการโต้ตอบของผู้ใช้
ผลปรากฏว่าการใช้การดำเนินการ setState
ซึ่งทริกเกอร์ React
การแสดงผลอีกครั้งภายใน Callback ของ Intersection Observer มีค่าใช้จ่ายสูง
ซึ่งอาจสร้างปัญหาให้กับอุปกรณ์ระดับโลว์เอนด์โดยการใช้เทรดหลักสำหรับ
ยาวเกินไป
วิธีหนึ่งที่นักพัฒนาแอปใช้เพื่อแบ่งงานออกเป็นงานย่อยๆ
เกี่ยวข้องกับ setTimeout
เราใช้เทคนิคนี้เพื่อเลื่อนการดำเนินการของ
setState
เรียกใช้งานแยกต่างหาก แม้ว่า setTimeout
จะอนุญาตให้เลื่อนได้
การเรียกใช้ JavaScript ซึ่งไม่ได้ให้การควบคุมลำดับความสำคัญแต่อย่างใด นำมาสู่นี้
ให้เข้าร่วมช่วงทดลองใช้ scheduler.yield
จากต้นทางเพื่อรับประกัน
ความต่อเนื่องของการเรียกใช้สคริปต์ของเราหลังจากดำเนินการกับเทรดหลัก
/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
if('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
entries.forEach(handleIntersection);
const maxNumberOfEntries = Math.max(...this.intersectingEntries);
if (Number.isFinite(maxNumberOfEntries)) {
await this.yieldToMain();
this.setState({ count: maxNumberOfEntries });
}
}, { threshold: 0.5 });
การเพิ่มวิธีการให้ผลตอบแทนนี้ลงในโค้ด PLP ส่งผลให้ INP ดีขึ้น เนื่องจาก งานหลักที่ใช้เวลานานจึงแบ่งออกเป็นชุดย่อยๆ งานที่มีลำดับความสำคัญสูงกว่า เช่น การโต้ตอบของผู้ใช้และงานการแสดงผลที่ตามมา เพื่อ จะเกิดขึ้นเร็วกว่าที่เคย
โปรดทราบว่า Trendsol ใช้เฟรมเวิร์ก PuzzleJs เพื่อใช้งานฟรอนท์เอนด์แบบไมโคร โดยใช้ React v16.9.0 เมื่อใช้ React 18 ประสิทธิภาพเดียวกัน ของคุณ แต่ด้วยเหตุผลหลายประการทำให้ Trendsol ไม่สามารถอัปเกรด
ผลลัพธ์ทางธุรกิจ
ในการวัดผลกระทบของการปรับปรุง INP ที่นำไปใช้ เราได้ทำการทดสอบ A/B เพื่อ ดูว่าเมตริกธุรกิจได้รับผลกระทบอย่างไร โดยรวมแล้ว การเปลี่ยนแปลงใน PLP ส่งผลให้ ดีขึ้นอย่างมาก เช่น ลด INP ลง 50% และเพิ่มขึ้น 1% อัตราการคลิกผ่านที่เพิ่มขึ้นจากหน้าข้อมูลไปยังหน้ารายละเอียดผลิตภัณฑ์ ต่อเซสชันของผู้ใช้ ในภาพต่อไปนี้ คุณสามารถดูการปรับปรุง INP ของ PLP ในช่วงเวลาที่ผ่านมา:
บทสรุป
การเพิ่มประสิทธิภาพ INP เป็นกระบวนการที่ซับซ้อนและเป็นกระบวนการที่ต้องทำซ้ำๆ แต่สามารถทำได้ง่ายขึ้น มีเวิร์กโฟลว์ที่ชัดเจน วิธีง่ายๆ ในการแก้ไขข้อบกพร่องและการปรับปรุง INP ของเว็บไซต์ขึ้นอยู่กับว่าคุณรวบรวมข้อมูลภาคสนามของตนเองหรือไม่ หากคุณ ไม่ใช่ PSI และ Lighthouse คือจุดเริ่มต้นที่ดี เมื่อคุณระบุ หน้าที่มีปัญหา คุณสามารถใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อค้นหาข้อมูลเจาะลึกเพื่อพยายามจำลองเนื้อหาอีกครั้ง ปัญหา
อนุญาตชุดข้อความหลักเป็นครั้งคราวเพื่อให้เบราว์เซอร์ทำงานได้มากขึ้น
ในการจัดการงานที่เร่งด่วน จะทำให้เว็บไซต์ของคุณตอบสนองได้ดีขึ้น
เพื่อให้ลูกค้าได้รับประสบการณ์ของผู้ใช้ที่ดียิ่งขึ้น API การกำหนดเวลาที่ใหม่กว่า
เช่น scheduler.yield()
ทำให้งานนี้ง่ายขึ้น
ขอขอบคุณ Jeremy Wagner, Barry Pollard และ Houssein Djirdeh จาก Google และทีมวิศวกรของ Trendsol สำหรับการมีส่วนร่วมในงานนี้