Optymalizacja PrestaShop - jak przyspieszyć sklep i poprawić konwersję

Krok 1Hosting i serwer - oddziel czas aplikacji od czasu sieci

Hosting, konfiguracja PHP, baza danych, kod aplikacji, cache i odległość sieciowa wspólnie wpływają na TTFB. Sam wysoki wynik nie wskazuje przyczyny - trzeba rozdzielić czas połączenia, kolejki, PHP i zapytań SQL oraz porównać pomiar z cache i bez niego.

Nie ma jednego minimalnego rozmiaru serwera dla każdego sklepu. Dobierz CPU, RAM, storage i liczbę procesów na podstawie wersji PrestaShop, katalogu, ruchu, integracji i pomiarów pod obciążeniem. Zmianę hostingu uzasadnij profilem aplikacji albo testem porównawczym tej samej kopii sklepu.

Lista kontrolna konfiguracji serwera:

• Wersja PHP zgodna z dokładną wersją PrestaShop i modułami oraz nadal wspierana przez wydawcę PHP - potwierdź w aktualnej macierzy zgodności przed zmianą.
• Wspierana wersja MySQL albo MariaDB oraz InnoDB; buffer pool dobierz do roboczego zestawu danych i dostępnej pamięci na podstawie metryk, nie liczby produktów.
• OPcache skonfigurowany i zweryfikowany pomiarem hit rate, pamięci oraz zachowania po wdrożeniu nowej wersji kodu.
• Współczesny protokół HTTP dostępny w użytym środowisku; wersję i wpływ sprawdź w nagłówkach oraz waterfallu.
• Storage z opóźnieniem i przepustowością adekwatnymi do bazy, logów i cache; decyzję oprzyj na metrykach I/O.
• Lokalizacja infrastruktury dobrana do odbiorców oraz zależności; mierz opóźnienie z reprezentatywnych regionów.
• Gzip lub Brotli kompresja odpowiedzi HTTP - HTML, CSS, JS powinny być kompresowane.

Krok 2Konfiguracja PHP - OPcache, limity i rozszerzenia

Konfiguracja PHP może wpływać na czas generowania odpowiedzi. OPcache przechowuje skompilowany bytecode w pamięci, dlatego sprawdź, czy jest aktywny i czy jego pamięć oraz polityka odświeżania odpowiadają sposobowi wdrażania aplikacji.

Nie kopiuj uniwersalnego php.ini. Zapisz konfigurację używaną przez proces webowy oraz osobno przez CLI/cron. Parametry dobieraj po pomiarze i testuj na kopii:

• memory_limit i liczbę procesów PHP dobierz razem do szczytowego zużycia pamięci, limitów hostingu i równoległych żądań. Podniesienie limitu nie usuwa wycieku pamięci ani kosztownego importu.
• Czas żądania webowego i czas importu/cron mają różne budżety. Długie zadania dziel na partie z możliwością wznowienia, zamiast maskować problem globalnym zwiększeniem max_execution_time.
• Potwierdź aktywność OPcache w środowisku obsługującym HTTP; ustawienia CLI mogą być inne. Odczyty diagnostyczne udostępniaj tylko uprawnionemu administratorowi.
• Pamięć OPcache i pojemność na skrypty dobierz z jego statystyk: zajętości, liczby zapisanych kluczy, restartów i trafień cache. Po zmianie porównaj pamięć oraz rozkład TTFB.
• Przy opcache.validate_timestamps=1 zmiany plików są sprawdzane zgodnie z opcache.revalidate_freq. Wariant validate_timestamps=0 wymaga skutecznej inwalidacji lub restartu właściwego procesu webowego przy każdym deployu, aktualizacji modułu i rollbacku; bez takiej procedury nie wyłączaj sprawdzania plików.
• opcache.revalidate_freq jest ignorowane, kiedy validate_timestamps jest wyłączone. Test wydania powinien potwierdzić, że HTTP wykonuje nową wersję kodu, a rollback przywraca poprzednią.
• JIT traktuj jako osobny eksperyment dla konkretnej wersji PHP i obciążenia. Nie włączaj go automatycznie jako ustawienia PrestaShop; porównaj czas CPU, pamięć, stabilność i wydajność z wariantem bazowym.
• Cache ścieżek plików oceniaj razem z profilem operacji plikowych i sposobem publikacji kodu. Nie zmieniaj kilku warstw cache równocześnie, bo utrudnia to przypisanie efektu.

