Przypadek, w którym GoDaddy wprowadził zmiany, aby poprawić wydajność witryn dla milionów witryn, pomagając im uzyskać dobre wyniki w Google PageSpeed Insights i Podstawowych wskaźnikach internetowych.
GoDaddy to największa na świecie platforma usług dla przedsiębiorców na całym świecie. Naszą misją jest wspieranie ponad 20 milionów klientów i przedsiębiorców na całym świecie, którzy tworzą naszą globalną społeczność, oferując im pomoc i narzędzia potrzebne do rozwijania działalności w internecie.
W 2019 r. GoDaddy wprowadził usługę Websites + Marketing, aby udostępnić narzędzia i usługi, które są łatwe w użyciu i pomagają właścicielom firm w osiąganiu celów. Usługa ta integruje tworzenie witryn z narzędziami marketingowymi i e-commerce, a także zapewnia najlepsze wskazówki, aby pomóc klientom w osiąganiu sukcesu w ich nowych przedsięwzięciach.
Od czasu uruchomienia usługi Witryny i marketing wydajność była ważną częścią usługi, która była monitorowana i nad którą aktywnie pracowaliśmy. W tym artykule omówimy drogę, jaką firma GoDaddy przeszła od testowania wydajności w laboratorium do korzystania z danych z prawdziwego świata za pomocą podstawowych wskaźników internetowych. Omówimy też serię ulepszeń wprowadzonych w usłudze, które pozwoliły uzyskać bardzo wysoki wskaźnik pozytywnych wyników testów w przypadku witryn klientów.
Śledzenie wydajności za pomocą Lighthouse
Do śledzenia wydajności używamy danych Lighthouse. Za każdym razem, gdy witryna jest publikowana na platformie, mierzymy jej wydajność za pomocą naszego wewnętrznego narzędzia Lighthouse4u, które udostępnia Google Lighthouse jako usługę (https://github.com/godaddy/lighthouse4u). Dzięki temu mogliśmy uzyskać dobry obraz ogólnej wydajności witryn w warunkach laboratoryjnych.
Miliony witryn hostowanych na naszej platformie mają szeroki zakres funkcji i treści, dlatego ważne było połączenie danych o wydajności z metadanymi o każdej testowanej witrynie (np. użyty szablon, typ renderowanych widżetów itp.). Dzięki temu mogliśmy wyciągnąć wnioski dotyczące tego, które funkcje witryny mają niższą skuteczność, a także uzyskać informacje o tym, gdzie szukać możliwości poprawy.
Dzięki temu mogliśmy np. ustalić, że „wyskakujące okienko” ma negatywny wpływ na szybkość strony. Strony z tą funkcją miały o 12 punktów niższą wydajność niż bez niej. Po wprowadzeniu zmian w kodzie, które opóźniają wczytywanie JavaScriptu, poprawiliśmy wynik Lighthouse o 2 punkty. Mogliśmy zastosować te wnioski do innych funkcji, takich jak baner z informacją o plikach cookie, który wyświetla się po załadowaniu strony.
Oprócz analizowania problematycznych witryn pod kątem funkcji przeanalizowaliśmy pakiet JavaScriptu i stwierdziliśmy, że duża część jego rozmiaru pochodzi z zewnętrznych zależności (immutable.js i draft.js). Zmniejszyliśmy rozmiar pakietu, zmieniając strukturę konsumentów, aby wczytywanie zależności odbywało się z opóźnieniem na żądanie. W efekcie rozmiar typowego pakietu JavaScript zmniejszył się o ponad 50% – z ponad 200 KB do około 90 KB (skompresowany). Mniejszy rozmiar pakietu umożliwił przeglądarce wczytywanie zasobów zewnętrznych i wykonywanie kluczowych skryptów na wcześniejszym etapie początkowego wczytywania witryny, co przełożyło się na poprawę wskaźników największego wyrenderowania treści (LCP) i opóźnienia pierwszego wejścia (FID).
Dzięki naszym nieustannym wysiłkom średnia ocena Lighthouse dla stron klientów wzrosła z około 40 punktów w listopadzie 2020 r. do ponad 70 punktów w maju 2021 r. Nie wszystkie nasze próby się jednak powiodły. Czasami byliśmy zaskoczeni, że wyniki testów przeprowadzonych w lokalnych środowiskach testowych nie zawsze były zgodne z wynikami uzyskanymi w warunkach rzeczywistych. Wyniki badań laboratoryjnych były bardzo pomocne, ale nadszedł czas, aby skupić się na wrażeniach prawdziwych użytkowników obserwowanych w warunkach rzeczywistych.
Śledzenie rzeczywistych danych o użytkownikach za pomocą podstawowych wskaźników internetowych
Po dodaniu do witryn naszych klientów biblioteki web-vitals mogliśmy mierzyć dane na rzeczywistych urządzeniach pochodzące od prawdziwych użytkowników. W tym przypadku sprzęt, szybkość sieci i interakcji użytkownika (np. przewijanie lub klikanie) nie są na stałym poziomie, jak w przypadku testów Lighthouse w laboratorium. Był to duży krok we właściwym kierunku, ponieważ mieliśmy teraz dane, które były reprezentatywne dla doświadczeń użytkowników witryny.
Skupienie się na najsłabszym ogniwie: skumulowane przesunięcie układu (CLS)
Analiza nowych danych pozwoliła nam spojrzeć na problem z innego punktu widzenia i zrozumieć, co trzeba zrobić, aby zwiększyć szybkość witryny. Dzięki działaniom podjętym w celu poprawy wyniku Lighthouse nasz LCP w 50. percentylu wynosił 860 ms, a FID przy tym samym progu – poniżej 10 ms. W efekcie wskaźniki te w witrynach klientów osiągały wysoką wartość: odpowiednio 78% i 98%. Jednak wartości zbiorczego przesunięcia układu (CLS) znacznie się różnią od tych, do których przywykliśmy w Lighthouse. Nasz wynik CLS w 75.percentylu wynosił 0,17, czyli przekraczał próg 0,1, który oznacza „pozytywny wynik”. W przypadku wszystkich naszych witryn wskaźnik pozytywnych wyników wynosił więc tylko 47%.
Ta wartość obniżyła ogólną skuteczność do 40%, dlatego postanowiliśmy wyznaczyć ambitny cel, którym jest zwiększenie tego wskaźnika do ponad 60% do końca sierpnia 2021 r. Aby to zrobić, musimy się skupić na CLS.
W rzeczywistych warunkach użytkownicy wchodzą w interakcję ze stroną i przewijają zawartość „pod kartą”, co jest lepiej rejestrowane przez podstawowe wskaźniki internetowe. Ze względu na zmienność sposobu, w jaki użytkownicy wchodzą w interakcję z witryną podczas jej wczytywania, CLS różni się od danych z laboratorium i z pomiarów terenowych.
Droga do uzyskania pozytywnej oceny we wszystkich podstawowych wskaźnikach internetowych
Aby poprawić skuteczność, trzeba działać metodą prób i błędów, a nie każda próba przynosi oczekiwane rezultaty. Oto jednak kilka ulepszeń, które pomogły nam osiągnąć nasze cele.
Zarezerwowanie miejsca na wczytywanie obrazów znacznie poprawiło nasz wynik CLS, ponieważ zapobiega przesuwaniu się treści znajdujących się pod obrazami. W przypadku przeglądarek, które obsługują tę właściwość, użyliśmy właściwości CSS aspect-ratio. W przypadku tych, które tego nie robią, wczytujemy przezroczysty obraz zastępczy, który jest przechowywany w pamięci podręcznej i ma rozmiar zaledwie kilku bajtów, dzięki czemu wczytuje się niemal natychmiast.
To ogólne zachowanie obrazu pozwoliło nam wstępnie obliczyć ostateczną wysokość obrazu podczas renderowania po stronie serwera na podstawie szerokości widocznego obszaru i współczynnika proporcji obrazu. W wyniku tego znaczniki HTML z odpowiednio zarezerwowanym pionowym miejscem na końcowy obraz. Poprawa była szczególnie widoczna na urządzeniach mobilnych, ponieważ obrazy są renderowane na pełną szerokość widocznego obszaru na urządzeniach mobilnych.
Niektóre komponenty w witrynach naszych klientów zawierają zawartość dynamiczną (np. listę zewnętrznych opinii klientów), której nie można przekształcić w czysty kod CSS, aby wykorzystać zalety renderowania po stronie serwera. W tych obszarach trudno jest poprawić zmiany układu, ponieważ zawartość (a zatem wysokość) będzie się zmieniać. W takich przypadkach komponent był zapakowany w kontener z zamontowanym min-height, który został wstępnie określony na podstawie średniej wysokości poszczególnych komponentów. Element min-height jest usuwany po zakończeniu renderowania wewnętrznego komponentu dynamicznego. Chociaż nie było idealne, to pozwoliło nam znacznie zmniejszyć przesunięcie układu.
Chociaż skupialiśmy się na ulepszaniu CLS, nadal pracowaliśmy też nad LCP. W wielu witrynach to właśnie obrazy są głównym czynnikiem wpływającym na LCP, więc dla nas było to oczywiste pole do poprawy. Wprowadziliśmy ulepszenia w łatwym wczytywaniu obrazów za pomocą IntersectionObserver, ale zdaliśmy sobie sprawę, że rozmiary obrazów nie były ustawione w najbardziej optymalny sposób w przypadku poszczególnych punktów przełamania (mobilne, tablety, komputery, duże komputery), więc zaktualizowaliśmy kod generowania obrazów, aby ograniczać i skalować obrazy na potrzeby poszczególnych punktów przełamania, a potem ponownie skalować rozdzielczość na podstawie gęstości pikseli. Na przykład rozmiar dużego obrazu zmniejszył się z 192 KB do 102 KB.
Aby szybko renderować strony internetowe na urządzeniach z niestabilnym połączeniem z internetem, dodaliśmy kod, który dynamicznie zmniejsza jakość obrazu na podstawie szybkości połączenia. Można to zrobić za pomocą właściwości downlink zwracanej przez funkcję navigator.connection. Stosujemy parametry zapytania oparte na adresie URL, aby zmniejszyć jakość obrazu za pomocą interfejsu Asset API na podstawie tych warunków sieci.
Niektóre sekcje witryn naszych klientów są wczytywane dynamicznie. Wiemy, które sekcje będą renderowane w konkretnej witrynie po jej opublikowaniu, więc użyliśmy podpowiedzi zasobu rel=preconnect, aby wstępnie zainicjować połączenie i wykonać niezbędne procedury nawiązywania połączenia. Używamy też wskazówek dotyczących zasobów, aby szybko wczytywać czcionki i inne ważne zasoby.
Podczas tworzenia witryn klienci dodają różne sekcje, które mogą zawierać skrypty wstawiane inline, aby umożliwić różne funkcje. Umieszczanie tych skryptów w stronach HTML nie zawsze zapewnia optymalną wydajność. Zdecydowaliśmy się wyodrębnić te skrypty, aby umożliwić przeglądarce asynchroniczne wczytywanie i analizowanie ich zawartości. Nowe skrypty zewnętrzne można też udostępniać na różnych stronach. Umożliwiło to dodatkowe zwiększenie wydajności w postaci buforowania w przeglądarce i sieci dystrybucji treści. Pozostawiliśmy skrypty krytyczne w kodziku, aby przeglądarka mogła je szybciej analizować i wykonywać.
Wyniki
Nasze wysiłki skupione na wskaźniku CLS przyniosły efekty. Liczba stron z dostateczną wartością podstawowych wskaźników internetowych wzrosła z około 40% do prawie 70% – to poprawa o 75%.
Gdy użytkownicy wracają na naszą platformę, aby wprowadzić aktualizacje i ponownie opublikować swoje witryny, uzyskują najnowsze ulepszenia wydajności. W wyniku liczba witryn, które „przechodzą testy Core Web Vitals”, stale rośnie, co widać na wykresie poniżej:
Podsumowanie
Wyznaczanie obszarów, w których można poprawić skuteczność, i skuteczne śledzenie postępów zależy w dużej mierze od narzędzi używanych do pomiarów. Lighthouse był przydatny do pomiaru skuteczności w „warunkach laboratoryjnych”, ale nie rejestrował dokładnie problemów ze skutecznością, które występowały tylko w przypadku interakcji z użytkownikiem (np. przewijania strony).
Śledzenie podstawowych wskaźników internetowych w rzeczywistych warunkach za pomocą metadanych umożliwiło nam wizualizację, ukierunkowanie i pomiar wpływu naszych ulepszeń. Podjęcie działań mających na celu poprawę wyników w Core Web Vitals pozwoliło zespołowi zidentyfikować i zastąpić nieefektywne wzorce w naszej bazie kodu. Czasami obiecujące zmiany nie przyniosły oczekiwanych rezultatów, a czasami było odwrotnie. Świat nie jest idealny, więc musisz próbować dalej.