Badania pokazują, że 40% kupujących porzuca zakupy, jeśli strona ładuje się dłużej niż 3 sekundy. Szybkość działania serwisu jest więc ważna dla eCommerce i dlatego wiele firm wydaje kilka, a nawet kilkanaście tysięcy złotych miesięcznie na jej optymalizację. Raccoon Storefront, autorski front-endowy interfejs Headless Commerce wykorzystywany w platformie 'merce, rozwiązuje ten problem. Ma to też nieoczywiste korzyści, jak na przykład pozytywny wpływ na wyniki SEO.
Szybkość mierzona przez PageSpeed Insights
Specjaliści do spraw eCommerce za podstawę oceny szybkości witryny przyjmują wyniki z popularnego PageSpeed Insights. To stworzone przez Google narzędzie służy do analizy i oceny wydajności stron na urządzeniach mobilnych i desktopowych. PageSpeed Insights bierze pod uwagę różne aspekty witryny, takie jak prędkość ładowania, optymalizacja dla urządzeń mobilnych, wydajność sieciowa i wiele innych. Na podstawie tych wyników udziela również zaleceń dotyczących polepszenia wydajności frontu, co może pomóc w poprawie doświadczenia użytkownika oraz pozycji w wynikach wyszukiwania. Ocena zależy od różnych czynników, które wpływają na wydajność i optymalizację. Kilka głównych elementów, które mogą wpływać na wynik to:
- Szybkość ładowania. Jednym z najważniejszych czynników jest czas potrzebny na załadowanie się strony. Im jest on krótszy, tym wyższa ocena.
- Optymalizacja obrazów. Rozmiar i format obrazów mają istotny wpływ na prędkość ładowania. PageSpeed weryfikuje, czy obrazy są zoptymalizowane i czy są kompresowane w odpowiedni sposób.
- Optymalizacja kodu. Ocena może być też zależna od czystości i efektywności kodu HTML, CSS i JavaScript. Nieoptymalny kod może spowalniać ładowanie witryny.
- Optymalizacja dla urządzeń mobilnych. PageSpeed bierze pod uwagę, czy strona jest odpowiednio dostosowana do urządzeń mobilnych. Optymalizacja dla mobilnych użytkowników jest kluczowa w erze smartfonów.
- Wydajność sieciowa. Narzędzie analizuje także wydajność sieciową, w tym czas potrzebny na pobranie zasobów strony z serwera.
- Caching. Wykorzystanie mechanizmu pamięci podręcznej przeglądarki cache może znacząco przyspieszyć ładowanie strony dla użytkowników, a tym samym poprawić ocenę.
Wyniki PageSpeed Insights w eCommerce
Mając tak szczegółową listę rzeczy, o które należy zadbać w celu poprawy wydajności, nie wszystkie eCommerce dobrze wypadają w tych pomiarach. Dzieje się tak z kilku powodów. Narzędzie zostało stworzone dla statycznych stron, którymi platformy eCommerce nigdy nie były i nigdy nie będą. Dlatego główne powody słabego wypadania serwisów eCommerce w PageSpeed Insights to:
- Ilość zasobów. Platformy eCommerce często zawierają dużą ilość obrazów, produktów, skryptów JavaScript, arkuszy stylów CSS oraz innych zasobów. Tak duża ich liczba może znacząco wpływać na czas ich ładowania.
- Złożone funkcje. Strony często zawierają wiele funkcji, takich jak proces płatności, filtry, rekomendacje produktów itp. Implementacja tych rozwiązań może spowodować dodatkowe żądania sieciowe i skrypty, które mogą spowalniać ładowanie.
- Dynamiczna zawartość. Produkty, ceny, dostępność i inne dane mogą być dynamicznie generowane z bazy danych. To oznacza, że strona musi często je pobierać, co może mieć wpływ na wydajność.
- Integracje z zewnętrznymi usługami. Serwisy często korzystają z różnych usług, takich jak płatności, analiza danych, kody traktujące, marketingowe i inne. Integracja usług może wprowadzać dodatkowe żądania sieciowe i skrypty, które wpływają na wyniki.
- Optymalizacja obrazów. Zdjęcia produktów są ważnym elementem sprzedaży online, jednak mogą one być również głównym źródłem spowolnienia ładowania witryny, jeśli nie są odpowiednio zoptymalizowane pod względem wielkości i formatu.
Jednak nawet obiektywnie szybkie w działaniu serwisy potrafiły słabo wypadać w badaniu. Przyczyną było samo narzędzie. Nie dokonuje ono podczas pomiarów żadnych interakcji: nie przewija zdjęć, nie dodaje produktów do koszyka, nie nalicza rabatów – sprawdza głównie czas ściągnięcia wybranych elementów. Istniały więc bardzo szybkie w działaniu platformy eCommerce, które posiadały niski scoring od Google. A ten wpływał negatywnie na pozycje w wynikach wyszukiwania, bo Google twierdziło, że jeśli strona ma słaby wynik, to nie daje użytkownikom dobrego doświadczenia. Dlatego szukano rozwiązania, które wpłynie na nie tylko na szybkość serwisu, ale także na jego dobry wynik dla Google. Jednym z nich jest oddzielenie front-endu od back-endu.
Headless Commerce jako źródło zmiany
Headless to pojęcie, które odnosi się do architektury eCommerce, w której front-end i back-end są rozdzielone. W tradycyjnym podejściu front-end, czyli to, co widzą użytkownicy na stronie i back-end, czyli logika biznesowa i bazy danych, są ściśle powiązane. Headless pozwala na większą elastyczność i skalowalność, ponieważ można łatwiej aktualizować i modyfikować front-end bez wpływu na back-end. Analizy rynkowe zakładają, że do 2026 roku ponad 33% wszystkich platform eCommerce będzie korzystało z technologii headless. Już teraz badania pokazują, że 84% firm korzystających z headless commerce deklaruje lepsze działanie platformy, a 38% z nich zauważyło poprawę rankingu SEO.
W platformie 'merce stworzyliśmy autorskie podejście do tego tematu i wykorzystujemy Raccoon Storefront, front-endowy interfejs Headless Commerce. Podczas jego budowy i rozwoju szczególną kwestię położyliśmy na czterech najważniejszych kwestiach związanych z szybkością w eCommerce:
- Szybkość wyświetlania się treści. W tym celu wykorzystaliśmy SSR – renderowanie HTML po stronie serwera. Pomaga to w szybszym wyświetlaniu treści, co z kolei wpływa także na wyniki SEO. To podejście pomaga nam uzyskać lepsze wskaźniki w metrykach FCP. Popularne biblioteki, które pomagają na zaimplementowanie SSR to: Next.js, Nuxt.js, Gatsby.js. Obecnie do tego celu wykorzystujemy Astro.js, choć wcześniej był to Next.js.
- Szybkość ładowania strony. Wykorzystujemy cachowanie danych na poziomie serwera Graph’owego oraz serwera SSR, ponieważ bezpośrednie odwołanie do serwera jest wolniejsze niż do cache. Za orchestracje cache odpowiada głównie GraphQL z bazą w postaci Redis. Taka konfiguracja pozwala na poprawę metryki TTFB.
- Optymalizacja obrazów i grafiki. Pozwala na zmniejszenie wagi, co z kolei przekłada się na szybsze ładowanie strony. W tym celu skorzystaliśmy z kilku podejść, takich jak lazy loading czy responsive images. Dzięki temu wpływamy na metryki związane z grafiką: LCP, FID czy CLS. Wcześniej korzystaliśmy ze zmodyfikowanego komponentu Image z Next.js, jednak po zmianach został on przepisany do aktualnej biblioteki UI. Od strony back-endu korzystamy z Thumbor.
- Optymalizacja kodu. W tym obszarze zwróciliśmy uwagę na takie elementy jak: minimalizacja kodu, kompresja plików, asynchroniczna hydracja komponentów. Wszystko to ma wpływ na metryki: FCP, LCP, FID, CLS oraz wpływa także na TBT. W tym aspekcie warto wspomnieć o używanym przez nas Solid.js, Vite.js czy wspomniane wcześniej Astro.js
Rozwiązania robot friendly
Kolejnym punktem na liście zmian była kwestia widoczności treści dla robotów Google. Wpływ Server-Side Rendering (SSR) na widoczność w Google jest znaczący, ponieważ umożliwia robotom wyszukiwarek skuteczne indeksowanie treści strony. Tradycyjne metody renderowania stron, takie jak Client-Side Rendering (CSR), mogą sprawić, że treści generowane dynamicznie przez JavaScript nie są łatwo dostępne dla robotów wyszukiwarek podczas procesu indeksowania. SSR polega na generowaniu treści na serwerze przed przesłaniem ich do przeglądarki użytkownika. Dzięki temu, gdy roboty Google odwiedzają stronę, otrzymują one gotowy HTML zawierający pełną treść, co ułatwia ich zrozumienie i zindeksowanie. W efekcie strona może być lepiej widoczna w wynikach wyszukiwania, ponieważ Google może bardziej efektywnie ocenić jej zawartość i tematykę.
Dlatego też poprawne wdrożenie SSR ma pozytywny wpływ na pozycję strony w wynikach wyszukiwania, zwłaszcza jeśli chodzi o frazy kluczowe i treści generowane dynamicznie. Jest to szczególnie istotne dla eCommerce, które zawierają wiele zmieniających się treści.
Czy potrzebny jest wybór między SPA a MPA?
Często w kontekście budowy eCommerce zadawane jest pytanie: SPA czy MPA? Single Page Application (SPA) to rodzaj aplikacji internetowej, która działa w przeglądarce i interakcje z użytkownikiem odbywają się poprzez dynamiczne wczytywanie treści, bez konieczności przeładowywania całej strony. SPA zwykle korzysta z technologii JavaScript, aby asynchronicznie pobierać dane z serwera i aktualizować zawartość witryny w czasie rzeczywistym.
Z kolei Multi-Page Application (MPA) to tradycyjny rodzaj aplikacji internetowej, w której każda strona internetowa jest osobnym plikiem HTML. Nawigacja między różnymi sekcjami aplikacji wymaga przeładowania całej jej zawartości. SPA działa więc na jednej stronie, która dynamicznie zmienia się w odpowiedzi na działania użytkownika, podczas gdy MPA składa się z wielu osobnych podstron, z których każda odpowiada na określone żądanie użytkownika.
Przez ostatnie lata dominowało przekonanie, że to podejście SPA w eCommerce sprawdza się lepiej: jest mniejsze, bardziej zoptymalizowane i dzięki temu serwis ładuje się szybciej. Jednak podeszliśmy do tematu inaczej. Raccoon Storefront wykorzystuje oba podejścia. Na stronach z dużą ilością contentu, czyli na stronie głównej, listingach, karcie produktu i zakładkach informacyjnych wykorzystujemy MPA, a na stronach bardziej dynamicznych, jak koszyk czy konta klientów – SPA. To, wraz z innymi rozwiązaniami technicznymi, jak hydracje czy mikro lokalne hydracje danych, pozwoliło nam rozwiązać problem szybkości, co potwierdzają testy PageSpeed Insights.
– Stworzony przez nas Raccoon Storefront to wynik doświadczeń, które zbieramy w rozwiązywaniu wyzwań technologicznych związanych z eCommerce – twierdzi Błażej Pędzik, Senior JavaScript Developer w merce.com S.A. – Podczas pracy bardziej liczy się dla nas podejście do pisania kodu, jego uniwersalność i łatwość optymalizacji niż moda na poszczególne języki, frameworki czy wybór między SPA a MPA. Kiedyś opieraliśmy się na wspieranym przez Google Angularze, później bardziej odpowiednie dla eCommerce rozwiązania zaczął oferować rozwijany przez Facebooka React, dziś wiążemy duże nadzieje z Astro.js. Aby zapewnić najlepsze doświadczenie dla użytkownika końcowego, zawsze szukamy optymalnego rozwiązania. Wiemy, że aby to zrobić, musimy umiejętnie łączyć wiele elementów i technologii – dodaje.
Relacja między szybkością storefrontu a kosztami SEO
Badanie Hubspot’s State of Marketing Report pokazuje, że wydatki na pozycjonowanie, które ponoszone są przez firmy, stale rosną. Mniejsze podmioty wydają na te działania średnio około 2 tysięcy złotych miesięcznie. Kompleksowa obsługa większych eCommerce to koszty rzędu 20 tysięcy, jednak 13% ankietowanych specjalistów SEO deklaruje, że pracuje na miesięcznych budżetach przekraczających nawet 40 tysięcy. Dodatkowo zakłada się, że wydatki na działania związane z pozycjonowaniem i contentem wzrosną w najbliższych latach o około 15-20% RDR.
Dlatego coraz więcej marek szuka optymalizacji kosztów nie tylko pod kątem ustawień kampanii, ale także pod kątem technologii.
Wpływ technologii na SEO – case study OCHNIK
Jednym z pierwszych merchantów wdrożonych na nowej wersji Racoon Storefront był OCHNIK. W tym projekcie, realizowanym wraz z agencją SEO Altavia Kamikaze + K2, współpracującą z marką OCHNIK, zostały postawione cele związane z widocznością marki w TOP3 i TOP10, wzrostem ruchu nonbrand i poprawą wskaźników Core Web Vitals.
– Szybkość działania serwisu ma wpływ na wiele kwestii. Z jednej strony są one bardzo oczywiste, jak poprawa UX klientów, a dzięki temu mniej porzuconych koszyków i większa konwersja. Są też takie mniej oczywiste, ale jak się okazuje, równie ważne. To, że osiągamy lepsze wyniki w SEO dzięki szybkości, jest najlepszym przykładem – komentuje Dawid Szrek, Manager ds. eCommerce i projektów IT w OCHNIK.
Przeprowadzone prace pozwoliły na osiągnięcie następujących wyników w badanych okresach styczeń 2023 do styczeń 2024:
Widoczność w TOP3:
Wzrost o 151%
Widoczność w TOP10
Wzrost 126%
Wzrost ruchu nonbrand – ruch, który nie wynika bezpośrednio z wyszukiwań nazwy marki lub konkretnego produktu. Oznacza to, że użytkownicy odwiedzają stronę poprzez wyszukiwania ogólne, frazy tematyczne lub inne zapytania, które nie są powiązane z nazwą marki lub konkretnym produktem.
Wzrost o 309%
Wskaźnik FCP (First Contentful Paint) – czas od rozpoczęcia ładowania strony do wyrenderowania dowolnej części treści strony na ekranie. Krótki czas i szybsze pojawienie się treści na ekranie wpływają na doświadczenia użytkowników.
Zmniejszenie o 68%
Wskaźnik LCP (Largest Contentful Paint) - czas od rozpoczęcia ładowania strony do wyrenderowania największego bloku tekstu lub największego elementu graficznego na ekranie.
Zmniejszenie o 82%
Wskaźnik CLS (Cumulative Layout Shift) - mierzy stabilności układu serwisu. Sprawdza, jak bardzo elementy na stronie zmieniają swoje położenie podczas ładowania się strony. Zmniejszenie o 100%
Wskaźnik INP (Interaction to Next Paint) - najdłuższy czas oczekiwania na kliknięcie lub interakcję względem strony.
Zmniejszenie o 62%
Wskaźnik TTFB (Time To First Byte) - czas, jaki upływa od wysłania żądania HTTP przez przeglądarkę użytkownika do otrzymania pierwszego bajtu odpowiedzi z serwera. Jest to pierwszy krok w procesie ładowania strony internetowej i odzwierciedla szybkość, z jaką serwer jest w stanie zareagować na żądanie.
Zmniejszenie o 80%
Zmiana liczby fraz nonbrand w TOP3
Wzrost o 144
Średnia zmiana pozycji dla fraz nonbrand:
Wzrost o 12,45
– Optymalizacja wskaźników Core Web Vitals stanowi dla SEOwców nie lada wyzwanie, a coraz częściej jest koniecznością – nie tylko ze względu na fakt, że parametry te mogą wpływać na wyniki danej witryny w Google. Wskaźniki zostały stworzone dla mierzalnego i odczuwalnego pokazania w ujęciu liczbowym rzeczy mniej uchwytnych – realnych odczuć użytkowników związanych z wydajnością serwisu, wpływających na zadowolenie, czyli popularny w ostatnim czasie User Experience. Google w jasny sposób sygnalizuje, że używa CWV w swoim systemie rankingowym, dlatego utrzymanie dobrych parametrów ma wpływ na osiągnięcie sukcesu w wyszukiwarce – twierdzi Marta Bajerska, Senior Technical SEO Specialist w Altavia Kamikaze + K2.
Wynik PageSpeed Insights można sprawdzić pod linkiem: https://pagespeed.web.dev/analysis/https-ochnik-com/4873yjogvb?hl=pl&form_factor=desktop
Projekt wdrożenia dla marki OCHNIK zajął II miejsce w konkursie semKRK 2024 w kategorii Najlepsza kampania SEO oraz został nominowany do Global Search Awards w kategorii Best European SEO Campaign.
Autorem tekstu jest Marcin Rutkowski.