Krok 3Audyt modułów - mierz koszt każdego dodatku

Moduły mogą dodawać zapytania SQL, zasoby CSS i JavaScript, hooki oraz zużycie pamięci PHP. Nie zakładaj wpływu na podstawie samej liczby dodatków - zmierz konkretne żądania, hooki i zasoby.

W rozwijanym przez lata sklepie lista modułów może urosnąć bez kontroli. Dlatego robimy inwentaryzację: cel modułu, status wsparcia, wykorzystanie, wpływ na wydajność i zależności. Liczba sama nie przesądza o problemie, ale dublowanie funkcji i nieużywany kod zwiększają powierzchnię ryzyka.

Jak przeprowadzić audit modułów:

• Na środowisku testowym użyj profilera zgodnego z zainstalowaną wersją i sprawdź liczbę, łączny czas oraz powtarzalność zapytań SQL dla strony głównej, kategorii i produktu. Nie ma uniwersalnego progu liczby zapytań - szukaj regresji, duplikatów i zapytań dominujących w czasie odpowiedzi.
• Przejrzyj listę modułów: potrzebne, kandydaci do wyłączenia i nieaktywne. Przed odinstalowaniem sprawdź zależności oraz procedurę producenta - może usuwać konfigurację lub dane. Najpierw wykonaj test kopii i potwierdź możliwość przywrócenia.
• Dla każdego modułu JavaScript sprawdź: czy skrypt ładuje się na każdej stronie (globalnie) czy tylko tam gdzie jest potrzebny? Moduł live chat, Google Analytics, popupy - czy są odroczane czy blokują render?
• Używaj Network Throttling w DevTools i sprawdzaj Waterfall - które zewnętrzne skrypty i piksele śledzące blokują interaktywność strony.
• Dla modułów statystyk ustal, które dane zapisują i kto z nich korzysta. GA/GTM nie jest kopią danych sklepu: może mieć inną próbę i zakres. Wyłączenie zbierania i retencję rozpatruj osobno; nie kasuj tabel tylko dlatego, że działa zewnętrzna analityka.
• Dla sliderów i innych rozbudowanych komponentów zmierz transfer JavaScript, CSS i obrazów oraz koszt pracy głównego wątku. Ładuj tylko zasoby potrzebne na danej stronie i porównaj wariant z komponentem oraz bez niego.

Krok 4System cache PrestaShop - Smarty, FS Cache i zewnętrzne backend'y

PrestaShop ma kilka warstw cache wbudowanego. Zrozumienie ich różnic jest kluczowe - włączenie złego cache może nie pomóc wcale albo spowodować błędy wyświetlania nieaktualnych danych.

Cache szablonów Smarty i politykę rekompilacji dobierz do sposobu wdrażania kodu. Ustawienie produkcyjne zweryfikuj dla dokładnej wersji sklepu, a po deploymencie sprawdź poprawne odświeżenie skompilowanych szablonów.

Opcje łączenia, kompresji i cache zasobów w panelu włączaj pojedynczo na stagingu. Po każdej zmianie przetestuj wygląd, JavaScript i checkout, ponieważ zgodność zależy od motywu oraz modułów.

Zewnętrzne backend'y cache dla PrestaShop:

• Backend cache w pamięci, na przykład Redis lub Memcached, dobierz do wspieranego adaptera, sposobu inwalidacji i infrastruktury. Porównaj hit rate, pamięć i czas odpowiedzi przed zmianą oraz po niej.
• Pełny cache HTML można realizować na warstwie serwera lub reverse proxy, jeśli architektura to wspiera. Nie kopiuj konfiguracji przeznaczonej dla innego CMS-a; określ osobno reguły dla stron publicznych, sesji, walut, grup klientów, koszyka i checkoutu.
• Varnish, FastCGI cache i funkcje cache wybranych CDN-ów wymagają jawnych reguł omijania oraz inwalidacji. Przetestuj scenariusze zalogowane i niezalogowane, różne ceny, koszyk oraz zmianę produktu.
• Zaprojektuj inwalidację po zmianie produktów, cen i promocji oraz test wykrywający nieaktualną odpowiedź.

