การปรับปรุง Core Web Vitals ในหน้าแรกของ Mail.ru ส่งผลให้อัตรา Conversion เพิ่มขึ้นเฉลี่ย 10%

การทำงานเป็นเวลาหลายเดือนเพื่อปรับปรุง Core Web Vitals ในหน้าแรกของ Mail.ru ส่งผลให้เปอร์เซ็นไทล์ที่ 75 ใน Cumulative Layout Shift (CLS) เพิ่มขึ้น 60% ทำให้ระยะเวลาเซสชันเฉลี่ยเพิ่มขึ้น 2.7% และอัตรา Conversion ของส่วนหลักเพิ่มขึ้นมากกว่า 10%

จุดเริ่มต้น

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

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

แม้ว่าโปรเจ็กต์นี้จะพัฒนามาเป็นเวลานานโดยใช้ Fest ซึ่งเป็นระบบเทมเพลตภายในบริษัท แต่เราก็เริ่มย้ายข้อมูลไปยัง Svelte 3 ในปี 2019

Svelte ใช้ความไวปฏิกิริยาในลักษณะที่ไม่ใช้ DOM เสมือน ซึ่งทำให้ใช้ทรัพยากรน้อยลง วิธีการของ Svelte จะนำฟังก์ชันที่ไม่ได้ใช้ออกจากแพ็กเกจเวอร์ชันที่ใช้งานจริง เนื่องจากคอมไพเลอร์จะไม่สร้างโค้ดที่ใช้งานฟังก์ชันเหล่านั้นหากไม่ได้ใช้ฟังก์ชัน โค้ดที่ไม่ได้ใช้งานจะถูกนำออกระหว่างการคอมไพล์ ซึ่งส่งผลให้แพ็กเกจมีขนาดเล็กลง ซึ่งอาจช่วยลดเวลาในการบล็อกทั้งหมด (TBT) ในระหว่างการเริ่มต้นหน้าเว็บได้

การติดตามเมตริกประสิทธิภาพ

ก่อนเพิ่มประสิทธิภาพ Core Web Vitals คุณควรประเมินประสิทธิภาพในภาคสนาม ก่อนที่จะมี Core Web Vitals เราติดตามเมตริกอื่นๆ เช่น First Contentful Paint (FCP) ในแดชบอร์ดประสิทธิภาพภายใน

สคริปต์รวบรวมเมตริกของเราได้รับการแก้ไขเพื่อรวบรวม Core Web Vitals และส่งสคริปต์ไปยังแดชบอร์ดประสิทธิภาพเพื่อดูภาพ สคริปต์ของเราใช้ PerformanceObserver API เพื่อรับเมตริก ซึ่งเป็นส่วนหนึ่งของฟรอนท์เอนด์สากล "Platform" ภายใน Mail.ru เพื่อให้สอดคล้องกับคำแนะนำของ Google

แดชบอร์ดแสดงเมตริกต่อไปนี้สำหรับผู้ใช้ (ค่าระหว่างวันที่ 15-21 มีนาคม 2021)

การปรับปรุง Core Web Vitals

แม้จะมีคำแนะนำมากมายสำหรับการปรับปรุง Core Web Vitals แต่ทุกโปรเจ็กต์ต่างก็มีความท้าทายที่ต่างกัน หน้าแรกของ Mail.ru ระบุโอกาสต่อไปนี้

• การใช้ตัวยึดตำแหน่งสำหรับแบนเนอร์โฆษณาเพื่อลด CLS
• ใช้การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) เพื่อลด Largest Contentful Paint (LCP)
• การแยกโค้ดเพื่อลด LCP และ First Input Delay (FID)

โครงกระดูกเพื่อการพัฒนา CLS

CLS คือหนึ่งในเมตริกฟิลด์ที่มีประสิทธิภาพแย่ที่สุดสำหรับหน้าแรกของ Mail.ru การสร้างโปรไฟล์ภายหลังสำหรับหน้านี้ในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บของ Chrome แสดงให้เห็นว่าโฆษณาเป็นสาเหตุของปัญหา ทีมของเราตัดสินใจที่จะใช้ตัวยึดตำแหน่งเพื่อจองพื้นที่สำหรับโฆษณาก่อนที่จะโหลดเพื่อปรับปรุงความเสถียรของเลย์เอาต์

