Wstęp
„Mamy nowy design, ale ruch i tak spada” – to zdanie słyszę od właścicieli sklepów internetowych coraz częściej. Inwestują w lepsze zdjęcia, szybszy hosting, a strona i tak ładuje się jak za czasów dial-up. Najczęściej winowajcą jest źle skonfigurowane cache’owanie. W tym artykule pokażę trzy najczęstsze błędy, które sam widziałem u klientów, i jak je naprawić.
1. Cache całej strony – szybko, ale kosztem personalizacji
Zaczyna się niewinnie: „Włączmy full-page cache, przecież strony się szybciej ładują”. I faktycznie – dla niezalogowanego użytkownika to działa pięknie. Ale gdy wchodzi klient z koszykiem lub zalogowany, zaczynają się problemy. Widok „Witaj, Janie” z cudzym imieniem, nieaktualna liczba produktów w koszyku – to wróg konwersji.
Przykład: Klient z branży odzieżowej wdrożył Varnish z cache’em całej strony. Ruch wzrósł, ale współczynnik konwersji spadł o 12%. Okazało się, że zalogowani użytkownicy widzieli cudze rekomendacje. Fix? Użycie ESI (Edge Side Includes) do dynamicznych fragmentów. Koszt implementacji: około 8 godzin pracy backend developera.
Lekcja: Nie cache’uj całej strony dla zalogowanych. Segmentuj cache na podstawie stanu użytkownika i dynamicznych elementów.
2. Zbyt długie TTL – świeżość danych ma znaczenie
„Ustawmy cache na 24 godziny, po co odświeżać co chwilę?” – myślał właściciel sklepu z elektroniką. Efekt? Klienci widzieli nieaktualne ceny promocyjne, a po kliknięciu w produkt okazywało się, że jest już niedostępny. Współczynnik odrzuceń wzrósł o 18%.
Dane: Badania pokazują, że 40% użytkowników opuszcza stronę, jeśli widzi nieaktualne informacje o stanie magazynowym. Dla sklepu z dużą rotacją to katastrofa.
Rozwiązanie: Użyj dynamicznego TTL w zależności od typu treści. Strony produktów – 10-15 minut, strony kategorii – 30 minut, blog – 1 godzina. Dodatkowo wdróż webhooki do inwalidacji cache przy zmianie stanu magazynowego.
Fix: Implementacja w Node.js z Redisem i niestandardową logiką TTL. Zajęło to 2 dni, ale konwersja wróciła do normy.
3. Brak cache’owania API – backend dusi się od requestów
Standardowy scenariusz: frontend pobiera dane z REST API przy każdym odświeżeniu strony. Nawet jeśli masz cache na warstwie CDN, backend API może być przeciążony. W jednym z projektów (sklep z częściami samochodowymi) każde zapytanie o wyszukiwarkę generowało 200 ms odpowiedzi. Przy 500 użytkownikach jednocześnie czas rósł do 5 sekund.
Dlaczego to problem? Wolne API to wolna strona, a to uderza w SEO – Google od dawna bierze pod uwagę Core Web Vitals. Dla e-commerce każda dodatkowa sekunda to spadek konwersji o 7%.
Rozwiązanie: Wdróż cache odpowiedzi API na poziomie Redis lub Memcached. Kluczuj po parametrach zapytania i nagłówkach. Dla często używanych endpointów (np. lista kategorii) ustaw cache na 5 minut. Dla wyszukiwarki – cache na 1 minutę, ale z możliwością szybkiej inwalidacji.
Wynik: Po optymalizacji średni czas odpowiedzi API spadł z 200 ms do 10 ms. Całkowity czas ładowania strony skrócił się z 4,2 s do 1,8 s. Ruch organiczny po 3 miesiącach wzrósł o 23%.
Podsumowanie
Cache’owanie to potężne narzędzie, ale źle skonfigurowane potrafi zniszczyć zarówno UX, jak i konwersję. Klucz to segmentacja, dynamiczne TTL i cache’owanie API. Jeśli Twój sklep działa wolno, zacznij od audytu cache – często to najtańsza optymalizacja, która przynosi największe efekty.
Masz problem z wydajnością swojego e-commerce? JurskiTech specjalizuje się w optymalizacji szybkości i UX. Sprawdź nasze usługi.
