W ramach projektu skoncentrowanego na optymalizacji podstawowych wskaźników internetowych i przejściu na Next.js współczynnik konwersji wzrósł o 5%, a liczba stron na sesję – o 87%.
QuintoAndar to brazylijska firma z branży protekologicznej, której produkty oferują kompleksowe rozwiązania cyfrowe dla nieruchomości. W tym roku zrealizowaliśmy projekt skupiający się na poprawie wydajności centrum treści w naszej aplikacji. Udało nam się uzyskać lepsze wyniki w zakresie zwiększania ruchu użytkowników i liczby konwersji.
46%
niższy współczynnik odrzuceń
87%
wzrost liczby stron na sesję
5%
wzrost liczby konwersji w fazie weryfikacji
Testy
W naszej aplikacji znajduje się centrum treści na temat mieszkań i mieszkań z ponad 40 tys. stron, na których użytkownicy mogą znaleźć informacje o swoich nieruchomościach, zdjęcia pomieszczeń ogólnodostępnych, poczytać o okolicy i znaleźć oferty do wynajęcia lub sprzedaży. Te strony są bardzo ważne dla QuintoAndar:
- Stanowią ważne źródło bezpłatnego ruchu ze stale rosnącą liczbą użytkowników przechodzących z wyników wyszukiwania.
- Mają wysoki współczynnik konwersji w średnim i długim okresie w porównaniu z innymi stronami.
Pojawiły się jednak problemy z wydajnością i wygodą użytkowników tych stron:
- Wydajność zmierzona za pomocą podstawowych wskaźników internetowych nie została zoptymalizowana. Pojawiły się też znane problemy związane z powolnym ładowaniem stron, powolnym reagowaniem na dane wejściowe użytkownika i niestabilnością układu.
- Współczynniki odrzuceń były wysokie, nawet jeśli oczekiwaliśmy ich wyższych niż w innych częściach aplikacji.
- Aktualizacja dotycząca jakości stron w wyszukiwarce Google – która w tym czasie nie była jeszcze publikowana, uwzględniała w algorytmie rankingowym podstawowe wskaźniki internetowe, co oznacza, że wydajność strony może wpłynąć na sposób wyświetlania wyników wyszukiwania.
Jednocześnie zidentyfikowaliśmy możliwości związane z doświadczeniami dla programistów, które mogą zapewnić korzyści w innych projektach w całej firmie:
- Mechanizm renderowania po stronie serwera, który renderuje wszystkie strony o dużej liczbie wizyt, w tym te dotyczące mieszkań, został stworzony przez naszych pracowników, a jego obsługa i wdrażanie nowych pracowników stały się zbyt skomplikowana.
- Podstawowe funkcje zapewniające dobre działanie aplikacji, takie jak podział kodu, również wymagały niestandardowej konfiguracji i ręcznej pracy ze strony programistów.
- QuintoAndar ma ponad 30 aplikacji internetowych React. Publikowanie aktualizacji tych aplikacji i utrzymywanie ich zgodnie ze sprawdzonymi metodami jest żmudnym zadaniem.
Podejście
Rozpoczęliśmy projekt optymalizacji skuteczności w centrum treści dla mieszkań, aby poprawić wygodę użytkowników, ponieważ te ulepszenia mogłyby zwiększyć liczbę konwersji, poprawić SEO i łatwość obsługi. Inicjatywa ta była także doskonałą okazją do poprawy komfortu obsługi aplikacji.
Migracja do Next.js
Nowa wersja strony mieszkania została zaimplementowana za pomocą Next.js. Centrum treści w kondominium, choć w dużej mierze niezależne od innych części aplikacji, wydawało się dobrym kandydatem do wypróbowania nowej platformy. Będziemy w stanie zrozumieć, jak duże są wysiłki związane z migracją, i ocenić, jak ich funkcje mogłyby pomóc bez wpływu na inne aplikacje React w QuintoAndar.
Jednym z trudniejszych zadań było dopilnowanie, aby strony nadal umożliwiały indeksowanie przez wyszukiwarki. Next.js spełnia to wymaganie, ponieważ od razu obsługuje renderowanie po stronie serwera i eliminuje potrzebę stosowania niestandardowej konfiguracji. Dokumentacja znacznie ułatwia dzielenie się wiedzą o takich zadaniach jak pobieranie danych na serwerze czy wdrażanie nowych programistów. Renderowanie po stronie serwera pomaga też poprawiać wydajność takich wskaźników jak pierwsze wyrenderowanie treści (FCP).
Platforma udostępnia też inne funkcje zwiększające wydajność, takie jak automatyczne dzielenie kodu i pobieranie z wyprzedzeniem. Mimo że istniejąca struktura zapewniała już te funkcje, dodatkowe nakłady pracy wymagane ze strony programistów spowolniły ich wdrożenie. Na przykład podział kodu na poziomie strony lub komponentu trzeba było wykonać ręcznie.
Optymalizacja zasobów JavaScript
Pierwszym krokiem było usunięcie nieużywanego kodu. Przyjrzeliśmy się raportom Analizator pakietów aplikacji internetowych, który pokazuje zawartość każdego pakietu JS, i dokładnie sprawdziliśmy wszystkie skrypty innych firm. Udało nam się usunąć niektóre biblioteki śledzenia, które nie były używane na tej konkretnej stronie.
Nasz zespół przeszedł dalej i przyjrzał się kosztowi wydajności istniejących funkcji. Na przykład użycie przycisku „Lubię to” wymagało sporo kodu JavaScriptu. Jednak na stronie mieszkania mniej niż 0,5% użytkowników weszło w interakcję z przyciskiem, który jest dostępny i częściej używany w innych częściach aplikacji. Po dyskusjach dotyczących zagadnień technicznych i usług zdecydowaliśmy się usunąć tę funkcję.
Zastosowano już inne optymalizacje JS, takie jak kompresja statyczna z użyciem Brotli, którą przeprowadzono w czasie kompilacji za pomocą BrotliWebpackPlugin. Zastosowano też ją do innych typów zasobów statycznych. Początkowo korzystaliśmy z kompresji zapewnianej przez CDN, dzięki czemu Brotli zmniejszył rozmiar pliku JS o 18% w porównaniu z gzip. Potem w czasie kompilacji przeszliśmy na kompresję Brotli i osiągnęliśmy zmniejszenie o 24%.
Optymalizacja zasobów graficznych
W wersji mobilnej większość części strony widocznej na ekranie zajmuje baner powitalny. Jest to również największe wyrenderowanie treści (LCP).
Wcześniej wszystkie obrazy miały już atrybuty srcset i sizes, aby wyświetlać obrazy elastyczne. Wykorzystaliśmy też narzędzie Thumbor do zmiany rozmiaru obrazów na żądanie i skonfigurowaliśmy naszą sieć CDN, aby wydajnie je buforować.
Nowoczesne urządzenia mobilne mają wyświetlacze o bardzo dużej gęstości pikseli, co oznacza, że przeglądarka renderuje 3- lub 4-krotne wersje obrazu, jeśli jest taka możliwość. Im większa rozdzielczość, tym trudniej jest dostrzec różnice, ale rozmiar plików będzie się zwiększał. Ograniczenie maksymalnej rozdzielczości obrazu poprawiło rozmiar obrazu bez negatywnego wpływu na wygodę użytkowników. Ograniczyliśmy baner do wersji podwójnej, czyli co najwyżej 35% mniej niż wersja 3x i o 50% mniejsza od wersji 4x.
Na zakończenie użyliśmy strategii wstępnego wczytywania, która pozwoliła nam jak najszybciej pobrać i wyświetlić te dane. W ramach tego działania zamierzamy poprawić wskaźnik LCP.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
Wbudowany komponent obrazu Next.js obejmuje wiele z tych optymalizacji, takich jak elastyczne zmienianie rozmiaru czy priorytet wczytywania. W ramach tego projektu nie przenieśliśmy istniejących obrazów do tego komponentu, ale planujemy zastosować go w nowych funkcjach.
Zmniejszanie przesunięcia układu
Na stronie mieszkania wystąpiły problemy z skumulowanym przesunięciem układu (CLS). Elementy odpowiedzialne za przesunięcia układu zostały wyrenderowane tylko po stronie klienta, np. uwierzytelniające znaczniki po stronie serwera za pomocą komponentów renderowanych 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, a wartości szacunkowe (min-height). Istnieje więcej opcji, na przykład możesz użyć właściwości CSS aspect-ratio. Utworzyliśmy też obiekty zastępcze, aby zapobiec przeciąganiu układu do dynamicznego renderowania.
Stopniowe wdrażanie zmian
Nasz zespół chciał potwierdzić, że zoptymalizowana wersja strony centrum mieszkania będzie bardziej wygodna dla użytkowników. Aby to osiągnąć, wdrożyliśmy strategię progresywnego wdrażania:
- Na pierwszym etapie nowa wersja została opublikowana dla kilku starannie wybranych adresów URL, aby widziało je tylko kilkaset użytkowników dziennie.
- W drugim etapie publikowano ją dla większej liczby stron, dzięki czemu codziennie korzystało z niej kilka tysięcy użytkowników.
- W fazie trzeciej i ostatniej została ona opublikowana na wszystkich stronach, a wdrożenie zostało zakończone u wszystkich użytkowników.
W tym okresie zespół inżynierów stale mierzył wydajność stron w środowisku produkcyjnym i pracował nad ulepszeniem. Dodatkowo zespół porównał dane biznesowe w nowej i poprzedniej wersji. Wyniki uzyskane w tym okresie były obiecujące.
Wyniki
Zespół za pomocą SpeedCurve stale przeprowadzał testy laboratoryjne na stronie mieszkania. Oto wyniki dla wersji mobilnej:
| Dane modułu | Przed | Po | Różnica |
|---|---|---|---|
| Największe wyrenderowanie treści (LCP) | 2,41 sekundy | 1,48 sekundy | –39% |
| Time to Interactive (TTI) | 12,16 sekundy | 7,48 sekundy | –39% |
| Całkowity czas blokowania (TBT) | 1124 milisekundy | 1056 milisekund | –4% |
| Skumulowane przesunięcie układu (CLS) | 0,0402 | 0,0093 | –77% |
Chcieliśmy też sprawdzić, jaki wpływ będzie to miało na naszych rzeczywistych użytkowników. Korzystając z danych zebranych za pomocą Instana Website Monitoring, przyglądaliśmy się 1 miesiącowi przed wdrożeniem i po nim. Porównując 75 centyl w przypadku użytkowników urządzeń mobilnych, wykazaliśmy, że wskaźnik LCP spadł o 26%, a wskaźnik FID (FID) spadł o 72%.
PageSpeed Insights zawiera raport z danymi z ostatnich 28 dni. Sama najczęściej odwiedzana strona z kondominami 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 znajdują się w kategorii „dobrych”.
Podczas wdrażania progresywnego zaobserwowaliśmy spadek współczynnika odrzuceń. Do momentu opublikowania wszystkich wersji witryny 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 wyników wyszukiwania spadek współczynnika odrzuceń był jeszcze większy i spadek o 59%. To dobry znak, jeśli chodzi o inwestycje w reklamy typu płatność za kliknięcie (PPC).
Jeśli chodzi o wpływ na dane dotyczące działalności biznesowej, przeanalizowaliśmy współczynniki konwersji w przypadku takich transakcji jak umówienie się na wycieczkę czy złożenie wniosku o wynajem lub zakup nieruchomości. Chociaż wciąż wprowadzamy ulepszenia, nasz zespół porównał konwersje między poprzednią a nową wersją. W tym samym tygodniu grupa stron z nową wersją odnotowała 5-procentowy wzrost konwersji, a na innych stronach – nieznaczny spadek tych samych danych.
Podsumowanie
Ten projekt jest pierwszą częścią długoterminowej migracji z React bez platformy do Next.js. Zespoły, które od tego czasu pracowały nad stroną mieszkania, wyraziły pozytywne opinie na temat udoskonalonych funkcji dla deweloperów. Inne zespoły, które musiały uruchamiać nowe aplikacje internetowe, zrobiły to już za pomocą Next.js. Wierzymy, że Next.js uprości konserwację i utworzy pewną płaszczyznę między różnymi aplikacjami.
Ogólnie rzecz biorąc, centrum treści w kondominium stale się rozwija pod względem bezwzględnej liczby użytkowników i transakcji. W analizie długoterminowej wpływa na to wiele czynników, takie jak rozwój działalności QuintoAndar i inicjatywy SEO, takie jak ulepszone indeksowanie stron. W trakcie realizacji projektu zaobserwowaliśmy, że jednym z tych czynników, które mają duży potencjał pozytywnego wpływu na konwersje, jest również wydajność strony.
Specjalne podziękowania dla Pedro Carmo, menedżera produktu w zespole ds. SEO za zagłębienie się w dane użytkowników i stworzenie całej analizy konwersji widocznej w tym studium przypadku.