เมื่อคุณใช้ตัวยึดตำแหน่ง ขั้นตอนแรกคือการกำหนดขนาดของเนื้อหาที่จะแทนที่ โชคดีที่หน้าแรกของ Mail.ru เวอร์ชันเดสก์ท็อปได้ระบุขนาดสำหรับโฆษณาไว้อย่างชัดเจน หลังจากพูดคุยกับทีมออกแบบแล้ว ก็มีการใช้โครงกระดูก UI ที่เคลื่อนไหวได้ของ SVG เป็นตัวยึดตำแหน่งเนื่องจากช่วยลดเวลาในการโหลดเนื้อหาที่รับรู้

การกลับมาของ SSR

เพื่อทำให้การเปลี่ยนจาก Fest ไปเป็น Svelte เป็นเรื่องง่าย เราจึงค่อยๆ เขียนโปรเจ็กต์ที่มีอยู่ใหม่แทนที่จะเริ่มใหม่ตั้งแต่ต้น ในเดือนมีนาคม 2021 เราได้ย้ายฟรอนท์เอนด์ส่วนใหญ่ไปยัง Svelte และได้นำ SSR มาใช้ในแอปพลิเคชันเวอร์ชันที่ใช้งานจริงหลังจากได้คัดกรองและแก้ไขปัญหาด้านประสิทธิภาพแบ็กเอนด์แล้วในเดือนมีนาคม 2021

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

แม้ว่าเครื่องมือสำหรับนักพัฒนาเว็บของ Chrome จะแสดงเหตุการณ์ Layout Shift แต่เราไม่สามารถค้นหาสาเหตุได้ แม้ว่า SSR จะไม่ใช่ปัญหา แต่ก็ช่วยในการค้นพบวิธีแก้ปัญหาในภายหลัง การแก้ไขโค้ดที่ทำให้เกิดการหน่วงเวลาภาพวาดช่วยปรับปรุงความเสถียรของเลย์เอาต์ของคอมโพเนนต์ News

ผลอีกอย่างหนึ่งของ SSR อาจมีต่อ CLS คือการเคลื่อนไหวของส่วนประกอบก่อนและหลังส่วนที่เป็นความชุ่มชื้น ซึ่งอาจนำไปสู่การเปลี่ยนแปลงของเลย์เอาต์เพิ่มเติม เราพบสิ่งนี้โดยเฉพาะในเวอร์ชันอุปกรณ์เคลื่อนที่ และจำเป็นต้องให้ความสนใจเป็นพิเศษกับมาร์กอัปคอมโพเนนต์ที่มีไฮเดรต วิธีแก้ปัญหาที่ดีสำหรับปัญหานี้คือการโอนตรรกะการแสดงผลจาก JavaScript ไปยัง CSS ให้ได้มากที่สุดเท่าที่จะเป็นไปได้

การแยกโค้ดและ Polyfill ที่ไม่ได้ใช้

ในการปรับปรุงความเร็วในการโหลดหน้าเว็บที่รับรู้ได้นั้น คุณต้องทำงานเพื่อลดค่า LCP และ FID วิธีหนึ่งที่สามารถทำได้คือการใช้การแยกโค้ด นอกเหนือจากหน้าแรกของ Mail.ru แล้ว ทีมของเรากำลังพัฒนาวิดเจ็ตสำหรับการนำทางพอร์ทัลด้วย ขณะนี้เครื่องมือดังกล่าวฝังอยู่ในหลายโครงการของบริษัทของเรา

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

เราตัดสินใจใช้รูปแบบ module/nomodule ในการโหลดกลุ่ม JavaScript สำหรับเบราว์เซอร์ที่ทันสมัยหรือแบบเดิม เนื่องจาก type="module" แอตทริบิวต์ขององค์ประกอบ <script> ไม่ได้กำหนดเป้าหมายเบราว์เซอร์ที่ทันสมัยตรงตามความต้องการของเรา เพื่อแก้ไขปัญหานี้ Mail.ru ใช้เครื่องมือภายในองค์กรเพื่อระบุเวอร์ชันของเบราว์เซอร์ที่ทันสมัยบนแบ็กเอนด์ และสามารถปรับใช้กับเบราว์เซอร์เหล่านั้นตามความเหมาะสม

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

