Zalando ลดเวลาแสดงความคิดเห็นเกี่ยวกับประสิทธิภาพจาก 1 วันเหลือ 15 นาทีด้วย Lighthouse CI

ทีมดูแลเว็บของ Zalando พบว่าการผสานรวม CI ของ Lighthouse ช่วยเพิ่มประสิทธิภาพในเชิงรุกได้ โดยมีการตรวจสอบสถานะอัตโนมัติที่สามารถเปรียบเทียบสัญญาผูกมัดปัจจุบันกับสาขาหลักเพื่อป้องกันการถดถอยด้านประสิทธิภาพ

Jan Brockmeyer

Jeremy Colin

หมายเหตุ: กรณีศึกษานี้เขียนโดย Jeremy Colin และ Jan Brockmeyer จากทีมโครงสร้างพื้นฐานของเว็บของ Zalando

Zalando เป็นแพลตฟอร์มแฟชั่นออนไลน์ชั้นนำของยุโรปที่มีลูกค้าที่ใช้งานอยู่มากกว่า 35 ล้านคน ในโพสต์นี้ เราจะอธิบายเหตุผลที่เราเริ่มใช้ CI ของ Lighthouse, ความสะดวกในการใช้งาน และข้อดีที่มีต่อทีมของเรา

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

100 _{มิลลิวินาที}

การปรับปรุงเวลาในการโหลดหน้าเว็บ

0.7_%

รายได้เพิ่มขึ้นต่อเซสชัน

การยอมรับจากบริษัทไม่ได้แปลไปสู่ประสิทธิภาพเสมอไป

แม้ว่าภายในบริษัทจะมีประสิทธิภาพที่ดีพอสมควร แต่หากไม่ได้กำหนดประสิทธิภาพเป็นเกณฑ์การนำส่งผลิตภัณฑ์ ก็อาจทำให้หล่นผ่านไปได้ง่าย เมื่อออกแบบเว็บไซต์ Zalando ใหม่ในปี 2020 เรามุ่งเน้นที่การนำเสนอฟีเจอร์ใหม่ๆ ขณะเดียวกันก็ยังคงรักษาประสบการณ์ที่ยอดเยี่ยมของผู้ใช้ไว้ รวมถึงการปรับโฉมเว็บไซต์ด้วยแบบอักษรที่กำหนดเองและสีสันที่สดใสมีชีวิตชีวายิ่งขึ้น อย่างไรก็ตาม เมื่อเว็บไซต์และแอปที่ออกแบบใหม่พร้อมเปิดตัว เมตริกผู้ใช้ในช่วงแรกก็เปิดเผยว่าเวอร์ชันใหม่ทำงานช้าลง First Contentful Paint ทำงานช้าลงสูงสุดถึง 53% และเวลาที่ใช้ในการวัดผลจากเมตริก Time to Interactive รายงานว่าช้าลงถึง 59%

เว็บที่ Zalando

เว็บไซต์ Zalando สร้างโดยทีมหลักที่พัฒนาเฟรมเวิร์กโดยมีทีมฟีเจอร์กว่า 15 ทีมที่ช่วยสร้าง Microservice แบบฟรอนท์เอนด์ นอกจากจะรองรับรุ่นใหม่แล้ว เรายังได้เปลี่ยนบางส่วนของเว็บไซต์ให้ใช้สถาปัตยกรรมที่เป็นศูนย์กลางมากขึ้น

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

Web Vitals และ Lighthouse เป็นผู้ช่วยเหลือ

เราไม่ได้พึงพอใจกับเมตริกภายในบริษัท เนื่องจากเมตริกเหล่านั้นปรับเข้ากับการตั้งค่าใหม่ไม่ได้ ที่สำคัญกว่านั้นคือ ไม่ได้มุ่งเน้นที่ประสบการณ์ของลูกค้า เราเปลี่ยนไปใช้ Core Web Vitals เนื่องจากมีชุดเมตริกที่กระชับ แต่ครอบคลุม และมุ่งเน้นผู้ใช้เป็นหลัก

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

แสดงความคิดเห็นด้านประสิทธิภาพแก่นักพัฒนาซอฟต์แวร์เกี่ยวกับคำขอพุล

เราไม่ได้ต้องการหยุดเพียงเท่านี้ เนื่องจากเราต้องการใช้โอกาสนี้ในการไม่เพียงแต่ตอบรับเรื่องประสิทธิภาพเท่านั้น แต่ยังเป็นเชิงรุกด้วย การข้ามจากโมดูลโหนด Lighthouse ไปยังเซิร์ฟเวอร์ CI (LHCI) ของ Lighthouse ไม่ใช่เรื่องยากเกินไป เราเลือกใช้โซลูชันแบบโฮสต์ด้วยตนเองเพื่อให้เราผสานรวมกับบริการของบริษัทที่มีอยู่ได้ดียิ่งขึ้น แอปพลิเคชันเซิร์ฟเวอร์ LHCI สร้างขึ้นเป็นอิมเมจ Docker ซึ่งจากนั้นจะทำให้ใช้งานได้กับคลัสเตอร์ Kubernetes ร่วมกับฐานข้อมูล PostgreSQL และรายงานไปยัง GitHub

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

การตรวจสอบสถานะ CI GitHub ของ Lighthouse ช่วยให้นักพัฒนาแอปเข้าใจการถดถอยและแก้ไขปัญหาได้ก่อนที่จะถึงเวอร์ชันที่ใช้งานจริง

รายงานคอมมิตโดยละเอียดของ Lighthouse CI เมื่อเทียบกับสาขาหลัก

การขยายความครอบคลุมของประสิทธิภาพ

เราเริ่มต้นด้วยแนวทางที่ปฏิบัติได้จริง ปัจจุบัน Lighthouse ทำงานในหน้าที่สำคัญที่สุด 2 หน้าเท่านั้น ได้แก่ หน้าแรกและหน้ารายละเอียดผลิตภัณฑ์ โชคดีที่ CI ของ Lighthouse ช่วยให้ขยายการกำหนดค่าการเรียกใช้ได้อย่างง่ายดาย ทีมฟีเจอร์ที่ทำงานในหน้าเว็บที่เจาะจงของเว็บไซต์สามารถตั้งค่ารูปแบบ URL และการยืนยันที่ตรงกันได้ ด้วยสถานการณ์นี้ เราจึงมั่นใจมากว่าความครอบคลุมของประสิทธิภาพของเราจะเพิ่มขึ้น

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