Kupujący z telefonem w ręku daje sklepowi kilka sekund. Jeśli w tym czasie nie zobaczy zdjęcia produktu i ceny, wraca do wyników Google i klika w następny sklep, a Google to odnotowuje, bo szybkość i stabilność strony są jednym z sygnałów, według których układa wyniki.
Wolny sklep płaci więc dwa razy - traci klienta, który już wszedł, i traci pozycję, przez którą wszedłby następny. Poniżej opisujemy sześć optymalizacji, które w naszych projektach decydują o tym, czy sklep mieści się w progach Google.
Gdzie wolny sklep traci pieniądze
Dla właściciela sklepu wolna strona rzadko wygląda jak problem. Na laptopie w biurze, na światłowodzie, sklep otwiera się natychmiast. Kupujący otwiera go na telefonie sprzed czterech lat, w tramwaju albo w galerii handlowej, na takim łączu, jakie akurat ma. Ten sam sklep potrafi tam przez kilka sekund pokazywać biały ekran.
Google mierzy to trzema wskaźnikami i publikuje progi, które strona ma spełnić. LCP (Largest Contentful Paint) to moment, w którym kupujący widzi to, po co przyszedł - zdjęcie produktu, cenę, pierwsze pozycje na listingu. Próg wynosi 2,5 sekundy. INP (Interaction to Next Paint) to opóźnienie między dotknięciem ekranu a reakcją strony, po kliknięciu w filtr, w przycisk „do koszyka" albo w strzałkę galerii. Próg wynosi 200 milisekund. CLS (Cumulative Layout Shift) to skakanie układu, czyli sytuacja, w której baner albo zdjęcie doładowuje się nad przyciskiem i przesuwa go w dół. Próg wynosi 0,1. Google ocenia stronę na podstawie danych zebranych od jej odwiedzających w Chrome, więc jeden szybki test na biurowym laptopie nie zmienia tej oceny.
Koszt widać w dwóch miejscach. W sprzedaży - kupujący, który czeka na zdjęcie, ma wciąż otwartą kartę z wynikami Google i drugi sklep w zasięgu kciuka. Im dalej w ścieżce zakupu, tym drożej. Porzucenie listingu kosztuje jedno wejście, a porzucenie koszyka kosztuje zamówienie, które prawie było. W pozycjach - przy podobnych ofertach Google wyżej ustawia sklep, który progi spełnia, więc sklep poniżej progów oddaje ruch konkurentowi, zanim ktokolwiek porówna ceny.
W hurcie ten sam problem wygląda łagodniej. Kontrahent loguje się do panelu B2B, takiego jak ten, który zbudowaliśmy dla iBox, bo ma tam swój cennik i musi złożyć zamówienie. Kupujący w sklepie B2C nie ma takiego obowiązku, a w wynikach Google czekają inne sklepy z tym samym produktem.
Trzy drogi do szybkiego sklepu - porównanie
W dniu startu prawie każdy sklep jest szybki. Różnice pojawiają się po roku, gdy w sklepie jest kilkanaście skryptów marketingowych, kilka tysięcy produktów więcej i motyw, którego nikt nie odchudzał. Porównanie jest jakościowe.
| Kryterium | Gotowy szablon w abonamencie (SaaS) z aplikacjami | Otwarty silnik sklepowy z gotowym motywem i wtyczkami | Sklep szyty na miarę na otwartych komponentach (Laravel i Lunar) |
|---|---|---|---|
| Zwrot z inwestycji (ROI), czyli kiedy szybkość zaczyna zarabiać | Niski koszt wejścia. Szybkość jest taka, jaką daje dostawca, a każda dodana aplikacja ją obniża | Niski koszt wejścia, potem koszt odchudzania. Motyw i wtyczki ładują kod pod funkcje, których sklep nie używa | Wyższy koszt wejścia. Zwrot bierze się z tego, że strona ładuje tylko to, co sprzedaje, i z pozycji, które z tego wynikają |
| Czas do startu sprzedaży (Time-to-Market) | Najkrótszy - konfiguracja i import produktów | Krótki, jeśli motyw pasuje. Praca nad progami Google zwykle zaczyna się po starcie | Dłuższy, bo front i katalog powstają pod konkretny sklep |
| Koszty bieżące (OPEX) | Abonament plus opłaty za aplikacje. Wydajność serwera poza Twoją kontrolą | Hosting plus aktualizacje motywu i wtyczek, z których każda może zepsuć wynik | Hosting i rozwój. Bez opłat licencyjnych, bo Laravel i Lunar są na licencji MIT |
| Elastyczność | W granicach edytora motywu i katalogu aplikacji dostawcy | Duża na papierze, ograniczona tym, ile wtyczek zniesie strona na telefonie | Każdy element strony i katalogu można ułożyć pod to, co kupujący ma zobaczyć najpierw |
| Uzależnienie od dostawcy (Vendor lock-in) | Dane i front u dostawcy. Zmiana platformy oznacza migrację | Kod otwarty, ale zależność od motywu i wtyczek, które rozwija ktoś inny | Kod i dane należą do Ciebie. Zmiana wykonawcy nie wymaga zmiany platformy |
Jeśli katalog liczy kilkaset produktów, a sklep sprzedaje głównie stałym klientom, gotowy szablon wystarczy i nie ma powodu płacić za więcej. Sklep na miarę ma sens wtedy, gdy o przewadze decyduje katalog liczony w tysiącach SKU od kilku dostawców i ruch z Google, który ten katalog ma przynosić. Tak wyglądają sklepy B2C dopasowane do branży, które budujemy, na Laravelu i Lunarze.
Co dzieje się między kliknięciem w Google a zamówieniem
Tak wygląda droga kupującego przez sklep, który mieści się w progach. Przy każdym kroku podajemy, który wskaźnik Google w tym miejscu mierzy:
- Kupujący wpisuje w Google „rower elektryczny miejski" i klika w wynik. Od tej chwili liczy się LCP.
- Serwer odsyła gotową stronę listingu z pierwszymi produktami, zdjęciami i cenami. Kupujący widzi je, zanim załaduje się cokolwiek innego.
- Zdjęcia poniżej pierwszego ekranu doładowują się dopiero wtedy, gdy kupujący przewija.
- Kupujący dotyka filtra „rozmiar koła". Lista odświeża się od razu, bo wartości filtra i liczby produktów są policzone z góry. Tu Google mierzy INP.
- Wchodzi na kartę produktu. Główne zdjęcie ładuje się z priorytetem, a miejsce na galerię, cenę i przycisk jest zarezerwowane, więc nic nie przesuwa się, kiedy doładowują się opinie i baner. Tu Google mierzy CLS.
- Klika „do koszyka". Koszyk odpowiada natychmiast, a skrypty marketingowe dostają zdarzenie w tle, po reakcji strony.
- Formularz zamówienia i płatność ładują tylko to, co jest potrzebne na tym kroku, bez czatu i rekomendacji.
Sześć optymalizacji, które decydują o wyniku
Kolejność wynika z tego, gdzie w sklepie B2C ładowanie trwa najdłużej i gdzie poprawa daje najwięcej przy najmniejszej ingerencji w to, co już działa.
Strona gotowa na serwerze zamiast składanej w przeglądarce
Wiele nowoczesnych frontów sklepowych wysyła do przeglądarki pustą stronę i paczkę skryptów, a telefon kupującego składa z nich listing na miejscu. Na laptopie programisty trwa to ułamek sekundy. Na średnim telefonie i sieci komórkowej trwa to sekundy, w czasie których kupujący patrzy na biały ekran, a LCP rośnie.
Strona renderowana na serwerze odwraca kolejność. Serwer wysyła gotowy listing albo kartę produktu ze zdjęciem i ceną, przeglądarka pokazuje ją od razu, a interaktywność dołącza w tle. Sklepy, które budujemy na Laravelu i Lunar PHP, działają w ten sposób. Google dostaje przy okazji gotową treść do indeksowania, zamiast czekać, aż skrypty ją wygenerują.
Druga część tej optymalizacji to czas, jakiego serwer potrzebuje na przygotowanie strony. Gotowe fragmenty listingów trzymane są w pamięci serwera i odświeżane wtedy, gdy zmienia się cena albo stan magazynowy, więc setne wejście na tę samą kategorię kosztuje tyle, co odczyt z pamięci.
Zdjęcia produktów, które ważą tyle, ile trzeba
Zdjęcia to najcięższy element strony sklepu. Z cenników dystrybutorów przychodzą pliki w rozmiarze do druku, a bez obróbki trafiają na stronę w takiej postaci, jaką przysłał dostawca. Kupujący na telefonie pobiera wtedy wielokrotnie więcej danych, niż jego ekran jest w stanie pokazać.
Poprawnie skonfigurowany sklep przygotowuje z każdego zdjęcia kilka rozmiarów, wysyła ten, który pasuje do ekranu, i zapisuje je w nowoczesnym formacie (WebP albo AVIF). Główne zdjęcie na karcie produktu ładuje się z priorytetem, przed wszystkim innym, bo to ono zwykle decyduje o LCP. Galeria i zdjęcia na dalszych pozycjach listingu doładowują się dopiero przy przewijaniu.
Przy katalogu liczonym w tysiącach SKU ta obróbka musi dziać się automatycznie w chwili importu z cennika dostawcy. Nikt w zespole nie zmniejszy ręcznie kilkunastu tysięcy zdjęć, a wystarczy jedna partia nowych produktów w oryginalnym rozmiarze, żeby wynik LCP dla całej kategorii spadł poniżej progu.
Budżet na skrypty zewnętrzne
Tagi reklamowe, piksel retargetingu, czat, widget opinii, narzędzie do testów A/B, mapa cieplna, menedżer zgód. Każdy z nich to kilka linijek do wklejenia i każdy wykonuje się na telefonie kupującego. Osobno żaden nie jest problemem. Razem sprawiają, że po dotknięciu przycisku „do koszyka" telefon jest zajęty kilkunastoma innymi rzeczami, a INP przekracza próg.
Optymalizacja polega na dwóch decyzjach. Skrypty, które nie są potrzebne do pokazania produktu, ładują się po pierwszej interakcji albo w czasie, gdy przeglądarka nie ma nic innego do roboty. Skrypty, których nikt w firmie nie umie przypisać do konkretnego celu, znikają - tag po kampanii sprzed dwóch lat wciąż wykonuje się przy każdym wejściu.
Ta decyzja należy do zarządu, bo skrypt do sklepu dodaje zwykle dział marketingu, a skutek widzi dział sprzedaży w wyniku konwersji na telefonie. Przydaje się prosta zasada - każdy nowy skrypt przechodzi przez sprawdzenie, co zrobił z czasem reakcji strony, zanim zostanie na stałe.
Układ, który nie skacze
Skakanie układu ma kilka źródeł. Zdjęcie bez zarezerwowanych wymiarów, pod które strona robi miejsce dopiero po jego pobraniu. Pasek zgody na cookies, który wsuwa się od góry i spycha wszystko w dół. Czcionka, która podmienia się z systemowej na firmową i zmienia szerokość nagłówka. Baner promocyjny wstrzykiwany przez narzędzie marketingowe nad listingiem.
Dla kupującego skutek jest jeden. Celuje w „do koszyka", układ się przesuwa i trafia w „porównaj" albo w reklamę. Dla Google skutkiem jest wartość CLS powyżej 0,1 na adresach, które mają sprzedawać.
Poprawka polega na tym, że każdy element strony ma miejsce zarezerwowane, zanim się załaduje. Zdjęcia mają zapisane wymiary, pasek zgody nakłada się na treść zamiast ją przesuwać, czcionka firmowa ma zapasową o tej samej szerokości, a banery mają stały slot o znanej wysokości.
Katalog, który nie spowalnia listingu
W sklepie z dużym katalogiem listing z filtrami jest najdroższą stroną do przygotowania. Każdy filtr z liczbą produktów przy wartości oznacza policzenie tysięcy pozycji według atrybutu. Jeśli atrybuty są niespójne, bo każdy z dostawców inaczej zapisuje rozmiar koła albo pojemność akumulatora, sklep liczy je w locie przy każdym dotknięciu filtra i pokazuje wartości, za którymi nie stoi żaden produkt.
Rozwiązanie zaczyna się w katalogu. Atrybuty są sprowadzane do jednego standardu w chwili importu, wartości filtrów pochodzą wprost z atrybutów, a liczby produktów są policzone z góry i odświeżane przy zmianie stanu. Kategorie schodzą do poziomu, na którym listing ma rozsądną długość, więc strona pokazuje pierwszą stronę wyników zamiast całej kategorii. Dotknięcie filtra kończy się wtedy odpowiedzią od razu, a LCP listingu jest niezależne od tego, ile produktów jest w katalogu.
Tę samą pracę nad danymi opisujemy przy wdrożeniu platformy B2B, bo w hurcie problem z katalogiem wygląda identycznie.
Pomiar u kupujących i próg w kryteriach odbioru
Test szybkości w narzędziu laboratoryjnym mierzy jedno wejście na jednym urządzeniu w jednych warunkach. Google ocenia stronę na danych zebranych od odwiedzających w Chrome i w Search Console pokazuje bezpłatnie, które adresy sklepu są dobre, które wymagają poprawy, a które są słabe. O pozycjach mówi ten raport. Wynik testu laboratoryjnego jest wskazówką dla programisty.
Jeśli nikt tego raportu nie ogląda regularnie, spadek wyniku po wdrożeniu nowego motywu albo wtyczki wychodzi na jaw po kwartale, razem ze spadkiem ruchu. Optymalizacja polega tu na procesie. Progi Google są zapisane jako warunek odbioru w umowie z wykonawcą i jako warunek publikacji każdej zmiany na stronie. Po każdym wdrożeniu ktoś sprawdza raport i porównuje go z poprzednim tygodniem. Wynik Core Web Vitals trafia do comiesięcznego przeglądu obok konwersji na telefonie, bo te dwie liczby poruszają się razem.
Sklep rowerowy Trippi na Lunar PHP
Wyzwanie. Trippi sprzedaje rowery, e-bike i akcesoria z katalogu czterech dystrybutorów, z których każdy inaczej opisuje ten sam sprzęt. Razem to ponad 22 000 pozycji w czterech cennikach i czterech formatach. Przed projektem kategorie odwzorowywały cenniki dystrybutorów, a filtry były jednym zestawem na cały sklep. Do produktu prowadziła wyszukiwarka i nazwa w brzmieniu z cennika. Podpięcie nowego dostawcy zajmowało 2-3 tygodnie pracy programisty.
Wdrożone rozwiązanie. Sklep zbudowany na Lunar PHP i Laravelu, z Idosell i Tpay w tle. Cztery cenniki sprowadziliśmy do jednego drzewa kategorii i wspólnego zestawu atrybutów już w chwili importu, a z 22 000 pozycji wybraliśmy według reguł per dostawca, marka i kategoria 12 000 SKU, które Trippi chce sprzedawać. Filtry są przypisane do kategorii, ich wartości pochodzą wprost z atrybutów, a przy każdej wartości widać liczbę produktów. Listing kategorii „Elektryczne" to 1368 produktów rozbitych na podkategorie, które odpowiadają temu, jak kupujący nazywa rower, którego szuka. Dla szybkości oznacza to, że listing nie liczy niczego w locie, a kupujący na telefonie dostaje podkategorię o rozsądnej długości zamiast całej kategorii naraz.
Wyniki. Katalog 12 000 SKU stał się przeszukiwalny przez kategorie i filtry zamiast wyłącznie przez wyszukiwarkę. Podpięcie nowego dostawcy skróciło się z 2-3 tygodni do 2-3 dni. Sklep stoi na otwartym Lunar PHP na własnym serwerze, bez kosztu licencji, więc decyzję o mocniejszym hostingu albo pamięci podręcznej podejmuje Trippi. Pełny opis znajdziesz w realizacji dla Trippi.
Checklista dla zarządu przed rozmową o szybkości
Każde z tych pytań da się sprawdzić w jeden dzień bez udziału programisty:
- Otwórz swój sklep na telefonie, na sieci komórkowej, w oknie prywatnym. Ile sekund mija, zanim zobaczysz zdjęcie i cenę pierwszego produktu?
- Czy raport Core Web Vitals w Search Console pokazuje adresy Twojego sklepu jako dobre, i kto go oglądał w ostatnim miesiącu?
- Ile skryptów zewnętrznych ładuje karta produktu i kto w firmie potrafi powiedzieć, po co jest każdy z nich?
- Kto może dodać nowy skrypt marketingowy do sklepu i czy ktoś sprawdza potem, co zrobił z czasem reakcji strony?
- Czy zdjęcia z cenników dostawców są zmniejszane automatycznie przy imporcie, czy trafiają na stronę w oryginalnym rozmiarze?
- Ile trwa odświeżenie listingu po dotknięciu filtra w największej kategorii sklepu?
- Czy w umowie z wykonawcą albo w procesie publikacji zmian jest zapisany próg szybkości jako warunek odbioru?
- Jaki udział zamówień pochodzi z telefonów i czy konwersję na telefonie ktoś porównuje z konwersją na komputerze?
Porozmawiajmy o szybkości Twojego sklepu
Jeśli chcesz wiedzieć, jak te sześć optymalizacji przełożyłoby się na Twój sklep, napisz do nas albo umów rozmowę. Zajrzymy z Tobą do raportu Core Web Vitals w Search Console, powiemy, co ciągnie wynik w dół, i ocenimy, czy da się to poprawić na obecnej platformie, czy przewaga wymaga frontu i katalogu zbudowanych pod Twoją branżę. Jeśli obok sklepu prowadzisz sprzedaż hurtową, obejrzymy przy okazji, jak ten sam katalog zasiliłby platformę zakupową B2B bez utrzymywania danych w dwóch miejscach.
O autorze