วิธีที่ Mercado Libre เพิ่มประสิทธิภาพเพื่อ Web Vitals (TBT/FID)

การเพิ่มประสิทธิภาพการโต้ตอบของหน้ารายละเอียดผลิตภัณฑ์เพื่อลด FID สูงสุดที่เป็นไปได้ 90% ใน Lighthouse และเพิ่ม FID เพิ่มขึ้น 9% ในรายงานประสบการณ์ของผู้ใช้ Chrome

Carlos Aranha

Demián Renzulli

Joan Baca

Mercado Libre เป็นระบบนิเวศอีคอมเมิร์ซและการชำระเงินที่ใหญ่ที่สุดในลาตินอเมริกา โดยให้บริการใน 18 ประเทศ และเป็นผู้นำตลาดในบราซิล เม็กซิโก และอาร์เจนตินา (อิงตามผู้เข้าชมที่ไม่ซ้ำและการดูหน้าเว็บ)

บริษัทมุ่งเน้นเรื่องประสิทธิภาพเว็บมานานแล้ว แต่เมื่อเร็วๆ นี้ บริษัทได้จัดตั้งทีมเพื่อตรวจสอบประสิทธิภาพและนำการปรับปรุงไปใช้ในส่วนต่างๆ ของเว็บไซต์

บทความนี้สรุปผลงานของ Guille Paz, Pablo Carminatti และ Oleh Burkhay จากทีมสถาปัตยกรรมฟรอนท์เอนด์ของ Mercado Libre เพื่อเพิ่มประสิทธิภาพ หนึ่งใน Core Web Vitals นั่นคือ First Input Delay (FID) และพร็อกซีของห้องทดลอง Total block Time (TBT)

งานที่ใช้เวลานาน, First Input Delay และเวลาทั้งหมดในการบล็อก

การเรียกใช้โค้ด JavaScript ราคาแพงอาจทำให้เกิดงานที่ใช้เวลานาน ซึ่งก็คือการทำงานที่ทำงานนานกว่า 50 มิลลิวินาทีในเทรดหลักของเบราว์เซอร์

FID (First Input Delay) จะวัดระยะเวลาตั้งแต่ที่ผู้ใช้โต้ตอบกับหน้าเว็บเป็นครั้งแรก (เช่น เมื่อผู้ใช้คลิกลิงก์) จนถึงตอนที่เบราว์เซอร์เริ่มประมวลผลเครื่องจัดการเหตุการณ์เพื่อตอบสนองต่อการโต้ตอบนั้นจริงๆ เว็บไซต์ที่เรียกใช้โค้ด JavaScript ราคาแพงมักจะมีงานที่ใช้เวลานานหลายงาน ซึ่งจะส่งผลเสียต่อ FID

เพื่อมอบประสบการณ์การใช้งานที่ดีแก่ผู้ใช้ เว็บไซต์ควรพยายามให้ First Input Delay น้อยกว่า 100 มิลลิวินาที ดังนี้

แม้ว่าเว็บไซต์ Mercado Libre มีประสิทธิภาพดีในหลายๆ ส่วน แต่เว็บไซต์กลับพบในรายงานประสบการณ์ของผู้ใช้ Chrome ว่าหน้ารายละเอียดผลิตภัณฑ์มี FID ต่ำ จากข้อมูลดังกล่าว พวกเขาตัดสินใจที่จะปรับปรุงการโต้ตอบสำหรับหน้าผลิตภัณฑ์ในเว็บไซต์

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

วัดการโต้ตอบของหน้ารายละเอียดผลิตภัณฑ์

FID ต้องใช้ผู้ใช้จริง ดังนั้นจึงวัดในห้องทดลองไม่ได้ อย่างไรก็ตาม เมตริก Total Blocked Time (TBT) ที่วัดได้ในห้องทดลอง มีความสัมพันธ์ที่ดีกับ FID ในภาคสนาม และยังบันทึกปัญหาที่ส่งผลต่อการโต้ตอบด้วย

ตัวอย่างเช่น ในการติดตามต่อไปนี้ ขณะที่เวลาทั้งหมดที่ใช้ในการทำงานในเทรดหลักคือ 560 มิลลิวินาที แต่มีเพียง 345 มิลลิวินาทีเท่านั้นที่ถือว่าเป็นเวลาในการบล็อกทั้งหมด (ผลรวมของส่วนต่างๆ ของแต่ละงานที่เกิน 50 มิลลิวินาที)

Mercado Libre ใช้ TBT เป็นเมตริกพร็อกซีในห้องทดลองเพื่อวัดและปรับปรุงการโต้ตอบของหน้ารายละเอียดผลิตภัณฑ์ในชีวิตจริง

วิธีการทั่วไปที่บริษัทใช้มีดังนี้