Krok 5Optymalizacja obrazów - WebP, lazy loading i prawidłowe rozmiary

Obrazy bywają istotną częścią transferu na stronach produktu i kategorii. W waterfallu porównaj rozmiar źródła z wymiarem renderowanym, format, kompresję i moment pobrania; wpływ na LCP potwierdź pomiarem dla konkretnego elementu.

Sprawdź typy obrazów i rozmiary miniaturek skonfigurowane w używanej wersji PrestaShop. Powiąż je z kontekstem: lista produktów, karta produktu, koszyk i wyszukiwarka. Zanim usuniesz rozmiar, potwierdź, czy nie korzysta z niego moduł lub inny wariant motywu.

Konwersja do WebP i AVIF:

• Obsługę WebP i AVIF potwierdź dla dokładnej wersji PrestaShop, biblioteki obrazów, motywu oraz modułów. Samo wygenerowanie pliku nie zmienia adresów obrazów w szablonie.
• Gdy potrzebny jest moduł lub konwersja poza aplikacją, najpierw przygotuj próbkę z kopii plików. Sprawdź adresy miniaturek, regenerację, źródła w szablonie, fallback oraz cache. Zachowaj oryginały i plan wycofania.
• Porównaj WebP, AVIF i używany format przy podobnej jakości wizualnej: rozmiar, czas kodowania, przezroczystość i kolory. Obsługę enkodera potwierdź w zainstalowanej bibliotece; nie wywodź jej z samego numeru Imagick.
• Lazy loading stosuj dla obrazów poza początkowym widokiem. Nie dodawaj go do potwierdzonego obrazu LCP ani innych obrazów potrzebnych od razu; po zmianie sprawdź również szybkie przewijanie kategorii.
• Atrybut fetchpriority=high rozważ dla potwierdzonego obrazu LCP. To wskazówka dla przeglądarki, nie gwarancja czasu pobrania. Nie oznaczaj w ten sposób wszystkich miniaturek.
• Sprawdź metadane zdjęć, zwłaszcza lokalizację GPS. Usuwaj niepotrzebne dane świadomie; przed odrzuceniem profilu kolorów wykonaj prawidłową konwersję i kontrolę wizualną produktu. Nie nadpisuj jedynej kopii oryginału.
• Sprawdź rzeczywisty srcset i sizes w motywie dla produktu, kategorii i banerów. Jeśli brakuje dopasowania do szerokości ekranu, dodaj je przy użyciu istniejących wariantów obrazów i przetestuj wybór źródła w różnych viewportach.

Krok 6Optymalizacja bazy danych MySQL/MariaDB

Zacznij od rozmiarów tabel, tempa przyrostu, czasu zapytań, blokad i wykorzystania pamięci. Sama liczba rekordów nie dowodzi problemu wydajnościowego. Nazwy i relacje tabel zależą od wersji, prefiksu oraz modułów; logi mogą być potrzebne do diagnozy, raportowania lub rozliczeń.

Plan prac przy bazie danych powinien obejmować:

• Spójny backup oraz próbę odtworzenia na kopii, z ustalonym oknem prac i odpowiedzialnością za rollback. Sam komunikat o wykonaniu kopii nie potwierdza możliwości przywrócenia sklepu.
• Mapę danych: właściciel tabeli, zależności, okres retencji i użycie przez raporty, moduły oraz integracje. Najpierw wylicz kandydatów do archiwizacji bez usuwania i zatwierdź zakres.
• Dla koszyków sprawdź powiązania z zamówieniami, pozycjami, regułami i modułami. Sam wiek rekordu nie oznacza porzuconego koszyka. Nie wykonuj bezpośredniego DELETE z tabeli koszyków na podstawie daty.
• Usuwanie lub archiwizację realizuj mechanizmem zgodnym z aplikacją i zależnościami, najpierw na kopii. Sprawdź raporty, historię zamówień, integracje i checkout po operacji; dopiero potem zaplanuj kontrolowane partie na produkcji.
• OPTIMIZE TABLE nie jest rutynową receptą dla największych tabel. Dla konkretnego silnika i wersji sprawdź korzyść, miejsce robocze, czas oraz możliwe blokady; przetestuj operację na kopii. Odbudowa tabeli może obciążyć I/O i wymagać okna serwisowego.
• Slow query log zbieraj w uzgodnionym oknie, z progiem dobranym do obciążenia i ograniczeniem rozmiaru. Chroń jego zawartość, bo zapytania mogą zawierać dane klientów. Grupuj zapytania według łącznego czasu, częstotliwości i blokad.