นอกจากการลดขนาดกลุ่มและผลในเชิงบวกต่อ Core Web Vitals แล้ว การแยกโค้ดยังช่วยปรับปรุงประสบการณ์ของนักพัฒนาซอฟต์แวร์ด้วย มีเพียงผู้ใช้เพียง 3.5% ที่ใช้เบราว์เซอร์แบบเดิมและส่วนการแชร์ดังกล่าวมีแนวโน้มลดลง การใช้งานการแยกโค้ดจึงช่วยให้นักพัฒนาซอฟต์แวร์ใช้ API เบราว์เซอร์ล่าสุดได้โดยไม่ต้องเปิดตัวการเพิ่ม Polyfill ซึ่งจำเป็นสำหรับเบราว์เซอร์เวอร์ชันเก่าให้แก่ผู้ใช้ทั้งหมด

ผลลัพธ์

หลังจากความพยายามในการเพิ่มประสิทธิภาพ เราได้สังเกตค่าเฉลี่ยสำหรับสัปดาห์ที่ 24-30 พฤษภาคม 2021 ในข้อมูลภาคสนามของเรา ดังนี้

กราฟด้านล่างแสดงการเปลี่ยนแปลงของค่าเมตริกประสิทธิภาพของหน้าเว็บตาม "แพลตฟอร์ม" ดูวันที่ที่สำคัญ 2 วันที่ในกราฟ:

• 23 มีนาคม 2021: การเปิดตัวการปรับปรุงกับส่วนของหน้าสุดท้ายซึ่งย้ายไปยัง Svelte
• 19 เมษายน 2021: การเผยแพร่การทำซ้ำพร้อม SSR ที่ส่งคืนและเลย์เอาต์ที่แก้ไขเพื่อแก้ไขการถดถอย CLS

ค่าที่ลดลงตั้งแต่วันที่ 1 ถึง 10 พฤษภาคมเนื่องจากวันหยุดเดือนพฤษภาคมในรัสเซีย

ผลลัพธ์ที่ได้จากการใช้ "แพลตฟอร์ม" จะสอดคล้องกับการเพิ่มขึ้นของค่าเมตริกในรายงาน UX ของ Chrome (CrUX)

การเปรียบเทียบค่าระยะเวลาเซสชันเฉลี่ยของผู้ใช้ 1 สัปดาห์ก่อนเปิดตัวการปรับปรุงช่วงแรกและ 1 สัปดาห์หลังจากการเปิดตัวแสดงให้เห็นว่าเพิ่มขึ้น 2.7% นอกจากนี้ Conversion โดยรวมยังเพิ่มขึ้นอย่างมากในส่วนส่วนใหญ่ของหน้าเว็บ โดยเฉพาะอย่างยิ่ง Conversion ในแอปอีเมล Mail.ru เพิ่มขึ้น 11.6% ส่วน Conversion ของส่วนข่าวเพิ่มขึ้น 13.5%

ผลลัพธ์ที่ไม่คาดคิดที่สุดที่เราได้รับคือ อัตราการคลิกผ่าน (CTR) ของแบนเนอร์การตลาดเพิ่มขึ้น 17.4% (เวลาในการแสดงผลลดลงอย่างมากจากการเปิดตัวแท็ก SSR และการโหลดล่วงหน้า)

หลังจากวิเคราะห์ส่วนอื่นๆ ในหน้าเว็บแล้ว เราสังเกตเห็นว่าเนื้อหาส่วนใหญ่มีประสิทธิภาพดีขึ้นอย่างมาก แม้กระทั่งสำหรับหัวข้อต่างๆ เช่น สภาพอากาศและไวรัสโคโรนา ซึ่งไม่ใช่ข้อมูลสำคัญในหน้าของเรา แต่เราก็เห็น Conversion เพิ่มขึ้น 9.6% และ 9.5% ตามลำดับ

บทสรุป

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

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