Projekt skupiony na optymalizacji podstawowych wskaźników internetowych i przejściu na Next.js spowodował wzrost współczynników konwersji o 5% i liczba stron na sesję o 87%.
QuintoAndar to brazylijska firma proptech, której produkty to kompleksowe cyfrowe rozwiązania w zakresie nieruchomości. W tym roku zrealizowaliśmy projekt, którego celem było poprawę skuteczności centrum treści w naszej aplikacji, i miało miarodajne efekty wzrostu ruchu użytkowników i danych o konwersjach.
46%
zmniejszenie współczynnika odrzuceń
87%
wzrost liczby stron na sesję
5%
poprawa konwersji podczas fazy weryfikacji
Wyzwania
Nasza aplikacja zawiera ponad 40 tys. stron z treściami o apartamentach, na których użytkownicy mogą znaleźć informacje o swoich nieruchomościach, obejrzeć zdjęcia wspólnych pomieszczeń, dowiedzieć się więcej o sąsiedztwie oraz znaleźć dostępne oferty wynajmu lub sprzedaży. Te strony są bardzo ważne dla QuintoAndar:
- Są one ważnym źródłem ruchu organicznego, a liczba użytkowników, którzy trafiają do nich z wyników wyszukiwarki, stale rośnie.
- W porównaniu z innymi stronami mają one w średniej i długoterminowej perspektywie wysoki współczynnik konwersji.
Pojawiły się jednak problemy z wydajnością i wygodą użytkowania tych stron:
- Ich wydajność mierzona za pomocą podstawowych wskaźników internetowych nie była zoptymalizowana, a znane były problemy z powolnym wczytywaniem stron, wolnym reagowaniem na działania użytkowników i niestabilnością układu.
- Ich wskaźniki odrzuceń były wysokie, choć spodziewaliśmy się, że będą wyższe niż w innych częściach aplikacji.
- Aktualizacja dotycząca jakości strony w wyszukiwarce Google – która wtedy nie była jeszcze udostępniana – obejmowała w algorytmie rankingowym podstawowe wskaźniki internetowe. Oznaczało to, że wydajność strony mogła wpływać na wyświetlanie wyników wyszukiwania.
Jednocześnie zidentyfikowaliśmy kilka możliwości ułatwiających pracę deweloperów, które mogą przynieść korzyści w innych projektach w firmie:
- Nasza logika renderowania po stronie serwera, która renderuje wszystkie strony o dużej liczbie wizyt, w tym strony apartamentów, została stworzona wewnętrznie i stała się zbyt skomplikowana, aby ją utrzymać i wdrożyć w związku z nowymi pracownikami.
- Funkcje niezbędne do zapewnienia dobrej wydajności aplikacji, takie jak dzielenie kodu, wymagały też niestandardowej konfiguracji i ręcznej pracy deweloperów.
- QuintoAndar ma ponad 30 aplikacji internetowych React. Przesyłanie aktualizacji tych aplikacji i utrzymywanie ich zgodnie ze sprawdzonymi metodami jest trudnym zadaniem.
Podejście
Rozpoczęliśmy projekt optymalizacji skuteczności w centrum treści, aby poprawić wrażenia użytkowników. Te usprawnienia mogą przełożyć się na wzrost liczby konwersji, lepsze SEO i łatwość obsługi. Inicjatywa była też doskonałą okazją do ulepszenia środowiska programistycznego.
Migracja do Next.js
Nowa wersja strony o apartamentach została zaimplementowana za pomocą Next.js. Ponieważ moduł ten jest w dużej mierze niezależny od innych części aplikacji, wydawał się dobrym kandydatem do wypróbowania nowego frameworku. Dzięki temu moglibyśmy określić zakres prac związanych z przeniesieniem i ocenić, jak funkcje aplikacji mogą pomóc bez wpływu na inne aplikacje React w QuintoAndar.
Wymaganie to miało na celu zapewnienie, że strony będą nadal indeksowane przez wyszukiwarki. Next.js spełnia ten wymóg, ponieważ obsługuje renderowanie po stronie serwera „out-of-the-box” i eliminuje potrzebę niestandardowej konfiguracji. Dzięki dokumentacji łatwiej jest przekazywać informacje o wykonaniu takich zadań jak pobieranie danych na serwerze oraz wdrażanie nowych programistów. Renderowanie po stronie serwera powoduje też polepszanie wydajności, co widać na przykład w przypadku wskaźnika pierwszego wyrenderowania treści (FCP).
Platforma udostępnia też inne funkcje zwiększające wydajność, takie jak automatyczne podział kodu i pobieranie z wyprzedzeniem. Mimo że obecna struktura udostępniała już takie funkcje, dodatkowa praca wymagana przez deweloperów wstrzymuje ich wdrożenie. Na przykład podział kodu na poziomie strony lub komponentu musiał być wykonany ręcznie.
Optymalizacja zasobów JavaScript
Pierwszym krokiem było usunięcie nieużywanego kodu. Sprawdziliśmy raporty Webpack Bundle Analyzer, które zawierają zawartość każdego pakietu JS, oraz dokładnie przejrzeliśmy wszystkie skrypty innych firm. Dzięki temu udało nam się usunąć niektóre biblioteki śledzenia, których nie używano na tej stronie.
Nasz zespół poszedł dalej i przeanalizował koszty wydajności dotychczasowych funkcji. Na przykład przycisk „Lubię to” wymagał sporej ilości kodu JavaScript. Jednak na stronie wspólnoty mieszkaniowej mniej niż 0,5% użytkowników klikało przycisk, który jest dostępny i częściej używany w innych częściach aplikacji.Po dyskusji z inżynierami i pracownikami zespołu ds. produktu zdecydowaliśmy się usunąć tę funkcję.
Wdrożone były już inne optymalizacje JS, takie jak kompresja statyczna za pomocą Brotli, która została wykonana w czasie kompilacji za pomocą BrotliWebpackPlugin i została zastosowana również do innych typów zasobów statycznych. Początkowo opieraliśmy się na kompresji zapewnianej przez CDN, a Brotli zmniejszył rozmiar JS o 18% w porównaniu do gzip. Jednak później przeszliśmy na kompresję Brotli, co pozwoliło zredukować ją o 24%.
Optymalizacja zasobów obrazów
W wersji mobilnej baner powitalny zajmuje większość obszaru powyżej zagięcia. Jest to również największe wyrenderowanie treści (LCP) strony.
Wcześniej wszystkie obrazy miały atrybuty srcset i sizes, aby wyświetlać obrazy elastyczne. Używaliśmy też narzędzia Thumbor, by na żądanie zmieniać rozmiar obrazów, i skonfigurowaliśmy naszą sieć CDN w taki sposób, aby wydajnie buforować obrazy.
Nowoczesne urządzenia mobilne mają wyświetlacze o bardzo wysokiej gęstości pikseli, co oznacza, że przeglądarka renderuje 3 lub 4 wersje obrazu (jeśli są dostępne). Wraz ze wzrostem rozdzielczości różnice stają się mniej widoczne dla ludzkiego oka, ale rozmiary plików będą się zwiększać. Ograniczenie maksymalnej rozdzielczości obrazu poprawiło rozmiar obrazu bez uszczerbku na wygodzie użytkowników. Ograniczyliśmy rozmiar głównego obrazu do maksymalnie 2 x, co oznacza, że jest on o około 35% mniejszy niż w wersji 3 x i o 50% mniejszy niż w wersji 4 x.
Na zakończenie zastosowaliśmy strategię wstępnego wczytywania, aby jak najszybciej pobrać i wyświetlić dane z wykorzystaniem odpowiedniego współczynnika, co pozwoli zwiększyć wartość LCP.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
Wbudowany komponent obrazu Next.js zawiera wiele z tych optymalizacji, np. elastyczną zmianę rozmiaru i priorytetowe wczytywanie. W ramach tego projektu nie przenieśliśmy istniejących obrazów, aby można było używać tego komponentu, ale planujemy wdrożyć go w nowych funkcjach.
Ograniczanie przesunięcia układu
Na stronie apartamentu wystąpiło kilka problemów z zbiorczym przesunięciem układu (CLS). Elementy odpowiedzialne za przesunięcia układu były renderowane tylko u klienta – na przykład hydratacja znaczników po stronie serwera z komponentami renderowanymi przez klienta lub obrazy bez zdefiniowanych atrybutów width i height.
Aby rozwiązać te problemy, w miarę możliwości ustawiamy dokładne wymiary tych elementów lub szacowane wartości z użyciem min-height. Dostępnych jest więcej opcji, np. użycie właściwości aspect-ratio w kodzie CSS. Utworzyliśmy też elementy zastępcze, aby dynamicznie renderowane komponenty nie powodowały zmian układu.
stopniowe wdrażanie zmian;
Nasz zespół chciał sprawdzić, czy zoptymalizowana wersja strony apartamentu w apartamentowcu zapewni użytkownikom lepsze wrażenia. Aby to osiągnąć, przyjęliśmy strategię stopniowego wdrażania:
- W pierwszej fazie nowa wersja została opublikowana dla kilku wybranych adresów URL, więc widziało je tylko kilkaset użytkowników dziennie;
- W drugiej fazie został opublikowany na kolejnych stronach, co oznacza kilka tysięcy użytkowników dziennie;
- W trzeciej i ostatniej fazie został opublikowany na wszystkich stronach, a wdrożenie zostało ukończone dla wszystkich użytkowników.
W tym czasie zespół inżynierów stale mierzył wydajność stron w produkcji i pracował nad ich ulepszaniem. Dodatkowo zespół porównał dane biznesowe między nową i poprzednią wersją. Wyniki w tym okresie weryfikacji były obiecujące.
Wyniki
Aby stale przeprowadzać testy laboratoryjne na stronie apartamentu, zespół korzystał z narzędzi SpeedCurve. Oto wyniki dla wersji mobilnej:
| Wskaźnik modułu | Przed | Po | Różnica |
|---|---|---|---|
| Największe wyrenderowanie treści (LCP) | 2,41 sekundy | 1,48 sekundy | -39% |
| Czas do pełnej interaktywności (TTI) | 12,16 sekundy | 7,48 s | –39% |
| Łączny czas blokowania (TBT) | 1124 ms | 1056 milisekund | -4% |
| Skumulowane przesunięcie układu (CLS) | 0,0402 | 0,0093 | –77% |
Chcieliśmy też sprawdzić wpływ tej zmiany na naszych użytkowników. Korzystając z danych terenowych zebranych za pomocą Instana Website Monitoring, przeanalizowaliśmy miesięczny okres przed i po wdrożeniu. Porównując 75 percentyla dla użytkowników urządzeń mobilnych, stwierdziliśmy, że LCP zmniejszył się o 26%, a FID – o 72%.
PageSpeed Insights udostępnia raport z danymi pól z ostatnich 28 dni. Sama najczęściej wyświetlana strona osiedlach mieszkaniowych miała wystarczającą ilość danych, aby wygenerować raport dla użytkowników urządzeń mobilnych. Od listopada 2021 r. wszystkie podstawowe wskaźniki internetowe są w grupie „dobrych”.
Podczas stopniowego wdrażania zauważyliśmy spadek współczynnika odrzuceń. Gdy zakończyliśmy wdrażanie na wszystkich stronach, Google Analytics wykazał spadek współczynnika odrzuceń o 46%, wzrost liczby stron na sesję o 87% i wzrost średniego czasu trwania sesji o 49%. W przypadku płatnych wyszukiwań spadek współczynnika odrzuceń był jeszcze większy i wyniósł 59%. Jest to pozytywny sygnał w odniesieniu do inwestycji w reklamy z modelem pay-per-click (PPC).
Aby ocenić wpływ tej zmiany na dane biznesowe, przeanalizowaliśmy współczynniki konwersji w przypadku takich transakcji jak zaplanowanie wycieczki czy zgłoszenie się do wynajmu lub zakupu nieruchomości. Podczas wdrażania ulepszeń nasz zespół porównał konwersje między poprzednią a nową wersją. W tym samym tygodniu na grupie stron w nowej wersji odnotowano wzrost liczby konwersji o 5%, podczas gdy na innych stronach ten sam rodzaj danych nieznacznie się obniżył.
Podsumowanie
Ten projekt jest pierwszą częścią długofalowego procesu migracji z reakcji bez platformy do Next.js. Zespoły, które od tamtej pory pracowały nad stroną o apartamentach, oceniły to, co ulepszyliśmy w przypadku deweloperów. Inne zespoły, które musiały uruchomić nowe aplikacje internetowe, zrobiły to już za pomocą Next.js. Uważamy, że Next.js uprości działania związane z konserwacją i stworzy wspólną płaszczyznę dla różnych aplikacji.
Ogólnie biorąc pod uwagę, że centrum treści na tych platformach stale się rozwija, można zwiększać bezwzględną liczbę użytkowników i transakcji. W przypadku długoterminowej analizy jest wiele czynników, które się do tego przyczyniły, np. rozszerzenie działalności QuintoAndar i inicjatywy SEO, takie jak ulepszone indeksowanie stron. W tym projekcie zaobserwowaliśmy, że wydajność strony jest również jednym z tych czynników o dużym potencjale zwiększenia liczby konwersji.
Specjalne podziękowania dla Pedro Carmo, menedżera produktu w zespole SEO, za zapoznanie się z danymi użytkowników i stworzenie całej analizy konwersji przedstawionej w tym opracowaniu.