Case study: Optymalizacja PolarSport pod kątem Core Web Vitals

Case study: PolarSport

Optymalizacja e-commerce pod kątem Core Web Vitals

Firma: PolarSport

Branża: Sprzęt górski

System e-commerce: Magento 2

Poniższe case study jest przedrukiem oryginalnego PolarSport Case Study przygotowanego przez Alpacode.

Alpacode to strategiczny sojusz dwóch agencji e-commerce Virtua and Hatimeria.

O kliencie

PolarSport to jedna z największych sieci detalicznych oferujących sprzęt outdoorowy w Polsce. Założyciele wywodzą się ze środowiska przewodników górskich, co pozwala im doskonale rozumieć potrzeby swoich klientów. Firma posiada dziesięć sklepów w największych miastach Polski, a także prężnie rozwijającą się platformę e-commerce opartą na Magento 2, dostępną pod adresem polarsport.pl. Z biegiem czasu strona internetowa znacznie zwolniła, głównie przez brak optymalizacji. Niekonsekwentne zarządzanie treściami, niska jakość obrazów i nieefektywne tworzenie stron i podstron generowały liczne błędy. Z dnia na dzień wskaźniki wydajności ulegały pogorszeniu, co szybko wygenerowało potrzebę optymalizacji strony pod kątem Core Web Vitals (CWV).

Podejście mobile-first

Rozpoczęliśmy naszą pracę od audytu e-commerce. Statystyki z CWV pokazują, że poprawa wydajności witryny na urządzeniach mobilnych proporcjonalnie poprawia wydajność witryny na innych urządzeniach. Jednak statystyki CWV nie pokazują, jak witryna powinna być tworzona, ale jak powinna działać na urządzeniach w pierwszych sekundach wizyty użytkownika. Dlatego w pierwszej kolejności pod uwagę brany jest stan witryny uruchomionej na urządzeniach mobilnych, takich jak smartfony i tablety — ruch na stronie i jej dostępność muszą zostać zwiększone. Na początku skupiliśmy się więc na przygotowaniu złożonego i progresywnego planu. Każdy kolejny krok stopniowo zwiększał wynik, a tym samym poprawiał reakcję witryny na odwiedzających ją klientów.

Strona główna

Strona kategorii

Strona produktu

Poprawa wydajności

Obecnie statystyki wydajności (zestaw metryk, które przedstawiają wydajność strony liczbowo, co przekłada się na czas ładowania w przeglądarce i wygodę użytkowania) dla CWV składają się z następujących komponentów, które należy ulepszyć:

• FCP (First Contentful Paint) — mierzy czas ładowania pierwszego elementu na stronie po jego uruchomieniu przez użytkownika.
• LCP (Largest Contentful Paint) — mierzy czas ładowania największego elementu na stronie widocznego dla użytkownika.
• TBT (Total Blocking Time) — mierzy czas potrzebny stronie internetowej na reakcję po interakcji z nią przez użytkownika.
• CLS (Cumulative Layout Shift) — mierzy stopień, w jakim szablon strony przesunął się na ekranie, nie z powodu działań użytkownika, ale z powodu problemów programistycznych.

Aby zapewnić najlepszą poprawę, dodaliśmy dwa kolejne wskaźniki, które musiały zostać uwzględnione w optymalizacji:

• SI (Speed ​​Index) — mierzy, jak szybko zaplanowana treść wypełnia stronę, tj. jak szybko użytkownik widzi zawartość strony. Im mniejsza wartość, tym lepiej.
• TTI (Time to Interactive) – mierzy czas potrzebny na załadowanie strony, aby użytkownik mógł z niej korzystać i wchodzić z nią w interakcję.

Zaplanowaliśmy również optymalizację backendową. Zasadniczo punkty serwera sprowadzały się do zminimalizowania wartości TTFB, co miało wpływ na wskaźniki TBT i FCP Core Web Vitals. TTFB (Time to First Byte) to czas od wysłania żądania przez klienta do otrzymania pierwszej odpowiedzi. Przed optymalizacją TTFB na stronach kategorii wynosił od kilku do nawet kilkunastu sekund.

Jakie prace wykonaliśmy

Optymalizacja dla CWV to długi proces, który wymaga systematycznej i dokładnej pracy. Ta praca jest w zasadzie nieskończona – tak długo jak istnieje e-commerce, wymaga codziennej konserwacji. Jednak wszelkie zaniedbania można usunąć i można wdrożyć stałe dobre praktyki. Pracowaliśmy przez kilka miesięcy w kilku interakcjach, aby osiągnąć oczekiwane rezultaty. Ważne jest to, że pracowaliśmy na natywnym Magento Theme.

Optymalizacja frontendowa