• ใช้ WebPageTest เพื่อพิจารณาว่าสคริปต์ใดทำให้เทรดหลักไม่ว่างบนอุปกรณ์จริง
• ใช้ Lighthouse เพื่อระบุผลกระทบของการเปลี่ยนแปลงใน Max Potential First Input Delay (Max Potential FID)

ใช้ WebPageTest เพื่อแสดงภาพงานที่ใช้เวลานาน

WebPageTest (WPT) เป็นเครื่องมือประสิทธิภาพเว็บที่ให้คุณเรียกใช้การทดสอบบนอุปกรณ์จริงในที่ต่างๆ ทั่วโลก

Mercado Libre ใช้ WPT เพื่อสร้างประสบการณ์การใช้งานของผู้ใช้ซ้ำโดยการเลือกประเภทอุปกรณ์และสถานที่ที่คล้ายกับผู้ใช้จริง โดยเฉพาะอย่างยิ่งพวกเขาเลือกอุปกรณ์โมโต 4G และ Dulles จากเวอร์จิเนีย เนื่องจากต้องการนำเสนอประสบการณ์ของผู้ใช้ Mercado Libre ในเม็กซิโก เมื่อสังเกตมุมมองเทรดหลักของ WPT แล้ว Mercado Libre พบว่ามีการทำงานยาวต่อเนื่องกันหลายงานซึ่งบล็อกเทรดหลักเป็นเวลา 2 วินาที ดังนี้

จากการวิเคราะห์ Waterfall ที่สัมพันธ์กันพบว่าส่วนสำคัญของ 2 วินาทีนั้นมาจากโมดูลข้อมูลวิเคราะห์ ขนาด Bundle หลักของแอปพลิเคชันนั้นใหญ่ (950 KB) และใช้เวลานานในการแยกวิเคราะห์ คอมไพล์ และดำเนินการ

ใช้ Lighthouse เพื่อระบุ FID สูงสุดที่อาจเกิดขึ้น

Lighthouse ไม่อนุญาตให้คุณเลือกระหว่างอุปกรณ์และตำแหน่งที่แตกต่างกัน แต่เครื่องมือนี้มีประโยชน์มากสำหรับการวินิจฉัยเว็บไซต์และรับคำแนะนำด้านประสิทธิภาพ

เมื่อเรียกใช้ Lighthouse ในหน้ารายละเอียดผลิตภัณฑ์ Mercado Libre พบว่า Max Potential FID เป็นเมตริกเดียวที่ทำเครื่องหมายเป็นสีแดงด้วยค่า 1710 ms

จากข้อมูลนี้ Mercado Libre ตั้งเป้าหมายที่จะปรับปรุงคะแนน FID สูงสุดที่เป็นไปได้ในเครื่องมือของห้องทดลอง เช่น Lighthouse และ WebPageTest โดยมีสมมติฐานว่าการปรับปรุงเหล่านี้จะส่งผลต่อผู้ใช้จริง จึงแสดงในเครื่องมือการตรวจสอบผู้ใช้จริง เช่น รายงานประสบการณ์ของผู้ใช้ Chrome

เพิ่มประสิทธิภาพงานที่ใช้เวลานาน

การทำซ้ำครั้งแรก

Mercado Libre ได้ตั้งเป้าหมายในการเพิ่มประสิทธิภาพโมดูล 2 ที่ใช้โค้ดราคาแพงโดยพิจารณาจากการติดตามเทรดหลัก

ทางทีมได้เริ่มเพิ่มประสิทธิภาพของโมดูลการติดตามภายในแล้ว โมดูลนี้มีงานที่หนักของ CPU ซึ่งไม่สำคัญต่อการทำงานของโมดูล ดังนั้นจึงควรถูกนำออกอย่างปลอดภัย ส่งผลให้ JavaScript ทั้งเว็บไซต์ลดลง 2%

หลังจากนั้น พวกเขาก็เริ่มปรับปรุงขนาด Bundle ทั่วไปดังนี้

Mercado Libre ใช้ webpack-bundle-analyzer เพื่อตรวจหาโอกาสสำหรับการเพิ่มประสิทธิภาพ

• ในตอนแรกพวกเขาต้องการโมดูล Lodash แบบเต็ม โดยเราแทนที่ฟีเจอร์นี้ด้วยการกำหนดแต่ละวิธีให้โหลดเฉพาะ Lodash บางส่วนแทนที่จะโหลดทั้งคลัง และใช้ร่วมกับปลั๊กอิน Lodash-webpack-plugin เพื่อย่อ Lodash แม้แต่ในภายหลัง

และยังใช้การเพิ่มประสิทธิภาพ Babel ต่อไปนี้ด้วย

