Studium przypadku dotyczące zmian wprowadzonych przez firmę GoDaddy w celu zwiększenia wydajności milionów witryn i osiągnięcia dobrych wyników w PageSpeed Insights i podstawowych wskaźnikach internetowych.
GoDaddy to największa na świecie platforma usługowa dla przedsiębiorców z całego świata. Naszym celem jest wspomaganie naszej światowej społeczności liczącej ponad 20 milionów klientów i przedsiębiorców z całego świata przez udzielanie im pomocy i narzędzi niezbędnych do rozwoju online.
W 2019 roku firma GoDaddy wprowadziła witrynę Websites i Marketing, oferując łatwe w obsłudze narzędzia i usługi, które pomagają właścicielom firm osiągać cele. Usługa ta polega na połączeniu tworzenia witryn internetowych z narzędziami marketingowymi i e-commerce oraz zapewnia najlepsze w swojej klasie wskazówki, aby pomóc klientom w osiągnięciu sukcesu w ich nowych przedsięwzięciach.
Od wprowadzenia na rynek wersji „Strony internetowe i marketing” skuteczność jest istotnym elementem usługi, którą monitorujemy i pracujemy nad nią aktywnie. W tym artykule omówimy drogę GoDaddy od używania laboratoryjnych testów wydajności do wykorzystywania rzeczywistych danych z podstawowymi wskaźnikami internetowymi oraz serii ulepszeń wprowadzonych w usłudze z myślą o bardzo wysokim wskaźniku sprawności stron naszych klientów.
Śledzenie skuteczności za pomocą Lighthouse
Używamy danych z Lighthouse do śledzenia skuteczności. Za każdym razem, gdy na platformie publikujemy witrynę, mierzymy jej wydajność za pomocą naszego wewnętrznego narzędzia o nazwie „Lighthouse4u”, które udostępnia Google Lighthouse jako usługę https://github.com/godaddy/lighthouse4u. Dostarczało nam to informacji na temat ogólnej skuteczności witryn w warunkach laboratoryjnych.
Miliony witryn hostowanych na naszej platformie mają szeroki zakres funkcji i treści, dlatego było ważne, aby połączyć dane dotyczące wydajności z metadanymi o każdej testowanej witrynie (np. użyty szablon, typ renderowanych widżetów itp.). Pozwoliło nam to wyciągnąć wnioski dotyczące elementów witryny, które miały gorszą skuteczność, a jednocześnie dało nam znać, gdzie szukać ulepszeń.
Dzięki temu na przykład stwierdziliśmy, że „wyskakujące okienko” ma negatywny wpływ na szybkość strony. W przypadku witryn, w których dostępna jest ta funkcja, wyniki były o 12 punktów niższe niż bez niego. Po wprowadzeniu zmian w kodzie, które opóźniają wczytywanie JavaScriptu, poprawiliśmy wynik w Lighthouse o 2 punkty. Udało nam się zastosować tę wiedzę do innych funkcji, takich jak „baner z plikami cookie”, który jest renderowany wkrótce po wczytaniu strony.
Oprócz przyjrzenia się problematycznym witrynom na podstawie cech, przeprowadziliśmy analizę naszego pakietu JavaScript i stwierdziliśmy, że duża część jego rozmiaru pochodzi z zależności zewnętrznych (immutable.js i Draft.js). Zmniejszyliśmy rozmiar pakietu, zmieniając strukturę konsumentów w taki sposób, aby korzystał z leniwego ładowania w zależności od popytu. W rezultacie rozmiar typowego pakietu JavaScript zmniejszył się o ponad 50%, który wzrósł z ponad 200 KB do około 90 KB (zminimalizowane). Mniejszy pakiet pozwala przeglądarce wczytywać zewnętrzne zasoby i wykonywać kluczowe skrypty na wcześniejszym etapie cyklu wczytywania witryny, co przynosi korzyści w zakresie największego wyrenderowania treści (LCP) i opóźnienia po pierwszym działaniu (FID).
Dzięki naszym nieustającym wysiłkom średni wynik witryny klientów w Lighthouse w listopadzie 2020 r. wzrósł z około 40 punktów do ponad 70 punktów w maju 2021 r. Jednak nie wszystkie nasze próby się sprawdziły i niekiedy byliśmy zaskoczeni, gdy wyniki nie zawsze były spójne między wynikami testowanymi w lokalnych środowiskach testowych a wynikami w terenie. Wyniki modułu były bardzo pomocne, ale teraz czas skupić się na rzeczywistych wrażeniach użytkowników, które zaobserwowano w tej dziedzinie.
Śledzenie rzeczywistych danych użytkowników za pomocą podstawowych wskaźników internetowych
Po dodaniu biblioteki web-vitals do witryn klientów mogliśmy mierzyć dane dotyczące rzeczywistych urządzeń pochodzące od rzeczywistych użytkowników, gdzie sprzęt, szybkość sieci i interakcje użytkowników (np. przewijanie lub klikanie) nie są utrzymywane na stabilnym poziomie, jak miało to miejsce w przypadku laboratorium korzystającego z Lighthouse. To był ważny krok we właściwym kierunku, ponieważ mieliśmy teraz dane reprezentujące wrażenia użytkowników witryny.
Skupimy się na najsłabszym linku: skumulowanym przesunięciem układu (CLS)
Analiza nowych danych dała nam nową perspektywę tego, co należy zrobić, aby zwiększyć szybkość witryny. W związku z poprawą wyniku Lighthouse nasze 75 percentyl LCP wynosił 860 ms, a FID przy tym samym progu poniżej 10 ms, więc osiągnęliśmy wysoki współczynnik zaliczeń dla tych wskaźników w witrynach naszych klientów: odpowiednio 78% i 98%. Jednak wartości w polu skumulowanego przesunięcia układu (CLS) wyglądają zupełnie inaczej niż w przypadku narzędzia Lighthouse. Nasz wskaźnik CLS w 75.centylu wynosił 0,17 – powyżej progu 0,1 do wyniku testu.W związku z tym współczynnik zdania wyniósł tylko 47% we wszystkich witrynach.
Ten wskaźnik obniżył ogólny współczynnik zdawalności do 40%, więc postanowiliśmy ambitnie wyznaczyć ambitny cel, aby do końca sierpnia 2021 r. podnieść ten wskaźnik do ponad 60%. W tym celu musimy skupić się na CLS.
W rzeczywistości użytkownicy wchodzą w interakcje ze stroną i przewijają poza część strony widoczną na ekranie, co lepiej wykrywa podstawowe wskaźniki internetowe. Ze względu na zmienność w sposobie, w jaki użytkownicy korzystają z witryny podczas początkowego ładowania, wskaźnik CLS różnił się od danych laboratoryjnych i polowych.
Droga do osiągnięcia wszystkich podstawowych wskaźników internetowych
Ulepszanie wydajności wymaga metody prób i błędów, a nie każda próba nie zawsze działa zgodnie z oczekiwaniami. Przedstawiamy jednak kilka ulepszeń, które pomogły nam osiągnąć te cele.
Zarezerwowanie miejsca na wczytywanie obrazów znacznie poprawiło wynik CLS, ponieważ zapobiega przesuwaniu się treści pod obrazami. Zastosowaliśmy właściwość CSS aspect-ratio do rozwiązania tego problemu w przeglądarkach, które ją obsługują. W przypadku pozostałych użytkowników wczytaliśmy przezroczysty obraz zastępczy, który został zapisany w pamięci podręcznej i ma rozmiar zaledwie kilku bajtów, dzięki czemu wczytywał się niemal natychmiast.
To ogólne działanie obrazu pozwoliło nam wstępnie obliczyć wysokość ostatecznego obrazu podczas renderowania po stronie serwera na podstawie szerokości widocznego obszaru i współczynnika proporcji obrazu. W rezultacie w znacznikach HTML znajduje się przestrzeń pionowa odpowiednio zarezerwowana dla ostatecznego obrazu. Poprawę można było zaobserwować szczególnie na urządzeniach mobilnych, ponieważ obrazy są renderowane na całej długości widocznego obszaru urządzeń mobilnych.
Niektóre komponenty witryn naszych klientów mają zawartość dynamiczną (np. listę zewnętrznych opinii klientów) i nie można ich przekonwertować na zwykły kod CSS, aby wykorzystać korzyści związane z wydajnością dzięki renderowaniu po stronie serwera. Są to obszary wymagające poprawy przesunięcia układu, ponieważ treść (a zatem wysokość) będzie różna. W takich przypadkach zapakowaliśmy komponent do kontenera z zastosowanym parametrem min-height, ustalonym z góry na podstawie obserwacji średniej wysokości każdego z komponentów. min-height jest usuwany po zakończeniu renderowania wewnętrznego komponentu dynamicznego. To rozwiązanie nie jest idealne, ale pozwoliło znacznie ograniczyć przesunięcie układu.
Koncentrując się na ulepszeniach CLS, nadal pracowaliśmy nad LCP. W przypadku wielu witryn to właśnie obrazy mają największy wpływ na wartość LCP i jest to dla nas oczywisty obszar ulepszeń. Wprowadziliśmy ulepszenia dotyczące leniwego ładowania obrazów za pomocą IntersectionObserver, ale zdaliśmy sobie sprawę, że ich rozmiar nie jest ustawiony w optymalny sposób dla każdego punktu przerwania (na urządzenia mobilne, tablety, komputery, duże komputery). Dlatego zaktualizowaliśmy kod generowania obrazów, aby ograniczać i skalować obrazy według punktu przerwania, a następnie skalować rozdzielczość odpowiednio do gęstości pikseli. Na przykład zmniejszyliśmy rozmiar konkretnego dużego obrazu ze 192 KB do 102 KB.
Aby szybko renderować strony internetowe na urządzeniach ze słabą jakością połączenia sieciowego, dodaliśmy kod, który dynamicznie zmniejsza jakość obrazów na podstawie szybkości połączenia. Możesz to zrobić, używając właściwości downlink zwróconej przez navigator.connection. Na podstawie tych warunków sieciowych używamy parametrów zapytań opartych na adresach URL, aby obniżyć jakość zdjęć przez nasz interfejs API zasobów.
Kilka sekcji witryn naszych klientów jest ładowanych dynamicznie. Ponieważ wiemy, które sekcje zostaną wyrenderowane w danej witrynie po jej opublikowaniu, użyliśmy wskaźnika zasobu rel=preconnect do zainicjowania połączenia i odpowiednich uzgadniania połączenia z wyprzedzeniem. Korzystamy też ze wskazówek dotyczących zasobów, aby szybko ładować czcionki i inne ważne zasoby.
Podczas tworzenia witryn klienci dodają różne sekcje, które mogą zawierać wbudowane skrypty pozwalające na korzystanie z różnych funkcji. Wbudowanie tych skryptów na stronie HTML nie zawsze zapewnia optymalną wydajność. Zdecydowaliśmy się udostępnić te skrypty na zewnątrz, aby umożliwić przeglądarce asynchroniczne ładowanie i analizowanie treści skryptu. Skrypty nowo udostępnione na zewnątrz mogą być też udostępniane na innych stronach. Zwiększyło to wydajność w postaci buforowania przeglądarki i sieci CDN. Pozostawiliśmy w tej sekcji krytyczne skrypty, aby umożliwić przeglądarce szybsze analizowanie i wykonywanie ich.
Wyniki
Wysiłki w kwestii CLS się opłaciły, więc współczynnik ukończenia naszych podstawowych wskaźników internetowych wzrósł z około 40% do prawie 70%, czyli wzrost o 75%.
Użytkownicy wracają na naszą platformę, by wprowadzać aktualizacje i ponownie publikować swoje strony, odnotowują najnowsze ulepszenia wydajności. W rezultacie liczba witryn spełniających „podstawowe wskaźniki internetowe” stale rośnie, jak widać na wykresie poniżej:
Podsumowanie
Znalezienie obszarów wymagających poprawy skuteczności i skutecznego śledzenia postępów w dużym stopniu zależy od narzędzi używanych do pomiarów. Narzędzie Lighthouse było przydatne do pomiaru skuteczności części strony widocznej na ekranie w ramach laboratorium, ale nie wychwyciło dokładnie problemów z wydajnością, które występowały wyłącznie w wyniku interakcji użytkownika (np. przewijania strony).
Śledzenie rzeczywistych podstawowych wskaźników internetowych za pomocą metadanych umożliwiło nam wizualizację, kierowanie i mierzenie wpływu wprowadzonych ulepszeń. Dążenie do poprawy wyników podstawowych wskaźników internetowych pozwoliło zespołowi zidentyfikować i zastępować nieprawidłowe wzorce znalezione w naszej bazie kodu. Czasami obiecujące zmiany nie dały oczekiwanych efektów, a w innych przypadkach stało się inaczej. To niezwykły świat, więc trzeba próbować dalej.