Kilka miesięcy pracy nad poprawą podstawowych wskaźników internetowych na stronie głównej Mail.ru zaowocowało 60-procentowym wzrostem 75.percentyla skumulowanego przesunięcia układu (CLS), średnim czasem sesji o 2,7% i współczynnikami konwersji w głównych sekcjach o ponad 10%.
Pierwsze kroki
Mail.ru to jedna z wiodących usług pocztowych w rosyjskojęzycznym internecie i znajduje się na liście 5 najpopularniejszych witryn w Rosji pod względem ruchu. Poczta Mail.ru jest ważnym źródłem informacji dla wielu osób. Odbiera ona kilkaset milionów wizyt miesięcznie i jest portalem, z którego można korzystać między innymi do poczty e-mail, wiadomości, mediów społecznościowych i wyników wyszukiwania w internecie.
Firma Mail.ru chciała zapewnić swoim użytkownikom wysoką jakość usług, więc rozpoczęto pracę nad poprawą podstawowych wskaźników internetowych. Zanim omówimy naszą strategię optymalizacji, warto najpierw zwrócić uwagę na kilka szczegółów technicznych strony głównej Mail.ru.
Chociaż projekt od dawna był rozwijany z wykorzystaniem naszego własnego silnika do tworzenia szablonów (Fest), w 2019 roku rozpoczęliśmy migrację do Svelte 3.
Svelte wdraża reaktywność w sposób bez wirtualnego modelu DOM, dzięki czemu nie wykorzystuje zasobów. Metoda Svelte usuwa nieużywane funkcje z pakietów produkcyjnych, ponieważ implementujący je kod nie jest generowany przez kompilator, gdy funkcje nie są używane. Nieużywany kod jest usuwany podczas kompilacji, co skutkuje mniejszymi pakietami. Może to zmniejszyć całkowity czas blokowania (TBT) podczas uruchamiania strony.
Śledzenie danych skuteczności
Przed zoptymalizowaniem podstawowych wskaźników internetowych warto ocenić wydajność w tej dziedzinie. Przed wprowadzeniem podstawowych wskaźników internetowych śledziliśmy inne dane, np. Pierwsze wyrenderowanie treści (FCP), w naszym wewnętrznym panelu wydajności.
Nasz skrypt zbierania danych został zmodyfikowany tak, aby zbierał podstawowe wskaźniki internetowe i przenosił je do panelu wydajności w celu wizualizacji. Zgodnie z zaleceniami Google nasz skrypt korzysta z interfejsu PerformanceObserver API do uzyskiwania wskaźników, który jest częścią uniwersalnego frontendu „Platform” w Mail.ru.
Panel zawierał te dane o użytkownikach (średnie wartości dla tygodnia 15–21 marca 2021 r.):
| Nazwa grupy danych | Podstawowe wskaźniki internetowe | Inne wskaźniki internetowe | |||||
|---|---|---|---|---|---|---|---|
| Nazwa danych | LCP | FID | CLS | FCP | Do ustalenia | TTI | |
| Udział użytkowników zgodny z wartościami progowymi podstawowych wskaźników internetowych | dobrze | 52% | 92% | 33% | 35% | 42% | 43% |
| potrzeba poprawy | 19% | 5% | 23% | 38% | 16% | 25% | |
| słabe | 29% | 3% | O 44% | 27% | 42% | O 32% | |
Poprawa podstawowych wskaźników internetowych
Chociaż istnieje wiele wskazówek dotyczących poprawy podstawowych wskaźników internetowych, każdy projekt wiąże się z innymi wyzwaniami. W przypadku strony głównej Mail.ru zidentyfikowano następujące możliwości:
- Implementowanie obiektów zastępczych banerów reklamowych, by ograniczyć CLS.
- Zastosowanie renderowania po stronie serwera (SSR) w celu ograniczenia największego wyrenderowania treści (LCP).
- Podział kodu w celu zmniejszenia LCP i opóźnienia po pierwszym działaniu (FID).
Szkielety poprawiające CLS
Wartość CLS była jednym z najgorszych wskaźników pól na stronie głównej Mail.ru. Kolejne profilowanie tej strony w panelu Wydajność w Narzędziach deweloperskich w Chrome pokazało, że źródłem problemu były reklamy. Aby poprawić stabilność układu, nasz zespół zdecydował się na użycie obiektów zastępczych, aby zarezerwować miejsce na reklamy przed ich załadowaniem.
Implementując obiekty zastępcze, najpierw trzeba określić wymiary treści, która je zastąpi. Na szczęście na stronie głównej Mail.ru na komputery dokładnie udokumentowane są rozmiary reklam. Po rozmowie z zespołem projektowym szkielety interfejsu animowane w SVG zostały użyte jako obiekty zastępcze, ponieważ skrócą postrzegany czas wczytywania treści.
Powrót SSR
Aby ułatwić przejście z Fest na Svelte, przerobiliśmy istniejący projekt stopniowo, zamiast zaczynać od początku. Do marca 2021 roku przenieśliśmy większość frontendu do Svelte i po sklasyfikowaniu i usunięciu problemów z wydajnością backendu przenieśliśmy SSR do naszej aplikacji produkcyjnej.
Po wdrożeniu SSR zespół odkrył przyczynę regresji CLS, która początkowo była niezauważana: sekcja Wiadomości nie była wstawiona w momencie renderowania pierwszej treści na stronie. Między początkowym wymalowaniem znaczników strony podanymi przez serwer a wstawieniem sekcji wiadomości na kliencie wystąpiło opóźnienie. To zachowanie spowodowało zmianę szkieletu reklamy, co pogorszyło CLS.
Chociaż w Narzędziach deweloperskich w Chrome były widoczne zdarzenia przesunięcia układu, na początku nie udało nam się znaleźć przyczyny. Sama SSR nie była problemem, ale pomogła później w znalezieniu rozwiązania. Naprawienie kodu odpowiedzialnego za opóźnienie renderowania poprawiło stabilność układu komponentu wiadomości.
Innym skutkiem SSR na CLS jest ruch komponentów przed nawodnieniem i po nim, co może prowadzić do dalszych zmian układu. Ten problem wystąpił szczególnie w przypadku wersji mobilnej, co wymagało zwrócenia szczególnej uwagi na znaczniki hydratowanego komponentu. Dobrym rozwiązaniem tego problemu było przeniesienie jak największej liczby logiki wyświetlania z JavaScriptu do CSS.
Podział kodu i nieużywane elementy polyfill
Aby poprawić postrzeganą szybkość ładowania stron, konieczna była zmniejszenie wartości LCP i FID. Możesz to zrobić na przykład przez podział kodu. Oprócz strony głównej Mail.ru nasz zespół pracuje nad widżetem do nawigacji w portalu. Obecnie jest on umieszczony w wielu projektach naszej firmy.
Ze względów historycznych widżet jest wstawiany na samym początku strony jako skrypt wczytujący synchronicznie. Udział kodu polyfill w tym skrypcie rosło z czasem. Aby ograniczyć negatywny wpływ wczytywania kodu polyfill na wydajność, wdrożyliśmy podział kodu na nowoczesne i starsze przeglądarki.
Zdecydowaliśmy się na wzorzec module/nomodule do wczytywania pakietów JavaScript dla nowoczesnych i starszych przeglądarek, ponieważ atrybut type="module" elementu <script> nie był kierowany na przeglądarki, które były wystarczająco nowoczesne. Aby rozwiązać ten problem, Mail.ru używa własnego narzędzia do identyfikowania nowoczesnych wersji przeglądarek w backendzie i może się do nich odpowiednio dostosować.
Gdy już udało się zidentyfikować przeglądarki w backendzie, wdrożyliśmy podział kodu między przeglądarkami nowoczesnymi i starszymi. W rezultacie w nowoczesnych przeglądarkach rozmiar synchronicznie wczytywanego widżetu JavaScript zmniejszył się o 43,3%. Tę metodę zastosowano też w przypadku innych skryptów portalu.
Oprócz zmniejszenia rozmiaru pakietu i pozytywnego wpływu na podstawowe wskaźniki internetowe, dzielenie kodu poprawia również wrażenia programistów. Tylko 3,5% naszych użytkowników korzysta ze starszych przeglądarek, które wykazują tendencję spadkową.Dlatego wdrożenie podziału kodu umożliwiło naszym programistom korzystanie z najnowszych interfejsów API przeglądarek bez konieczności wprowadzania zbędnych operacji polyfill niezbędnych dla wszystkich użytkowników starszych przeglądarek.
Wyniki
Po przeprowadzeniu optymalizacji zaobserwowaliśmy w naszych danych terenowych średnie wartości z tygodnia 24–30 maja 2021 r.:
| Nazwa grupy danych | Podstawowe wskaźniki internetowe | Inne wskaźniki internetowe | |||||
|---|---|---|---|---|---|---|---|
| Nazwa danych | LCP | FID | CLS | FCP | Do ustalenia | TTI | |
| Udział użytkowników zgodny z wartościami progowymi podstawowych wskaźników internetowych | dobrze | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| potrzeba poprawy | 18% | 4% | 3% | 34% | 17% | 24% | |
| słabe | 24% | 3% | 4% | 23% | 34% | 25% | |
Poniższe wykresy przedstawiają zmiany wartości danych o skuteczności stron internetowych w poszczególnych kategoriach „Platforma”. Zwróć uwagę na 2 ważne daty widoczne na wykresach:
- 23 marca 2021 roku: wydanie iteracji z sekcjami ostatniej strony przeniesionymi do Svelte.
- 19 kwietnia 2021 r.: wydanie iteracji ze zwróconym SSR i układem zmodyfikowanym w celu poprawienia regresji CLS.
Spadek wartości od 1 do 10 maja wiąże się z świętami majowymi w Rosji.
Wyniki uzyskane na podstawie wartości „Platforma” są zgodne ze wzrostem wartości danych w Raporcie na temat użytkowania Chrome (CrUX).
Porównanie średniego czasu trwania sesji użytkownika na tydzień przed wprowadzeniem początkowych ulepszeń i tydzień po nim pokazuje wzrost o 2,7%. Ponadto w większości sekcji strony można zaobserwować znaczny wzrost liczby konwersji. W szczególności liczba konwersji na aplikację do poczty e-mail Mail.ru wzrosła o 11,6%, a liczba konwersji w sekcji „Wiadomości” wzrosła o 13,5%.
181%
Zwiększenie udziału w przypadku prawidłowego progu CLS
2,7%
Wyższy średni czas trwania sesji
13,5%
Wzrost współczynnika konwersji sekcji wiadomości
Najbardziej nieoczekiwanym wynikiem był wzrost współczynnika klikalności (CTR) banera marketingowego o 17,4% (czas renderowania banera marketingowego został znacznie skrócony dzięki wprowadzeniu SSR i wstępnego wczytywania tagów).
Po przeanalizowaniu pozostałych sekcji na stronie zaobserwowaliśmy znaczny wzrost skuteczności w większości z nich. Nawet w niektórych sekcjach takich jak Pogoda czy Koronawirus – które nie są kluczowe na naszej stronie, odnotowujemy wzrost konwersji odpowiednio o 9,6% i 9,5%.
Podsumowanie
Poprawa wydajności jest trudna, ponieważ nakład pracy może trwać dłużej. Musisz regularnie sprawdzać zmiany wskaźników i upewnić się, że żadne nowe funkcje usługi nie powodują pogorszenia podstawowych wskaźników internetowych. Aby to osiągnąć, monitorujemy zmiany w podstawowych wskaźnikach internetowych w naszym budżecie wydajności.
Przede wszystkim podkreśliliśmy znaczenie podstawowych wskaźników internetowych dla wszystkich członków naszego zespołu produktowego – od menedżerów i projektantów po testerów i kontrolę jakości. Każdy członek zespołu powinien mieć świadomość wskaźników wydajności i mieć możliwość ich poprawy. Regularnie włączamy też cele optymalizacji skuteczności do naszych procesów biznesowych. Aby zadbać o wygodę użytkowników, możemy zadbać o wysoką jakość usług tylko dzięki wspólnym wysiłkom wszystkich członków zespołu.