Krok 7Minifikacja i łączenie CSS/JS - CCC i zaawansowane techniki

Opcje CCC oceniaj osobno. Minifikacja, łączenie i cache rozwiązują różne problemy; łączenie może też zwiększyć ilość nieużywanego kodu w danym widoku. Zapisz wariant bazowy i porównaj transfer, waterfall oraz pracę głównego wątku po każdej zmianie.

Zachowaj ostrożność przy JS - niektóre moduły mają skrypty z błędami po minifikacji lub zakładają określoną kolejność ładowania. Testuj na środowisku staging.

Co zrobić gdy CCC nie wystarcza:

• Defer i async nie są zamienne. Dla klasycznych skryptów defer zachowuje kolejność odroczonych skryptów, async wykonuje je po pobraniu. Użyj mechanizmu rejestracji zasobów właściwego dla wersji i zachowaj zależności, inicjalizację zgód oraz kontrakt integracji analitycznej.
• Preload rozważ dla późno odkrywanego zasobu krytycznego. Musi wskazywać rzeczywisty URL, poprawny typ as i tryb CORS. Nie preloaduj wszystkiego: konkurencja o transfer i podwójne pobrania mogą pogorszyć wynik.
• Preconnect rozważ tylko dla niezbędnego, wcześnie używanego zewnętrznego originu. Może wcześniej wykonać część pracy połączenia, ale nie gwarantuje jego ponownego wykorzystania. Sprawdź również zgodność z przyjętym modelem zgód.
• Dns-prefetch przygotowuje rozpoznanie nazwy, a nie pełne połączenie. To opcjonalna wskazówka, nie obowiązkowy dodatek dla każdej domeny; efekt potwierdź w pomiarze.
• Critical CSS musi pokrywać rzeczywiście widoczne stany i szerokości ekranu. Sam <link rel="preload" as="style"> tylko pobiera plik - nie stosuje jego reguł. Pozostały arkusz musi zostać dołączony jako stylesheet. Jeśli wdrażasz ładowanie asynchroniczne, potrzebujesz sprawdzonego mechanizmu aktywacji, fallbacku bez JavaScript oraz zgodności z CSP; przetestuj brak migotania i przesunięć układu.
• Coverage pomaga znaleźć kandydatów do redukcji CSS, lecz pojedynczy przebieg nie obejmuje otwartego menu, walidacji, wariantów produktu i innych stanów. Przy PurgeCSS zachowaj dynamiczne selektory i przetestuj pełne ścieżki, zanim usuniesz reguły.

Krok 8CDN - Content Delivery Network dla sklepu PrestaShop

CDN może serwować statyczne zasoby z punktów położonych bliżej użytkownika. Potencjalny wpływ zależy od lokalizacji odbiorców, cache hit ratio, rozmiaru zasobów i czasu serwera źródłowego, dlatego porównaj te same URL-e z reprezentatywnych regionów.

Przykładowe warianty do oceny według aktualnych funkcji i cenników dostawców:

• Usługa proxy/CDN, na przykład Cloudflare: sprawdź w bieżącej dokumentacji wybranego planu obsługiwane protokoły, kompresję, minifikację, ochronę i reguły cache; każdą funkcję włączaj osobno i testuj.
• Dla zasobów statycznych z haszem w URL można rozważyć dłuższy TTL, ale koszyk, checkout, konto, ceny zależne od klienta i odpowiedzi z sesją wymagają jawnych wykluczeń.
• CDN typu pull, na przykład Bunny CDN lub KeyCDN: sprawdź integrację z używaną wersją PrestaShop, sposób unieważniania oraz łączny koszt transferu i żądań.
• CloudFront może pasować do infrastruktury opartej o AWS; decyzję oprzyj na istniejącej architekturze, kompetencjach operacyjnych i kosztach.
• Usługi transformacji obrazów, na przykład ImageKit lub Cloudinary, mogą generować formaty i rozmiary na żądanie. Zweryfikuj cache key, jakość, limity, koszty i zachowanie fallbacków.