• การใช้ @babel/plugin-transform-runtime เพื่อนำตัวช่วยของ Babel กลับมาใช้ซ้ำตลอดทั้งโค้ดและลดขนาดของ Bundle ลงได้อย่างมาก
• ใช้ babel-plugin-search-and-replace เพื่อแทนที่โทเค็น ณ เวลาที่สร้างเพื่อนำไฟล์การกำหนดค่าขนาดใหญ่ภายในแพ็กเกจหลักออก
• การเพิ่ม babel-plugin-transform-react-remove-prop-types เพื่อประหยัดไบต์เพิ่มเติมโดยนำประเภทพร็อพเพอร์ออก

การเพิ่มประสิทธิภาพเหล่านี้ทำให้ขนาดแพ็กเกจลดลงประมาณ 16%

วัดผลกระทบ

การเปลี่ยนแปลงนี้ลดปริมาณงานที่ยาวติดต่อกันของ Mercado Libre ลงจาก 2 วินาทีเหลือ 1 วินาที ดังนี้

Lighthouse แสดงความล่าช้าของอินพุตแรกที่อาจเกิดขึ้นสูงสุดลดลง 57%:

การทำซ้ำครั้งที่ 2

ทีมยังคงค้นหางานยาวๆ ต่อไปเพื่อหาการปรับปรุงในภายหลัง

จากข้อมูลดังกล่าว พวกเขาตัดสินใจที่จะใช้การเปลี่ยนแปลงต่อไปนี้

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

วัดผลกระทบ

การติดตาม WebPageTest ที่ได้แสดงการดำเนินการ JS เป็นส่วนๆ ที่เล็กลง

และเวลาสูงสุดที่เป็นไปได้ FID ใน Lighthouse ลดลงเพิ่มขึ้น 60% ดังนี้

แสดงภาพความคืบหน้าสำหรับผู้ใช้จริง

แม้ว่าเครื่องมือทดสอบจากห้องปฏิบัติการอย่าง WebPageTest และ Lighthouse จะเหมาะอย่างยิ่งสำหรับการปรับปรุงโซลูชันในระหว่างการพัฒนา แต่เป้าหมายที่แท้จริงคือการปรับปรุงประสบการณ์ของผู้ใช้จริง

รายงานประสบการณ์ของผู้ใช้ Chrome จะแสดงเมตริกประสบการณ์ของผู้ใช้สำหรับประสบการณ์ที่ผู้ใช้ Chrome ในชีวิตจริงได้รับจากจุดหมายยอดนิยมบนเว็บ คุณจะใช้ข้อมูลจากรายงานได้โดยการเรียกใช้การค้นหาใน BigQuery, PageSpeedInsights หรือ CrUX API

แดชบอร์ด CrUX เป็นวิธีง่ายๆ ในการแสดงภาพความคืบหน้าของเมตริกหลัก ได้แก่

ขั้นตอนถัดไป

ประสิทธิภาพของเว็บไม่ใช่งานที่เสร็จสิ้น และ Mercado Libre เข้าใจถึงคุณค่าที่การเพิ่มประสิทธิภาพเหล่านี้มอบให้แก่ผู้ใช้ แม้ว่าทางบริษัทยังคงใช้การเพิ่มประสิทธิภาพหลายอย่างในเว็บไซต์ต่อไป ซึ่งรวมถึงการดึงข้อมูลล่วงหน้าในหน้าข้อมูลผลิตภัณฑ์ที่แสดง การเพิ่มประสิทธิภาพรูปภาพ และอื่นๆ แต่ก็ยังคงเพิ่มการปรับปรุงหน้าข้อมูลผลิตภัณฑ์ที่แสดงอย่างต่อเนื่องเพื่อลดเวลาในการบล็อกรวม (TBT) และด้วย FID ของพร็อกซี และอื่นๆ อีกมากมาย การเพิ่มประสิทธิภาพเหล่านี้ รวมถึงสิ่งต่อไปนี้

• กำลังทำซ้ำในโซลูชันการแยกโค้ด
• การปรับปรุงการเรียกใช้สคริปต์ของบุคคลที่สาม
• การปรับปรุงการรวมแพ็กเกจเนื้อหาอย่างต่อเนื่องที่ระดับ Bundler (Webpack)

Mercado Libre มองเห็นภาพรวมของประสิทธิภาพได้ ดังนั้นแม้บริษัทจะเพิ่มประสิทธิภาพการโต้ตอบในเว็บไซต์อย่างต่อเนื่อง ทางบริษัทก็ได้เริ่มประเมินโอกาสในการปรับปรุง Core Web Vitals ปัจจุบันอีก 2 รายการ ได้แก่ LCP (Largest Contentful Paint) และ CLS (Cumulative Layout Shift) เพิ่มมากขึ้น