Kilka miesięcy pracy nad poprawą podstawowych wskaźników internetowych na stronie głównej Mail.ru zaowocowało 60-procentowym wzrostem skumulowanego przesunięcia układu (CLS) w 75.percentilu, co zwiększyło średni czas trwania sesji o 2,7%, a współczynnik konwersji w głównych sekcjach o ponad 10%.
Od czego zaczęliśmy
Mail.ru to jedna z najpopularniejszych usług poczty e-mail w rosyjskojęzycznej części Internetu. Pod względem liczby użytkowników jest to 5. najpopularniejsza strona w Rosji. Mail.ru to ważne źródło informacji dla wielu osób. Portal ten notuje kilkaset milionów wizyt miesięcznie. Jest to portal, w którym użytkownicy mogą korzystać z poczty e-mail, wiadomości, mediów społecznościowych, wyszukiwarek internetowych i innych usług.
Firma Mail.ru chciała zapewnić odwiedzającym wysoką jakość wrażeń, dlatego zaczęła pracować nad poprawą podstawowych wskaźników internetowych. Zanim omówimy naszą strategię optymalizacji, warto przyjrzeć się kilku szczegółom technicznym strony głównej Mail.ru.
Chociaż projekt był już od dawna rozwijany za pomocą naszego wewnętrznego silnika do tworzenia szablonów Fest, w 2019 roku zaczęliśmy przechodzić na Svelte 3.
Svelte implementuje reaktywność w sposób, który nie wykorzystuje wirtualnego DOM, co sprawia, że zużywa mniej zasobów. Metoda firmy Svelte polega na usuwaniu z pakietów produkcyjnych nieużywanych funkcji, ponieważ kompilator nie generuje kodu implementującego te funkcje, jeśli nie są używane. Nieużywany kod jest usuwany podczas kompilacji, co powoduje mniejsze rozmiary pakietów. Może to pomóc w zmniejszeniu czasu całkowitego blokowania (TBT) podczas uruchamiania strony.
Śledzenie danych o skuteczności
Zanim zoptymalizujesz podstawowe wskaźniki internetowe, warto ocenić wydajność w praktyce. Przed wprowadzeniem podstawowych wskaźników internetowych w naszym wewnętrznym panelu wydajności śledziliśmy inne dane, np. pierwsze wyrenderowanie treści (FCP).
Zmieniliśmy nasz skrypt do zbierania danych, aby zbierał podstawowe wskaźniki internetowe i przekazywał je do naszego panelu wydajności na potrzeby wizualizacji. Zgodnie z zaleceniami Google nasz skrypt używa interfejsu PerformanceObserver API do uzyskiwania danych. Jest on częścią uniwersalnego interfejsu frontowego „Platform” w Mail.ru.
W panelu wyświetlane są te dane o użytkownikach (średnie wartości w ciągu tygodnia od 15 do 21 marca 2021 r.):
| Nazwa grupy danych | Core Web Vitals | Inne wskaźniki internetowe | |||||
|---|---|---|---|---|---|---|---|
| Nazwa danych | LCP | FID | CLS | FCP | TBT | TTI | |
| Odsetek użytkowników zgodnie z progami podstawowych wskaźników internetowych | dobrze | 52% | 92% | 33% | 35% | 42% | 43% |
| wymaga-poprawy | 19% | 5% | 23% | 38% | 16% | 25% | |
| słabe | 29% | 3% | 44% | 27% | 42% | 32% | |
Poprawianie podstawowych wskaźników internetowych
Chociaż istnieje wiele wskazówek dotyczących ulepszania podstawowych wskaźników internetowych, każdy projekt niesie ze sobą unikalne wyzwania. Na stronie głównej Mail.ru zidentyfikowano te możliwości:
- Wdrożenie obiektów zastępczych dla banerów reklamowych w celu zmniejszenia CLS.
- Korzystanie z renderowania po stronie serwera (SSR), aby skrócić czas największego wyrenderowania treści (LCP).
- Podział kodu w celu zmniejszenia wartości LCP i opóźnienia przy pierwszym działaniu (FID).
Szkielety poprawiające CLS
CLS był jednym z najsłabszych danych zgromadzonych na stronie głównej Mail.ru. Kolejne profilowanie tej strony w panelu Wydajność w Narzędziach deweloperskich Chrome wykazało, że problemem były reklamy. Aby zwiększyć stabilność układu, nasz zespół zdecydował się na użycie symboli zastępczych, które zarezerwują miejsce na reklamy przed ich załadowaniem.
Podczas implementowania symboli zastępczych należy najpierw określić wymiary treści, które je zastąpią. Na szczęście w przypadku strony głównej Mail.ru w wersji na komputery rozmiary reklam są ściśle udokumentowane. Po rozmowie z zespołem projektantów postanowiliśmy użyć jako obiektów zastępczych animowanych szkieletów interfejsu w formacie SVG, ponieważ zmniejszają one czas wczytywania treści.
Powrót SSR
Aby ułatwić przejście z Fest na Svelte, nie zaczynaliśmy od nowa, tylko stopniowo przepisaliśmy istniejący projekt. W marcu 2021 r. przenieśliśmy większość front-endu na Svelte, a po zdiagnozowaniu i rozwiązaniu problemów z wydajnością backendu wprowadziliśmy w końcu SSR w naszej aplikacji produkcyjnej.
Po wdrożeniu SSR zespół odkrył przyczynę regresji CLS, która początkowo przeszła niezauważona: sekcja z informacjami o aktualnościach nie była wstawiana w momencie renderowania pierwszych treści na stronie. Pomiędzy początkowym wyświetleniem znaczników strony dostarczonych przez serwer a wstawieniem sekcji wiadomości na kliencie wystąpiło opóźnienie. To zachowanie spowodowało przesunięcie szkieletu reklamy, co pogorszyło wskaźnik CLS.
Narzędzia programistyczne Chrome pokazały zdarzenia zmiany układu, ale początkowo nie udało nam się znaleźć ich przyczyny. Chociaż problemem nie był sam SSR, to później pomogło to w znalezieniu rozwiązania. Poprawiliśmy kod odpowiedzialny za opóźnienie wyświetlania, co poprawiło stabilność układu komponentu wiadomości.
Kolejnym wpływem SSR na CLS jest przesuwanie komponentów przed i po nasyceniu, co może prowadzić do dalszych zmian układu. Wystąpiło to głównie w wersji mobilnej i wymagało zwrócenia szczególnej uwagi na znaczniki komponentów po hydratacji. Dobrym rozwiązaniem tego problemu było przeniesienie jak największej ilości logiki wyświetlania z JavaScriptu do CSS, o ile było to możliwe.
Dzielenie kodu i nieużywane polyfille
Aby poprawić postrzegany czas wczytywania strony, konieczne było zmniejszenie wartości LCP i FID. Jednym ze sposobów jest dzielenie kodu. Oprócz strony głównej Mail.ru nasz zespół opracowuje widżet nawigacji portalu. Obecnie jest ona używana w wielu projektach naszej firmy.
Ze względów historycznych widżet jest wstawiany na samym początku strony jako skrypt wczytujący się synchronicznie. Udział polyfilli w tym skrypcie wzrósł z czasem. Aby ograniczyć negatywny wpływ wczytywania tych polyfilli na wydajność, wdrożyliśmy podział kodu zarówno w przypadku nowoczesnych, jak i starszych przeglądarek.
Zdecydowaliśmy się nie używać wzorca module/nomodule do wczytywania pakietów JavaScript w przypadku nowoczesnych i starszych przeglądarek, ponieważ atrybut <script> type="module" nie kierował się do przeglądarek, które byłyby wystarczająco nowoczesne do naszych potrzeb. Aby rozwiązać ten problem, Mail.ru używa własnego narzędzia do identyfikowania nowoczesnych wersji przeglądarek na zapleczu i może się do nich odpowiednio dostosować.
Gdy udało się zidentyfikować przeglądarki na zapleczu, wdrożyliśmy podział kodu na potrzeby nowoczesnych i starszych przeglądarek. W efekcie rozmiar synchronicznie wczytywanych widżetów JavaScript w nowoczesnych przeglądarkach zmniejszył się o 43,3%. Zastosowaliśmy tę praktykę również w przypadku niektórych innych skryptów portalu.
Oprócz zmniejszenia rozmiaru pakietu i pozytywnych skutków dla podstawowych wskaźników internetowych podział kodu ułatwia też pracę deweloperom. Tylko 3,5% użytkowników korzysta z przestarzałych przeglądarek, a ich liczba maleje.Dzięki zastosowaniu podziału kodu nasi deweloperzy mogą korzystać z najnowszych interfejsów API przeglądarek bez wprowadzania niepotrzebnego kodu polyfill dla wszystkich użytkowników.
Wyniki
Po optymalizacji w danych polowych zaobserwowaliśmy średnie wartości w przypadku tygodnia od 24 do 30 maja 2021 r.:
| Nazwa grupy danych | Core Web Vitals | Inne wskaźniki internetowe | |||||
|---|---|---|---|---|---|---|---|
| Nazwa danych | LCP | FID | CLS | FCP | TBT | TTI | |
| Odsetek użytkowników zgodnie z progami podstawowych wskaźników internetowych | dobrze | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| wymaga-poprawy | 18% | 4% | 3% | 34% | 17% | 24% | |
| słabe | 24% | 3% | 4% | 23% | 34% | 25% | |
Wykresy poniżej przedstawiają zmiany wartości danych o skuteczności strony internetowej według wymiaru „Platforma”. Zwróć uwagę na 2 ważne daty na wykresach:
- 23 marca 2021 r.: opublikowanie wersji z ostatnimi sekcjami przeniesionymi do Svelte;
- 19 kwietnia 2021 r.: opublikowaliśmy iterację z przywróconym SSR i modyfikowanym układem, aby poprawić regresję CLS.
Spadek wartości od 1 do 10 maja wynika z majowych świąt w Rosji.
Wyniki uzyskane przy użyciu wymiaru „Platforma” są zgodne ze wzrostem wartości danych w raporcie na temat użytkowania Chrome (CrUX).
Porównanie średniej długości sesji użytkownika w ciągu tygodnia przed wdrożeniem początkowych ulepszeń i tygodnia po wdrożeniu pokazuje wzrost o 2,7%. Ponadto w większości sekcji strony odnotowano ogólny znaczny wzrost liczby konwersji. Wzrost konwersji w aplikacji poczty e-mail Mail.ru wyniósł 11,6%, a w sekcji z informacjami – 13,5%.
181%
Zwiększenie udziału progu dobrego CLS
2,7%
dłuższy średni czas trwania sesji,
13,5%
Zwiększenie współczynnika konwersji sekcji z wiadomościami
Największym zaskoczeniem był wzrost współczynnika klikalności banera marketingowego o 17,4% (czas jego renderowania został znacznie skrócony dzięki wprowadzeniu tagów SSR i wstępnego wczytywania).
Po przeanalizowaniu pozostałych sekcji na stronie zauważyliśmy znaczną poprawę wydajności w przypadku większości z nich. Nawet w przypadku sekcji takich jak Pogoda czy Koronawirus, które nie są kluczowymi sekcjami na naszej stronie, odnotowaliśmy wzrost liczby konwersji odpowiednio o 9,6% i 9,5%.
Podsumowanie
Poprawa wydajności jest trudna, ponieważ może wymagać sporo czasu. Należy regularnie sprawdzać zmiany wskaźników w czasie i upewnić się, że wszystkie nowe funkcje produktu nie powodują regresji w przypadku metryki Core Web Vitals. W tym celu monitorujemy zmiany w podstawowych wskaźnikach internetowych w naszym budżecie skuteczności.
Co najważniejsze, podkreśliliśmy znaczenie podstawowych wskaźników internetowych wszystkim członkom naszego zespołu ds. produktów, od menedżerów i projektantów po testerów i osoby odpowiedzialne za jakość. Każdy członek zespołu powinien znać dane dotyczące skuteczności i mieć możliwość ich poprawy. Regularnie też uwzględniamy cele optymalizacji skuteczności w naszych procesach biznesowych. Zapewnienie wysokiej jakości wrażeń użytkowników jest możliwe tylko dzięki wspólnemu wysiłkowi wszystkich członków zespołu.