{
„@context”: „https://schema.org”,
„@type”: „Article”,
„articleSection”: „Case Study”,
„name”: „PrestaShop LCP Optimization – sklep z 50 000 produktów”,
„description”: „Optymalizacja wydajności PrestaShop: LCP z 8,5s do 1,8s w 24h.”,
„publisher”: {
„@type”: „Organization”,
„name”: „HelpGuru.eu”,
„url”: „https://helpguru.eu”
},
„author”: {
„@type”: „Person”,
„name”: „Adrian Szewalski”,
„url”: „https://helpguru.eu/news/author/aszewalski/”
},
„about”: {
„@type”: „Thing”,
„name”: „PrestaShop 8.x”
},
„mainEntity”: {
„@type”: „ItemList”,
„name”: „Wyniki Case Study”,
„itemListElement”: [
{
„@type”: „ListItem”,
„position”: 1,
„name”: „Przed”,
„description”: „LCP 14,8s, Mobile 12/100, porzucenia koszyka 40%”
},
{
„@type”: „ListItem”,
„position”: 2,
„name”: „Po”,
„description”: „LCP 1,8s, Mobile 92/100, porzucenia koszyka 8%”
},
{
„@type”: „ListItem”,
„position”: 3,
„name”: „Czas realizacji”,
„description”: „24 godziny”
}
]
}
}

Zgłoszenie o 15:47 w piątek

Wiadomość wpadła tuż przed weekendem: „Sklep chodzi jak mucha w smole. Klienci skarżą się, że strony nie otwierają się wcale. Analityka pokazuje, że 40% odwiedzających porzuca koszyk zanim cokolwiek zobaczy. Jutro mam promocję na 10 000 produktów.”

Uruchomiliśmy PageSpeed Insights. Wynik Mobile: 12/100. LCP (Largest Contentful Paint): 14,8 sekundy. TTFB (Time to First Byte): 2,3s. CLS: 0,42 – wszystko w czerwonej strefie.

To był klasyczny obraz sklepu, który rósł organicznie przez kilka lat bez żadnej optymalizacji technicznej. Nikt nie usuwał starych danych. Nikt nie konfigurował cache. Hosting “na styk” obsługiwał 50 000 SKU.

Diagnoza: trzy ukryte zabójcy wydajności

1. Tabela ps_connections ważąca 14 GB

Pierwsze zapytanie diagnostyczne wyjaśniło wszystko:

SHOW TABLE STATUS WHERE Name = 'ps_connections';

Wynik: 14,2 GB danych, ponad 180 milionów wierszy – logi połączeń gości gromadzone od 2019 roku. PrestaShop wykonywał INSERT INTO ps_connections przy każdym wejściu na stronę, a przy 50 000 produktach baza dosłownie dusiła się pod własnym ciężarem.

2. Brak kompresji obrazów i WebP

Strona główna ładowała banner w rozdzielczości 3840×2160 px, 4,8 MB, bez jakiegokolwiek atrybutu loading="lazy". Przeglądarka musiała pobrać ten obraz zanim wyrenderowała cokolwiek powyżej linii zgięcia – stąd zabójczy LCP.

3. Smarty Cache bez mechanizmu invalidacji

Cache był włączony w trybie Compile always – PrestaShop kompilował szablony przy każdym żądaniu. Paradoksalnie: cache był włączony, ale nie działał. Każde wejście na stronę kategorii powodowało rekompilację 80 plików .tpl.

Akcja HelpGuru – krok po kroku

Krok 1: Oczyszczenie bazy danych (godzina 1–2)

Backup przed każdą operacją – nasz standard. Następnie:

TRUNCATE TABLE ps_connections;
TRUNCATE TABLE ps_guest;
TRUNCATE TABLE ps_statssearch;
OPTIMIZE TABLE ps_product, ps_product_lang, ps_category, ps_image;

ps_guest i ps_connections nie zawierają danych zamówień – bezpieczne do wyczyszczenia. Historia sprzedaży, klienci i zamówienia pozostały nienaruszone. Efekt natychmiastowy: TTFB z 2,3s → 0,6s.

Krok 2: Konwersja obrazów do WebP (godzina 2–6)

Masowa regeneracja miniatur z konwersją do WebP przez ImageManager::resize() PrestaShopa:

• 15 230 obrazów produktów skonwertowanych do WebP
• Banner główny skompresowany z 4,8 MB → 320 KB
• Atrybut fetchpriority="high" dodany do obrazu LCP
• Reszta obrazów: loading="lazy"

Krok 3: Naprawa konfiguracji Smarty Cache (godzina 6–8)

Zmiana trybu kompilacji na Never recompile (production). Automatyczna invalidacja przy zapisie produktu przez hook actionProductSave. Dodano OPcache (512 MB) i Memcached dla sesji.

Krok 4: Nginx FastCGI Cache (godzina 8–12)

Strony kategorii i strona główna – cache na poziomie Nginx (TTL: 1h). Koszyk i konto klienta wykluczone przez nagłówek X-Skip-Cache.

Krok 5: Monitoring (godzina 12–24)

Uptime Robot (check co 5 minut) i zadanie cron do cotygodniowego OPTIMIZE TABLE + automatyczny TRUNCATE tabel statystyk po 30 dniach.

Wyniki po 24 godzinach

• ✅ LCP: 14,8s → 1,8s (↓ 88%)
• ✅ Mobile PageSpeed Score: 12 → 92/100
• ✅ TTFB: 2,3s → 0,28s
• ✅ CLS: 0,42 → 0,04
• ✅ Porzucenia koszyka: 40% → 8%

Promocja weekendowa odbyła się bez zakłóceń. Klient szacuje, że odzyskał sprzedaż na poziomie 15–20× kosztu całej optymalizacji.

Dlaczego PrestaShop zwalnia z wiekiem

PrestaShop bez regularnej higieny bazy danych i przeglądu konfiguracji cache co 12 miesięcy – zaczyna “zbierać kurz”. Tabela ps_connections to numer jeden wróg wydajności w sklepach z historią dłuższą niż rok. Sprawdź jej rozmiar dziś – jeśli przekracza 500 MB, masz problem.

Koszt naprawy: 4 roboczogodziny. Zysk klienta z odzyskanej sprzedaży: szacunkowo 15× wartości usługi w pierwszy weekend po optymalizacji.