Jak aplikacja QuintoAndar zwiększyła współczynniki konwersji i liczbę stron na sesję dzięki poprawie skuteczności stron

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%.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar to brazylijska firma proptech, której produkty oferują kompleksowe cyfrowe rozwiązania w zakresie nieruchomości. W tym roku zrealizowaliśmy projekt mający na celu poprawę wydajności sekcji z treściami w naszej aplikacji. Udało nam się zwiększyć liczbę wizyt i konwersji.

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ą uzyskać informacje o swoich nieruchomościach, obejrzeć zdjęcia wspólnych pomieszczeń, przeczytać o okolicy 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.

Jednak w przypadku tych stron wystąpiły problemy ze sprawnością i wygodą użytkowników:

  • Ich wydajność mierzona za pomocą podstawowych wskaźników internetowych nie była zoptymalizowana, a znane były problemy z powolnym wczytywaniem stron, wolną reakcją na działania użytkowników i niestabilnością układu.
  • Ich wskaźnik odrzuceń był wysoki, choć spodziewaliśmy się, że będzie wyższy niż w innych częściach aplikacji.
  • Aktualizacja dotycząca jakości stron w wyszukiwarce Google, która w tym czasie nie została jeszcze opublikowana, miałaby uwzględniać podstawowe wskaźniki internetowe w algorytmie rankingu, co oznacza, że wydajność strony mogłaby 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.
  • Kluczowe funkcje, które zapewniają dobrą wydajność aplikacji, takie jak dzielenie kodu, wymagały też niestandardowej konfiguracji i ręcznej pracy deweloperów.
  • QuintoAndar ma ponad 30 aplikacji internetowych opartych na React. Przesyłanie aktualizacji tych aplikacji i utrzymywanie ich zgodnie ze sprawdzonymi metodami jest trudnym zadaniem.

Podejście

Rozpoczęliśmy projekt optymalizacji wydajności strony z informacjami o apartamentach, aby zwiększyć wygodę użytkowników. Ulepszenia te mogą bowiem przełożyć się na wzrost liczby konwersji, poprawę SEO i wygodę korzystania. Ta inicjatywa była też odpowiednią okazją do ulepszenia środowiska programistów.

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 „od razu po wyjęciu z pudełka” i nie wymaga konfiguracji niestandardowej. Dokumentacja znacznie ułatwia dzielenie się wiedzą na temat wykonywania takich zadań jak pobieranie danych na serwerze i wprowadzanie 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).

Framework udostępnia też inne funkcje zwiększające wydajność, takie jak automatyczne dzielenie koduprefetching. Chociaż istniejąca struktura zapewniała już takie funkcje, dodatkowe działania wymagane od deweloperów opóźniły ich wdrażanie. Na przykład podział kodu na poziomie strony lub komponentu musiał być wykonany ręcznie.

Optymalizacja zasobów JavaScriptu

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ł do działania dużej ilości kodu JavaScript. Jednak na stronie wspólnoty 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 odpowiedzialnymi za produkt zdecydowaliśmy się usunąć tę funkcję.

Animacja pokazująca funkcję przycisku „Lubię to”. Karta z informacjami o apartamencie do wynajęcia. W prawym dolnym rogu karty znajduje się szary przycisk w kształcie serca, który po kliknięciu zmienia kolor na niebieski.

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 korzystaliśmy z kompresji udostępnianej przez CDN, a Brotli zmniejszył rozmiar kodu JS o 18% w porównaniu z gzip. Następnie przełączyliśmy się na kompresję Brotli w czasie kompilacji i udało nam się zmniejszyć rozmiar o 24%.

Optymalizacja zasobów obrazów

W wersji mobilnej baner powitalny zajmuje większość obszaru powyżej zagięcia. Czasami jest to też największe wyrenderowanie treści (LCP) na stronie.

Strona budynku mieszkalnego Edifício Copan (São Paulo, Brazylia). Zdjęcie zrobione z poziomu gruntu, na którym widać krzywizny konstrukcji budynku.
Baner powitalny na stronie apartamentu.

Wcześniej wszystkie obrazy miały atrybuty srcset i sizes, aby wyświetlać obrazy elastyczne. Użyliśmy też narzędzia Thumbor do zmiany rozmiaru obrazów na żądanie i skonfigurowaliśmy sieć CDN, aby efektywnie przechowywać je w pamięci podręcznej.

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 przypadku wersji 3 x i o 50% mniejszy niż w przypadku wersji 4 x.

Na koniec użyliśmy strategii wstępnego wczytywania, aby jak najszybciej pobrać i wyświetlić stronę. Mamy nadzieję, że dzięki temu uda nam się poprawić wynik LCP.

<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">