Krok 9Optymalizacja szablonu i frontendu

Motyw może wpływać na liczbę zasobów, rozmiar DOM i pracę głównego wątku. Zamiast oceniać go po nazwie lub kategorii, zmierz wykorzystywane komponenty - slidery, mega menu, funkcje AJAX i animacje - na reprezentatywnych widokach.

Audyt szablonu - od czego zacząć:

• Sprawdź liczbę faktycznie pobieranych plików fontów, ich warianty i transfer. Usuń niewykorzystywane warianty, ustaw świadomą strategię font-display i porównaj efekt wizualny oraz metryki.
• Sprawdź klasyczne skrypty w <head>, które blokują parser, oraz ich zależności. Moduły JavaScript mają inne zasady ładowania. Odroczenie wybieraj po analizie inicjalizacji i testach formularzy, menu, produktu oraz checkoutu - samo przeniesienie tagu nie dowodzi poprawy LCP.
• Dla mega menu zmierz osobno CSS, JavaScript, DOM oraz koszt interakcji. Jeśli prostszy wariant spełnia wymagania nawigacji, porównaj oba rozwiązania w tych samych warunkach.
• Dla animacji zmierz pracę JavaScript, stylowanie, layout i kompozycję. Nie każda animacja wymaga biblioteki JS; prostszy efekt CSS może wystarczyć. Uwzględnij prefers-reduced-motion i usuń efekty, które utrudniają użycie sklepu lub nie uzasadniają kosztu.
• Czcionki zewnętrzne: self-hosting może usunąć żądanie przeglądarki do dostawcy fontu i ułatwić kontrolę wydajności. Nie oznacza automatycznie pełnej zgodności z RODO/GDPR - licencję, podstawę przetwarzania i pozostałe transfery danych ocenia klient lub jego doradca.
• Powtarzalne style inline mogą zwiększać HTML, ale sam atrybut style nie wyłącza cache odpowiedzi. Rozważ współdzielone klasy lub zmienne CSS, jeśli redukują powtórzenia bez utraty dynamicznych wariantów produktu.
• Rozmiar i głębokość DOM traktuj jako sygnał diagnostyczny, nie samodzielny próg zaliczenia. Użyj narzędzi wydajnościowych, aby wskazać koszt stylowania, layoutu i interakcji, a potem usuń niepotrzebne węzły w konkretnym widoku.

Krok 10Core Web Vitals - LCP, INP i CLS w praktyce PrestaShop

Core Web Vitals opisują ładowanie, responsywność i stabilność wizualną. Dane terenowe i pomiary laboratoryjne odpowiadają na różne pytania: trend użytkowników śledź w dostępnych danych terenowych, a kontrolowane porównania zmian wykonuj w tych samych warunkach laboratoryjnych.

LCP (Largest Contentful Paint) - główny kandydat do optymalizacji:

• Zidentyfikuj element LCP na każdym strategicznie ważnym typie strony w narzędziu diagnostycznym; nie zakładaj z góry, że będzie to ten sam element na produkcie, kategorii i stronie głównej.
• Dla potwierdzonego obrazu LCP usuń lazy loading i zapewnij wczesne odkrycie źródła. Rozważ fetchpriority=high, właściwe rozmiary i kompresję. Konkretny format, CDN ani silnik cache nie są warunkiem zaliczenia LCP - porównaj cały czas ładowania i renderowania.
• Jeśli LCP to tekst, sprawdź moment pobrania fontu i strategię font-display. Preloaduj tylko rzeczywiście potrzebny font z poprawnym crossorigin. Fallback dobierz również pod stabilność układu; swap nie gwarantuje braku CLS.
• TTFB wyznacza najwcześniejszy moment, w którym przeglądarka może zacząć przetwarzać HTML. Jego udział w LCP oceń razem z odkryciem zasobu, transferem i renderowaniem, zamiast przypisywać wynik wyłącznie serwerowi.

