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

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

Denis Stasyev
Denis Stasyev
GitHub
Sven May
Sven May
GitHub

จุดเริ่มต้น

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

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

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

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

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

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

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

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

ชื่อกลุ่มเมตริก Core Web Vitals Web Vitals อื่นๆ
ชื่อเมตริก LCP FID CLS FCP TBT TTI
ส่วนแบ่งผู้ใช้ตามเกณฑ์ของ Core Web Vitals ดี 52% 92% 33% 35% 42% 43%
needs-improvement 19% 5% 23% 38% 16% 25%
แย่ 29% 3% 44% 27% 42% 32%
เมตริกสำหรับสัปดาห์วันที่ 15-21 มีนาคม 2021
Core Web Vitals ก่อนการเพิ่มประสิทธิภาพแสดงให้เห็นว่าผู้ใช้ประมาณ 1 ใน 3 อยู่ในกลุ่ม "ไม่ดี"
ค่า Web Vitals ก่อนการปรับปรุง

การปรับปรุง 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 มาใช้กับแอปพลิเคชันเวอร์ชันที่ใช้งานจริงหลังจากประเมินและแก้ไขปัญหาด้านประสิทธิภาพของแบ็กเอนด์

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

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

JavaScript ที่ใช้งานอยู่จะแสดงหน้าว่างในส่วนข่าวเท่านั้น โดยจะซ่อนการกระโดดของเลย์เอาต์
การค้นหาปัญหาการวาดข่าวเมื่อปิดใช้ JavaScript
การปิดใช้ JavaScript จะแสดงการเปลี่ยนแปลงเลย์เอาต์ซึ่งก่อนหน้านี้ซ่อนจากสายตามนุษย์
การแก้ไขปัญหาการวาดข่าวเมื่อปิดใช้ JavaScript

ผลอีกอย่างหนึ่งที่ SSR อาจส่งผลต่อ CLS คือการเคลื่อนไหวของคอมโพเนนต์ก่อนและหลังการไฮเดรต ซึ่งอาจทําให้เลย์เอาต์เปลี่ยนเพิ่มเติม เราพบปัญหานี้ในเวอร์ชันอุปกรณ์เคลื่อนที่โดยเฉพาะ และจะต้องให้ความสำคัญเป็นพิเศษกับมาร์กอัปคอมโพเนนต์ที่ผ่าน Hydrate แล้ว วิธีที่ได้ผลดีในการแก้ปัญหานี้คือ โอนตรรกะการแสดงผลจาก 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 ในข้อมูลภาคสนาม ดังนี้

ชื่อกลุ่มเมตริก Core Web Vitals Web Vitals อื่นๆ
ชื่อเมตริก LCP FID CLS FCP TBT TTI
ส่วนแบ่งผู้ใช้ตามเกณฑ์ของ Core Web Vitals ดี 58% (+6%) 93% (+1%) 93% (+60%) 43% (+8%) 49% (+7%) 51% (+8%)
needs-improvement 18% 4% 3% 34% 17% 24%
แย่ 24% 3% 4% 23% 34% 25%
เมตริกสำหรับสัปดาห์วันที่ 24-30 มีนาคม 2021
เมตริกทั้งหมดในหมวดหมู่ &quot;ดี&quot; เพิ่มขึ้นอย่างน้อย 1% CLS ได้สูงสุดถึง 60%
การเปรียบเทียบ Web Vitals ก่อนและหลัง (การเปลี่ยนแปลงในกลุ่ม "ดี" จะแสดงในวงเล็บ)

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

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

ค่าที่ลดลงตั้งแต่วันที่ 1-10 พฤษภาคมเป็นเพราะวันหยุดในเดือนพฤษภาคมของรัสเซีย

LCP ตั้งแต่เดือนมีนาคมถึง 1 มิถุนายน 2021 แสดงการปรับปรุงเล็กน้อยเมื่อเวลาผ่านไป
กราฟ LCP ใน "แพลตฟอร์ม": 16 มีนาคมถึง 1 มิถุนายน 2021
FID ตั้งแต่วันที่ 16 มีนาคมถึง 1 มิถุนายน 2021 แสดงให้เห็นถึงการปรับปรุงเล็กน้อยในระดับสูง
กราฟ FID ใน "แพลตฟอร์ม": 16 มีนาคมถึง 1 มิถุนายน 2021
CLS ตั้งแต่วันที่ 16 มีนาคมถึง 1 มิถุนายน 2021 แสดงให้เห็นถึงการปรับปรุงอย่างมากตั้งแต่วันที่ 23 เมษายน
กราฟ CLS ใน "แพลตฟอร์ม": 16 มีนาคมถึง 1 มิถุนายน 2021

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

เมตริก LCP จาก CrUX เพิ่มขึ้นจาก 51% เป็น 58% ในกลุ่ม &quot;ดี&quot;
การเปลี่ยนแปลงเมตริก LCP ใน CrUX ในปี 2021
เมตริก FID จาก CrUX แสดงการปรับปรุง FID เล็กน้อยจาก 91% เป็น 93% ในกลุ่ม &quot;ดี&quot;
การเปลี่ยนแปลงเมตริก FID ใน CrUX ในปี 2021
เมตริก CLS ใน CrUX แสดงการปรับปรุงอย่างมากจาก 46% เป็น 98% ในกลุ่ม &quot;ดี&quot;
การเปลี่ยนแปลงเมตริก CLS ใน CrUX ในปี 2021

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

181%

เพิ่มส่วนแบ่งของเกณฑ์ CLS ที่ดี

2.7%

ระยะเวลาเซสชันเฉลี่ยสูงขึ้น

13.5%

อัตรา Conversion ของส่วนข่าวเพิ่มขึ้น

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

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

บทสรุป

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

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