Prace wykonaliśmu zgodnie z najlepszymi praktykami dla programistów dla Google Lighthouse. W praktyce było wiele drobnych zadań, w tym kompresja logo, kompresja obrazów i zmiana formatu webp, optymalizacja suwaków zgodnie z zaleceniami Google, czy czyste kolory w CSS. Zweryfikowaliśmy, że wszystkie znaczniki HTML <a> i <img> miały atrybuty title=”particular images titles” i alt=”Alternative content to display”, pozbyliśmy się podwójnych identyfikatorów, zweryfikowaliśmy CSS i HTML, zaktualizowaliśmy wersję oprogramowania na serwerze i usunęliśmy nieużywane moduły zewnętrzne.

Każde zadanie poprawiło szybkość strony i zapisało żądania dla serwera. Rozpoczęliśmy pracę nad optymalizacją SEO oraz wdrożyliśmy dobre praktyki. Jednocześnie przeprowadziliśmy prace nad poprawą kluczowych wskaźników.

Poprawa FCP

Aby poprawić FCP (większość prac pokrywała się z działaniami optymalizacyjnymi dla LPC, gdzie nastąpiła redukcja użytego kodu JavaScript i CSS) wstępnie załadowaliśmy zasoby z zewnętrznych witryn, takich jak googlefont.com lub fontawesome.com. Przeanalizowaliśmy również metodę ładowania czcionek Google, ograniczyliśmy ich liczbę, ładując je za pośrednictwem plików znajdujących się bezpośrednio jako statyczne pliki czcionek na serwerze, zamiast używać zewnętrznego adresu URL, takiego jak fonts.googleapis.com, i zaimplementowaliśmy opcję display = swap.

Redukcja LCP

Aby zmniejszyć wartość LCP, przejrzeliśmy i wyeliminowaliśmy nadmiernie występujące pliki JS, wyeliminowaliśmy nadmiernie występujące zapytania do zewnętrznych witryn (np. Facebook, Edrone, Sugodeku, Anilima, Retagro, Citydsp i inne) oraz sprawdziliśmy i skonfigurowaliśmy istniejącą sieć CDN. Następnym krokiem była analiza powstałego scalonego pliku CSS, wyeliminowanie zduplikowanych wpisów i nieużywanych wpisów klas CSS (takich jak bootstrap.css lub biblioteki selektora dat), przegląd innych bibliotek i modułów, które dodają własne pliki CSS do poszczególnych stron, oraz minifikacja plików CSS i JS.

Poprawa TBT

Na poprawę wskaźnika TBT wpłynęła weryfikacja zainstalowanych dodatkowych modułów, odchudzenie struktury DOM poprzez modyfikację poszczególnych plików szablonów (PHTML), weryfikacja zewnętrznych stron internetowych np.: ZenDesk, Facebook, Google Analytics, Google CDN, Bootstrap CDN, FontsAwesome CDN, Google Fonts, Google Tag Manager, New Relic, Other Google APIs/SDKs, Google/Doubleclick. Występowały również typowe operacje, które poprawiały wskaźniki TBT i LCP, takie jak lazy-loading dla zdjęć, obrazów, wyskakujących okienek, filmów i bardziej skomplikowanych skryptów.

Poprawa CLS

Wskaźnik CLS został poprawiony poprzez weryfikację, które elementy img nie mają atrybutów width i height – ograniczenie ich na stronie pozwoliło uniknąć przesunięć w czasie renderowania witryny. Zweryfikowaliśmy dodatkowe elementy i banery, które wyskakują lub przewijają się natychmiast po załadowaniu strony, uniemożliwiając prawidłową interakcję użytkowników z elementami wyświetlanymi w widoku „above the fold”. Zweryfikowaliśmy i poprawiliśmy animacje na stronie. Wzięliśmy również pod uwagę działania dedykowane konkretnym podstronom – różne dla strony głównej, kategorii i produktów.

Optymizacja backendowa

Aby poprawnie wdrożyć optymalizację, konieczna jest praca backendowa. Naszymi celami były:
1. Przyspieszenie sklepu internetowego tak, aby ładowanie frontu dla nagłówka x-cache: MISS header nie trwało dłużej niż 1 sekundę.
2. Poprawa ustawień Varnish, Redisa i nagłówków.
3. Skrócenie czasu TTFP poniżej 400 ms i tego, co wpływa na długi TTFB w Magento 2:

– Brak optymalizacji kodu źródłowego,

– Nieprawidłowe ustawienia serwera,

– Brak buforowania back-endu,

– Brak optymalizacji bazy danych.

4. Wyeliminowanie zapytań mySQL obciążających bazę danych.
5. Poprawa stabilności www.polarsport.pl.

Zaplanowaliśmy naszą pracę według następujących kroków:

– Analiza i wybór kluczowych KP.

– Priorytetyzacja zadań i stworzenie harmonogramu pracy.

– Praca programistyczna, testy i wdrażanie zaplanowanych zadań.