Krok 11TTFB - Time to First Byte i generowanie HTML po stronie serwera

Dla nawigacji TTFB (Time to First Byte) opisuje czas do pierwszego bajtu dokumentu. Odczyt może obejmować przekierowania, połączenie sieciowe i oczekiwanie na odpowiedź; sam etap Waiting w waterfallu nie jest pełnym budżetem nawigacji. W sklepie bez pełnego cache HTML częścią tego czasu może być PHP i baza, ale udział każdej warstwy trzeba zmierzyć.

Jak analizować TTFB:

• W DevTools lub innym narzędziu rozdziel fazy żądania głównego dokumentu i zapisz rozkład wyników z kilku powtórzeń. Próg diagnostyczny ustal jako SLO dla konkretnej ścieżki, regionu i warunków cache.
• Przetestuj osobno użytkownika zalogowanego i niezalogowanego, ponieważ sesja i personalizacja mogą zmieniać reguły cache; potwierdź rzeczywiste nagłówki oraz hit/miss.
• Porównaj wariant z cache i bez niego przy użyciu udokumentowanego mechanizmu obejścia w danej warstwie albo na kontrolowanym środowisku. Parametr ?nocache=1 nie jest uniwersalnym kontraktem PrestaShop ani każdego proxy.
• Przetestuj kilka lokalizacji. Różnica może wynikać z sieci, routingu, punktu CDN, cache i obciążenia, dlatego analizuj waterfall oraz nagłówki, nie tylko jedną liczbę.
• Jeśli metryki bazy wskazują problem, zbierz slow query log w reprezentatywnym okresie i powiąż zapytania z trasami. Oceniaj łączny czas, częstotliwość i blokady.
• Jeśli środowisko używa PHP-FPM, sprawdź kolejkę, zajętość procesów i zużycie pamięci. Osiągnięcie pm.max_children może powodować oczekiwanie, lecz podniesienie limitu bez zapasu pamięci i CPU może pogorszyć stabilność. Skok TTFB sam nie rozstrzyga przyczyny.
• Gdy czas generowania aplikacji dominuje w profilu, użyj zgodnego profilera PHP, na przykład Blackfire lub Tideways. Profil może wskazać kosztowne funkcje i zapytania, ale wynik interpretuj razem z próbką ruchu, cache i bazą.

Krok 12Monitoring i pomiary po wdrożeniu

Optymalizacja bez monitoringu to akcja jednorazowa. Po wdrożeniu zmian ustaw system który będzie alertować gdy wydajność spadnie - nowa wersja modułu, aktualizacja PrestaShop, flash sprzedaż z dużym ruchem, czy po prostu rosnący katalog produktów mogą cofnąć postępy.

Zestaw narzędzi monitoringu:

• Search Console → Core Web Vitals: zapisuj cykliczne odczyty i zmiany grup adresów, jeśli dla witryny są dostępne dane terenowe.
• PageSpeed Insights API może wspierać powtarzalne pomiary kluczowych URL-i; sprawdź aktualne limity i rozdziel dane laboratoryjne od terenowych w dashboardzie.
• Monitoring dostępności, na przykład UptimeRobot lub Better Uptime: ustaw lokalizacje, częstotliwość i progi zgodnie z uzgodnionym SLO oraz przetestuj kanał alertu.
• APM, na przykład New Relic lub Datadog, dobierz według potrzeby śledzenia transakcji, błędów i zapytań oraz kosztu retencji. Sam poziom ruchu nie wyznacza uniwersalnego progu opłacalności.
• Sentry lub podobne narzędzie może zbierać obsłużone typy błędów JavaScript i backendu po poprawnej instalacji. Zweryfikuj source mapy, filtrowanie danych i testowe zdarzenie przed poleganiem na alertach.
• Log Analysis: analizuj logi serwera (access log, error log) regularnie. Narzędzia: GoAccess (real-time), AWStats, lub ELK Stack.