Sau nhiều tháng nỗ lực cải thiện Các chỉ số quan trọng về trang web trên trang chủ của Mail.ru, điểm số tổng hợp về Mức thay đổi bố cục tích luỹ (CLS) ở phân vị thứ 75 đã tăng 60%, thời lượng phiên trung bình tăng 2,7% và tỷ lệ chuyển đổi của các phần cốt lõi tăng hơn 10%.
Bắt đầu từ đâu
Mail.ru là một trong những dịch vụ email hàng đầu trên Internet bằng tiếng Nga và có mặt trong 5 trang web hàng đầu ở Nga về lưu lượng truy cập. Mail.ru là một tài nguyên quan trọng đối với nhiều người. Trang web này nhận được vài trăm triệu lượt truy cập mỗi tháng và là một cổng thông tin nơi mọi người có thể truy cập vào email, tin tức, mạng xã hội, nội dung tìm kiếm hiệu suất trên Internet và nhiều nội dung khác.
Mail.ru muốn mang đến cho khách truy cập trải nghiệm chất lượng cao, vì vậy, họ bắt đầu cải thiện Các chỉ số quan trọng về trang web. Trước khi thảo luận về chiến lược tối ưu hoá, trước tiên, bạn cần lưu ý một số thông tin kỹ thuật về trang chủ Mail.ru.
Mặc dù dự án đã được phát triển từ lâu bằng công cụ tạo mẫu nội bộ Fest, nhưng chúng tôi đã bắt đầu di chuyển sang Svelte 3 vào năm 2019.
Svelte triển khai tính năng phản ứng theo cách không sử dụng DOM ảo, nhờ đó giảm mức sử dụng tài nguyên. Phương pháp của Svelte sẽ xoá các hàm không dùng đến khỏi gói phát hành chính thức vì trình biên dịch sẽ không tạo mã triển khai các hàm đó nếu các hàm đó không được sử dụng. Mã không sử dụng sẽ bị xoá trong quá trình biên dịch, dẫn đến các gói nhỏ hơn. Điều này có thể giúp giảm Tổng thời gian chặn (TBT) trong quá trình khởi động trang.
Theo dõi các chỉ số hiệu suất
Trước khi tối ưu hoá Các chỉ số quan trọng về trang web, bạn nên đánh giá hiệu suất trong thực tế. Trước khi có Chỉ số quan trọng chính của trang web, chúng tôi đã theo dõi các chỉ số khác, chẳng hạn như Hiển thị nội dung đầu tiên (FCP), trong trang tổng quan về hiệu suất nội bộ.
Chúng tôi đã sửa đổi tập lệnh thu thập chỉ số để thu thập Core Web Vitals và truyền các chỉ số này đến trang tổng quan về hiệu suất để hiển thị. Theo đề xuất của Google, tập lệnh của chúng tôi sử dụng PerformanceObserver API để lấy các chỉ số. Đây là một phần của "Nền tảng" giao diện người dùng chung bên trong Mail.ru.
Trang tổng quan hiển thị các chỉ số sau đây cho người dùng (giá trị trung bình trong tuần từ ngày 15 đến ngày 21 tháng 3 năm 2021):
| Tên nhóm chỉ số | Các chỉ số quan trọng về trang web | Các chỉ số quan trọng khác về trang web | |||||
|---|---|---|---|---|---|---|---|
| Tên chỉ số | LCP (Thời gian hiển thị nội dung lớn nhất) | FID (Thời gian phản hồi lần tương tác đầu tiên) | CLS (Điểm số tổng hợp về mức thay đổi bố cục) | FCP (hiển thị nội dung đầu tiên) | TBT | TTI | |
| Tỷ lệ người dùng tuân thủ các ngưỡng của Core Web Vitals | thú vị | 52% | 92% | 33% | 35% | 42% | 43% |
| cần-cải-thiện | 19% | (5%) | 23% | 38% | 16% | 25% | |
| kém | 29% | 3% | 44% | 27% | 42% | 32% | |
Cải thiện các chỉ số quan trọng về trang web
Mặc dù có nhiều hướng dẫn để cải thiện Chỉ số quan trọng chính của trang web, nhưng mỗi dự án đều có những thách thức riêng. Đối với trang chủ Mail.ru, chúng tôi đã xác định được những cơ hội sau:
- Triển khai phần giữ chỗ cho biểu ngữ quảng cáo để giảm CLS.
- Sử dụng tính năng hiển thị phía máy chủ (SSR) để giảm Thời gian hiển thị nội dung lớn nhất (LCP).
- Phân tách mã để giảm LCP và Thời gian phản hồi lần tương tác đầu tiên (FID).
Bộ xương để cải thiện CLS
CLS là một trong những chỉ số thực tế có hiệu suất kém nhất đối với trang chủ Mail.ru. Sau đó, việc phân tích trang này trong bảng điều khiển Hiệu suất của Công cụ của Chrome cho nhà phát triển cho thấy quảng cáo là nguồn gốc của vấn đề. Để cải thiện độ ổn định của bố cục, nhóm chúng tôi đã quyết định sử dụng phần giữ chỗ để đặt trước không gian cho quảng cáo trước khi quảng cáo tải.
Khi triển khai phần giữ chỗ, bước đầu tiên là xác định kích thước của nội dung sẽ thay thế phần giữ chỗ. May mắn là phiên bản trang chủ Mail.ru dành cho máy tính để bàn đã ghi nhận nghiêm ngặt kích thước quảng cáo. Sau khi trao đổi với nhóm thiết kế, chúng tôi đã sử dụng khung giao diện người dùng động SVG làm phần giữ chỗ vì khung này giúp giảm thời gian tải nội dung.
SSR trở lại
Để dễ dàng chuyển đổi từ Fest sang Svelte, chúng tôi đã viết lại dần dần dự án hiện có thay vì bắt đầu lại. Đến tháng 3 năm 2021, chúng tôi đã di chuyển hầu hết phần giao diện người dùng sang Svelte và cuối cùng đã đưa SSR vào ứng dụng chính thức sau khi phân loại và khắc phục các vấn đề về hiệu suất của phần phụ trợ.
Sau khi triển khai SSR, nhóm nghiên cứu đã phát hiện nguyên nhân gây ra sự hồi quy CLS mà ban đầu không được chú ý: phần tin tức không được chèn vào thời điểm hiển thị nội dung đầu tiên trên trang. Có độ trễ giữa lần vẽ đầu tiên của mã đánh dấu trang do máy chủ cung cấp và lần chèn phần tin tức trên ứng dụng. Hành vi này dẫn đến việc thay đổi khung quảng cáo, khiến CLS trở nên tệ hơn.
Mặc dù Công cụ dành cho nhà phát triển của Chrome cho thấy các sự kiện Layout Shift, nhưng ban đầu chúng tôi không tìm thấy lý do. Mặc dù SSR không phải là vấn đề, nhưng nó đã giúp phát hiện ra giải pháp sau này. Việc sửa mã chịu trách nhiệm về độ trễ vẽ đã cải thiện độ ổn định của bố cục thành phần tin tức.
Một hiệu ứng khác mà SSR có thể gây ra đối với CLS là việc di chuyển các thành phần trước và sau khi hydrat hoá, điều này có thể dẫn đến sự thay đổi bố cục hơn nữa. Chúng tôi gặp phải vấn đề này trên phiên bản dành cho thiết bị di động và cần đặc biệt chú ý đến mã đánh dấu thành phần đã hydrat hoá. Một giải pháp hay cho vấn đề này là chuyển càng nhiều logic hiển thị từ JavaScript sang CSS càng tốt khi có thể.
Phân tách mã và các đoạn mã polyfill không dùng đến
Để cải thiện tốc độ tải trang được cảm nhận, chúng tôi cần phải giảm các giá trị LCP và FID. Một cách để đạt được điều này là thông qua tính năng phân tách mã. Ngoài trang chủ Mail.ru, nhóm chúng tôi đang phát triển một tiện ích để điều hướng cổng thông tin. Công cụ này hiện được nhúng trong nhiều dự án của công ty chúng tôi.
Vì lý do lịch sử, tiện ích được chèn vào ngay đầu trang dưới dạng tập lệnh tải đồng bộ. Tỷ lệ phần trăm polyfill trong tập lệnh này đã tăng lên theo thời gian. Để hạn chế tác động tiêu cực đến hiệu suất khi tải các polyfill này, chúng tôi đã triển khai tính năng phân tách mã cho cả trình duyệt hiện đại và trình duyệt cũ.
Chúng tôi quyết định không sử dụng mẫu module/nomodule để tải các gói JavaScript cho trình duyệt hiện đại hoặc cũ, vì thuộc tính type="module" của phần tử <script> không nhắm đến các trình duyệt đủ hiện đại cho nhu cầu của chúng tôi. Để giải quyết vấn đề này, Mail.ru sử dụng một công cụ nội bộ để xác định các phiên bản trình duyệt hiện đại ở phần phụ trợ và có thể điều chỉnh cho phù hợp với các trình duyệt đó.
Sau khi xác định được trình duyệt trong phần phụ trợ, chúng tôi đã triển khai tính năng phân tách mã cho trình duyệt hiện đại và trình duyệt cũ. Kết quả là kích thước của tiện ích JavaScript được tải đồng bộ cho các trình duyệt hiện đại đã giảm 43,3%. Phương pháp này cũng được áp dụng cho một số tập lệnh cổng thông tin khác.
Ngoài việc giảm kích thước gói và tác động tích cực đến Các chỉ số quan trọng về trang web, tính năng phân tách mã cũng cải thiện trải nghiệm của nhà phát triển. Chỉ có 3,5% người dùng sử dụng trình duyệt cũ và tỷ lệ này đang có xu hướng giảm.Vì vậy, việc triển khai tính năng phân tách mã cho phép các nhà phát triển sử dụng các API trình duyệt mới nhất mà không cần giới thiệu polyfill cho tất cả người dùng.
Kết quả
Sau khi tối ưu hoá, chúng tôi đã quan sát thấy các giá trị trung bình trong tuần từ ngày 24 đến ngày 30 tháng 5 năm 2021 trong dữ liệu thực địa:
| Tên nhóm chỉ số | Các chỉ số quan trọng về trang web | Các chỉ số quan trọng khác về trang web | |||||
|---|---|---|---|---|---|---|---|
| Tên chỉ số | LCP (Thời gian hiển thị nội dung lớn nhất) | FID (Thời gian phản hồi lần tương tác đầu tiên) | CLS (Điểm số tổng hợp về mức thay đổi bố cục) | FCP (hiển thị nội dung đầu tiên) | TBT | TTI | |
| Tỷ lệ người dùng tuân thủ các ngưỡng của Core Web Vitals | thú vị | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| cần-cải-thiện | 18% | 4% | 3% | 34% | 17% | 24% | |
| kém | 24% | 3% | 4% | 23% | 34% | 25% | |
Các biểu đồ dưới đây cho thấy sự thay đổi về giá trị của các chỉ số hiệu suất trang web theo "Nền tảng". Lưu ý hai ngày quan trọng trên biểu đồ:
- Ngày 23 tháng 3 năm 2021: phát hành bản lặp với các phần trang cuối cùng được di chuyển sang Svelte;
- Ngày 19 tháng 4 năm 2021: phát hành bản lặp lại với SSR được trả về và bố cục được sửa đổi để sửa lỗi hồi quy CLS.
Giá trị giảm từ ngày 1 tháng 5 đến ngày 10 tháng 5 là do các ngày lễ tháng 5 ở Nga.
Kết quả thu được khi sử dụng "Nền tảng" phù hợp với mức tăng của các giá trị chỉ số trong Báo cáo trải nghiệm người dùng trên Chrome (CrUX).
Bản so sánh các giá trị trung bình về thời lượng phiên của người dùng một tuần trước khi triển khai các điểm cải tiến ban đầu và một tuần sau khi triển khai cho thấy mức tăng trưởng 2,7%. Hơn nữa, tổng thể số lượt chuyển đổi đã tăng đáng kể ở hầu hết các phần của trang. Cụ thể, số lượt chuyển đổi sang ứng dụng email Mail.ru tăng 11,6%, số lượt chuyển đổi của mục tin tức tăng 13,5%.
181%
Tăng tỷ lệ phần trăm ngưỡng CLS tốt
2,7%
Thời lượng phiên trung bình cao hơn
13,5%
Tăng tỷ lệ chuyển đổi của mục tin tức
Kết quả ngoài mong đợi nhất mà chúng tôi nhận được là Tỷ lệ nhấp (CTR) của biểu ngữ tiếp thị tăng 17,4% (thời gian kết xuất của biểu ngữ này giảm đáng kể nhờ việc sử dụng SSR và thẻ tải trước).
Sau khi phân tích các phần còn lại trên trang, chúng tôi nhận thấy hiệu suất của phần lớn các phần này đã cải thiện đáng kể. Ngay cả đối với các mục như Thời tiết và Coronavirus (không phải là mục chính trên trang của chúng tôi), chúng tôi cũng nhận thấy số lượt chuyển đổi tăng lần lượt là 9,6% và 9,5%.
Kết luận
Việc cải thiện hiệu suất là một thách thức vì công việc liên quan có thể kéo dài. Bạn nên thường xuyên theo dõi những thay đổi về chỉ số theo thời gian và đảm bảo rằng tất cả các tính năng mới của sản phẩm đều không gây ra sự suy giảm về chỉ số Core Web Vitals. Để đạt được điều này, chúng tôi theo dõi các thay đổi về Chỉ số quan trọng chính của trang web trong ngân sách hiệu suất.
Quan trọng nhất, chúng tôi nhấn mạnh tầm quan trọng của Các chỉ số quan trọng về trang web đối với tất cả thành viên trong nhóm sản phẩm, từ người quản lý và nhà thiết kế đến người kiểm thử và nhân viên đảm bảo chất lượng. Mỗi thành viên trong nhóm phải nắm được các chỉ số hiệu suất và có quyền cải thiện các chỉ số đó. Chúng tôi cũng thường xuyên lồng ghép các mục tiêu tối ưu hoá hiệu suất vào quy trình kinh doanh. Chúng tôi chỉ có thể cung cấp thành công trải nghiệm chất lượng cao cho người dùng thông qua nỗ lực chung của tất cả thành viên trong nhóm.