Wydajność aplikacji sieciowych jest tematem ważnym – brzmi to jak truizm, ale w rzeczywistości temat jest dość złożony i nie tak oczywisty, jak mogłoby się wydawać. W eSky temat wydajności zawsze mieliśmy z tyłu głowy. Jednakże w ostatnim czasie skupiliśmy się na nim bardziej, a obszar nabrał nowych kształtów. Wpływ na to miało wiele czynników, choć na pewno jednym z bardziej istotnych była zapowiedziana przez Google aktualizacja algorytmu wyszukiwarki. Po zmianie, znaczący wpływ na wynik indeksu zaczęła mieć jakość strony.
Po pierwsze: zbadanie stanu obecnego
Impulsem do podjęcia działań, w tym rewizji stanu obecnego, okazała się współpraca z firmami Botega IT Minds i Google. Wspólne warsztaty pozwoliły nam odnaleźć i usunąć kluczowe problemy z wydajnością wybranych obszarów naszego serwisu, a następnie poprawić sposoby działania, w tym monitorowanie i analizę danych.
W ramach prac nie tylko naprawiliśmy kilka istotnych problemów wydajnościowych, ale też wdrożyliśmy nowe narzędzia. Przede wszystkim jednak zmieniliśmy nasze postrzeganie problemów wydajności. Kluczowe było podkreślenie znaczenia biznesowego zadań z obszaru web performance i odejście od postrzegania wydajności wyłącznie jako kwestii technicznej.
Po drugie: wskaźniki wydajności
Pierwszym krokiem przy badaniu web performance jest poprawne określenie, czym jest dla nas wydajność. Może się to wydawać trywialne, no bo w końcu wystarczy uruchomić Lighthouse i odczytać wynik. Nasza wydajność wynosi, dajmy na to, 80. Ale co to faktycznie znaczy? Najpierw należy pochylić się nad samymi wskaźnikami, którymi się posługujemy. A jest ich sporo. Wspomniany wynik Lighthouse to w rzeczywistości średnia ważona kilku wskaźników, określanych jako Web Vitals oraz Speed Index, zdefiniowany i rozpropagowany przez WebPageTest.org.
Pierwsze zagadnienie to zmienność wyniku Lighthouse. Proporcje użyte do jego wyliczenia są inne w Lighthouse 6 i inne w Lighthouse 8. Trzeba mieć to na uwadze, porównując wyniki, w szczególności, jeżeli korzystamy z narzędzi, które wewnętrznie używają Lighthouse i nie mamy pewności z której konkretnie wersji. Jeśli mamy taką potrzebę, wagę poszczególnych miar możemy zdefiniować sami.
Drugie zagadnienie to same wskaźniki. Każdy z nich można powiązać ze specyficznym momentem, w którym znajduje się użytkownik przeglądający stronę. Każdy ze wskaźników odpowiada na nieco inne pytanie, między innymi szybkość ładowania, responsywność, płynność animacji. Warto zaznaczyć, że każda strona naszego serwisu może potrzebować innego podejścia – interaktywny formularz będzie wymagał solidnego FID i CLS, natomiast dla zwykłej strony produktowej znacznie ważniejsza będzie kombinacja LCP i CLS.
Trzecia rzecz to warunki, w jakich zostały wykonane testy. Generalnie możemy je robić w tzw. “polu” (field based tests lub zamiennie real user monitoring – RUM) lub laboratoryjnie, w izolowanym i powtarzalnym środowisku. W pierwszym przypadku nie kontrolujemy warunków, w jakich został zebrany pomiar (przeglądarka, system operacyjny, CPU i RAM urządzenia, typ sieci, jakość sygnału). W warunkach laboratoryjnych możemy sprecyzować kontekst, w którym dokonujemy testów. Analizując dane, dobrze jest znać bazowy profil swojego klienta i uwzględniać go w trakcie porównywania wyników.
Po czwarte, wszelkie miary o których mowa, ciągle ewoluują. Web performance, jaki chcemy zmierzyć, ma się odnosić do doświadczenia klienta (customer experience), dlatego nowsze wskaźniki nie bazują na prostym pomiarze czasu trwania, ale wplatają w pomiar swoją logikę. Takie miary jak Speed Index, CLS czy TBT są bardziej złożone, ich algorytmy są z czasem dopracowywane, a interpretacja wymaga szerszej perspektywy.
Ewaluacja wyników i dostrajanie budżetów wydajności dla poszczególnych obszarów serwisu, a także pozycjonowanie względem rynku, jest zatem w nieunikniony sposób procesem ciągłym.
Po trzecie: narzędzia do zbierania danych
Ważnym aspektem w optymalizacji wydajności są narzędzia. Na rynku dostępne jest sporo rozwiązań, czy to open source, czy też płatnych. W eSky zdecydowaliśmy, że w pierwszej kolejności potrzebujemy zbierać dane od realnych użytkowników, ale jednocześnie badać też wydajność serwisu syntetycznie. Zestaw narzędzi powinien móc wspierać proces optymalizacji na etapie programowania rozwiązań. W dalszej perspektywie, istotne mogą być narzędzia porównujące wydajność serwisu względem konkurencji lub też zestawiające ją z innymi wskaźnikami biznesowymi.
W procesie testowania różnych rozwiązań posłużyliśmy się narzędziami, które już znamy i które można było stosunkowo łatwo i szybko dostosować do naszych potrzeb.
Jeszcze w trakcie wspólnych prac z Bottega/Google posłużyliśmy się narzędziem SpeedCurve, które zostało użyte do wskazania głównych problemów, a także monitorowania postępów optymalizacji. Z czasem zestaw narzędziowy został rozszerzony. Dane RUM, czyli bezpośrednio od użytkowników, są zbierane za pomocą Elastic APM i prezentowane w Grafana. Testy syntetyczne są wplecione w nasze procesy CI/CD i realizowane za pomocą SiteSpeed.io. Wyniki prezentujemy w Grafana, a raporty utrzymujemy w Google Cloud Storage. SiteSpeed.io służy nam także jako narzędzie do uruchamiania scenariuszy testowych na żądanie, które badają wydajność tworzonego rozwiązania przed i po. Raporty z takich testów można później porównać, a wyniki badać pod kątem potencjalnego wpływu na wydajność.
Grafana służy nam nie tylko jako narzędzie wizualizujące dane, ale pozwala także na zarządzanie budżetami wydajności w odniesieniu do określonych części serwisu i odpowiada za alerty naruszeń kluczowych wskaźników.
Po czwarte: zaangażowanie biznesu
Jednym z kluczowych aspektów budowania wydajności jest zaangażowanie w ten proces działu biznes. Zespół ten nie tylko jest beneficjentem efektów optymalizacji wydajności, ale de facto jej aktywnym uczestnikiem. Każdy współczesny serwis internetowy bazuje na wielu treściach firm partnerskich, które z czasem mogą stać się problemem z punktu widzenia wydajności. Implementacja ich skryptów w sposób dynamiczny, poprzez narzędzia takie jak Google Tag Manager (GTM), sprawia że kontrola nad nimi jest utrudniona.
Narzędzia takie jak SiteSpeed.io pozwalają nam identyfikować skrypty trzecie i określać ich liczbę oraz wagę. My poszliśmy jeszcze dalej. Realizujemy dwa rodzaje testów, w którym jeden uruchamia stronę bez GTM, a więc bez zbędnych obciążeń. To pozwala nam określać realny wpływ skryptów na daną część serwisu. I tu pojawia się ważna rola biznesu. Generalnie optymalizacja takich skryptów, o ile wykluczymy ich błędną implementację, sprowadza się do ich usunięcia, ograniczenia emisji lub też dialogu z partnerem na temat potencjalnych możliwości optymalizacji. Jakkolwiek abstrakcyjna wydaje się ostatnia możliwość, w eSky mamy sukcesy także na tym polu, co pokazuje, że właściwe zaangażowanie biznesu jest nie mniej ważne niż optymalnie działający kod.
Po piąte: wydajność stałym elementem planowania
Wiedza na temat wydajności, właściwe narzędzia i zaangażowanie biznesu są kluczowe, by właściwie zdefiniować sobie cele optymalizacji wydajności. Nie chodzi tylko o określenie, które wskaźniki będą kluczowe dla danej części serwisu, ale też jaki ma być ich poziom. Jak u konkurencji? Lepiej? O ile lepiej? A może niekoniecznie musi być lepiej… Tylko mając właściwe dane oraz zaangażowane osoby biznesowej jesteśmy w stanie poprawnie zdefiniować te cele, a następnie przełożyć je na budżety, o które będziemy dbać.
Wszystko to składa się na swojego rodzaju kulturę, która raz zaszczepiona powinna być pielęgnowana i rozwijana. Jej celem jest uczynienie tematu wydajności stałym elementem planowania nowych rozwiązań, zamiast okresowych zrywów i pospolitego ruszenia. Nie jest to na pewno zadanie proste, jednak zdecydowanie warte swojej ceny, zwłaszcza teraz, gdy Google rozlicza nas z wydajności dostarczanych rozwiązań. W przyszłości natomiast dotyczyć może również innych aspektów działania stron internetowych, takich jak na przykład coraz popularniejszy Carbon Footprint.