Studium przypadku dotyczące kilku istotnych zmian wprowadzonych w Wix z myślą o poprawie szybkości ładowania witryn w przypadku milionów witryn i ułatwia im uzyskiwanie dobrych wyników w PageSpeed Insights i podstawowych wskaźnikach internetowych.
Dzięki wykorzystaniu standardów branżowych, dostawców usług w chmurze i funkcji CDN w połączeniu z dużym przepisywaniem naszego środowiska wykonawczego witryny odsetek witryn Wix, które osiągają dobre 75. percentyl wyników dla wszystkich podstawowych wskaźników internetowych, ponad trzykrotnie wzrósł rok do roku – jak wynika z danych CrUX i HTTPArchive.
Wix działa w kulturze ukierunkowanej na wydajność, a użytkownicy będą nadal wdrażać kolejne ulepszenia. Gdy skupiamy się na wskaźnikach KPI wydajności, spodziewamy się, że liczba witryn, które przekroczy wartości progowe podstawowych wskaźników internetowych, będzie rosnąć.
Przegląd
Świat skuteczności jest pięknie skomplikowany z wieloma zmiennymi i elementami. Badania pokazują, że szybkość witryny ma bezpośredni wpływ na współczynniki konwersji i przychody dla firm. W ostatnich latach branża kładzie nacisk na widoczność w zakresie wydajności i przyspieszanie działania sieci. Od maja 2021 r. sygnały dotyczące jakości strony będą uwzględniane w rankingu w wyszukiwarce Google.
Wyjątkowym wyzwaniem w Wix jest obsługa milionów witryn, z których część została zbudowana wiele lat temu i od tego czasu nie jest aktualizowana. Udostępniamy różne narzędzia i artykuły, które pomagają użytkownikom analizować i zwiększać skuteczność witryn.
Wix to środowisko zarządzane, więc nie wszystko jest w rękach użytkownika. Współdzielenie wspólnej infrastruktury stwarza wiele wyzwań dla wszystkich tych witryn, ale stwarza też możliwość wprowadzenia istotnych ulepszeń we wszystkich usługach, tj. wykorzystywania korzyści skali.
Mówienie w swoim języku
Jednym z głównych problemów związanych z wydajnością jest znalezienie wspólnej terminologii do omawiania różnych aspektów wrażeń użytkownika przy jednoczesnym uwzględnieniu wydajności zarówno technicznej, jak i postrzeganej. Używanie dobrze zdefiniowanego i wspólnego języka w organizacji umożliwiło nam łatwe omawianie i kategoryzowanie różnych aspektów technicznych i zalet, doprecyzowanie raportów skuteczności oraz bardzo pomogło zrozumieć, na czym należy się skupić w pierwszej kolejności.
Poprawiliśmy wszystkie nasze monitorowanie i wewnętrzne dyskusje, aby uwzględniały dane zgodne ze standardami branżowymi, takie jak wskaźniki internetowe, w tym:
Złożoność witryny i wyniki wydajności
Utworzenie witryny, która wczytuje się natychmiast, jest bardzo proste. Wystarczy, że uprościsz ją za pomocą języka HTML i będziesz ją wyświetlać przez CDN.
Prawda jest jednak taka, że witryny stają się coraz bardziej złożone i zaawansowane, działają bardziej jak aplikacje niż dokumenty i obsługują takie funkcje, jak blogi, rozwiązania e-commerce, niestandardowy kod itp.
Wix udostępnia bardzo duży różnorodność szablonów, co umożliwia użytkownikom łatwe tworzenie witryn o różnych możliwościach biznesowych. Te dodatkowe funkcje często wiążą się z pewnymi kosztami wydajności.
Podróż
Na początku był to kod HTML,
Przy każdorazowym wczytaniu strony internetowej rozpoczyna się ona zawsze od wstępnego żądania na adres URL w celu pobrania dokumentu HTML. Ta odpowiedź HTML aktywuje wszystkie dodatkowe żądania klienta i logikę przeglądarki, aby uruchomić i wyrenderować witrynę. To najważniejsza część wczytywania strony, ponieważ nic się nie dzieje, dopóki nie pojawi się początek odpowiedzi (tzw. TTFB, czyli czas do pierwszego bajtu).
Przeszłość: renderowanie po stronie klienta
W przypadku obsługi dużych systemów zawsze musisz się liczyć z kompromisami dotyczącymi wydajności, niezawodności i kosztów. Jeszcze kilka lat temu Wix wykorzystywała renderowanie po stronie klienta, w ramach którego rzeczywiste treści HTML były generowane za pomocą JavaScriptu po stronie klienta (tj.w przeglądarce). Dzięki temu mogliśmy obsługiwać wiele witryn bez ponoszenia ogromnych kosztów operacyjnych.
Przedstawiciel obsługi klienta pozwolił nam użyć zwykłego dokumentu HTML, który był zasadniczo pusty. Spowoduje to tylko pobranie wymaganego kodu i danych, które zostały użyte do wygenerowania pełnego kodu HTML na urządzeniu klienckim.
Dzisiaj: renderowanie po stronie serwera (SSR)
Kilka lat temu przeszliśmy na renderowanie po stronie serwera (SSR), co przyniosło korzyści SEO i skuteczności witryny, poprawiło początkową widoczność strony i zapewniło lepsze indeksowanie w wyszukiwarkach, które nie obsługują JavaScriptu w pełni.
Takie podejście poprawiło widoczność, zwłaszcza w przypadku wolniejszych urządzeń lub połączeń, i umożliwiło dalszą optymalizację wydajności. Oznaczało to jednak, że na bieżąco generowana była unikalna odpowiedź HTML na każde żądanie strony internetowej, co jest znacznie od optymalnego, zwłaszcza w przypadku witryn z dużą liczbą wyświetleń.
Wprowadzamy buforowanie w wielu lokalizacjach
Kod HTML każdej witryny był w większości statyczny, ale miał kilka zastrzeżenia:
- Często się zmienia. Za każdym razem, gdy użytkownik edytuje swoją witrynę lub wprowadza zmiany w danych witryny, np. w asortymencie sklepu.
- Miała ona określone dane i pliki cookie dotyczące konkretnych użytkowników, co oznacza, że 2 osoby odwiedzające tę samą witrynę zobaczą nieco inny kod HTML. Dotyczy to na przykład obsługi funkcji produktów, takich jak zapamiętywanie, jakie produkty użytkownik dodał do koszyka, lub czat, który użytkownik rozpoczął wcześniej z firmą.
- Nie wszystkie strony można zapisywać w pamięci podręcznej. Na przykład strona z niestandardowym kodem użytkownika, która wyświetla bieżącą godzinę w ramach dokumentu, nie kwalifikuje się do buforowania.
Początkowo korzystaliśmy ze stosunkowo bezpiecznego sposobu umieszczania kodu HTML w pamięci podręcznej bez danych użytkownika, a następnie modyfikowaliśmy na bieżąco tylko określone fragmenty odpowiedzi HTML w przypadku każdego użytkownika w przypadku każdego trafienia w pamięci podręcznej.
Wewnętrzne rozwiązanie CDN
W tym celu wdrożyliśmy własne rozwiązanie – za pomocą pamięci podręcznej HTTP Vary do obsługi serwera proxy i buforowania, usługę Kafka do obsługi komunikatów o nieprawidłowości oraz usługę opartą na Scala/Netty, która pośredniczy w tych odpowiedziach HTML, ale mutuje kod HTML i dodaje do odpowiedzi zapisanej w pamięci podręcznej dane specyficzne dla użytkownika oraz pliki cookie.
To rozwiązanie umożliwiło nam wdrożenie wąskich komponentów w większej liczbie lokalizacji geograficznych i regionach dostawców usług chmurowych rozsianych po całym świecie. W 2019 r. wprowadziliśmy ponad 15 nowych regionów i stopniowo włączyliśmy zapisywanie w pamięci podręcznej w przypadku ponad 90% wyświetleń stron, które kwalifikowały się do takiego buforowania. Wyświetlanie witryn z dodatkowych lokalizacji zmniejszyło opóźnienie sieciowe między klientami a serwerami obsługującymi odpowiedź HTML, ponieważ treści są bliżej użytkowników witryny.
Zaczęliśmy też buforować niektóre odpowiedzi interfejsu API tylko do odczytu, korzystając z tego samego rozwiązania i unieważniając pamięć podręczną po każdej zmianie treści witryny. Na przykład lista postów na blogu w witrynie jest przechowywana w pamięci podręcznej i jest unieważniona po opublikowaniu/zmodyfikowaniu posta.
Mniejsze złożoność
Wdrożenie buforowania znacznie poprawiło wydajność, głównie na etapach TTFB i FCP, oraz poprawiło naszą niezawodność dzięki wyświetlaniu treści z lokalizacji bliżej użytkownika.
Jednak konieczność modyfikowania kodu HTML każdej odpowiedzi spowodowała jednak niepotrzebną złożoność. Usunięcie tej odpowiedzi dało możliwość dalszego zwiększenia wydajności.
Buforowanie przeglądarki (i przygotowanie do obsługi sieci CDN)
Około 13%
Żądania HTML obsługiwane bezpośrednio z pamięci podręcznej przeglądarki, co oszczędza dużo przepustowości i skraca czas wczytywania ponownych wyświetleń.
Kolejnym krokiem było całkowite usunięcie z kodu HTML danych dotyczących użytkowników i pobranie ich z osobnego punktu końcowego, wywoływanego w tym celu przez klienta po dostarczeniu kodu HTML.
Starannie przenieśliśmy te dane i pliki cookie do nowego punktu końcowego, który jest wywoływany przy każdym wczytaniu strony, ale zwraca smukły plik JSON, który jest wymagany tylko do procesu nawodnienia, aby zapewnić interaktywność na całej stronie.
Pozwoliło nam to włączyć zapisywanie kodu HTML w pamięci podręcznej przeglądarki, co oznacza, że przeglądarki zapisują odpowiedź HTML na potrzeby ponownych wizyt i wywołują jedynie serwer w celu sprawdzenia, czy treść się nie zmieniła. Służy do tego HTTP ETag, czyli identyfikator przypisany do konkretnej wersji zasobu HTML. Jeśli treść pozostaje taka sama, nasze serwery do klienta otrzymują odpowiedź 304 (nie zmodyfikowano) bez treści.
Dodatkowo ta zmiana oznacza, że nasz kod HTML nie jest już przeznaczony dla użytkowników i nie zawiera plików cookie. Innymi słowy, można ją przechowywać w pamięci podręcznej w dowolnym miejscu, co daje możliwość korzystania z usług dostawców CDN, którzy oferują znacznie lepsze usługi geograficzne w setkach lokalizacji na całym świecie.
DNS, SSL i HTTP/2
Po włączeniu buforowania czasy oczekiwania zostały skrócone, a inne ważne elementy początkowego połączenia stały się dłuższe. Ulepszona infrastruktura sieciowa i monitorowanie pozwoliły nam skrócić czas DNS, połączeń i protokołu SSL.
HTTP/2 był włączony we wszystkich domenach użytkowników, co zmniejszało zarówno liczbę wymaganych połączeń, jak i obciążenia związane z każdym nowym połączeniem. Wdrożenie tej zmiany było stosunkowo łatwe, przy jednoczesnym wykorzystaniu zalet protokołu HTTP/2 w zakresie wydajności i odporności.
Kompresja Brotli (w porównaniu z gzip)
21–25%
Zmniejszenie mediany rozmiaru transferu plików
Tradycyjnie wszystkie pliki były kompresowane za pomocą kompresji gzip, która jest najczęściej spotykaną opcją kompresji HTML w internecie. Protokół ten został po raz pierwszy wdrożony prawie 30 lat temu.
Nowsza kompresja Brotli wprowadza usprawnienia w zakresie kompresji niemal bez żadnych kompresji i powoli staje się coraz bardziej popularna, co opisaliśmy w corocznym rozdziałie dotyczącym kompresji Web Almanac. Od jakiegoś czasu jest ona obsługiwana przez wszystkie główne przeglądarki.
Włączyliśmy obsługę Brotli w naszych serwerach proxy nginx na brzegu sieci dla wszystkich klientów, które ją obsługują.
Przejście na kompresję Brotli skróciło medianę rozmiaru przesyłanych plików o 21–25%, co zmniejszyło wykorzystanie przepustowości i skróciło czas wczytywania.
Sieci dostarczania treści (CDN)
Dynamiczny wybór sieci CDN
W Wix zawsze wykorzystywaliśmy sieci CDN do przesyłania całego kodu i obrazów JavaScript w witrynach użytkowników.
Niedawno przeprowadziliśmy integrację z rozwiązaniem naszego dostawcy DNS, aby automatycznie wybrać najlepszą sieć CDN na podstawie sieci i źródła klienta. Dzięki temu możemy wyświetlać pliki statyczne z najlepszej lokalizacji dla każdego użytkownika i uniknąć problemów z dostępnością w określonej sieci CDN.
Już wkrótce... domeny użytkownika obsługiwane przez sieci CDN
Ostatnim elementem łamigłówki jest dostarczanie ostatniej (najważniejszej) części przez sieć CDN: kod HTML z domeny użytkownika.
Zgodnie z opisem powyżej stworzyliśmy własne rozwiązanie do buforowania i wyświetlania wyników HTML i API związanych z daną witryną. Utrzymanie tego rozwiązania w wielu nowych regionach wiąże się również z kosztami operacyjnymi, a dodawanie nowych lokalizacji staje się procesem, którym musimy zarządzać i stale optymalizować.
Obecnie integrujemy się z różnymi dostawcami CDN, aby umożliwić wyświetlanie całej witryny Wix bezpośrednio z lokalizacji CDN. Pozwala to usprawnić dystrybucję naszych serwerów na całym świecie i tym samym dodatkowo skrócić czas odpowiedzi. Jest to wyzwanie ze względu na dużą liczbę obsługiwanych przez nas domen, które wymagają zamknięcia SSL na brzegu sieci.
Integracja z sieciami CDN sprawia, że witryny Wix są bliżej klienta niż kiedykolwiek wcześniej, a wczytywanie obejmuje więcej usprawnień, w tym nowsze technologie, takie jak HTTP/3, bez żadnego wysiłku z naszej strony.
Kilka słów o monitorowaniu wydajności
Prowadzisz witrynę Wix, zapewne zastanawiasz się, jak wpłynie to na jej wyniki i jak wypadamy na tle innych platform witryn.
Większość z powyższych zadań została wdrożona w ubiegłym roku, a niektóre są nadal wdrażane.
W ostatnio opublikowano edycję z 2020 r. w publikacji Web Almanac by HTTPArchive, która zawiera doskonały rozdział na temat wrażeń użytkowników systemu CMS. Pamiętaj, że wiele danych opisanych w tym artykule pochodzi z połowy 2020 roku.
W 2021 r. nie możemy się już doczekać, kiedy pojawi się zaktualizowany raport. Na bieżąco monitorujemy raporty CrUX dotyczące naszych witryn oraz wewnętrzne dane o skuteczności.
Dokładamy wszelkich starań, aby stale skracać czas wczytywania i udostępniać naszym użytkownikom platformę, na której mogą tworzyć witryny według własnego uznania bez obniżania wydajności.
Firma DebugBear opublikowała niedawno bardzo interesującą weryfikację skuteczności kreatora witryn, która obejmuje niektóre ze wspomnianych wyżej obszarów i sprawdza wydajność bardzo prostych witryn tworzonych na każdej z platform. Ta witryna została zbudowana prawie 2 lata temu i od tego czasu nie była modyfikowana, ale platforma wciąż się udoskonala, a wraz z nią jej skuteczność można zaobserwować, sprawdzając dane z ubiegłego półtora roku.
Podsumowanie
Mamy nadzieję, że nasze doświadczenie zainspiruje Cię do wdrożenia w Twojej organizacji kultury ukierunkowanej na skuteczność oraz że podane wyżej informacje będą przydatne i przydatne w odniesieniu do Twojej platformy lub witryny.
Podsumowując:
- Wybierz zestaw wskaźników, które możesz regularnie monitorować za pomocą narzędzi zatwierdzonych przez branżę. Zalecamy stosowanie podstawowych wskaźników internetowych.
- Wykorzystaj pamięć podręczną przeglądarki i sieci CDN.
- Przejdź na HTTP/2 (lub HTTP/3, jeśli to możliwe).
- Użyj kompresji Brotli.
Dziękujemy za zapoznanie się z naszą historią. Zachęcamy do zadawania pytań, dzielenia się pomysłami na Twitterze i GitHub oraz do udziału w rozmowach na temat wydajności w ulubionych kanałach.