Wbudowany komponent obrazu Next.js obejmuje wiele takich optymalizacji, jak dostosowywanie rozmiaru i ładowanie według priorytetów. Podczas tego projektu nie przeprowadziliśmy migracji dotychczasowych obrazów, aby używać tego komponentu, ale planujemy go zastosować w przyszłych funkcjach.

Ograniczanie przesunięcia układu

Na stronie dotyczącej apartamentu wystąpiło kilka problemów z zbiorczym przesunięciem układu (CLS). Elementy odpowiedzialne za zmiany układu były renderowane tylko po stronie klienta, np. przez odświeżanie znaczników po stronie serwera za pomocą komponentów renderowanych po stronie klienta lub obrazów bez zdefiniowanych atrybutów widthheight.

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 CSS aspect-ratio. Utworzyliśmy też elementy zastępcze, aby dynamicznie renderowane komponenty nie powodowały zmian układu.

Obraz przedstawiający obszar miejski w Mapach Google z czerwonym znacznikiem pośrodku.
Definiowanie wymiarów elementów takich jak obraz mapy zmniejszyło wartość CLS.

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:

  1. 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;
  2. W drugiej fazie został opublikowany na kolejnych stronach, co obejmowało kilka tysięcy użytkowników dziennie;
  3. 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 w nowej i poprzedniej wersji. 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 w wersji mobilnej:

Dane laboratoryjne 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%
Wyniki wskaźników laboratoryjnych zebrane za pomocą SpeedCurve.

Chcieliśmy też sprawdzić wpływ na prawdziwych 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%.

Wykres liniowy z wartościami LCP porównujące nowe i poprzednie wersje w bieżącym i poprzednim miesiącu. Krzywa nowej wersji waha się między 2 a 4 sekundami, przez większość czasu pozostając poniżej krzywej poprzedniej wersji.
Wykres liniowy z wartościami FID porównujące nową i poprzednią wersję w bieżącym i poprzednim miesiącu. Krzywa dla nowej wersji przez większość czasu pozostaje poniżej 100 ms, podczas gdy w przypadku poprzedniej wersji występuje kilka szarpnięć przekraczających 250 ms.
Dane z miejsca zdarzenia zebrane za pomocą Instana.

PageSpeed Insights zawiera raport z danymi polowymi z ostatnich 28 dni. Najczęściej odwiedzana strona o apartamentach zawierał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”.

Zrzut ekranu pokazujący raport PageSpeed Insights z powiększonym fragmentem sekcji Dane polowych. Wszystkie podstawowe wskaźniki internetowe (FCP, FID, LCP, CLS) są w dobrym zakresie.
PageSpeed Insights pokazuje, że użytkownicy urządzeń mobilnych dobrze oceniają najczęściej odwiedzaną stronę wspólnoty mieszkaniowej.

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).

Zrzut ekranu z wykresem z Google Analytics. Porównuje współczynniki odrzuceń między 2 okresami w marcu 2021 r. Od 17 marca odnotowujemy niewielki spadek współczynnika odrzuceń. Spadek jest wyraźny 24 marca.
Po wprowadzeniu nowej wersji na kolejnych stronach Google Analytics pokazuje spadek współczynnika odrzuceń.

Jeśli chodzi o wpływ na dane biznesowe, przeanalizowaliśmy współczynniki konwersji w przypadku transakcji takich jak rezerwacja wycieczki i zgłoszenie się do wynajęcia lub zakupu nieruchomości. Podczas wdrażania ulepszeń nasz zespół porównał konwersje między poprzednią a nową wersją. W tym samym tygodniu grupa stron z nową wersją wykazała wzrost liczby konwersji o 5%, podczas gdy na innych stronach odnotowano niewielki spadek tej miary.

Dwa wykresy liniowe obok siebie, z których każdy porównuje liczbę konwersji w bieżącym i poprzednim tygodniu. Po lewej stronie znajduje się wykres dla poprzedniej wersji strony, który pokazuje, że krzywa konwersji w bieżącym tygodniu jest nieco poniżej tej z poprzedniego tygodnia. Prawa kolumna dotyczy nowej wersji, a krzywa konwersji w bieżącym tygodniu jest nieco wyższa niż w poprzednim.
W tym samym tygodniu liczba konwersji w nowej wersji wzrosła, a w poprzedniej – nieznacznie spadła.

Podsumowanie

Ten projekt jest pierwszą częścią długoterminowego procesu przenoszenia z React bez ramki na Next.js. Od tego czasu zespoły, które pracowały nad stroną apartamentu, przekazały pozytywne opinie na temat ulepszeń dla programistó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 rzecz biorąc, hub treści o kwaterach na czas wakacji stale się rozwijał pod względem bezwzględnej liczby 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 ramach tego projektu zauważyliśmy, że wydajność strony to też jeden z czynników, który może mieć duży wpływ na pozytywny wpływ na konwersje.

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.