Porady PrestaShop FAQ

Dlaczego migracje są niebezpieczne dla SEO

Migracja sklepu PrestaShop to jedna z operacji niosących największe ryzyko z perspektywy SEO. Niezależnie od tego, czy przenosisz sklep na nowy serwer, zmieniasz domenę, aktualizujesz PrestaShop z wersji 1.6 do 1.7 lub 8.x, czy restrukturyzujesz wzorce adresów URL — każda migracja niesie ze sobą ryzyko zniszczenia miesięcy lub lat wypracowanych pozycji w wyszukiwarkach.

Powód jest prosty. Google i inne wyszukiwarki zaindeksowały Twoje obecne adresy URL, przypisały im autorytet i zbudowały mapę struktury Twojej witryny. Kiedy zmieniasz cokolwiek w tych adresach URL, ich strukturze lub dostępności, wyszukiwarki muszą ponownie ocenić wszystko. Jeśli przejście zostanie przeprowadzone źle, Google interpretuje zmianę jako zniknięcie starej treści i pojawienie się nowej, niesprawdzonej. Efektem jest spadek pozycji, z którego odzyskanie może zająć miesiące — o ile w ogóle nastąpi pełne odzyskanie.

Dobra wiadomość jest taka, że migracje można przeprowadzić bezpiecznie. Przy odpowiednim planowaniu, prawidłowej implementacji przekierowań i uważnym monitorowaniu możesz zachować zdecydowaną większość swoich pozycji podczas migracji. Ten przewodnik przeprowadzi Cię przez każdy etap procesu, od wstępnego audytu SEO po monitoring po migracji.

Audyt SEO przed migracją

Zanim dotkniesz jakiegokolwiek pliku konfiguracyjnego, potrzebujesz pełnego obrazu aktualnego stanu SEO. Ten audyt służy dwóm celom: daje Ci punkt odniesienia do porównania po migracji i identyfikuje najcenniejsze strony, które muszą być obsłużone z absolutną starannością.

Przeskanuj swoją obecną witrynę

Użyj narzędzia do crawlowania, takiego jak Screaming Frog, Sitebulb lub darmowej wersji Screaming Frog (ograniczonej do 500 adresów URL), aby przeskanować całą witrynę. Wyeksportuj pełną listę adresów URL, ich kody statusu HTTP, tytuły stron, opisy meta, tagi kanoniczne i strukturę linkowania wewnętrznego. Zapisz te dane. Będziesz ich potrzebować po migracji, aby zweryfikować, że nic nie zostało utracone.

Eksportuj dane z Google Search Console

Google Search Console to najbardziej wiarygodne źródło informacji o tym, które strony faktycznie generują ruch organiczny. Przejdź do Skuteczność > Wyniki wyszukiwania i wyeksportuj dane za ostatnie 16 miesięcy (maksymalny dostępny okres). Zwróć szczególną uwagę na:

Strony z największą liczbą kliknięć i wyświetleń. To Twoje strony generujące przychód. Awaria przekierowania na którejkolwiek z tych stron będzie miała natychmiastowy i widoczny wpływ na ruch.

Zapytania generujące największy ruch. Po migracji będziesz monitorować te zapytania, aby zweryfikować stabilność pozycji.

Strony z dużą liczbą wyświetleń, ale małą liczbą kliknięć. Te strony są na granicy osiągnięcia dobrych pozycji i są szczególnie wrażliwe na zakłócenia.

Udokumentuj swoją strukturę URL

PrestaShop generuje adresy URL na podstawie ustawień przyjaznych adresów URL, struktury kategorii i konfiguracji produktów. Udokumentuj te wzorce. Na przykład, czy Twoje adresy URL produktów mają strukturę /kategoria/nazwa-produktu.html, czy po prostu /nazwa-produktu.html? Czy adresy URL kategorii zawierają identyfikatory, takie jak /3-nazwa-kategorii? Czy strony CMS znajdują się pod /content/5-nazwa-strony?

Zrozumienie tych wzorców jest kluczowe, ponieważ nowa instalacja może domyślnie generować inne struktury adresów URL, a każdy zmieniony adres URL wymaga przekierowania.

Sprawdź istniejące linki zwrotne

Użyj narzędzia do sprawdzania linków zwrotnych, takiego jak Ahrefs, Moz lub raport Linki w Google Search Console, aby zidentyfikować, które zewnętrzne strony linkują do Twojego sklepu i do których konkretnych stron. Te strony z linkami zwrotnymi niosą największy autorytet, a ich utrata oznacza utratę wartości SEO każdego linku zwrotnego, który na nie wskazuje.

Tworzenie mapy URL

Mapa URL to najważniejszy dokument w całej migracji. To arkusz kalkulacyjny, który mapuje każdy stary adres URL na odpowiadający mu nowy adres URL. Każdy adres URL, który kiedykolwiek generował ruch, ma linki zwrotne lub pojawia się w mapie witryny, musi mieć swoje mapowanie.

Generowanie listy adresów URL

Połącz adresy URL ze skanowania witryny, eksportu z Google Search Console, raportu linków zwrotnych i mapy witryny XML. Usuń duplikaty i posortuj według ważności (ruch i wartość linków zwrotnych). Twoja finalna lista powinna zawierać:

Wszystkie adresy URL produktów. W PrestaShop są one generowane na podstawie nazwy produktu i konfiguracji przyjaznych adresów URL. Jeśli zmieniasz strukturę adresów URL (na przykład usuwasz rozszerzenia .html lub zmieniasz format ścieżki kategorii), każdy adres URL produktu ulega zmianie.

Wszystkie adresy URL kategorii. Adresy URL kategorii w PrestaShop często zawierają identyfikator kategorii, a ten identyfikator może być inny w nowej instalacji, jeśli ponownie importujesz kategorie.

Wszystkie adresy URL stron CMS. Obejmują one stronę informacyjną, regulamin, politykę prywatności i wszelkie inne strony z treścią.

Wszystkie adresy URL producentów i dostawców, jeśli korzystasz z tych funkcji.

Paginowane adresy URL dla kategorii z dużą liczbą produktów.

Tworzenie mapowania

Dla każdego starego adresu URL określ, jaki będzie odpowiadający mu nowy adres URL. Jeśli struktura adresów URL nie zmienia się (ta sama domena, te same ustawienia przyjaznych adresów URL, te same identyfikatory), wiele adresów URL może mapować się na siebie i nie potrzeba przekierowania. Ale zweryfikuj to. Nawet niewielkie zmiany, takie jak inna głębokość drzewa kategorii lub różnica w końcowym ukośniku, tworzą nowe adresy URL wymagające przekierowań.

Jeśli zmieniasz wzorce adresów URL systematycznie (na przykład usuwasz wszystkie rozszerzenia .html), możesz użyć przekierowań opartych na wyrażeniach regularnych zamiast mapować każdy adres URL indywidualnie. Ale zawsze zweryfikuj wyrażenie regularne na swojej faktycznej liście adresów URL przed uruchomieniem.

Implementacja przekierowań 301

Przekierowanie 301 informuje wyszukiwarki, że strona została trwale przeniesiona do nowej lokalizacji. Przenosi zdecydowaną większość wartości SEO (equity linków) ze starego adresu URL na nowy. To mechanizm, który zachowuje Twoje pozycje podczas migracji.

Gdzie umieszczać przekierowania

Dla PrestaShop na Apache przekierowania umieszcza się w pliku .htaccess w katalogu głównym dokumentów. Umieść reguły przekierowań przed regułami rewrite PrestaShop (przed sekcją zaczynającą się od # Dispatcher).

Dla PrestaShop na Nginx przekierowania umieszcza się w konfiguracji bloku serwera. Może być konieczne przeładowanie Nginx po zmianach: sudo nginx -t && sudo systemctl reload nginx.

Składnia reguł przekierowań

Dla Apache .htaccess, indywidualne przekierowania używają tego formatu:

Redirect 301 /stara-sciezka/stary-produkt.html https://www.nowadomena.com/nowa-sciezka/nowy-produkt

Dla przekierowań opartych na wzorcach z użyciem mod_rewrite:

RewriteEngine On RewriteRule ^stara-kategoria/(.*)$ /nowa-kategoria/$1 [R=301,L]

Dla Nginx, indywidualne przekierowania:

location = /stara-sciezka/stary-produkt.html { return 301 https://www.nowadomena.com/nowa-sciezka/nowy-produkt; }

Obsługa dużej liczby przekierowań

Sklepy PrestaShop z tysiącami produktów potrzebują bardziej skalowalnego podejścia niż pisanie indywidualnych reguł przekierowań. Opcje obejmują użycie RewriteMap w Apache (który czyta z pliku tekstowego lub bazy danych), użycie modułu PrestaShop zaprojektowanego do zarządzania przekierowaniami lub implementację przekierowań na poziomie aplikacji przez niestandardowy moduł przechwytujący błędy 404 i sprawdzający tabelę przekierowań.

Podejście na poziomie aplikacji ma tę zaletę, że jest zarządzalne przez panel administracyjny, ale dodaje niewielki narzut wydajnościowy do każdego żądania 404. Podejście przez .htaccess jest szybsze, ale trudniejsze w zarządzaniu na dużą skalę.

Aktualizacja mapy witryny XML

Twoja mapa witryny XML informuje wyszukiwarki, które adresy URL istnieją na Twojej stronie i powinny być przeskanowane. Po migracji mapa witryny musi natychmiast odzwierciedlać nową strukturę adresów URL.

Generowanie nowej mapy witryny

PrestaShop posiada wbudowane generowanie mapy witryny, ale wielu właścicieli sklepów korzysta z modułu takiego jak Google Sitemap lub zewnętrznego modułu SEO dla większej kontroli. Po migracji wygeneruj świeżą mapę witryny zawierającą wszystkie nowe adresy URL. Zweryfikuj, że mapa witryny nie zawiera żadnych starych adresów URL, które teraz przekierowują.

Przesyłanie zaktualizowanej mapy witryny

Przejdź do Google Search Console, nawiguj do sekcji Mapy witryn i prześlij nowy adres URL mapy witryny (zazwyczaj https://www.twojadomena.com/1_index_sitemap.xml dla PrestaShop). Jeśli sam adres URL mapy witryny uległ zmianie, usuń stary wpis i dodaj nowy.

Przesłanie świeżej mapy witryny sygnalizuje Google, że struktura Twojej strony uległa zmianie i zachęca do szybszego crawlowania nowych adresów URL. W połączeniu z prawidłowymi przekierowaniami 301 ze starych adresów URL, daje to Google jasny obraz tego, co się stało.

Kroki migracji w Google Search Console

Migracja w tej samej domenie (przeniesienie serwera lub aktualizacja)

Jeśli Twoja domena nie zmienia się, nie są potrzebne żadne specjalne działania w Search Console poza przesłaniem zaktualizowanej mapy witryny i monitorowaniem. Google odkryje zmiany poprzez normalne crawlowanie.

Migracja ze zmianą domeny

Jeśli zmieniasz domeny, użyj narzędzia Zmiana adresu w Google Search Console. Wymaga to, aby zarówno stara, jak i nowa domena były zweryfikowane w Search Console. Kroki są następujące:

Po pierwsze, skonfiguruj i zweryfikuj nową domenę w Google Search Console. Po drugie, upewnij się, że wszystkie przekierowania 301 są na miejscu ze starej domeny na nową. Po trzecie, przejdź do właściwości starej domeny w Search Console i użyj Ustawienia > Zmiana adresu. Po czwarte, postępuj zgodnie z instrukcjami, aby określić nową domenę.

Informuje to Google wyraźnie, że Twoja strona została przeniesiona, co znacząco przyspiesza proces przejścia. Bez tego kroku Google ostatecznie to ustali na podstawie przekierowań 301, ale zajmie to więcej czasu.

Kwestie propagacji DNS

Jeśli Twoja migracja obejmuje zmianę rekordów DNS (kierowanie domeny na nowy serwer), pamiętaj, że propagacja DNS nie jest natychmiastowa. Różne resolvery DNS na całym świecie aktualizują się w różnym czasie, a pełna propagacja może zająć od 24 do 72 godzin.

Minimalizowanie przestojów

Przed migracją zmniejsz TTL (Time To Live) DNS do niskiej wartości, takiej jak 300 sekund (5 minut). Zrób to co najmniej 48 godzin przed właściwą migracją, aby stary, wysoki TTL zdążył wygasnąć wszędzie. Kiedy zmienisz rekordy DNS, resolvery będą sprawdzać aktualizacje co 5 minut zamiast co kilka godzin.

Po zakończeniu i zweryfikowaniu migracji zwiększ TTL z powrotem do normalnej wartości, takiej jak 3600 (1 godzina) lub wyższej, aby zmniejszyć obciążenie zapytaniami DNS.

Uruchamianie obu serwerów równolegle

Podczas okna propagacji niektórzy odwiedzający dotrą do starego serwera, a niektórzy do nowego. Utrzymuj stary serwer z kopią strony (lub przynajmniej z regułami przekierowań) do czasu zakończenia propagacji. Natychmiastowe wyłączenie starego serwera powoduje przestoje dla odwiedzających, których DNS nie został jeszcze zaktualizowany.

Monitoring pozycji po migracji

Praca nie kończy się, gdy migracja staje się aktywna. Monitoring po migracji jest niezbędny, aby wychwycić problemy, zanim spowodują trwałe szkody.

Natychmiastowe sprawdzenia (Dzień 1)

Zweryfikuj, że wszystkie kluczowe strony ładują się poprawnie na nowej witrynie. Przetestuj każde przekierowanie z Twojej mapy URL, aby potwierdzić, że działa. Sprawdź Google Search Console pod kątem nowych błędów crawlowania. Przeprowadź świeże skanowanie witryny i porównaj je z danymi ze skanowania przed migracją.

Monitoring w pierwszym tygodniu

Sprawdzaj Google Search Console codziennie pod kątem błędów crawlowania, problemów z indeksowaniem i wszelkich spadków ruchu. Sprawdź raport Pokrycie pod kątem stron, które nie są już indeksowane lub zwróciły błędy. Monitoruj pozycje swoich kluczowych słów kluczowych za pomocą narzędzia do śledzenia pozycji. Pewne wahania są normalne w pierwszym tygodniu, ale duże spadki na ważnych słowach kluczowych wskazują na problem z przekierowaniem.

Monitoring w pierwszym miesiącu

Porównaj ruch organiczny w Google Analytics lub swojej platformie analitycznej z tym samym okresem przed migracją. Sprawdź, czy wszystkie ważne strony są ponownie indeksowane, wyszukując site:twojadomena.com/konkretna-strona w Google. Zweryfikuj, że stare adresy URL są usuwane z indeksu (powinny przekierowywać na nowe adresy URL, a Google powinien ostatecznie zastąpić je w swoim indeksie).

Ocena po trzech miesiącach

Po trzech miesiącach od migracji Twój ruch organiczny powinien ustabilizować się na poziomie równym lub zbliżonym do poziomu sprzed migracji. Jeśli tak się nie stało, zbadaj, które konkretne strony lub zapytania straciły pozycje i sprawdź ich łańcuchy przekierowań, jakość treści i kondycję techniczną.

Najczęstsze błędy migracyjne

Używanie przekierowań 302 zamiast 301

Przekierowanie 302 informuje wyszukiwarki, że przeniesienie jest tymczasowe. Wyszukiwarki nie przenoszą pełnej wartości linków (equity) przez przekierowania 302. Zawsze używaj 301 dla trwałych migracji. To najczęstszy i najbardziej szkodliwy błąd.

Zapomnienie o przekierowaniu non-www na www (lub odwrotnie)

Jeśli Twoja stara strona używała www.example.com, a nowa używa example.com (lub odwrotnie), potrzebujesz przekierowań zarówno dla zmiany struktury URL, jak i zmiany www/non-www. Zapomnienie o jednym z nich tworzy sytuację, w której niektóre stare adresy URL zwracają błędy 404.

Brak aktualizacji linków wewnętrznych

Po migracji Twoje linki wewnętrzne powinny wskazywać bezpośrednio na nowe adresy URL, a nie na stare adresy URL, które przekierowują. Podczas gdy przekierowania zachowują wartość SEO dla linków zewnętrznych, linki wewnętrzne prowadzące przez przekierowania tworzą niepotrzebne łańcuchy przekierowań i spowalniają crawlowanie.

Utrata HTTPS

Jeśli Twoja stara strona używała HTTPS, a nowa nie (lub odwrotnie), Google traktuje je jako różne adresy URL. Upewnij się, że Twój certyfikat SSL jest prawidłowo skonfigurowany na nowym serwerze przed uruchomieniem i że wszystkie przekierowania używają prawidłowego protokołu.

Zmienianie wielu rzeczy jednocześnie

Jeśli zmieniasz domenę, strukturę URL, treść i projekt strony jednocześnie, diagnozowanie przyczyn ewentualnych spadków pozycji staje się niemożliwe. Zmień jak najmniej rzeczy podczas samej migracji. Aktualizacje treści i projektu mogą nastąpić po ustabilizowaniu się pozycji.

Harmonogram migracji

Dobrze zaplanowana migracja PrestaShop przebiega według następującego harmonogramu:

4 tygodnie przed: Przeprowadź pełny audyt SEO, wyeksportuj wszystkie dane, rozpocznij tworzenie mapy URL. Obniż TTL DNS, jeśli zmieniasz serwery.

2 tygodnie przed: Sfinalizuj mapę URL, napisz wszystkie reguły przekierowań, skonfiguruj nową stronę w środowisku staging i dokładnie przetestuj.

1 tydzień przed: Przetestuj wszystkie przekierowania na stagingu. Zweryfikuj, że nowa mapa witryny XML jest poprawna. Przeprowadź pełne skanowanie strony staging i porównaj z danymi skanowania starej strony.

Dzień migracji: Wdróż nową stronę, aktywuj przekierowania, zaktualizuj DNS jeśli to konieczne, prześlij nową mapę witryny do Search Console, użyj narzędzia Zmiana adresu jeśli zmieniasz domeny.

Tydzień 1: Monitoruj Search Console codziennie, naprawiaj wszelkie błędy crawlowania natychmiast, weryfikuj działanie przekierowań.

Miesiąc 1: Cotygodniowe przeglądy Search Console, porównuj ruch z punktem odniesienia, sprawdzaj postęp indeksowania.

Miesiąc 3: Pełna ocena w odniesieniu do punktu odniesienia sprzed migracji. Rozwiąż wszelkie pozostałe problemy.

Podsumowanie

Udana migracja PrestaShop, która zachowuje pozycje w Google, wymaga trzech rzeczy: dokładnego przygotowania, prawidłowej implementacji przekierowań i starannego monitoringu po migracji. Audyt przed migracją daje Ci punkt odniesienia i identyfikuje najcenniejsze strony. Mapa URL i przekierowania 301 zapewniają, że wartość SEO każdej strony zostanie przeniesiona do nowej lokalizacji. Aktualizacja mapy witryny i konfiguracja Search Console pomagają Google szybko odkryć i przetworzyć zmiany. A monitoring po migracji wychwytuje problemy, zanim staną się trwałe. Pomiń którykolwiek z tych kroków, a ryzykujesz utratę pozycji, których zbudowanie zajęło miesiące lub lata. Zastosuj je wszystkie, a Twoja migracja stanie się kontrolowanym przejściem, a nie katastrofą SEO.

Przeczytaj pełną odpowiedź

Zrozumienie przekierowań i dlaczego 301 to jedyny prawidłowy wybór

Podczas migracji sklepu PrestaShop adresy URL ulegają zmianie. Produkty, które znajdowały się pod jednym adresem, teraz znajdują się pod innym. Kategorie, które miały jeden slug, teraz mają inny. Bez przekierowań każdy stary adres URL staje się ślepą uliczką, zwracając błąd 404 zarówno odwiedzającym, jak i wyszukiwarkom. Skumulowany efekt jest katastrofalny: utracony ruch, utracone pozycje i utracona sprzedaż.

Przekierowanie to instrukcja z Twojego serwera, która informuje przeglądarki i boty wyszukiwarek, że strona została przeniesiona. Kiedy odwiedzający lub Googlebot żąda starego adresu URL, serwer odpowiada nową lokalizacją, a klient automatycznie ją śledzi. Jednak nie wszystkie przekierowania są równe, a użycie niewłaściwego typu może podważyć całą Twoją migrację.

301 vs 302: Kluczowa różnica

Przekierowanie 301 sygnalizuje trwałe przeniesienie. Informuje wyszukiwarki, aby przeniosły skumulowaną wartość linków (wartość SEO zbudowaną dzięki linkom zwrotnym, jakości treści i zaangażowaniu użytkowników) ze starego adresu URL na nowy. Z czasem Google zastępuje stary adres URL w swoim indeksie nowym. To właśnie tego potrzebujesz po migracji.

Przekierowanie 302 sygnalizuje tymczasowe przeniesienie. Informuje wyszukiwarki, że stary adres URL ostatecznie wróci, więc powinny zachować stary adres URL w indeksie i nie przenosić wartości linków. Użycie przekierowań 302 po trwałej migracji oznacza, że Google nadal próbuje indeksować Twoje stare adresy URL, Twoje nowe adresy URL mają trudności z uzyskaniem autorytetu i tracisz pozycje niepotrzebnie.

Istnieje również przekierowanie 307, które jest odpowiednikiem 302 w HTTP/1.1, oraz przekierowanie 308, które jest odpowiednikiem 301 w HTTP/1.1. Dla celów SEO w PrestaShop 301 jest standardowym i powszechnie obsługiwanym wyborem.

Reguła jest prosta: jeśli strona została trwale przeniesiona, użyj 301. Po migracji strona została trwale przeniesiona. Zawsze używaj 301.

Konfiguracja przekierowań w .htaccess (Apache)

Większość instalacji PrestaShop działa na Apache, a plik .htaccess jest miejscem, w którym konfigurujesz przekierowania. Ten plik znajduje się w katalogu głównym PrestaShop obok index.php.

Kolejność ma znaczenie

Plik .htaccess PrestaShop zawiera reguły rewrite obsługujące przyjazne adresy URL, wymuszanie HTTPS i kierowanie żądań do odpowiednich kontrolerów. Twoje reguły przekierowań muszą być umieszczone przed regułami rewrite PrestaShop. Jeśli umieścisz je po nich, reguły PrestaShop mogą przechwycić żądanie jako pierwsze i Twoje przekierowania nigdy nie zostaną wykonane.

Poszukaj komentarza # Dispatcher lub bloku zaczynającego się od RewriteRule ^api. Twoje niestandardowe przekierowania powinny znaleźć się powyżej tej sekcji, ale po RewriteEngine On.

Przekierowania indywidualnych stron

Najprostszą formą przekierowania jest mapowanie jednego konkretnego starego adresu URL na jeden konkretny nowy adres URL:

Redirect 301 /stara-kategoria/stary-produkt.html https://www.example.com/nowa-kategoria/nowy-produkt

Dyrektywa Redirect jest częścią modułu mod_alias Apache. Pierwszy argument to kod statusu HTTP (301), drugi to stara ścieżka (względem katalogu głównego dokumentów), a trzeci to pełny nowy adres URL.

Ważne szczegóły: stara ścieżka musi zaczynać się od ukośnika i nie może zawierać nazwy domeny. Nowy adres URL musi być pełnym adresem URL zawierającym protokół i domenę. Stara ścieżka jest dopasowywana dokładnie, łącznie z końcowymi ukośnikami i rozszerzeniami plików.

Przekierowania oparte na wzorcach z RewriteRule

Gdy wiele adresów URL podlega przewidywalnej zmianie wzorca, indywidualne przekierowania stają się niepraktyczne. Moduł mod_rewrite Apache pozwala pisać reguły oparte na wzorcach z użyciem wyrażeń regularnych:

RewriteEngine On RewriteRule ^stara-kategoria/(.*)$ /nowa-kategoria/$1 [R=301,L]

Ta reguła przechwytuje wszystko po stara-kategoria/ i dołącza to do nowa-kategoria/. $1 jest odwołaniem wstecznym do pierwszej przechwyconej grupy (części w nawiasach). Flagi [R=301,L] określają przekierowanie 301 oraz że jest to ostatnia reguła do przetworzenia w przypadku dopasowania.

Typowe scenariusze przekierowań opartych na wzorcach podczas migracji PrestaShop:

Usuwanie rozszerzeń .html:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Zmiana z adresów URL kategorii opartych na ID na oparte na nazwach:

RewriteRule ^3-stara-nazwa-kategorii(.*)$ /nowa-nazwa-kategorii$1 [R=301,L]

Przekierowanie całego podkatalogu:

RewriteRule ^shop/(.*)$ /$1 [R=301,L]

Przekierowania warunkowe

Czasami potrzebujesz przekierowań, które stosują się tylko w określonych warunkach. RewriteCond zapewnia tę możliwość:

RewriteCond %{HTTP_HOST} ^staradomena\.com$ [NC] RewriteRule ^(.*)$ https://www.nowadomena.com/$1 [R=301,L]

To przekierowuje wszystkie żądania ze staradomena.com na nowadomena.com, zachowując ścieżkę. Flaga [NC] sprawia, że warunek jest nieczuły na wielkość liter.

Aby przekierować tylko wtedy, gdy żądany plik nie istnieje na nowym serwerze (przydatne podczas stopniowej migracji):

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^stara-sciezka/(.*)$ /nowa-sciezka/$1 [R=301,L]

Konfiguracja przekierowań w Nginx

Jeśli Twój PrestaShop działa na Nginx, przekierowania konfiguruje się w pliku konfiguracji bloku serwera, zazwyczaj znajdującym się pod /etc/nginx/sites-available/twojadomena.conf lub /etc/nginx/conf.d/twojadomena.conf.

Przekierowania indywidualne

location = /stara-kategoria/stary-produkt.html { return 301 https://www.example.com/nowa-kategoria/nowy-produkt; }

Modyfikator = określa dokładne dopasowanie. Bez niego Nginx traktuje lokalizację jako dopasowanie prefiksowe, co mogłoby przekierować więcej adresów URL niż zamierzono.

Przekierowania oparte na wzorcach

location ~ ^/stara-kategoria/(.*)$ { return 301 /nowa-kategoria/$1; }

Modyfikator ~ włącza dopasowanie regex. Przechwycona grupa $1 działa w ten sam sposób jak w Apache.

Przekierowania oparte na mapie dla dużych list

Dyrektywa map w Nginx jest idealna do zarządzania setkami lub tysiącami indywidualnych przekierowań bez zaśmiecania bloku serwera:

map $request_uri $redirect_target { /stary-produkt-1.html /nowy-produkt-1; /stary-produkt-2.html /nowy-produkt-2; /stary-produkt-3.html /nowy-produkt-3; }

server { if ($redirect_target) { return 301 $redirect_target; } }

Blok map jest ewaluowany tylko raz na żądanie i jest wysoce wydajny nawet z tysiącami wpisów. Możesz nawet załadować mapę z zewnętrznego pliku za pomocą dyrektywy include.

Pamiętaj, aby przetestować konfigurację za pomocą nginx -t i przeładować za pomocą systemctl reload nginx po wszelkich zmianach.

Masowe przekierowania z CSV

Przy migracjach obejmujących tysiące produktów, ręczne pisanie reguł przekierowań nie jest wykonalne. Podejście oparte na CSV usprawnia ten proces.

Tworzenie pliku CSV

Wyeksportuj swoje stare adresy URL z danych skanowania przed migracją lub bazy danych. Wyeksportuj nowe adresy URL z nowej instalacji. Dopasuj je w arkuszu kalkulacyjnym z dwiema kolumnami: stara ścieżka URL i nowa ścieżka URL. Zapisz jako CSV.

Twój plik CSV może wyglądać tak:

/3-stara-kategoria,/nowa-kategoria /stara-kategoria/stary-produkt-1.html,/nowa-kategoria/nowy-produkt-1 /stara-kategoria/stary-produkt-2.html,/nowa-kategoria/nowy-produkt-2 /content/5-o-nas,/content/o-nas

Konwersja CSV na reguły .htaccess

Prostym podejściem jest konwersja każdej linii CSV na dyrektywę Redirect. Za pomocą edytora tekstu z funkcją znajdź i zamień lub prostego narzędzia wiersza poleceń:

awk -F',' '{print "Redirect 301 " $1 " https://www.example.com" $2}' redirects.csv >> .htaccess

To odczytuje plik CSV, dzieli każdą linię po przecinku i generuje dyrektywę Redirect dla każdej linii.

Użycie tabeli bazy danych

Dla bardzo dużych list przekierowań (10 000+ wpisów) rozważ przechowywanie przekierowań w tabeli bazy danych i obsługę ich na poziomie aplikacji. Utwórz tabelę z kolumnami dla starej ścieżki i nowej ścieżki, a następnie napisz mały moduł PrestaShop lub override, który przechwytuje błędy 404, sprawdza tabelę i zwraca przekierowanie 301, jeśli znaleziono dopasowanie. To podejście jest łatwiejsze w zarządzaniu przez interfejs administracyjny, ale dodaje małe zapytanie do bazy danych przy każdej odpowiedzi 404.

Rozwiązania przekierowań oparte na modułach

Kilka modułów PrestaShop zapewnia zarządzanie przekierowaniami przez panel administracyjny, eliminując potrzebę bezpośredniej edycji plików konfiguracji serwera.

Zalety przekierowań opartych na modułach

Moduł do przekierowań oferuje przyjazny interfejs użytkownika do dodawania, edytowania i usuwania przekierowań. Zazwyczaj zawiera funkcjonalność importu/eksportu do operacji masowych, logowanie do śledzenia, które przekierowania są używane, oraz możliwość zarządzania przekierowaniami przez członków zespołu bez dostępu do serwera.

Jak działają przekierowania oparte na modułach

Większość modułów do przekierowań działa poprzez podpięcie do procesu obsługi żądań PrestaShop. Kiedy przychodzi żądanie, które normalnie skutkowałoby błędem 404, moduł je przechwytuje, sprawdza swoją bazę danych przekierowań pod kątem pasującego starego adresu URL, a jeśli go znajdzie, wysyła odpowiedź z przekierowaniem 301 na nowy adres URL.

Niektóre moduły idą dalej, automatycznie tworząc przekierowania, gdy zmienisz przyjazny adres URL produktu w panelu administracyjnym. To zapobiega częstemu problemowi łamania starych linków podczas optymalizacji slugów adresów URL.

Kwestie wydajności

Przekierowania oparte na modułach dodają niewielki narzut do każdego żądania 404, ponieważ muszą odpytać bazę danych. Dla większości sklepów jest to pomijalne, ale jeśli masz tysiące przekierowań i znaczny ruch botów trafiający w stare adresy URL, zapytania do bazy danych mogą się sumować. Rozważ użycie warstwy cache lub przeniesienie najczęściej używanych przekierowań do .htaccess dla optymalnej wydajności.

Przekierowania regex: Moc i niebezpieczeństwo

Przekierowania oparte na wyrażeniach regularnych to potężne narzędzia, które mogą obsługiwać złożone transformacje adresów URL za pomocą jednej reguły. Są również najczęstszym źródłem błędów przekierowań i nieskończonych pętli.

Kiedy używać przekierowań regex

Używaj przekierowań regex, gdy zmiana adresu URL jest zgodna ze spójnym, przewidywalnym wzorcem. Dobrymi kandydatami są: usuwanie lub dodawanie rozszerzeń plików we wszystkich adresach URL, zmiana prefiksu adresu URL dla całej sekcji witryny, usuwanie lub dodawanie prefiksów językowych oraz usuwanie parametrów zapytania.

Typowe wzorce regex dla PrestaShop

Usuwanie prefiksu identyfikatora kategorii, który PrestaShop 1.6 dodaje do adresów URL kategorii:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

To dopasowuje adresy URL takie jak /3-buty i przekierowuje do /buty.

Dodawanie prefiksu językowego:

RewriteCond %{REQUEST_URI} !^/(en|de|fr)/ RewriteRule ^(.+)$ /en/$1 [R=301,L]

Usuwanie podwójnych ukośników:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Bezpieczne testowanie reguł regex

Przed wdrożeniem przekierowań regex na produkcji, dokładnie je przetestuj. Użyj testera wyrażeń regularnych online (takiego jak regex101.com), aby zweryfikować, że Twój wzorzec dopasowuje adresy URL, które zamierzasz, i nie dopasowuje tych, których nie powinien.

Zacznij od przekierowania 302 podczas testowania. To zapobiega cachowaniu nieprawidłowych przekierowań przez wyszukiwarki. Po zweryfikowaniu, że reguła działa poprawnie, zmień ją na 301.

Testuj przypadki brzegowe: adresy URL z parametrami zapytania, adresy URL ze znakami specjalnymi, adresy URL z wieloma pasującymi wzorcami. Każdy z tych przypadków może ujawnić problemy, które nie są oczywiste przy prostych testowych adresach URL.

Testowanie przekierowań

Wdrażanie przekierowań bez dokładnego testowania to przepis na katastrofę. Oto metody, których powinieneś użyć do weryfikacji przekierowań przed i po uruchomieniu.

Testowanie z wiersza poleceń za pomocą curl

Polecenie curl jest najbardziej niezawodnym sposobem testowania przekierowań, ponieważ pokazuje dokładnie, co zwraca serwer:

curl -I https://www.example.com/stary-produkt.html

Flaga -I żąda tylko nagłówków. W odpowiedzi szukaj:

HTTP/1.1 301 Moved Permanently Location: https://www.example.com/nowy-produkt

Zweryfikuj, że kod statusu to 301 (nie 302) i że nagłówek Location wskazuje na prawidłowy nowy adres URL.

Aby śledzić łańcuch przekierowań i zobaczyć każdy skok:

curl -IL https://www.example.com/stary-produkt.html

Flaga -L mówi curl, aby śledził przekierowania, pokazując nagłówki na każdym kroku.

Testowanie masowe

Dla dużych list przekierowań zautomatyzuj testowanie za pomocą pętli:

while IFS=, read -r old new; do status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.example.com$old") echo "$old -> $status" done < redirects.csv

To odczytuje plik CSV, testuje każdy stary adres URL i wyświetla kod statusu HTTP. Każdy adres URL, który nie zwraca 301, wymaga uwagi.

Testowanie w przeglądarce

Otwórz narzędzia developerskie przeglądarki (F12), przejdź do karty Sieć (Network) i przejdź do starego adresu URL. Karta Sieć pokazuje łańcuch żądań, w tym wszystkie przekierowania. Zweryfikuj kod statusu, cel przekierowania i ostateczną stronę, która się ładuje.

Inspekcja w Google Search Console

Po wdrożeniu użyj narzędzia Inspekcja adresów URL w Google Search Console, aby sprawdzić, jak Google widzi Twoje przekierowane adresy URL. Wprowadź stary adres URL i sprawdź, czy Google rozpoznaje przekierowanie i odkrył nowy adres URL.

Łańcuchy przekierowań i jak ich unikać

Łańcuch przekierowań występuje, gdy jedno przekierowanie prowadzi do kolejnego przekierowania, które może prowadzić do jeszcze jednego. Na przykład: adres URL A przekierowuje na adres URL B, który przekierowuje na adres URL C, który wreszcie serwuje treść. Każdy skok dodaje opóźnienie i rozcieńcza wartość linków.

Dlaczego łańcuchy przekierowań są szkodliwe

Google oświadczył, że będzie śledzić łańcuchy przekierowań, ale z ograniczeniami. Po określonej liczbie skoków (zazwyczaj 5-10) Googlebot rezygnuje i traktuje adres URL jako błąd. Nawet dla krótszych łańcuchów każdy skok opóźnia dostarczenie strony i traci niewielką ilość wartości linków.

Dla odwiedzających każde przekierowanie dodaje 50-200 milisekund opóźnienia, w zależności od warunków sieciowych i czasu odpowiedzi serwera. Łańcuch 3 przekierowań może dodać pół sekundy lub więcej do postrzeganego czasu ładowania.

Najczęstsze przyczyny łańcuchów przekierowań w PrestaShop

Najczęstszy łańcuch występuje, gdy migracja dodaje przekierowania na istniejących przekierowaniach. Na przykład, możesz mieć stare przekierowania z poprzedniej zmiany struktury URL, a nowa migracja dodaje kolejną warstwę. Adres URL A przekierowuje na adres URL B (z pierwszej migracji), a adres URL B przekierowuje na adres URL C (z drugiej migracji).

Kolejną częstą przyczyną jest interakcja między wbudowanym przekierowaniem kanonicznym PrestaShop a Twoimi niestandardowymi przekierowaniami. PrestaShop może przekierować z niekanonicznego adresu URL na wersję kanoniczną, a jeśli Twoje niestandardowe przekierowanie również pasuje, otrzymujesz łańcuch.

Wymuszanie HTTPS dodaje kolejny potencjalny skok. Jeśli Twoje przekierowanie wskazuje na adres URL HTTP, a serwer następnie przekierowuje na HTTPS, to jest dwukrokowy łańcuch.

Naprawianie łańcuchów przekierowań

Regularnie audytuj swoje przekierowania za pomocą narzędzia do crawlowania, które wykrywa łańcuchy. Gdy znajdziesz łańcuch, zaktualizuj pierwsze przekierowanie tak, aby wskazywało bezpośrednio na ostateczny cel. Adres URL A powinien przekierowywać bezpośrednio na adres URL C, omijając adres URL B.

Dodając nowe przekierowania podczas migracji, zawsze sprawdzaj, czy docelowy adres URL sam nie jest przekierowaniem. Jeśli jest, ustaw nowe przekierowanie tak, aby wskazywało na ostateczny cel.

Najczęstsze pułapki i jak ich unikać

Nieskończone pętle przekierowań

Nieskończona pętla występuje, gdy adres URL A przekierowuje na adres URL B, a adres URL B przekierowuje z powrotem na adres URL A. Przeglądarka wykrywa to i wyświetla błąd ERR_TOO_MANY_REDIRECTS. Częste przyczyny obejmują sprzeczne reguły w .htaccess (jedna reguła przekierowuje www na non-www, a druga przekierowuje non-www na www), sprzeczne przekierowania między .htaccess a modułem do przekierowań oraz reguły regex, które są zbyt szerokie i dopasowują swoje własne docelowe adresy URL.

Aby naprawić pętlę, zacznij od wyłączenia wszystkich niestandardowych przekierowań i włączaj je jedno po drugim, aż pętla się pojawi. To identyfikuje konfliktową regułę.

Zapominanie o parametrach zapytania

Domyślnie dyrektywa Redirect Apache przepuszcza parametry zapytania do nowego adresu URL. Jednak RewriteRule nie przepuszcza parametrów zapytania, chyba że dodasz flagę [QSA] (Query String Append). Jeśli Twoje stare adresy URL zawierają ważne parametry zapytania (takie jak ?id_product=123), upewnij się, że są prawidłowo obsługiwane.

Wielkość liter

Na serwerach Linux adresy URL rozróżniają wielkość liter. /Produkt.html i /produkt.html to różne adresy URL. Jeśli Twoja stara strona miała adresy URL z mieszaną wielkością liter, a nowa normalizuje do małych liter, potrzebujesz przekierowań obsługujących oba przypadki. Użyj flagi [NC] w RewriteRule dla dopasowania nieczułego na wielkość liter.

Brak przekierowania wszystkich wariantów URL

Pojedyncza strona produktowa może być dostępna pod wieloma adresami URL: z końcowym ukośnikiem i bez niego, z rozszerzeniem .html i bez niego, z prefiksem ścieżki kategorii i bez niego, z www i bez www. Każdy wariant, który został zaindeksowany, potrzebuje własnego przekierowania na nowy kanoniczny adres URL.

Pozostawianie przekierowań na zawsze

Chociaż przekierowania powinny pozostać na miejscu przez co najmniej 12 miesięcy po migracji (Google zaleca co najmniej rok), nie powinny pozostawać w nieskończoność. Po roku lub dłużej stare adresy URL nie powinny pojawiać się w wynikach wyszukiwania ani generować znaczącego ruchu. Audytuj logi przekierowań, usuń reguły, które nie są już aktywowane, i utrzymuj czystą konfigurację.

Podsumowanie

Prawidłowa konfiguracja przekierowań 301 to najważniejsze zadanie techniczne podczas migracji PrestaShop. Każdy stary adres URL, który miał ruch, linki zwrotne lub widoczność w wyszukiwarkach, musi przekierowywać na swój nowy odpowiednik z kodem statusu 301. Metoda implementacji zależy od Twojego serwera (Apache .htaccess lub konfiguracja Nginx), liczby adresów URL (indywidualne reguły, wzorce regex lub moduły wspierane bazą danych) i kompetencji technicznych Twojego zespołu. Testuj każde przekierowanie przed uruchomieniem za pomocą curl lub narzędzi developerskich przeglądarki. Uważaj na łańcuchy przekierowań, nieskończone pętle i kwestie wielkości liter. Monitoruj Google Search Console po wdrożeniu, aby zweryfikować, że Google prawidłowo przetwarza Twoje przekierowania. I pamiętaj, że 302 tam, gdzie powinno być 301, nigdy nie jest nieszkodliwe. To zawsze zły wybór dla trwałej migracji.

Przeczytaj pełną odpowiedź

Dlaczego jakość motywu ma większe znaczenie niż wygląd

Wybór motywu PrestaShop to jedna z najbardziej konsekwentnych decyzji, jakie podejmuje właściciel sklepu. Motyw kontroluje nie tylko to, jak wygląda Twój sklep, ale także jak działa pod względem wydajności, jak dostępny jest dla klientów z niepełnosprawnościami, jak dobrze wyszukiwarki mogą go crawlować i jak łatwo można go rozbudować za pomocą modułów. Źle zbudowany motyw tworzy problemy, które narastają z czasem. To, co wygląda jak drobna niedogodność podczas konfiguracji, staje się wąskim gardłem wydajności pod obciążeniem, koszmarem konserwacyjnym podczas aktualizacji lub awarią doświadczenia klienta, która po cichu zabija konwersje.

Problem polega na tym, że rynki motywów są zalane motywami, które wyglądają imponująco na zrzutach ekranów demo, ale są zbudowane z minimalną uwagą na standardy kodowania, wydajność czy kompatybilność. Wielu deweloperów motywów optymalizuje pod kątem atrakcyjności wizualnej w podglądzie, wiedząc, że większość kupujących ocenia motywy na podstawie wyglądu, a nie sposobu budowy. Ten przewodnik nauczy Cię patrzeć poza powierzchnię i identyfikować sygnały ostrzegawcze oddzielające dobrze zbudowany motyw PrestaShop od takiego, który sprawi Ci problemy.

Nadmierna liczba żądań HTTP

Jednym z najbardziej wiarygodnych wskaźników źle zbudowanego motywu jest nadmierna liczba żądań HTTP. Każdy plik CSS, plik JavaScript, obraz, czcionka i zasób zewnętrzny ładowany przez stronę wymaga osobnego żądania do serwera. Chociaż nowoczesne przeglądarki mogą obsługiwać wiele żądań równolegle dzięki HTTP/2, każde żądanie nadal dodaje opóźnienie, szczególnie na połączeniach mobilnych.

Dobrze zbudowany motyw PrestaShop powinien ładować się z nie więcej niż 30 do 50 żądaniami na typowej stronie produktu lub kategorii, zakładając brak dodatkowych zainstalowanych modułów. Źle zbudowane motywy rutynowo przekraczają 80, a nawet 100 żądań. Najczęstsze przyczyny to ładowanie wielu plików CSS zamiast ich łączenia, dołączanie bibliotek JavaScript nieużywanych na każdej stronie, ładowanie czcionek webowych od wielu dostawców oraz osadzanie zewnętrznych widgetów lub pikseli śledzących bezpośrednio w motywie zamiast przez moduły.

Aby sprawdzić to przed zakupem motywu, otwórz demo motywu w Chrome, otwórz Narzędzia deweloperskie (F12), przejdź do karty Sieć (Network) i przeładuj stronę. Spójrz na łączną liczbę żądań pokazaną na dole panelu. Następnie sprawdź, co jest ładowane. Czy jest tam kilkadziesiąt indywidualnych plików CSS? Czy jest wiele wersji jQuery? Czy są żądania do domen trzecich, których nie rozpoznajesz? To sygnały ostrzegawcze.

Zwróć szczególną uwagę na żądania blokujące renderowanie. CSS i synchroniczny JavaScript w nagłówku dokumentu uniemożliwiają przeglądarce wyświetlenie jakiejkolwiek treści, dopóki nie zakończą ładowania. Dobrze zbudowany motyw odkłada niekrytyczne CSS i JavaScript, aby strona zaczęła się renderować szybko. Źle zbudowany motyw ładuje wszystko z góry, tworząc pusty ekran trwający sekundy.

Style inline i zakodowany na sztywno design

Profesjonalni deweloperzy motywów używają klas CSS i arkuszy stylów do kontrolowania wyglądu wizualnego motywu. To podejście jest łatwe w utrzymaniu, nadpisywalne i wydajne, ponieważ przeglądarki cachują zewnętrzne arkusze stylów. Źle zbudowane motywy natomiast rozrzucają style inline w swoich szablonach Smarty i plikach PHP. Znajdziesz tam rzeczy takie jak style=\"color: #333; font-size: 14px; margin-top: 20px;\" bezpośrednio na elementach HTML.

Style inline są problematyczne z kilku powodów. Nie mogą być cachowane oddzielnie od HTML. Są niezwykle trudne do nadpisania za pomocą CSS, wymagając deklaracji !important wszędzie. Sprawiają, że motyw jest praktycznie niemożliwy do dostosowania bez bezpośredniej edycji plików szablonów, co oznacza, że Twoje dostosowania są tracone przy każdej aktualizacji motywu. Ponadto zwiększają rozmiar dokumentu HTML, co wpływa na wydajność przy każdym ładowaniu strony.

Powiązanym sygnałem ostrzegawczym jest znajdowanie wartości projektowych zakodowanych na sztywno w plikach PHP. Jeśli widzisz kody kolorów, rozmiary czcionek lub wymiary layoutu zdefiniowane w PHP zamiast w CSS lub panelu konfiguracyjnym, deweloper motywu poszedł na skróty. Każda zmiana wizualna będzie wymagać edycji kodu PHP, co jest podatne na błędy i sprawia, że aktualizacje są niebezpieczne.

Aby sprawdzić style inline, kliknij prawym przyciskiem myszy na różnych elementach w demo motywu i wybierz Zbadaj element. Spójrz na panel Stylów w Narzędziach deweloperskich. Jeśli widzisz dużą liczbę stylów wymienionych pod element.style zamiast pochodzących z klas CSS, motyw w dużym stopniu polega na stylowaniu inline. Niektóre style inline są normalne i akceptowalne (na przykład dynamiczne obrazy tła ustawiane przez CMS), ale jeśli większość stylowania jest inline, to wyraźny sygnał ostrzegawczy.

Brak responsywnego designu

W 2026 roku ponad 60 procent ruchu e-commerce pochodzi z urządzeń mobilnych. Motyw, który nie działa dobrze na urządzeniach mobilnych, nie jest po prostu niedogodny. Bezpośrednio kosztuje Cię sprzedaż i pozycje w wyszukiwarkach, ponieważ Google stosuje indeksowanie mobile-first, co oznacza, że ocenia Twoją stronę na podstawie wersji mobilnej.

Ale responsywny design to nie tylko kwestia tego, czy motyw ma widok mobilny. Wiele motywów twierdzi, że jest responsywnych, ale implementuje to źle. Sygnały ostrzegawcze złego responsywnego designu obejmują tekst, który wychodzi poza swój kontener na małych ekranach, przyciski i linki zbyt małe do niezawodnego tapnięcia, przewijanie poziome na urządzeniach mobilnych, obrazy, które nie zmieniają rozmiaru i zmuszają użytkownika do przewijania poziomego, menu nawigacyjne trudne lub niemożliwe do użycia na urządzeniach dotykowych oraz formularze zamówień nieużywalne na telefonach.

Przetestuj demo motywu na prawdziwym telefonie, a nie tylko zmieniając rozmiar okna przeglądarki. Zmiana rozmiaru przeglądarki nie odtwarza interakcji dotykowych, rzeczywistych warunków sieciowych ani zachowania renderowania przeglądarek mobilnych. Wypróbuj cały proces zakupu na telefonie: przeglądaj kategorie, otwórz produkt, dodaj do koszyka i przejdź przez proces zamawiania. Jeśli jakikolwiek krok jest frustrujący lub zepsuty, motyw nie przechodzi najbardziej podstawowego testu gotowości mobilnej.

Sprawdź również, czy motyw używa prawidłowych responsywnych obrazów. Dobrze zbudowany motyw serwuje różne rozmiary obrazów dla różnych rozmiarów ekranu za pomocą atrybutu srcset lub elementu <picture>. Źle zbudowany motyw serwuje ten sam duży obraz desktopowy na urządzenia mobilne i polega na CSS, aby wizualnie go zmniejszyć, marnując przepustowość i spowalniając ładowanie stron mobilnych.

Zakodowany na sztywno tekst bez tłumaczeń

PrestaShop posiada rozbudowany system tłumaczeń, który pozwala tłumaczyć każdy ciąg znaków wyświetlany użytkownikowi na dowolny język. Prawidłowo zbudowany motyw używa tego systemu dla każdego widocznego tekstu, od etykiet przycisków po komunikaty błędów po tekst nagłówków. Składnia Smarty wygląda tak: {l s='Add to cart' d='Shop.Theme.Actions'}, co udostępnia ciąg znaków w interfejsie tłumaczeń panelu administracyjnego.

Źle zbudowane motywy kodują tekst na sztywno bezpośrednio w swoich szablonach. Zamiast używać funkcji tłumaczenia, piszą zwykły HTML jak <button>Add to cart</button>. Oznacza to, że tekst nie może być przetłumaczony, co sprawia, że motyw jest bezużyteczny dla sklepów wielojęzycznych i problematyczny nawet dla sklepów jednojęzycznych, które chcą dostosować etykiety przycisków lub komunikaty.

Aby to sprawdzić, spójrz na demo motywu i zanotuj konkretne ciągi tekstowe, takie jak etykiety przycisków, nagłówki sekcji i tekst zastępczy. Następnie spróbuj znaleźć pliki tłumaczeń motywu. Dobrze zbudowany motyw zawiera katalogi tłumaczeń lub konsekwentnie używa domen tłumaczeń PrestaShop. Jeśli dokumentacja motywu nie wspomina o tłumaczeniach ani wsparciu wielojęzycznym, to powód do niepokoju. Jeśli masz dostęp do jakichkolwiek plików szablonów motywu (niektóre rynki udostępniają podglądy plików), wyszukaj ciągi zwykłego tekstu, które powinny być tłumaczalne. Każdy ciąg znaków widoczny dla użytkownika powinien być opakowany w wywołanie funkcji tłumaczenia.

Konflikty jQuery i problemy z JavaScript

PrestaShop zawiera jQuery jako część swojego podstawowego frameworka front-end. Dobrze zbudowany motyw współpracuje z wersją jQuery dostarczaną przez PrestaShop. Źle zbudowany motyw albo pakuje własną wersję jQuery (tworząc konflikty), ładuje dodatkowe biblioteki JavaScript duplikujące funkcjonalność już dostępną w rdzeniu, albo używa technik JavaScript niekompatybilnych z innymi modułami.

Konflikty jQuery to jeden z najczęstszych problemów z motywami firm trzecich. Kiedy motyw ładuje własną wersję jQuery, może zepsuć moduły zależne od wersji rdzeniowej. Objawy obejmują moduły, które cicho przestają działać (przyciski, które nie reagują na kliknięcia, formularze, które się nie wysyłają, funkcje AJAX, które nie działają), błędy JavaScript w konsoli przeglądarki oraz funkcje, które działają w demo motywu (gdzie nie ma zainstalowanych innych modułów), ale psują się w prawdziwym sklepie.

Aby sprawdzić konflikty jQuery przed zakupem, otwórz demo motywu, otwórz konsolę przeglądarki (F12, karta Konsola) i wpisz jQuery.fn.jquery, aby zobaczyć, która wersja jest załadowana. Następnie sprawdź w karcie Sieć (Network), czy ładowane są wielokrotne pliki jQuery. Jeśli widzisz więcej niż jeden plik jQuery lub jeśli wersja nie odpowiada tej, którą dostarcza PrestaShop (jQuery 3.x dla PrestaShop 1.7 i 8.x), motyw prawdopodobnie będzie powodować konflikty.

Sprawdź również, czy w konsoli nie ma błędów JavaScript podczas nawigowania po demo. Błędy na stronie demo, gdzie warunki są kontrolowane i zainstalowane są tylko domyślne moduły, to bardzo silny sygnał ostrzegawczy. Jeśli motyw nie może działać czysto we własnym środowisku demo, zdecydowanie będzie miał problemy w prawdziwym sklepie z dodatkowymi modułami.

Brak obsługi hooków

System hooków PrestaShop to podstawowy mechanizm integracji modułów ze sklepem. Hooki to predefiniowane punkty w szablonach motywu, w których moduły mogą wstawiać swoją treść. Standardowe hooki PrestaShop obejmują displayHeader, displayTop, displayHome, displayFooter, displayLeftColumn, displayRightColumn, displayProductAdditionalInfo i wiele innych.

Dobrze zbudowany motyw obsługuje wszystkie standardowe hooki PrestaShop, zapewniając, że każdy moduł zaprojektowany dla PrestaShop będzie działał prawidłowo. Źle zbudowany motyw usuwa hooki, aby uprościć layout, zastępuje standardowe hooki własnymi proprietarnymi hookami lub pozycjonuje hooki w miejscach, które psują oczekiwany układ.

Brakujące hooki oznaczają, że moduły, które zainstalujesz, nie będą miały gdzie wyświetlić swojej treści. Moduł płatności, który polega na displayPaymentReturn, nie pokaże komunikatu potwierdzającego. Moduł personalizacji produktu używający displayProductAdditionalInfo będzie niewidoczny na stronach produktów. Skończysz modyfikując szablony motywu ręcznie, aby dodać brakujące hooki (co psuje się przy aktualizacjach motywu) lub wybierając moduły zaprojektowane specjalnie dla tego motywu (co ogranicza Twoje opcje i tworzy uzależnienie od dostawcy).

Aby sprawdzić obsługę hooków, poszukaj w dokumentacji motywu listy obsługiwanych hooków. Jeśli taka lista nie istnieje, to samo w sobie jest powodem do niepokoju. W demo zainstaluj lub wyobraź sobie instalację modułu używającego standardowego hooka i sprawdź, czy layout motywu go obsługuje. Możesz również zbadać pliki szablonów motywu, jeśli są dostępne, wyszukując {hook h='displayHome'} i inne standardowe nazwy hooków.

Brak obsługi motywów potomnych

PrestaShop 1.7 i nowsze wersje obsługują motywy potomne (child themes), które pozwalają dostosowywać motyw bez modyfikowania jego oryginalnych plików. Motyw potomny dziedziczy wszystko z motywu nadrzędnego i zawiera tylko pliki, które chcesz nadpisać. Gdy motyw nadrzędny jest aktualizowany, Twoje dostosowania pozostają nienaruszone, ponieważ znajdują się w osobnych plikach.

Motyw, który nie obsługuje motywów potomnych, zmusza Cię do dokonywania wszystkich dostosowań bezpośrednio w plikach motywu. Za każdym razem, gdy deweloper motywu wydaje aktualizację, stajesz przed wyborem: pominąć aktualizację i stracić poprawki błędów oraz nowe funkcje, lub zastosować aktualizację i stracić wszystkie swoje dostosowania. Żadna z tych opcji nie jest akceptowalna dla sklepu produkcyjnego.

Sprawdź dokumentację motywu i jego plik theme.yml pod kątem obsługi motywów potomnych. Plik theme.yml to centralny plik konfiguracyjny motywu PrestaShop i powinien zawierać pole parent lub dokumentację wyjaśniającą, jak utworzyć motyw potomny. Jeśli deweloper motywu nie wspomina o motywach potomnych w swojej dokumentacji, zapytaj go bezpośrednio przed zakupem. Deweloper, który nie obsługuje motywów potomnych, albo nie rozumie nowoczesnego rozwoju PrestaShop, albo nie dba o długoterminową utrzymywalność swojego produktu.

Słaba dostępność

Dostępność internetowa oznacza, że osoby z niepełnosprawnościami mogą korzystać z Twojego sklepu. Obejmuje to osoby używające czytników ekranowych, osoby nawigujące klawiaturą zamiast myszki, osoby słabowidzące korzystające z powiększenia ekranu oraz osoby z daltonizmem. Dostępność jest nie tylko ważna etycznie. W wielu krajach, w tym w Unii Europejskiej i Stanach Zjednoczonych, strony e-commerce są zobowiązane prawem do spełniania standardów dostępności (WCAG 2.1 Poziom AA).

Źle zbudowany motyw całkowicie ignoruje dostępność. Typowe błędy dostępności obejmują obrazy bez atrybutów alt (czytniki ekranowe nie mogą ich opisać), pola formularzy bez powiązanych etykiet (czytniki ekranowe nie mogą powiedzieć użytkownikowi, co wpisać), niewystarczający kontrast kolorów między tekstem a tłem (osoby słabowidzące nie mogą przeczytać tekstu), elementy interaktywne niedostępne lub nieaktywowalne za pomocą klawiatury, wskaźniki fokusa usunięte ze względów estetycznych (użytkownicy klawiatury nie widzą, gdzie się znajdują na stronie) oraz atrybuty ARIA użyte nieprawidłowo lub w ogóle nieużyte.

Aby przeprowadzić podstawową kontrolę dostępności demo motywu, spróbuj nawigować po stronie używając wyłącznie klawiatury (Tab do przechodzenia między elementami, Enter do aktywowania przycisków i linków). Jeśli nie możesz dotrzeć do wszystkich interaktywnych elementów lub jeśli nie ma widocznego wskaźnika fokusa pokazującego, który element jest aktualnie wybrany, motyw nie przechodzi podstawowego testu dostępności. Uruchom również stronę przez darmowe narzędzie, takie jak WAVE Web Accessibility Evaluation Tool lub użyj audytu dostępności Lighthouse w Chrome DevTools (przejdź do karty Lighthouse, zaznacz tylko Dostępność i uruchom audyt). Dobrze zbudowany motyw powinien uzyskać co najmniej 80 na 100 w audycie dostępności Lighthouse.

Rozdęte rozmiary plików

Rozmiar plików motywu bezpośrednio wpływa na to, jak szybko ładuje się Twój sklep. Rozdęte motywy zawierają niepotrzebne zasoby, niezoptymalizowane obrazy, nieminifikowane CSS i JavaScript oraz całe biblioteki używane do jednej funkcji. Często można znaleźć motywy, które dostarczają kilka megabajtów CSS (gdy faktycznie używany CSS to ułamek tego), wiele czcionek ikonowych ładowanych w całości, gdy używana jest tylko garstka ikon, nieskompresowane obrazy demo pozostawione w katalogu motywu oraz biblioteki JavaScript jak Moment.js lub Lodash dołączone w całości, gdy potrzebna jest tylko jedna lub dwie funkcje.

Aby ocenić rozmiary plików, sprawdź łączny rozmiar transferu w karcie Sieć (Network) Chrome DevTools podczas ładowania demo motywu. Dobrze zoptymalizowany motyw powinien ładować mniej niż 1 MB łącznych zasobów na typowej stronie (z wyłączeniem obrazów produktów, które są zmienne). Jeśli demo motywu ładuje 2 do 3 MB lub więcej CSS, JavaScript i czcionek, motyw jest rozdęty. Zwróć szczególną uwagę na rozmiary plików CSS. Motywy PrestaShop używające Bootstrap lub podobnego frameworka powinny zawierać tylko te komponenty Bootstrap, których faktycznie używają, a nie całą bibliotekę. Plik CSS o rozmiarze 500 KB na jednej stronie jest niemal na pewno rozdęty.

Sprawdź również, czy motyw minifikuje swoje produkcyjne CSS i JavaScript. Minifikacja usuwa białe znaki, komentarze i zbędne znaki, zazwyczaj zmniejszając rozmiary plików o 20 do 40 procent. Wyświetl źródło plików CSS w demo. Jeśli zawierają czytelny, sformatowany kod z komentarzami, nie są minifikowane, co sugeruje, że deweloper nie wdrożył prawidłowego procesu budowania.

Jak ocenić motyw przed zakupem

Sprawdzenie theme.yml

Plik theme.yml to serce konfiguracyjne motywu PrestaShop. Definiuje nazwę motywu, wersję, kompatybilność, obsługiwane hooki, konfigurację layoutu i zarządzanie zasobami. Szukaj jasnej deklaracji kompatybilności z wersją PrestaShop, listy zarejestrowanych hooków i przypisanych do nich modułów, definicji layoutu dla różnych typów stron (produkt, kategoria, CMS, checkout) oraz deklaracji zasobów określających, które pliki ładują się globalnie, a które na konkretnych stronach. Jeśli plik theme.yml jest minimalny lub brakuje w nim kluczowych sekcji, motyw został zbudowany bez przestrzegania wytycznych rozwoju motywów PrestaShop.

Testowanie z trybem debugowania

Jeśli możesz zainstalować motyw w środowisku testowym, natychmiast włącz tryb debugowania PrestaShop, ustawiając _PS_MODE_DEV_ na true w config/defines.inc.php. To ujawnia błędy PHP, ostrzeżenia i powiadomienia ukryte w trybie produkcyjnym. Dobrze zbudowany motyw powinien generować zero błędów i minimalne ostrzeżenia. Jeśli tryb debugowania produkuje zalew błędów, motyw ma problemy z jakością kodu, które spowodują problemy na produkcji.

Sprawdzenie historii dewelopera

Przeszukaj informacje o deweloperze przed zakupem. Sprawdź, ile motywów opublikował, jak niedawno jego motywy były aktualizowane i co mówią recenzje. Zwróć uwagę na negatywne recenzje wspominające o błędach, zepsutych funkcjach po aktualizacjach lub niereagującym wsparciu. Szczegółowy changelog dokumentujący poprawki błędów i aktualizacje kompatybilności wskazuje na aktywną konserwację. Brak changelogu sugeruje, że motyw może być porzucony po początkowej sprzedaży.

Weryfikacja kompatybilności

Zawsze weryfikuj, że motyw wyraźnie deklaruje kompatybilność z Twoją dokładną wersją PrestaShop. Sformułowania takie jak „kompatybilny z PrestaShop 1.7 i nowszymi" są zbyt ogólnikowe. Potrzebujesz konkretnych numerów wersji wymienionych jako przetestowane. Zweryfikuj, sprawdzając, kiedy motyw był ostatnio aktualizowany. Jeśli motyw deklaruje kompatybilność z PrestaShop 8.1, ale był ostatnio aktualizowany przed wydaniem tej wersji, twierdzenie jest w najlepszym razie niezweryfikowane.

Prawdziwy koszt złego motywu

Źle zbudowany motyw ma konkretne, mierzalne koszty. Problemy z wydajnością obniżają Twój wynik PageSpeed, wpływając na pozycje i konwersje (każda dodatkowa sekunda czasu ładowania zmniejsza konwersje o 7 do 10 procent). Brak obsługi hooków wymusza płatną pracę dewelopera dla każdego nowego modułu. Słaba dostępność tworzy odpowiedzialność prawną. Brak obsługi motywów potomnych zamienia każdą aktualizację w ręczne łączenie zmian. Konflikty jQuery psują moduły, powodując utraconą sprzedaż z powodu zepsutych przycisków dodawania do koszyka i niedziałających formularzy płatności.

Oceniając motywy, weź pod uwagę całkowity koszt posiadania. Tani motyw wymagający setek euro pracy dewelopera jest znacznie droższy niż droższy motyw, który działa poprawnie od początku.

Lista kontrolna podsumowująca

Przed zakupem jakiegokolwiek motywu PrestaShop przejdź przez tę listę kontrolną. Otwórz demo i sprawdź kartę Sieć (Network) pod kątem nadmiernych żądań HTTP (powyżej 50 budzi niepokój, powyżej 80 to sygnał ostrzegawczy). Zbadaj elementy pod kątem stylów inline, które powinny być w klasach CSS. Przetestuj cały proces zakupu na prawdziwym urządzeniu mobilnym. Poszukaj zakodowanego na sztywno tekstu, który nie może być przetłumaczony. Sprawdź konsolę przeglądarki pod kątem błędów JavaScript i wielokrotnych wersji jQuery. Zweryfikuj, że standardowe hooki PrestaShop są obecne w szablonach. Potwierdź, że tworzenie motywu potomnego jest udokumentowane i wspierane. Uruchom audyt dostępności Lighthouse i sprawdź nawigację klawiaturą. Przejrzyj łączne rozmiary transferu CSS, JavaScript i czcionek. Przeczytaj plik theme.yml pod kątem prawidłowej struktury konfiguracji. Sprawdź historię aktualizacji i responsywność wsparcia dewelopera. Zweryfikuj wyraźną kompatybilność z Twoją wersją PrestaShop.

Motyw, który przechodzi wszystkie te testy, nie jest gwarantowaną perfekcją, ale przeszedł podstawowy próg jakości oddzielający profesjonalną pracę od amatorskiego rozwoju. Motyw, który nie przechodzi wielu testów, sprawi Ci problemy. Czas poświęcony na ocenę przed zakupem oszczędza znacznie więcej czasu, pieniędzy i frustracji niż radzenie sobie z konsekwencjami źle zbudowanego motywu po tym, jak już prowadzi Twój sklep.

Przeczytaj pełną odpowiedź

Ukryty koszt nadmiaru czcionek w motywach PrestaShop

Otwórz DevTools w przeglądarce, przejdź do karty Sieć (Network), przefiltruj po "Font" i przeładuj swój sklep PrestaShop. Jeśli widzisz więcej niż trzy lub cztery pliki czcionek do pobrania, masz problem, który po cichu kosztuje Cię klientów. Większość motywów PrestaShop jest dostarczana z oszałamiającą liczbą zasobów czcionek, których przeciętny sklep nigdy nie używa, a każdy z nich opóźnia moment, w którym Twoi odwiedzający mogą faktycznie przeczytać treść.

Nadmiar czcionek to jeden z najbardziej pomijanych problemów wydajnościowych w PrestaShop. Właściciele sklepów spędzają godziny na optymalizacji obrazów, włączaniu CCC (Combine, Compress, Cache) i dostrajaniu konfiguracji serwera, a jednocześnie ignorują fakt, że ich motyw ładuje 800KB lub więcej plików czcionek przy każdym załadowaniu strony. Ten artykuł wyjaśnia dokładnie, dlaczego tak się dzieje, jak przeprowadzić audyt ładowania czcionek i co z tym zrobić.

Jak motywy PrestaShop dołączają czcionki

Motywy PrestaShop są dystrybuowane jako samodzielne pakiety. Kiedy deweloper motywu buduje motyw, chce, aby działał od razu po instalacji dla jak największej liczby sklepów. Oznacza to, że dołącza każdy wariant czcionki i bibliotekę ikon, które mogą się hipotetycznie przydać. Rezultatem jest motyw dostarczany ze znacznie większą liczbą zasobów czcionek, niż jakikolwiek pojedynczy sklep kiedykolwiek użyje.

Typowy motyw PrestaShop zawiera trzy kategorie czcionek. Po pierwsze, czcionki wyświetlane używane do nagłówków, tekstu głównego i elementów interfejsu. Są to zazwyczaj czcionki Google Fonts, takie jak Roboto, Open Sans, Lato lub Montserrat. Po drugie, czcionki ikonowe, takie jak FontAwesome, Material Icons lub zestawy ikon specyficzne dla motywu. Po trzecie, czcionki zapasowe lub dekoracyjne, które motyw używa do specyficznych komponentów, takich jak banery, odznaki lub sekcje promocyjne.

Problem się potęguje, ponieważ każda rodzina czcionek zazwyczaj jest dostarczana w wielu grubościach i stylach. Pojedyncza czcionka jak Roboto może zawierać Regular (400), Medium (500), Bold (700) i ich warianty kursywne, każdy jako osobny plik WOFF2. Pomnóż to przez dwie lub trzy rodziny czcionek plus bibliotekę ikon, a szybko dojdziesz do 12 do 15 indywidualnych plików czcionek ładowanych na każdej stronie.

Problem z FontAwesome

FontAwesome zasługuje na osobną sekcję, ponieważ jest największym sprawcą problemów wydajnościowych związanych z czcionkami w motywach PrestaShop. Pełna biblioteka FontAwesome 5 waży około 150KB za sam plik webfont, plus kolejne 60-80KB za CSS. FontAwesome 6 jest jeszcze większy. Biblioteka zawiera ponad 1600 ikon, ale przeciętny sklep PrestaShop używa może 20 do 30 z nich.

Oznacza to, że zmuszasz każdego odwiedzającego do pobrania ponad 200KB danych czcionek i CSS tylko po to, żebyś mógł wyświetlić ikonę koszyka, lupę wyszukiwania i kilka logotypów mediów społecznościowych. To absurdalny kompromis, który ma miejsce, ponieważ deweloperzy motywów uważają za łatwiejsze dołączenie całej biblioteki niż tworzenie podzbioru dla konkretnych potrzeb każdego sklepu.

Motyw Classic w PrestaShop 1.7 i 8.x zawiera FontAwesome 4.7, który jest nieco mniejszy, ale nadal zawiera setki ikon, których nigdy nie użyjesz. Motyw Hummingbird w PrestaShop 8.x odszedł od FontAwesome na rzecz ikon SVG, co jest znaczącą poprawą, ale wiele motywów i modułów firm trzecich nadal polega na FontAwesome i ładuje własną kopię na wierzchu tego, co dostarcza motyw.

Google Fonts i podatek wydajnościowy

Google Fonts to najpopularniejsza usługa czcionek webowych, a motywy PrestaShop intensywnie z niej korzystają. Jednak ładowanie Google Fonts w domyślny sposób tworzy łańcuch żądań zabijających wydajność.

Kiedy Twój motyw ładuje Google Fonts przez standardowy tag link, przeglądarka musi najpierw połączyć się z fonts.googleapis.com, aby pobrać plik CSS. Ten plik CSS następnie informuje przeglądarkę, aby pobrała właściwe pliki czcionek z fonts.gstatic.com. Każde z tych połączeń wymaga rozwiązywania DNS, uzgadniania TCP i negocjacji TLS. Na połączeniach mobilnych ten łańcuch może dodać 300-500ms opóźnienia, zanim pojedynczy znak tekstu wyrenderuje się na ekranie.

Co gorsza, CSS Google Fonts używa deskryptora font-display ustawionego na "swap" domyślnie od 2019 roku, ale wiele starszych motywów nadal odwołuje się do adresów URL CSS Google Fonts sprzed tej zmiany. Bez font-display: swap przeglądarka może ukryć cały tekst na stronie do momentu pobrania czcionki, tworząc przerażający Flash of Invisible Text (FOIT), gdzie odwiedzający widzą pustą stronę przez jedną do trzech sekund.

Istnieje również kwestia prywatności. Ładowanie czcionek z CDN Google oznacza, że Google otrzymuje informacje o każdym odwiedzającym Twój sklep, w tym jego adres IP i odwiedzane strony. Zgodnie z RODO wymaga to wyraźnej zgody, a niemiecki sąd orzekł w styczniu 2022, że używanie Google Fonts bez zgody narusza RODO, co skutkuje karami.

Jak przeprowadzić audyt ładowania czcionek

Zanim będziesz mógł naprawić problem, musisz dokładnie zrozumieć, jakie czcionki ładuje Twój motyw i które z nich faktycznie potrzebujesz. Oto systematyczne podejście.

Otwórz Chrome DevTools (F12), przejdź do karty Sieć (Network) i zaznacz pole "Wyłącz cache" (Disable cache). Przeładuj stronę i przefiltruj po "Font" w pasku filtrów. Zobaczysz każdy plik czcionki pobierany przez przeglądarkę. Zanotuj nazwy plików, rozmiary i kolumnę inicjatora, która informuje, który plik CSS zażądał każdej czcionki.

Następnie użyj karty Pokrycie (Coverage) w DevTools (Ctrl+Shift+P, następnie wpisz "Coverage"). Rozpocznij nagrywanie pokrycia i nawiguj po swoim sklepie. Karta Pokrycie pokazuje dokładnie, ile każdego pliku CSS jest faktycznie używane. Dla CSS FontAwesome zazwyczaj zobaczysz 90% lub więcej oznaczonych jako nieużywane.

Możesz również użyć audytu Lighthouse w DevTools. Uruchom audyt wydajności i poszukaj rekomendacji "Zmniejsz nieużywane CSS" (Reduce unused CSS) i "Upewnij się, że tekst pozostaje widoczny podczas ładowania czcionek webowych" (Ensure text remains visible during webfont load). Lighthouse specyficznie wskaże problemy wydajnościowe związane z czcionkami.

Dla bardziej dokładnej analizy użyj WebPageTest (webpagetest.org), aby uruchomić test z połączenia mobilnego. Spójrz na wykres kaskadowy (waterfall) i znajdź żądania czcionek. Zanotuj, kiedy zaczynają się ładować w stosunku do innych zasobów i ile czasu zajmują. Na połączeniu 3G opóźnienia ładowania czcionek stają się boleśnie oczywiste.

Usuwanie nieużywanych czcionek krok po kroku

Kiedy już wiesz, jakie czcionki ładuje Twój motyw i które faktycznie potrzebujesz, czas usunąć nadmiar. Podejście różni się w zależności od architektury Twojego motywu.

Dla motywów, które ładują Google Fonts przez tag link w szablonie nagłówka, znajdź plik szablonu zawierający odniesienie do Google Fonts. W większości motywów jest to templates/layout/head.tpl lub podobny plik. Jeśli używasz motywu potomnego, skopiuj ten szablon do katalogu motywu potomnego przed edycją. Usuń lub zmodyfikuj link Google Fonts, aby zawierał tylko grubości i rodziny, których faktycznie używasz.

Dla FontAwesome sprawdź, czy Twój motyw ładuje go przez plik CSS w katalogu assets/css, czy przez link CDN. Jeśli jest to plik lokalny, masz dwie opcje. Możesz zastąpić pełny pakiet FontAwesome podzbiorem zawierającym tylko ikony, których używasz, lub możesz całkowicie zastąpić użycie czcionek ikonowych inline SVG.

Aby stworzyć podzbiór FontAwesome, użyj narzędzia takiego jak IcoMoon (icomoon.io) lub Fontello (fontello.com). Narzędzia te pozwalają wybrać tylko konkretne ikony, których potrzebujesz, i wygenerować niestandardowy plik czcionki, który może mieć 5-10KB zamiast 150KB. Będziesz musiał zaktualizować nazwy klas CSS, jeśli narzędzie generuje inne, ale większość pozwala zachować oryginalne nazwy klas FontAwesome.

Dla Google Fonts sprawdź każdy plik CSS w swoim motywie pod kątem deklaracji @font-face. Deweloperzy motywów czasami importują czcionki bezpośrednio w CSS zamiast przez szablon nagłówka. Użyj wyszukiwania DevTools (Ctrl+Shift+F), aby przeszukać wszystkie załadowane zasoby pod kątem "@font-face" i "fonts.googleapis.com".

Implementacja font-display: swap

Jeśli zachowujesz jakiekolwiek czcionki webowe, upewnij się absolutnie, że używają deskryptora font-display: swap. To informuje przeglądarkę, aby natychmiast wyświetliła tekst używając zapasowej czcionki systemowej, podczas gdy czcionka webowa pobiera się w tle. Gdy czcionka webowa jest gotowa, przeglądarka ją podmienia. To eliminuje FOIT i zapewnia, że Twoja treść jest czytelna natychmiast.

Dla Google Fonts ładowanych przez CDN dodaj parametr display=swap do adresu URL. Na przykład zmień fonts.googleapis.com/css2?family=Roboto:wght@400;700 na fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap. Zauważ, że Google dodał ten parametr domyślnie w 2019 roku, ale wiele motywów PrestaShop nadal używa starszych formatów adresów URL.

Dla czcionek hostowanych samodzielnie z deklaracjami @font-face w CSS dodaj font-display: swap do każdego bloku @font-face. Otwórz plik CSS motywu zawierający reguły @font-face i dodaj tę właściwość. Umieszcza się ją wewnątrz bloku @font-face obok font-family, src i font-weight.

Pamiętaj, że font-display: swap może powodować Flash of Unstyled Text (FOUT), gdzie tekst krótko pojawia się w czcionce zapasowej przed przełączeniem na czcionkę webową. Jest to znacznie lepsze doświadczenie niż niewidoczny tekst, ale możesz zminimalizować wizualne szarpnięcie, wybierając czcionki zapasowe, które ściśle odpowiadają metryce Twojej czcionki webowej. Właściwości CSS size-adjust, ascent-override i descent-override pomagają w tym.

Samodzielne hostowanie czcionek vs ładowanie z CDN

Samodzielne hostowanie czcionek zamiast ładowania z CDN Google oferuje kilka znaczących zalet dla sklepów PrestaShop.

Wydajność poprawia się, ponieważ eliminujesz dodatkowe wyszukiwanie DNS i połączenie z serwerami Google. Twoje czcionki ładują się z tej samej domeny co inne zasoby, co oznacza, że przeglądarka może ponownie wykorzystać istniejące połączenia. Dzięki HTTP/2 lub HTTP/3 wszystkie pliki czcionek mogą pobierać się jednocześnie przez jedno połączenie.

Zgodność z przepisami o prywatności staje się prostsza, ponieważ dane odwiedzających nie są już wysyłane do Google. To całkowicie eliminuje problem z RODO i nie musisz dodawać Google Fonts do swojego banera zgody na pliki cookie.

Niezawodność poprawia się, ponieważ nie jesteś zależny od zewnętrznej usługi. Jeśli CDN Google ma problem (rzadko, ale się zdarza), Twoje czcionki nadal się ładują.

Aby samodzielnie hostować Google Fonts, użyj narzędzia google-webfonts-helper (gwfh.mranftl.com/fonts), które zapewnia prosty interfejs do pobierania dowolnej czcionki Google w formacie WOFF2 z prawidłowym CSS @font-face. Pobierz tylko grubości i style, których potrzebujesz, umieść pliki w katalogu assets/fonts Twojego motywu i dodaj CSS @font-face do arkusza stylów motywu.

Jedyną potencjalną wadą samodzielnego hostowania jest utrata możliwości trafienia w cache, jeśli odwiedzający załadował już tę samą czcionkę z CDN Google na innej stronie. Jednak przeglądarki w dużej mierze wyeliminowały to międzystronowe cachowanie ze względów prywatności od 2020 roku, więc ta zaleta w praktyce już nie istnieje.

Podzbiory czcionek: Opcja nuklearna

Tworzenie podzbiorów czcionek oznacza usuwanie znaków, których nie potrzebujesz, z pliku czcionki. Typowa łacińska czcionka webowa zawiera znaki dla kilkudziesięciu języków, z których wielu Twój sklep nie używa. Tworząc podzbiór tylko do znaków, których Twój sklep potrzebuje, możesz zmniejszyć rozmiary plików czcionek o 50-70%.

Narzędzie pyftsubset z biblioteki Python fonttools to najbardziej niezawodny sposób tworzenia podzbiorów czcionek. Możesz określić dokładnie, które zakresy Unicode mają być uwzględnione. Dla sklepu działającego tylko po angielsku możesz stworzyć podzbiór ograniczony do Basic Latin (U+0020-007F) plus Latin-1 Supplement (U+00A0-00FF) dla symboli walut i znaków diakrytycznych.

Dla sklepów działających w wielu językach musisz być ostrożniejszy. Uwzględnij zakresy Unicode dla wszystkich języków obsługiwanych przez Twój sklep. CSS Google Fonts faktycznie robi to automatycznie za pomocą deskryptorów unicode-range, ładując podzbiory znaków na żądanie, ale czcionki hostowane samodzielnie wymagają ręcznego tworzenia podzbiorów.

Prostszym podejściem jest używanie wyłącznie formatu WOFF2 i porzucenie wsparcia dla starszych formatów. WOFF2 używa kompresji Brotli i tworzy pliki o 30% mniejsze niż WOFF. Każda nowoczesna przeglądarka obsługuje WOFF2, więc chyba że musisz obsługiwać Internet Explorer 11, nie ma powodu, aby dołączać formaty WOFF, TTF czy EOT. Wiele motywów PrestaShop nadal dostarcza wszystkie cztery formaty ze względu na kompatybilność wsteczną, która nie jest już potrzebna.

Stosy czcionek systemowych: Alternatywa za zerowym kosztem

Najbardziej radykalnym rozwiązaniem problemu wydajności czcionek jest nieużywanie czcionek webowych w ogóle. Nowoczesne systemy operacyjne dostarczają wysokiej jakości czcionki, które wyglądają doskonale na ekranie. Stos czcionek systemowych używa czcionki dostarczanej przez system operacyjny, co oznacza zero plików czcionek do pobrania i natychmiastowe renderowanie tekstu.

Nowoczesny stos czcionek systemowych wygląda tak: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif. Daje to San Francisco na urządzeniach Apple, Segoe UI na Windows i Roboto na Android. Wszystkie to czyste, nowoczesne, dobrze czytelne czcionki bezszeryfowe.

GitHub, Bootstrap 5 i wiele wysoko wydajnych stron internetowych używa stosów czcionek systemowych. Różnica wizualna między czcionką systemową a czcionką Google Fonts jak Open Sans czy Roboto jest minimalna, szczególnie dla tekstu głównego. Większość Twoich klientów nie zauważy ani nie będzie dbać o to, czy Twój sklep używa Roboto załadowanego z serwera, czy Roboto już zainstalowanego na ich telefonie z Androidem.

Aby zaimplementować stos czcionek systemowych w PrestaShop, musisz zmodyfikować CSS motywu, aby zastąpić istniejące deklaracje font-family, usunąć reguły @font-face i tagi link Google Fonts oraz usunąć pliki czcionek z katalogu assets motywu. Jeśli używasz motywu potomnego, możesz nadpisać deklaracje czcionek motywu nadrzędnego bez modyfikowania plików motywu nadrzędnego.

Co z czcionkami ikonowymi?

Jeśli usuniesz FontAwesome lub inną czcionkę ikonową, potrzebujesz alternatywy do wyświetlania ikon. Najlepszym nowoczesnym podejściem jest inline SVG. Ikony SVG renderują się ostro w każdym rozmiarze, mogą być stylowane za pomocą CSS i dodają wagę tylko za konkretne używane ikony, zamiast ładować całą bibliotekę ikon.

Motyw Hummingbird PrestaShop używa ikon SVG natywnie, co jest jednym z powodów jego lepszej wydajności w porównaniu do Classic. Jeśli Twój motyw używa FontAwesome, możesz zastąpić poszczególne ikony za pomocą SVG ze źródeł takich jak Heroicons, Feather Icons, a nawet własne pliki SVG FontAwesome (które są dostępne oddzielnie od wersji czcionkowej).

Dla sklepu PrestaShop zazwyczaj potrzebujesz mniej niż 30 unikalnych ikon: koszyk, wyszukiwanie, konto użytkownika, serce/lista życzeń, strzałki, logotypy mediów społecznościowych i kilka ikon specyficznych dla kategorii. Jako inline SVG mogą one łącznie ważyć 10-15KB, w porównaniu do 150-200KB za pełną czcionkę FontAwesome i CSS.

Mierzenie wpływu

Po usunięciu nieużywanych czcionek zmierz poprawę. Uruchom Lighthouse przed i po, porównując wynik Wydajności (Performance), First Contentful Paint (FCP) i Largest Contentful Paint (LCP). Optymalizacja czcionek zazwyczaj poprawia FCP o 200-500ms na połączeniach mobilnych.

Sprawdź łączny rozmiar transferu w karcie Sieć (Network) DevTools. Dobrze zoptymalizowany sklep PrestaShop powinien transferować mniej niż 50KB danych czcionek łącznie. Jeśli przejdziesz na czcionki systemowe, ta liczba spada do zera.

Zweryfikuj również, że Twój sklep nadal wygląda poprawnie. Sprawdź każdy typ strony: stronę główną, kategorię, produkt, koszyk i zamówienie. Niektóre motywy używają specyficznych czcionek dla specyficznych elementów i usunięcie czcionki może spowodować nieoczekiwane renderowanie z czcionką zapasową. Zawsze dokładnie testuj przed wdrożeniem zmian czcionek na produkcji.

Podsumowanie: Lista kontrolna ładowania czcionek

Przeprowadź audyt aktualnego ładowania czcionek za pomocą karty Sieć (Network) DevTools przefiltrowanej po czcionkach. Zidentyfikuj, które czcionki są faktycznie używane, sprawdzając pokrycie CSS. Usuń wszystkie rodziny lub grubości Google Fonts, których nie używasz. Zastąp pełne czcionki ikonowe wersjami podzbiorów lub inline SVG. Dodaj font-display: swap do wszystkich pozostałych deklaracji @font-face. Hostuj czcionki samodzielnie zamiast ładować z CDN Google. Rozważ użycie wyłącznie WOFF2, aby wyeliminować starsze, większe formaty. Oceń, czy czcionki systemowe mogłyby całkowicie zastąpić Twoje czcionki webowe. Zmierz przed i po za pomocą Lighthouse i WebPageTest. Cel jest prosty: ładuj tylko to, czego potrzebujesz, ładuj to efektywnie i nigdy nie zmuszaj odwiedzających do czekania na czcionki, których nie widzą.

Przeczytaj pełną odpowiedź

Dwa oficjalne motywy, dwie różne filozofie

PrestaShop jest dostarczany z dwoma oficjalnymi motywami: Classic i Hummingbird. Classic jest domyślnym motywem od czasu wydania PrestaShop 1.7 w 2016 roku. Hummingbird pojawił się wraz z PrestaShop 8.x jako nowoczesna alternatywa zaprojektowana z myślą o wydajności i przyszłościowości. Wybór między nimi to nie tylko kwestia tego, który lepiej wygląda. Oba motywy reprezentują fundamentalnie różne podejścia do architektury front-end, a Twój wybór wpływa na wydajność, kompatybilność modułów, nakład pracy przy dostosowywaniu i długoterminową utrzymywalność.

Ten artykuł zapewnia dokładne porównanie oparte na architekturze, rzeczywistych danych wydajnościowych, praktycznych aspektach i konkretnych sytuacjach, w których każdy motyw ma sens. Niezależnie od tego, czy zaczynasz nowy sklep, czy rozważasz migrację, pomoże Ci to podjąć świadomą decyzję.

Architektura: Co się zmieniło i dlaczego

Classic został zbudowany na Bootstrap 4, jQuery i szablonach Smarty. Stosuje tradycyjne podejście renderowania po stronie serwera, gdzie serwer generuje pełne strony HTML i wysyła je do przeglądarki. JavaScript jest używany głównie do elementów interaktywnych, takich jak koszyk, strona produktu i proces zamawiania. CSS jest kompilowany z plików Sass i dostarczany jako jeden duży arkusz stylów.

Hummingbird został zbudowany jako gruntowne przemodelowanie od podstaw. Używa Bootstrap 5, rezygnuje z jQuery na rzecz natywnego JavaScript i wprowadza architekturę komponentową. CSS jest bardziej modularny, JavaScript lżejszy, a ogólny rozmiar zasobów znacząco mniejszy.

Usunięcie jQuery to najbardziej konsekwencyjna zmiana architektoniczna. jQuery dodawał około 87KB (30KB po kompresji gzip) do każdego załadowania strony i zachęcał do stylu kodowania, w którym moduły swobodnie manipulowały DOM-em bez koordynacji. Hummingbird zastępuje jQuery nowoczesnymi API przeglądarek, takimi jak fetch, querySelector, classList i delegacja zdarzeń. Oznacza to, że sam motyw jest szybszy, ale moduły zależne od jQuery wymagają aktualizacji.

Bootstrap 5 przynosi własne zmiany. Rezygnuje z jQuery jako zależności (zgodnie z podejściem Hummingbird), używa właściwości niestandardowych CSS (zmiennych) dla łatwiejszego tematowania, usprawnia system siatki z lepszymi narzędziami responsywnymi i aktualizuje wzorce znaczników komponentów. Przejście z Bootstrap 4 na 5 wpływa na każdy niestandardowy CSS lub nadpisania szablonów odwołujące się do klas specyficznych dla Bootstrap.

Porównanie wydajności: Konkretne liczby

Wydajność to główny powód, dla którego PrestaShop stworzył Hummingbird, a liczby potwierdzają tę decyzję. Testowanie obu motywów na identycznej instalacji PrestaShop 8.1 z tymi samymi produktami, modułami i konfiguracją serwera ujawnia znaczące różnice.

Na typowej stronie produktu mierzonej za pomocą Lighthouse na symulowanym połączeniu mobilnym, Classic osiąga wynik wydajności w zakresie 45-55, podczas gdy Hummingbird osiąga 65-75. Szczegółowe metryki opowiadają jaśniejszą historię.

First Contentful Paint (FCP) poprawia się o około 0,5 do 1,0 sekundy z Hummingbird. Wynika to głównie z mniejszego ładunku CSS i braku blokującego renderowanie jQuery. Largest Contentful Paint (LCP) poprawia się o podobny margines, ponieważ krytyczna ścieżka renderowania jest krótsza.

Total Blocking Time (TBT) odnotowuje najbardziej dramatyczną poprawę. JavaScript Classic oparty na jQuery tworzy znaczące blokowanie głównego wątku, gdy przeglądarka parsuje i wykonuje bibliotekę plus wszystkie zależne od jQuery skrypty modułów. Podejście Hummingbird oparte na natywnym JavaScript zmniejsza TBT o 40-60% w typowych konfiguracjach.

Cumulative Layout Shift (CLS) jest w przybliżeniu równoważny między oboma motywami przy prawidłowej konfiguracji, ponieważ stabilność layoutu zależy bardziej od wymiarów obrazów i implementacji leniwego ładowania niż od wyboru frameworka.

Łączny rozmiar transferu opowiada kolejną część historii. Domyślna instalacja Classic transferuje około 350-450KB CSS i JavaScript przy pierwszym załadowaniu strony. Hummingbird obniża to do 200-300KB. Różnica kumuluje się w trakcie całej sesji przeglądania, gdy odwiedzający nawigują po Twoim sklepie.

Te liczby zakładają czystą instalację. W praktyce moduły firm trzecich często dodają własne CSS i JavaScript, co może zawęzić lub poszerzyć różnicę w zależności od tego, jak dobrze te moduły są zoptymalizowane dla każdego motywu.

Kompatybilność modułów: Słoń w pokoju

To miejsce, gdzie zalety Hummingbird wiążą się ze znaczącym zastrzeżeniem. Wiele modułów PrestaShop zostało zbudowanych z myślą o architekturze Classic. Są zależne od jQuery, używają wzorców znaczników Bootstrap 4 i zakładają konkretne struktury szablonów dostarczane przez Classic.

Kiedy instalujesz te moduły na Hummingbird, kilka rzeczy może się zepsuć. Funkcjonalność JavaScript opierająca się na jQuery przestanie działać po cichu lub wyrzuci błędy. Dialogi modalne, rozwijane menu i inne komponenty Bootstrap 4 mogą nie renderować się poprawnie ze zmienionymi znacznikami i nazwami klas Bootstrap 5. Nadpisania szablonów zakładające strukturę szablonów Classic nie zadziałają z reorganizowanymi szablonami Hummingbird.

Powaga tego problemu zależy od Twojego zestawu modułów. Rdzeniowe moduły PrestaShop są kompatybilne z oboma motywami. Dobrze utrzymywane moduły firm trzecich od aktywnych deweloperów zazwyczaj obsługują Hummingbird. Jednak starsze moduły, niszowe moduły lub moduły od deweloperów, którzy zaprzestali aktualizacji swoich produktów, mogą działać tylko z Classic.

Przed wyborem Hummingbird powinieneś przetestować każdy moduł, którego planujesz używać. Zainstaluj je w środowisku staging z aktywnym Hummingbird i dokładnie przetestuj każdą funkcję. Zwróć szczególną uwagę na funkcjonalność zależną od JavaScript, taką jak koszyki AJAX, pola personalizacji produktu, szybkie podglądy i kroki zamówienia.

Niektórzy deweloperzy modułów dostarczają osobne pliki szablonów dla Classic i Hummingbird. Kiedy widzisz katalogi takie jak views/templates/hook/classic/ i views/templates/hook/hummingbird/ w module, ten moduł wyraźnie obsługuje oba motywy. To złoty standard kompatybilności.

Smarty vs Twig: Kwestie przyszłościowości

PrestaShop ogłosił zamiar przejścia ze Smarty na Twig jako silnik szablonów dla panelu frontowego. To przejście jest dyskutowane od lat i jest częściowo zaimplementowane w panelu administracyjnym. Hummingbird jest zaprojektowany z myślą o tym przejściu, choć na dzień PrestaShop 8.x i 9.x oba motywy nadal używają Smarty do szablonów front-office.

Znaczenie tego dla Twojego wyboru motywu jest pośrednie, ale ważne. Struktura szablonów Hummingbird jest zorganizowana w sposób, który ułatwi ewentualną migrację ze Smarty na Twig. Jeśli zbudujesz rozbudowane dostosowania na strukturze szablonów Classic, możesz stanąć przed większym nakładem migracyjnym, gdy (nie "jeśli") PrestaShop zakończy przejście na Twig.

Niemniej jednak to przejście jest "wkrótce" od kilku lat. Podejmowanie decyzji dzisiaj wyłącznie na podstawie przyszłej zmiany silnika szablonów jest przedwczesne. Wybierz na podstawie aktualnych, konkretnych potrzeb i zaakceptuj, że pewien nakład migracyjny będzie wymagany niezależnie od wybranego motywu, gdy przejście na Twig nastąpi.

Podejście do dostosowywania

Dostosowywanie Classic jest dobrze udokumentowane i powszechnie rozumiane. Istnieją setki poradników, tysiące postów na forach i lata wiedzy społeczności na temat modyfikowania Classic. Motyw używa prostego Sass do stylowania, tradycyjnego jQuery do interaktywności i szablonów Smarty, które są łatwe do czytania i modyfikowania.

Dostosowywanie Hummingbird wymaga zaktualizowanych umiejętności. Musisz czuć się komfortowo z nowoczesnym CSS (właściwości niestandardowe, nowoczesne selektory, zapytania kontenerowe), natywnym JavaScript (bez podpórki jQuery) i podejściem Bootstrap 5 opartym na narzędziach (utility-first). Krzywa uczenia się jest steilsza, jeśli Twój zespół jest przyzwyczajony do rozwoju opartego na jQuery.

Jednak właściwości niestandardowe CSS w Hummingbird sprawiają, że pewne typy dostosowań są znacznie łatwiejsze niż w Classic. Chcesz zmienić kolor główny w całym motywie? Zmodyfikuj jedną właściwość niestandardową CSS. W Classic musiałeś wyśledzić każdą zmienną Sass, przekompilować i poradzić sobie z konfliktami specyficzności.

Hummingbird używa również bardziej semantycznej struktury HTML, co ułatwia celowanie w elementy za pomocą selektorów CSS i poprawia dostępność. Pliki szablonów są lepiej zorganizowane z wyraźniejszym podziałem odpowiedzialności.

Obsługa motywów potomnych

Oba motywy obsługują motywy potomne (child themes), co jest zalecanym sposobem dostosowywania motywu PrestaShop bez bezpośredniej modyfikacji plików motywu nadrzędnego. Motywy potomne pozwalają nadpisywać konkretne szablony, dodawać niestandardowe CSS i JavaScript oraz utrzymywać dostosowania między aktualizacjami motywu.

Mechanizm motywu potomnego w Classic jest dojrzały i dobrze przetestowany. Tworzysz katalog motywu potomnego, definiujesz theme.yml odwołujący się do Classic jako rodzica i selektywnie nadpisujesz pliki, które chcesz zmienić. Ten workflow jest stabilny od PrestaShop 1.7.

Obsługa motywów potomnych w Hummingbird działa tak samo na poziomie frameworka, ale ma pewne praktyczne różnice. Ponieważ szablony Hummingbird mają inną strukturę, nadpisania motywu potomnego z motywu opartego na Classic nie mogą być ponownie wykorzystane. Musisz stworzyć nowe nadpisania oparte na strukturze szablonów Hummingbird.

PrestaShop 8.x ogólnie ulepszył obsługę motywów potomnych, ułatwiając nadpisywanie zasobów (CSS i JavaScript) i częściowych szablonów. Te ulepszenia dotyczą zarówno motywów potomnych Classic, jak i Hummingbird.

Jeśli zlecasz tworzenie niestandardowego motywu deweloperowi, wybranie Hummingbird jako rodzica jest lepszym wyborem na dłuższą metę. Czystsza architektura oznacza mniejszy dług techniczny, a nowoczesne podejście CSS oznacza mniejszą liczbę potrzebnych nadpisań dla typowych dostosowań.

Ścieżka migracji: Z Classic na Hummingbird

Jeśli aktualnie korzystasz z Classic i rozważasz przejście na Hummingbird, oto co faktycznie obejmuje migracja.

Nadpisania szablonów trzeba przebudować od zera. Nie możesz po prostu skopiować nadpisań szablonów Classic do motywu potomnego Hummingbird. Struktura plików szablonów, nazwy zmiennych i nazwy bloków są inne. Musisz zbadać każde nadpisanie, zrozumieć, co osiąga, i odtworzyć je używając struktury szablonów Hummingbird.

Niestandardowy CSS wymaga przeglądu i prawdopodobnie znaczącej rewizji. Jeśli Twój CSS celuje w klasy Bootstrap 4, te nazwy klas mogły ulec zmianie w Bootstrap 5. Jeśli Twój CSS używa wzorców zależnych od jQuery (takich jak stylowanie elementów na podstawie klas dodanych przez jQuery), te się zepsują. Jeśli Twój CSS używa nazw klas specyficznych dla motywu Classic, te mogą nie istnieć w Hummingbird.

Niestandardowy JavaScript musi zostać przepisany. Każdy kod jQuery musi zostać przekonwertowany na natywny JavaScript. Jest to często najbardziej czasochłonna część migracji, ponieważ kod jQuery bywa głęboko powiązany z wzorcami manipulacji DOM, które wymagają przemyślenia na nowo.

Kompatybilność modułów musi zostać zweryfikowana dla każdego zainstalowanego modułu. Jak omówiono powyżej, moduły zależne od jQuery lub Bootstrap 4 mogą wymagać aktualizacji lub zamienników.

Realistyczny harmonogram migracji umiarkowanie dostosowanego sklepu Classic na Hummingbird to 40-80 godzin pracy dewelopera. To nie jest projekt weekendowy. Zaplanuj to jako pełnoprawne przedsięwzięcie deweloperskie ze środowiskiem staging, dokładnym testowaniem i planem wycofania zmian.

Kiedy wybrać Classic

Wybierz Classic, gdy Twój sklep zależy od starszych modułów firm trzecich, które nie zostały zaktualizowane pod kątem kompatybilności z Hummingbird. Wybierz go, gdy Twój zespół deweloperski jest bardziej biegły w jQuery i Bootstrap 4 i nie masz budżetu na przekwalifikowanie lub zatrudnienie nowych osób. Wybierz go, gdy budujesz w napiętym terminie i potrzebujesz najszerszego możliwego wyboru kompatybilnych motywów i modułów z rynku PrestaShop.

Classic to również bezpieczniejszy wybór dla sklepów działających na PrestaShop 1.7.x lub wczesnych wersjach 8.0.x. Hummingbird został wprowadzony później w cyklu 8.x i może nie być w pełni dostępny lub stabilny na starszych wersjach PrestaShop.

Jeśli Twój sklep już działa na Classic z rozbudowanymi dostosowaniami i osiąga zadowalającą wydajność, może nie być przekonującego powodu do migracji. Zyski wydajnościowe z Hummingbird są realne, ale mogą nie uzasadniać nakładu migracyjnego, jeśli Twój sklep już ładuje się szybko i dobrze konwertuje.

Kiedy wybrać Hummingbird

Wybierz Hummingbird, gdy zaczynasz nowy sklep PrestaShop 8.x lub 9.x od zera. Zalety wydajnościowe są darmowe, gdy nie masz starych dostosowań do migracji. Wybierz go, gdy wydajność jest najwyższym priorytetem dla Twojego biznesu, szczególnie jeśli Twoja publiczność to głównie użytkownicy mobilni na wolniejszych połączeniach, gdzie każdy kilobajt ma znaczenie.

Wybierz Hummingbird, gdy chcesz zabezpieczyć swój sklep na przyszłość. W miarę jak PrestaShop kontynuuje ewolucję w kierunku nowoczesnych praktyk front-end, Hummingbird będzie otrzymywać najwięcej uwagi deweloperskiej i jako pierwszy korzystać z nowych funkcji.

Wybierz go, gdy masz deweloperów biegłych w nowoczesnym JavaScript i CSS. Architektura Hummingbird jest czystsza i łatwiejsza w utrzymaniu dla zespołów z aktualnymi umiejętnościami front-end.

I wybierz go, gdy zależy Ci na dostępności. Semantyczny HTML Hummingbird, atrybuty ARIA i obsługa nawigacji klawiaturą są zauważalnie lepsze niż w Classic. Jeśli Twój sklep musi spełniać standardy dostępności WCAG, Hummingbird daje Ci lepszy punkt wyjścia.

Kwestia motywów firm trzecich

Wielu właścicieli sklepów pomija oba oficjalne motywy i kupuje motyw firmy trzeciej z rynku PrestaShop Addons lub od niezależnych sprzedawców. Te motywy prawie zawsze bazują na architekturze Classic, ponieważ Classic jest dostępny znacznie dłużej i reprezentuje większą bazę zainstalowaną.

Jeśli używasz motywu firmy trzeciej, pytanie Classic vs Hummingbird jest w dużej mierze akademickie dla Twojego obecnego sklepu. Deweloper Twojego motywu podjął za Ciebie decyzje architektoniczne. Jednak oceniając nowe motywy firm trzecich, sprawdź, czy są zbudowane na fundamentach Classic, czy Hummingbird. Motywy zbudowane na Hummingbird będą osiągać lepszą wydajność i dłużej utrzymywać kompatybilność.

Uważaj na motywy firm trzecich, które twierdzą, że są "oparte na Hummingbird", ale w rzeczywistości jedynie zapożyczają jego styl wizualny, zachowując zależną od jQuery architekturę Classic pod spodem. Sprawdź zależności JavaScript motywu i framework CSS, aby to zweryfikować.

Werdykt: Nie ma złej odpowiedzi, ale jest lepsza

Dla nowych sklepów na PrestaShop 8.x lub nowszym, Hummingbird jest jasną rekomendacją. Jest szybszy, bardziej nowoczesny, lepiej utrzymywany i bardziej przyszłościowy. Problem z kompatybilnością modułów zmniejsza się w miarę jak ekosystem nadgania, a start od zera oznacza brak kosztów migracji starych rozwiązań.

Dla istniejących sklepów działających na Classic ze znaczącymi dostosowaniami, decyzja wymaga analizy kosztów i korzyści. Oblicz nakład migracyjny uczciwie, zmierz swoją aktualną wydajność, aby zrozumieć potencjalny zysk, i zdecyduj, czy poprawa uzasadnia inwestycję. Czasami odpowiedź brzmi tak, czasami nie, a czasami właściwą odpowiedzią jest poczekanie do następnego dużego przeprojektowania, aby zmienić motyw.

Niezależnie od wybranego motywu, zasady dobrej wydajności front-end obowiązują jednakowo: minimalizuj rozmiary zasobów, leniwie ładuj treść poniżej złożenia strony, optymalizuj obrazy i regularnie audytuj szybkość strony. Dobrze zoptymalizowany sklep na Classic zawsze pokonaje źle skonfigurowany sklep na Hummingbird. Motyw zapewnia fundament, ale wykonanie decyduje o wyniku.

Przeczytaj pełną odpowiedź

Twój motyw jest prawdopodobnie wolniejszy, niż myślisz

Każdy właściciel sklepu PrestaShop ma zdanie na temat szybkości swojego motywu, ale bardzo niewielu ma faktyczne dane. Stwierdzenie "mój sklep wydaje się szybki" jest pozbawione znaczenia, gdy Google mierzy Twoje Core Web Vitals z dokładnością do milisekundy i używa tych liczb do określania Twojej pozycji w wyszukiwarce. Aby zrozumieć rzeczywisty wpływ motywu na wydajność, potrzebujesz systematycznego podejścia do pomiarów, które izoluje wkład motywu od wydajności serwera, narzutu modułów i warunków sieciowych.

Ten artykuł przeprowadzi Cię przez kompletną metodologię pomiarów wydajności. Nauczysz się, jak używać Lighthouse, WebPageTest, Chrome DevTools i monitoringu użytkowników rzeczywistych, aby dokładnie określić, ile Twój motyw kosztuje w czasie ładowania, interaktywności i stabilności wizualnej. Co ważniejsze, nauczysz się, jak oddzielić wydajność motywu od wszystkiego innego, abyś mógł podejmować świadome decyzje o optymalizacji lub wymianie.

Dlaczego wydajność motywu ma większe znaczenie, niż myślisz

Twój motyw kontroluje całe doświadczenie front-end. Determinuje, które pliki CSS się ładują, ile JavaScript jest wykonywane, jak renderowane są obrazy, jak ładowane są czcionki i jak konstruowany jest layout. Źle zbudowany motyw może dodać 2-5 sekund do czasu ładowania strony niezależnie od tego, jak szybki jest Twój serwer lub jak dobrze zakodowane są Twoje moduły.

Core Web Vitals Google bezpośrednio mierzą aspekty doświadczenia użytkownika, które kontroluje Twój motyw. Largest Contentful Paint (LCP) mierzy, jak szybko główna treść staje się widoczna. First Input Delay (FID) i jego następca Interaction to Next Paint (INP) mierzą, jak szybko strona reaguje na interakcję użytkownika. Cumulative Layout Shift (CLS) mierzy stabilność wizualną podczas ładowania strony. Wszystkie trzy metryki są silnie uzależnione od architektury motywu.

Wpływ biznesowy jest konkretny. Badania konsekwentnie pokazują, że każda dodatkowa sekunda czasu ładowania strony zmniejsza współczynniki konwersji o 7-10%. Motyw, który dodaje 2 sekundy zbędnego czasu ładowania, może kosztować Cię 15-20% potencjalnej sprzedaży. To sprawia, że pomiar wydajności motywu to nie ćwiczenie techniczne, lecz analiza krytyczna dla biznesu.

Przygotowanie środowiska testowego

Zanim zaczniesz mierzyć, potrzebujesz kontrolowanego środowiska testowego. Mierzenie wydajności na żywym sklepie, gdy klienci przeglądają strony, a obciążenie serwera się zmienia, da niespójne wyniki. Musisz zminimalizować zmienne.

Idealnie przygotuj kopię staging swojego sklepu PrestaShop. Powinna to być identyczna kopia Twojego sklepu produkcyjnego działająca na tym samym sprzęcie serwerowym lub podobnej konfiguracji. Zainstaluj te same moduły, zaimportuj te same produkty i użyj tej samej konfiguracji motywu. Jedyną różnicą powinno być to, że żadni prawdziwi klienci nie mają do niego dostępu.

Jeśli pełne środowisko staging nie jest możliwe, przeprowadzaj testy poza godzinami szczytu, gdy obciążenie serwera jest minimalne. Przeprowadź każdy test co najmniej trzy razy i uśrednij wyniki, aby uwzględnić zmienność sieci i serwera.

Wyłącz wszelkie proxy cachujące (takie jak Cloudflare) na potrzeby testowania lub użyj adresu URL staging, który omija CDN. Cachowanie CDN maskuje prawdziwą wydajność Twojego motywu, serwując zbuforowaną treść. Chcesz zmierzyć, co się dzieje, gdy odwiedzający trafia na Twój serwer źródłowy z pustym cachem przeglądarki.

Udokumentuj swoją bazową konfigurację. Zanotuj wersję PHP, wersję PrestaShop, aktywne moduły, ustawienia CCC (Combine, Compress, Cache) i specyfikację serwera. Te informacje będą potrzebne do odtworzenia wyników i porównania pomiarów w czasie.

Lighthouse: Twój punkt wyjścia

Google Lighthouse jest wbudowany w Chrome DevTools i zapewnia najbardziej dostępny audyt wydajności. Symuluje urządzenie mobilne na ograniczonym połączeniu i mierzy kluczowe metryki używane przez Google do pozycjonowania w wyszukiwarkach.

Aby uruchomić audyt Lighthouse, otwórz Chrome DevTools (F12), przejdź do karty Lighthouse, wybierz "Wydajność" (Performance) jako kategorię, wybierz "Urządzenie mobilne" (Mobile) jako urządzenie i kliknij "Analizuj ładowanie strony" (Analyze page load). Lighthouse przeładuje stronę w symulowanym środowisku i wygeneruje szczegółowy raport.

Wynik Wydajności (0-100) to ważona kompozycja sześciu metryk: First Contentful Paint (10%), Speed Index (10%), Largest Contentful Paint (25%), Total Blocking Time (30%), Cumulative Layout Shift (25%). Zauważ, że Total Blocking Time i Largest Contentful Paint razem stanowią 55% wyniku, więc to metryki najbardziej prawdopodobne do wpływu przez jakość motywu.

Uruchom audyt na co najmniej czterech typach stron: stronie głównej, stronie kategorii, stronie produktu i stronie koszyka lub zamówienia. Każdy typ strony ma inną złożoność DOM i wymagania dotyczące zasobów, a Twój motyw może działać bardzo różnie na każdym z nich.

Ważne zastrzeżenie: Lighthouse działa w symulowanym środowisku z ograniczaniem CPU i sieci. Bezwzględne liczby, które produkuje, nie odpowiadają rzeczywistej wydajności. Są przydatne do porównań (przed vs po, motyw A vs motyw B), ale nie powinny być traktowane jako faktyczne doświadczenie Twoich klientów. Dla rzeczywistych liczb potrzebujesz Monitoringu Użytkowników Rzeczywistych (Real User Monitoring), omówionego dalej w tym artykule.

Zapisz każdy wynik Lighthouse w arkuszu kalkulacyjnym. Uwzględnij testowany adres URL, datę i godzinę, ogólny wynik Wydajności i wartość każdej indywidualnej metryki. To tworzy bazę odniesienia, do której możesz się odwołać podczas wprowadzania zmian.

WebPageTest: Głęboka analiza

WebPageTest (webpagetest.org) to darmowe narzędzie, które zapewnia znacznie więcej szczegółów niż Lighthouse. Uruchamia prawdziwe przeglądarki na prawdziwym sprzęcie z lokalizacji na całym świecie, dając Ci dokładniejszy obraz tego, czego doświadczają Twoi klienci.

Rozpocznij test, wprowadzając adres URL swojego sklepu, wybierając lokalizację testową blisko Twojej głównej publiczności i wybierając prędkość połączenia. Dla sklepów europejskich użyj lokalizacji testowej we Frankfurcie lub Londynie z profilem połączenia Cable lub 4G. Uruchom co najmniej trzy testy, aby uzyskać medianę wyników.

Wykres kaskadowy (waterfall) to najcenniejszy output z WebPageTest. Pokazuje każdy pojedynczy zasób ładowany przez Twoją stronę, w kolejności chronologicznej, z czasem pobierania każdego zasobu. Ta wizualizacja natychmiast uwidacznia, które zasoby blokują renderowanie i które ładują się zbędnie.

Szukaj tych wzorców na wykresie kaskadowym. Blokujące renderowanie CSS i JavaScript pojawiają się jako długie paski na górze wykresu przed wyrenderowaniem jakiejkolwiek treści. Duże pliki czcionek pobierające się przed krytyczną treścią wskazują na złą strategię ładowania czcionek. Żądania do stron trzecich (analityka, widgety społecznościowe, wtyczki czatowe), które blokują lub opóźniają zasoby Twojego motywu.

WebPageTest zapewnia również widok taśmy filmowej (filmstrip), który pokazuje zrzuty ekranowe Twojej strony w interwałach 100ms podczas ładowania. Jest to niesamowicie przydatne do zrozumienia wizualnego doświadczenia ładowania. Możesz zobaczyć dokładnie, kiedy pojawia się tekst, kiedy renderują się obrazy i kiedy występują przesunięcia layoutu.

Widok "Rozkład treści" (Content Breakdown) pokazuje łączną wagę Twojej strony podzieloną według typu treści: HTML, CSS, JavaScript, obrazy, czcionki i inne zasoby. Dla dobrze zoptymalizowanego motywu CSS powinien mieć mniej niż 100KB po kompresji, JavaScript mniej niż 150KB po kompresji, a czcionki mniej niż 50KB. Jeśli Twoje liczby są znacząco wyższe, Twój motyw niesie nadmiarową wagę.

Karta Wydajność Chrome DevTools: Analiza klatka po klatce

Karta Wydajność (Performance) w Chrome DevTools zapewnia najbardziej szczegółową dostępną analizę. Nagrywa szczegółową oś czasu wszystkiego, co przeglądarka robi podczas ładowania strony, w tym wykonanie JavaScript, obliczenia layoutu, operacje malowania i kompozycję.

Aby z niej skorzystać, otwórz DevTools (F12), przejdź do karty Wydajność (Performance), zaznacz "Zrzuty ekranowe" (Screenshots) i "Web Vitals", wybierz ograniczenie sieci "Wolne 3G" (Slow 3G) i ograniczenie CPU "4x spowolnienie" (4x slowdown), następnie kliknij przycisk nagrywania i przeładuj stronę. Zatrzymaj nagrywanie, gdy strona w pełni się załaduje.

Wynikowa oś czasu pokazuje kilka pasów informacji. Pas Sieć (Network) pokazuje żądania zasobów. Pas Klatki (Frames) pokazuje zrzuty ekranowe w kluczowych momentach. Pas Główny wątek (Main) pokazuje wykonanie JavaScript na głównym wątku. Znaczniki Web Vitals pokazują dokładnie, kiedy wystąpiły zdarzenia FCP, LCP i CLS.

Skup się na pasie Głównego wątku. Długie żółte bloki to wykonanie JavaScript. Szukaj zadań JavaScript trwających dłużej niż 50ms, ponieważ to "długie zadania" (long tasks), które blokują interakcję użytkownika i przyczyniają się do Total Blocking Time. Zidentyfikuj, które skrypty powodują te długie zadania, klikając na nie, aby zobaczyć stos wywołań. Jeśli długie zadania pochodzą z plików JavaScript Twojego motywu, to jest problem wydajnościowy motywu.

Czerwone bloki na pasie Głównego wątku wskazują na thrashing layoutu, gdzie przeglądarka jest zmuszona wielokrotnie przeliczać layout w szybkiej sukcesji. Dzieje się tak często, gdy JavaScript odczytuje właściwości layoutu (offsetHeight, getBoundingClientRect) i następnie modyfikuje DOM w pętli. Kod motywu powodujący thrashing layoutu jest częstą przyczyną słabych wyników INP.

Karty "Wstecz" (Bottom-Up) i "Drzewo wywołań" (Call Tree) poniżej osi czasu pozwalają sortować wykonanie JavaScript według łącznego czasu lub czasu własnego. To pokazuje, które konkretne funkcje pochłaniają najwięcej czasu CPU podczas ładowania strony. Jeśli funkcje motywu dominują na tej liście, Twój motyw jest wąskim gardłem wydajności.

Analiza kaskadowa sieci dla zasobów motywu

Karta Sieć (Network) w DevTools zapewnia inny widok ładowania zasobów. Filtruj według typu zasobu (CSS, JS, Font, Img), aby izolować zasoby specyficzne dla motywu i zrozumieć ich wpływ.

Zacznij od identyfikacji wszystkich zasobów należących do Twojego motywu. Zazwyczaj ładują się ze ścieżek takich jak /themes/twoj-motyw/assets/ lub podobnych. Zanotuj łączną liczbę i sumaryczny rozmiar. Następnie zidentyfikuj zasoby ładowane przez moduły (ze ścieżek /modules/), aby oddzielnie zrozumieć wkład modułów.

Włącz pole "Wyłącz cache" (Disable cache) i przeładuj. To symuluje pierwszego odwiedzającego. Zanotuj łączny rozmiar transferu i czas do DOMContentLoaded i zdarzeń Load. Następnie przeładuj bez zaznaczania pola, aby zobaczyć doświadczenie z cache (ponowny odwiedzający). Różnica pokazuje, jak bardzo Twój motyw korzysta z cachowania przeglądarki.

Spójrz na kolumnę "Inicjator" (Initiator), aby zrozumieć łańcuch zależności. Plik CSS załadowany przez szablon nagłówka motywu jest zasobem krytycznym, który blokuje renderowanie. Plik JavaScript załadowany z atrybutem async lub defer jest nieblokujący. Zrozumienie tych zależności pomaga zidentyfikować, które zasoby motywu znajdują się na ścieżce krytycznej, a które mogłyby być odłożone.

Użyj kolumny "Priorytet" (Priority) (włącz ją przez menu prawego przycisku myszy na nagłówku kolumny), aby zobaczyć, jak przeglądarka priorytetyzuje każdy zasób. Zasoby z priorytetem "Najwyższy" (Highest) lub "Wysoki" (High) to te, które przeglądarka uważa za najważniejsze. Jeśli Twój motyw ładuje niekrytyczne zasoby z wysokim priorytetem, to szansa na optymalizację.

Porównanie z motywem i bez motywu

Aby naprawdę wyizolować wpływ wydajnościowy Twojego motywu, potrzebujesz porównania. Najbardziej rygorystyczne podejście to przetestowanie sklepu z Twoim obecnym motywem, a następnie przełączenie na domyślny minimalny motyw PrestaShop i ponowne testy.

W środowisku staging przeprowadź pełny zestaw pomiarów z aktywnym obecnym motywem. Zapisz wszystkie metryki. Następnie przełącz motyw na domyślny Classic (lub Hummingbird, jeśli korzystasz z PrestaShop 8.x+) i przeprowadź te same pomiary. Różnica reprezentuje przyrostowy wpływ Twojego motywu w porównaniu z domyślnym.

To porównanie nie jest idealne, ponieważ domyślny motyw nie ma Twoich dostosowań, a wyjście wizualne jest inne. Ale daje Ci górną granicę tego, ile poprawy wydajności jest możliwe przez optymalizację motywu. Jeśli Twój obecny motyw uzyskuje 30 punktów mniej niż domyślny w Lighthouse, wiesz, że jest znaczny potencjał do poprawy.

Bardziej kontrolowane porównanie polega na stopniowym wyłączaniu funkcji motywu. Zacznij z wszystkimi funkcjami włączonymi, zmierz, następnie wyłącz niestandardowe czcionki i zmierz ponownie. Wyłącz efekty JavaScript motywu i zmierz. Usuń czcionkę ikonową motywu. Każdy krok pokazuje przyrostowy koszt tej konkretnej funkcji.

Core Web Vitals: Co faktycznie mierzy Google

Core Web Vitals to trzy metryki, których Google używa do celów pozycjonowania. Są mierzone na rzeczywistych użytkownikach poprzez Chrome User Experience Report (CrUX), a nie przez narzędzia laboratoryjne jak Lighthouse. Zrozumienie różnicy między pomiarami laboratoryjnymi a terenowymi jest kluczowe.

Pomiary laboratoryjne (Lighthouse, WebPageTest) używają symulowanych warunków. Pomiary terenowe (CrUX, Real User Monitoring) rejestrują faktyczne doświadczenia użytkowników na różnych urządzeniach, sieciach i lokalizacjach. Twój wynik Lighthouse może wynosić 75, ale jeśli większość Twoich klientów korzysta ze starszych telefonów z wolnymi połączeniami, dane terenowe mogą opowiadać zupełnie inną historię.

Aby zobaczyć swoje dane terenowe, użyj raportu Core Web Vitals w Google Search Console lub PageSpeed Insights (pagespeed.web.dev). PageSpeed Insights pokazuje zarówno dane laboratoryjne, jak i terenowe, gdy są dostępne. Jeśli Twoja strona ma wystarczający ruch, zobaczysz dane od rzeczywistych użytkowników obok symulacji Lighthouse.

Progi dla dobrych Core Web Vitals to: LCP poniżej 2,5 sekundy, INP poniżej 200 milisekund i CLS poniżej 0,1. Google ocenia 75. percentyl Twoich użytkowników, co oznacza, że 75% Twoich użytkowników musi mieć dobre doświadczenie, aby metryka została sklasyfikowana jako "dobra". To wysoki próg, ponieważ Twoi najgorzej radzący sobie odwiedzający (stare telefony, wolne sieci) silnie wpływają na 75. percentyl.

Twój motyw bezpośrednio wpływa na wszystkie trzy metryki. LCP jest uzależniony od rozmiaru pliku CSS (który blokuje renderowanie), strategii ładowania czcionek i implementacji obrazu hero. INP jest uzależniony od wykonania JavaScript, efektywności obsługi zdarzeń i tego, jak motyw reaguje na kliknięcia i przewijanie. CLS jest uzależniony od miejsc zarezerwowanych dla obrazów, dynamicznego wstawiania treści i ładowania czcionek.

Monitoring Użytkowników Rzeczywistych: Prawda obiektywna

Real User Monitoring (RUM) rejestruje dane wydajnościowe od Twoich faktycznych odwiedzających podczas przeglądania sklepu. To najdokładniejszy pomiar rzeczywistego wpływu wydajnościowego Twojego motywu, ponieważ odzwierciedla faktyczne urządzenia, sieci i wzorce użytkowania Twojej publiczności.

Google Analytics 4 automatycznie rejestruje Core Web Vitals, jeśli masz snippet gtag.js na swojej stronie. Możesz zobaczyć te dane w GA4 w sekcji Raporty, Doświadczenie użytkownika, lub tworząc niestandardową eksplorację.

Dla bardziej szczegółowego RUM, dedykowane usługi jak SpeedCurve, Datadog lub darmowa biblioteka JavaScript web-vitals zapewniają szczegółowe dane. Biblioteka web-vitals (dostępna na npm) jest szczególnie przydatna, ponieważ możesz ją dodać do swojego motywu i wysyłać dane wydajnościowe do dowolnego punktu końcowego analityki.

Dzięki danym RUM możesz segmentować wydajność według typu urządzenia (mobilne vs desktop), przeglądarki (Chrome vs Safari vs Firefox), kraju i typu strony. Ta segmentacja często ujawnia, że Twój motyw działa bardzo różnie dla różnych segmentów publiczności. Motyw może osiągać dobre wyniki dla użytkowników desktopowego Chrome, ale słabe dla użytkowników mobilnego Safari ze względu na różnice w wydajności silnika JavaScript lub renderowania CSS.

Śledź dane RUM w czasie, aby korelować zmiany wydajności z aktualizacjami motywu, instalacjami modułów lub zmianami konfiguracji. Jeśli Twoje LCP nagle wzrasta o 500ms, sprawdź, co zmieniło się w Twoim motywie lub zestawie modułów w tym dniu.

Profilowanie po stronie serwera: Oddzielanie backendu od frontendu

Czasami słaba szybkość strony jest obwiniana na motyw, gdy prawdziwym problemem jest czas przetwarzania po stronie serwera. Przed optymalizacją motywu zweryfikuj, że serwer generuje HTML szybko.

PrestaShop zawiera wbudowany profiler, który możesz włączyć w panelu administracyjnym w sekcji Zaawansowane parametry, Wydajność, Tryb debugowania. Profiler dodaje pasek debugowania na dole każdej strony pokazujący liczbę zapytań SQL, czas wykonania SQL, czas generowania strony i zużycie pamięci.

Dobrze skonfigurowana instalacja PrestaShop powinna generować większość stron w mniej niż 500ms po stronie serwera. Jeśli generowanie serwera trwa dłużej niż sekundę, problemem nie jest Twój motyw, lecz Twój serwer, zapytania do bazy danych lub hooki modułów. Naprawianie motywu nie pomoże, jeśli serwer potrzebuje 3 sekundy tylko na wygenerowanie HTML.

Możesz również zmierzyć czas odpowiedzi serwera (Time to First Byte, TTFB) z karty Sieć (Network) w DevTools. Kliknij na żądanie dokumentu HTML i spójrz na sekcję Chronometraż (Timing). Wartość "Oczekiwanie (TTFB)" (Waiting (TTFB)) pokazuje, jak długo przeglądarka czekała na odpowiedź serwera. Odejmij opóźnienie sieciowe (które możesz oszacować z wartości "Połączenie" (Connection)), aby uzyskać przybliżony czas przetwarzania serwera.

Jeśli Twoje TTFB jest wysokie, ale zasoby motywu są szybkie, skup się na optymalizacji serwera (PHP OPcache, cache zapytań MySQL, Redis/Memcached, cachowanie obiektów PrestaShop) zamiast optymalizacji motywu. Jeśli Twoje TTFB jest szybkie, ale strona nadal ładuje się wolno, motyw jest prawdopodobnie wąskim gardłem.

Framework testowania przed/po

Wprowadzając zmiany wydajnościowe motywu, potrzebujesz rygorystycznego porównania przed/po, aby zweryfikować, że zmiana faktycznie pomogła. Oto framework, który produkuje wiarygodne wyniki.

Przed wprowadzeniem jakiejkolwiek zmiany uruchom pięć audytów Lighthouse na każdej docelowej stronie i zapisz medianę wyniku i indywidualne metryki. Uruchom również trzy testy WebPageTest i zapisz wartości mediany. Zachowaj pełne raporty, nie tylko wyniki, ponieważ możesz potrzebować zbadać szczegóły później.

Wprowadź zmianę. Wyczyść wszystkie cache, w tym cache Smarty PrestaShop, OPcache i wszelki cache CDN. Poczekaj co najmniej 60 sekund na pełny reset OPcache, jeśli zmieniłeś pliki PHP.

Uruchom te same pięć audytów Lighthouse i trzy testy WebPageTest na tych samych stronach. Porównaj wyniki mediany. Zmiana jest znacząca, jeśli produkuje spójną poprawę we wszystkich uruchomieniach testowych. Jeśli niektóre uruchomienia pokazują poprawę, a inne regresję, wpływ zmiany mieści się w marginesie błędu pomiaru.

Bądź sceptyczny wobec małych popraw. Wyniki Lighthouse mogą się różnić o plus minus 5 punktów między identycznymi uruchomieniami ze względu na zmienność symulowanego ograniczenia sieci i CPU. Zmiana, która poprawia wynik z 62 na 65, może nie być prawdziwą poprawą. Zmiana z 62 na 75 prawie na pewno jest.

Dla najbardziej rygorystycznego porównania użyj funkcji porównania wizualnego WebPageTest. Wprowadź adres URL staging (przed zmianą) i adres URL produkcji (po zmianie), lub uruchom ten sam adres URL w różnych momentach i porównaj zapisane testy. WebPageTest generuje zestawienie taśmy filmowej obok siebie i podkreśla różnice.

Najczęstsze problemy wydajnościowe motywu i jak je wykryć

Poprzez pomiary zidentyfikujesz konkretne problemy wydajnościowe. Oto najczęstsze problemy związane z motywem i metryki, które je ujawniają.

Blokujący renderowanie CSS objawia się wysokim FCP i LCP z długą przerwą między TTFB a FCP na wykresie kaskadowym. Rozwiązaniem jest wstawienie krytycznego CSS inline i odłożenie niekrytycznych arkuszy stylów. Nadmiarowy JavaScript objawia się wysokim TBT i słabymi wynikami INP. Długie zadania na osi czasu karty Wydajność to potwierdzają. Niezoptymalizowane ładowanie czcionek manifestuje się jako FOIT (niewidoczny tekst) na taśmie filmowej lub przerwa między FCP a momentem faktycznego pojawienia się tekstu. Przesunięcia layoutu z obrazów bez wymiarów lub dynamicznie wstawianej treści objawiają się wysokimi wynikami CLS.

Każdy problem ma specyficzną sygnaturę pomiarową. Nauka odczytywania tych sygnatur to to, co przekształca pracę wydajnościową z zgadywania w inżynierię. Najpierw zmierz, diagnozuj na podstawie danych, napraw konkretny problem, a następnie zmierz ponownie, aby zweryfikować, że poprawka zadziałała.

Budowanie rutyny monitoringu wydajności

Pomiar wydajności nie powinien być jednorazową czynnością. Zbuduj rutynę, która wychwytuje regresje, zanim wpłyną na Twoich klientów i pozycje w wyszukiwarkach.

Co tydzień uruchamiaj Lighthouse na czterech kluczowych typach stron i zapisuj wyniki. Co miesiąc przeprowadzaj pełną analizę WebPageTest i porównuj z poprzednim miesiącem. Po każdej aktualizacji motywu lub instalacji modułu przeprowadzaj porównanie przed/po. Skonfiguruj monitoring Core Web Vitals w Google Search Console i przeglądaj go co miesiąc.

Rozważ automatyzację za pomocą narzędzi takich jak Lighthouse CI (do automatycznych uruchomień Lighthouse w pipeline'ie wdrożeniowym) lub SpeedCurve (do ciągłego monitoringu z alertami). Te narzędzia natychmiast Cię powiadomią, gdy wydajność spadnie, pozwalając zidentyfikować i naprawić przyczynę, zanim wpłynie na Twoje pozycje w wyszukiwarkach.

Celem nie jest idealny wynik Lighthouse. Celem jest zrozumienie dokładnie, gdzie Twój czas i zasoby są wykorzystywane przy każdym ładowaniu strony, oraz podejmowanie świadomych, opartych na danych decyzji o tym, co optymalizować, co zachować i co usunąć.

Przeczytaj pełną odpowiedź

Prawdziwa debata wokół cen szablonów

Każdy właściciel sklepu PrestaShop staje w pewnym momencie przed tym pytaniem: czy korzystać z darmowego szablonu, czy zainwestować w wersję premium? Odpowiedź wydaje się oczywista na pierwszy rzut oka. Darmowy oszczędza pieniądze, premium kosztuje. Ale rzeczywisty koszt szablonu wykracza daleko poza cenę zakupu. Darmowy szablon, który wymaga setek euro na prace dostosowawcze, powoduje problemy z wydajnością lub brakuje w nim kluczowych funkcji, może ostatecznie kosztować znacznie więcej niż szablon premium, który działa poprawnie od razu po instalacji.

Ten przewodnik przedstawia rzeczywiste różnice między darmowymi a premium szablonami PrestaShop, analizuje ukryte koszty po obu stronach i pomaga podjąć świadomą decyzję opartą na tym, czego faktycznie potrzebujesz, a nie na tym, co mówi cena.

Co tak naprawdę oferują darmowe szablony

PrestaShop jest dostarczany z domyślnym szablonem. W PrestaShop 1.7 i 8.x jest to szablon Classic. PrestaShop 9 wprowadza Hummingbird jako nowy domyślny szablon. Te oficjalne szablony są naprawdę dobrze wykonane. Przestrzegają standardów kodowania PrestaShop, obsługują wszystkie standardowe hooki, poprawnie współpracują z systemem tłumaczeń i otrzymują aktualizacje wraz z platformą. Dla właściciela sklepu, który potrzebuje czystego, funkcjonalnego designu i jest gotowy dostosować go za pomocą CSS, domyślny szablon jest uzasadnionym punktem wyjścia.

Poza oficjalnymi szablonami, krajobraz darmowych szablonów jest znacznie bardziej zróżnicowany pod względem jakości. Darmowe szablony od zewnętrznych deweloperów dzielą się na kilka kategorii. Niektóre są okrojonymi wersjami szablonów premium, zaprojektowanymi, aby dać przedsmak pracy dewelopera i zachęcić do zakupu pełnej wersji. Są one zazwyczaj funkcjonalne, ale ograniczone — brakuje w nich funkcji takich jak zaawansowane układy stron produktowych, mega menu czy konfigurowalne schematy kolorów. Inne to projekty hobbystyczne lub portfoliowe tworzone przez indywidualnych deweloperów. Ich jakość jest bardzo zróżnicowana — od zaskakująco dobrych po ledwo działające. A potem są szablony, które są darmowe, ponieważ służą innemu celowi niż bycie dobrym szablonem, na przykład szablony dołączane z adware, szablony zawierające ukryte linki zwrotne do strony dewelopera, lub szablony zbierające dane o użytkowaniu bez informowania o tym.

Oficjalny marketplace PrestaShop Addons oferuje kilka darmowych szablonów, które muszą przejść podstawowy proces weryfikacji. Darmowe szablony z nieznanych źródeł spoza oficjalnego marketplace'u niosą ze sobą znacznie większe ryzyko i powinny być oceniane ze szczególną ostrożnością.

Co zapewniają szablony premium

Szablony premium PrestaShop kosztują zazwyczaj od 60 do 300 euro, przy czym większość mieści się w przedziale od 80 do 150 euro. Za tę cenę otrzymujesz zazwyczaj szablon z dopracowanym designem, który zawiera wiele gotowych układów stron i schematów kolorów, panel konfiguracyjny w panelu administracyjnym pozwalający dostosowywać kolory, czcionki, układy i inne elementy wizualne bez edycji kodu, zestaw towarzyszących modułów (mega menu, niestandardowe strony produktów, slidery obrazów, funkcjonalność bloga) zaprojektowanych do bezproblemowej współpracy z szablonem, dokumentację wyjaśniającą konfigurację i dostosowywanie, okres wsparcia technicznego (zazwyczaj od 3 do 12 miesięcy w zależności od marketplace'u i sprzedawcy) oraz aktualizacje kompatybilności dla nowych wersji PrestaShop.

Wartość szablonu premium to nie tylko design. To zaoszczędzony czas programistyczny. Zbudowanie od zera niestandardowego modułu mega menu, konfigurowalnego systemu układu stron produktowych i konfiguratora szablonu w panelu administracyjnym kosztowałoby tysiące euro czasu deweloperskiego. Szablon premium łączy to wszystko za ułamek tej ceny.

Różnice w jakości kodu

Najbardziej znacząca różnica między darmowymi a premium szablonami jest często niewidoczna dla kupującego: jakość kodu. Deweloperzy szablonów premium, dla których sprzedaż szablonów jest głównym źródłem dochodu, mają finansową motywację do pisania czystego, łatwego w utrzymaniu kodu. Złe recenzje i zgłoszenia wsparcia kosztują ich czas i pieniądze, więc inwestują w jakość od samego początku. Deweloperzy darmowych szablonów nie mają ciągłej relacji finansowej ze swoimi użytkownikami, nie ponoszą kosztów wsparcia za zły kod i nie ryzykują reputacją w przypadku porzucenia projektu. Oficjalne szablony PrestaShop mają doskonałą jakość kodu, ale średnia jakość darmowych szablonów od zewnętrznych deweloperów jest znacznie niższa.

Konkretne różnice obejmują organizację szablonów (szablony premium używają logicznych hierarchii z częściowymi szablonami; darmowe często wykorzystują monolityczne szablony), architekturę CSS (szablony premium używają BEM lub podobnych metodologii z odpowiednimi właściwościami niestandardowymi; darmowe mają nieustrukturyzowany CSS z konfliktami specyficzności) oraz jakość JavaScript (szablony premium stosują nowoczesne praktyki i współpracują z zarządzaniem zasobami PrestaShop; darmowe ładują biblioteki redundantnie i powodują konflikty z modułami).

Wsparcie i aktualizacje

Gdy coś się zepsuje w Twoim szablonie — czy to z powodu aktualizacji PrestaShop, konfliktu z modułem, czy nieudanej modyfikacji — potrzebujesz pomocy. To jest moment, w którym różnica między darmowym a premium staje się najbardziej odczuwalna.

Szablony premium kupione za pośrednictwem oficjalnych marketplace'ów obejmują określony okres wsparcia. W tym okresie możesz kontaktować się z deweloperem w sprawie pytań technicznych, zgłoszeń błędów i problemów z kompatybilnością. Jakość wsparcia różni się między deweloperami, ale zobowiązanie umowne istnieje. Zapłaciłeś za produkt, a sprzedawca ma obowiązek zapewnić, że działa zgodnie z opisem.

Darmowe szablony nie wiążą się z żadnym zobowiązaniem do wsparcia. Jeśli napotkasz błąd, Twoje opcje to naprawienie go samodzielnie, zatrudnienie dewelopera do naprawy lub porzucenie szablonu. Oryginalny deweloper nie ma motywacji, aby odpowiadać na Twoje zgłoszenie błędu, badać Twój problem czy wydawać poprawkę. Niektórzy deweloperzy darmowych szablonów oferują wsparcie społecznościowe przez fora lub zgłoszenia na GitHubie, ale jest to dobrowolne i niewiarygodne.

Aktualizacje podlegają temu samemu wzorcowi. Deweloperzy szablonów premium wydają aktualizacje, gdy pojawiają się nowe wersje PrestaShop, gdy odkrywane są błędy i gdy dodawane są nowe funkcje. Te aktualizacje są dostarczane przez marketplace i mogą być stosowane przez panel administracyjny. Darmowe szablony mogą nigdy nie otrzymać aktualizacji po ich pierwszym wydaniu. Gdy PrestaShop 8 wprowadził zmiany w systemie szablonów, szablony premium zostały zaktualizowane. Wiele darmowych szablonów zbudowanych dla PrestaShop 1.7 zostało po prostu porzuconych, pozostawiając ich użytkowników na starej wersji PrestaShop lub zmuszając do gorączkowego poszukiwania nowego szablonu.

Zagrożenia bezpieczeństwa darmowych szablonów

Bezpieczeństwo to obszar, w którym darmowe szablony niosą ze sobą naprawdę podwyższone ryzyko. Szablon ma dostęp do całego front office'u Twojego sklepu. Kontroluje, jaki HTML, CSS i JavaScript jest dostarczany do przeglądarek Twoich klientów. Złośliwy lub skompromitowany szablon może wstrzyknąć kod kopania kryptowalut, przekierować klientów na strony phishingowe, kraść dane formularzy w tym informacje płatnicze, tworzyć ukryte konta administratorów lub instalować backdoory, które utrzymują się nawet po usunięciu szablonu.

Szablony premium z uznanych marketplace'ów przechodzą proces weryfikacji, który sprawdza znane problemy bezpieczeństwa. Marketplace PrestaShop Addons, ThemeForest i inne renomowane platformy skanują przesłane szablony pod kątem złośliwego kodu, znanych podatności i zgodności z podstawowymi standardami bezpieczeństwa. Ta weryfikacja nie jest doskonała i podatności nadal mogą istnieć, ale zapewnia podstawowy poziom ochrony.

Darmowe szablony pobierane z przypadkowych stron internetowych nie mają takiej ochrony. Ufasz nieznanemu deweloperowi dostęp do front endu Twojego sklepu. Nawet jeśli deweloper ma dobre intencje, jego kod może zawierać niezamierzone luki bezpieczeństwa, takie jak podatności na cross-site scripting (XSS), punkty SQL injection w specyficznych dla szablonu handlerach AJAX lub niebezpieczna obsługa przesyłania plików w panelach konfiguracji szablonu.

Najbezpieczniejszym darmowym szablonem jest oficjalny domyślny szablon PrestaShop, ponieważ jest utrzymywany przez zespół PrestaShop i otrzymuje aktualizacje bezpieczeństwa wraz z samą platformą.

Niebezpieczeństwo nulled szablonów

Szablony nulled to szablony premium, które zostały pirackie i dystrybuowane za darmo. Stanowią one najniebezpieczniejszą kategorię szablonów PrestaShop. Korzystanie z nulled szablonu to nie tylko naruszenie praw własności intelektualnej. To bezpośrednie zagrożenie bezpieczeństwa dla Twojego biznesu i Twoich klientów.

Szablony nulled są modyfikowane przed dystrybucją. Kod weryfikacji licencji jest usuwany (to właśnie czyni je nulled), ale inne modyfikacje są często dodawane jednocześnie. Typowe modyfikacje obejmują backdoor umożliwiający dystrybutorowi dostęp do panelu administratora Twojego sklepu w dowolnym momencie, zbieranie danych wysyłających dane osobowe Twoich klientów i dane zamówień na zewnętrzne serwery, wstrzykiwanie spamu SEO dodającego ukryte linki do stron hazardowych, farmaceutycznych lub dla dorosłych w kodzie HTML Twojego sklepu (co szkodzi Twoim pozycjom w wyszukiwarkach i potencjalnie narusza przepisy reklamowe), JavaScript do kopania kryptowalut wykorzystujący urządzenia Twoich klientów do kopania podczas przeglądania sklepu oraz łańcuchy przekierowań wysyłające część Twojego ruchu na strony konkurencji lub strony oszustw.

Te modyfikacje są zaprojektowane tak, aby być niewidoczne. Są zaciemnione, uruchamiane tylko pod określonymi warunkami (na przykład tylko dla odwiedzających z konkretnych krajów lub dopiero po tym, jak sklep działa przez określony czas) i ukryte w plikach, których właściciele sklepów rzadko sprawdzają. Możesz używać nulled szablonu przez miesiące, zanim odkryjesz, że wysyłał dane Twoich klientów na serwer w innym kraju.

Nie istnieje żaden uzasadniony powód, aby korzystać z nulled szablonu. Jeśli nie stać Cię na szablon premium, użyj oficjalnego darmowego szablonu. Jest lepszy pod każdym mierzalnym względem niż piracki szablon premium.

Porównanie wydajności

Wydajność szablonu bezpośrednio wpływa na współczynnik konwersji Twojego sklepu i pozycje w wyszukiwarkach. Google wykorzystuje Core Web Vitals jako czynnik rankingowy, a te metryki są w dużym stopniu kształtowane przez jakość szablonu.

Oficjalne szablony PrestaShop Classic i Hummingbird są zoptymalizowane pod kątem wydajności. Ładują minimalną ilość CSS i JavaScript, używają wydajnych struktur szablonów i obsługują wbudowane funkcje wydajnościowe PrestaShop, takie jak CCC (Combine, Compress, Cache) dla plików CSS i JavaScript. Sklep działający na domyślnym szablonie z prawidłową konfiguracją serwera zazwyczaj osiąga dobre wyniki Core Web Vitals bez dodatkowych prac optymalizacyjnych.

Szablony premium różnią się wydajnością. Najlepsze szablony premium dorównują lub przewyższają wydajność domyślnego szablonu, oferując jednocześnie znacznie więcej funkcji. Osiągają to dzięki technikom takim jak lazy loading obrazów i treści poniżej linii widoczności, warunkowe ładowanie JavaScript (ładowanie kodu karuzeli tylko na stronach, które mają karuzele), zoptymalizowany CSS unikający nieużywanych reguł oraz efektywne wykorzystanie czcionek webowych z odpowiednimi ustawieniami font-display. Najgorsze szablony premium jednak poświęcają wydajność na rzecz wizualnej złożoności, ładując wiele sliderów, bibliotek animacji i czcionek ikonowych na każdej stronie, niezależnie od tego, czy są potrzebne.

Darmowe szablony od zewnętrznych deweloperów (z wyłączeniem oficjalnego domyślnego) zwykle działają słabo. Bez komercyjnej motywacji do optymalizacji, deweloperzy darmowych szablonów często włączają wszystkie funkcje na wszystkich stronach, używają niezoptymalizowanych obrazów z treści demonstracyjnych, które trafiają do produkcji, ładują pełne buildy bibliotek zamiast wybierania potrzebnych komponentów i pomijają minifikację oraz łączenie zasobów.

Przed wyborem jakiegokolwiek szablonu przetestuj jego demo za pomocą Google PageSpeed Insights i sprawdź wyniki Core Web Vitals. Szablon, który uzyskuje poniżej 50 punktów na urządzeniach mobilnych we własnym zoptymalizowanym środowisku demo, będzie działał jeszcze gorzej w Twoim prawdziwym sklepie z dodatkowymi modułami, większą liczbą produktów i rzeczywistymi warunkami hostingu.

Opcje dostosowywania

Dostosowywanie określa, ile możesz zmienić w wyglądzie sklepu bez pisania kodu. Oficjalny szablon PrestaShop oferuje minimalne wbudowane możliwości dostosowywania: logo, favicona i kilka podstawowych ustawień. Wszelkie zmiany wizualne wykraczające poza te podstawy wymagają edycji plików CSS lub szablonów Smarty.

Szablony premium zazwyczaj zawierają moduł konfiguratora szablonu zapewniający graficzny interfejs do zarządzania kolorami, typografią, opcjami układu, konfiguracją nagłówka i stopki, układem strony produktu oraz wyświetlaniem strony kategorii. Te opcje pozwalają nietechnicznemu właścicielowi sklepu stworzyć wizualnie wyróżniający się sklep bez dotykania kodu. Darmowe szablony czasami zawierają podstawowe opcje dostosowywania, ale zazwyczaj ograniczają się do kilku wyborów kolorów i przesyłania logo. Różnica jest znaczna.

Marketplace a niezależni sprzedawcy

Miejsce zakupu szablonu premium ma takie samo znaczenie jak sam fakt zakupu. Trzy główne kanały dystrybucji szablonów PrestaShop to oficjalny marketplace PrestaShop Addons, ogólne marketplace'y szablonów takie jak ThemeForest oraz niezależni deweloperzy szablonów sprzedający przez własne strony internetowe.

Marketplace PrestaShop Addons zapewnia najwyższy poziom ochrony kupującego. Szablony są weryfikowane pod kątem kompatybilności z PrestaShop, jakości kodu i bezpieczeństwa. Marketplace obsługuje płatności, zapewnia proces rozstrzygania sporów i egzekwuje zobowiązania wsparcia. Wadą jest mniejszy wybór w porównaniu z ogólnymi marketplace'ami i czasami wyższe ceny.

ThemeForest i podobne marketplace'y oferują znacznie większy wybór w konkurencyjnych cenach. Jednak proces weryfikacji pod kątem jakości specyficznej dla PrestaShop jest mniej rygorystyczny. Szablon może przejść ogólną weryfikację ThemeForest, mając jednocześnie problemy specyficzne dla PrestaShop, takie jak brakujące hooki, niekompatybilne struktury szablonów lub konflikty z popularnymi modułami. Wsparcie jest zapewniane przez dewelopera szablonu, a nie przez marketplace, a jakość znacząco różni się między sprzedawcami.

Niezależni sprzedawcy oferują szablony przez własne strony internetowe. To może być najlepsza lub najgorsza opcja w zależności od konkretnego dewelopera. Uznani deweloperzy szablonów PrestaShop z portfolio dobrze ocenianych szablonów, aktywnymi blogami lub samouczkami i widocznym zaangażowaniem w społeczność są często najlepszym źródłem szablonów wysokiej jakości. Dogłębnie rozumieją PrestaShop i budują szablony specjalnie dla tej platformy. Nieznani deweloperzy sprzedający pojedynczy szablon przez niejasną stronę internetową stanowią jednak kategorię najwyższego ryzyka wśród szablonów premium.

Niezależnie od miejsca zakupu, zawsze sprawdź, czy sprzedawca oferuje politykę zwrotów, jakie są warunki wsparcia (czas trwania, czas odpowiedzi, co jest objęte) oraz czy aktualizacje są wliczone w cenę zakupu, czy wymagają dodatkowej subskrypcji.

Na co zwrócić uwagę w dokumentacji szablonu

Jakość dokumentacji jest jednym z najbardziej wiarygodnych wskaźników ogólnej jakości szablonu. Deweloper, który inwestuje czas w tworzenie dokładnej dokumentacji, inwestuje również czas w pisanie czystego kodu, dokładne testowanie i utrzymywanie produktu w czasie.

Dobra dokumentacja szablonu zawiera przewodnik instalacji obejmujący wymagania serwerowe, instrukcje instalacji krok po kroku i rozwiązywanie typowych problemów instalacyjnych. Zawiera przewodnik konfiguracji wyjaśniający każdą opcję w panelu konfiguracji szablonu, ze zrzutami ekranu pokazującymi, co zmienia każde ustawienie. Zawiera przewodnik dostosowywania wyjaśniający, jak utworzyć szablon potomny, które pliki szablonów kontrolują które części sklepu i jak bezpiecznie nadpisywać poszczególne elementy. Zawiera referencję hooków wymieniającą wszystkie obsługiwane hooki i ich lokalizację w układzie. Zawiera dziennik zmian dokumentujący każdą aktualizację z datami, numerami wersji i opisami tego, co się zmieniło. Oraz zawiera informacje o kompatybilności określające, z którymi wersjami PrestaShop przeprowadzono testy.

Słaba dokumentacja to pojedynczy plik PDF z kilkoma zrzutami ekranu pokazującymi kreator instalacji. Jeśli deweloper nie potrafi poświęcić czasu na dokumentację własnego produktu, oszczędza też na innych aspektach.

Całkowity koszt posiadania

Prawdziwy koszt szablonu to nie cena zakupu. To łączna kwota, którą wydajesz na szablon przez cały okres życia Twojego sklepu, wliczając cenę zakupu, koszty dostosowywania, czas deweloperski na poprawki i obejścia, prace optymalizacji wydajności oraz koszt utraconych możliwości z powodu problemów związanych z szablonem.

Rozważ dwa scenariusze. W scenariuszu pierwszym wybierasz darmowy szablon. Wydajesz zero na sam szablon, ale potrzebujesz dewelopera do dostosowania designu (500 euro), naprawy problemów z układem mobilnym (200 euro), dodania brakujących hooków dla dwóch modułów (300 euro) i obejścia konfliktu jQuery (150 euro). Po aktualizacji PrestaShop, która psuje szablon (bo nie jest już utrzymywany), wydajesz 400 euro na migrację do nowego szablonu. Całkowity koszt: 1550 euro plus przestoje i utracona sprzedaż podczas migracji.

W scenariuszu drugim wybierasz szablon premium za 120 euro. Wbudowany konfigurator obsługuje dostosowywanie designu (zero dodatkowych kosztów). Szablon obsługuje wszystkie standardowe hooki (zero dodatkowych kosztów). Deweloper wydaje aktualizację dla nowej wersji PrestaShop (zero dodatkowych kosztów, wliczone w zakup). Kontaktujesz się ze wsparciem, aby rozwiązać drobne pytanie konfiguracyjne (zero dodatkowych kosztów, objęte okresem wsparcia). Całkowity koszt: 120 euro.

Te liczby są ilustracyjne, nie uniwersalne. Niektóre darmowe szablony nie wymagają żadnych dodatkowych inwestycji, a niektóre szablony premium wymagają rozległego dostosowywania mimo swojej ceny. Ale wzorzec się utrzymuje. Tańsza opcja na początku jest często droższą opcją w dłuższej perspektywie.

Rzeczywiste przykłady ukrytych kosztów

Ukryte koszty pojawiają się w obszarach niewidocznych podczas wstępnej oceny. Niekompatybilność z modułami jest częsta: darmowy szablon, który usuwa hook displayProductExtraContent, uniemożliwia korzystanie z modułów dodających zakładki na stronach produktów. Odkrywasz to dopiero po zakupie modułu, a następnie stajesz przed płatnymi modyfikacjami szablonu, ograniczonymi alternatywami modułów lub zmianą szablonu.

Szkody SEO wynikające ze złej struktury HTML to kolejny ukryty koszt. Szablony nieprawidłowo używające znaczników nagłówkowych (wielokrotne znaczniki H1, pomijane poziomy nagłówków) szkodzą pozycjom w sposób trudny do zdiagnozowania i kosztowny w naprawie poprzez przepisywanie szablonów.

Koszty wydajnościowe są znaczące. Jednosekundowy wzrost czasu ładowania strony w sklepie o obrotach 100 000 euro rocznie kosztuje około 7 000 do 10 000 euro rocznie w utraconych konwersjach. Jeśli darmowy szablon ładuje się wolniej niż zoptymalizowany szablon premium, darmowa opcja kosztuje tysiące rocznie w niewidocznych utraconych przychodach.

Dokonanie właściwego wyboru

Oficjalny domyślny szablon PrestaShop jest właściwym wyborem, jeśli posiadasz umiejętności programistyczne, chcesz maksymalnej kontroli i planujesz zainwestować w niestandardowy rozwój. Szablon premium jest właściwym wyborem, jeśli potrzebujesz dopracowanego sklepu szybko, brakuje Ci umiejętności technicznych i chcesz dołączonych modułów ze wsparciem. Darmowy szablon od zewnętrznego dewelopera rzadko jest właściwym wyborem. Jedynym uzasadnionym przypadkiem użycia jest tymczasowy sklep testowy lub proof-of-concept, gdzie szablon zostanie wymieniony przed wdrożeniem produkcyjnym.

Nigdy nie używaj nulled szablonu w żadnych okolicznościach. Zagrożenia bezpieczeństwa są realne, ryzyko prawne jest realne, a finansowe szkody ze skompromitowanego sklepu znacznie przewyższają koszt jakiegokolwiek legalnego szablonu premium.

Końcowe rekomendacje

Zacznij od oficjalnego szablonu PrestaShop, jeśli nie jesteś pewien. Jest darmowy, dobrze utrzymywany, bezpieczny i kompatybilny ze wszystkim. Zawsze możesz później przejść na szablon premium, gdy będziesz miał jaśniejszy obraz swoich potrzeb. Jeśli zdecydujesz się na zakup szablonu premium, priorytetowo traktuj szablony z oficjalnego marketplace'u PrestaShop Addons lub od uznanych deweloperów z udowodnionym dorobkiem. Czytaj recenzje uważnie, zwracając uwagę na wzmianki o jakości wsparcia, częstotliwości aktualizacji i problemach z kompatybilnością. Dokładnie przetestuj demo na urządzeniach mobilnych i sprawdź wydajność za pomocą PageSpeed Insights przed zakupem.

Niezależnie od wybranego szablonu, zachowaj paragon zakupu i informacje o licencji, utwórz szablon potomny dla swoich modyfikacji zamiast edytować szablon bezpośrednio, dokumentuj wszelkie ręczne zmiany wprowadzane w plikach szablonu, testuj aktualizacje szablonu w środowisku stagingowym przed zastosowaniem ich w produkcji i utrzymuj regularne kopie zapasowe, aby móc szybko odzyskać sprawność w przypadku, gdy aktualizacja szablonu spowoduje problemy. Szablon jest fundamentem front endu Twojego sklepu. Zainwestowanie czasu w wybór odpowiedniego — czy to darmowego, czy premium — zapobiega problemom, które są kosztowne i uciążliwe w późniejszej naprawie.

Przeczytaj pełną odpowiedź

Dlaczego rozrost modułów jest cichym zabójcą wydajności PrestaShop

Każdy sklep PrestaShop zaczyna szybko. Potem instalujesz pięć modułów, dziesięć modułów, trzydzieści modułów i nagle Twoja strona główna ładuje się cztery sekundy. Winowajcą rzadko jest jeden ogromny moduł. Zamiast tego są to dziesiątki małych modułów, z których każdy dodaje swój własny plik CSS, swój własny plik JavaScript i swoje własne zapytania do bazy danych przy każdym załadowaniu strony. Ten skumulowany ciężar to właśnie rozrost modułów, i jest to główny powód, dla którego sklepy PrestaShop z czasem stają się wolne.

Problem polega na tym, że większość właścicieli sklepów nigdy nie przeprowadza audytu tego, co ich moduły faktycznie ładują. Instalują moduł na etykiety produktów, kolejny na przyciski udostępniania w mediach społecznościowych, kolejny na popup z newsletterem, kolejny na analitykę, i każdy z nich cicho rejestruje się na hookach takich jak displayHeader i actionFrontControllerSetMedia. Nawet jeśli moduł wyświetla treść tylko na stronach produktów, może nadal ładować swoje pliki CSS i JavaScript na stronie głównej, stronach kategorii, w koszyku i w kasie. Oznacza to, że Twoi klienci pobierają zasoby, których nigdy nie wykorzystają na danej stronie.

Prawidłowy audyt modułów ujawnia dokładnie, co każdy moduł wnosi do wagi Twojej strony. Pokazuje, które moduły są największymi winowajcami, które ładują zasoby niepotrzebnie i które możesz zoptymalizować lub całkowicie usunąć. Ten artykuł przeprowadza Cię przez kompletny proces audytu modułów PrestaShop pod kątem wydajności, wykorzystując DevTools przeglądarki, tryb debugowania PrestaShop i systematyczną analizę.

Krok 1: Włączenie trybu debugowania PrestaShop i profilowania wydajności

Zanim otworzysz narzędzia przeglądarki, musisz włączyć wbudowane funkcje profilowania PrestaShop. PrestaShop posiada tryb debugowania, który ujawnia szczegółowe informacje o wykonywaniu hooków, czasach ładowania modułów i zapytaniach do bazy danych. Aby go włączyć, musisz zmodyfikować dwa ustawienia.

Najpierw przejdź do Zaawansowane parametry, następnie Wydajność w panelu administracyjnym. Ustaw Tryb debugowania na Tak. To włącza raportowanie błędów i dodatkowe logowanie, które pomaga identyfikować problematyczne moduły. Jednak prawdziwa moc tkwi w funkcji profilowania.

Aby włączyć pełne profilowanie, musisz edytować plik defines.inc.php znajdujący się w katalogu config PrestaShop. Znajdź linię definiującą _PS_DEBUG_PROFILING_ i ustaw ją na true. W PrestaShop 1.7 i 8.x ta stała kontroluje, czy pasek profilowania pojawia się na dole każdej strony front office. Po włączeniu przeładuj dowolną stronę sklepu, a zobaczysz szczegółowy panel profilowania pokazujący czasy wykonania dla każdego hooka, każdego modułu i każdego zapytania SQL.

Panel profilowania jest podzielony na kilka sekcji. Sekcja hooków pokazuje każdy hook wykonany na bieżącej stronie, które moduły są podpięte do każdego hooka i jak długo każdy moduł wykonywał się. Sekcja SQL pokazuje każde zapytanie do bazy danych, jego czas wykonania oraz który moduł lub funkcja rdzenia je wywołała. Sekcja modułów daje podsumowanie całkowitego czasu wykonania na moduł we wszystkich hookach.

Zwróć szczególną uwagę na kolumnę całkowitego czasu wykonania. Dobrze zoptymalizowany moduł powinien dodawać mniej niż 10 milisekund do ładowania strony. Jeśli widzisz moduł zajmujący 50, 100 czy nawet 500 milisekund, to poważny problem wydajnościowy wymagający zbadania.

Krok 2: Używanie DevTools przeglądarki do mapowania zasobów modułów

Wbudowane profilowanie PrestaShop informuje o wydajności po stronie serwera, ale nie pokazuje pełnego obrazu tego, co dzieje się w przeglądarce. Do tego potrzebujesz narzędzi deweloperskich przeglądarki. Otwórz Chrome lub Firefox, naciśnij F12 i przejdź do zakładki Sieć (Network).

Przeładuj stronę główną z otwartą zakładką Sieć. Zobaczysz każde żądanie wykonywane przez przeglądarkę: HTML, pliki CSS, pliki JavaScript, obrazy, czcionki i wywołania AJAX. Celem jest identyfikacja, które z tych żądań pochodzą z modułów.

W PrestaShop zasoby modułów podążają za przewidywalnym wzorcem URL. Pliki CSS z modułów są zazwyczaj serwowane ze ścieżek takich jak /modules/nazwamodulu/views/css/nazwapliku.css lub /modules/nazwamodulu/css/nazwapliku.css. Pliki JavaScript podążają za tym samym wzorcem z js zamiast css. Użyj paska filtrów w zakładce Sieć, aby filtrować po „modules/" i natychmiast zobaczysz każdy zasób ładowany z zainstalowanych modułów.

Dla każdego znalezionego zasobu modułu zanotuj następujące informacje: nazwę pliku, jego rozmiar (zarówno przesłany, jak i nieskompresowany) oraz czy ładuje się na bieżącym typie strony. Chcesz zbudować arkusz kalkulacyjny lub prostą listę, która mapuje każdy moduł na jego zasoby. Typowy audyt może ujawnić coś takiego: moduł A ładuje dwa pliki CSS o łącznej wielkości 45 KB i jeden plik JavaScript o 120 KB na każdej stronie, ale wyświetla treść tylko na stronach produktów. Oznacza to, że strony kategorii, strona główna i koszyk ładują 165 KB niepotrzebnych zasobów.

Zakładka Sieć pokazuje również widok kaskadowy (waterfall), który ujawnia, kiedy każdy zasób zaczyna się ładować i jak długo to trwa. Zasoby blokujące renderowanie (CSS blokujący renderowanie i synchroniczny JavaScript) są szczególnie szkodliwe, ponieważ uniemożliwiają przeglądarce wyświetlenie jakiejkolwiek treści do czasu ich załadowania. Szukaj plików JavaScript modułów, które ładują się w sekcji head bez atrybutów async lub defer, ponieważ to one najbardziej wpływają na postrzegany czas ładowania.

Krok 3: Analiza kaskady sieciowej per moduł

Widok kaskadowy w DevTools zasługuje na osobną sekcję, ponieważ ujawnia problemy wydajnościowe, których same rozmiary plików nie pokazują. Gdy patrzysz na kaskadę, chcesz zidentyfikować trzy typy problemów.

Po pierwsze, szukaj zasobów blokujących renderowanie pochodzących z modułów. Pojawiają się one jako paski rozpoczynające się wcześnie w kaskadzie i opóźniające zdarzenie pierwszego malowania (pionowa zielona lub niebieska linia). W PrestaShop pliki CSS dodane przez hook displayHeader lub przez addCSS w setMedia zazwyczaj blokują renderowanie. Jeśli moduł dodaje duży plik CSS, który jest potrzebny tylko na konkretnych stronach, blokuje renderowanie na każdej stronie bez powodu.

Po drugie, szukaj łańcuchów sekwencyjnego ładowania. Niektóre moduły ładują plik JavaScript, który następnie wyzwala ładowanie dodatkowych zasobów: kolejnych plików JavaScript, plików CSS, czcionek webowych lub wywołań zewnętrznych API. Każde ogniwo w tym łańcuchu dodaje opóźnienie. Moduł ładujący jQuery UI, następnie motyw CSS jQuery UI, potem niestandardowy skrypt widgetu, a potem CSS widgetu tworzy łańcuch czterech sekwencyjnych żądań, który może zająć od 200 do 400 milisekund nawet przy szybkim łączu.

Po trzecie, szukaj żądań zewnętrznych. Niektóre moduły wykonują wywołania do zewnętrznych serwerów w celu analityki, śledzenia, ładowania czcionek, widgetów mediów społecznościowych lub danych API. Te żądania są szczególnie niebezpieczne, ponieważ nie masz kontroli nad czasem odpowiedzi zewnętrznego serwera. Moduł udostępniania społecznościowego wywołujący API Facebooka, Twittera i Pinteresta przy każdym załadowaniu strony może dodać 500 milisekund lub więcej opóźnienia, a jeśli którykolwiek z tych serwerów jest wolny lub niedostępny, może zablokować całą stronę przed zakończeniem ładowania.

Aby zmierzyć wpływ per moduł, użyj funkcji blokowania w Chrome DevTools. Kliknij prawym przyciskiem myszy na żądanie z konkretnego modułu i wybierz „Block request domain" lub „Block request URL". Następnie przeładuj stronę i porównaj czas ładowania. Daje to bezpośredni pomiar tego, ile zasoby danego modułu wnoszą do całkowitego czasu ładowania strony. Powtórz to dla każdego modułu, aby zbudować ranking od najcięższych do najlżejszych.

Krok 4: Analiza wykonywania hooków

Zrozumienie, których hooków używa każdy moduł, jest kluczowe dla identyfikacji niepotrzebnego ładowania. System hooków PrestaShop to mechanizm, za pomocą którego moduły wstrzykują swoją treść, zasoby i logikę na strony. Najważniejsze hooki pod kątem wydajności dla stron front office to displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo i displayProductListFunctionalButtons.

Hook displayHeader jest najczęściej nadużywanym hookiem w ekosystemie PrestaShop. Moduły rejestrują się na tym hooku, aby dodać swoje pliki CSS i JavaScript do sekcji head strony. Problem polega na tym, że displayHeader uruchamia się na każdej stronie front office. Jeśli moduł rejestruje się na displayHeader bez sprawdzania, którą stronę klient aktualnie przegląda, ładuje swoje zasoby wszędzie.

Aby zobaczyć, które moduły są zarejestrowane na poszczególnych hookach, przejdź do Wygląd, następnie Pozycje w panelu administracyjnym. Ta strona pokazuje każdy hook i każdy moduł do niego podpięty. Sprawdź szczególnie displayHeader i actionFrontControllerSetMedia. Policz, ile modułów jest tam zarejestrowanych. W typowym sklepie z 30 lub więcej zainstalowanymi modułami możesz znaleźć od 15 do 20 modułów na samym displayHeader. Każdy z nich dodaje co najmniej jeden plik CSS lub JavaScript do każdej strony.

Teraz skrzyżuj te dane z wynikami z DevTools. Dla każdego modułu na displayHeader sprawdź, czy ten moduł rzeczywiście musi ładować się na bieżącej stronie. Moduł recenzji produktów potrzebuje swoich zasobów tylko na stronach produktów. Moduł listy życzeń potrzebuje swoich zasobów tylko na stronach produktów i konta. Moduł tabeli rozmiarów potrzebuje swoich zasobów tylko na stronach produktów. A mimo to wszystkie ładują się na stronie głównej, stronach kategorii, stronach CMS i w procesie składania zamówienia.

Dane profilowania z kroku 1 dodają kolejny wymiar do tej analizy. Niektóre moduły nie tylko ładują niepotrzebne zasoby, ale także wykonują kosztowny kod PHP przy każdym wywołaniu hooka. Moduł, który uruchamia zapytania do bazy danych w swojej metodzie hookDisplayHeader, aby sprawdzić wartości konfiguracyjne lub pobrać dane, marnuje zasoby serwera na każdej stronie, nawet gdy jego wynik nie jest potrzebny.

Krok 5: Identyfikacja najcięższych modułów

Mając dane z profilowania, DevTools i analizy hooków, możesz teraz uszeregować moduły według ich wpływu na wydajność. Utwórz listę z następującymi kolumnami: nazwa modułu, liczba ładowanych plików CSS, łączny rozmiar CSS, liczba ładowanych plików JavaScript, łączny rozmiar JavaScript, czas wykonania serwera z profilowania, liczba zapytań do bazy danych oraz strony, na których moduł faktycznie wyświetla treść.

Moduły, które uzyskują najwyższe wyniki w tych metrykach, są Twoimi największymi winowajcami. Z naszego doświadczenia w audytowaniu setek sklepów PrestaShop wynika, że następujące kategorie modułów są konsekwentnie najgorszymi pod względem wydajności.

Moduły budowania stron (page builder) są często najcięższe. Ładują duże frameworki CSS, wiele bibliotek JavaScript dla swojego edytora wizualnego, a czasem nawet ładują zasoby edytora na front office. Page builder ładujący 300 KB CSS i 500 KB JavaScript na każdej stronie nie jest niczym niezwykłym.

Moduły mediów społecznościowych osadzające widgety z Facebooka, Instagrama czy Twittera ładują zewnętrzne skrypty, które są zarówno duże, jak i nieprzewidywalne pod względem czasu ładowania. Pojedynczy widget kanału Instagram może dodać 1 MB lub więcej JavaScript do Twojej strony.

Moduły analityki i śledzenia korzystające z wielu pikseli śledzących ładują skrypty z zewnętrznych domen. Każdy piksel śledzący zazwyczaj dodaje od 20 do 50 KB JavaScript plus dodatkowe żądania sieciowe dla obrazów pikseli i wywołań API.

Moduły sliderów i karuzel ładują duże biblioteki JavaScript, takie jak Slick, Owl Carousel czy Swiper, wraz z ich CSS. Nawet jeśli slider pojawia się tylko na stronie głównej, zasoby często ładują się na każdej stronie.

Moduły czatu na żywo ładują znaczące paczki JavaScript dla interfejsu widgetu czatu, zazwyczaj od 100 do 300 KB, plus nawiązują połączenia WebSocket, które zużywają zasoby przez całą sesję przeglądania.

Krok 6: Pomiar wydajności przed i po zmianach

Zanim zaczniesz wyłączać hooki lub usuwać moduły, ustal bazowy pomiar. Użyj wielu narzędzi, aby uzyskać pełny obraz.

W Chrome DevTools przejdź do zakładki Lighthouse i uruchom audyt wydajności. Zapisz Wynik Wydajności, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) i Cumulative Layout Shift (CLS). Uruchom audyt trzy razy i uśrednij wyniki, aby uwzględnić zmienność.

Użyj zakładki Wydajność (Performance) w DevTools, aby nagrać ślad ładowania strony. Daje to wykres płomieni pokazujący dokładnie, co przeglądarka robi w każdej milisekundzie. Szukaj długich zadań (bloków dłuższych niż 50 milisekund) i identyfikuj, które skrypty modułów je powodują.

Zmierz również wagę strony. W zakładce Sieć sprawdź łączną liczbę żądań i łączny przesłany rozmiar na dole panelu. Filtruj po CSS i JS osobno, aby uzyskać sumy specyficzne dla modułów.

Zapisz wszystkie te liczby przed wprowadzeniem jakichkolwiek zmian. Następnie, w miarę optymalizowania modułów przez odpinanie ich od niepotrzebnych hooków lub całkowite wyłączanie, ponownie uruchom te same pomiary. Różnica powie Ci dokładnie, ile wydajności zyskałeś z każdej zmiany.

Dobrze przeprowadzony audyt modułów zazwyczaj redukuje wagę strony o 30 do 50 procent i poprawia czasy ładowania o jedną do dwóch sekund. W sklepach z wieloma słabo zoptymalizowanymi modułami poprawa może być jeszcze bardziej dramatyczna.

Krok 7: Wyłączanie niepotrzebnych hooków

Gdy już zidentyfikujesz, które moduły ładują zasoby na stronach, gdzie nie są potrzebne, masz kilka opcji optymalizacji. Najprostszym podejściem jest odpięcie modułów od hooków, na których nie muszą być obecne.

Przejdź do Wygląd, następnie Pozycje w panelu administracyjnym. Znajdź moduł na hooku, z którego chcesz go usunąć. Kliknij ikonę kosza lub przycisk odpięcia, aby usunąć moduł z tego konkretnego hooka. To zapobiega wykonywaniu modułu na tym hooku całkowicie.

Jednak zachowaj ostrożność z tym podejściem. Niektóre moduły używają displayHeader nie tylko do ładowania CSS i JavaScript, ale także do wykonywania niezbędnych zadań inicjalizacyjnych. Odpięcie takiego modułu od displayHeader może zepsuć jego funkcjonalność na stronach, gdzie jest rzeczywiście potrzebny. Zawsze testuj w środowisku stagingowym lub co najmniej przetestuj konkretne strony, na których moduł powinien nadal działać po odpięciu.

Lepszym długoterminowym podejściem jest skontaktowanie się z deweloperem modułu i poproszenie o warunkowe ładowanie zasobów. Dobrze zakodowany moduł powinien sprawdzać bieżący kontroler lub typ strony przed załadowaniem swoich zasobów. Na przykład moduł recenzji produktów powinien ładować swoje CSS i JavaScript tylko wtedy, gdy bieżący kontroler to ProductController. W ten sposób moduł pozostaje podpięty do displayHeader dla kompatybilności, ale ładuje zasoby tylko wtedy, gdy są faktycznie potrzebne.

Jeśli czujesz się komfortowo edytując kod modułu, możesz samodzielnie dodać warunkowe sprawdzenia. W metodzie hookDisplayHeader lub hookActionFrontControllerSetMedia modułu dodaj sprawdzenie nazwy bieżącego kontrolera. Jeśli kontroler nie jest tym, na którym moduł wyświetla treść, zakończ funkcję wcześniej bez dodawania jakichkolwiek zasobów. To najbardziej celowa i efektywna optymalizacja, jaką możesz wykonać.

Praktyczna lista kontrolna audytu modułów

Podsumowując cały proces audytu, oto praktyczna lista kontrolna, którą możesz stosować. Zacznij od włączenia profilowania debugowania PrestaShop. Otwórz zakładkę Sieć w DevTools i przeładuj stronę główną. Filtruj żądania po ścieżce modules i wylistuj każdy zasób modułu. Zanotuj rozmiar i typ każdego zasobu. Sprawdź Wygląd, następnie Pozycje pod kątem modułów na displayHeader. Skrzyżuj rejestracje hooków z miejscami, gdzie moduły faktycznie wyświetlają treść. Użyj blokowania żądań w DevTools, aby zmierzyć wpływ per moduł. Zapisz bazowe wyniki Lighthouse. Odpnij moduły od hooków, na których nie są potrzebne. Dodaj warunkowe ładowanie do modułów ładujących się globalnie. Ponownie zmierz wyniki Lighthouse po każdej zmianie. Udokumentuj swoje ustalenia i zmiany na przyszłość.

To systematyczne podejście zapewnia, że nie przegapisz żadnych możliwości optymalizacji i daje konkretne dane uzasadniające każdą wprowadzoną zmianę. Rozrost modułów nie jest tajemnicą. To mierzalny, rozwiązywalny problem, a każdy sklep PrestaShop korzysta z dokładnego audytu modułów przynajmniej raz w roku.

Przeczytaj pełną odpowiedź

Główna przyczyna: jak system hooków PrestaShop obsługuje zasoby

Jeśli kiedykolwiek sprawdzałeś kod źródłowy swojego sklepu PrestaShop i zastanawiałeś się, dlaczego moduł, który wyświetla widget tylko na stronach produktów, ładuje swoje CSS i JavaScript na stronie głównej, stronach kategorii, a nawet w kasie — nie jesteś sam. To jeden z najczęstszych problemów wydajnościowych w ekosystemie PrestaShop, który wynika ze sposobu działania systemu hooków w połączeniu z leniwymi praktykami programistycznymi.

PrestaShop wykorzystuje architekturę opartą na hookach, aby umożliwić modułom wstrzykiwanie treści, zasobów i logiki do różnych części strony. Gdy moduł musi dodać pliki CSS lub JavaScript do strony, zazwyczaj robi to za pośrednictwem jednego z dwóch hooków: displayHeader lub actionFrontControllerSetMedia. Oba te hooki uruchamiają się na każdej stronie front office bez wyjątku. W samym systemie hooków nie istnieje wbudowany mechanizm ograniczający wywołanie hooka do konkretnych typów stron. To całkowicie odpowiedzialność dewelopera modułu, aby sprawdzić, która strona jest ładowana i zdecydować, czy dodawać zasoby, czy nie.

Problem polega na tym, że wielu deweloperów modułów idzie na skróty. Zamiast pisać logikę warunkową sprawdzającą bieżący kontroler, po prostu rejestrują swoje zasoby przy każdym wywołaniu hooka. Rozumowanie jest proste: jeśli zasoby są zawsze załadowane, moduł zawsze zadziała niezależnie od tego, gdzie pojawia się jego treść. To podejście „odpal i zapomnij" gwarantuje, że moduł działa poprawnie, ale gwarantuje również słabą wydajność.

Jak nadużywanie hooka displayHeader powoduje rozrost stron

Hook displayHeader jest głównym mechanizmem, za pomocą którego moduły dodają treść do sekcji HTML head na każdej stronie. Gdy moduł implementuje metodę hookDisplayHeader, PrestaShop wywołuje tę metodę przy każdym załadowaniu strony front office. Wewnątrz tej metody moduły zazwyczaj wywołują $this->context->controller->addCSS() i $this->context->controller->addJS(), aby zarejestrować swoje pliki zasobów.

Oto co dzieje się w typowym sklepie z 25 zainstalowanymi modułami. Piętnaście z nich ma metodę hookDisplayHeader. Każdy dodaje od jednego do czterech plików CSS i JavaScript. Oznacza to, że każda strona w Twoim sklepie ładuje od 15 do 60 dodatkowych żądań HTTP wyłącznie z modułów, niezależnie od tego, czy te moduły wyświetlają cokolwiek na bieżącej stronie.

Rozważ konkretny przykład. Moduł dodający popup z przewodnikiem po rozmiarach na stronach produktów potrzebuje jednego pliku CSS do stylizacji popupu i jednego pliku JavaScript do obsługi zachowania popupu. Jeśli deweloper zarejestruje te zasoby w hookDisplayHeader bez żadnego warunkowego sprawdzenia, oba pliki ładują się na stronie głównej, na każdej stronie kategorii, na stronie koszyka, w kasie i na każdej stronie CMS. Przewodnik po rozmiarach nigdy nie pojawi się na żadnej z tych stron, ale przeglądarka i tak pobiera, parsuje i przetwarza pliki CSS i JavaScript.

Pomnóż to przez każdy moduł, który podąża za tym samym wzorcem, i zaczniesz rozumieć, dlaczego niektóre sklepy PrestaShop ładują 2 MB lub więcej zasobów modułów na stronach, gdzie większość tych zasobów jest całkowicie zbędna.

Hook actionFrontControllerSetMedia

PrestaShop 1.7 wprowadził hook actionFrontControllerSetMedia jako bardziej nowoczesną alternatywę dla displayHeader do rejestracji zasobów. Ten hook został zaprojektowany specjalnie do rejestrowania plików CSS i JavaScript przy użyciu nowych metod registerStylesheet i registerJavascript. Te metody oferują przewagi nad starszymi funkcjami addCSS i addJS, w tym możliwość ustawiania priorytetu ładowania, określania atrybutów async lub defer oraz kontrolowania pozycji (head lub bottom) znaczników skryptów.

Jednak actionFrontControllerSetMedia cierpi na dokładnie ten sam fundamentalny problem co displayHeader: uruchamia się na każdej stronie. Moduł rejestrujący zasoby w hookActionFrontControllerSetMedia bez sprawdzania bieżącego kontrolera ładuje te zasoby wszędzie, tak samo jak starsze podejście.

Jedyną różnicą jest metoda rejestracji, nie zakres ładowania. Czy deweloper użyje addCSS w displayHeader, czy registerStylesheet w actionFrontControllerSetMedia, wynik jest taki sam, jeśli nie doda logiki warunkowej. Zasoby ładują się globalnie.

Prawidłowe ładowanie warunkowe: co robią dobre moduły

Dobrze opracowany moduł sprawdza, którą stronę przegląda klient, zanim załaduje jakiekolwiek zasoby. Standardowym sposobem na to w PrestaShop jest sprawdzenie nazwy kontrolera. Każda strona front office jest obsługiwana przez konkretny kontroler: IndexController dla strony głównej, CategoryController dla stron kategorii, ProductController dla stron produktów, CartController dla koszyka i tak dalej.

Wewnątrz metody hookDisplayHeader lub hookActionFrontControllerSetMedia deweloper może uzyskać dostęp do bieżącego kontrolera przez $this->context->controller. Sprawdzając nazwę klasy lub właściwość php_self kontrolera, moduł może zdecydować, czy ładować swoje zasoby. Moduł recenzji produktów, na przykład, powinien sprawdzić, czy bieżąca strona jest stroną produktu i załadować swoje CSS i JavaScript tylko w takim przypadku.

To podejście warunkowe nie jest trudne do wdrożenia. Dodaje może od pięciu do dziesięciu linii kodu do metody hooka. Jednak zaskakująco wiele modułów, w tym popularne płatne moduły na marketplace PrestaShop Addons i znane darmowe moduły, całkowicie pomija to sprawdzenie. Powodem jest połączenie wygody dewelopera i faktu, że PrestaShop nie wymusza ani nawet nie zachęca do warunkowego ładowania w swojej dokumentacji rozwoju modułów.

Niektórzy deweloperzy argumentują, że globalne ładowanie zasobów zapewnia kompatybilność z niestandardowymi szablonami lub nietypowymi konfiguracjami stron, gdzie treść modułu może pojawić się niespodziewanie. Choć ten argument ma ziarno prawdy, nie uzasadnia kosztu wydajnościowego. Lepszym podejściem jest domyślne warunkowe ładowanie zasobów z opcją konfiguracyjną umożliwiającą globalne ładowanie dla sklepów, które tego potrzebują.

Metoda setMedia: najlepsze praktyki dla deweloperów modułów

Dla deweloperów modułów czytających ten artykuł, oto najlepsze praktyki ładowania zasobów, które szanują wydajność stron użytkowników.

Po pierwsze, zawsze używaj hooka actionFrontControllerSetMedia zamiast displayHeader do rejestracji zasobów w PrestaShop 1.7 i nowszych. Nowszy hook zapewnia lepszą kontrolę nad zachowaniem ładowania zasobów i oddziela rejestrację zasobów od generowania HTML.

Po drugie, zawsze sprawdzaj bieżący kontroler przed rejestracją zasobów. Użyj podejścia z białą listą: zdefiniuj listę kontrolerów, na których Twój moduł wyświetla treść, i rejestruj zasoby tylko wtedy, gdy bieżący kontroler jest na tej liście. To podejście jest bardziej utrzymywalne niż czarna lista, ponieważ nowe typy stron dodane w przyszłych wersjach PrestaShop nie będą przypadkowo ładować Twoich zasobów.

Po trzecie, używaj registerStylesheet i registerJavascript zamiast addCSS i addJS. Nowsze metody pozwalają określić id dla każdego zasobu, co umożliwia szablonom i innym modułom czyste nadpisywanie lub usuwanie Twoich zasobów. Obsługują też ustawienia priorytetów kontrolujące kolejność ładowania zasobów.

Po czwarte, rozważ, czy Twój JavaScript naprawdę musi ładować się w sekcji head, czy może ładować się na dole strony z atrybutem defer. JavaScript w sekcji head blokuje renderowanie, co oznacza, że przeglądarka nie może wyświetlić żadnej treści, dopóki Twój skrypt nie zakończy pobierania i parsowania. Przeniesienie skryptów na dół lub dodanie defer eliminuje to blokowanie renderowania.

Po piąte, minimalizuj rozmiary plików zasobów. Minifikuj pliki CSS i JavaScript przed dystrybucją modułu. Usuń nieużywane reguły CSS. Unikaj dołączania całych bibliotek jak jQuery UI czy Bootstrap, gdy używasz tylko niewielkiej części ich funkcjonalności. Każdy kilobajt się liczy, gdy zasoby Twojego modułu ładują się przy tysiącach odsłon dziennie.

Mierzenie wpływu globalnych zasobów na wydajność

Aby zrozumieć, ile globalne ładowanie zasobów kosztuje Twój sklep, potrzebujesz konkretnych pomiarów. Otwórz Chrome DevTools na stronie głównej i przejdź do zakładki Sieć (Network). Przeładuj stronę i filtruj żądania po ścieżce /modules/. Policz łączną liczbę żądań i ich sumaryczny rozmiar. To jest narzut zasobów modułów na stronie, gdzie większość modułów nie wyświetla żadnej treści.

Teraz zrób to samo na stronie produktu, gdzie wiele modułów legalnie potrzebuje swoich zasobów. Porównaj liczby. W dobrze zoptymalizowanym sklepie strona produktu powinna ładować znacznie więcej zasobów modułów niż strona główna, ponieważ to tam większość modułów wyświetla swoją treść. W słabo zoptymalizowanym sklepie liczby są prawie identyczne, ponieważ każdy moduł ładuje wszystko wszędzie.

Konkretny benchmark z audytów w rzeczywistych sklepach: sklep z 35 zainstalowanymi modułami ładował 1,8 MB CSS i JavaScript modułów na stronie głównej. Po wdrożeniu warunkowego ładowania we wszystkich modułach zasoby modułów na stronie głównej spadły do 340 KB. Strona produktu, gdzie większość modułów legalnie potrzebowała swoich zasobów, przeszła z 2,1 MB do 1,4 MB. Czas ładowania strony głównej poprawił się o 1,3 sekundy, a wynik wydajności Lighthouse wzrósł z 42 do 71.

Te liczby nie są niczym niezwykłym. Globalne ładowanie zasobów jest jednym z największych źródeł niepotrzebnej wagi stron w sklepach PrestaShop, a jego naprawienie często przynosi najbardziej dramatyczne poprawy wydajności.

Jak zidentyfikować problematyczne moduły w swoim sklepie

Znalezienie modułów ładujących zasoby globalnie wymaga systematycznego podejścia. Zacznij od zakładki Sieć w DevTools, jak opisano powyżej. Dla każdego zasobu modułu znalezionego na stronie głównej zadaj sobie pytanie: czy ten moduł wyświetla jakąkolwiek treść na stronie głównej? Jeśli odpowiedź brzmi nie, ten moduł ładuje zasoby niepotrzebnie.

Innym podejściem jest użycie trybu profilowania debugowania PrestaShop. Gdy profilowanie jest włączone (poprzez ustawienie _PS_DEBUG_PROFILING_ na true w pliku config/defines.inc.php), PrestaShop wyświetla szczegółowe dane o wykonywaniu hooków na dole każdej strony. Te dane pokazują dokładnie, które moduły wykonują się na każdym hooku i jak długo to zajmuje. Każdy moduł, który wykonuje się na displayHeader lub actionFrontControllerSetMedia, ale nie wykonuje się na żadnym hooku wyświetlającym widoczne wyjście na bieżącej stronie, jest kandydatem do optymalizacji.

Możesz również sprawdzić programistycznie, analizując kod źródłowy każdego modułu. Sprawdź metody hookDisplayHeader i hookActionFrontControllerSetMedia w głównym pliku PHP modułu. Jeśli metoda zawiera wywołania addCSS, addJS, registerStylesheet lub registerJavascript bez jakichkolwiek warunkowych sprawdzeń nazwy kontrolera, ten moduł ładuje zasoby globalnie.

Dla sklepów z wieloma modułami ta ręczna weryfikacja może być czasochłonna. Praktycznym skrótem jest skupienie się najpierw na największych zasobach. Posortuj zasoby modułów w zakładce Sieć według rozmiaru i zacznij badać największe pliki. Plik JavaScript o wielkości 200 KB ładujący się globalnie jest znacznie większym problemem niż plik CSS o wielkości 3 KB, więc ustal odpowiednie priorytety.

Żądanie poprawek od deweloperów modułów

Gdy zidentyfikujesz moduł ładujący zasoby globalnie, Twoim pierwszym krokiem powinno być skontaktowanie się z deweloperem i poproszenie o poprawkę. Większość profesjonalnych deweloperów modułów jest otwarta na prośby o poprawę wydajności, szczególnie gdy możesz dostarczyć konkretne dane o wpływie.

Napisz jasną, techniczną wiadomość wyjaśniającą problem. Wspomnij, że metoda hookDisplayHeader modułu ładuje CSS i JavaScript na każdej stronie bez sprawdzania bieżącego kontrolera. Określ, które strony faktycznie potrzebują zasobów, a które ładują je niepotrzebnie. Dołącz rozmiary plików i szacowany wpływ na wydajność. Jeśli masz wyniki Lighthouse pokazujące porównanie przed i po zablokowaniu zasobów modułu, dołącz je.

Jeśli deweloper jest responsywny, zazwyczaj wyda aktualizację w ciągu kilku tygodni dodającą warunkowe ładowanie. Jeśli deweloper jest niereaktywny lub odrzuca problem, masz kilka opcji: samodzielnie wdrożyć warunkowe ładowanie, edytując kod modułu, użyć modułu wydajnościowego, który może selektywnie blokować zasoby na konkretnych stronach, lub znaleźć alternatywny moduł, który podąża za lepszymi praktykami programistycznymi.

Obejścia, gdy nie możesz modyfikować modułu

Czasami nie możesz bezpośrednio modyfikować modułu. Może być zaszyfrowany przez IonCube, może to być moduł, którego nie chcesz utrzymywać jako fork, lub moduł może nadpisywać Twoje zmiany przy każdej aktualizacji. W takich przypadkach potrzebujesz obejść.

Jednym skutecznym obejściem jest stworzenie małego niestandardowego modułu, który odpina problematyczny moduł od displayHeader i actionFrontControllerSetMedia, a następnie ponownie dodaje zasoby tylko na stronach, gdzie są potrzebne. Ten niestandardowy moduł użyłby hooka actionFrontControllerSetMedia z wysokim priorytetem (aby wykonywał się po problematycznym module) i wywoływał Media::unregisterStylesheet i Media::unregisterJavascript, aby usunąć globalnie załadowane zasoby. Następnie na stronach, gdzie zasoby są faktycznie potrzebne, ponownie by je zarejestrował.

Innym obejściem jest użycie pliku Theme.yml do nadpisywania zasobów modułów. W PrestaShop 1.7 i nowszych plik konfiguracyjny theme.yml szablonu może usuwać konkretne zasoby modułów z ładowania. To rozwiązanie na poziomie szablonu, które utrzymuje się mimo aktualizacji modułów. Jednak usuwa zasoby ze wszystkich stron, nie selektywnie, więc musiałbyś połączyć to z ponownym dodawaniem zasobów na konkretnych stronach przez niestandardowy moduł lub szablon.

Trzecia opcja, dostępna w PrestaShop 8.x, to wykorzystanie wbudowanych funkcji priorytetów i usuwania w systemie zarządzania zasobami. PrestaShop 8 ulepszył potok zasobów, dając szablonom większą kontrolę nad tym, które zasoby modułów się ładują. Sprawdź dokumentację swojego szablonu, aby uzyskać szczegółowe instrukcje dotyczące wykorzystania tych funkcji.

Niezależnie od wybranego podejścia, zawsze dokładnie testuj po wprowadzeniu zmian. Usunięcie CSS modułu może zepsuć jego wygląd wizualny, a usunięcie JavaScript może zepsuć interaktywne funkcje. Przetestuj każdy typ strony, na którym moduł powinien nadal działać poprawnie.

Zapobieganie: ocena modułów przed instalacją

Najlepszym sposobem na uniknięcie problemów z globalnym ładowaniem zasobów jest ocena modułów przed ich instalacją. Choć nie zawsze jest to możliwe, istnieją sprawdzenia, które możesz wykonać.

Jeśli moduł udostępnia sklep demonstracyjny, odwiedź go i sprawdź stronę główną za pomocą DevTools. Sprawdź, czy zasoby modułu ładują się na stronach, gdzie moduł nie wyświetla treści. Jeśli zasoby ładują się globalnie w demo, będą ładować się globalnie również w Twoim sklepie.

Jeśli masz dostęp do kodu źródłowego modułu przed zakupem (niektóre marketplace'y udostępniają podglądy kodu), sprawdź metody hookDisplayHeader i hookActionFrontControllerSetMedia. Poszukaj logiki warunkowego ładowania. Brak jakiegokolwiek sprawdzenia kontrolera jest sygnałem ostrzegawczym.

Przeczytaj recenzje modułu i forum wsparcia. Użytkownicy świadomi wydajności często zgłaszają problemy z globalnym ładowaniem zasobów w recenzjach. Jeśli wielu użytkowników skarżyło się na spowalnianie sklepu przez moduł, potraktuj tę opinię poważnie.

Na koniec weź pod uwagę ogólną jakość kodu dewelopera. Deweloperzy, którzy stosują najlepsze praktyki w jednym obszarze, zazwyczaj stosują je również w innych. Jeśli kod modułu jest czysty, dobrze udokumentowany i przestrzega standardów kodowania PrestaShop, bardziej prawdopodobne jest, że prawidłowo obsługuje ładowanie zasobów. Jeśli kod jest chaotyczny i źle ustrukturyzowany, globalne ładowanie zasobów to prawdopodobnie tylko jeden z wielu problemów.

Przeczytaj pełną odpowiedź

Dlaczego warto używać Cloudflare z PrestaShop?

Cloudflare znajduje się między Twoimi odwiedzającymi a serwerem PrestaShop, działając jako reverse proxy zapewniający ochronę przed DDoS, Web Application Firewall (WAF), globalny CDN dla zasobów statycznych oraz terminację SSL/TLS. Prawidłowo skonfigurowany Cloudflare może dramatycznie poprawić czasy ładowania stron Twojego sklepu, zmniejszyć przepustowość serwera i blokować złośliwy ruch, zanim w ogóle dotrze do Twojego hostingu. Jednak źle skonfigurowany Cloudflare jest jedną z najczęstszych przyczyn pętli przekierowań, uszkodzonego procesu składania zamówienia, nieprawidłowych adresów IP klientów i katastrof z buforowaniem w PrestaShop. Ten przewodnik przeprowadzi Cię przez każdy krok prawidłowej konfiguracji.

Krok 1: Konfiguracja DNS

Po dodaniu domeny do Cloudflare musisz skonfigurować rekordy DNS. Najważniejszą decyzją jest to, które rekordy powinny być proxowane (pomarańczowa chmurka) a które działać jako DNS-only (szara chmurka).

Rekordy proxowane (pomarańczowa chmurka):

Twój główny rekord A lub AAAA wskazujący na IP serwera (np. example.com i www.example.com)
Wszelkie rekordy CNAME dla subdomen obsługujących treści webowe

Rekordy DNS-only (szara chmurka):

Rekordy MX (poczta) — te nigdy nie mogą być proxowane
Rekordy używane do FTP, SSH lub innych usług nie-HTTP
Rekordy wskazujące na serwery pocztowe (np. mail.example.com)

Ważne: Jeśli używasz subdomeny dla panelu administracyjnego PrestaShop (np. admin.example.com), możesz ją proxować, ale pamiętaj o regułach buforowania omówionych później. Nigdy nie twórz rekordu DNS, który niepotrzebnie ujawnia prawdziwy adres IP Twojego serwera — gdy Twoja główna domena jest proxowana, atakujący znający prawdziwe IP mogą całkowicie ominąć Cloudflare. Rozważ zmianę IP serwera po włączeniu Cloudflare, jeśli wcześniej było publicznie znane.

Krok 2: Konfiguracja SSL/TLS — używaj Full (Strict)

To jest absolutnie najważniejsze ustawienie. Przejdź do SSL/TLS > Overview w panelu Cloudflare.

Zawsze używaj trybu Full (Strict). Oto co robi każdy tryb i dlaczego pozostałe są niewłaściwe dla PrestaShop:

Off: Brak szyfrowania. Nigdy nie używaj tego dla sklepu e-commerce.
Flexible: Szyfruje ruch między odwiedzającym a Cloudflare, ale wysyła niezaszyfrowane HTTP do Twojego serwera. To powoduje nieskończone pętle przekierowań w PrestaShop, ponieważ serwer widzi HTTP, ustawia force_ssl = 1, przekierowuje na HTTPS, Cloudflare dostarcza go przez HTTPS, ale następne żądanie trafia na serwer ponownie jako HTTP. To jest najczęstszy błąd Cloudflare z PrestaShop.
Full: Szyfruje end-to-end, ale nie weryfikuje certyfikatu SSL Twojego serwera. Akceptowalne, ale nie zalecane.
Full (Strict): Szyfruje end-to-end i weryfikuje certyfikat serwera źródłowego. To jest prawidłowe ustawienie. Jeśli nie masz płatnego certyfikatu SSL, użyj darmowego Cloudflare Origin Certificate (ważnego przez 15 lat) zainstalowanego na Twoim serwerze.

Aby zainstalować Cloudflare Origin Certificate: przejdź do SSL/TLS > Origin Server > Create Certificate. Pobierz certyfikat i klucz prywatny, zainstaluj je na swoim serwerze webowym (Apache lub Nginx) i uruchom ponownie usługę. Ten certyfikat jest ważny tylko dla ruchu przechodzącego przez Cloudflare — będzie wyświetlany jako nieważny przy bezpośrednim dostępie.

W sekcji SSL/TLS > Edge Certificates włącz:

Always Use HTTPS: Tak
Automatic HTTPS Rewrites: Tak (naprawia mieszaną treść przez przepisywanie URL-ów HTTP na HTTPS)
Minimum TLS Version: TLS 1.2

Krok 3: Konfiguracja buforowania

Domyślne zachowanie buforowania Cloudflare działa dobrze dla zasobów statycznych, ale może powodować poważne problemy, jeśli buforuje dynamiczne strony PrestaShop. Przejdź do Caching > Configuration.

Zalecane ustawienia:

Caching Level: Standard
Browser Cache TTL: Respect Existing Headers (pozwól PrestaShop kontrolować buforowanie przeglądarki przez ustawienia CCC)
Always Online: Wyłącz to dla sklepów e-commerce — pokazywanie nieaktualnych stron produktów ze złymi cenami lub produktami niedostępnymi jest gorsze niż pokazanie strony błędu

Co Cloudflare buforuje domyślnie: Tylko pliki statyczne z rozszerzeniami takimi jak .js, .css, .png, .jpg, .gif, .svg, .woff2, .ico. NIE buforuje domyślnie stron HTML, co jest prawidłowe dla PrestaShop. Nie włączaj „Cache Everything" bez odpowiednich reguł obejścia, bo Twoi klienci będą widzieć koszyki, sesje i dane osobowe innych osób.

Krok 4: Page Rules i Cache Rules

Page Rules (lub nowsze Cache Rules) pozwalają dostosować zachowanie Cloudflare dla konkretnych wzorców URL. Dla PrestaShop potrzebujesz reguł chroniących panel administracyjny i proces składania zamówienia przed buforowaniem, jednocześnie optymalizując dostarczanie treści statycznych.

Reguła 1: Ominięcie cache dla panelu administracyjnego

Utwórz regułę pasującą do example.com/admin* (zamień „admin" na swoją rzeczywistą nazwę katalogu panelu administracyjnego):

Cache Level: Bypass
Disable Performance: Tak (wyłącza Rocket Loader, Mirage i inne optymalizacje, które mogą psuć JS panelu administracyjnego)
Security Level: High

Reguła 2: Ominięcie cache dla kasy i koszyka

Utwórz regułę pasującą do example.com/order* i kolejną dla example.com/cart* (lub użyj example.com/*order* jeśli używasz przyjaznych URL-ów):

Cache Level: Bypass
Disable Performance: Tak

Jeśli Twój PrestaShop używa URL-ów kasy generowanych przez moduły (np. z modułów express checkout), dodaj reguły również dla tych ścieżek.

Reguła 3: Ominięcie cache dla konta klienta

Dopasuj example.com/my-account* lub example.com/identity* i wszelkie inne strony klienta wymagające uwierzytelnienia:

Cache Level: Bypass

Reguła 4: Agresywne buforowanie zasobów statycznych

Dopasuj example.com/themes/* i example.com/js/* i example.com/modules/*/views/css/*:

Cache Level: Cache Everything
Edge Cache TTL: 1 miesiąc
Browser Cache TTL: 1 tydzień

Uwaga dotycząca nowszego systemu Rules: Cloudflare migruje z Page Rules na oddzielne Cache Rules, Configuration Rules i Transform Rules. Logika jest taka sama — utwórz Cache Rule z niestandardowym wyrażeniem filtrującym jak (http.request.uri.path contains \"/admin\") i ustaw akcję na bypass cache.

Krok 5: Rocket Loader — wyłącz go

Rocket Loader to funkcja Cloudflare, która odracza ładowanie całego JavaScript na Twoich stronach. Przejdź do Speed > Optimization > Content Optimization i wyłącz Rocket Loader.

Choć brzmi korzystnie, Rocket Loader powoduje poważne problemy z PrestaShop:

Zepsute przyciski dodawania do koszyka: PrestaShop polega na inline'owych blokach JavaScript i handlerach jQuery ready, które muszą wykonywać się w kolejności. Rocket Loader odracza je i zmienia kolejność.
Awarie modułów płatności: Bramki płatności jak PayPal, Stripe i Mollie wstrzykują własny JavaScript, z którym Rocket Loader interferuje, powodując awarie kasy i utracone zamówienia.
Uszkodzenie panelu administracyjnego: Panel administracyjny intensywnie wykorzystuje inline'owy JavaScript do walidacji formularzy, wywołań AJAX i stron konfiguracji modułów. Rocket Loader psuje to wszystko.
Moduły zgody na cookies i RODO: Polegają na blokowaniu pewnych zasobów do momentu udzielenia zgody. Rocket Loader podważa to, przepisując sposób ładowania wszystkich zewnętrznych zasobów.

Nawet jeśli ustawisz Page Rule wyłączający funkcje wydajnościowe na /admin*, front office i tak się zepsuje. Najbezpieczniejszym podejściem jest wyłączenie Rocket Loadera globalnie.

Krok 6: Przywracanie prawdziwego IP

Gdy Cloudflare proxuje ruch, Twój serwer widzi adresy IP Cloudflare zamiast prawdziwych IP odwiedzających. To psuje PrestaShop na kilka sposobów: rekordy zamówień pokazują IP Cloudflare, wykrywanie oszustw zawodzi, geolokalizacja jest błędna, ograniczanie szybkości nie działa, a dane analityczne są bezużyteczne.

Apache (mod_remoteip)

Zainstaluj i włącz moduł:

sudo a2enmod remoteip\nsudo systemctl restart apache2

Dodaj do konfiguracji Apache (virtual host lub globalnie):

RemoteIPHeader CF-Connecting-IP\nRemoteIPTrustedProxy 173.245.48.0/20\nRemoteIPTrustedProxy 103.21.244.0/22\nRemoteIPTrustedProxy 103.22.200.0/22\nRemoteIPTrustedProxy 103.31.4.0/22\nRemoteIPTrustedProxy 141.101.64.0/18\nRemoteIPTrustedProxy 108.162.192.0/18\nRemoteIPTrustedProxy 190.93.240.0/20\nRemoteIPTrustedProxy 188.114.96.0/20\nRemoteIPTrustedProxy 197.234.240.0/22\nRemoteIPTrustedProxy 198.41.128.0/17\nRemoteIPTrustedProxy 162.158.0.0/15\nRemoteIPTrustedProxy 104.16.0.0/13\nRemoteIPTrustedProxy 104.24.0.0/14\nRemoteIPTrustedProxy 172.64.0.0/13\nRemoteIPTrustedProxy 131.0.72.0/22

Cloudflare publikuje swoje zakresy IP na cloudflare.com/ips — sprawdzaj okresowo i aktualizuj konfigurację, jeśli się zmienią.

Nginx

Użyj modułu ngx_http_realip_module (zazwyczaj domyślnie skompilowany):

set_real_ip_from 173.245.48.0/20;\nset_real_ip_from 103.21.244.0/22;\n# ... dodaj wszystkie zakresy Cloudflare ...\nreal_ip_header CF-Connecting-IP;

Konfiguracja PrestaShop

Nawet z mod_remoteip niektóre moduły PrestaShop odczytują IP z $_SERVER['HTTP_CF_CONNECTING_IP'] lub $_SERVER['HTTP_X_FORWARDED_FOR']. Jeśli po skonfigurowaniu mod_remoteip nadal widzisz adresy IP Cloudflare w zamówieniach, sprawdź plik config/defines.inc.php PrestaShop pod kątem nadpisań związanych z IP lub dodaj następujący kod (nie zawsze konieczny, jeśli mod_remoteip działa):

if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {\n    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];\n}

Krok 7: Reguły WAF (Web Application Firewall)

WAF Cloudflare chroni Twój sklep przed SQL injection, XSS i innymi atakami. Na darmowym planie otrzymujesz podstawową ochronę. Na planie Pro i wyższych otrzymujesz zarządzane zestawy reguł.

Zalecane ustawienia WAF

Security Level: Medium (pod Security > Settings). „High" może wywoływać wyzwania dla legalnych klientów w sieciach mobilnych lub na VPN-ach.
Challenge Passage: 30 minut (jak długo odwiedzający pozostaje zweryfikowany po rozwiązaniu wyzwania)
Bot Fight Mode: Włączaj z ostrożnością — może blokować callbacki bramek płatności (IPN) od PayPal, Stripe itp. Jeśli go włączysz, dodaj wyjątki WAF dla znanych ścieżek webhooków, takich jak /module/paypal/notify.

Niestandardowe reguły WAF dla PrestaShop

Utwórz te reguły firewalla pod Security > WAF > Custom Rules:

Blokowanie bezpośredniego dostępu do wrażliwych plików:

Wyrażenie: (http.request.uri.path contains \"config/settings.inc.php\") or (http.request.uri.path contains \".env\") or (http.request.uri.path contains \"composer.json\") or (http.request.uri.path contains \"var/logs/\")

Akcja: Block

Ograniczenie częstotliwości prób logowania:

Użyj Rate Limiting Rules, aby ograniczyć żądania do URL logowania administratora (np. /adminXYZ/index.php) do 5 żądań na minutę na IP. To zapobiega atakom brute force na panel administracyjny.

Whitelisting adresów IP dostawców płatności:

Jeśli używasz Bot Fight Mode, utwórz regułę Allow dla adresów IP webhooków Twojego dostawcy płatności, aby ich callbacki server-to-server nigdy nie były weryfikowane.

Krok 8: Ustawienia wydajności

Przejdź do Speed > Optimization i skonfiguruj:

Auto Minify: Włącz dla JavaScript, CSS i HTML. CCC PrestaShop (Combine, Compress, Cache) wykonuje własną minifikację, więc może dojść do podwójnej minifikacji, ale jest to zazwyczaj nieszkodliwe. Jeśli zauważysz problemy z renderowaniem, wyłącz minifikację CSS Cloudflare i polegaj na CCC PrestaShop.
Brotli: Włącz — lepsza kompresja niż gzip, obsługiwana przez wszystkie nowoczesne przeglądarki
Early Hints: Włącz — informuje przeglądarki o wstępnym ładowaniu krytycznych zasobów przed pełnym dostarczeniem HTML
HTTP/2: Włączony domyślnie na wszystkich planach Cloudflare
HTTP/3 (QUIC): Włącz dla lepszej wydajności w sieciach mobilnych

Mirage (plan Pro): Jeśli dostępne, włącz. Mirage stosuje lazy loading obrazów i serwuje odpowiednio dopasowane obrazy w zależności od urządzenia odwiedzającego. Dobrze współpracuje z obrazami produktów PrestaShop.

Polish (plan Pro): Włącz z kompresją „Lossy" dla obrazów produktów lub „Lossless", jeśli jakość obrazu jest krytyczna (np. druki artystyczne). Polish kompresuje obrazy w locie na krawędzi sieci bez modyfikowania oryginałów.

Krok 9: Czyszczenie cache Cloudflare

Gdy aktualizujesz wygląd sklepu, dodajesz nowe produkty lub zmieniasz pliki CSS/JS, musisz wyczyścić cache Cloudflare, aby odwiedzający widzieli najnowszą wersję.

Metody czyszczenia:

Purge Everything: Dashboard > Caching > Configuration > Purge Everything. Używaj oszczędnie — wymusza ponowne pobranie wszystkich zasobów z Twojego serwera.
Purge by URL: Czyść konkretne pliki, np. example.com/themes/your-theme/assets/css/theme.css
Purge by Tag / Prefix: Dostępne na planach Enterprise
Czyszczenie przez API: Użyj API Cloudflare do automatyzacji czyszczenia cache po wdrożeniach. Możesz to zintegrować z workflow wdrażania modułów PrestaShop.

System CCC PrestaShop dołącza ciągi wersji do plików CSS i JS (np. theme.css?v=12345), co naturalnie unieważnia cache Cloudflare, gdy pliki się zmieniają. Jeśli prawidłowo korzystasz z CCC, rzadko potrzebujesz ręcznego czyszczenia cache dla zasobów statycznych.

Najczęstsze błędy i jak ich unikać

Błąd 1: SSL ustawiony na Flexible

Objawy: Nieskończona pętla przekierowań, ERR_TOO_MANY_REDIRECTS, biała strona. Rozwiązanie: Zmień tryb SSL na Full (Strict) i zainstaluj certyfikat origin na swoim serwerze.

Błąd 2: Buforowanie dynamicznych stron

Objawy: Klient A widzi koszyk lub dane konta Klienta B, wyświetlane są złe ceny, zalogowani użytkownicy widzą treść dla niezalogowanych. Rozwiązanie: Nigdy nie używaj „Cache Everything" jako globalnego ustawienia. Buforuj tylko ścieżki zasobów statycznych. Zawsze omijaj cache dla /order, /cart, /my-account i panelu administracyjnego.

Błąd 3: Włączony Rocket Loader

Objawy: Dodawanie do koszyka nie działa, formularze płatności się nie ładują, moduły w panelu administracyjnym generują błędy JavaScript, galerie na stronach produktów są zepsute. Rozwiązanie: Wyłącz Rocket Loader globalnie.

Błąd 4: Brak przywracania prawdziwych IP

Objawy: Wszystkie zamówienia pokazują ten sam adres IP (IP Cloudflare), moduły geolokalizacji pokazują złe kraje, ograniczanie szybkości banuje Cloudflare zamiast atakujących. Rozwiązanie: Skonfiguruj mod_remoteip lub ngx_http_realip_module, jak opisano powyżej.

Błąd 5: Bot Fight Mode blokujący webhooki

Objawy: Potwierdzenia płatności nigdy nie dochodzą, zamówienia pozostają w statusie „Oczekiwanie na płatność", logi IPN/webhook pokazują odpowiedzi 403 lub challenge. Rozwiązanie: Utwórz reguły wyjątków WAF dla URL-ów webhooków dostawców płatności i zakresów IP.

Błąd 6: Problemy z e-mailem po konfiguracji

Objawy: E-maile przestają działać, walidacja SPF/DKIM zawodzi. Przyczyna: Rekordy DNS związane z e-mailem (MX, SPF TXT, DKIM) zostały przypadkowo ustawione jako proxowane (pomarańczowa chmurka). Rozwiązanie: Wszystkie rekordy DNS dotyczące e-maila muszą być DNS-only (szara chmurka). Proxowanie działa tylko dla ruchu HTTP/HTTPS.

Błąd 7: Development Mode pozostawiony włączony

Objawy: Cache nigdy nie działa, wysokie obciążenie serwera źródłowego. Przyczyna: Development Mode został włączony podczas konfiguracji i zapomniany. Rozwiązanie: Wyłącz Development Mode w Caching > Configuration po zakończeniu konfiguracji. Development Mode automatycznie wyłącza się po 3 godzinach, ale i tak sprawdź.

Lista kontrolna rozwiązywania problemów

Gdy coś pójdzie nie tak z Cloudflare i PrestaShop, przejdź przez tę listę kontrolną:

Pętle przekierowań: Sprawdź tryb SSL (musi być Full lub Full Strict), sprawdź .htaccess pod kątem zduplikowanych przekierowań HTTPS, zweryfikuj, że PS_SSL_ENABLED w PrestaShop jest ustawione na 1 w bazie danych.
Ostrzeżenia o mieszanej treści: Włącz Automatic HTTPS Rewrites w Cloudflare, sprawdź twardo zakodowane URL-e http:// w szablonie lub stronach CMS.
Wolny TTFB (Time to First Byte): Cloudflare domyślnie nie buforuje HTML. Wolny TTFB to wolny serwer źródłowy — optymalizuj PrestaShop (włącz CCC, skonfiguruj OPcache, sprawdź zapytania bazodanowe) zamiast winić Cloudflare.
CSS/JS się nie aktualizuje: Wyczyść cache CCC PrestaShop (panel administracyjny > Wydajność), następnie wyczyść cache Cloudflare. Sprawdź, czy CCC dołącza ciągi wersji do URL-ów plików.
Panel administracyjny wolny lub zepsuty: Upewnij się, że Twoja Page Rule omija cache i wyłącza funkcje wydajnościowe dla katalogu administratora. Sprawdź, czy WAF Cloudflare nie blokuje żądań AJAX panelu administracyjnego.
Klienci otrzymują wyzwania: Obniż Security Level do Medium lub Low. Sprawdź, czy Under Attack Mode nie jest włączony (powinien być używany tylko podczas aktywnych ataków DDoS). Przejrzyj zdarzenia firewalla w Security > Events, aby zobaczyć, jakie reguły się uruchamiają.
Wywołania API zawodzą: Jeśli Twój sklep ma endpointy REST API lub web services, upewnij się, że Cloudflare nie weryfikuje ani nie blokuje żądań API. Utwórz regułę WAF zezwalającą na żądania do /api/* ze znanych zakresów IP.
Obrazy się nie ładują: Sprawdź, czy Hotlink Protection jest włączone i przypadkowo nie blokuje Twojej własnej domeny. Zweryfikuj, że URL-e obrazów używają HTTPS.

Cloudflare z PrestaShop Multistore

Jeśli prowadzisz PrestaShop multistore z wieloma domenami, każda domena musi być dodana do Cloudflare osobno (na darmowym planie każda domena to oddzielna strefa). Upewnij się, że:

Tryb SSL jest ustawiony na Full (Strict) na każdej strefie
Page Rules są zduplikowane dla każdej domeny
Przywracanie prawdziwego IP obejmuje wszystkie domeny (mod_remoteip jest globalny, więc jedna konfiguracja obsługuje wszystkie virtual hosty)

Zalecany plan Cloudflare dla PrestaShop

Darmowy plan pokrywa większość potrzeb: DNS, CDN, podstawowy WAF i SSL. Plan Pro (około 20 USD/miesiąc) dodaje Mirage, Polish, zarządzane zestawy reguł WAF i więcej Page Rules. Dla sklepów o dużym ruchu, plan Business dodaje niestandardowe reguły WAF i dodatkowe funkcje wydajnościowe. Większość małych i średnich sklepów PrestaShop działa doskonale na darmowym planie lub planie Pro.

Podsumowanie

Prawidłowa konfiguracja Cloudflare z PrestaShop sprowadza się do kilku kluczowych decyzji: używaj SSL Full (Strict), wyłącz Rocket Loader, omijaj cache na dynamicznych stronach, przywracaj prawdziwe IP odwiedzających i chroń webhooki płatności przed ochroną przed botami. Ustaw to prawidłowo od początku, a Cloudflare stanie się potężnym sojusznikiem wydajności i bezpieczeństwa Twojego sklepu. Ustaw to źle, a spędzisz godziny na debugowaniu pętli przekierowań, zepsutych kas i widmowych zamówień. Poświęć czas na jednokrotną prawidłową konfigurację, a Twój sklep PrestaShop skorzysta z szybszych czasów ładowania na całym świecie, zmniejszonego obciążenia serwera i solidnej ochrony przed atakami.

Przeczytaj pełną odpowiedź

Czym jest WebP i dlaczego ma znaczenie dla PrestaShop

WebP to nowoczesny format obrazów opracowany przez Google, który zapewnia zarówno kompresję stratną, jak i bezstratną dla obrazów internetowych. W porównaniu z tradycyjnymi formatami, takimi jak JPEG i PNG, WebP zazwyczaj dostarcza o 25-35% mniejsze pliki przy równoważnej jakości wizualnej. Dla sklepu e-commerce działającego na PrestaShop, gdzie strony produktów często zawierają dziesiątki obrazów, przejście na WebP może dramatycznie zmniejszyć wagę stron, poprawić czasy ładowania i podnieść wyniki Core Web Vitals — a wszystko to bezpośrednio wpływa na pozycje SEO i współczynniki konwersji.

W przeciwieństwie do starszych formatów nowej generacji, które miały problemy z adopcją, WebP osiągnął niemal uniwersalne wsparcie przeglądarek. Stan na rok 2026 — każda główna przeglądarka — Chrome, Firefox, Safari, Edge, Opera i ich mobilne odpowiedniki — w pełni obsługuje WebP. Nawet dawni opornicy, jak starsze wersje Safari na macOS Catalina, są obecnie statystycznie nieistotni, stanowiąc mniej niż 0,3% globalnego ruchu. Oznacza to, że możesz z pewnością serwować obrazy WebP praktycznie wszystkim odwiedzającym bez martwienia się o problemy z kompatybilnością.

Dla sprzedawców korzystających z PrestaShop zyski wydajnościowe są znaczące. Typowy katalog produktów z 1000 produktów i 5 obrazami każdy może zaobserwować redukcję łącznego rozmiaru obrazów z 500 MB do poniżej 350 MB. Na stronach list produktów wyświetlających 20-40 miniatur, przekłada się to na 200-400 KB oszczędności przy każdym załadowaniu strony — wystarczająco, aby znacząco poprawić metryki Time to First Contentful Paint i Largest Contentful Paint.

Włączanie WebP w PrestaShop 1.7 i 8.x

PrestaShop 1.7.8+ i wszystkie wersje 8.x zawierają natywne wsparcie dla WebP. Funkcja jest wbudowana w system regeneracji obrazów i może być włączona przez panel administracyjny. Oto jak ją aktywować:

Przejdź do Wygląd > Ustawienia obrazów (w PS 8.x) lub Preferencje > Obrazy (w PS 1.7).
Poszukaj sekcji Opcje generowania obrazów na dole strony.
Znajdź ustawienie Format obrazów i wybierz jedną z opcji związanych z WebP. PrestaShop zazwyczaj oferuje: tylko JPEG, tylko PNG, tylko WebP lub JPEG/PNG + WebP (generuje oba formaty).
Wybierz JPEG/PNG + WebP, jeśli chcesz kompatybilność wsteczną, lub Tylko WebP, jeśli masz pewność, że wszyscy Twoi odwiedzający używają nowoczesnych przeglądarek.
Ustaw suwak Jakość WebP. Wartość między 80 a 85 zapewnia doskonałą równowagę między rozmiarem pliku a jakością wizualną dla fotografii produktowej.
Kliknij Zapisz, a następnie kliknij Regeneruj miniatury, aby utworzyć wersje WebP wszystkich istniejących obrazów.

Proces regeneracji może zająć znaczną ilość czasu przy dużych katalogach. Dla sklepu z 5000+ produktami, spodziewaj się procesu trwającego od 30 minut do kilku godzin w zależności od zasobów serwera. Zdecydowanie zaleca się uruchamianie regeneracji poza godzinami szczytu lub przez CLI, aby uniknąć problemów z limitem czasu PHP.

Regeneracja CLI dla dużych katalogów

Dla sklepów z tysiącami produktów regeneracja przez przeglądarkę prawdopodobnie przekroczy limit czasu. Użyj zamiast tego podejścia CLI:

php bin/console prestashop:image:regenerate --format=all

To polecenie działa bez ograniczeń limitu czasu serwera webowego. Możesz również celować w konkretne typy obrazów:

php bin/console prestashop:image:regenerate --type=products --format=all\nphp bin/console prestashop:image:regenerate --type=categories --format=all

W wersjach PrestaShop 1.7, które nie mają polecenia konsolowego, możesz zwiększyć limity czasu PHP i uruchomić regenerację przez panel administracyjny lub użyć niestandardowego skryptu PHP, który bezpośrednio wywołuje klasę ImageManager.

Konfiguracja serwera: reguły Apache .htaccess

Nawet po włączeniu generowania WebP w PrestaShop, Twój serwer musi być skonfigurowany do serwowania prawidłowego formatu. PrestaShop generuje pliki WebP obok oryginalnych plików JPEG/PNG, ale serwer musi wiedzieć, kiedy serwować który format.

Dla serwerów Apache dodaj następujące reguły do pliku .htaccess w głównym katalogu PrestaShop lub w katalogu img/:

<IfModule mod_rewrite.c>\n  RewriteEngine On\n\n  # Serwuj obrazy WebP, jeśli przeglądarka je obsługuje i plik istnieje\n  RewriteCond %{HTTP_ACCEPT} image/webp\n  RewriteCond %{REQUEST_FILENAME} (.+)\\.(jpe?g|png)$\n  RewriteCond %1.webp -f\n  RewriteRule (.+)\\.(jpe?g|png)$ $1.webp [T=image/webp,E=REQUEST_image,L]\n</IfModule>\n\n# Ustaw prawidłowy typ MIME dla WebP\n<IfModule mod_mime.c>\n  AddType image/webp .webp\n</IfModule>\n\n# Nagłówek Vary zapobiegający problemom z buforowaniem\n<IfModule mod_headers.c>\n  Header append Vary Accept env=REQUEST_image\n</IfModule>

Te reguły działają następująco: gdy przeglądarka żąda pliku JPEG lub PNG, serwer sprawdza, czy przeglądarka wysyła nagłówek Accept: image/webp. Jeśli tak, i wersja .webp pliku istnieje na dysku, serwer transparentnie serwuje plik WebP zamiast oryginału. Nagłówek Vary: Accept zapewnia, że proxy buforujące przechowują oddzielne wersje dla przeglądarek obsługujących i nieobsługujących WebP.

Upewnij się, że mod_rewrite, mod_mime i mod_headers są włączone w Twojej instalacji Apache. Większość środowisk hostingu współdzielonego ma je domyślnie włączone, ale możesz zweryfikować u swojego dostawcy hostingu.

Konfiguracja Nginx

Dla sklepów działających na Nginx konfiguracja trafia do bloku server lub bloku location w pliku konfiguracyjnym Twojej witryny:

map $http_accept $webp_suffix {\n  default \"\";\n  \"~*image/webp\" \".webp\";\n}\n\nserver {\n  # ... istniejąca konfiguracja ...\n\n  location ~* ^(/img/.+)\\.(jpe?g|png)$ {\n    set $img_path $1;\n    add_header Vary Accept;\n    try_files $img_path$webp_suffix $uri =404;\n  }\n}

Dyrektywa map na poziomie http sprawdza, czy klient wysyła nagłówek Accept kompatybilny z WebP i odpowiednio ustawia zmienną. Blok location następnie używa try_files, aby najpierw spróbować zaserwować wersję WebP, wracając do oryginalnego formatu, jeśli plik WebP nie istnieje.

Po modyfikacji konfiguracji Nginx zawsze testuj przed przeładowaniem:

nginx -t\nnginx -s reload

Kwestie CDN

Jeśli używasz CDN, takiego jak Cloudflare, KeyCDN lub Bunny.net przed swoim sklepem PrestaShop, dostarczanie WebP wymaga dodatkowej uwagi.

Cloudflare

Cloudflare oferuje wbudowaną konwersję WebP poprzez funkcję Polish (dostępną na planach Pro i wyższych). Gdy Polish jest włączony z konwersją WebP, Cloudflare automatycznie konwertuje obrazy na WebP na krawędzi sieci — co oznacza, że nie musisz w ogóle generować plików WebP na swoim serwerze. Jednak bądź świadomy tych zastrzeżeń:

Polish działa tylko dla obrazów serwowanych przez proxy Cloudflare (włączona pomarańczowa chmurka).
Nie konwertuje obrazów większych niż 10 MB ani obrazów z pewnymi profilami kolorów.
Początkowa konwersja dodaje opóźnienie przy pierwszym żądaniu; kolejne żądania są serwowane z cache.
Jeśli również generujesz WebP lokalnie, możesz uzyskać podwójną konwersję, co może nieznacznie obniżyć jakość.

Jeśli wolisz serwować własne pliki WebP przez Cloudflare, upewnij się, że nagłówek Vary: Accept jest obsługiwany prawidłowo. Domyślnie Cloudflare usuwa nagłówek Vary. Możesz potrzebować utworzyć Cache Rule lub użyć Workera, aby zapewnić prawidłową negocjację treści.

Inne CDN-y

Większość nowoczesnych CDN-ów obsługuje negocjację treści na podstawie nagłówka Accept, ale musisz to jawnie włączyć. Sprawdź dokumentację swojego CDN w sekcji „obsługa nagłówka Vary" lub „negocjacja treści". Niektóre CDN-y wymagają włączenia opcji „Cache by Accept header" w regułach buforowania. Bez tego CDN może zbuforować pierwszą wersję, którą zobaczy (JPEG lub WebP) i serwować ją wszystkim odwiedzającym niezależnie od wsparcia przeglądarki.

Ustawienia jakości obrazu

Wybór odpowiedniego ustawienia jakości WebP jest kluczowy. Zbyt wysoka jakość i tracisz korzyści z rozmiaru pliku; zbyt niska i obrazy produktów wyglądają nieostro lub wykazują artefakty kompresji — co jest niedopuszczalne w e-commerce.

Oto zalecane ustawienia jakości według typu obrazu:

Obrazy produktów (duże widoki/widoki szczegółowe): Jakość 82-88. Zdjęcia produktów muszą wyglądać ostro, szczególnie dla przedmiotów, gdzie tekstura i detal mają znaczenie (moda, biżuteria, elektronika). Przy jakości 85 typowy obraz produktu 800x800 kompresuje się z ~120 KB (JPEG) do ~80 KB (WebP) bez widocznej utraty jakości.
Banery kategorii i obrazy główne: Jakość 78-82. Są zazwyczaj oglądane w większych rozmiarach, ale z mniejszą uwagą na drobne detale.
Miniatury i obrazy list: Jakość 75-80. Przy małych rozmiarach wyświetlania niższa jakość jest mniej zauważalna. Miniatura przy jakości 75 może być o 50-60% mniejsza od odpowiednika JPEG.
Logo i grafiki z ostrymi krawędziami: Użyj bezstratnego WebP lub zachowaj jako PNG. Kompresja stratna tworzy widoczne artefakty wokół tekstu i grafik z ostrymi krawędziami.

PrestaShop stosuje jedno ustawienie jakości globalnie. Jeśli potrzebujesz różnych poziomów jakości dla różnych typów obrazów, musiałbyś zmodyfikować klasę ImageManager lub użyć modułu od zewnętrznego dewelopera, który zapewnia bardziej szczegółową kontrolę.

Strategie awaryjne (fallback)

Choć wsparcie przeglądarek dla WebP jest niemal uniwersalne w 2026 roku, wdrożenie strategii awaryjnej jest nadal uważane za najlepszą praktykę, szczególnie jeśli Twój sklep obsługuje klientów korzystających ze starszych urządzeń lub ograniczonych środowisk korporacyjnych.

Negocjacja treści po stronie serwera

Reguły .htaccess i Nginx opisane powyżej implementują negocjację treści po stronie serwera. To zalecane podejście, ponieważ jest transparentne dla warstwy aplikacji. Przeglądarka żąda oryginalnego URL-a, a serwer decyduje, który format dostarczyć na podstawie nagłówka Accept. Nie są wymagane żadne zmiany w szablonach ani kodzie front-endowym.

Element HTML Picture

Alternatywne podejście wykorzystuje element <picture>, aby pozwolić przeglądarce wybrać najlepszy format:

<picture>\n  <source srcset=\"image.webp\" type=\"image/webp\">\n  <img src=\"image.jpg\" alt=\"Nazwa produktu\">\n</picture>

To wymaga modyfikacji szablonów PrestaShop (Smarty lub Twig w zależności od wersji). Choć daje jawną kontrolę, jest bardziej inwazyjne i trudniejsze w utrzymaniu przy aktualizacjach szablonów. Negocjacja po stronie serwera jest ogólnie preferowana dla wdrożeń PrestaShop.

Wbudowany fallback PrestaShop

Gdy wybierzesz opcję „JPEG/PNG + WebP" w ustawieniach obrazów PrestaShop, system generuje oba formaty. PrestaShop 8.x obsługuje fallback automatycznie w swoich szablonach rdzeniowych, sprawdzając, czy plik WebP istnieje, zanim go poda. Jeśli używasz niestandardowego szablonu, zweryfikuj, że szablony obrazów produktów wspierają to podejście z podwójnym formatem.

Najczęstsze pułapki i jak je naprawić

1. Zepsute obrazy po włączeniu WebP

Najczęstszym problemem po włączeniu WebP są zepsute obrazy w całym sklepie. Zazwyczaj dzieje się tak, ponieważ:

Pliki WebP nie zostały wygenerowane. Włączenie ustawienia wpływa tylko na nowo przesłane obrazy. Musisz kliknąć „Regeneruj miniatury", aby utworzyć wersje WebP istniejących obrazów. Dla dużych katalogów użyj polecenia CLI.
Uprawnienia plików są nieprawidłowe. Użytkownik serwera webowego (zazwyczaj www-data) musi mieć uprawnienia do zapisu w drzewie katalogów img/. Po regeneracji zweryfikuj uprawnienia: find img/ -name \"*.webp\" -exec ls -la {} \\;
Reguły .htaccess kolidują. Domyślny .htaccess PrestaShop zawiera reguły przepisywania, które mogą kolidować z regułami WebP. Umieść reguły WebP przed domyślnym blokiem przepisywania PrestaShop, aby zapewnić ich wcześniejsze przetwarzanie.

2. Brakujące rozszerzenia GD lub Imagick

Generowanie WebP wymaga, aby PHP miało bibliotekę GD lub rozszerzenie ImageMagick skompilowane ze wsparciem WebP. Aby sprawdzić:

php -r \"echo gd_info()['WebP Support'] ? 'GD WebP OK' : 'GD WebP BRAK';\"

Lub dla ImageMagick:

php -r \"echo in_array('WEBP', Imagick::queryFormats()) ? 'Imagick WebP OK' : 'Imagick WebP BRAK';\"

Jeśli wsparcie WebP jest niedostępne, musisz przekompilować PHP z odpowiednimi flagami lub zainstalować prawidłowe pakiety. Na Debian/Ubuntu: apt-get install libwebp-dev a następnie przekompilowanie rozszerzenia GD, lub instalacja wersji PHP zawierającej wsparcie WebP (PHP 7.4+ zazwyczaj zawiera je domyślnie).

Na hostingu współdzielonym, jeśli Twoja kompilacja PHP nie obsługuje WebP, skontaktuj się z dostawcą hostingu. Większość nowoczesnych środowisk hostingowych zawiera wsparcie WebP w instalacjach PHP 8.x.

3. Problemy z buforowaniem

Problemy związane z buforowaniem należą do najbardziej frustrujących kwestii WebP:

Cache przeglądarki: Po włączeniu WebP przeglądarki mogą nadal wyświetlać buforowane wersje JPEG/PNG. Zalecaj użytkownikom twarde odświeżanie (Ctrl+Shift+R), ale problem rozwiązuje się sam, gdy buforowane obrazy wygasną.
Cache po stronie serwera: Jeśli używasz Varnish, Redis lub jakiegokolwiek buforowania pełnych stron, cache musi zostać wyczyszczony po włączeniu WebP. W przeciwnym razie buforowane strony będą odwoływać się do starych URL-ów obrazów lub typów MIME.
Cache CDN: Wyczyść cache CDN całkowicie po włączeniu WebP. Zwróć szczególną uwagę na klucze cache CDN — jeśli CDN nie różnicuje buforowania według nagłówka Accept, może serwować WebP przeglądarkom, które go nie obsługują (lub odwrotnie).
OPcache: Jeśli zmodyfikowałeś pliki PHP w ramach włączania WebP (na przykład niestandardowe nadpisania ImageManager), zresetuj OPcache, aby upewnić się, że nowy kod zacznie działać.
Cache Smarty PrestaShop: Wyczyść cache Smarty z panelu administracyjnego (Zaawansowane parametry > Wydajność) lub usuń zawartość katalogu var/cache/.

4. Nieprawidłowe typy MIME

Jeśli Twój serwer nie rozpoznaje rozszerzenia .webp, przeglądarki nie będą w stanie wyrenderować obrazów, mimo że pliki są prawidłowe. Upewnij się, że konfiguracja serwera zawiera prawidłowe mapowanie typu MIME: image/webp dla plików .webp. Dyrektywa AddType w sekcji Apache powyżej to obsługuje.

5. Problemy z przesyłaniem obrazów w panelu administracyjnym

Panel administracyjny PrestaShop waliduje przesyłane formaty obrazów. W niektórych wersjach bezpośrednie przesyłanie obrazu WebP przez edytor produktów może się nie powieść z błędem walidacji. Dzieje się tak, ponieważ biała lista walidatora przesyłania może nie zawierać WebP. Sprawdź dozwolone rozszerzenia w Zaawansowane parametry > Administracja lub odpowiedniej konfiguracji.

6. Niekompatybilność z modułami zewnętrznymi

Niektóre moduły zewnętrzne (szczególnie slidery, moduły galerii i moduły powiększania obrazów produktów) na sztywno zapisują rozszerzenia plików obrazów lub nie obsługują WebP. Po włączeniu WebP przetestuj wszystkie moduły wyświetlające obrazy. Typowe objawy to brakujące miniatury w modułach sliderów lub zepsuta funkcjonalność powiększania. Skontaktuj się z deweloperem modułu w sprawie aktualizacji lub upewnij się, że Twoja negocjacja treści po stronie serwera prawidłowo obsługuje fallback.

Testowanie dostarczania WebP

Po konfiguracji zweryfikuj, że obrazy WebP są faktycznie serwowane. Oto kilka metod:

Narzędzia deweloperskie przeglądarki

Otwórz swój sklep w Chrome lub Firefox.
Otwórz DevTools (F12) i przejdź do zakładki Sieć (Network).
Filtruj po typie Img.
Przeładuj stronę.
Kliknij na dowolne żądanie obrazu i sprawdź Nagłówki odpowiedzi (Response Headers). Content-Type powinien być image/webp.
Sprawdź również kolumnę Type na liście sieciowej — dla skonwertowanych obrazów powinna wyświetlać „webp".

Testowanie z linii poleceń

Użyj curl, aby zweryfikować, że negocjacja treści działa prawidłowo:

# Żądanie ze wsparciem WebP\ncurl -s -I -H \"Accept: image/webp,image/*\" https://twojsklep.com/img/p/1/2/3/456-home_default.jpg | grep Content-Type\n# Oczekiwane: Content-Type: image/webp\n\n# Żądanie bez wsparcia WebP\ncurl -s -I -H \"Accept: image/jpeg\" https://twojsklep.com/img/p/1/2/3/456-home_default.jpg | grep Content-Type\n# Oczekiwane: Content-Type: image/jpeg

Narzędzia online

Google PageSpeed Insights i Lighthouse oznaczają obrazy, które nie są serwowane w formatach nowej generacji. Uruchom audyt Lighthouse na swoich stronach produktów — jeśli WebP jest prawidłowo skonfigurowany, nie powinieneś widzieć rekomendacji „Serve images in next-gen formats".

Wpływ na wydajność

Rzeczywisty wpływ WebP na wydajność sklepu PrestaShop zależy od wielkości katalogu i kompozycji stron, ale typowe poprawy obejmują:

Redukcja łącznej wagi strony: 15-30% na stronach list produktów i 10-20% na stronach szczegółów produktów, gdzie obrazy stanowią większość pobieranych bajtów.
Largest Contentful Paint (LCP): Poprawa średnio o 200-600ms, ponieważ główny obraz produktu ładuje się szybciej. To jedna z trzech metryk Core Web Vitals, która bezpośrednio wpływa na pozycje w wyszukiwarkach.
Time to Interactive (TTI): Marginalna poprawa, ponieważ ładowanie obrazów konkuruje z wykonywaniem JavaScript o przepustowość, ale nie o CPU.
Oszczędności przepustowości serwera: Dla sklepu obsługującego 100 000 odsłon miesięcznie, WebP może zmniejszyć miesięczne zużycie przepustowości o 20-50 GB, potencjalnie obniżając koszty hostingu.
Wydajność mobilna: Największe zyski są na połączeniach mobilnych, gdzie mniejsze rozmiary obrazów przekładają się bezpośrednio na szybsze czasy ładowania w sieciach 4G/5G. Indeksowanie Google mobile-first czyni to szczególnie ważnym.

Pamiętaj, że generowanie WebP dodaje obciążenie CPU podczas przetwarzania obrazów (przesyłanie i regeneracja). Na słabszym hostingu współdzielonym regeneracja miniatur dla dużego katalogu może tymczasowo spowolnić serwer. Planuj regenerację w okresach niskiego ruchu.

Lista kontrolna podsumowująca

Aby pomyślnie wdrożyć WebP w swoim sklepie PrestaShop, postępuj według tej listy kontrolnej:

Zweryfikuj, że PHP ma GD lub ImageMagick ze wsparciem WebP.
Włącz generowanie WebP w ustawieniach obrazów PrestaShop (użyj JPEG/PNG + WebP dla bezpieczeństwa).
Ustaw jakość na 82-85 dla optymalnej równowagi.
Regeneruj wszystkie miniatury (użyj CLI dla dużych katalogów).
Dodaj reguły negocjacji treści po stronie serwera (.htaccess lub konfiguracja Nginx).
Skonfiguruj CDN do różnicowania cache według nagłówka Accept.
Wyczyść wszystkie pamięci podręczne (przeglądarka, serwer, CDN, Smarty, OPcache).
Przetestuj dostarczanie za pomocą DevTools przeglądarki i curl.
Zweryfikuj, że moduły zewnętrzne prawidłowo wyświetlają obrazy.
Uruchom audyt Lighthouse, aby potwierdzić brak ostrzeżeń o „formatach nowej generacji".

WebP nie jest już opcjonalny w konkurencyjnym e-commerce. Dzięki wbudowanemu wsparciu PrestaShop i prostej konfiguracji serwera nie ma powodu, aby dalej serwować przerosłe pliki JPEG i PNG. Konfiguracja zajmuje mniej niż godzinę, a korzyści wydajnościowe są natychmiastowe i mierzalne.

Przeczytaj pełną odpowiedź

Czym jest Critical CSS i dlaczego ma znaczenie dla PrestaShop?

Critical CSS to minimalny zestaw reguł CSS wymaganych do wyrenderowania zawartości widocznej na ekranie bez przewijania (tzw. above the fold). Kiedy przeglądarka ładuje Twój sklep PrestaShop, musi pobrać, przeanalizować i zastosować każdy plik CSS, zanim będzie mogła wyświetlić cokolwiek na ekranie. Oznacza to, że typowa instalacja PrestaShop z arkuszem stylów motywu, arkuszami stylów modułów i ewentualnie frameworkiem CSS może zmusić odwiedzających do wpatrywania się w pustą stronę przez kilka sekund, podczas gdy przeglądarka przetwarza setki kilobajtów CSS, które mogą nawet nie być istotne dla tego, co odwiedzający widzi jako pierwsze.

Koncepcja stojąca za critical CSS jest prosta: wyodrębnij tylko te style, które są potrzebne dla początkowego widoku (viewport), wstaw je bezpośrednio do dokumentu HTML i odłóż ładowanie całej reszty. Dzięki temu przeglądarka może rozpocząć renderowanie strony niemal natychmiast, co dramatycznie poprawia postrzegany czas ładowania oraz kilka kluczowych wskaźników wydajności.

Jak CSS blokujący renderowanie szkodzi Core Web Vitals

Core Web Vitals od Google to zestaw metryk, które bezpośrednio wpływają na pozycje w wynikach wyszukiwania. CSS blokujący renderowanie negatywnie oddziałuje na wiele metryk jednocześnie.

Largest Contentful Paint (LCP) mierzy moment, w którym największy widoczny element kończy renderowanie. Ponieważ CSS całkowicie blokuje renderowanie, każda milisekunda poświęcona na pobieranie i parsowanie CSS dodaje się bezpośrednio do wyniku LCP. Sklep PrestaShop ładujący 300 KB CSS przed wyrenderowaniem czegokolwiek będzie konsekwentnie przekraczał próg 2,5 sekundy LCP, szczególnie na połączeniach mobilnych.

First Contentful Paint (FCP) śledzi moment, w którym przeglądarka po raz pierwszy renderuje jakąkolwiek treść. CSS blokujący renderowanie opóźnia FCP, ponieważ przeglądarka nie może narysować ani jednego piksela, dopóki wszystkie blokujące arkusze stylów nie zostaną przetworzone. Sklepy z wieloma modułami, z których każdy wstrzykuje własne pliki CSS, często odnotowują czasy FCP przekraczające 3-4 sekundy na połączeniach 3G.

Cumulative Layout Shift (CLS) również może być dotknięty pośrednio. Gdy CSS ładuje się z opóźnieniem lub asynchronicznie bez prawidłowego critical CSS, elementy mogą renderować się bez stylów, a następnie zmieniać pozycję po zastosowaniu arkuszy stylów. Tworzy to niestabilność wizualną, która frustruje użytkowników i podnosi wyniki CLS.

Interaction to Next Paint (INP) cierpi, ponieważ główny wątek jest zajęty parsowaniem dużych plików CSS zamiast odpowiadać na dane wejściowe użytkownika. Nawet po początkowym renderowaniu przeglądarka musi nadal przetwarzać odroczone arkusze stylów, a jeśli dzieje się to podczas interakcji użytkownika, powoduje zauważalne opóźnienia.

Identyfikacja zasobów blokujących renderowanie w PrestaShop

Zanim będziesz mógł wyeliminować CSS blokujący renderowanie, musisz dokładnie zidentyfikować, które zasoby powodują problemy. Kilka narzędzi może pomóc w tej analizie.

Google PageSpeed Insights oferuje konkretny audyt o nazwie „Eliminate render-blocking resources" (Wyeliminuj zasoby blokujące renderowanie), który wymienia każdy plik CSS i JavaScript blokujący początkowe renderowanie. Przepuść swoją stronę główną PrestaShop oraz kluczowe strony kategorii i produktów przez to narzędzie. Zwróć uwagę na kolumnę szacowanych oszczędności, która pokazuje, ile milisekund możesz odzyskać, odraczając każdy zasób.

Zakładka Coverage w Chrome DevTools jest nieoceniona w zrozumieniu wykorzystania CSS. Otwórz DevTools, przejdź do zakładki Coverage (Ctrl+Shift+P, następnie wpisz „coverage") i przeładuj stronę. Pokazuje to dokładnie, jaka część każdego pliku CSS jest faktycznie używana podczas początkowego renderowania. W typowym sklepie PrestaShop odkryjesz, że 70-85% CSS załadowanego na danej stronie nie jest wykorzystywane na tej konkretnej stronie.

WebPageTest oferuje widoki filmstrip i waterfall, które wyraźnie pokazują, kiedy pliki CSS są żądane, kiedy kończą się ładować i kiedy następuje pierwsze renderowanie. Przerwa między dotarciem HTML a pierwszym renderowaniem jest w dużej mierze spowodowana CSS blokującym renderowanie.

Typowy sklep PrestaShop 1.7 lub 8.x ładuje następujące zasoby CSS blokujące renderowanie: arkusz stylów motywu (często 200-400 KB), plik frameworka Bootstrap (150 KB+), Font Awesome lub czcionki ikonowe (50-100 KB) oraz od 3 do 15 arkuszy stylów specyficznych dla modułów. W sumie może to łatwo przekroczyć 500 KB CSS blokującego renderowanie.

Ręczna ekstrakcja Critical CSS

Ręczna ekstrakcja polega na identyfikacji reguł CSS potrzebnych dla treści widocznej bez przewijania i oddzieleniu ich od reszty. Choć wymaga dużo pracy, to podejście daje największą kontrolę nad wynikiem.

Zacznij od zidentyfikowania, co pojawia się powyżej linii zgięcia (above the fold) na każdym typie strony. W przypadku sklepu PrestaShop kluczowe szablony stron to: strona główna, listing kategorii, strona produktu, koszyk i kasa. Każdy z nich ma inną zawartość above the fold. Strona główna zazwyczaj wyświetla nagłówek, nawigację oraz baner główny lub slider. Strony kategorii pokazują nagłówek, okruszki nawigacyjne (breadcrumbs) i pierwszy rząd produktów. Strony produktów wyświetlają nagłówek, zdjęcie produktu, tytuł i cenę.

Użyj zakładki Coverage w Chrome DevTools, aby zidentyfikować, które reguły CSS są stosowane do elementów above the fold. Możesz również skorzystać z panelu „Computed" w zakładce Elements, aby zobaczyć dokładnie, które reguły wpływają na każdy widoczny element.

Wyodrębnij te reguły do osobnego pliku lub bloku inline. Typowy ładunek critical CSS dla strony PrestaShop powinien wynosić od 10 KB do 30 KB (przed gzip). Jeśli Twój critical CSS przekracza 50 KB, prawdopodobnie uwzględniasz zbyt wiele reguł. Skup się ściśle na układzie (grid, flexbox), typografii (font-family, font-size, line-height dla widocznego tekstu), kolorach i tłach widocznych elementów, strukturze nagłówka i nawigacji oraz układzie głównego obszaru treści.

Podejście ręczne najlepiej sprawdza się w sklepach o stałym designie, który rzadko się zmienia. Jeśli często aktualizujesz motyw lub dodajesz moduły, obciążenie związane z utrzymaniem ręcznego critical CSS staje się nie do utrzymania.

Zautomatyzowane narzędzia do Critical CSS

Zautomatyzowane narzędzia generują critical CSS, renderując Twoją stronę w przeglądarce bezgłowej (headless) i wyodrębniając tylko te style, które są stosowane do elementów w obrębie widoku (viewport). Dwa narzędzia dominują w tej przestrzeni.

Critters (Google Chrome Labs)

Critters to wtyczka Webpack, która wstawia critical CSS w czasie budowania. W przeciwieństwie do innych narzędzi, Critters nie korzysta z przeglądarki bezgłowej. Zamiast tego parsuje HTML i CSS statycznie, identyfikując, które selektory pasują do elementów obecnych w dokumencie HTML. Sprawia to, że jest szybszy i bardziej przewidywalny niż podejścia oparte na przeglądarce.

Do integracji z PrestaShop, Critters sprawdza się dobrze, gdy jest włączony do niestandardowego potoku budowania. Przetwarza wyrenderowany wynik HTML i wstawia krytyczne style inline, jednocześnie konwertując pozostałe linki do arkuszy stylów na ładowanie asynchroniczne. Kluczową zaletą Critters jest szybkość i niezawodność podczas procesów budowania. Ponieważ nie potrzebuje uruchomionej instancji przeglądarki, może przetwarzać strony szybko i konsekwentnie.

Kwestie konfiguracyjne Critters w PrestaShop obejmują ustawienie odpowiedniej szerokości viewport (zazwyczaj 1350px dla desktopa, 375px dla urządzeń mobilnych), wykluczenie pewnych selektorów generowanych dynamicznie (takich jak klasy specyficzne dla modułów dodawane przez JavaScript) oraz prawidłową obsługę deklaracji font-face, aby uniknąć efektu FOIT (flash of invisible text — migotanie niewidocznego tekstu).

Critical (Addy Osmani)

Pakiet npm Critical używa przeglądarki bezgłowej (Puppeteer) do renderowania stron i wyodrębniania CSS widocznego bez przewijania. Daje on bardziej dokładne wyniki niż analiza statyczna, ponieważ widzi stronę dokładnie tak, jak prawdziwa przeglądarka, włącznie z treścią renderowaną przez JavaScript i dynamicznie stosowanymi stylami.

Aby użyć Critical z PrestaShop, należy stworzyć krok budowania, który pobiera każdy typ strony z Twojego sklepu produkcyjnego lub testowego, wyodrębnia critical CSS i wstrzykuje go do szablonów motywu. Podejście to wymaga starannej obsługi uwierzytelniania dla stron za logowaniem (kasa, strony konta) oraz uwzględnienia różnych viewport dla responsywnego critical CSS.

Critical można uruchomić jako krok po wdrożeniu. Po wdrożeniu aktualizacji motywu ponownie generujesz critical CSS dla każdego typu strony i odpowiednio aktualizujesz style inline. Zapewnia to synchronizację critical CSS z faktycznymi stylami Twojego motywu.

Ustawienia CCC w PrestaShop: Combine, Compress, Cache

PrestaShop zawiera wbudowaną optymalizację CSS poprzez funkcję CCC (Combine, Compress, Cache — Łącz, Kompresuj, Cachuj), dostępną w panelu administracyjnym w sekcji Zaawansowane > Wydajność. Zrozumienie tych ustawień jest niezbędne przed wdrożeniem critical CSS, ponieważ wchodzą one w interakcję z Twoją strategią optymalizacji.

Łączenie plików CSS (Combine CSS files) scala wszystkie pliki CSS w jeden połączony plik. Zmniejsza to liczbę żądań HTTP, co było kluczowe w środowiskach HTTP/1.1. W przypadku HTTP/2 i HTTP/3 korzyść z łączenia jest mniejsza, ponieważ wiele plików może być pobieranych równolegle. Jednak łączenie nadal pomaga w kwestii blokowania renderowania, ponieważ przeglądarka musi czekać na tylko jeden plik zamiast potencjalnie kilkudziesięciu.

Kompresja CSS (Compress CSS) (minifikacja) usuwa białe znaki, komentarze i zbędne znaki z plików CSS. Zazwyczaj zmniejsza to rozmiar pliku CSS o 15-25%. Zawsze włączaj tę opcję na produkcji.

Cache CSS dodaje unikalny hash do nazw połączonych plików CSS, umożliwiając agresywne cachowanie po stronie przeglądarki przy jednoczesnym zapewnieniu, że odwiedzający otrzymują zaktualizowane style po zmianach. Działa to zarówno z wbudowanym systemem PrestaShop, jak i konfiguracjami CDN.

Przy wdrażaniu critical CSS obok CCC, zalecaną konfiguracją jest włączenie wszystkich trzech opcji CCC. Połączony i zminifikowany plik CSS staje się Twoim odroczonym (niekrytycznym) arkuszem stylów, podczas gdy critical CSS jest wstawiany inline w sekcji head HTML. Daje to najlepsze z obu rozwiązań: natychmiastowe renderowanie dzięki inline critical CSS oraz wydajne cachowanie pełnego arkusza stylów przy kolejnych ładowaniach strony.

Jedno ważne zastrzeżenie: po włączeniu lub zmianie ustawień CCC musisz wyczyścić cache PrestaShop. Przejdź do Zaawansowane > Wydajność i kliknij „Wyczyść cache" lub usuń zawartość katalogów /var/cache/prod/ i /var/cache/dev/. Skompilowane szablony Smarty w /var/cache/smarty/compile/ również powinny zostać wyczyszczone.

Implementacja Inline Critical CSS w PrestaShop

Faktyczna implementacja critical CSS w PrestaShop polega na modyfikacji szablonu head motywu w celu wstawienia krytycznych stylów inline i odroczenia pozostałego CSS.

W pliku _partials/head.tpl Twojego motywu (lub jego odpowiedniku) musisz dodać critical CSS inline w tagu style w sekcji head dokumentu. Zastępuje to normalny link do arkusza stylów dla stylów above the fold. Critical CSS powinien być umieszczony bezpośrednio po tagach meta i przed jakimikolwiek innymi zasobami.

Praktycznym podejściem jest stworzenie szablonu Smarty, który zawiera critical CSS inline. Utwórz plik w swoim motywie pod ścieżką _partials/critical-css.tpl, który zawiera krytyczne style opakowane w element style. Następnie dołącz ten partial w swoim szablonie head. Pozwala to utrzymać critical CSS w sposób łatwy do zarządzania, oddzielony od głównej logiki szablonu.

Dla różnych typów stron możesz warunkowo ładować różne zestawy critical CSS. PrestaShop udostępnia zmienną $page.page_name w Smarty, która informuje, jaki typ strony jest renderowany. Użyj jej, aby ładować critical CSS specyficzny dla danego typu strony: jeden zestaw dla strony głównej, inny dla stron kategorii, kolejny dla stron produktów i ogólny fallback dla wszystkich pozostałych stron.

Asynchroniczne ładowanie pozostałego CSS

Po wstawieniu critical CSS inline, pozostały CSS musi ładować się bez blokowania renderowania. Istnieje kilka technik do tego celu.

Technika zamiany atrybutu media jest najbardziej powszechnie obsługiwanym podejściem. Zmień atrybut media linku do arkusza stylów na „print" i dodaj handler onload, który przełączy go na „all" po załadowaniu. Informuje to przeglądarkę, że arkusz stylów jest przeznaczony tylko do druku, więc pobiera go z niskim priorytetem i nie blokuje renderowania. Po załadowaniu handler onload przełącza typ media na „all", stosując style na ekranie. Dołącz fallback noscript z oryginalnym linkiem dla użytkowników bez JavaScript.

Podejście z rel=\"preload\" wykorzystuje wstępne ładowanie linków, aby pobrać arkusz stylów z wysokim priorytetem, ale bez blokowania renderowania. Dodaj rel=\"preload\" i as=\"style\" do elementu link, wraz z handlerem onload, który zmienia rel na „stylesheet". Podejście to zapewnia lepszy priorytet ładowania niż technika zamiany media, ale ma nieco mniejszą obsługę przeglądarek w starszych wersjach.

Biblioteka loadCSS od Filament Group zapewnia solidne rozwiązanie JavaScript do asynchronicznego ładowania CSS z szeroką obsługą przeglądarek. Obsługuje przypadki brzegowe i fallbacki, które ręczne implementacje mogą pominąć. Dla sklepów PrestaShop, które muszą obsługiwać starsze przeglądarki, jest to najbezpieczniejszy wybór.

Niezależnie od wybranej techniki, zawsze dołączaj fallback <noscript> zawierający normalny link do arkusza stylów. Zapewnia to, że strona pozostaje funkcjonalna dla niewielkiego odsetka odwiedzających z wyłączonym JavaScript.

Problemy z CSS modułów w PrestaShop

Moduły PrestaShop są jednym z największych źródeł CSS blokującego renderowanie i stanowią unikalne wyzwania dla optymalizacji critical CSS.

Wzorce wstrzykiwania CSS przez moduły: Większość modułów PrestaShop rejestruje swój CSS poprzez hookDisplayHeader lub za pośrednictwem metody setMedia() modułu, która wywołuje $this->context->controller->addCSS(). Te arkusze stylów są dodawane do sekcji head strony i domyślnie blokują renderowanie. Gdy CCC jest włączone, PrestaShop łączy te arkusze stylów modułów z CSS motywu, co oznacza, że nie mogą być indywidualnie odroczone.

Zbędny CSS modułów na nieistotnych stronach: Częstym problemem jest ładowanie przez moduły swojego CSS na każdej stronie, nawet gdy funkcjonalność modułu jest używana tylko na konkretnych stronach. Moduł płatności ładujący swój CSS na stronie głównej lub moduł porównywania produktów ładujący CSS na stronie kasy marnuje przepustowość i wydłuża czas blokowania renderowania. Przeprowadź audyt swoich modułów i upewnij się, że każdy z nich ładuje CSS tylko na stronach, gdzie jest faktycznie potrzebny. Wiele modułów oferuje opcję konfiguracji do tego celu. Dla tych, które jej nie mają, możesz nadpisać hook nagłówka modułu, dodając warunki typu strony.

Jakość CSS modułów zewnętrznych: Moduły zewnętrzne (third-party) często zawierają słabo zoptymalizowany CSS. Możesz napotkać moduły dostarczające pliki CSS o rozmiarze 50 KB+, gdy potrzebują zaledwie 5 KB. Niektóre zawierają całe frameworki CSS dołączone w module. Inne dostarczają niezminifikowany CSS deweloperski. Zidentyfikuj te moduły za pomocą zakładki Coverage w Chrome DevTools i rozważ stworzenie zoptymalizowanych wersji ich arkuszy stylów w katalogu nadpisań modułów Twojego motywu pod ścieżką /themes/your-theme/modules/module-name/views/css/.

Kolejność ładowania CSS modułów: PrestaShop ładuje CSS modułów w kolejności, w jakiej moduły są zarejestrowane dla hooków. Jeśli CSS kluczowego modułu jest ładowany jako ostatni w połączonym pliku, przeglądarka musi przeanalizować cały poprzedzający CSS, zanim dotrze do istotnych stylów. Możesz wpływać na kolejność ładowania poprzez stronę pozycji modułów w panelu administracyjnym (Wygląd > Pozycje), przesuwając istotne moduły wyżej w hooku displayHeader.

Pomiar poprawy: przed i po

Pomiar wpływu wdrożenia critical CSS wymaga spójnej metodologii testowania i odpowiednich metryk.

Narzędzia pomiarowe: Użyj Google PageSpeed Insights dla danych laboratoryjnych i terenowych, WebPageTest dla szczegółowej analizy waterfall oraz Chrome DevTools Lighthouse dla szybkich lokalnych audytów. Przeprowadzaj testy z wielu lokalizacji i przy różnych prędkościach połączenia. Wydajność mobilna na połączeniach 3G zazwyczaj pokazuje najbardziej dramatyczną poprawę dzięki critical CSS, ponieważ opóźnienie spowodowane blokowaniem renderowania jest proporcjonalne do prędkości połączenia.

Kluczowe metryki do śledzenia: First Contentful Paint jest metryką najbardziej bezpośrednio poprawianą przez critical CSS, ponieważ mierzy pierwsze zdarzenie renderowania. LCP powinien się również poprawić, ponieważ przeglądarka może rozpocząć renderowanie i ładowanie widocznych obrazów wcześniej. Time to Interactive może się nieznacznie poprawić, ponieważ główny wątek spędza mniej czasu na początkowym parsowaniu CSS.

Metodologia testowania: Zawsze przeprowadzaj co najmniej 5 testów przed i 5 testów po wdrożeniu, a następnie porównuj mediany, a nie pojedyncze uruchomienia. Warunki sieciowe, obciążenie serwera i cachowanie CDN mogą powodować znaczne wahania między poszczególnymi uruchomieniami testów. Narzędzia takie jak WebPageTest pozwalają określić liczbę uruchomień i automatycznie obliczają mediany.

Realne wyniki wydajnościowe

Na podstawie rzeczywistych optymalizacji sklepów PrestaShop, oto typowe poprawy wydajności, jakich można oczekiwać po prawidłowym wdrożeniu critical CSS.

First Contentful Paint: Typowa poprawa o 1,2 do 2,5 sekundy na mobilnych połączeniach 3G. Sklep, który wcześniej miał FCP na poziomie 4,2 sekundy, może realistycznie osiągnąć 1,8 do 2,0 sekundy z prawidłowo wdrożonym critical CSS. Na desktopie z łączami szerokopasmowymi poprawa wynosi zazwyczaj 0,3 do 0,8 sekundy.

Largest Contentful Paint: Poprawa o 0,8 do 2,0 sekundy jest typowa. LCP zyskuje, ponieważ przeglądarka może wcześniej rozpocząć ładowanie obrazów i innych dużych elementów, gdy CSS nie blokuje już renderowania. Sklep PrestaShop z LCP wynoszącym 5,1 sekundy na urządzeniu mobilnym może często obniżyć ten wynik poniżej 3,0 sekund dzięki critical CSS w połączeniu z optymalizacją obrazów.

Wynik PageSpeed: Mobilne wyniki PageSpeed zazwyczaj rosną o 15 do 30 punktów po wyeliminowaniu CSS blokującego renderowanie. Sklep uzyskujący 35-45 punktów na urządzeniach mobilnych może realistycznie osiągnąć 60-75 dzięki samemu critical CSS. W połączeniu z innymi optymalizacjami (kompresja obrazów, odraczanie JavaScript, cachowanie po stronie serwera) wyniki powyżej 85 są osiągalne.

Total Blocking Time: Redukcja o 200 do 500 milisekund jest typowa, ponieważ główny wątek spędza mniej czasu na parsowaniu CSS podczas krytycznej fazy ładowania.

Te wyniki zakładają dobrze skonfigurowaną instalację PrestaShop z nowoczesnym motywem, rozsądnymi czasami odpowiedzi serwera (poniżej 500ms TTFB) i prawidłową konfiguracją CDN. Sklepy z ekstremalnie wolnym hostingiem, nadmierną liczbą modułów lub mocno zmodyfikowanymi motywami mogą odnotować inne wyniki.

Lista kontrolna wdrożenia

Podsumowując cały proces wdrażania critical CSS w Twoim sklepie PrestaShop, wykonaj poniższe kroki w kolejności. Po pierwsze, przeprowadź audyt aktualnego stanu CSS za pomocą zakładki Coverage w Chrome DevTools, aby zrozumieć, ile CSS jest ładowane i ile jest faktycznie używane above the fold. Po drugie, włącz ustawienia CCC w PrestaShop (Combine, Compress, Cache) jako podstawową optymalizację. Po trzecie, wybierz metodę generowania critical CSS: ręczna ekstrakcja dla prostych, stabilnych motywów, lub zautomatyzowane narzędzia takie jak Critters lub Critical dla złożonych lub często aktualizowanych sklepów. Po czwarte, wygeneruj critical CSS dla każdego głównego typu strony: strona główna, kategoria, produkt, koszyk i kasa. Po piąte, zaimplementuj inline critical CSS w szablonie head motywu z warunkowym ładowaniem per typ strony. Po szóste, skonfiguruj asynchroniczne ładowanie pozostałego połączonego pliku CSS za pomocą techniki zamiany media lub preload. Po siódme, przeprowadź audyt CSS modułów, aby wyeliminować zbędne ładowanie arkuszy stylów na nieistotnych stronach. Po ósme, zmierz wyniki za pomocą PageSpeed Insights, WebPageTest i Lighthouse, porównując metryki przed i po. Po dziewiąte, ustaw proces ponownego generowania critical CSS po aktualizacjach motywu lub znaczących zmianach w modułach. Na koniec, monitoruj Core Web Vitals w Google Search Console, aby zweryfikować rzeczywiste poprawy dla prawdziwych odwiedzających w czasie.

Optymalizacja critical CSS jest jedną z najbardziej skutecznych popraw wydajności, jakie możesz wprowadzić w sklepie PrestaShop. Choć początkowe wdrożenie wymaga wysiłku, wynikająca z niego poprawa Core Web Vitals, doświadczenia użytkownika i pozycji w wynikach wyszukiwania sprawia, że jest to inwestycja w pełni warta poświęconego czasu.

Przeczytaj pełną odpowiedź

Dlaczego warto zmienić domyślny adres URL panelu administracyjnego

Każda instalacja PrestaShop tworzy katalog administracyjny o nazwie takiej jak admin1234 — cyfry są generowane losowo podczas instalacji. W tym katalogu znajduje się back office Twojego sklepu. Choć losowy przyrostek zapewnia pewien podstawowy poziom ukrycia, nie jest to silne zabezpieczenie. Zautomatyzowane boty i atakujący rutynowo skanują tysiące stron internetowych w poszukiwaniu typowych wzorców adresów URL panelu administracyjnego. Zmiana adresu URL panelu na coś nieprzewidywalnego dodaje znaczącą warstwę obrony.

Głównym powodem zmiany nazwy folderu administracyjnego jest zmniejszenie narażenia na ataki brute-force na logowanie. Jeśli atakujący nie może znaleźć Twojej strony logowania, nie może próbować odgadnąć Twojego hasła. Nie zastępuje to silnych haseł i innych środków bezpieczeństwa, ale jest skutecznym pierwszym krokiem, który nic nie kosztuje i zajmuje zaledwie kilka minut.

Dodatkowo niestandardowy adres URL panelu sprawia, że Twój sklep wygląda bardziej profesjonalnie, jeśli pracownicy lub klienci muszą uzyskać dostęp do back office. Adres URL taki jak twojadomena.com/zarzadzanie-sklepem/ jest łatwiejszy do zapamiętania i przekazania niż twojadomena.com/admin7382pqxz/.

Jak działają adresy URL panelu administracyjnego PrestaShop

Katalog administracyjny PrestaShop to fizyczny folder na Twoim serwerze. Gdy wpisujesz twojadomena.com/admin1234/ w przeglądarce, serwer WWW szuka katalogu admin1234 i serwuje plik index.php znajdujący się w nim. Oznacza to, że zmiana adresu URL panelu administracyjnego to przede wszystkim kwestia zmiany nazwy katalogu w systemie plików serwera.

Wewnątrz katalogu administracyjnego PrestaShop przechowuje pliki kontrolerów, pliki szablonów i konfigurację, która odwołuje się do ścieżki administracyjnej. W PrestaShop 1.7 i 8.x katalog administracyjny zawiera również komponenty routingu Symfony. Konfiguracja wewnętrzna przechowuje nazwę katalogu administracyjnego w pliku app/config/parameters.php (lub config/parameters.php w starszych wersjach) pod kluczem ps_admin_dir. Ta wartość musi się zgadzać z rzeczywistą nazwą katalogu, aby back office działał prawidłowo.

Krok po kroku: Zmiana nazwy katalogu administracyjnego

Metoda 1: Przez FTP lub Menedżer plików

Jest to najbezpieczniejsza i najprostsza metoda. Działa na wszystkich typach hostingu i wszystkich wersjach PrestaShop od 1.6 do 8.x i 9.x.

Połącz się z serwerem przez FTP (FileZilla, WinSCP) lub użyj menedżera plików w panelu hostingu (cPanel, Plesk).
Przejdź do głównego katalogu PrestaShop — jest to miejsce, gdzie widzisz foldery takie jak classes/, modules/, themes/ oraz Twój aktualny folder administracyjny.
Zidentyfikuj aktualny folder administracyjny. Będzie miał nazwę w stylu admin1234 lub admin-dev (w instalacjach deweloperskich). Nie myl go z folderem admin-dev/, jeśli masz zainstalowaną wersję ze źródeł.
Zmień nazwę folderu na wybraną przez siebie. Kliknij prawym przyciskiem myszy na folder w kliencie FTP i wybierz „Zmień nazwę". Wybierz nazwę, która jest trudna do odgadnięcia, ale łatwa do zapamiętania. Dobre przykłady: manage-xyz, backoffice-abc, control-2024. Unikaj oczywistych nazw takich jak admin, administrator, backend, dashboard czy manage.
Zaktualizuj plik konfiguracyjny. Otwórz app/config/parameters.php w edytorze tekstu i znajdź linię zawierającą ps_admin_dir. Zmień wartość tak, aby dokładnie odpowiadała nowej nazwie katalogu.
Wyczyść cache. Usuń zawartość var/cache/prod/ i var/cache/dev/ (jeśli istnieje). Stary cache zawiera odwołania do poprzedniej nazwy katalogu administracyjnego.
Przetestuj nowy adres URL. Otwórz przeglądarkę i przejdź pod adres twojadomena.com/twoja-nowa-nazwa-admina/. Powinieneś zobaczyć stronę logowania PrestaShop.

Metoda 2: Przez SSH (Wiersz poleceń)

Jeśli masz dostęp SSH do serwera, możesz zmienić nazwę katalogu jednym poleceniem:

cd /var/www/html/prestashop
mv admin1234 twoja-nowa-nazwa

Następnie zaktualizuj konfigurację:

sed -i "s/admin1234/twoja-nowa-nazwa/g" app/config/parameters.php

I wyczyść cache:

rm -rf var/cache/prod/* var/cache/dev/*

Ta metoda jest szybsza i mniej podatna na błędy niż używanie FTP, szczególnie jeśli nazwa katalogu pojawia się w wielu miejscach pliku konfiguracyjnego.

Różnice między wersjami PrestaShop

PrestaShop 1.6

W PrestaShop 1.6 nazwa katalogu administracyjnego jest przechowywana w config/settings.inc.php zamiast w app/config/parameters.php. Szukaj linii w stylu:

define('_PS_ADMIN_DIR_', '/var/www/html/prestashop/admin1234');

Zmień ścieżkę, aby odpowiadała nowej nazwie katalogu. Struktura katalogu app/ nie istnieje w wersji 1.6, ponieważ poprzedza ona integrację z Symfony. Poza tym proces zmiany nazwy katalogu jest identyczny.

PrestaShop 1.7

PrestaShop 1.7 wprowadził framework Symfony, co dodało plik app/config/parameters.php. Jednak 1.7 nadal zachowuje wsteczną kompatybilność z niektórymi elementami starszego routingu administracyjnego. Po zmianie nazwy wyczyść zarówno cache Smarty (var/cache/), jak i cache Symfony. Nazwa katalogu administracyjnego jest przechowywana w parameters.php w tablicy parameters:

'parameters' => array(
    // ...
    'ps_admin_dir' => 'twoja-nowa-nazwa',
    // ...
)

PrestaShop 8.x

PrestaShop 8.x kontynuuje architekturę z wersji 1.7 z głębszą integracją Symfony. Proces jest taki sam jak w 1.7, ale plik parameters.php może w niektórych konfiguracjach używać konfiguracji opartej na YAML. Sprawdź zarówno app/config/parameters.php, jak i app/config/parameters.yml, jeśli istnieje. Po zmianie nazwy zawsze całkowicie wyczyść cache.

PrestaShop 9.x

PrestaShop 9.x dalej udoskonala integrację z Symfony. Koncepcja katalogu administracyjnego pozostaje, ale routing jest bardziej oparty na Symfony. Plik parameters.php lub parameters.yml nadal zawiera odniesienie do katalogu administracyjnego. Proces zmiany nazwy pozostaje niezmieniony, ale zwróć szczególną uwagę na wyczyszczenie wszystkich warstw cache, ponieważ cache routingu Symfony jest bardziej agresywny w wersji 9.x.

Aktualizacja .htaccess po zmianie nazwy

W większości przypadków nie musisz modyfikować pliku .htaccess w głównym katalogu PrestaShop po zmianie nazwy folderu administracyjnego. Reguły .htaccess PrestaShop zazwyczaj nie odwołują się do katalogu administracyjnego po nazwie. Reguły przekierowań obsługują front office (strony widoczne dla klientów), a katalog administracyjny jest dostępny bezpośrednio bez przepisywania adresów.

Istnieją jednak wyjątki. Jeśli dodałeś niestandardowe reguły bezpieczeństwa do .htaccess, które odwołują się do starej nazwy katalogu administracyjnego, musisz zaktualizować te reguły. Na przykład, jeśli wcześniej dodałeś białą listę IP dla obszaru administracyjnego:

# Stara reguła
<Directory /var/www/html/prestashop/admin1234>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.50
</Directory>

To musi zostać zaktualizowane, aby odwoływać się do nowej nazwy katalogu. Podobnie sprawdź wszelkie wtyczki bezpieczeństwa (takie jak reguły mod_security) lub konfiguracje CDN (reguły stron Cloudflare), które mogą odwoływać się do starej ścieżki administracyjnej.

Sprawdź również plik .htaccess wewnątrz samego katalogu administracyjnego. PrestaShop umieszcza go tam na potrzeby wewnętrznego routingu. Plik ten zazwyczaj nie wymaga modyfikacji, ponieważ używa ścieżek względnych, ale po zmianie nazwy zweryfikuj go, aby upewnić się, że nic nie jest zepsute.

Typowe pułapki i czego NIE robić

Nie używaj dowiązań symbolicznych jako skrótu

Niektórzy administratorzy tworzą dowiązanie symboliczne (symlink) z nowej nazwy do starego katalogu administracyjnego, zamiast faktycznie go zmieniać. To całkowicie niweczy cel, ponieważ stary katalog nadal istnieje i jest dostępny. Zawsze wykonuj prawdziwą zmianę nazwy, a nie tworzenie dowiązania symbolicznego.

Nie zapomnij zaktualizować parameters.php

Najczęstszym pojedynczym błędem jest zmiana nazwy katalogu bez zaktualizowania pliku konfiguracyjnego. Gdy tak się stanie, zobaczysz białą stronę lub błąd 500 przy próbie dostępu do panelu administracyjnego. PrestaShop wewnętrznie odwołuje się do nazwy katalogu administracyjnego z konfiguracji, a niezgodność powoduje natychmiastową awarię.

Nie wybieraj oczywistych nazw

Zmiana nazwy katalogu administracyjnego z admin1234 na admin lub administrator jest kontrproduktywna. Zautomatyzowane skanery sprawdzają te oczywiste nazwy w pierwszej kolejności. Wybierz coś, co łączy słowa i cyfry w sposób trudny do odgadnięcia: store-mgmt-7x9, bo-access-42, a nawet całkowicie losowy ciąg znaków jak kx9m4p2q.

Nie zmieniaj nazwy, gdy użytkownicy są zalogowani

Aktywne sesje back office zostaną natychmiast przerwane po zmianie nazwy katalogu. Każdy użytkownik administracyjny aktualnie zalogowany zobaczy błąd i utraci niezapisaną pracę. Wykonuj zmianę nazwy w okresie niskiego ruchu i powiadom personel korzystający z back office.

Nie zapomnij o zakładkach i zapisanych linkach

Po zmianie nazwy zaktualizuj wszelkie zakładki, zapisane hasła w przeglądarce, wpisy w menedżerze haseł i dokumentację odwołującą się do starego adresu URL panelu. Powiadom wszystkich pracowników mających dostęp do back office o nowym adresie URL.

Nie używaj znaków specjalnych ani spacji

Nazwa katalogu administracyjnego musi być prawidłowym komponentem ścieżki URL. Używaj wyłącznie małych liter, cyfr i myślników. Unikaj spacji, podkreślników (choć działają, myślniki są czystsze), znaków akcentowanych i wszelkich znaków specjalnych.

Konflikty modułów i uwagi dotyczące modułów zewnętrznych

Większość dobrze napisanych modułów PrestaShop używa wewnętrznych funkcji PrestaShop do określania ścieżki katalogu administracyjnego, zamiast ją hardkodować. Te moduły będą nadal działać po zmianie nazwy bez żadnej interwencji. Jednak niektóre źle zakodowane moduły mogą hardkodować ścieżkę administracyjną w swoich plikach konfiguracyjnych, JavaScript lub endpointach AJAX.

Po zmianie nazwy katalogu administracyjnego przetestuj następujące elementy w back office:

Wszystkie zainstalowane moduły — otwórz stronę konfiguracji każdego modułu
Każdy moduł korzystający z wywołań AJAX (sprawdź konsolę przeglądarki pod kątem błędów 404)
Callbacki i webhooki modułów płatności
Wszelkie niestandardowe integracje lub połączenia ERP odwołujące się do adresu URL panelu
Zadania cron wywołujące zadania po stronie administracyjnej

Jeśli moduł przestaje działać po zmianie nazwy, sprawdź jego pliki konfiguracyjne pod kątem zhardkodowanych ścieżek administracyjnych. Wiele modułów przechowuje swoje ustawienia w tabeli bazy danych ps_configuration, a niektóre z tych wartości mogą zawierać starą nazwę katalogu administracyjnego.

Aby przeszukać bazę danych pod kątem odwołań do starego katalogu administracyjnego:

SELECT * FROM ps_configuration WHERE value LIKE '%admin1234%';

Zastąp admin1234 starą nazwą katalogu, a ps_ rzeczywistym prefiksem Twojej bazy danych.

Dodatkowe środki bezpieczeństwa dla obszaru administracyjnego

Zmiana nazwy katalogu administracyjnego to dobry pierwszy krok, ale powinna być częścią kompleksowej strategii bezpieczeństwa. Rozważ te dodatkowe środki:

Biała lista adresów IP

Jeśli Ty i Twój zespół zawsze uzyskujecie dostęp do back office ze stałych adresów IP, możesz ograniczyć dostęp na poziomie serwera WWW. Dla Apache, dodaj do .htaccess w katalogu administracyjnym:

Order Deny,Allow
Deny from all
Allow from 203.0.113.50
Allow from 198.51.100.25

Dla Nginx, dodaj do bloku server:

location /twoja-nazwa-admina/ {
    allow 203.0.113.50;
    allow 198.51.100.25;
    deny all;
}

To jest niezwykle skuteczne, ponieważ nawet jeśli atakujący odkryje Twój adres URL panelu, nie będzie mógł uzyskać dostępu do strony logowania z nieautoryzowanego adresu IP.

Uwierzytelnianie dwuskładnikowe (2FA)

PrestaShop 8.x nie zawiera wbudowanego 2FA, ale kilka modułów zapewnia tę funkcjonalność. Uwierzytelnianie dwuskładnikowe wymaga dodatkowego kroku weryfikacji (zazwyczaj kodu z aplikacji mobilnej, takiej jak Google Authenticator) oprócz hasła. Dzięki temu ataki brute-force stają się praktycznie niemożliwe, nawet jeśli atakujący zna zarówno adres URL panelu, jak i hasło.

Certyfikat SSL/TLS

Zawsze uzyskuj dostęp do panelu administracyjnego przez HTTPS. Szyfruje to dane logowania podczas transmisji, zapobiegając atakom typu man-in-the-middle. Większość dostawców hostingu oferuje bezpłatne certyfikaty SSL przez Let's Encrypt. Back office PrestaShop powinien być skonfigurowany tak, aby wymuszał SSL w Parametry sklepu > Ogólne > Włącz SSL oraz Włącz SSL na wszystkich stronach.

Ograniczanie prób logowania

PrestaShop zawiera podstawową ochronę przed brute-force, która blokuje adresy IP po określonej liczbie nieudanych prób logowania. Upewnij się, że jest to włączone w ustawieniach bezpieczeństwa. Możesz również wdrożyć ograniczanie szybkości żądań (rate limiting) na poziomie serwera WWW za pomocą modułów takich jak mod_evasive dla Apache lub limit_req dla Nginx.

Regularna rotacja haseł

Upewnij się, że wszystkie konta administracyjne używają silnych, unikalnych haseł. Dobre hasło ma co najmniej 16 znaków i zawiera mieszankę liter, cyfr i symboli. Używaj menedżera haseł do generowania i przechowywania tych haseł. Zmieniaj hasła okresowo, szczególnie gdy pracownik odchodzi z firmy lub dochodzi do incydentu bezpieczeństwa.

Audyt kont administracyjnych

Regularnie przeglądaj listę kont administracyjnych w Zaawansowane > Zespół > Pracownicy. Usuń lub dezaktywuj konta pracowników, którzy nie potrzebują już dostępu. Każda osoba powinna mieć własne konto, zamiast dzielić się danymi logowania — umożliwia to śledzenie, kto wprowadził które zmiany.

Co zrobić, gdy utracisz dostęp

Jeśli zmienisz nazwę katalogu administracyjnego i nie możesz uzyskać dostępu do back office, nie panikuj. Połącz się z serwerem przez FTP lub SSH i albo zmień nazwę katalogu z powrotem na oryginalną, albo sprawdź plik parameters.php, aby upewnić się, że nazwa katalogu się zgadza. Jeśli zgubiłeś zarówno nazwę katalogu, jak i konfigurację, sprawdź rzeczywistą listę katalogów na serwerze — katalog administracyjny to ten, który zawiera pliki takie jak ajax-tab.php, init.php oraz podkatalog themes/ z motywem back office.

Możesz również znaleźć nazwę katalogu administracyjnego w bazie danych:

SELECT value FROM ps_configuration WHERE name = 'PS_ADMIN_DIR';

Pamiętaj jednak, że nie wszystkie wersje PrestaShop przechowują tę wartość w tabeli konfiguracji. Plik parameters.php jest autorytatywnym źródłem informacji.

Automatyzacja zmiany adresu URL panelu za pomocą narzędzia

Jeśli zarządzasz wieloma instalacjami PrestaShop, możesz stworzyć prosty skrypt powłoki do automatyzacji procesu zmiany nazwy:

#!/bin/bash
OLD_NAME="$1"
NEW_NAME="$2"
PS_ROOT="/var/www/html/prestashop"

if [ -z "$OLD_NAME" ] || [ -z "$NEW_NAME" ]; then
    echo "Użycie: $0 stara-nazwa-admina nowa-nazwa-admina"
    exit 1
fi

mv "$PS_ROOT/$OLD_NAME" "$PS_ROOT/$NEW_NAME"
sed -i "s/$OLD_NAME/$NEW_NAME/g" "$PS_ROOT/app/config/parameters.php"
rm -rf "$PS_ROOT/var/cache/prod/*" "$PS_ROOT/var/cache/dev/*"
echo "Katalog administracyjny zmieniony z $OLD_NAME na $NEW_NAME"
echo "Proszę zweryfikować dostęp pod adresem: twojadomena.com/$NEW_NAME/"

Zapisz to jako rename-admin.sh, nadaj mu uprawnienia do wykonywania poleceniem chmod +x rename-admin.sh i uruchom go z nazwami starego i nowego katalogu jako argumentami. Zawsze testuj nowy adres URL natychmiast po uruchomieniu narzędzia.

Stosując się do tych kroków i łącząc zmianę adresu URL panelu z dodatkowymi środkami bezpieczeństwa, znacząco zmniejszysz powierzchnię ataku back office Twojego sklepu PrestaShop.

Przeczytaj pełną odpowiedź

Przejście silnika szablonów w PrestaShop

PrestaShop przechodzi jedną z najważniejszych zmian architektonicznych w swojej historii — migrację z Smarty na Twig jako główny silnik szablonów. Ta zmiana, rozpoczęta w PrestaShop 1.7 i osiągająca ważny kamień milowy w PrestaShop 9.0 (wydanym w czerwcu 2025), dotyczy każdego programisty, projektanta motywów i twórcy modułów pracującego z platformą.

Zrozumienie tej zmiany jest kluczowe, niezależnie od tego, czy utrzymujesz istniejący sklep, planujesz aktualizację, czy rozwijasz nowe moduły i motywy. Ten przewodnik omawia, co się zmieniło, co się jeszcze zmienia i jak przygotować swoje projekty PrestaShop na erę Twig.

Czym są Smarty i Twig?

Smarty - Silnik klasyczny

Smarty to silnik szablonów PHP, który napędza PrestaShop od jego początków. Oddziela logikę biznesową PHP od prezentacji HTML.

Główne cechy Smarty -

Pliki szablonów używają rozszerzenia .tpl
Zmienne są dostępne za pomocą nawiasów klamrowych i znaku dolara - {$variable}
Modyfikatory używają składni pipe - {$variable|escape:'html'}
Bloki używają sparowanych tagów - {block name='content'}{/block}
Dziedziczenie szablonów przez {extends file='parent.tpl'}

Twig - Nowoczesny silnik

Twig to silnik szablonów zbudowany przez SensioLabs, firmę stojącą za frameworkiem Symfony. Ponieważ PrestaShop stopniowo adoptuje komponenty Symfony, przejście na Twig jest naturalną ewolucją.

Główne cechy Twig -

Pliki szablonów używają rozszerzenia .html.twig
Zmienne używają podwójnych nawiasów klamrowych - {{ variable }}
Filtry używają składni pipe - {{ variable|escape('html') }}
Bloki używają sparowanych tagów - {% block content %}{% endblock %}
Dziedziczenie szablonów przez {% extends 'parent.html.twig' %}

Porównanie składni - obok siebie

Wyświetlanie zmiennych

Funkcja	Smarty	Twig
Prosta zmienna	`{$product.name}`	`{{ product.name }}`
Dostęp do tablicy	`{$products[0].name}`	`{{ products[0].name }}`
Metoda obiektu	`{$product->getName()}`	`{{ product.getName() }}`
Wartość domyślna	`{$var\|default:'N/A'}`	`{{ var\|default('N/A') }}`

Struktury kontrolne

<!-- Smarty: if/else -->
{if $product.active}
  <span class="badge badge-success">Aktywny</span>
{elseif $product.pending}
  <span class="badge badge-warning">Oczekujący</span>
{else}
  <span class="badge badge-danger">Nieaktywny</span>
{/if}

<!-- Twig: if/else -->
{% if product.active %}
  <span class="badge badge-success">Aktywny</span>
{% elseif product.pending %}
  <span class="badge badge-warning">Oczekujący</span>
{% else %}
  <span class="badge badge-danger">Nieaktywny</span>
{% endif %}

Pętle

<!-- Smarty: pętla foreach -->
{foreach $products as $product}
  <div class="product">
    <h3>{$product.name}</h3>
    <p>{$product.price|number_format:2:',':'.'}</p>
  </div>
{foreachelse}
  <p>Nie znaleziono produktów.</p>
{/foreach}

<!-- Twig: pętla for -->
{% for product in products %}
  <div class="product">
    <h3>{{ product.name }}</h3>
    <p>{{ product.price|number_format(2, ',', '.') }}</p>
  </div>
{% else %}
  <p>Nie znaleziono produktów.</p>
{% endfor %}

Co się już zmieniło - oś czasu

PrestaShop 1.7 (2016)

Rozpoczęcie migracji. Back office zaczął adoptować kontrolery Symfony z szablonami Twig. Front office pozostał w pełni oparty na Smarty.

PrestaShop 8.x (2022-2024)

Więcej stron back office zostało zmigrowanych do Symfony i Twig. Kluczowe strony administracyjne jak Produkty, Zamówienia i Klienci otrzymały przepisane szablony Twig.

PrestaShop 9.0 (czerwiec 2025)

Ważny kamień milowy. Back office jest teraz w pełni zmigrowany do kontrolerów Symfony i szablonów Twig. Jednak Smarty wciąż jest obecny, ponieważ -

Front office (motywy) nadal głównie używa Smarty
Wiele modułów firm trzecich nadal używa szablonów Smarty
Strony administracyjne modułów używające starych AdminControllerów wciąż opierają się na Smarty

Wpływ na właścicieli sklepów

Jeśli używasz PrestaShop 1.7 lub 8.x

Nic się nie zmienia natychmiast. Twoje obecne motywy i moduły będą nadal działać. Planuj jednak ewentualną aktualizację do PrestaShop 9.0.

Jeśli aktualizujesz do PrestaShop 9.0

Największy wpływ dotyczy modułów modyfikujących strony back office. Sprawdź kompatybilność u deweloperów modułów przed aktualizacją.

Wpływ na deweloperów modułów

Szablony administracyjne modułów

Dla kompatybilności z PrestaShop 8.x (podejście klasyczne) -

class AdminMyModuleController extends ModuleAdminController
{
    public function renderList()
    {
        $this->context->smarty->assign([
            'my_data' => $this->getMyData(),
        ]);
        return $this->display(__FILE__, 'views/templates/admin/list.tpl');
    }
}

Dla PrestaShop 9.0+ (nowoczesne podejście) -

class MyModuleAdminController extends FrameworkBundleAdminController
{
    public function listAction(): Response
    {
        return $this->render('@Modules/mymodule/views/templates/admin/list.html.twig', [
            'my_data' => $this->getMyData(),
        ]);
    }
}

Wsparcie wielu wersji PrestaShop

if (version_compare(_PS_VERSION_, '9.0.0', '>=')) {
    return $this->render('@Modules/mymodule/admin/config.html.twig', $params);
} else {
    $this->context->smarty->assign($params);
    return $this->display($this->file, 'views/templates/admin/config.tpl');
}

Zalety Twig nad Smarty

Lepsza bezpieczeństwo

Twig automatycznie escapuje wyjście domyślnie, znacznie zmniejszając ryzyko XSS.

<!-- Twig: automatycznie escapowany domyślnie -->
{{ user_input }}  <!-- Encje HTML escapowane automatycznie -->
{{ trusted_html|raw }}  <!-- Jawnie oznaczony jako bezpieczny -->

<!-- Smarty: ręczne escapowanie wymagane -->
{$user_input|escape:'html'}  <!-- Musisz pamiętać o escapowaniu -->
{$user_input}  <!-- NIEBEZPIECZNE: brak escapowania -->

Integracja z Symfony

Twig integruje się natywnie z routingiem Symfony, renderowaniem formularzy, systemem tłumaczeń i komponentami bezpieczeństwa.

Lepsze komunikaty błędów

Twig dostarcza czytelne komunikaty błędów z dokładnymi numerami linii.

Nowoczesne narzędzia

Twig ma doskonałe wsparcie IDE z podświetlaniem składni, automatycznym uzupełnianiem i lintingiem w PhpStorm, VS Code i innych edytorach.

Typowe wzorce migracji

Tłumaczenie ciągów znaków

<!-- Smarty -->
{l s='Dodaj do koszyka' mod='mymodule'}

<!-- Twig -->
{{ 'Dodaj do koszyka'|trans({}, 'Modules.Mymodule.Shop') }}

Renderowanie hooków

<!-- Smarty -->
{hook h='displayProductButtons'}

<!-- Twig -->
{{ renderhook('displayProductButtons') }}

Nadpisywanie szablonów back office w PrestaShop 9

# Lokalizacja nadpisania modułu
modules/mymodule/views/PrestaShop/Admin/Product/CatalogPage/catalog.html.twig

{% extends '@PrestaShopCore/Admin/Product/CatalogPage/catalog.html.twig' %}

{% block product_catalog_tools %}
  {{ parent() }}
  <div class="my-custom-toolbar">
    <!-- Dodatkowa zawartość paska narzędzi -->
  </div>
{% endblock %}

Praktyczne porady dla właścicieli sklepów

Nie panikuj

Migracja jest stopniowa. Smarty nie zostanie usunięty z dnia na dzień.

Sprawdź kompatybilność modułów przed aktualizacją

Przed aktualizacją do PrestaShop 9.0 zweryfikuj, że każdy moduł jest kompatybilny.

Rozważ profesjonalną pomoc przy złożonych sklepach

Przy rozbudowanych customizacjach zatrudnij doświadczonego developera PrestaShop.

Testuj wszystko w środowisku stagingowym

Nigdy nie aktualizuj swojego sklepu produkcyjnego bezpośrednio.

Przeczytaj pełną odpowiedź

Dlaczego migracja serwera wymaga planowania

Przeniesienie sklepu PrestaShop na nowy serwer to jedna z najbardziej krytycznych operacji. Przy odpowiednim planowaniu możesz zredukować przestój do minut — a nawet osiągnąć płynne przejście bez widocznego przestoju dla klientów.

Lista kontrolna przed migracją

Zweryfikuj wymagania nowego serwera
Udokumentuj obecną konfigurację
Wylistuj wszystkie domeny i subdomeny
Zidentyfikuj niestandardowe pliki
Zaplanuj certyfikat SSL

Faza 1 - Przygotowanie nowego serwera

sudo apt update
sudo apt install apache2 mysql-server php8.1 php8.1-mysql \
  php8.1-gd php8.1-curl php8.1-intl php8.1-mbstring \
  php8.1-zip php8.1-xml php8.1-bcmath
sudo a2enmod rewrite ssl headers expires

Konfiguracja PHP

memory_limit = 512M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Utworzenie bazy danych

CREATE DATABASE prestashop CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'ps_user'@'localhost' IDENTIFIED BY 'silne_haslo';
GRANT ALL PRIVILEGES ON prestashop.* TO 'ps_user'@'localhost';

Faza 2 - Transfer plików

rsync -avz --progress -e ssh \
  /var/www/html/prestashop/ \
  user@nowy-serwer:/var/www/html/prestashop/

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

Faza 3 - Transfer bazy danych

mysqldump -u root -p --single-transaction --routines --triggers \
  prestashop > /tmp/prestashop_db.sql

scp /tmp/prestashop_db.sql user@nowy-serwer:/tmp/
mysql -u ps_user -p prestashop < /tmp/prestashop_db.sql

Faza 4 - Aktualizacja konfiguracji

Edytuj app/config/parameters.php z nowymi danymi bazy danych. NIE zmieniaj URL-i sklepu.

Faza 5 - Test na nowym serwerze

Zmień plik hosts na swoim komputerze, aby wskazywał na nowy serwer i przetestuj dokładnie cały sklep.

Faza 6 - Przełączenie

Obniż TTL DNS 48 godzin wcześniej
Włącz tryb konserwacji na starym sklepie
Finalna synchronizacja bazy danych
Finalna synchronizacja plików
Zmień rekordy DNS
Wyłącz tryb konserwacji na nowym sklepie

Faza 7 - Weryfikacja po migracji

Wyczyść wszystkie cache
Zregeneruj .htaccess
Zweryfikuj SSL
Przetestuj dostarczanie emaili
Sprawdź zadania cron
Utrzymuj oba serwery przez 48-72 godziny

Typowe pułapki migracji

Zakodowane na twardo ścieżki w plikach modułów
Konfiguracja emaili
URL-e obrazów
Mixed content po SSL

Przeczytaj pełną odpowiedź

Dlaczego zrozumienie bazy danych ma znaczenie

PrestaShop przechowuje wszystko — produkty, zamówienia, klientów, ustawienia, tłumaczenia, obrazy, ceny — w bazie danych MySQL. Zrozumienie struktury bazy danych daje Ci supermoc do szybszego diagnozowania problemów, wykonywania masowych operacji i odzyskiwania się po błędach.

Tabele produktów

ps_product

Główna tabela produktów z podstawowymi danymi -

Kolumna	Cel
id_product	Unikalny identyfikator produktu
price	Cena bazowa (bez podatku)
reference	Referencja/SKU produktu
active	Włączony (1) lub wyłączony (0)

ps_product_lang

Dane produktu specyficzne dla języka - nazwa, opis, meta tytuł, URL.

ps_stock_available

Rzeczywista tabela śledzenia stanów magazynowych.

SELECT * FROM ps_stock_available 
WHERE id_product = 42 AND id_product_attribute = 0;

Tabele zamówień

ps_orders

Najważniejsza tabela handlowa. Każdy wiersz to zamówienie.

ps_order_detail

Poszczególne pozycje w zamówieniu z produktem, ilością i ceną.

SELECT o.reference, o.date_add, o.total_paid_tax_incl,
  od.product_name, od.product_quantity, od.unit_price_tax_incl
FROM ps_orders o
JOIN ps_order_detail od ON o.id_order = od.id_order
WHERE o.id_order = 12345;

Tabele klientów

ps_customer

Konta klientów z emailem, zahaszowanym hasłem, imieniem, statusem newslettera.

SELECT c.id_customer, c.email, c.firstname, c.date_add
FROM ps_customer c
LEFT JOIN ps_orders o ON c.id_customer = o.id_customer
WHERE o.id_order IS NULL AND c.active = 1;

Tabele koszyka

ps_cart i ps_cart_product

Koszyki i ich produkty. Porzucone koszyki pozostają tutaj.

SELECT c.id_cart, cu.email, c.date_add
FROM ps_cart c
JOIN ps_customer cu ON c.id_customer = cu.id_customer
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_order IS NULL
AND c.date_add > DATE_SUB(NOW(), INTERVAL 7 DAY);

Tabele konfiguracji

ps_configuration

Magazyn klucz-wartość dla wszystkich ustawień.

SELECT name, value FROM ps_configuration 
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SSL_ENABLED', 'PS_SHOP_ENABLE');

Tabele modułów i hooków

ps_module, ps_hook, ps_hook_module

Moduły, hooki i ich powiązania. ps_hook_module kontroluje kolejność wykonania.

Typowe operacje

-- Podwyżka cen o 10%
UPDATE ps_product SET price = price * 1.10;

-- Wyłączenie produktów niedostępnych
UPDATE ps_product p
JOIN ps_stock_available sa ON p.id_product = sa.id_product 
SET p.active = 0
WHERE sa.quantity <= 0 AND sa.id_product_attribute = 0;

Zasady bezpieczeństwa bazy danych

Zawsze twórz kopię zapasową przed modyfikacjami
Nigdy nie modyfikuj ps_shop_url bezpośrednio
Testuj zapytania z SELECT przed uruchomieniem UPDATE lub DELETE

Przeczytaj pełną odpowiedź

Czym są hooki w PrestaShop?

Hooki to mechanizm rozszerzeń PrestaShop — punkty w kodzie, gdzie moduły mogą się podpinać, aby dodawać funkcjonalność, modyfikować zachowanie lub wstrzykiwać treść na strony.

Dwa typy hooków

Hooki wyświetlania

Hooki wyświetlania (z prefiksem display) wstrzykują treść HTML na stronę. Przykłady -

displayHeader — w sekcji <head>
displayHome — obszar treści strony głównej
displayFooter — stopka
displayProductAdditionalInfo — dodatkowe informacje o produkcie

Hooki akcji

Hooki akcji (z prefiksem action) wykonują logikę bez zwracania HTML. Przykłady -

actionCartSave — gdy koszyk jest zapisywany
actionOrderStatusUpdate — przy zmianie statusu zamówienia
actionValidateOrder — przy walidacji zamówienia

Jak działa kolejność wykonania

PrestaShop sprawdza tabelę ps_hook_module, aby znaleźć moduły zarejestrowane na hooku. Moduły są wykonywane w kolejności kolumny position.

SELECT hm.position, m.name AS module_name, h.name AS hook_name
FROM ps_hook_module hm
JOIN ps_module m ON hm.id_module = m.id_module
JOIN ps_hook h ON hm.id_hook = h.id_hook
WHERE h.name = 'displayHeader'
ORDER BY hm.position ASC;

Dlaczego pozycja ma znaczenie

Dla hooków wyświetlania pozycja określa kolejność wizualną. Dla hooków akcji pozycja określa kolejność przetwarzania.

Rejestrowanie hooków w module

public function install()
{
    return parent::install()
        && $this->registerHook('displayHeader')
        && $this->registerHook('displayProductAdditionalInfo')
        && $this->registerHook('actionCartSave');
}

public function hookDisplayHeader($params)
{
    $this->context->controller->addCSS($this->_path . 'views/css/style.css');
}

public function hookActionCartSave($params)
{
    $cart = $params['cart'];
    $this->logCartActivity($cart);
}

Zarządzanie pozycjami hooków w Back Office

Przejdź do Wygląd > Pozycje, aby zobaczyć wszystkie hooki i przypisane moduły. Możesz zmieniać kolejność przez przeciąganie lub przesadzanie modułów.

Typowe problemy z wykonaniem hooków

Konflikty modułów

Gdy dwa moduły na tym samym hooku wyświetlania produkują zduplikowaną treść, zmień ich kolejność lub odpnij problematyczny moduł.

Wpływ na wydajność

SELECT h.name, COUNT(*) AS module_count
FROM ps_hook_module hm
JOIN ps_hook h ON hm.id_hook = h.id_hook
GROUP BY h.name
ORDER BY module_count DESC
LIMIT 20;

Ważne hooki dla właścicieli sklepów

Checkout - displayPayment, paymentOptions, actionValidateOrder
SEO - displayHeader, filterHtmlContent
Wyświetlanie produktu - displayProductAdditionalInfo, displayAfterProductThumbs

Przeczytaj pełną odpowiedź

RODO a e-commerce: co muszą wiedzieć właściciele sklepów

Ogólne rozporządzenie o ochronie danych (RODO) weszło w życie w maju 2018 roku i fundamentalnie zmieniło sposób, w jaki firmy e-commerce obchodzą się z danymi osobowymi. Jeśli Twój sklep PrestaShop obsługuje klientów z Europejskiego Obszaru Gospodarczego, podlegasz RODO niezależnie od tego, gdzie fizycznie znajduje się Twoja firma. Rozporządzenie przyznaje osobom fizycznym określone prawa dotyczące ich danych osobowych, a Twój sklep musi posiadać techniczne i organizacyjne możliwości realizacji tych praw.

Dla właścicieli sklepów PrestaShop najbardziej wymagające operacyjnie aspekty RODO to wnioski o dostęp do danych (SAR — Subject Access Request) oraz wnioski o usunięcie danych. SAR to sytuacja, gdy klient prosi o dostarczenie kopii wszystkich danych osobowych, które przechowujesz na jego temat. Wniosek o usunięcie, znany również jako prawo do bycia zapomnianym, to sytuacja, gdy klient prosi o usunięcie jego danych osobowych. Oba muszą być obsłużone w ściśle określonych terminach, a ich niespełnienie może skutkować znacznymi karami finansowymi.

Ten artykuł obejmuje stronę praktyczną: jakie dane PrestaShop przechowuje, jak je eksportować, jak je usuwać lub anonimizować, co musisz zachować ze względów prawnych i jak zbudować niezawodny proces obsługi tych wniosków.

Jakie dane osobowe przechowuje PrestaShop

Zanim będziesz mógł odpowiedzieć na jakikolwiek wniosek o dane, musisz dokładnie wiedzieć, gdzie w Twojej instalacji PrestaShop znajdują się dane osobowe. Dane osobowe to wszelkie informacje, które mogą zidentyfikować osobę fizyczną, bezpośrednio lub pośrednio. W typowym sklepie PrestaShop dane osobowe są rozproszone po wielu tabelach bazy danych i potencjalnie po modułach firm trzecich.

Główne tabele PrestaShop zawierające dane osobowe

Tabela ps_customer przechowuje podstawowy rekord klienta: imię i nazwisko, adres e-mail, datę urodzenia, datę utworzenia konta, adres IP przy rejestracji i flagi zgody na marketing. Tabela ps_address przechowuje adresy dostawy i fakturowania, w tym pełne imię i nazwisko, ulicę, miasto, kod pocztowy, kraj i numery telefonów. Pojedynczy klient może mieć wiele adresów.

Tabela ps_orders zawiera historię zamówień powiązaną z klientami, w tym metody płatności i szczegóły dostawy. Tabela ps_order_detail przechowuje pozycje zamówienia dla każdego zamówienia. Tabela ps_cart przechowuje dane koszyka, które obejmują wybrane produkty i mogą być powiązane z klientem. Tabele ps_message i ps_customer_message zawierają wiadomości wymienione między klientem a sklepem poprzez formularz kontaktowy lub system wiadomości zamówienia.

Tabele ps_connections i ps_connections_source śledzą połączenia odwiedzających, w tym adresy IP i URL-e źródłowe. Tabela ps_guest przechowuje dane gości powiązane z ciasteczkami. Tabela ps_customer_session (w nowszych wersjach) śledzi sesje logowania.

Dane w modułach firm trzecich

Każdy moduł, który zbiera lub przetwarza dane klientów, tworzy dodatkowe miejsca przechowywania danych. Moduły newslettera przechowują adresy e-mail. Moduły recenzji przechowują imiona klientów i tekst recenzji. Moduły list życzeń łączą preferencje produktowe z kontami klientów. Moduły lojalnościowe i programów nagród śledzą zachowania zakupowe. Moduły analityczne mogą przechowywać wzorce przeglądania. Każdy z tych modułów musi być uwzględniony przy odpowiadaniu na wniosek o dane.

Dlatego utrzymywanie rejestru przetwarzania danych — dokumentu wymieniającego każde miejsce, w którym przechowywane są dane osobowe — jest nie tylko dobrą praktyką, ale wymogiem RODO. Bez niego nie możesz zagwarantować kompletności odpowiedzi na wniosek SAR.

Moduł RODO PrestaShop

PrestaShop udostępnia oficjalny moduł zgodności z RODO (psgdpr), który obsługuje podstawowe wymagania dotyczące wniosków o dane. Ten moduł jest dostępny dla PrestaShop 1.7 i nowszych wersji i można go zainstalować z katalogu modułów w panelu administracyjnym.

Co robi moduł

Moduł RODO dodaje do sklepu framework zarządzania zgodami, umożliwiający śledzenie, kiedy i gdzie klienci wyrazili zgodę na przetwarzanie danych. Dodaje checkboxy zgody do formularzy rejestracji, formularzy kontaktowych i formularzy zapisu na newsletter. Każde działanie związane ze zgodą jest rejestrowane ze znacznikiem czasu.

W zakresie wniosków o dane moduł zapewnia dwie kluczowe funkcje. Funkcja eksportu danych generuje plik PDF lub CSV zawierający wszystkie dane osobowe powiązane z adresem e-mail klienta. Funkcja usuwania danych anonimizuje lub usuwa dane osobowe danego klienta.

Moduł dodaje również sekcję na stronie konta klienta w front office, gdzie klienci mogą przeglądać i pobierać własne dane oraz bezpośrednio składać wnioski o usunięcie.

Konfiguracja modułu

Po instalacji przejdź do strony konfiguracji modułu. Znajdziesz tam sekcje do zarządzania checkboxami zgody (które formularze wymagają zgody i jaki tekst wyświetlać), konfigurowania, które moduły są zgodne z RODO (moduł może odpytywać kompatybilne moduły o przechowywane dane) oraz konfiguracji stron przenoszenia danych i usuwania danych widocznych dla klientów.

Moduł integruje się z innymi modułami zgodnymi z RODO poprzez znormalizowany interfejs. Gdy moduł implementuje hooki RODO, moduł psgdpr może automatycznie uwzględnić dane tego modułu w operacjach eksportu i usuwania. Sprawdź, które z zainstalowanych modułów wspierają tę integrację, ponieważ moduły, które jej nie wspierają, będą wymagały obsługi ręcznej.

Obsługa wniosków o dostęp do danych (SAR)

Gdy klient zażąda dostępu do swoich danych osobowych, masz jeden miesiąc kalendarzowy na odpowiedź. Ten termin biegnie od dnia otrzymania wniosku i obejmuje czas potrzebny na weryfikację tożsamości wnioskodawcy. Jeśli wniosek jest złożony lub otrzymujesz dużą liczbę wniosków, możesz przedłużyć ten termin o dodatkowe dwa miesiące, ale musisz poinformować klienta o przedłużeniu w ciągu pierwszego miesiąca.

Weryfikacja tożsamości

Przed udostępnieniem jakichkolwiek danych osobowych musisz zweryfikować, że osoba składająca wniosek jest tym, za kogo się podaje. Jeśli wniosek pochodzi z zalogowanego konta klienta, jest to zazwyczaj wystarczająca weryfikacja. Jeśli wniosek przychodzi e-mailem, powinieneś poprosić wnioskodawcę o potwierdzenie szczegółów, które znałby tylko posiadacz konta, takich jak numery ostatnich zamówień lub adres w aktach. Nie proś o nadmierne dokumenty weryfikacyjne, ponieważ samo w sobie może to stanowić naruszenie RODO (zasada minimalizacji danych), ale zrób wystarczająco dużo, aby zapobiec nieuprawnionemu ujawnieniu danych.

Korzystanie z modułu RODO do eksportu

W panelu administracyjnym PrestaShop przejdź do konfiguracji modułu RODO i znajdź sekcję zarządzania danymi osobowymi. Wprowadź adres e-mail klienta i użyj funkcji eksportu. Moduł wygeneruje plik zawierający dane z głównych tabel PrestaShop oraz z modułów kompatybilnych z RODO.

Przejrzyj wyeksportowane dane przed wysłaniem ich do klienta. Eksport powinien zawierać: dane konta klienta (imię i nazwisko, e-mail, datę urodzenia, datę rejestracji), wszystkie adresy w aktach, historię zamówień ze szczegółami, historię koszyków, wiadomości i korespondencję, logi zgód oraz wszelkie dane specyficzne dla modułów (subskrypcje newslettera, recenzje, listy życzeń).

Co musi zawierać eksport

Zgodnie z artykułem 15 RODO eksport danych musi zawierać nie tylko surowe dane, ale również informacje o tym, jak dane są przetwarzane. W szczególności powinieneś podać: kategorie przetwarzanych danych osobowych, cele przetwarzania, wszelkie strony trzecie, którym dane zostały udostępnione (procesory płatności, przewoźnicy, platformy marketingowe), okres przechowywania lub kryteria jego określania oraz informacje o prawach klienta (sprostowanie, usunięcie, ograniczenie, sprzeciw).

Moduł RODO obsługuje eksport surowych danych, ale informacje kontekstowe o celach przetwarzania i udostępnianiu stronom trzecim zazwyczaj muszą pochodzić z Twojej polityki prywatności. Rozważ dołączenie linku do polityki prywatności do eksportu danych lub załączenie listu przewodniego podsumowującego te informacje.

Ręczny eksport dla niezintegrowanych modułów

Dla modułów, które nie integrują się z modułem RODO, musisz ręcznie wyodrębnić dane. Zazwyczaj obejmuje to bezpośrednie odpytywanie tabel bazy danych modułu. Na przykład moduł recenzji produktów może przechowywać dane w tabeli typu ps_product_comment z ID klienta jako kluczem obcym. Musisz wyeksportować wszystkie wiersze powiązane z ID klienta.

Udokumentuj te ręczne kroki w procedurze obsługi SAR, aby nie zostały pominięte, gdy wniosek obsługuje inny członek zespołu.

Prawo do usunięcia: anonimizacja vs pełne usunięcie

Prawo do usunięcia (artykuł 17) pozwala klientom żądać usunięcia ich danych osobowych. Jednak to prawo nie jest absolutne. Istnieją uzasadnione powody do zachowania pewnych danych, a zrozumienie tych wyjątków jest kluczowe dla prawidłowej obsługi wniosków o usunięcie.

Kiedy musisz usunąć

Jeśli klient żąda usunięcia i żaden z wyjątków nie ma zastosowania, musisz usunąć lub zanonimizować jego dane osobowe bez zbędnej zwłoki (ten sam jednomiesięczny termin co dla SAR). Dane muszą być usunięte ze wszystkich systemów, w tym z kopii zapasowych, jeśli jest to technicznie możliwe. Musisz również powiadomić wszelkie strony trzecie, którym udostępniłeś dane (procesory płatności, narzędzia marketingowe), aby mogły usunąć swoje kopie.

Kiedy możesz odmówić usunięcia

Artykuł 17(3) RODO wymienia kilka wyjątków, w których możesz odmówić realizacji wniosku o usunięcie. Najbardziej istotne dla e-commerce to:

Obowiązek prawny: Prawo podatkowe w większości krajów UE wymaga przechowywania faktur i dokumentów finansowych przez określony okres, zazwyczaj od 5 do 10 lat w zależności od jurysdykcji. Oznacza to, że nie możesz usunąć danych zamówień potrzebnych do zgodności podatkowej, nawet jeśli klient zażąda usunięcia. Musisz zachować dane fakturowe (imię i nazwisko, adres, szczegóły zamówienia, kwoty) przez wymagany prawem okres.

Roszczenia prawne: Jeśli istnieje trwający spór, roszczenie gwarancyjne lub potencjalne postępowanie prawne związane z zamówieniami klienta, możesz zachować dane niezbędne do ustalenia, wykonania lub obrony przed roszczeniami prawnymi.

Obowiązek umowny: Jeśli zamówienie jest nadal przetwarzane, wysyłane lub mieści się w okresie zwrotu/gwarancji, masz uzasadniony powód do zachowania powiązanych danych do momentu pełnego zakończenia transakcji.

Podejście anonimizacyjne

Praktycznym rozwiązaniem dla większości sklepów e-commerce jest anonimizacja zamiast pełnego usunięcia. Anonimizacja oznacza zastąpienie danych osobowych nieidentyfikowalnymi zamiennikami przy jednoczesnym zachowaniu rekordów transakcyjnych potrzebnych do celów księgowych i prawnych.

Na przykład zamiast usuwania rekordu zamówienia w całości, zastąpiłbyś imię i nazwisko klienta czymś w stylu "Klient zanonimizowany" lub hashem, e-mail zamiennikiem typu "deleted@anonymized.invalid", adres ogólnymi wartościami ("Adres usunięty", "Miasto usunięte") i usunął numery telefonów. Samo zamówienie — w tym szczegóły produktów, ilości, ceny i kwoty podatków — pozostaje nienaruszone dla celów księgowych, ale nie może już być powiązane z identyfikowalną osobą.

Moduł RODO PrestaShop domyślnie używa tego podejścia anonimizacyjnego. Gdy przetwarzasz wniosek o usunięcie przez moduł, zastępuje on identyfikatory osobowe zanonimizowanymi wartościami zamiast całkowicie usuwać rekordy.

Co jest anonimizowane vs usuwane

W typowej operacji usuwania RODO w PrestaShop dzieje się następujące. Konto klienta jest dezaktywowane, a pola osobowe anonimizowane (imię i nazwisko staje się anonimowe, e-mail staje się hashem, data urodzenia jest czyszczona). Wszystkie adresy powiązane z klientem są anonimizowane (imiona i nazwiska, adresy ulic i numery telefonów zastąpione). Koszyki klienta są usuwane w całości, ponieważ nie mają wymogu prawnego przechowywania. Wiadomości i korespondencja z obsługą klienta są anonimizowane lub usuwane. Subskrypcje newslettera są usuwane. Rekordy gości i logi połączeń powiązane z klientem są czyszczone.

Rekordy zamówień są anonimizowane, ale zachowane: imię i nazwisko oraz adres klienta na zamówieniu są zastępowane anonimowymi wartościami, ale szczegóły zamówienia (produkty, ceny, podatki) pozostają dla zgodności księgowej. Faktury wygenerowane z tych zamówień nadal istnieją, ale z zanonimizowanymi danymi klienta.

Techniczne kroki przetwarzania wniosku o usunięcie

Krok 1: Zweryfikuj tożsamość i udokumentuj wniosek

Przed przetworzeniem jakiegokolwiek usunięcia zweryfikuj tożsamość wnioskodawcy, korzystając z tych samych metod opisanych dla SAR. Zaloguj wniosek ze znacznikiem czasu, tożsamością wnioskodawcy i zastosowaną metodą weryfikacji. Ten log sam w sobie jest wymogiem zgodności. Musisz wykazać, że wniosek został przetworzony i kiedy.

Krok 2: Sprawdź wyjątki dotyczące przechowywania

Przejrzyj historię zamówień klienta. Jeśli ma zamówienia w ramach Twojego prawnego okresu przechowywania (sprawdź lokalne wymogi prawa podatkowego), te rekordy zamówień muszą być zachowane w zanonimizowanej formie. Jeśli istnieją otwarte zamówienia, trwające spory lub aktywne roszczenia gwarancyjne, usunięcie powiązanych danych powinno być odroczone do momentu ich rozwiązania.

Krok 3: Przetwórz usunięcie

Użyj funkcji usuwania modułu RODO dla podstawowych danych. Wprowadź adres e-mail klienta w panelu administracyjnym modułu i wykonaj usunięcie. Moduł zanonimizuje dane w głównych tabelach i w modułach zintegrowanych z RODO.

Dla modułów niezintegrowanych z modułem RODO musisz obsłużyć usunięcie ręcznie. Może to obejmować uruchomienie zapytań SQL w celu anonimizacji lub usunięcia danych w tabelach specyficznych dla modułu lub skorzystanie z interfejsu administracyjnego modułu do usunięcia danych klienta.

Krok 4: Obsłuż zewnętrzne podmioty przetwarzające dane

Zidentyfikuj wszystkie usługi stron trzecich, które otrzymały dane klienta. Zazwyczaj obejmuje to procesor płatności (Stripe, PayPal, Mollie), przewoźników, którzy otrzymali adresy dostawy, platformy e-mail marketingowe (Mailchimp, Sendinblue) oraz wszelkie usługi analityczne przetwarzające dane osobowe. Skontaktuj się z każdym procesorem i zażądaj usunięcia danych klienta. Większość głównych procesorów ma własne procesy usuwania danych RODO. Udokumentuj każdą komunikację.

Krok 5: Potwierdź zakończenie

Wyślij potwierdzenie do klienta (na jego adres e-mail, zanim go zanonimizujesz, lub przez kanał komunikacji, którego użył do złożenia wniosku), informując, że jego dane zostały usunięte. Dołącz datę usunięcia i notatkę o wszelkich danych zachowanych na podstawie wyjątków prawnych, wyjaśniając podstawę prawną zachowania.

Wymagania dotyczące przechowywania danych zamówień

Przecięcie prawa RODO do usunięcia z wymogami prawa podatkowego dotyczącymi przechowywania to jeden z najczęściej źle rozumianych obszarów. Oto praktyczne zestawienie według głównych jurysdykcji UE.

Niemcy: Dokumenty handlowe i podatkowe muszą być przechowywane przez 10 lat (§ 147 AO, § 257 HGB). Obejmuje to faktury, dokumenty księgowe i związaną korespondencję.

Francja: Dokumenty handlowe muszą być przechowywane przez 10 lat (artykuł L123-22 Code de Commerce). Dokumenty podatkowe przez 6 lat od ostatniej operacji istotnej podatkowo.

Holandia: Dokumenty administracji podatkowej muszą być przechowywane przez 7 lat (artykuł 52 AWR).

Włochy: Kodeks cywilny wymaga 10 lat dla dokumentów handlowych (artykuł 2220 CC). Dokumenty podatkowe minimum 5 lat.

Hiszpania: Dokumenty handlowe przez 6 lat (artykuł 30 Codigo de Comercio). Dokumenty podatkowe przez 4 lata.

We wszystkich przypadkach to, co musi być zachowane, to zapis finansowy i transakcyjny, a nie profil marketingowy. Musisz zachować dane fakturowe (co zostało kupione, za ile, zapłacone podatki), ale możesz zanonimizować identyfikatory osobowe po pełnym zakończeniu relacji umownej (wszystkie dostawy zrealizowane, okresy zwrotów wygasłe, płatności rozliczone).

Praktycznym podejściem jest wdrożenie procesu dwuetapowego: natychmiastowa anonimizacja danych nieistotnych (preferencje marketingowe, historia przeglądania, subskrypcje newslettera, dane koszyka) połączona z zaplanowaną anonimizacją danych osobowych związanych z zamówieniami po wygaśnięciu prawnego okresu przechowywania.

Budowanie ścieżki audytu

RODO wymaga, abyś mógł wykazać zgodność, a nie tylko ją osiągnąć. Oznacza to prowadzenie rejestrów każdego otrzymanego wniosku o dane i sposobu jego obsługi.

Co logować

Dla każdego wniosku rejestruj: datę otrzymania wniosku, typ wniosku (dostęp, usunięcie, sprostowanie itp.), tożsamość wnioskodawcy i sposób weryfikacji tożsamości, datę przetworzenia wniosku, podjęte działania (dane wyeksportowane, dane zanonimizowane itp.), zastosowane wyjątki i ich podstawę prawną, powiadomione strony trzecie oraz datę poinformowania wnioskodawcy o wyniku.

Gdzie przechowywać log

Log wniosków powinien być przechowywany oddzielnie od danych klienta. Jeśli dane klienta zostaną usunięte, musisz zachować wpis logu pokazujący, że przetworzyłeś wniosek o usunięcie. Jednak sam log powinien zawierać minimalne dane osobowe. Rejestruj wniosek za pomocą numeru referencyjnego zamiast przechowywania pełnego imienia i nazwiska oraz e-maila klienta w logu. Referencja typu "GDPR-2026-0042" powiązana z bezpiecznie przechowywanym dokumentem oryginalnego wniosku jest lepsza niż powtarzanie danych osobowych w wielu systemach.

Moduł RODO PrestaShop prowadzi własny log operacji na danych, do którego możesz uzyskać dostęp w sekcji administracyjnej modułu. Uzupełnij go własnymi zapisami, jeśli Twój proces obejmuje ręczne kroki lub komunikację ze stronami trzecimi.

Terminy odpowiedzi i praktyczny workflow

Zasada jednego miesiąca

Masz jeden miesiąc kalendarzowy od otrzymania wniosku na odpowiedź. Oznacza to, że jeśli otrzymasz wniosek 15 marca, musisz odpowiedzieć do 15 kwietnia. Jeśli wniosek wpłynie 31 stycznia, termin to 28 lutego (lub 29 w roku przestępnym). Jeśli termin wypada w weekend lub święto, przedłuża się do następnego dnia roboczego.

Przedłużenie dla złożonych wniosków

Jeśli wniosek jest szczególnie złożony (na przykład klient ma rozległą historię zamówień z wielu lat) lub jeśli jednocześnie otrzymujesz dużą liczbę wniosków, możesz przedłużyć termin o dodatkowe dwa miesiące. Ale musisz poinformować wnioskodawcę w ciągu pierwszego miesiąca, że korzystasz z przedłużenia i wyjaśnić dlaczego.

Budowanie wewnętrznego workflow

Dla sklepów regularnie otrzymujących wnioski RODO ustal ustandaryzowany workflow. Wyznacz osobę lub zespół odpowiedzialny za obsługę wniosków. Utwórz współdzieloną skrzynkę pocztową lub system ticketów, gdzie wnioski są rejestrowane. Opracuj krok po kroku listy kontrolne dla każdego typu wniosku. Ustal wewnętrzne terminy krótsze niż termin prawny, aby umożliwić przegląd i kontrolę jakości. Prowadź okresowe szkolenia, aby pracownicy obsługi klienta rozpoznawali wnioski o dane (klienci nie zawsze używają terminologii prawnej).

Klient może powiedzieć "Chcę usunąć moje konto" lub "Wyślijcie mi wszystko, co o mnie wiecie", nigdy nie wspominając RODO ani praw osób, których dane dotyczą. Twój zespół musi rozpoznać takie wypowiedzi jako formalne wnioski i odpowiednio je przekierować.

Samoobsługa w front office

Moduł RODO PrestaShop dodaje sekcję w obszarze konta klienta, gdzie zalogowani klienci mogą przeglądać swoje przechowywane dane i samodzielnie inicjować wnioski. To podejście samoobsługowe ma kilka zalet.

Redukuje ręczne obciążenie Twojego zespołu, ponieważ klienci mogą eksportować własne dane bez angażowania pracowników. Zapewnia natychmiastową odpowiedź na wnioski o dostęp do danych, ponieważ eksport jest generowany na miejscu. I tworzy udokumentowany ślad wniosku i jego realizacji.

Jednak wnioski o usunięcie złożone przez portal samoobsługowy powinny być nadal przeglądane przed przetworzeniem. Automatyczne natychmiastowe usunięcie może spowodować problemy, jeśli klient ma otwarte zamówienia lub istnieją wymagania dotyczące przechowywania wymagające oceny. Skonfiguruj moduł tak, aby traktował samoobsługowe wnioski o usunięcie jako wnioski wymagające Twojego przeglądu i zatwierdzenia, a nie automatycznego wykonania.

Obsługa przypadków szczególnych

Zakupy gościnne

Klienci, którzy dokonali zakupu jako goście (bez zakładania konta), nadal mogą składać wnioski o dane. Ich dane są powiązane z adresem e-mail, a nie z ID konta klienta. Moduł RODO może wyszukiwać po adresie e-mail, aby znaleźć dane zamówień gości. Obowiązują te same procedury eksportu i anonimizacji.

Klienci z wieloma kontami

Niektórzy klienci zakładają wiele kont używając różnych adresów e-mail. Przy przetwarzaniu wniosku zweryfikuj, czy klient posiada dodatkowe konta. Klient powinien być w stanie podać, jakich adresów e-mail używał. Przetwarzaj każde konto osobno, chyba że możesz zweryfikować, że wszystkie konta należą do tej samej osoby.

Dane w kopiach zapasowych

RODO uznaje, że usuwanie danych z kopii zapasowych nie zawsze jest technicznie wykonalne. Jeśli Twoje kopie zapasowe bazy danych zawierają dane osobowe, które zostały usunięte z systemu produkcyjnego, udokumentuj to w swoich rejestrach. Jeśli kopia zapasowa zostanie kiedykolwiek przywrócona, musisz ponownie przetworzyć wszelkie wnioski o usunięcie, które zostały zrealizowane po wykonaniu kopii zapasowej. Prowadź log wniosków RODO oddzielnie od bazy danych, aby przetrwał przywracanie kopii zapasowej.

Pracownicy mający dostęp do danych klientów

RODO wymaga, aby dane osobowe były dostępne tylko dla osób, które potrzebują ich do realizacji swojej roli. Przejrzyj uprawnienia pracowników PrestaShop, aby upewnić się, że tylko upoważniony personel ma dostęp do danych klientów, może uruchamiać eksporty danych lub przetwarzać wnioski o usunięcie. System profili pracowniczych w PrestaShop pozwala ograniczyć dostęp do konkretnych sekcji panelu administracyjnego.

Konsekwencje niezgodności

Egzekwowanie RODO jest prowadzone przez krajowe organy ochrony danych (DPA). Kary mogą sięgać 20 milionów euro lub 4% globalnego rocznego obrotu, w zależności od tego, która kwota jest wyższa. W praktyce kary dla małych i średnich firm e-commerce były znacznie niższe, ale nie są pomijalne. Organy ochrony danych nakładały kary rzędu dziesiątek tysięcy euro za brak odpowiedzi na wnioski o dane w wymaganym terminie.

Poza karami, brak prawidłowej obsługi wniosków o dane niszczy zaufanie klientów. Klienci, którzy czują, że ich prawa do prywatności są ignorowane, przeniosą swoje zakupy gdzie indziej i mogą złożyć skargę do krajowego organu ochrony danych, co uruchamia dochodzenie pochłaniające czas i zasoby niezależnie od wyniku.

Podsumowanie i lista kontrolna

Obsługa wniosków RODO dotyczących danych w PrestaShop wymaga przygotowania, nie tylko reakcji. Zainstaluj i skonfiguruj oficjalny moduł RODO. Utwórz rejestr przetwarzania danych mapujący każde miejsce przechowywania danych osobowych, w tym moduły firm trzecich i usługi zewnętrzne. Ustal udokumentowany workflow przyjmowania, weryfikacji, przetwarzania i odpowiadania na wnioski. Poznaj lokalne wymogi przechowywania danych, abyś wiedział, co musisz zachować i na jak długo. Wdrażaj anonimizację zamiast pełnego usunięcia dla danych z prawnymi obowiązkami przechowywania. Prowadź ścieżkę audytu każdego wniosku i podjętego działania. Przeszkol zespół w rozpoznawaniu wniosków o dane nawet gdy są formułowane nieformalnie.

Zgodność z RODO to nie jednorazowa konfiguracja, ale ciągłe zobowiązanie operacyjne. Regularne przeglądy Twoich działań przetwarzania danych, integracji modułów i procedur obsługi zapewniają utrzymanie zgodności w miarę rozwoju sklepu i ewolucji wytycznych regulacyjnych.

Przeczytaj pełną odpowiedź

Dlaczego wybór serwera WWW ma znaczenie dla PrestaShop

PrestaShop to aplikacja PHP, która dynamicznie generuje strony HTML, serwuje zasoby statyczne takie jak obrazy, pliki CSS i JavaScript oraz obsługuje zapytania AJAX zarówno z front office, jak i back office. Serwer WWW znajduje się pomiędzy odwiedzającymi a aplikacją PHP, obsługując każde pojedyncze zapytanie HTTP. Jego architektura bezpośrednio wpływa na liczbę jednoczesnych odwiedzających, jaką sklep może obsłużyć, na szybkość ładowania stron oraz na ilość pamięci serwera zużywanej przez każdego odwiedzającego.

Apache i Nginx to dwa dominujące serwery WWW do hostowania PrestaShop. Apache jest domyślnym wyborem od najwcześniejszych wersji PrestaShop, a sam PrestaShop jest dostarczany z plikami .htaccess zaprojektowanymi specjalnie dla Apache. Nginx zyskał ogromną popularność w ciągu ostatniej dekady dzięki lepszej obsłudze jednoczesnych połączeń i mniejszemu zużyciu pamięci. Oba serwery mogą skutecznie obsługiwać PrestaShop, ale różnią się w aspektach, które mają znaczenie dla wydajności sklepu, złożoności konfiguracji oraz kosztów operacyjnych.

Architektura: Model procesowy vs pętla zdarzeń

Fundamentalna różnica między Apache a Nginx polega na sposobie obsługi przychodzących połączeń. Ta architektoniczna różnica jest źródłem wszystkich różnic wydajnościowych między tymi dwoma serwerami.

Model procesowy/wątkowy Apache

Apache tradycyjnie wykorzystuje model oparty na procesach za pośrednictwem modułu prefork MPM (Multi-Processing Module). W tym modelu Apache uruchamia pulę procesów roboczych, a każdy proces obsługuje jedno zapytanie naraz. Gdy przychodzi zapytanie, przypisywany jest do niego jeden proces. Ten proces odczytuje zapytanie, wykonuje kod PHP (przy użyciu mod_php), wysyła odpowiedź i dopiero wtedy staje się dostępny dla następnego zapytania.

Moduł worker MPM używa wątków zamiast oddzielnych procesów, co pozwala na więcej jednoczesnych połączeń przy mniejszym zużyciu pamięci. Moduł event MPM idzie jeszcze dalej, stosując podejście oparte na zdarzeniach dla połączeń keepalive, jednocześnie nadal używając wątków do aktywnego przetwarzania zapytań. Nowoczesne instalacje Apache zazwyczaj używają event MPM, ale podstawowy model wciąż polega na dedykowaniu wątku do każdego aktywnego zapytania.

Praktyczne konsekwencje są takie, że współbieżność Apache jest ograniczona liczbą skonfigurowanych wątków lub procesów roboczych. Jeśli skonfigurujesz 150 workerów i jednocześnie nadejdzie 151 zapytań, ostatnie zapytanie czeka w kolejce. Każdy worker zużywa pamięć (zazwyczaj 10-30 MB na proces z mod_php, mniej z PHP-FPM), więc maksymalna liczba workerów jest ograniczona dostępną pamięcią RAM.

Model sterowany zdarzeniami w Nginx

Nginx wykorzystuje asynchroniczną architekturę sterowaną zdarzeniami. Niewielka liczba procesów roboczych (zazwyczaj jeden na rdzeń procesora) obsługuje tysiące połączeń jednocześnie za pomocą pętli zdarzeń. Gdy przychodzi zapytanie, Nginx przetwarza je w sposób nieblokujący. Jeśli Nginx musi czekać na coś (odpowiedź z PHP-FPM, odczyt pliku z dysku, odpowiedź z serwera backendowego), nie blokuje workera. Zamiast tego przechodzi do obsługi innych połączeń i wraca, gdy oczekiwana operacja się zakończy.

Oznacza to, że proces roboczy Nginx obsługujący 1000 jednoczesnych połączeń zużywa mniej więcej tyle samo pamięci, co przy obsłudze 10 połączeń. Zużycie pamięci jest determinowane przez liczbę procesów roboczych (garstka), a nie liczbę połączeń (potencjalnie tysiące). Dlatego Nginx doskonale radzi sobie przy wysokiej współbieżności i jest preferowanym wyborem dla witryn o dużym ruchu.

.htaccess vs konfiguracja serwera

Jedną z najistotniejszych praktycznych różnic między Apache a Nginx jest sposób obsługi przepisywania adresów URL, kontroli dostępu i innych konfiguracji per-katalog.

Apache i .htaccess

Apache obsługuje pliki .htaccess, czyli pliki konfiguracyjne przypisane do katalogów, które mogą nadpisywać ustawienia ogólnoserwerowe. PrestaShop w dużym stopniu polega na .htaccess w zakresie przepisywania przyjaznych adresów URL, kontroli dostępu, nagłówków cachowania i nagłówków bezpieczeństwa. Gdy włączysz przyjazne adresy URL w PrestaShop, generuje on plik .htaccess z regułami mod_rewrite, które tłumaczą czyste adresy URL jak /shoes/running-shoe na wewnętrzny adres URL dispatchera.

Zaletą .htaccess jest wygoda. Nie potrzebujesz dostępu root, aby modyfikować zachowanie serwera WWW, a zmiany zaczynają obowiązywać natychmiast bez restartowania serwera. PrestaShop może zapisywać własny plik .htaccess z poziomu back office, co oznacza, że funkcje takie jak przyjazne adresy URL, konfiguracja serwera mediów i pewne ustawienia bezpieczeństwa działają od razu po instalacji.

Wadą jest wydajność. Każde zapytanie powoduje, że Apache szuka i parsuje pliki .htaccess w każdym katalogu od katalogu głównego dokumentu do katalogu żądanego pliku. Przy typowym zapytaniu PrestaShop, Apache może sprawdzać .htaccess w /, /var, /var/www, /var/www/html i dalszych katalogach. To dodaje operacje dyskowe I/O i czas przetwarzania do każdego zapytania. Dla witryny obsługującej setki zapytań na sekundę, ten narzut jest mierzalny.

Jeśli masz dostęp root do konfiguracji Apache, możesz przenieść wszystkie dyrektywy .htaccess do konfiguracji VirtualHost i wyłączyć przetwarzanie .htaccess za pomocą AllowOverride None. To eliminuje narzut per-zapytanie przy zachowaniu tej samej funkcjonalności. Jednak wtedy zmiany wymagają przeładowania Apache.

Konfiguracja Nginx

Nginx nie obsługuje plików .htaccess. Cała konfiguracja znajduje się w plikach konfiguracyjnych bloków server, zazwyczaj w /etc/nginx/sites-available/ lub /etc/nginx/conf.d/. Każda reguła przepisywania URL, dyrektywa kontroli dostępu i nagłówek cachowania muszą być zdefiniowane w tych plikach.

Oznacza to, że przy konfiguracji PrestaShop na Nginx musisz ręcznie przetłumaczyć reguły .htaccess PrestaShop na składnię konfiguracji Nginx. Reguły przepisywania są zasadniczo różne między tymi dwoma serwerami. Apache używa RewriteRule z wzorcami regex i flagami takimi jak [L,R=301], podczas gdy Nginx używa bloków location z dyrektywami try_files, rewrite i return.

Zaletą scentralizowanej konfiguracji jest wydajność (brak skanowania plików per-zapytanie) i przejrzystość (wszystkie reguły w jednym miejscu). Wadą jest to, że PrestaShop nie może wygenerować konfiguracji Nginx za Ciebie. Musisz ją napisać i utrzymywać samodzielnie, a każda zmiana wymaga uruchomienia nginx -t w celu przetestowania składni i systemctl reload nginx w celu jej zastosowania.

Integracja PHP

Oba serwery WWW muszą wykonywać kod PHP, aby generować strony PrestaShop. Metoda integracji PHP wpływa na wydajność, stabilność i zarządzanie zasobami.

Apache z mod_php

Tradycyjne podejście to Apache z mod_php, gdzie PHP działa jako moduł wewnątrz każdego procesu Apache. Jest to proste w konfiguracji i nie ma narzutu komunikacji międzyprocesowej, ponieważ PHP wykonuje się w tym samym procesie, który obsługuje zapytanie HTTP. Jednak każdy proces roboczy Apache niesie w pamięci pełne środowisko uruchomieniowe PHP, nawet gdy serwuje pliki statyczne jak obrazy czy CSS. To marnuje pamięć, ponieważ większość zapytań do sklepu PrestaShop dotyczy zasobów statycznych, a nie stron PHP.

Apache lub Nginx z PHP-FPM

PHP-FPM (FastCGI Process Manager) uruchamia PHP jako oddzielną pulę procesów. Serwer WWW komunikuje się z PHP-FPM przez gniazdo Unix lub połączenie TCP za pomocą protokołu FastCGI. Gdy zapytanie wymaga przetworzenia PHP, serwer WWW przekazuje je do PHP-FPM. Gdy przetwarzanie PHP jest zakończone, PHP-FPM odsyła wynik z powrotem do serwera WWW, który wysyła go do klienta.

Z PHP-FPM procesy serwera WWW obsługujące pliki statyczne nie niosą środowiska uruchomieniowego PHP, co oszczędza znaczną ilość pamięci. PHP-FPM oferuje również własne zarządzanie procesami z funkcjami takimi jak dynamiczne skalowanie puli, slow log (logowanie zapytań trwających dłużej niż próg) oraz możliwość jednoczesnego uruchamiania wielu wersji PHP dla różnych witryn.

Nginx używa wyłącznie PHP-FPM, ponieważ jego architektura sterowana zdarzeniami jest niekompatybilna z osadzaniem PHP. Apache może używać PHP-FPM przez mod_proxy_fcgi. We współczesnych wdrożeniach PHP-FPM jest zalecanym podejściem dla obu serwerów.

Konfiguracja PHP-FPM dla PrestaShop

Niezależnie od wybranego serwera WWW, konfiguracja PHP-FPM znacząco wpływa na wydajność PrestaShop. Kluczowe ustawienia to:

pm = dynamic jest zazwyczaj najlepszym trybem menedżera procesów. Uruchamia bazową liczbę workerów i tworzy więcej pod obciążeniem, do skonfigurowanego maksimum. To balansuje zużycie pamięci i responsywność.

pm.max_children określa maksymalną liczbę procesów PHP. Każde zapytanie PrestaShop zazwyczaj zużywa 30-80 MB pamięci, więc podziel dostępną pamięć RAM (minus to, co potrzebują serwer WWW i system operacyjny) przez 80, aby uzyskać konserwatywne maksimum. Dla serwera z 4 GB użytecznej pamięci RAM, 50 procesów potomnych jest rozsądnym punktem wyjścia.

pm.max_requests = 500 recykluje każdego workera po 500 zapytaniach, zapobiegając akumulacji wycieków pamięci. Moduły PrestaShop czasami mają drobne wycieki pamięci, a to ustawienie zapobiega ich narastaniu do problemowego poziomu.

Serwowanie plików statycznych

Sklep PrestaShop serwuje dużą liczbę plików statycznych: obrazy produktów, arkusze stylów CSS, pliki JavaScript, czcionki i przesłane media. Wydajność serwowania plików statycznych bezpośrednio wpływa na czas ładowania stron i zużycie zasobów serwera.

Wydajność serwowania plików statycznych przez Apache

Apache serwuje pliki statyczne przez swoje procesy robocze. Każde zapytanie o plik statyczny zajmuje workera na czas trwania transferu. Dla małych plików (CSS, JS, małe obrazy) jest to szybkie. Dla dużych plików lub wolnych połączeń klienckich worker jest zajęty dłużej. Z załadowanym mod_php, każdy worker niesie niepotrzebny narzut pamięciowy PHP nawet dla zapytań statycznych.

Apache obsługuje sendfile, co pozwala jądru systemu na bezpośredni transfer plików z dysku do gniazda sieciowego bez kopiowania danych przez przestrzeń użytkownika. Jest to domyślnie włączone i pomaga przy transferze dużych plików. Apache obsługuje również negocjację treści, zakresy bajtów i zapytania warunkowe (If-Modified-Since) od razu po instalacji.

Wydajność serwowania plików statycznych przez Nginx

Nginx doskonale radzi sobie z serwowaniem plików statycznych, ponieważ jego model sterowany zdarzeniami może obsługiwać tysiące jednoczesnych transferów plików bez proporcjonalnego zwiększania zużycia zasobów. Pojedynczy proces roboczy Nginx może serwować setki jednoczesnych zapytań o pliki statyczne. W połączeniu z efektywnym wykorzystaniem wywołania systemowego sendfile i wbudowaną obsługą cache otwartych plików (cachowanie deskryptorów plików dla często odwiedzanych plików), serwowanie plików statycznych jest niezwykle szybkie.

Dla sklepów PrestaShop z wieloma obrazami produktów (czyli większości sklepów), przewaga Nginx w serwowaniu plików statycznych jest znacząca. Strony produktów z 5-10 obrazami, plus pliki CSS, JavaScript i czcionek, generują 20-30 zapytań o pliki statyczne na jedno załadowanie strony. Przy dużym ruchu Nginx obsługuje je przy znacznie mniejszym zużyciu zasobów niż Apache.

Terminacja SSL/TLS

Każdy sklep PrestaShop powinien działać na HTTPS, a serwer WWW obsługuje szyfrowanie i deszyfrowanie SSL/TLS (terminację). Oba serwery dobrze obsługują nowoczesny TLS, ale istnieją różnice w konfiguracji i wydajności.

Apache konfiguruje SSL przez mod_ssl, z dyrektywami takimi jak SSLEngine on, SSLCertificateFile i SSLProtocol w bloku VirtualHost. Zszywanie OCSP, cachowanie sesji i wybór zestawu szyfrów są w pełni konfigurowalne.

Nginx konfiguruje SSL w bloku server z dyrektywami takimi jak ssl_certificate, ssl_protocols i ssl_ciphers. Nginx również obsługuje zszywanie OCSP i cachowanie sesji, a jego konfiguracja jest zazwyczaj bardziej zwięzła.

Pod względem wydajności, handshake TLS jest wymagający obliczeniowo ze względu na asymetryczne szyfrowanie. Zdolność Nginx do obsługi wielu jednoczesnych połączeń przy niewielkiej liczbie procesów roboczych oznacza, że może obsłużyć więcej handshake'ów TLS na sekundę przy mniejszym zużyciu pamięci. Dla sklepów, które otrzymują duże fale nowych odwiedzających (podczas wyprzedaży na przykład), przewaga wydajnościowa Nginx w zakresie TLS może zapobiec kolejkowaniu połączeń.

Reverse proxy i load balancing

Dla sklepów PrestaShop o dużym ruchu, architektura reverse proxy rozdziela odpowiedzialności i poprawia skalowalność. Najczęstsza konfiguracja wykorzystuje Nginx jako reverse proxy przed Apache lub inną instancją Nginx z PHP-FPM.

Nginx jako reverse proxy dla Apache

Ta hybrydowa konfiguracja łączy zalety obu serwerów. Nginx stoi z przodu, obsługując wszystkie przychodzące połączenia, serwując pliki statyczne bezpośrednio, zarządzając terminacją SSL i przekazując tylko zapytania PHP do Apache. Apache obsługuje przetwarzanie PHP, a ponieważ otrzymuje tylko zapytania PHP (nie zapytania o pliki statyczne), potrzebuje znacznie mniejszej liczby procesów roboczych.

Ta architektura daje efektywność obsługi połączeń Nginx i wydajność serwowania plików statycznych przy jednoczesnym zachowaniu obsługi .htaccess Apache dla generowanych reguł przepisywania PrestaShop. Jest to powszechna ścieżka migracji dla sklepów, które chcą wydajności Nginx bez przepisywania całej konfiguracji Apache.

Konfiguracja proxy Nginx używa dyrektywy proxy_pass do przekazywania zapytań do Apache, który zazwyczaj działa na niestandardowym porcie jak 8080. Pliki statyczne są serwowane bezpośrednio przez Nginx za pomocą bloku location dopasowującego rozszerzenia plików takie jak .jpg, .css, .js i .png.

Pełna konfiguracja Nginx

Dla maksymalnej wydajności Nginx serwuje wszystko: pliki statyczne i zapytania PHP (przez PHP-FPM). W stosie nie ma Apache. To eliminuje komunikację międzyprocesową między Nginx a Apache i usuwa narzut pamięciowy uruchamiania dwóch serwerów WWW. Wymaga jednak ręcznego tworzenia i utrzymywania konfiguracji Nginx dla przepisywania adresów URL PrestaShop, co wymaga więcej początkowej pracy.

Zalecana konfiguracja Nginx dla PrestaShop

Produkcyjna konfiguracja Nginx dla PrestaShop musi obsługiwać przyjazne adresy URL, dostęp do panelu administracyjnego, cachowanie plików statycznych, komunikację z PHP-FPM i bezpieczeństwo. Kluczowe elementy obejmują blok server nasłuchujący na portach 80 i 443, blok konfiguracji SSL z certyfikatami, dyrektywę root wskazującą na instalację PrestaShop oraz kilka bloków location.

Główny blok location używa try_files $uri $uri/ /index.php?$args do obsługi przyjaznych adresów URL PrestaShop. Najpierw próbuje obsłużyć zapytanie jako plik statyczny, potem jako katalog, a na końcu przekazuje je do dispatchera PrestaShop przez index.php.

Blok location dopasowujący ~ \.php$ przekazuje zapytania PHP do PHP-FPM za pomocą fastcgi_pass. Zawiera standardowe parametry FastCGI i ustawia SCRIPT_FILENAME na prawidłową ścieżkę.

Blok location dla zasobów statycznych ustawia długie nagłówki wygaśnięcia cache i wyłącza logowanie dostępu w celu zmniejszenia I/O. Wzorce dopasowujące takie jak \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ przechwytują typowe typy plików statycznych.

Bloki location związane z bezpieczeństwem blokują dostęp do wrażliwych plików i katalogów: .htaccess, .git, config/ (oprócz config/xml/, który jest potrzebny PrestaShop), vendor/, app/config/ i innych katalogów, które nigdy nie powinny być dostępne przez WWW.

Zalecana konfiguracja Apache dla PrestaShop

Apache z event MPM i PHP-FPM zapewnia najlepszy hosting PrestaShop oparty na Apache. Konfiguracja VirtualHost powinna włączać moduły rewrite, headers, expires, deflate i proxy_fcgi.

DocumentRoot wskazuje na instalację PrestaShop. AllowOverride All włącza przetwarzanie .htaccess, które jest potrzebne, chyba że przeniesiesz wszystkie reguły przepisywania PrestaShop do konfiguracji VirtualHost.

Integracja PHP-FPM używa SetHandler lub ProxyPassMatch do przekazywania zapytań .php do gniazda PHP-FPM. Podejście SetHandler z proxy:unix:/run/php/php-fpm.sock|fcgi://localhost jest prostsze i zalecane dla większości konfiguracji.

Włącz kompresję gzip za pomocą mod_deflate dla typów treści tekstowych: HTML, CSS, JavaScript, JSON, XML i SVG. Włącz cachowanie przeglądarki za pomocą mod_expires, ustawiając długie czasy wygaśnięcia dla zasobów statycznych i krótsze dla HTML.

Benchmarki wydajności i różnice w rzeczywistych warunkach

Surowe wyniki benchmarków różnią się ogromnie w zależności od sprzętu, konfiguracji, wersji PHP i wersji PrestaShop. Zamiast prezentować konkretne liczby, które byłyby mylące poza kontekstem, oto wzorce, które konsekwentnie pojawiają się w benchmarkach hostingu PrestaShop.

Dla serwowania plików statycznych, Nginx jest konsekwentnie 2-3 razy szybszy niż Apache i zużywa znacznie mniej pamięci. Ta różnica powiększa się wraz ze wzrostem współbieżności. Przy 100 jednoczesnych połączeniach różnica może wynosić 20%. Przy 1000 jednoczesnych połączeniach Nginx może zużywać 10 razy mniej pamięci.

Dla przetwarzania zapytań PHP, serwer WWW nie jest wąskim gardłem. Czas przetwarzania PHP-FPM dominuje w cyklu życia zapytania, a oba serwery WWW dodają pomijalny narzut w porównaniu z czasem, jaki PHP spędza na wykonywaniu kodu PrestaShop, odpytywaniu bazy danych i renderowaniu szablonów. Różnica w obsłudze zapytań PHP między Apache z PHP-FPM a Nginx z PHP-FPM wynosi zazwyczaj poniżej 5%, co mieści się w marginesie błędu pomiarowego dla większości sklepów.

Dla obciążeń mieszanych (realistyczny scenariusz), przewaga Nginx wynika z efektywnej obsługi plików statycznych obok zapytań PHP. Załadowanie strony generuje jedno zapytanie PHP i 20-30 zapytań o pliki statyczne. Nginx obsługuje te 20-30 zapytań statycznych z minimalnym zużyciem zasobów, podczas gdy Apache przydziela wątek roboczy do każdego z nich. Przy dużym ruchu ta różnica w zużyciu zasobów oznacza, że Nginx może utrzymać wyższą współbieżność zanim wydajność zacznie spadać.

Praktyczny wniosek jest taki, że dla sklepów z mniej niż 50 jednoczesnych odwiedzających, wybór serwera WWW nie robi prawie żadnej zauważalnej różnicy. Dla sklepów zbliżających się do lub przekraczających 100 jednoczesnych odwiedzających, architektoniczne zalety Nginx stają się istotne.

Przewodnik migracji: Apache do Nginx

Migracja istniejącego sklepu PrestaShop z Apache na Nginx obejmuje tłumaczenie konfiguracji, dokładne testowanie i przełączenie.

Krok 1: Przetłumacz reguły .htaccess

Otwórz plik .htaccess PrestaShop i zidentyfikuj wszystkie aktywne reguły przepisywania. Kluczowa sekcja to przepisywanie przyjaznych adresów URL, które zazwyczaj zaczyna się od RewriteCond %{REQUEST_FILENAME} !-f i RewriteRule .* - [E=REWRITEBASE:/]. Te reguły tłumaczą się na dyrektywę try_files Nginx wspomnianą w sekcji konfiguracji powyżej.

Przepisywania serwera mediów, obsługa prefiksu języka i wszelkie niestandardowe przekierowania również wymagają tłumaczenia. Każda para RewriteRule i RewriteCond Apache musi zostać skonwertowana na odpowiednią dyrektywę location, rewrite lub return Nginx.

Krok 2: Skonfiguruj Nginx obok Apache

Zainstaluj Nginx i skonfiguruj go do nasłuchiwania na innym porcie (np. 8080), podczas gdy Apache nadal działa na porcie 80. To pozwala przetestować konfigurację Nginx bez wpływu na działającą witrynę. Skieruj Nginx na ten sam katalog główny dokumentów co Apache, aby serwował te same pliki.

Krok 3: Przetestuj wszystko

Uzyskaj dostęp do witryny przez port Nginx i przetestuj każdy aspekt: stronę główną, strony kategorii, strony produktów, koszyk, proces zamówienia, panel administracyjny, przyjazne adresy URL, ładowanie obrazów i wielojęzyczne routowanie URL. Zwróć szczególną uwagę na wzorce URL zawierające znaki specjalne lub parametry zapytania.

Krok 4: Przełącz się

Po zakończeniu testów zatrzymaj Apache i przekonfiguruj Nginx do nasłuchiwania na portach 80 i 443. Przeładuj Nginx i sprawdź, czy witryna produkcyjna działa poprawnie. Zachowaj konfigurację Apache przez kilka dni na wypadek konieczności cofnięcia zmian.

Typowe problemy przy migracji

Najczęstszym problemem są brakujące reguły przepisywania dla wielojęzycznego routowania URL PrestaShop. Jeśli Twój sklep używa wielu języków z kodami języka w adresie URL (jak /en/, /de/, /fr/), upewnij się, że konfiguracja Nginx prawidłowo obsługuje te prefiksy.

Innym częstym problemem są limity rozmiaru przesyłanych plików. Apache używa LimitRequestBody, podczas gdy Nginx używa client_max_body_size. Jeśli importujesz produkty z dużymi obrazami, ustaw client_max_body_size na co najmniej 20M.

Zapytania AJAX panelu administracyjnego, które polegają na przepisywaniu .htaccess, mogą przestać działać, jeśli odpowiednie reguły Nginx nie zostały dodane. Przetestuj panel administracyjny dokładnie, w tym edycję produktów, zarządzanie zamówieniami i konfigurację modułów.

Który serwer powinieneś wybrać

Wybierz Apache, jeśli korzystasz z hostingu współdzielonego, na którym nie kontrolujesz serwera WWW, jeśli w dużym stopniu polegasz na .htaccess w konfiguracji (reguły generowane przez moduły, wtyczki bezpieczeństwa) lub jeśli nie czujesz się komfortowo z pisaniem i utrzymywaniem plików konfiguracyjnych Nginx. Apache z event MPM i PHP-FPM to solidna, dobrze wspierana konfiguracja dla sklepów PrestaShop o umiarkowanym ruchu.

Wybierz Nginx, jeśli masz dostęp root do serwera, Twój sklep obsługuje znaczny ruch (setki lub tysiące jednoczesnych odwiedzających), chcesz jak najniższego zużycia zasobów dla danego poziomu ruchu lub konfigurujesz nowy serwer i preferujesz długoterminowe korzyści architektury Nginx. Początkowy wysiłek konfiguracyjny jest jednorazowym kosztem, który zwraca się w postaci wydajności i efektywności zasobów.

Wybierz podejście z Nginx jako reverse proxy przed Apache, jeśli chcesz wydajności Nginx dla plików statycznych i obsługi połączeń, ale potrzebujesz obsługi .htaccess Apache dla kompatybilności z modułami PrestaShop, które generują lub zależą od reguł .htaccess.

Dla większości nowych instalacji PrestaShop na VPS lub serwerze dedykowanym, Nginx z PHP-FPM jest zalecanym wyborem. Konfiguracja jest dobrze udokumentowana, zalety wydajnościowe są realne, a operacyjna prostota jednego stosu serwera WWW zmniejsza koszty utrzymania. Dla istniejących sklepów na Apache, które działają zadowalająco, migracja na Nginx jest wartościową optymalizacją, ale nie pilną koniecznością, chyba że napotykasz limity wydajności.

Przeczytaj pełną odpowiedź

Jak wewnętrznie działa wyszukiwanie w PrestaShop

PrestaShop zawiera wbudowaną wyszukiwarkę produktów, która działa na indeksie pełnotekstowym przechowywanym bezpośrednio w bazie danych MySQL. W przeciwieństwie do zewnętrznych usług wyszukiwania, ten indeks znajduje się obok danych produktów w tej samej bazie danych, co oznacza, że jest szybki w odpytywaniu, ale wymaga jawnego utrzymania, aby pozostawał aktualny. Zrozumienie sposobu działania tego systemu wyszukiwania jest pierwszym krokiem do diagnozowania i naprawiania problemów z wyszukiwaniem.

Gdy klient wpisuje zapytanie w pasku wyszukiwania w Twoim sklepie, PrestaShop nie skanuje w czasie rzeczywistym każdej nazwy produktu i opisu. Zamiast tego wyszukuje terminy zapytania w wcześniej zbudowanym indeksie, który mapuje poszczególne słowa na produkty. Indeks ten jest konstruowany przez rozbicie pól tekstowych produktów na poszczególne słowa (tokenizacja), ich normalizację (zamiana na małe litery, usuwanie akcentów) i przechowywanie relacji między każdym słowem a produktami, w których się ono pojawia, wraz z wagą trafności.

To podejście jest zasadniczo takie samo jak w wyszukiwarkach internetowych typu Google, tyle że na znacznie mniejszą skalę. Kompromis polega na tym, że indeks musi być odbudowany za każdym razem, gdy dane produktów zmienią się w sposób, którego automatyczne indeksowanie nie wychwytuje, co jest główną przyczyną większości problemów z wyszukiwaniem w PrestaShop.

Tabele bazy danych wyszukiwania

Indeks wyszukiwania PrestaShop jest rozłożony na kilka tabel bazy danych, z których każda pełni określoną funkcję w procesie wyszukiwania.

ps_search_word

Ta tabela przechowuje każde unikalne słowo wyodrębnione z danych produktów, wraz z językiem, do którego należy. Każde słowo otrzymuje id_word, które służy jako klucz referencyjny. Tabela jest świadoma języków, co oznacza, że słowo "shoe" w katalogu angielskim i "Schuh" w katalogu niemieckim to oddzielne wpisy, każdy powiązany z odpowiednim identyfikatorem języka.

Gdy zajrzysz do tej tabeli, zobaczysz tysiące lub dziesiątki tysięcy wierszy, w zależności od rozmiaru katalogu i liczby języków. Każde odrębne słowo z każdego indeksowanego pola produktu jest tu reprezentowane.

ps_search_index

To jest główna tabela mapowania. Każdy wiersz łączy produkt (id_product) ze słowem (id_word) z wartością wagi. Waga określa, jak istotne jest dane słowo dla danego produktu. Słowo pojawiające się w nazwie produktu ma większą wagę niż to samo słowo pojawiające się w opisie, a wartości wag są konfigurowalne w back office.

Gdy klient wyszukuje "niebieski skórzany portfel", PrestaShop wyszukuje każde słowo w ps_search_word, znajduje odpowiednie wartości id_word, a następnie odpytuje ps_search_index w poszukiwaniu produktów pasujących do tych identyfikatorów słów. Produkty są rankingowane według sumy ich wag dla pasujących słów, przy czym produkty z wyższą łączną wagą pojawiają się na początku wyników.

ps_search_engine

Ta tabela przechowuje wzorce wyszukiwarek referrerów używane do śledzenia, które wyszukiwarki wysyłają ruch do Twojego sklepu. Nie jest bezpośrednio związana z wewnętrzną funkcjonalnością wyszukiwania, ale jest często mylona z nią ze względu na podobne nazewnictwo.

ps_alias

Tabela aliasów przechowuje aliasy wyszukiwanych terminów, czyli alternatywne pisownie lub synonimy, które powinny być mapowane na kanoniczny termin wyszukiwania. Na przykład możesz skonfigurować "sneakers" jako alias dla "adidasy", aby klienci wyszukujący którykolwiek z tych terminów otrzymywali te same wyniki. Aliasy są konfigurowane w back office w sekcji Parametry sklepu > Wyszukiwanie > Szukaj > Aliasy.

Kiedy i dlaczego reindeksacja jest konieczna

PrestaShop posiada funkcję automatycznego indeksowania, która aktualizuje indeks wyszukiwania za każdym razem, gdy produkt jest zapisywany przez back office. Gdy edytujesz produkt i klikniesz Zapisz, PrestaShop reindeksuje ten konkretny produkt, aktualizując jego wpisy w ps_search_word i ps_search_index. Działa to dobrze przy codziennym zarządzaniu produktami.

Jednak automatyczne indeksowanie nie pokrywa każdego scenariusza. Istnieje kilka typowych sytuacji, w których konieczna jest pełna reindeksacja.

Masowe importy produktów

Gdy importujesz produkty przez CSV, proces importu może nie wyzwalać hooków indeksowania wyszukiwania dla każdego produktu. Jest to szczególnie częste przy dużych importach, gdzie optymalizacje wydajnościowe pomijają nieistotne kroki przetwarzania. Po masowym imporcie nowe produkty mogą istnieć w katalogu, ale być całkowicie niewidoczne w wyszukiwaniu sklepowym.

Bezpośrednie modyfikacje bazy danych

Jeśli Ty lub moduł modyfikujecie dane produktów bezpośrednio w bazie danych (omijając model obiektowy PrestaShop), indeks wyszukiwania nie zostanie zaktualizowany. Dotyczy to aktualizacji SQL nazw produktów, opisów lub innych indeksowanych pól. Każda migracja bazy danych, czyszczenie danych lub zewnętrzne narzędzie synchronizacji, które zapisuje bezpośrednio do ps_product_lang, pozostawi indeks wyszukiwania nieaktualnym.

Zmiany języków

Dodanie nowego języka do sklepu wymaga pełnej reindeksacji, ponieważ indeks wyszukiwania jest specyficzny dla języka. Istniejące produkty potrzebują tokenizacji i dodania do indeksu treści w nowym języku. Podobnie, jeśli edytujesz treść produktu w konkretnym języku (zwłaszcza przez operacje masowe), reindeksacja zapewnia, że zmiany są odzwierciedlone w wyszukiwaniu.

Zmiany konfiguracji wag wyszukiwania

Gdy zmieniasz wartości wag przypisane do różnych pól produktu (więcej na ten temat poniżej), istniejące wpisy indeksu zachowują swoje stare wagi. Reindeksacja przelicza wszystkie wagi przy użyciu nowej konfiguracji.

Instalacje lub aktualizacje modułów

Niektóre moduły modyfikują struktury danych produktów lub dodają wyszukiwalne pola. Po zainstalowaniu lub zaktualizowaniu takich modułów reindeksacja zapewnia, że nowe lub zmodyfikowane dane są uwzględnione w indeksie wyszukiwania.

Uszkodzony indeks

Awarie bazy danych, nieudane migracje lub przerwane operacje indeksowania mogą pozostawić indeks wyszukiwania w niespójnym stanie. Symptomy obejmują produkty, które powinny pojawiać się w wynikach wyszukiwania, ale się nie pojawiają, produkty pojawiające się dla zupełnie błędnych terminów wyszukiwania lub wyszukiwanie zwracające brak wyników w ogóle. Pełna reindeksacja odbudowuje indeks od podstaw, rozwiązując te niespójności.

Jak reindeksować produkty

Metoda z poziomu back office

Przejdź do Parametry sklepu > Wyszukiwanie w back office PrestaShop. Na górze strony znajdziesz sekcję "Indeksowanie" z opcjami odbudowy indeksu wyszukiwania. Zazwyczaj dostępne są dwie opcje: dodanie do indeksu produktów, które jeszcze nie zostały zaindeksowane (przyrostowa) lub odbudowa całego indeksu od podstaw (pełna reindeksacja).

Dla większości scenariuszy rozwiązywania problemów wybierz pełną odbudowę. Opcja przyrostowa dodaje tylko brakujące produkty i nie aktualizuje istniejących wpisów, które mogą zawierać nieaktualne dane.

Metoda z poziomu back office działa dobrze dla małych i średnich katalogów (do kilku tysięcy produktów). Dla większych katalogów może wystąpić timeout z powodu limitu czasu wykonania PHP, co czyni metodę CLI konieczną.

Polecenie CLI do reindeksacji

Dla dużych katalogów lub zautomatyzowanych procesów użyj wiersza poleceń do uruchomienia reindeksacji. W PrestaShop 1.7 i nowszych polecenie to:

php bin/console prestashop:search-index:rebuild

Dla PrestaShop 1.6 wywołujesz bezpośrednio skrypt indeksowania. Dokładna ścieżka zależy od instalacji, ale logika indeksowania znajduje się w klasie Search.

Metoda CLI nie ma tych samych ograniczeń timeoutu co interfejs webowy. Dla bardzo dużych katalogów (dziesiątki tysięcy produktów w wielu językach) reindeksacja może trwać kilka minut. Postęp można monitorować przez wyświetlane informacje.

Jeśli uruchamiasz PrestaShop w Dockerze, wykonaj polecenie wewnątrz kontekstu kontenera, w którym dostępny jest PHP i baza kodu PrestaShop. Upewnij się, że uruchamiasz je jako użytkownik serwera WWW, aby uniknąć problemów z uprawnieniami plików cache, które mogą być generowane podczas procesu.

Automatyzacja reindeksacji

Jeśli Twój sklep korzysta z automatycznych importów produktów lub zewnętrznej synchronizacji danych, zaplanuj okresową reindeksację jako zadanie cron. Nocna reindeksacja zapewnia, że produkty dodane lub zmodyfikowane przez zautomatyzowane procesy będą wyszukiwalne następnego dnia. Wpis cron wywołałby to samo polecenie CLI według harmonogramu.

Pamiętaj, że reindeksacja krótkotrwale blokuje tabele wyszukiwania podczas odbudowy. W przypadku intensywnie odwiedzanego sklepu zaplanuj reindeksację na godziny o niskim ruchu, aby uniknąć wpływu na dostępność wyszukiwania dla aktywnych klientów.

Konfiguracja wag: Kontrola trafności wyszukiwania

PrestaShop pozwala skonfigurować, jaką wagę mają różne pola produktu w wynikach wyszukiwania. Jest to jedna z najpotężniejszych i najbardziej niedocenianych funkcji wbudowanego systemu wyszukiwania.

Dostępne pola wag

Konfiguracja wag znajduje się w Parametry sklepu > Wyszukiwanie. Możesz przypisać wagę (zazwyczaj od 1 do 10, choć wyższe wartości również działają) do każdego z tych pól produktu:

Nazwa produktu: Powinna zazwyczaj mieć najwyższą wagę. Gdy klient szuka produktu po nazwie, produkt o tej dokładnej nazwie powinien pojawić się na pierwszym miejscu.

Referencja: Kody referencyjne produktów są często używane przez klientów B2B, którzy znają dokładny SKU, którego potrzebują. Umiarkowana waga zapewnia, że wyszukiwanie po referencji działa dobrze, nie przytłaczając wyszukiwania po nazwie.

Krótki opis: Krótki opis często zawiera kluczowe zalety sprzedażowe i cechy produktu. Odpowiednia jest umiarkowana waga.

Opis: Pełny opis zawiera najwięcej tekstu, a zatem najwięcej potencjalnych dopasowań słów kluczowych. Jednak ponieważ zawiera tak dużo tekstu, wysoka waga może powodować nieistotne dopasowania, gdy wyszukiwany termin pojawia się przypadkowo w długim opisie. Zalecana jest niższa waga w porównaniu z nazwą produktu.

Kategoria: Uwzględnienie nazw kategorii w wyszukiwaniu pozwala klientom znajdować produkty po terminach kategorii, nawet gdy te terminy nie pojawiają się w tekście samego produktu.

Marka (producent): Klienci często szukają po nazwie marki. Umiarkowana do wysokiej waga zapewnia, że wyszukiwania po marce zwracają trafne wyniki.

Tagi: Tagi to jawnie przypisane terminy wyszukiwania dla produktów. Wysoka waga tagów daje bezpośrednią kontrolę nad tym, które produkty pojawiają się dla konkretnych zapytań wyszukiwania.

Atrybuty: Wartości atrybutów produktu (rozmiar, kolor, materiał) mogą być uwzględnione w indeksie wyszukiwania. To pozwala na wyszukiwania jak "czerwony XL", które zwracają produkty z takimi kombinacjami atrybutów.

Cechy: Wartości cech produktu (waga, wymiary, rodzaj materiału) również mogą być indeksowane.

Strategia wagowa

Rozsądna konfiguracja początkowa mogłaby być następująca: nazwa produktu na 6, referencja na 4, krótki opis na 3, opis na 1, kategoria na 2, producent na 3, tagi na 4, atrybuty na 2, cechy na 2. Jednak optymalne wagi zależą wyłącznie od Twojego katalogu i zachowań wyszukiwania Twoich klientów.

Jeśli Twoi klienci często szukają po SKU lub numerze referencyjnym, zwiększ wagę referencji. Jeśli wyszukiwania po marce są ważne, zwiększ wagę producenta. Jeśli stwierdzisz, że długie opisy powodują nieistotne wyniki o wysokim rankingu, zmniejsz wagę opisu lub ustaw ją na zero, aby całkowicie wykluczyć opisy z indeksu.

Po zmianie wag zawsze wykonaj pełną reindeksację, aby nowe wartości zaczęły obowiązywać dla wszystkich produktów.

Typowe problemy z wyszukiwaniem i ich rozwiązania

Produkty nie pojawiające się w wynikach wyszukiwania

To najczęstsza skarga dotycząca wyszukiwania. Produkt istnieje w katalogu, ale wyszukiwanie go po nazwie nie zwraca wyników. Przyczyny obejmują: produkt został dodany przez import, który nie wyzwolił indeksowania, produkt jest wyłączony lub niedostępny, a wyszukiwanie jest skonfigurowane do wykluczania takich produktów, lub indeks wyszukiwania jest uszkodzony.

Rozwiązanie: Najpierw zweryfikuj, czy produkt jest aktywny i widoczny. Następnie uruchom pełną reindeksację. Jeśli produkt nadal się nie pojawia, sprawdź, czy nazwa produktu zawiera znaki specjalne, które mogą być usuwane podczas tokenizacji, i sprawdź, czy ustawienie minimalnej długości słowa (w konfiguracji wyszukiwania) nie wyklucza krótkich słów z nazwy produktu.

Nieprawidłowe produkty na pierwszych pozycjach

Gdy wyszukanie "niebieski widget" zwraca produkt o nazwie "uchwyt na widgety" przed faktycznym produktem "niebieski widget", zazwyczaj jest to problem konfiguracji wag. Produkt, który ma wyższy ranking, zgromadził więcej łącznej wagi we wszystkich indeksowanych polach. Być może "widget" pojawia się wielokrotnie w opisie produktu uchwytu, a przy wysokiej wadze opisu te wystąpienia przeważają nad pojedynczym dopasowaniem w nazwie produktu.

Rozwiązanie: Dostosuj wagi pól, aby priorytetyzować nazwę produktu. Ustaw wagę nazwy produktu znacząco wyższą niż wagę opisu. Reindeksuj po wprowadzeniu zmian.

Wyszukiwanie zwraca zbyt wiele nieistotnych wyników

Dzieje się tak, gdy waga opisu jest zbyt wysoka lub gdy popularne słowa pojawiają się w wielu opisach produktów. Wyszukanie "premium" zwraca każdy produkt, którego opis zawiera słowo "premium", nawet gdy nie jest to definiująca cecha tych produktów.

Rozwiązanie: Zmniejsz wagę opisu lub użyj funkcji czarnej listy słów, aby wykluczyć popularne, nierozróżniające słowa z indeksu. Czarna lista jest konfigurowana w Parametry sklepu > Wyszukiwanie i pozwala określić słowa, które powinny być ignorowane podczas indeksowania.

Wyszukiwanie nie znajduje częściowych dopasowań

Wbudowane wyszukiwanie PrestaShop nie obsługuje prawdziwego dopasowania rozmytego. Jeśli klient szuka "but", nie znajdzie produktów zawierających tylko słowo "buty", chyba że stemming lub aliasy obsłużą tę odmianę. Jest to fundamentalne ograniczenie podejścia opartego na indeksie słów.

Rozwiązanie: Użyj funkcji aliasów, aby mapować popularne odmiany ("but" na "buty", "TV" na "telewizor"). Dla bardziej kompleksowego dopasowania częściowego rozważ zewnętrzne rozwiązanie wyszukiwania takie jak Elasticsearch.

Znaki akcentowane powodujące braki w wynikach

PrestaShop normalizuje znaki akcentowane podczas indeksowania (na przykład konwertując "cafe" i "café" do tej samej formy bazowej). Jeśli ta normalizacja nie działa prawidłowo, wyszukiwania z akcentami lub bez nich mogą dawać różne wyniki.

Rozwiązanie: Zweryfikuj, że konfiguracja wyszukiwania ma włączone usuwanie akcentów. Reindeksuj po weryfikacji. Jeśli problem utrzymuje się, sprawdź zestaw znaków i collation bazy danych, ponieważ niezgodne kodowania mogą zakłócać normalizację tekstu.

Optymalizacja wydajności wyszukiwania

Dla sklepów z dużymi katalogami (ponad 10 000 produktów) wydajność wyszukiwania może stać się problemem. Wbudowane wyszukiwanie wykonuje zapytania do bazy danych na tabelach indeksu przy każdym zapytaniu wyszukiwania, a przy dużym indeksie te zapytania mogą stawać się wolne.

Indeksy bazy danych

Upewnij się, że tabele ps_search_word i ps_search_index mają prawidłowe indeksy bazy danych. PrestaShop tworzy je domyślnie, ale jeśli tabele zostały zmienione lub odbudowane, indeksy mogą brakować. Kluczowe indeksy to te na id_word i id_lang w ps_search_word oraz na id_product i id_word w ps_search_index.

Minimalna długość słowa

Ustawienie minimalnej długości słowa kontroluje najkrótsze słowo, które zostanie zaindeksowane. Domyślnie jest to zazwyczaj 3 znaki, co oznacza, że jedno- i dwuznakowe słowa są wykluczone. Zwiększenie tego do 4 zmniejsza rozmiar indeksu i może poprawić szybkość wyszukiwania, ale oznacza, że wyszukiwania krótkich terminów jak "XL" czy "TV" nie będą działać. Zbalansuj rozmiar indeksu z wymaganiami wyszukiwania.

Czarna lista słów

Dodanie popularnych słów ("i", "w", "na", "do") do czarnej listy znacząco zmniejsza rozmiar indeksu, ponieważ te słowa pojawiają się w prawie każdym opisie produktu. Mniejsze tabele indeksu oznaczają szybsze zapytania.

Optymalizacja tabel

Po pełnej reindeksacji uruchom OPTIMIZE TABLE ps_search_word, ps_search_index w MySQL. Proces reindeksacji usuwa i ponownie wstawia dużą liczbę wierszy, co może pozostawić tabele we fragmentarycznym stanie. Optymalizacja odzyskuje tę przestrzeń i poprawia wydajność zapytań.

Elasticsearch jako alternatywa

Dla sklepów, które przerosły wbudowane wyszukiwanie PrestaShop, Elasticsearch zapewnia znaczącą aktualizację zarówno jakości wyszukiwania, jak i wydajności. Elasticsearch to dedykowany silnik wyszukiwania działający jako oddzielna usługa, oferujący funkcje, których wbudowane wyszukiwanie oparte na MySQL nie jest w stanie zapewnić.

Co dodaje Elasticsearch

Dopasowanie rozmyte pozwala Elasticsearch znajdować wyniki nawet gdy termin wyszukiwania jest błędnie napisany. Wyszukanie "skóra" nadal znajdzie produkty zawierające "skórzany". Stemming redukuje słowa do ich formy podstawowej, więc "bieganie", "biegnie" i "biegał" pasują do produktów zawierających dowolną z tych odmian. Obsługa synonimów pozwala definiować relacje między słowami ("sofa" i "kanapa") na poziomie silnika wyszukiwania, a nie przez ręczne aliasy.

Wyszukiwanie fasetowe (filtrowanie wyników po atrybutach takich jak zakres cenowy, kolor, marka) jest drastycznie szybsze z Elasticsearch, ponieważ jest zaprojektowany dokładnie do tego typu zapytań agregujących. Podpowiedzi autouzupełniania i funkcje "czy chodziło Ci o" to również natywne możliwości Elasticsearch.

Pod względem wydajności Elasticsearch obsługuje duże katalogi (ponad 100 000 produktów) z czasami odpowiedzi poniżej sekundy, ponieważ używa odwróconych indeksów zoptymalizowanych pod wyszukiwanie pełnotekstowe, w przeciwieństwie do MySQL, który jest głównie zaprojektowany dla danych relacyjnych.

Integracja z PrestaShop

Kilka modułów PrestaShop zapewnia integrację z Elasticsearch. Te moduły zazwyczaj zastępują domyślny kontroler wyszukiwania takim, który odpytuje Elasticsearch zamiast tabel wyszukiwania MySQL. Dane produktów są synchronizowane z PrestaShop do Elasticsearch albo w czasie rzeczywistym (przy zapisie produktu), albo poprzez okresową synchronizację wsadową.

Uruchomienie Elasticsearch wymaga dedykowanego serwera lub kontenera z odpowiednią ilością RAM (minimum 2 GB dla małych katalogów, więcej dla większych). Dodaje to złożoność operacyjną, ponieważ masz teraz kolejną usługę do monitorowania i utrzymywania. Dla wielu małych i średnich sklepów wbudowane wyszukiwanie z prawidłową konfiguracją wag i regularną reindeksacją jest wystarczające.

Kiedy rozważyć Elasticsearch

Rozważ Elasticsearch, gdy Twój katalog przekracza 10 000 produktów i wydajność wyszukiwania spada, gdy klienci często błędnie piszą terminy wyszukiwania i oczekują dopasowania rozmytego, gdy potrzebujesz zaawansowanych funkcji takich jak autouzupełnianie czy filtrowanie fasetowe, lub gdy jakość wyszukiwania jest przewagą konkurencyjną Twojego biznesu (sklepy B2B z złożonymi katalogami produktów, na przykład).

Lista kontrolna reindeksacji

Gdy wyszukiwanie nie działa prawidłowo w Twoim sklepie PrestaShop, postępuj zgodnie z tym procesem diagnostycznym i naprawczym. Po pierwsze, zweryfikuj, że problematyczne produkty są aktywne, widoczne i dostępne (jeśli wyszukiwanie wyklucza produkty niedostępne). Po drugie, sprawdź konfigurację wag wyszukiwania i upewnij się, że odpowiada Twoim priorytetom. Po trzecie, uruchom pełną odbudowę indeksu wyszukiwania z back office lub CLI. Po czwarte, wyczyść cache PrestaShop po reindeksacji. Po piąte, przetestuj wyszukiwanie konkretnymi terminami, aby zweryfikować naprawę. Po szóste, jeśli problemy utrzymują się, sprawdź tabele ps_search_word i ps_search_index bezpośrednio, aby zweryfikować, czy problematyczne produkty mają wpisy. Po siódme, jeśli indeks wydaje się prawidłowy, ale wyszukiwanie nadal zawodzi, zbadaj logikę kontrolera wyszukiwania i wszelkie moduły, które go nadpisują.

Regularna reindeksacja, połączona z przemyślaną konfiguracją wag i dobrze utrzymaną listą aliasów, utrzymuje wbudowane wyszukiwanie PrestaShop w niezawodnym działaniu dla większości sklepów. Dla tych, którzy potrzebują więcej, Elasticsearch zapewnia ścieżkę aktualizacji bez konieczności zmiany platformy.

Przeczytaj pełną odpowiedź

Zrozumienie trzech warstw cachowania w PrestaShop

PrestaShop wykorzystuje wiele mechanizmów cachowania do szybkiego dostarczania stron. Każda warstwa działa na innym poziomie stosu, a zrozumienie tego, co każda z nich robi, kiedy się aktywuje i kiedy trzeba ją wyczyścić, jest niezbędne zarówno do optymalizacji wydajności, jak i rozwiązywania problemów. Trzy najważniejsze warstwy cachowania to cache szablonów Smarty, PHP OPcache i cache przeglądarki. Współpracują ze sobą, ale rozwiązują różne problemy i wymagają różnych podejść do zarządzania.

Gdy klient odwiedza Twój sklep, zapytanie przechodzi przez wszystkie trzy warstwy w odwrotnej kolejności. Przeglądarka najpierw sprawdza swoją lokalną pamięć podręczną. Jeśli ma świeżą kopię zasobu, w ogóle nie kontaktuje się z serwerem. Jeśli przeglądarka wyśle zapytanie, przetwarza je PHP. OPcache zapewnia, że pliki PHP są kompilowane raz i ponownie używane z pamięci, a nie parsowane od nowa przy każdym zapytaniu. Wreszcie cache Smarty zapewnia, że renderowanie szablonów, które obejmuje parsowanie składni szablonów i wykonywanie logiki szablonów, zachodzi tylko wtedy, gdy to konieczne, a nie przy każdym załadowaniu strony.

Problemy powstają, gdy te warstwy serwują nieaktualne treści. Zmieniasz plik szablonu, ale strona wygląda tak samo. Aktualizujesz plik PHP, ale stare zachowanie nie ustępuje. Modyfikujesz CSS, ale przeglądarka nadal pokazuje stare style. Każdy z tych symptomów wskazuje na inną warstwę cachowania, a czyszczenie niewłaściwej marnuje czas bez rozwiązania problemu.

Cache szablonów Smarty: Jak działa

Smarty to silnik szablonów, którego PrestaShop używa do renderowania HTML. Każdy plik .tpl w Twoim motywie i modułach przechodzi przez Smarty, zanim stanie się kodem HTML wysyłanym do przeglądarki. Cachowanie Smarty działa w dwóch odrębnych fazach: kompilacja i cachowanie wyjścia.

Kompilacja szablonów

Gdy Smarty napotyka plik .tpl po raz pierwszy, kompiluje go do pliku PHP. Ten skompilowany plik jest przechowywany w katalogu /var/cache/prod/smarty/compile/ (lub /var/cache/dev/smarty/compile/ w trybie debugowania). Skompilowany plik zawiera logikę szablonu przetłumaczoną na czysty PHP, który wykonuje się znacznie szybciej niż parsowanie składni Smarty przy każdym zapytaniu.

Smarty sprawdza, czy skompilowana wersja jest aktualna, porównując znaczniki czasu. Jeśli źródłowy plik .tpl jest nowszy niż wersja skompilowana, Smarty automatycznie go rekompiluje. Jest to kontrolowane przez ustawienie compile_check. W produkcji możesz wyłączyć sprawdzanie kompilacji dla maksymalnej wydajności, co oznacza, że Smarty zakłada, iż skompilowane szablony są zawsze aktualne i nigdy nie sprawdza plików źródłowych.

Cachowanie wyjścia szablonów

Poza kompilacją, Smarty może również cachować wyrenderowane wyjście szablonów. Gdy cachowanie wyjścia jest włączone, Smarty przechowuje końcowy wynik HTML szablonu i serwuje go bezpośrednio przy kolejnych zapytaniach bez wykonywania jakiejkolwiek logiki szablonu. Jest to bardziej agresywne niż cachowanie kompilacji, ponieważ pomija nie tylko krok parsowania, ale również przetwarzanie danych i wykonywanie logiki w szablonie.

Cachowanie wyjścia w PrestaShop jest zarządzane per hook modułu. Każdy moduł może zadeklarować, czy jego wyjście hooka jest cachowalne, a PrestaShop przypisuje klucze cache na podstawie czynników takich jak aktualny język, sklep, waluta i grupa klientów. Oznacza to, że klient francuski i klient angielski otrzymują oddzielne cachowane wersje.

Ustawienia cache Smarty w PrestaShop

Konfigurujesz cachowanie Smarty w back office w sekcji Zaawansowane parametry > Wydajność. Istotne ustawienia to:

Kompilacja szablonów: To kontroluje, jak Smarty obsługuje kompilację szablonów. Opcje to zazwyczaj "Nigdy nie rekompiluj" (najszybsze, zawsze używa wersji skompilowanej), "Rekompiluj jeśli zmieniono" (sprawdza znaczniki czasu plików, dobry balans) i "Wymuszaj kompilację" (rekompiluje przy każdym zapytaniu, tylko do celów deweloperskich). W produkcji używaj "Rekompiluj jeśli zmieniono", chyba że masz pewność, że Twoje szablony nigdy nie zmieniają się pomiędzy wdrożeniami.

Cache: To przełącza cachowanie wyjścia Smarty. Po włączeniu Smarty przechowuje wyrenderowany wynik HTML i serwuje go bez ponownego wykonywania logiki szablonu. Zapewnia to znaczące korzyści wydajnościowe dla sklepów ze złożonymi szablonami lub wieloma hookami modułów.

Optymalizacje multi-front: Włącza cachowanie między wieloma serwerami frontendowymi. Istotne tylko dla konfiguracji klastrowych.

Czyszczenie cache: Opcje obejmują "Nigdy nie czyść plików cache", "Wyczyść cache za każdym razem, gdy coś zostanie zmodyfikowane" oraz konkretne strategie czyszczenia. Dla większości sklepów czyszczenie przy modyfikacji jest właściwym wyborem.

Czyszczenie cache Smarty

Aby wyczyścić cache Smarty ręcznie, możesz użyć przycisku "Wyczyść cache" na stronie Wydajność w back office. Usuwa to skompilowane szablony i cachowane wyjście z katalogu /var/cache/. Możesz również wyczyścić go, usuwając pliki bezpośrednio z serwera.

Musisz wyczyścić cache Smarty, gdy modyfikujesz pliki szablonów .tpl (jeśli sprawdzanie kompilacji jest wyłączone), gdy instalujesz lub aktualizujesz moduł zmieniający szablony, gdy zmieniasz motywy lub gdy modyfikujesz konfigurację związaną z szablonami. Jeśli zmienisz plik .tpl i zmiana nie pojawia się na froncie, cache kompilacji Smarty jest prawie zawsze przyczyną.

PHP OPcache: Jak działa

PHP OPcache to cache bytecodu wbudowany w PHP. Gdy PHP wykonuje skrypt, przechodzi przez trzy etapy: leksing (rozbijanie kodu źródłowego na tokeny), parsowanie (budowanie abstrakcyjnego drzewa składniowego) i kompilacja (generowanie bytecodu, który wykonuje silnik PHP). OPcache przechowuje skompilowany bytecod we współdzielonej pamięci, dzięki czemu kolejne zapytania o ten sam skrypt pomijają te etapy.

To różni się od cache Smarty. Smarty cachuje wyjście renderowania szablonów (HTML). OPcache cachuje wyjście kompilacji PHP (bytecod). Działają na zupełnie różnych poziomach. Szablon Smarty, który został skompilowany do pliku PHP przez Smarty, nadal korzysta z OPcache, ponieważ ten skompilowany plik PHP sam jest cachowany jako bytecod przez OPcache.

Konfiguracja OPcache dla PrestaShop

OPcache jest konfigurowany w pliku php.ini. Najważniejsze ustawienia dla PrestaShop to:

opcache.enable=1 włącza OPcache. To powinno być zawsze włączone w produkcji. Różnica wydajnościowa jest dramatyczna: wykonywanie PHP staje się 2 do 5 razy szybsze z włączonym OPcache.

opcache.memory_consumption=256 ustawia ilość współdzielonej pamięci (w megabajtach) dostępnej do przechowywania skompilowanego bytecodu. PrestaShop z kilkoma modułami może łatwo zużyć 128 MB lub więcej. Ustaw to na 256 MB lub więcej dla sklepów z wieloma modułami.

opcache.max_accelerated_files=20000 ustawia maksymalną liczbę plików PHP, które mogą być cachowane. Rdzeń PrestaShop plus moduły mogą łatwo mieć 10 000 lub więcej plików PHP.

opcache.validate_timestamps=1 nakazuje OPcache sprawdzać, czy pliki źródłowe się zmieniły. W produkcji możesz ustawić to na 0 dla maksymalnej wydajności, ale wtedy musisz restartować PHP-FPM przy każdym wdrożeniu.

opcache.revalidate_freq=60 definiuje, jak często (w sekundach) OPcache sprawdza zmiany plików. Dla produkcji 60 to dobry balans.

opcache.interned_strings_buffer=16 przydziela pamięć na internowane łańcuchy znaków. Ustaw to na 16 MB lub więcej.

opcache.save_comments=1 musi być włączone dla PrestaShop. PrestaShop używa adnotacji PHP DocBlock odczytywanych w czasie wykonania.

OPcache a rozdzielenie CLI i Web

Ważny szczegół dotyczący OPcache polega na tym, że środowiska CLI (wiersz poleceń) i web (PHP-FPM lub mod_php) utrzymują oddzielne pule OPcache. Czyszczenie OPcache z wiersza poleceń nie czyści webowego OPcache. Aby wyczyścić webowy OPcache, musisz albo restartować usługę PHP-FPM, albo wykonać opcache_reset() przez zapytanie webowe.

Ta różnica ma znaczenie w procesach wdrożeniowych. Jeśli wdrożysz nowy kod i wyczyścisz OPcache poleceniem CLI, Twoja witryna nadal serwuje stary bytecod, aż webowy OPcache również zostanie wyczyszczony.

Kiedy czyścić OPcache

Musisz wyczyścić OPcache za każdym razem, gdy modyfikujesz, przesyłasz lub zastępujesz pliki PHP na serwerze. Dotyczy to wdrażania nowej wersji PrestaShop, instalowania lub aktualizowania modułów, edycji plików PHP bezpośrednio na serwerze i aktualizacji zależności Composera. Restart PHP-FPM jest najbardziej niezawodnym sposobem na wyczyszczenie go.

Cache przeglądarki: Jak działa

Cachowanie przeglądarki jest ostatnią warstwą i działa wyłącznie po stronie klienta. Gdy przeglądarka pobiera zasób (plik CSS, JavaScript, obraz, czcionkę lub nawet stronę HTML), może przechować lokalną kopię i użyć jej ponownie przy kolejnych zapytaniach. Całkowicie eliminuje to podróże sieciowe dla cachowanych zasobów, co jest największą możliwą poprawą wydajności.

Cachowanie przeglądarki jest kontrolowane przez nagłówki odpowiedzi HTTP. Najważniejsze nagłówki to Cache-Control, Expires, ETag i Last-Modified.

Nagłówek Cache-Control

max-age=31536000 informuje przeglądarkę, aby cachowała zasób przez do jednego roku. no-cache oznacza, że przeglądarka może cachować zasób, ale musi zwalidować go z serwerem przed użyciem. no-store faktycznie zapobiega cachowaniu. public wskazuje, że odpowiedź może być cachowana przez dowolny cache, w tym CDN-y. private wskazuje, że odpowiedź jest specyficzna dla pojedynczego użytkownika.

Nagłówki ETag i Last-Modified

ETag to unikalny identyfikator konkretnej wersji zasobu. Serwer generuje go i wysyła z odpowiedzią. Przeglądarka odsyła go do walidacji. Last-Modified działa podobnie, ale używa znaczników czasu zamiast hashy.

Konfiguracja cache przeglądarki dla PrestaShop

Zasoby statyczne PrestaShop powinny być agresywnie cachowane przez przeglądarki. Dla Apache używasz modułów mod_expires i mod_headers. Dla Nginx dodajesz dyrektywy expires w blokach location dla plików statycznych.

Cache busting w PrestaShop

Z włączonym CCC, PrestaShop łączy pliki CSS i JavaScript w pakiety i generuje nazwy plików zawierające hash treści. Gdy treść się zmienia, zmienia się nazwa pliku. Bez CCC, niektóre motywy dodają query string z wersją do URL-ów.

Jak trzy warstwy współdziałają

Zrozumienie interakcji tych trzech warstw cachowania jest kluczowe dla efektywnego rozwiązywania problemów. Klient odwiedza stronę produktu. Przeglądarka sprawdza swój cache pod kątem HTML tej strony. Ponieważ HTML jest zazwyczaj serwowany z no-cache, przeglądarka wysyła zapytanie do serwera.

Serwer WWW otrzymuje zapytanie i przekazuje je do PHP. OPcache PHP-FPM ma bytecod plików PrestaShop cachowany we współdzielonej pamięci. PHP wykonuje bytecod bez rekompilacji plików źródłowych.

Kontroler PrestaShop wywołuje Smarty do wyrenderowania szablonu. Smarty sprawdza swój cache. Jeśli istnieje prawidłowy cachowany wynik, Smarty zwraca cachowany HTML bezpośrednio. Jeśli nie, wykonuje skompilowany szablon, generuje HTML i przechowuje go w cache wyjścia.

PHP wysyła odpowiedź HTML do przeglądarki, wraz z nagłówkami HTTP kontrolującymi cachowanie. Przeglądarka renderuje HTML i żąda plików CSS, JavaScript i obrazów. Dla każdego z tych zasobów przeglądarka sprawdza swój lokalny cache.

Rozwiązywanie problemów z nieaktualnymi treściami

Krok 1: Sprawdź przeglądarkę

Otwórz stronę w oknie incognito lub prywatnym, albo wykonaj twarde odświeżenie (Ctrl+Shift+R). Jeśli zmiana pojawia się w trybie incognito, ale nie w normalnym oknie, cache przeglądarki jest przyczyną.

Krok 2: Sprawdź cache Smarty

Jeśli zmiana nie pojawia się nawet w trybie incognito, problem jest po stronie serwera. Dla zmian w szablonach wyczyść cache Smarty z back office lub usuń zawartość var/cache/prod/smarty/.

Krok 3: Sprawdź OPcache

Jeśli wyczyszczenie cache Smarty nie pomaga i zmiana dotyczy pliku PHP, OPcache prawdopodobnie serwuje stary bytecod. Restartuj PHP-FPM lub wywołaj opcache_reset() przez zapytanie webowe.

Krok 4: Sprawdź inne cache

PrestaShop ma dodatkowe mechanizmy cachowania. Cache Symfony przechowuje skompilowane kontenery usług i definicje tras. Jeśli używasz reverse proxy jak Varnish lub CDN jak Cloudflare, te dodają kolejną warstwę cachowania.

Optymalna konfiguracja dla produkcji

Smarty: Ustaw kompilację szablonów na "Rekompiluj jeśli zmieniono". Włącz cachowanie wyjścia. Ustaw czyszczenie cache na "Wyczyść przy modyfikacji".

OPcache: Włącz z co najmniej 256 MB pamięci, 20000 max accelerated files, validate_timestamps włączone z revalidate_freq 60 sekund.

Cache przeglądarki: Ustaw Cache-Control z długimi wartościami max-age dla zasobów statycznych. Używaj no-cache dla odpowiedzi HTML. Włącz CCC w PrestaShop, aby uzyskać automatyczny cache busting.

Z tą konfiguracją Twój sklep korzysta ze wszystkich trzech warstw cachowania współpracujących razem. Zasoby statyczne są serwowane z cache przeglądarki bez kontaktu z serwerem. Pliki PHP są wykonywane z cachowanego bytecodu bez rekompilacji. A renderowanie szablonów jest cachowane, więc logika Smarty uruchamia się tylko, gdy treść się zmienia.

Kiedy czyścić każdą warstwę cache

Wyczyść cache Smarty gdy edytujesz pliki .tpl, zmieniasz pozycje lub hooki modułów, instalujesz lub aktualizujesz moduły zmieniające szablony, lub zmieniasz ustawienia związane z motywem.

Wyczyść OPcache gdy edytujesz pliki PHP, instalujesz lub aktualizujesz moduły, aktualizujesz rdzeń PrestaShop lub uruchamiasz Composer do aktualizacji zależności.

Wyczyść cache przeglądarki gdy musisz natychmiast zobaczyć zmiany CSS, JavaScript lub obrazów podczas rozwoju. Dla produkcji polegaj na cache busting zamiast prosić użytkowników o czyszczenie ich cache.

Kompleksowa sekwencja czyszczenia cache po dużym wdrożeniu: wyczyść katalogi kompilacji i cache Smarty, restartuj PHP-FPM aby wyczyścić OPcache, oczyść cache CDN lub reverse proxy jeśli dotyczy, i zweryfikuj w oknie incognito przeglądarki. Dla drobnych zmian wystarczy wyczyścić tylko odpowiednią warstwę.

Przeczytaj pełną odpowiedź

What Content Security Policy Is and Why It Matters

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that tells the browser exactly which resources are allowed to load on your pages. It prevents cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities by giving you granular control over where JavaScript, CSS, images, fonts, frames, and other resources can originate from.

Without CSP, a browser will execute any JavaScript it encounters on your page, regardless of where it came from. If an attacker manages to inject a malicious script (through a vulnerable module, a compromised third-party library, or a stored XSS vulnerability), the browser happily executes it with full access to the page content, including customer data, form inputs, and session cookies.

With CSP, you declare a whitelist of trusted sources. If the browser encounters a resource that does not match the policy, it blocks it and logs a violation. This means that even if an attacker finds a way to inject code into your page, the browser refuses to execute it because it does not come from an approved source.

For PrestaShop stores that handle customer personal information, payment data, and authentication credentials, CSP is a critical security layer. It is not a replacement for fixing vulnerabilities in your code, but it is an effective defense-in-depth measure that limits the damage when a vulnerability exists.

CSP Directives Explained

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. The most important directives for PrestaShop are:

default-src: The fallback directive. If a more specific directive is not set, the browser uses default-src. Setting default-src 'self' means that by default, only resources from your own domain are allowed.

script-src: Controls where JavaScript can be loaded from. This is the most critical directive for XSS prevention. Common values include 'self' (your own domain), specific CDN domains, and analytics domains.

style-src: Controls where CSS can be loaded from. PrestaShop themes and modules frequently use inline styles, which means you may need 'unsafe-inline' unless you implement a nonce-based approach.

img-src: Controls where images can be loaded from. PrestaShop stores often load images from their own domain, CDN domains, and third-party services like Google (for user avatars or Maps).

font-src: Controls where fonts can be loaded from. Google Fonts, Font Awesome CDN, and your own domain are common sources.

connect-src: Controls which URLs can be contacted via JavaScript (AJAX requests, WebSocket connections, EventSource). Payment gateways, analytics endpoints, and your own API endpoints need to be listed here.

frame-src: Controls which domains can be embedded in iframes. Payment gateways like PayPal, Stripe, and Klarna use iframes for their payment forms. YouTube and Vimeo embeds also require frame-src entries.

frame-ancestors: Controls which domains can embed your page in an iframe. Setting frame-ancestors 'self' prevents clickjacking attacks by ensuring your store cannot be embedded in another site's iframe.

object-src: Controls plugin content like Flash. Set this to 'none' because Flash is obsolete and no PrestaShop functionality requires it.

base-uri: Controls which URLs can be used in the <base> element. Set to 'self' to prevent base URI manipulation attacks.

form-action: Controls which URLs forms can submit to. This should include your own domain and any external payment processing endpoints.

Starting with Report-Only Mode

Deploying CSP on a PrestaShop store requires careful preparation because an overly restrictive policy will break functionality. The right approach is to start with report-only mode, which tells the browser to report violations without actually blocking anything.

Instead of using the Content-Security-Policy header, use Content-Security-Policy-Report-Only. This header accepts the exact same directives but only generates reports without enforcing the policy. Your store continues to function normally while you collect data about what would be blocked.

Setting Up Violation Reporting

Add a report-uri directive to your policy that points to an endpoint that collects violation reports. You can use a free service like Report URI (report-uri.com), which provides a dashboard for viewing and analyzing CSP violations, or you can set up your own endpoint.

The browser sends violation reports as JSON POST requests. Each report includes the blocked URI, the directive that was violated, the page where the violation occurred, and other useful debugging information. Collecting these reports for a week or two on a live store gives you a comprehensive picture of all the resources your store loads and where they come from.

Building Your Initial Policy

Using the violation reports from report-only mode, build a whitelist of all legitimate resource sources. Group them by directive type. Your initial policy will likely include:

Your own domain for all resource types. CDN domains (like cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) for scripts, styles, and fonts. Analytics domains (like google-analytics.com, googletagmanager.com, connect.facebook.net) for tracking. Payment gateway domains for scripts, frames, and connections. Chat widget domains if you use live chat. Social media domains for embedded content or share buttons.

Building a CSP for PrestaShop

PrestaShop presents specific challenges for CSP implementation because of its architecture and the modules ecosystem.

Handling Inline Styles and Scripts

PrestaShop core, themes, and many modules use inline styles and inline JavaScript extensively. Inline code is blocked by default in CSP because an attacker who injects content into your page would be injecting inline code. There are three approaches to handling this:

Using 'unsafe-inline': The simplest but least secure approach. Adding 'unsafe-inline' to script-src and style-src allows all inline code, which significantly weakens CSP's XSS protection. For style-src, this is generally acceptable because inline styles pose a much lower security risk than inline scripts. For script-src, avoid 'unsafe-inline' if at all possible.

Using nonces: The recommended approach. A nonce is a random, single-use token generated on each request. You add the nonce to your CSP header (script-src 'nonce-abc123') and to each legitimate inline script tag (<script nonce="abc123">). The browser only executes inline scripts that have the correct nonce. Since the nonce changes on every request and an attacker cannot predict it, injected scripts without the nonce are blocked.

Implementing nonces in PrestaShop requires modifying the theme to add nonce attributes to all inline script tags and creating a mechanism (typically a module or a custom hook) that generates the nonce, adds it to the CSP header, and makes it available to templates. This is a significant implementation effort but provides strong XSS protection.

Using hashes: You can whitelist specific inline scripts by their SHA-256 hash. The browser computes the hash of each inline script it encounters and checks it against the hashes listed in the CSP. This approach works for inline scripts that do not change between requests (static inline scripts), but it is impractical for PrestaShop because many inline scripts include dynamic content like product IDs, prices, and user-specific data that change the hash.

Handling eval and Dynamic Code

Some JavaScript libraries use eval() or new Function() to dynamically create and execute code. CSP blocks these by default. If a module or library requires eval, you must add 'unsafe-eval' to script-src. Common culprits include older versions of jQuery templates, some analytics scripts, and certain payment gateway libraries.

Check your violation reports for entries with eval or inline as the blocked URI. These indicate code that uses dynamic evaluation. Where possible, replace the library with a version that does not use eval. When that is not possible (such as with a third-party payment gateway library you cannot modify), 'unsafe-eval' is the only option.

Third-Party Services

Most PrestaShop stores rely on multiple third-party services, each of which needs to be whitelisted in your CSP. Here are the most common ones and the directives they require:

Google Analytics and Google Tag Manager: These require entries in script-src for www.google-analytics.com, www.googletagmanager.com, and tagmanager.google.com. They also need connect-src entries for www.google-analytics.com and analytics.google.com (for sending tracking data), and img-src entries for www.google-analytics.com (for the tracking pixel). Google Tag Manager is particularly challenging because it dynamically loads scripts from domains you may not know in advance, as the scripts loaded depend on the tags configured in GTM.

PayPal: Requires script-src and frame-src entries for *.paypal.com and *.paypalobjects.com. The exact domains depend on whether you use PayPal Standard, PayPal Express, or the newer PayPal Commerce Platform integration.

Stripe: Requires script-src for js.stripe.com, frame-src for js.stripe.com and hooks.stripe.com, and connect-src for api.stripe.com.

Google Fonts: Requires style-src for fonts.googleapis.com and font-src for fonts.gstatic.com.

YouTube embeds: Require frame-src for www.youtube.com and www.youtube-nocookie.com.

Facebook Pixel and social plugins: Require script-src and connect-src for connect.facebook.net and www.facebook.com, plus img-src for www.facebook.com and *.fbcdn.net.

Live chat widgets (Tidio, Crisp, Intercom, etc.): Each has its own set of domains for scripts, styles, WebSocket connections, and images. Check your violation reports or the provider's documentation for the exact domains required.

A Complete CSP Example for PrestaShop

Here is a realistic CSP header for a PrestaShop store that uses Google Analytics, Google Fonts, PayPal, YouTube embeds, and has inline styles:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

This policy includes 'unsafe-inline' and 'unsafe-eval' for scripts, which weakens XSS protection but is necessary for most PrestaShop installations that have not been modified to support nonces. For img-src, the data: source is included because PrestaShop and many modules use data URIs for small images and icons.

Implementing CSP in PrestaShop

Via .htaccess (Apache)

For Apache servers, add the CSP header in your .htaccess file. Place it near the top of the file, before the PrestaShop rewrite rules:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

This requires the mod_headers module to be enabled. You can verify by checking if your server returns the header using browser DevTools (Network tab, click on the main document request, check the Response Headers).

Via Nginx Configuration

For Nginx, add the header in your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

The always parameter ensures the header is sent even for error responses, which is important because error pages can also be targets for XSS attacks.

Via a PrestaShop Module

Implementing CSP through a module gives you the ability to manage the policy from the back office. The module hooks into the actionOutputHTMLBefore or uses PHP's header() function in a front controller hook to add the CSP header to every response. A module-based approach is easier to maintain because you can update the policy without editing server configuration files and without restarting the web server.

Testing Your CSP with Browser DevTools

After implementing your CSP (in report-only mode initially), use browser DevTools to monitor for violations. Open the Console tab and look for messages that start with "[Report Only]" (in report-only mode) or "Refused to" (in enforcement mode). Each message tells you exactly what was blocked and which directive was responsible.

Test every page type on your store: the home page, category pages, product pages, the cart, the checkout process (including each step and each payment method), the customer account pages, and CMS pages. Each page type may load different resources, and you need to ensure your policy covers all of them.

Pay special attention to the checkout process. A blocked payment gateway script or iframe during checkout directly prevents customers from completing purchases. Test every payment method you offer, including the 3D Secure verification flow if applicable, because these often load additional resources from domains that are not obvious.

Common Testing Pitfalls

Testing in a development environment may not reveal all violations because your development setup may not include all the third-party services that run on production (analytics, advertising pixels, live chat, A/B testing tools). Always deploy CSP in report-only mode on production first and collect reports for at least one to two weeks before switching to enforcement.

Some violations only occur under specific conditions. For example, a payment gateway might load additional verification scripts only when a customer's card requires 3D Secure authentication. Social sharing buttons might load scripts only when a visitor clicks them. Dynamic content loaded via AJAX may reference resources that are not present on the initial page load. Run through every possible user flow during testing.

Gradual Enforcement Strategy

The recommended deployment strategy for CSP on PrestaShop follows these steps:

Phase 1: Discovery. Deploy a permissive Content-Security-Policy-Report-Only header with default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; and a report-uri. This logs all resources without blocking anything, giving you a complete inventory of what your store loads.

Phase 2: Draft policy. Based on the violation reports, build a whitelist policy that covers all legitimate resources. Deploy it in report-only mode and monitor for violations that indicate you missed a resource.

Phase 3: Refine. Over one to two weeks, check violation reports daily and add any legitimate sources you missed. Pay attention to reports that come from specific page types or user flows you might not have tested manually.

Phase 4: Enforce. Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri directive so you continue receiving violation reports. Monitor closely for the first week after enforcement to catch any legitimate resources that are being blocked.

Phase 5: Tighten. Once enforcement is stable, look for opportunities to tighten the policy. Can you replace 'unsafe-inline' in script-src with nonces? Can you narrow wildcard domains to specific subdomains? Can you remove sources that are no longer used? Each tightening step improves your security posture.

Maintaining Your CSP

A CSP is not a set-and-forget configuration. Every time you install a new module, add a third-party service, change payment gateways, or update your theme, you may need to update your CSP to include new resource sources. Make CSP review part of your module installation and update process.

Keep your report-uri active even after enforcement so you receive alerts about new violations. A sudden increase in violation reports might indicate that a module update introduced new resource requirements, or it might indicate an actual XSS attack attempt that your CSP is successfully blocking. Either way, you want to know about it.

Document your CSP and the reason for each entry. Over time, policies accumulate entries for services you no longer use. Periodic reviews to remove unnecessary entries keep the policy clean and reduce the attack surface. A CSP with fewer allowed sources is inherently more secure than one with many.

Przeczytaj pełną odpowiedź

Czym jest Varnish i dlaczego ma znaczenie dla PrestaShop

Varnish Cache to odwrotne proxy HTTP (reverse proxy), które znajduje się pomiędzy serwerem www a internetem i serwuje zbuforowane kopie stron bez jakiegokolwiek kontaktu z PHP czy MySQL. Gdy odwiedzający żąda strony, którą Varnish ma w cache, odpowiedź pochodzi bezpośrednio z pamięci operacyjnej w ciągu mikrosekund. PHP nie jest uruchamiane. MySQL nie otrzymuje żadnego zapytania. Serwer WWW praktycznie nie zauważa, że żądanie miało miejsce.

To podejście jest zasadniczo różne od tego, jak działają moduły pełnego buforowania stron (FPC) oparte na PHP w PrestaShop. Moduł FPC nadal działa w ramach PHP. Żądanie trafia do Apache lub Nginx, PHP się uruchamia, PrestaShop inicjalizuje się (ładuje konfigurację, nawiązuje połączenia z bazą danych, parsuje trasy), a następnie moduł FPC przechwytuje żądanie zanim pełna logika kontrolera zostanie uruchomiona, serwując buforowany plik HTML. Choć jest to znacznie szybsze niż renderowanie strony od zera, nadal wymaga uruchomienia PHP i załadowania frameworka PrestaShop. Ten narzut, wynoszący zazwyczaj 50-200 milisekund nawet przy trafieniu w cache, kumuluje się pod obciążeniem.

Varnish całkowicie eliminuje ten narzut. Trafienie w cache Varnish jest serwowane w 1-5 milisekund. Przy dużym ruchu różnica jest dramatyczna. Sklep PrestaShop, który z trudem obsługuje 100 jednoczesnych użytkowników z modułem FPC, może obsłużyć tysiące jednoczesnych użytkowników z Varnishem, ponieważ zdecydowana większość żądań nigdy nie dociera do backendu PHP.

Kiedy moduły PHP Full Page Cache są wystarczające

Zanim zainwestujesz w Varnish, warto zrozumieć, kiedy moduł FPC oparty na PHP jest wystarczająco dobry. Dla wielu sklepów PrestaShop tak właśnie jest.

Jeśli Twój sklep generuje mniej niż 50 000 dziennych wyświetleń stron, dobrze skonfigurowany moduł FPC poradzi sobie z obciążeniem bez problemów. Dodatkowa złożoność Varnisha nie jest uzasadniona, gdy serwer dysponuje rezerwą mocy obliczeniowej. Jeśli czasy odpowiedzi serwera z FPC są konsekwentnie poniżej 200 milisekund, Twoi odwiedzający już otrzymują szybkie ładowanie stron. Wąskim gardłem w tym momencie jest prawdopodobnie renderowanie po stronie frontendu (CSS, JavaScript, obrazy), a nie czas odpowiedzi serwera.

Moduły FPC radzą sobie z niektórymi scenariuszami specyficznymi dla PrestaShop bardziej elegancko niż Varnish, ponieważ działają wewnątrz aplikacji. Mogą sprawdzić, czy użytkownik jest zalogowany, czy koszyk zawiera produkty i czy pewna dynamiczna treść wymaga personalizacji — wszystko w ramach tego samego procesu PHP. W przypadku Varnisha te sprawdzenia muszą być obsługiwane przez inspekcję ciasteczek i reguły wariacji cache, co dodaje złożoności konfiguracyjnej.

Rozważ Varnish, gdy Twój sklep regularnie obsługuje skoki ruchu (wyprzedaże błyskawiczne, kampanie marketingowe, szczyty sezonowe), które przeciążają moce PHP, gdy potrzebujesz czasów odpowiedzi poniżej 10 ms ze względu na SEO lub doświadczenie użytkownika, gdy budżet na hosting jest ograniczony i musisz obsłużyć większy ruch na tym samym sprzęcie, lub gdy sklep obsługuje wysoki stosunek anonimowego przeglądania (strony kategorii, strony produktów) w stosunku do aktywności koszyka i kasy.

Jak działa Varnish: Przepływ żądań

Zrozumienie przepływu żądań przez Varnish jest kluczowe dla prawidłowej konfiguracji z PrestaShop.

Przychodzące żądanie

Gdy odwiedzający żąda strony, żądanie trafia najpierw do Varnisha (Varnish nasłuchuje na porcie 80 lub 443, jeśli zakończenie SSL jest obsługiwane przez proxy frontendowe). Varnish analizuje żądanie: URL, metodę HTTP, ciasteczka i nagłówki.

Wyszukiwanie w cache

Varnish sprawdza swój cache pod kątem zapisanej odpowiedzi pasującej do tego żądania. Klucz cache jest zwykle oparty na URL i wybranych nagłówkach. Jeśli pasująca odpowiedź istnieje i nie wygasła, Varnish serwuje ją bezpośrednio. To jest trafienie w cache (cache hit). Odpowiedź jest wysyłana do odwiedzającego, a serwer backendowy nie jest w ogóle kontaktowany.

Pudło cache

Jeśli brak pasującej zbuforowanej odpowiedzi, Varnish przekazuje żądanie do serwera backendowego (Apache lub Nginx z PrestaShop). PrestaShop przetwarza żądanie normalnie, generuje odpowiedź HTML i odsyła ją do Varnisha. Varnish zapisuje odpowiedź w swoim cache (jeśli odpowiedź nadaje się do buforowania) i przekazuje ją odwiedzającemu. Kolejne żądania tej samej strony będą serwowane z cache.

Inwalidacja cache

Gdy dane produktu się zmienią, ceny zostaną zaktualizowane lub treść zostanie zmodyfikowana, wersja w cache staje się nieaktualna. Varnish musi zostać poinformowany o konieczności odrzucenia starej wersji z cache, aby pobrał świeżą z backendu. To jest inwalidacja cache, i jest to najtrudniejsza część każdego systemu buforowania do prawidłowego wdrożenia.

Konfiguracja VCL dla PrestaShop

Varnish Configuration Language (VCL) to język specyficzny dla domeny, który kontroluje sposób obsługi żądań przez Varnish. Prawidłowa konfiguracja VCL dla PrestaShop musi obsługiwać kilka zachowań specyficznych dla PrestaShop.

Definicja backendu

Definicja backendu informuje Varnish, dokąd przekazywać pudła cache. Dla typowej konfiguracji PrestaShop, gdzie Apache lub Nginx działa na tym samym serwerze na porcie 8080:

backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 5s; .first_byte_timeout = 60s; .between_bytes_timeout = 10s; }

Timeouty są ważne. Strony PrestaShop mogą potrzebować kilku sekund na wygenerowanie przy zimnym cache, szczególnie strony kategorii z wieloma produktami. Ustawienie first_byte_timeout zbyt nisko powoduje, że Varnish zwraca błąd 503 zanim PrestaShop zdąży wygenerować stronę.

Obsługa ciasteczek i sesji

Ciasteczka są największym wyzwaniem przy buforowaniu PrestaShop z Varnishem. PrestaShop ustawia domyślnie kilka ciasteczek, a Varnish traktuje każde żądanie z ciasteczkami jako niebuforowalne, chyba że poinstruujemy go inaczej. Jeśli nie obsłużysz ciasteczek w swoim VCL, Varnish nie będzie buforował praktycznie niczego.

PrestaShop ustawia te ciasteczka przy większości żądań: ciasteczko sesji (zwykle o nazwie PrestaShop-xxxx), ciasteczka związane z koszykiem, ciasteczka Google Analytics (_ga, _gid, _gat) oraz różne ciasteczka śledzące od narzędzi marketingowych. Spośród nich tylko ciasteczko sesji PrestaShop ma znaczenie dla zachowania cache. Ciasteczka analityczne i śledzące powinny być usuwane z żądania przed wyszukiwaniem w cache, aby nie uniemożliwiały buforowania.

W podprocedurze VCL vcl_recv usuń nieistotne ciasteczka:

sub vcl_recv { # Usuń ciasteczka Google Analytics i inne śledzące set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", ""); # Usuń pusty nagłówek ciasteczka if (req.http.Cookie ~ "^\s*$") { unset req.http.Cookie; } }

Decydowanie, co buforować

Nie każda strona PrestaShop powinna być buforowana. VCL musi rozróżniać między żądaniami buforowalnymi i niebuforowalnymi.

Zawsze buforuj: Strony produktów dla anonimowych odwiedzających, strony z listą kategorii, strony CMS (o nas, regulamin, kontakt), stronę główną, strony producentów i dostawców, strony mapy witryny.

Nigdy nie buforuj: Strony koszyka, strony kasy (wszystkie kroki), obszaru konta klienta (zamówienia, adresy, dane osobowe), stron logowania i rejestracji, żadnej strony dla zalogowanego klienta, żądań POST, żądań AJAX modyfikujących stan (dodaj do koszyka, aktualizuj ilość).

Logika VCL do tego celu zwykle sprawdza ścieżkę URL i obecność ciasteczek sesji:

sub vcl_recv { # Nie buforuj żądań POST if (req.method == "POST") { return (pass); } # Nie buforuj panelu administracyjnego if (req.url ~ "^/admin") { return (pass); } # Nie buforuj kasy i koszyka if (req.url ~ "(cart|order|login|my-account|module/)" ) { return (pass); } # Nie buforuj, jeśli klient ma produkty w koszyku if (req.http.Cookie ~ "PrestaShop-") { return (pass); } return (hash); }

Ustawianie czasu życia cache

W podprocedurze vcl_backend_response kontrolujesz, jak długo Varnish buforuje każdą odpowiedź. PrestaShop wysyła nagłówki Cache-Control, które zwykle mówią no-cache lub private, ponieważ zakłada, że każda odpowiedź może zawierać spersonalizowaną treść. Musisz je nadpisać dla stron, o których wiesz, że są bezpieczne do buforowania:

sub vcl_backend_response { # Buforuj strony produktów i kategorii przez 1 godzinę if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") { set beresp.ttl = 1h; unset beresp.http.Set-Cookie; } # Buforuj zasoby statyczne przez 1 dzień if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") { set beresp.ttl = 1d; unset beresp.http.Set-Cookie; } }

Usuwanie Set-Cookie z buforowanych odpowiedzi jest krytyczne. Jeśli buforowana odpowiedź zawiera nagłówek Set-Cookie, Varnish domyślnie jej nie zbuforuje, a nawet jeśli zostanie zmuszony do buforowania, ustawi to samo ciasteczko sesji dla każdego odwiedzającego, powodując przechwycenie sesji (session hijacking).

Inwalidacja cache za pomocą żądań PURGE

Gdy cena produktu się zmienia, nowy produkt jest dodawany lub treść jest aktualizowana, buforowana wersja musi zostać unieważniona. Varnish obsługuje żądania PURGE: specjalną metodę HTTP, która informuje Varnish o konieczności usunięcia konkretnego URL z cache.

Konfiguracja obsługi PURGE

Dodaj obsługę PURGE do swojego VCL:

acl purge { "127.0.0.1"; "localhost"; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge) { return (synth(405, "Not allowed.")); } return (purge); } }

ACL ogranicza żądania PURGE do localhost, uniemożliwiając zewnętrznym użytkownikom czyszczenie Twojego cache.

Wyzwalanie operacji purge z PrestaShop

PrestaShop natywnie nie wysyła żądań PURGE. Potrzebujesz modułu lub niestandardowego hooka, który wykrywa zmiany w treści nadającej się do buforowania i wysyła żądanie PURGE do Varnisha. Moduł podpina się pod zdarzenia PrestaShop takie jak actionProductUpdate, actionCategoryUpdate i actionCMSPageUpdate. Gdy te zdarzenia są wywoływane, moduł wysyła żądanie HTTP PURGE na odpowiedni URL serwera Varnish.

Przy aktualizacji produktu moduł powinien wyczyścić URL produktu, URL kategorii, do których produkt należy (ponieważ strony z listą kategorii wyświetlają ceny i dostępność produktów) oraz potencjalnie stronę główną, jeśli wyświetla polecane produkty. Ta kaskada operacji purge jest konieczna, aby zapobiec wyświetlaniu nieaktualnych danych w dowolnym miejscu witryny.

Inwalidacja oparta na BAN

W scenariuszach, gdy wiele URL-i wymaga jednoczesnego wyczyszczenia (aktualizacja cen w całej witrynie, zmiana designu, nowy baner promocyjny), indywidualne żądania PURGE są niepraktyczne. Varnish obsługuje bany, czyli reguły inwalidacji oparte na wzorcach. Ban informuje Varnish o konieczności odrzucenia każdego zbuforowanego obiektu pasującego do wzorca:

sub vcl_recv { if (req.method == "BAN") { if (!client.ip ~ purge) { return (synth(405, "Not allowed.")); } ban("req.url ~ " + req.http.X-Ban-Pattern); return (synth(200, "Banned.")); } }

Wysłanie żądania BAN z nagłówkiem X-Ban-Pattern: /category/ unieważni wszystkie zbuforowane strony kategorii w jednej operacji.

Edge Side Includes (ESI) dla bloków dynamicznych

Wiele stron PrestaShop zawiera mieszankę treści statycznej i dynamicznej. Lista produktów na stronie kategorii jest taka sama dla każdego odwiedzającego, ale nagłówek pokazujący liczbę produktów w koszyku jest spersonalizowany. Bez ESI nie można buforować strony w ogóle, ponieważ dynamiczny nagłówek sprawia, że cała odpowiedź jest specyficzna dla odwiedzającego.

Edge Side Includes rozwiązują to, pozwalając na oznaczenie sekcji strony jako osobno pobieranych fragmentów. Varnish składa finalną stronę z fragmentów buforowanych i niebuforowanych.

Jak działa ESI

W szablonie Smarty, zamiast renderować widget koszyka bezpośrednio, umieszczasz tag ESI:

<esi:include src="/module/cartwidget/ajax" />

Gdy Varnish przetwarza buforowaną stronę, napotyka tag ESI i wysyła osobne żądanie do backendu po ten fragment. Główne ciało strony jest serwowane z cache, podczas gdy widget koszyka jest pobierany świeżo z PrestaShop. Złożona odpowiedź zawiera zarówno buforowane ciało, jak i świeży widget koszyka.

Włącz przetwarzanie ESI w swoim VCL:

sub vcl_backend_response { set beresp.do_esi = true; }

Aspekty ESI dla PrestaShop

Wdrożenie ESI wymaga modyfikacji szablonów PrestaShop w celu oddzielenia dynamicznej treści na fragmenty kompatybilne z ESI. Każdy fragment potrzebuje własnego endpointu URL, który zwraca tylko HTML dla tego bloku. Fragmenty, które są zwykle dynamiczne i wymagają obsługi ESI, to: widget podsumowania koszyka (liczba produktów, suma), powitanie klienta ("Cześć, Jan"), wszelkie spersonalizowane rekomendacje produktów, link logowania/wylogowania oraz ostatnio przeglądane produkty.

Nakład pracy wymagany do prawidłowego wdrożenia ESI jest znaczny. Każdy dynamiczny fragment potrzebuje dedykowanego kontrolera, szablony wymagają restrukturyzacji, a reguły buforowania dla każdego fragmentu wymagają indywidualnego dostrojenia. To jeden z powodów, dla których Varnish jest uważany za zaawansowaną optymalizację — działa najlepiej, gdy aplikacja jest projektowana z myślą o nim.

Kontrole zdrowia backendu

Varnish może monitorować stan serwera backendowego i podejmować działania, gdy staje się niedostępny. Konfiguruje się to w definicji backendu:

backend default { .host = "127.0.0.1"; .port = "8080"; .probe = { .url = "/ping.php"; .timeout = 2s; .interval = 5s; .window = 5; .threshold = 3; } }

Varnish wysyła żądanie do /ping.php co 5 sekund. Jeśli 3 z ostatnich 5 sprawdzeń zakończy się niepowodzeniem, Varnish oznacza backend jako chory. Gdy backend jest chory, Varnish może serwować nieaktualną treść z cache (tryb grace) zamiast zwracać błędy odwiedzającym. Oznacza to, że Twój sklep pozostaje częściowo dostępny nawet gdy backend PHP ulega awarii lub jest restartowany.

Konfiguracja trybu grace określa, jak długo Varnish będzie serwował nieaktualną treść:

sub vcl_backend_response { set beresp.grace = 6h; }

Z 6-godzinnym grace, jeśli Twój backend padnie, odwiedzający zobaczą buforowane strony (nawet jeśli mają do 6 godzin) zamiast stron błędów. Ceny produktów mogą być nieznacznie nieaktualne, ale sklep pozostaje funkcjonalny, dopóki naprawiasz problem z backendem.

Benchmarki wydajności

Różnica wydajności między brakiem cache, PHP FPC i Varnishem jest znaczna i mierzalna.

Bez cache (czysty PrestaShop): Typowa strona produktu PrestaShop generuje się w 200-800 milisekund, w zależności od sprzętu serwera, liczby załadowanych modułów i liczby zapytań do bazy danych. Pod obciążeniem czasy odpowiedzi rosną, ponieważ workery PHP są nasycone. Pojedynczy serwer może obsłużyć 20-50 jednoczesnych użytkowników, zanim czasy odpowiedzi staną się nie do zaakceptowania.

Moduł PHP FPC: Trafienia w cache serwowane są w 30-100 milisekund, ponieważ PHP nadal się uruchamia, a framework częściowo inicjalizuje. Pod obciążeniem wydajność jest znacznie lepsza, ponieważ buforowane odpowiedzi wymagają minimalnego czasu przetwarzania PHP. Pojedynczy serwer może obsłużyć 200-500 jednoczesnych użytkowników w zależności od konfiguracji. Pudła cache nadal trwają pełny czas renderowania.

Varnish: Trafienia w cache serwowane są w 1-5 milisekund. Pod obciążeniem sam Varnish może obsłużyć tysiące jednoczesnych połączeń, ponieważ jest napisany w C i zaprojektowany specjalnie do tego obciążenia. Serwer backendowy obsługuje tylko pudła cache, które stanowią niewielki ułamek całkowitego ruchu w prawidłowo skonfigurowanym systemie. Ten sam sprzęt, który z trudem obsługuje 50 jednoczesnych użytkowników bez buforowania, może obsłużyć 5000 lub więcej z Varnishem.

Te liczby ilustrują, dlaczego Varnish jest wart złożoności konfiguracyjnej dla sklepów o dużym ruchu. Poprawa wydajności nie jest przyrostowa — jest o rząd wielkości.

Wymagania hostingowe

Varnish ma specyficzne wymagania hostingowe, których nie każde środowisko hostingowe PrestaShop może spełnić.

Dostęp do serwera

Potrzebujesz dostępu root, aby zainstalować i skonfigurować Varnish. Plany hostingu współdzielonego nie obsługują Varnisha, ponieważ wymaga on własnego procesu nasłuchującego na porcie i przechwytującego cały ruch HTTP. Potrzebujesz VPS, serwera dedykowanego lub instancji chmurowej, gdzie kontrolujesz pełny stos serwerowy.

Pamięć operacyjna

Varnish przechowuje swój cache w RAM. Ilość potrzebnej pamięci RAM zależy od liczby unikalnych stron w Twoim katalogu i rozmiaru każdej buforowanej odpowiedzi. Przybliżony wzór: liczba stron nadających się do buforowania pomnożona przez średni rozmiar strony daje minimalny rozmiar cache. Sklep z 5000 produktami, 200 kategoriami i średnim rozmiarem strony 50 KB potrzebuje około 260 MB pamięci cache. Dodaj narzut na sam Varnish i powinieneś przydzielić co najmniej 512 MB. Dla większych katalogów typowe jest 1-2 GB.

Konfiguracja portów

W standardowej konfiguracji Varnish nasłuchuje na porcie 80 (domyślny port HTTP) i przekazuje pudła cache do serwera www na innym porcie (zwykle 8080). Oznacza to, że musisz przekonfigurować Apache lub Nginx, aby nasłuchiwał na porcie 8080 zamiast 80. Jeśli używasz HTTPS (a powinieneś), zazwyczaj umieszczasz Nginx przed Varnishem do obsługi zakończenia SSL: Nginx na porcie 443 kończy SSL i przekazuje do Varnisha na porcie 80, który przekazuje pudła cache do Apache lub PHP-FPM na porcie 8080.

Przykład konfiguracji Docker

Uruchomienie Varnisha w Dockerze obok kontenera PrestaShop to czysty sposób na dodanie Varnisha do istniejącej konfiguracji bez modyfikowania systemu hosta.

Konfiguracja Docker Compose

Podstawowa konfiguracja Docker Compose z Varnishem, Nginx do SSL i PrestaShop:

services: varnish: image: varnish:7.4 ports: - "80:80" volumes: - ./varnish/default.vcl:/etc/varnish/default.vcl:ro environment: - VARNISH_SIZE=512m depends_on: - prestashop prestashop: image: prestashop/prestashop:8 expose: - "80" environment: - DB_SERVER=db db: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORD=secretpassword - MYSQL_DATABASE=prestashop

W tej konfiguracji Varnish jest punktem wejściowym na porcie 80. Kontener PrestaShop nie eksponuje swojego portu na hosta, tylko na sieć Dockera. Hostem backendu VCL byłby prestashop (nazwa usługi Docker) na porcie 80.

VCL dla Dockera

Definicja backendu VCL dla Dockera używa nazwy usługi zamiast localhost:

backend default { .host = "prestashop"; .port = "80"; }

Wewnętrzne DNS Dockera rozwiązuje nazwę usługi na IP kontenera. Reszta konfiguracji VCL pozostaje taka sama jak w konfiguracji bez Dockera.

Przechowywanie cache w Dockerze

Domyślnie obraz Docker Varnish używa przechowywania w pamięci (malloc), co jest idealne dla wydajności. Zmienna środowiskowa VARNISH_SIZE kontroluje, ile pamięci Varnish przydziela na swój cache. Ustaw tę wartość na taką, która mieści się w limitach pamięci kontenera, pozostawiając miejsce na sam proces Varnish.

Dla trwałego cache, który przetrwa restarty kontenera, możesz użyć przechowywania plikowego montując wolumen, ale jest to rzadko konieczne. Cache rozgrzewa się szybko (w ciągu minut od otrzymania ruchu), a przechowywanie plikowe jest wolniejsze niż przechowywanie w pamięci.

Monitorowanie wydajności Varnisha

Varnish zapewnia wbudowane narzędzia do monitorowania wydajności cache.

Polecenie varnishstat pokazuje statystyki w czasie rzeczywistym, w tym współczynnik trafień cache, połączenia z backendem i wykorzystanie pamięci. Najważniejszą metryką jest współczynnik trafień, który powinien wynosić 85% lub więcej dla dobrze skonfigurowanego systemu. Jeśli współczynnik trafień jest poniżej 70%, przejrzyj reguły VCL, ponieważ zbyt wiele żądań przechodzi do backendu.

Polecenie varnishlog pokazuje szczegółowe logi per żądanie, które są nieocenione przy debugowaniu, dlaczego konkretne żądania nie są buforowane. Możesz filtrować po wzorcu URL, kodzie odpowiedzi lub statusie trafienia/pudła cache.

Polecenie varnishtop pokazuje rankingową listę najczęstszych wpisów w logach, pomagając identyfikować wzorce w pudłach cache lub błędach.

Typowe pułapki

Zapominanie o usuwaniu ciasteczek

Najczęstszą błędną konfiguracją Varnisha z PrestaShop jest nieusuwanie ciasteczek analitycznych i śledzących. Te ciasteczka są obecne w praktycznie każdym żądaniu i sprawiają, że każde żądanie jest unikalne z perspektywy Varnisha, co skutkuje 0% współczynnikiem trafień. Zawsze usuwaj ciasteczka, których nie potrzebujesz do wariacji cache.

Buforowanie spersonalizowanej treści

Jeśli Twój VCL jest zbyt agresywny, będzie buforować strony zawierające spersonalizowaną treść (powitanie zalogowanego użytkownika, zawartość koszyka) i serwować je innym odwiedzającym. Powoduje to poważne problemy z użytecznością i potencjalne problemy z prywatnością. Zawsze przekazuj żądania zawierające ciasteczka sesji do backendu.

Brak inwalidacji przy zmianach treści

Bez odpowiedniego mechanizmu czyszczenia cache zmiany treści w panelu administracyjnym nie będą widoczne, dopóki buforowane strony nie wygasną naturalnie. Dla sklepu z aktywnymi zmianami stanów magazynowych oznacza to, że odwiedzający mogą widzieć produkty niedostępne, błędne ceny lub nieaktualne opisy. Wdróż obsługę PURGE lub BAN i zintegruj ją z hookami aktualizacji PrestaShop.

Ignorowanie HTTPS

Varnish natywnie nie obsługuje SSL. Musisz umieścić proxy kończące SSL (Nginx, HAProxy lub chmurowy load balancer) przed Varnishem. Brak zaplanowania tego w architekturze prowadzi do problemów z mieszaną treścią (mixed content), pętli przekierowań lub niemożności serwowania ruchu HTTPS w ogóle.

Czy Varnish jest odpowiedni dla Twojego sklepu

Varnish to potężne narzędzie, ale nie jest właściwym wyborem dla każdego sklepu PrestaShop. Dodaje złożoność operacyjną: kolejną usługę do monitorowania, kolejny język konfiguracyjny do nauki, kolejną warstwę w procesie debugowania. Korzyści są jasne i mierzalne dla sklepów, które ich potrzebują, ale wiążą się z kosztem w postaci czasu konfiguracji, konserwacji i trudności w rozwiązywaniu problemów.

Jeśli Twój sklep obsługuje mniej niż 50 000 wyświetleń stron dziennie, a serwer radzi sobie z obciążeniem komfortowo z modułem FPC, Varnish to niepotrzebna złożoność. Jeśli Twój sklep regularnie mierzy się ze skokami ruchu, które przeciążają serwer, obsługuje dużą ilość anonimowego ruchu przeglądania lub potrzebuje najszybszych możliwych czasów odpowiedzi dla SEO czy doświadczenia użytkownika, Varnish zapewnia poziom wydajności, którego żadne rozwiązanie buforowania oparte na PHP nie jest w stanie dorównać.

Zacznij od właściwej optymalizacji PrestaShop (optymalizacja zapytań, audyt modułów, PHP OPcache, optymalizacja obrazów) i modułu FPC. Jeśli te optymalizacje nie wystarczą, Varnish jest kolejnym krokiem na drabinie skalowania wydajności.

Przeczytaj pełną odpowiedź

Jak PrestaShop obsługuje obrazy produktów

Każdy obraz przesłany do PrestaShop przechodzi przez potok przetwarzania. Gdy dodajesz obraz produktu, system zapisuje oryginalny plik, a następnie generuje wiele zmniejszonych wersji zwanych miniaturkami. Każda miniaturka odpowiada typowi obrazu zdefiniowanemu w panelu administracyjnym w sekcji Wygląd > Ustawienia obrazów. Te typy obrazów określają dokładne wymiary w pikselach i są powiązane z konkretnymi kontekstami: listami produktów, stronami produktów, podglądami koszyka, nagłówkami kategorii, logami producentów i nie tylko.

PrestaShop przechowuje obrazy w katalogu /img/. W PrestaShop 1.7 i 8.x obrazy produktów są organizowane przy użyciu struktury katalogów opartej na identyfikatorze obrazu. Na przykład obraz o ID 1234 jest przechowywany w /img/p/1/2/3/4/. Wewnątrz tego katalogu znajdziesz oryginalny obraz (nazwany po ID, jak 1234.jpg) oraz wszystkie wygenerowane miniaturki (jak 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

Konwencja nazewnictwa jest następująca: {image_id}-{image_type_name}.{extension}. Oznacza to, że każdy zdefiniowany typ obrazu tworzy dodatkowy plik dla każdego obrazu produktu w katalogu. Sklep z 5000 obrazami produktów i 8 typami obrazów będzie miał około 45 000 plików obrazów (5000 oryginałów plus 5000 razy 8 miniaturek). Ta skala ma znaczenie, gdy trzeba je zregenerować.

Zrozumienie typów obrazów

Typy obrazów są zdefiniowane w tabeli bazy danych ps_image_type i zarządzane przez panel administracyjny. Każdy typ obrazu ma nazwę, szerokość, wysokość i flagi wskazujące, do jakich typów encji się stosuje (produkty, kategorie, producenci, dostawcy, sklepy). Domyślna instalacja PrestaShop zawiera kilka typów obrazów:

cart_default to zwykle 125x125 pikseli, używany w koszyku i mini koszyku. small_default to około 98x98 pikseli, używany w listach produktów w niektórych motywach. medium_default to około 452x452 piksele, używany dla miniaturek produktów na stronie produktu. home_default to około 250x250 pikseli, używany na stronie głównej i listach kategorii. large_default to około 800x800 pikseli, używany jako główny obraz produktu na stronie produktu.

Motywy mogą definiować własne wymagania dotyczące typów obrazów. Gdy instalujesz nowy motyw, zazwyczaj rejestruje on swoje preferowane typy obrazów podczas instalacji. Kluczowy punkt to to, że rzeczywiste pliki obrazów na dysku muszą odpowiadać temu, czego oczekuje motyw. Jeśli motyw żąda home_default w rozmiarze 340x340, ale Twoje pliki obrazów zostały wygenerowane w rozmiarze 250x250, ponieważ wcześniej używałeś innego motywu, każda lista produktów będzie wyświetlać obrazy o nieprawidłowych rozmiarach.

Kiedy regeneracja obrazów jest konieczna

Kilka sytuacji wymaga pełnej lub częściowej regeneracji miniaturek. Zrozumienie, kiedy jest to naprawdę konieczne, oszczędza czas na uruchamianiu procesu, który może trwać godzinami na dużych katalogach.

Zmiana motywu

To najczęstszy powód. Różne motywy wymagają różnych wymiarów obrazów. Gdy przełączasz się z jednego motywu na inny, szablony nowego motywu odwołują się do typów obrazów o konkretnych wymiarach. Jeśli te wymiary nie odpowiadają istniejącym plikom miniaturek, obrazy pojawiają się rozciągnięte, nieprawidłowo przycięte lub rozmazane. Po zainstalowaniu nowego motywu zawsze sprawdź jego wymagania dotyczące typów obrazów i zregeneruj miniaturki, aby pasowały.

Zmiana wymiarów typu obrazu

Jeśli zmodyfikujesz szerokość lub wysokość istniejącego typu obrazu poprzez Wygląd > Ustawienia obrazów, zmiana dotyczy tylko definicji w bazie danych. Wszystkie istniejące pliki miniaturek na dysku zachowują swoje stare wymiary. Musisz zregenerować miniaturki dla zmodyfikowanego typu obrazu, aby zastosować nowe wymiary do istniejących obrazów.

Dodawanie nowego typu obrazu

Gdy tworzysz nowy typ obrazu, żadne pliki miniaturek jeszcze dla niego nie istnieją. Jeśli szablon odwołuje się do tego nowego typu obrazu, wyświetli uszkodzone linki do obrazów, dopóki nie przeprowadzisz regeneracji. Proces regeneracji tworzy brakujące pliki miniaturek dla każdego istniejącego obrazu.

Problemy z jakością obrazów

Jeśli zmienisz ustawienie jakości kompresji JPEG w PrestaShop (znajdziesz je w Wydajność > Ustawienia obrazów lub sekcji konfiguracji obrazów w zależności od wersji), istniejące miniaturki zostały wygenerowane ze starym ustawieniem jakości. Regeneracja stosuje nowy poziom jakości do wszystkich miniaturek.

Po migracji lub przenoszeniu serwera

Czasami podczas migracji pliki miniaturek zostają utracone lub uszkodzone, podczas gdy oryginalne obrazy przetrwają. Jeśli obrazy produktów wyglądają na uszkodzone, ale oryginały istnieją w oczekiwanych katalogach, regeneracja odtwarza wszystkie miniaturki z oryginałów.

Włączanie formatu WebP

PrestaShop 8.x wprowadził obsługę WebP dla obrazów produktów. Gdy włączysz generowanie WebP, istniejące obrazy nie otrzymują automatycznie wariantów WebP. Musisz zregenerować miniaturki, aby utworzyć wersje .webp obok istniejących plików JPEG lub PNG.

Regeneracja przez panel administracyjny

PrestaShop udostępnia wbudowane narzędzie regeneracji w panelu administracyjnym w sekcji Wygląd > Ustawienia obrazów (lub Preferencje > Obrazy w starszych wersjach). Na dole strony znajdziesz sekcję regeneracji.

Dostępne opcje

Możesz wybrać usuwanie poprzednich obrazów przed regeneracją. Po włączeniu PrestaShop usuwa wszystkie istniejące miniaturki przed utworzeniem nowych. Jest to przydatne, gdy chcesz usunąć miniaturki dla typów obrazów, które już nie istnieją, ale oznacza, że wszystkie obrazy będą niedostępne podczas procesu regeneracji. Po wyłączeniu PrestaShop nadpisuje istniejące miniaturki i tworzy brakujące bez wcześniejszego usuwania czegokolwiek.

Możesz wybrać, które typy encji regenerować: produkty, kategorie, producentów, dostawców lub sklepy. Jeśli zmieniłeś tylko wymiary obrazów produktów, nie ma potrzeby regenerowania obrazów kategorii czy producentów.

Ograniczenia podejścia przez panel administracyjny

Regeneracja przez panel administracyjny działa jako żądanie webowe. Stwarza to kilka problemów dla dużych katalogów. Serwery WWW mają limity czasu wykonywania, zazwyczaj od 30 do 300 sekund w zależności od konfiguracji. Sklep z 10 000 obrazami produktów i 8 typami obrazów musi wygenerować 80 000 plików miniaturek. Nawet przy hojnym tempie 10 obrazów na sekundę zajmie to ponad dwie godziny. Większość serwerów WWW przerwie proces na długo przed jego zakończeniem.

Obowiązują także limity pamięci. Każdy obraz musi zostać załadowany do pamięci, przeskalowany przy użyciu GD lub ImageMagick i zapisany. Oryginalne obrazy o wysokiej rozdzielczości mogą zużywać od 20 do 50 MB pamięci podczas przetwarzania. Domyślny limit pamięci PHP wynoszący 128 MB lub 256 MB może zostać szybko wyczerpany, szczególnie przy przetwarzaniu obrazów sekwencyjnie bez odpowiedniego zwalniania pamięci.

Jeśli proces zostanie przerwany przez timeout lub błąd pamięci, kończysz z częściowo zregenerowanym katalogiem. Niektóre produkty mają nowe miniaturki, inne mają stare, a niektóre mogą nie mieć żadnych. Ten niespójny stan jest gorszy od pierwotnego problemu.

Regeneracja CLI dla dużych katalogów

Dla sklepów z więcej niż kilkuset produktami zdecydowanie zalecana jest regeneracja z linii poleceń. Omija ona limity czasu serwera WWW i może być skonfigurowana z wyższymi limitami pamięci.

Użycie konsoli PrestaShop

PrestaShop 1.7.5 i nowsze zawierają konsolę Symfony. Możesz regenerować miniaturki za pomocą:

php bin/console prestashop:image:regenerate

Polecenie to akceptuje kilka opcji. Aby regenerować tylko konkretne typy obrazów, użyj flagi --image-type z nazwą typu obrazu. Aby przetwarzać tylko produkty, kategorie lub inne konkretne typy encji, użyj flagi --entity. Flaga --format pozwala określić, które formaty wyjściowe generować (jpg, png, webp).

Uruchom polecenie z katalogu głównego PrestaShop. Jeśli używasz Dockera, wykonaj je wewnątrz kontenera:

docker exec -u www-data your-container php bin/console prestashop:image:regenerate

Flaga -u www-data zapewnia, że wygenerowane pliki są własnością użytkownika serwera WWW. Uruchamianie jako root tworzy pliki, których serwer WWW nie może serwować ani modyfikować później.

Konfiguracja pamięci i czasu

Przy wykonywaniu z CLI możesz zwiększyć limity PHP bezpośrednio w poleceniu:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Ustawienie max_execution_time=0 całkowicie usuwa limit czasu, a 512 MB pamięci jest wystarczające dla większości katalogów. Dla sklepów z ekstremalnie wysokorozdzielczymi oryginałami (4000x4000 pikseli lub więcej) możesz potrzebować 1 GB lub więcej.

Niestandardowe podejście do regeneracji

Dla bardzo dużych katalogów (50 000 lub więcej obrazów) nawet polecenie konsolowe może być powolne lub problematyczne. Niestandardowe podejście PHP pozwala przetwarzać obrazy w partiach ze śledzeniem postępu, obsługą błędów i możliwością wznowienia po przerwaniu.

Podejście polega na odpytaniu bazy danych o wszystkie rekordy obrazów, iterowaniu przez nie w partiach po 100 lub 200, generowaniu miniaturek dla każdego obrazu i rejestrowaniu postępu. Jeśli proces zostanie przerwany, można go wznowić od miejsca zatrzymania, sprawdzając, które miniaturki już istnieją.

Podejście partiowe umożliwia również rozłożenie regeneracji na wiele uruchomień w godzinach o niskim ruchu, unikając wpływu na wydajność działającego sklepu.

Generowanie WebP podczas regeneracji

WebP to nowoczesny format obrazu, który zapewnia znacznie mniejsze rozmiary plików niż JPEG przy porównywalnej jakości. PrestaShop 8.x może generować wersje WebP miniaturek podczas procesu regeneracji.

Włączanie obsługi WebP

Przed regeneracją włącz WebP w konfiguracji PrestaShop. W PrestaShop 8.x ta opcja znajduje się w ustawieniach obrazów. Po włączeniu proces regeneracji tworzy zarówno tradycyjną miniaturkę JPEG/PNG, jak i wersję .webp dla każdego typu obrazu.

Wymagania serwerowe

Generowanie WebP wymaga rozszerzenia GD skompilowanego z obsługą WebP (--with-webp) lub rozszerzenia ImageMagick z delegatami WebP. Możesz sprawdzić obsługę GD za pomocą phpinfo() lub gd_info(). Szukaj WebP Support w wynikach. Jeśli obsługa WebP jest niedostępna, proces regeneracji cicho pomija tworzenie WebP bez generowania błędów.

Rozważania dotyczące przestrzeni dyskowej

Pliki WebP są zazwyczaj o 25 do 35 procent mniejsze niż równoważne pliki JPEG, ale przechowujesz oba formaty. Sklep z 40 000 miniaturek JPEG zajmujących 2 GB przestrzeni dyskowej będzie potrzebował około 3,4 GB łącznie po wygenerowaniu WebP (oryginalne 2 GB plus około 1,4 GB plików WebP). Zaplanuj odpowiednio swoją przestrzeń dyskową przed rozpoczęciem pełnej regeneracji.

Serwowanie WebP przeglądarkom

Generowanie plików WebP to tylko połowa rozwiązania. Twój motyw i serwer muszą być skonfigurowane do serwowania WebP przeglądarkom, które go obsługują, z fallbackiem do JPEG/PNG dla przeglądarek, które tego nie robią. Jest to zazwyczaj obsługiwane przez elementy <picture> w szablonach motywu lub przez negocjację treści po stronie serwera przy użyciu nagłówka Accept.

W Apache możesz dodać reguły przepisywania, które sprawdzają obsługę WebP i serwują wersję WebP, gdy jest dostępna. W Nginx dyrektywa try_files może sprawdzić, czy istnieje wersja .webp żądanego obrazu i serwować ją, jeśli nagłówek Accept przeglądarki zawiera image/webp.

Wpływ na wydajność i łagodzenie skutków

Regeneracja obrazów jest intensywna pod względem procesora i obciążająca dla I/O. Na działającym sklepie może znacząco obniżyć wydajność, jeśli nie jest odpowiednio zarządzana.

Wpływ na procesor

Każda operacja zmiany rozmiaru obrazu wymaga załadowania oryginału do pamięci, wykonania algorytmu skalowania, zastosowania ustawień jakości/kompresji i zapisania wyniku na dysk. Sama operacja skalowania jest kosztowna obliczeniowo, szczególnie dla dużych obrazów zmniejszanych do małych miniaturek. Na środowisku hostingu współdzielonego może to nasycić procesor i spowolnić cały sklep.

Wpływ na I/O

Regeneracja odczytuje każdy oryginalny obraz i zapisuje wiele plików miniaturek. Na tradycyjnych dyskach twardych tworzy to znaczne obciążenie I/O. Na dyskach SSD wpływ jest znacznie mniejszy, ale nadal zauważalny na dużą skalę. Wzorzec I/O jest szczególnie nieprzyjazny dla dysków obrotowych, ponieważ obejmuje losowe odczyty (oryginały rozrzucone po katalogach) w połączeniu z sekwencyjnymi zapisami (miniaturki w tych samych katalogach).

Uruchamianie regeneracji w godzinach o niskim ruchu

Zaplanuj regenerację na okres o najniższym ruchu. Dla sklepów europejskich to zazwyczaj między 2:00 a 6:00 w nocy. Dla sklepów o globalnym ruchu może nie być prawdziwego okresu niskiego ruchu, ale możesz zidentyfikować relatywne punkty niskiego ruchu z danych analitycznych.

Użycie nice i ionice

Na serwerach Linux możesz obniżyć priorytet procesu regeneracji, aby nie pozbawiał innych procesów zasobów. Polecenie nice obniża priorytet procesora, a ionice obniża priorytet I/O:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Wartość nice 19 to najniższy priorytet. Klasa ionice 3 to klasa bezczynności (idle), co oznacza, że proces otrzymuje czas I/O tylko wtedy, gdy nic innego go nie potrzebuje. Drastycznie redukuje to wpływ na działający sklep, ale sprawia, że regeneracja trwa dłużej.

Tymczasowe skalowanie

Jeśli korzystasz z serwera w chmurze, rozważ tymczasowe zwiększenie mocy serwera (więcej rdzeni procesora, więcej RAM, szybsza pamięć masowa) na czas regeneracji, a następnie zmniejszenie. Dodatkowy koszt kilku godzin zasobów wyższego poziomu jest zazwyczaj minimalny w porównaniu z wpływem powolnej, wielodniowej regeneracji na wydajność sklepu.

Unikanie timeoutów podczas regeneracji

Timeouty to najczęstszy problem przy regeneracji obrazów. Oto konkretne ustawienia i konfiguracje, które im zapobiegają.

Konfiguracja PHP

Dyrektywa max_execution_time ogranicza czas działania procesu PHP. Dla wykonywania z CLI zazwyczaj jest już ustawiona na 0 (bez limitu), ale zweryfikuj to sprawdzając php -i | grep max_execution_time. Dla regeneracji webowej przez panel administracyjny zwiększ tę wartość w php.ini lub .htaccess:

php_value max_execution_time 7200

Zwiększ również max_input_time, jeśli używasz panelu administracyjnego, ponieważ timeout przesyłania formularza jest oddzielny od timeoutu wykonywania:

php_value max_input_time 7200

Timeout serwera WWW

Dyrektywa Apache Timeout oraz Nginx proxy_read_timeout / fastcgi_read_timeout mogą przerywać długotrwałe żądania nawet jeśli samo PHP nie przekroczyło timeoutu. Dla Apache: Timeout 7200. Dla Nginx dodaj do bloku server: fastcgi_read_timeout 7200; lub proxy_read_timeout 7200;.

Konfiguracja PHP-FPM

Jeśli używasz PHP-FPM (co robi większość nowoczesnych konfiguracji), request_terminate_timeout w konfiguracji puli może również zabijać długotrwałe procesy. Ustaw na 0, aby wyłączyć timeout, lub dopasuj do żądanego maksymalnego czasu wykonywania:

request_terminate_timeout = 7200

Timeouty Cloudflare i CDN

Jeśli Twój sklep jest za Cloudflare lub innym CDN, CDN ma własny timeout żądań (darmowy plan Cloudflare ma timeout 100 sekund). To sprawia, że regeneracja przez panel administracyjny za CDN jest praktycznie niemożliwa. Musisz użyć regeneracji CLI, ominąć CDN dla dostępu administracyjnego lub użyć rozwiązania, które przetwarza obrazy asynchronicznie.

Strategie regeneracji przyrostowej

Pełna regeneracja przetwarza każdy obraz w katalogu. Dla sklepów z dziesiątkami tysięcy obrazów może to trwać wiele godzin. Podejścia przyrostowe przetwarzają tylko te obrazy, które rzeczywiście potrzebują nowych miniaturek.

Selektywna regeneracja typu obrazu

Jeśli dodałeś lub zmodyfikowałeś tylko jeden typ obrazu, nie musisz regenerować wszystkich typów. Użyj opcji --image-type w poleceniu konsoli, aby celować tylko w konkretny typ obrazu, który się zmienił. Redukuje to pracę do jednej ósmej (lub jakiejkolwiek frakcji Twoich łącznych typów obrazów) pełnej regeneracji.

Przetwarzanie oparte na dacie

Jeśli musisz zregenerować miniaturki tylko dla ostatnio dodanych produktów (na przykład po naprawieniu problemu z przetwarzaniem obrazów), możesz odpytać bazę danych o obrazy dodane po konkretnej dacie i przetworzyć tylko te. Tabela ps_image domyślnie nie ma kolumny z datą, ale powiązana tabela ps_product ma pola date_add i date_upd, które można wykorzystać do identyfikacji niedawno zmodyfikowanych produktów.

Wykrywanie brakujących miniaturek

Zamiast regenerować wszystko, przeskanuj katalogi obrazów, aby znaleźć obrazy, którym brakuje konkretnych miniaturek, i zregeneruj tylko te. To najszybsze podejście, gdy dodałeś nowy typ obrazu lub gdy częściowa regeneracja została przerwana.

Logika jest prosta: dla każdego ID obrazu w bazie danych sprawdź, czy oczekiwany plik miniaturki istnieje na dysku. Jeśli nie — zregeneruj tylko tę miniaturkę. Zamienia to wielogodzinną pełną regenerację w ukierunkowany proces, który może zająć minuty.

Przetwarzanie równoległe

Dla bardzo dużych katalogów możesz podzielić zakres ID obrazów na fragmenty i przetwarzać je równolegle przy użyciu wielu procesów PHP. Na przykład jeden proces obsługuje ID obrazów od 1 do 10000, inny od 10001 do 20000 itd. Każdy proces działa niezależnie, a łączna przepustowość jest w przybliżeniu proporcjonalna do liczby równoległych procesów (ograniczona przez rdzenie procesora i przepustowość I/O).

Bądź ostrożny z przetwarzaniem równoległym i obciążeniem I/O dysku. Uruchamianie zbyt wielu procesów jednocześnie na tradycyjnym dysku twardym spowoduje rywalizację o I/O i faktycznie spowolni działanie. Na dyskach SSD 4 do 8 równoległych procesów zazwyczaj działa dobrze.

Rozważania dotyczące formatów obrazów

PrestaShop obsługuje JPEG, PNG i GIF jako formaty źródłowe i może generować miniaturki w tych formatach plus WebP. Format źródłowy wpływa na zachowanie regeneracji.

Obrazy JPEG

JPEG jest najczęstszym formatem dla zdjęć produktów. Obsługuje kompresję stratną, co oznacza, że za każdym razem, gdy JPEG jest zapisywany, pewna jakość jest tracona. Dlatego regeneracja miniaturek z oryginalnych przesyłanych plików daje lepsze wyniki niż regeneracja z wcześniej przeskalowanych miniaturek. Zawsze upewnij się, że pracujesz z oryginalnym przesłanym obrazem, a nie wcześniej wygenerowaną miniaturką.

Obrazy PNG

PNG obsługuje przezroczystość i kompresję bezstratną. Jeśli Twoje obrazy produktów używają przezroczystych teł, miniaturki PNG zachowują tę przezroczystość. Jednak pliki PNG są zazwyczaj znacznie większe niż pliki JPEG. Zastanów się, czy faktycznie potrzebujesz przezroczystości. Jeśli nie, konwersja obrazów produktów PNG do JPEG podczas regeneracji może znacznie zmniejszyć przestrzeń dyskową i poprawić czasy ładowania stron.

Obsługa GIF

PrestaShop może przyjmować przesyłane pliki GIF, ale wygenerowane miniaturki ze źródeł GIF są statyczne (animacja nie jest zachowywana). Jeśli masz animowane obrazy produktów GIF, pamiętaj, że regeneracja produkuje statyczne miniaturki z pierwszej klatki.

Weryfikacja po regeneracji

Po zakończeniu regeneracji zweryfikuj wyniki przed założeniem, że wszystko jest poprawne.

Kontrola wyrywkowa jakości obrazów

Otwórz kilka stron produktów i wizualnie sprawdź obrazy. Upewnij się, że miniaturki są ostre, prawidłowo proporcjonalne i nie są rozciągnięte ani pikselowe. Zwróć szczególną uwagę na obrazy, które były pierwotnie małe (bliskie lub mniejsze od wymiarów miniaturki), ponieważ te mają największe szanse na problemy z jakością przy powiększaniu.

Weryfikacja liczby plików

Porównaj liczbę wygenerowanych miniaturek z oczekiwaniami. Jeśli masz 5000 obrazów produktów i 8 typów obrazów, powinieneś mieć około 40 000 plików miniaturek (plus oryginały i potencjalnie warianty WebP). Znacząco niższa liczba wskazuje, że proces regeneracji został przerwany lub napotkał błędy na niektórych obrazach.

Sprawdzenie uprawnień plików

Upewnij się, że zregenerowane pliki są własnością użytkownika serwera WWW (zazwyczaj www-data na Debian/Ubuntu lub apache na CentOS). Jeśli uruchomiłeś regenerację jako root, pliki mogą być nieczytelne dla serwera WWW, powodując uszkodzone obrazy na froncie sklepu. Napraw za pomocą: chown -R www-data:www-data img/p/.

Czyszczenie cache

Po regeneracji wyczyść wszystkie cache. Obejmuje to wewnętrzną pamięć podręczną PrestaShop (Zaawansowane parametry > Wydajność), wszelką pamięć podręczną opcode (OPcache) i wszelką pamięć podręczną CDN lub reverse proxy. Stare buforowane strony mogą nadal odwoływać się do starych URL-i lub wymiarów obrazów. Jeśli używasz modułu, który generuje sprite'y CSS lub obrazy inline, zregeneruj je również.

Jeśli Twój sklep jest za Cloudflare, wyczyść cache dla ścieżki /img/ lub wykonaj pełne czyszczenie cache. Cloudflare agresywnie buforuje obrazy i odwiedzający mogą widzieć stare miniaturki, dopóki cache CDN nie wygaśnie lub nie zostanie wyczyszczony.

Rozwiązywanie typowych problemów z regeneracją

Czarne lub uszkodzone miniaturki

Zazwyczaj wskazuje to na problem z biblioteką GD. Rozszerzenie GD może nie obsługiwać formatu źródłowego (na przykład GD skompilowane bez obsługi JPEG). Zweryfikuj możliwości GD za pomocą gd_info(). Inną przyczyną jest niewystarczająca ilość pamięci: jeśli PHP nie może przydzielić wystarczającej pamięci do załadowania oryginalnego obrazu, GD może wyprodukować czarny obraz zamiast zgłosić błąd.

Błędne wymiary wygenerowanych miniaturek

Jeśli miniaturki mają nieoczekiwane wymiary, sprawdź definicje typów obrazów w bazie danych. Panel administracyjny może pokazywać jedną wartość, podczas gdy baza danych zawiera inną (może się to zdarzyć po nieudanym imporcie lub ręcznej modyfikacji bazy danych). Odpytaj bezpośrednio: SELECT * FROM ps_image_type WHERE name = 'home_default';

Regeneracja zawiesza się bez postępu

Zawieszony proces regeneracji zazwyczaj oznacza, że napotkał bardzo duży obraz, który wyczerpał dostępną pamięć. Sprawdź log błędów PHP pod kątem błędów alokacji pamięci. Rozwiązaniem jest zwiększenie limitu pamięci lub wstępne przetworzenie problematycznych obrazów źródłowych w celu zmniejszenia ich rozdzielczości przed regeneracją.

Błędy odmowy uprawnień

Jeśli regeneracja zgłasza błędy uprawnień, proces PHP nie może zapisywać do katalogów obrazów. Zdarza się to powszechnie w środowiskach Docker, gdzie wolumeny montowane przez bind mają różną własność wewnątrz i na zewnątrz kontenera. Upewnij się, że użytkownik uruchamiający polecenie regeneracji ma uprawnienia do zapisu w całym drzewie katalogów /img/.

Podsumowanie

Regeneracja obrazów to zadanie konserwacyjne, z którym spotyka się każdy właściciel sklepu PrestaShop, zazwyczaj podczas zmiany motywu lub optymalizacji ustawień obrazów. Dla małych katalogów (poniżej 500 produktów) narzędzie panelu administracyjnego działa adekwatnie. Dla czegokolwiek większego regeneracja CLI jest jedynym niezawodnym podejściem. Kluczowe zasady to: zawsze pracuj z oryginalnymi obrazami, dopasuj definicje typów obrazów do wymagań motywu, zarządzaj proaktywnie zasobami serwera i timeoutami, stosuj podejścia przyrostowe gdy to możliwe i weryfikuj wyniki po zakończeniu procesu. Z WebP stającym się standardem dla obrazów webowych, regeneracja służy również jako mechanizm tworzenia wariantów w nowoczesnych formatach całego katalogu produktów, zapewniając mniejsze rozmiary plików i szybsze ładowanie stron dla Twoich klientów.

Przeczytaj pełną odpowiedź

Macierz kompatybilności wersji PHP dla PrestaShop

Wybór odpowiedniej wersji PHP dla Twojego sklepu PrestaShop to jedna z najważniejszych decyzji infrastrukturalnych, jakie podejmiesz. Uruchomienie niekompatybilnej wersji PHP może spowodować białe ekrany, niedziałające procesy płatności, awarie modułów i luki w zabezpieczeniach. Ten kompleksowy przewodnik obejmuje każdą wersję PrestaShop od 1.6 do 9.x i przyporządkowuje każdą z nich do obsługiwanych wersji PHP, zalecanych konfiguracji i kwestii aktualizacji.

Dlaczego wersja PHP ma znaczenie dla PrestaShop

PHP to serwerowy język programowania, który napędza PrestaShop. Każda główna wersja PHP wprowadza poprawki wydajności, nowe funkcjonalności języka i wycofuje starsze funkcje. Kod źródłowy PrestaShop ewoluuje równolegle z PHP, co oznacza, że nowsze wersje PrestaShop wykorzystują nowoczesne funkcje PHP, jednocześnie rezygnując ze wsparcia dla przestarzałych wersji.

Używanie niewłaściwej wersji PHP powoduje trzy kategorie problemów:

Błędy fatalne - Funkcje usunięte w nowszych wersjach PHP (np. funkcje mysql_* usunięte w PHP 7.0, each() usunięta w PHP 8.0) powodują natychmiastowe awarie.
Ostrzeżenia o wycofaniu - Wycofane funkcje generują ostrzeżenia, które mogą uszkodzić odpowiedzi AJAX, wyjście JSON i generowanie PDF, gdy display_errors jest włączone.
Narażenie na zagrożenia bezpieczeństwa - Wersje PHP, które osiągnęły koniec życia, nie otrzymują już łatek bezpieczeństwa, pozostawiając Twój sklep podatnym na ataki.

Pełna macierz kompatybilności

PrestaShop 1.6.x

Wersja PrestaShop	PHP 5.4	PHP 5.5	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2+
1.6.0.x - 1.6.0.14	Tak	Tak	Tak	Nie	Nie	Nie
1.6.1.0 - 1.6.1.4	Tak	Tak	Tak	Częściowo	Nie	Nie
1.6.1.5 - 1.6.1.23	Tak	Tak	Tak	Tak	Tak	Nie
1.6.1.24+	Tak	Tak	Tak	Tak	Tak	Nie

Zalecane PHP dla 1.6.x - PHP 7.1. Oferuje najlepszą równowagę między wydajnością a kompatybilnością. Uruchamianie 1.6.x na PHP 7.2+ wymaga modyfikacji plików rdzeniowych, co przerywa ścieżkę aktualizacji i nie jest zalecane.

PrestaShop 1.7.x

Wersja PrestaShop	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0+
1.7.0.x - 1.7.4.x	Tak (zalecane)	Nie	Nie	Nie	Nie
1.7.5.x	Tak	Tak (zalecane)	Nie	Nie	Nie
1.7.6.x	Tak	Tak (zalecane)	Tak	Nie	Nie
1.7.7.x	Tak	Tak	Tak (zalecane)	Częściowo	Nie
1.7.8.x	Tak	Tak	Tak	Tak (zalecane)	Nie

Krytyczne ostrzeżenie - Żadna wersja PrestaShop 1.7 nie obsługuje PHP 8.0 ani nowszego. Jeśli uruchomisz PS 1.7.6 na PHP 8, Smarty natychmiast się zawiesi, ponieważ silnik szablonów używa funkcji usuniętych w PHP 8.0. Usunięcie funkcji each() i zmiany w działaniu array_key_exists() z obiektami powodują błędy fatalne.

PrestaShop 8.x

Wersja PrestaShop	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.1	PHP 8.2	PHP 8.3
8.0.0 - 8.0.2	Tak (min)	Tak	Tak	Tak	Częściowo	Nie	Nie
8.0.3 - 8.0.5	Tak (min)	Tak	Tak	Tak	Tak (zalecane)	Nie	Nie
8.1.0 - 8.1.2	Nie	Tak (min)	Tak	Tak	Tak (zalecane)	Częściowo	Nie
8.1.3 - 8.1.7	Nie	Tak (min)	Tak	Tak	Tak (zalecane)	Tak	Częściowo

Zalecane PHP dla 8.x - PHP 8.1. Jest to optimum oferujące pełną kompatybilność, aktywne wsparcie bezpieczeństwa i doskonałą wydajność z kompilacją JIT. PHP 8.1 wprowadza Fibers, Enums, właściwości readonly i typy intersection, z których PrestaShop 8 może korzystać.

PrestaShop 9.x

Wersja PrestaShop	PHP 8.1	PHP 8.2	PHP 8.3	PHP 8.4
9.0.x	Tak (min)	Tak	Tak (zalecane)	Tak

Zalecane PHP dla 9.x - PHP 8.3 lub 8.4. PrestaShop 9 działa na Symfony 6.4 LTS i wymaga PHP 8.1 jako minimum. PHP 8.4 wprowadza Property Hooks i asymetryczną widoczność, które przyszłe aktualizacje PrestaShop będą wykorzystywać.

Daty zakończenia wsparcia PHP, które musisz znać

Wersja PHP	Aktywne wsparcie do	Poprawki bezpieczeństwa do	Status (2026)
PHP 7.4	Lis 2021	Lis 2022	EOL - Niebezpieczny
PHP 8.0	Lis 2022	Lis 2023	EOL - Niebezpieczny
PHP 8.1	Lis 2023	Gru 2025	EOL - Aktualizuj wkrótce
PHP 8.2	Gru 2024	Gru 2026	Tylko bezpieczeństwo
PHP 8.3	Gru 2025	Gru 2027	Tylko bezpieczeństwo
PHP 8.4	Gru 2026	Gru 2028	Aktywne wsparcie

Jeśli w 2026 roku używasz PHP 7.4 lub 8.0, pracujesz na niewspieranej wersji, która nie otrzymuje już poprawek bezpieczeństwa. Jest to krytyczne ryzyko dla każdego sklepu e-commerce obsługującego dane płatnicze.

Jak sprawdzić aktualną wersję PHP

Metoda 1 - Panel administracyjny PrestaShop

Przejdź do Zaawansowane > Informacje. Sekcja Informacje o serwerze wyświetla Twoją wersję PHP wraz z limitem pamięci, maksymalnym czasem wykonania i innymi istotnymi ustawieniami.

Metoda 2 - Plik PHP Info

Utwórz plik o nazwie phpinfo.php w katalogu głównym sklepu o następującej treści:

<?php phpinfo();

Uzyskaj do niego dostęp przez przeglądarkę pod adresem https://twojsklep.com/phpinfo.php. Usuń ten plik natychmiast po sprawdzeniu - ujawnia wrażliwe szczegóły konfiguracji serwera.

Metoda 3 - Linia poleceń

php -v
php -r "echo PHP_VERSION;"

Pamiętaj, że wersja PHP CLI może różnić się od wersji PHP serwera web. Zawsze weryfikuj przez interfejs webowy lub phpinfo().

Typowe problemy przy nieprawidłowej wersji PHP

Biały ekran śmierci (WSOD)

Najczęstszy objaw niekompatybilności PHP. Sprawdź log błędów PHP (zazwyczaj pod /var/log/php-errors.log lub dostępny przez panel hostingowy). Typowe błędy to:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Ostrzeżenia o wycofaniu psują AJAX

Gdy display_errors = On i aktualizujesz PHP, ostrzeżenia o wycofaniu są dołączane do odpowiedzi AJAX. To psuje parsowanie JSON w panelu administracyjnym, powodując ciche awarie funkcji takich jak wyszukiwanie produktów, wyszukiwanie klientów i tworzenie zamówień. Rozwiązanie:

; php.ini
display_errors = Off
log_errors = On
error_log = /sciezka/do/php-error.log

Niekompatybilność modułów

Moduły firm trzecich mogą nie obsługiwać Twojej wersji PHP. Przed aktualizacją PHP sprawdź kompatybilność każdego zainstalowanego modułu. Typowe problematyczne obszary:

Moduły używające create_function() - usunięta w PHP 8.0
Moduły używające funkcji mysql_* - usunięte w PHP 7.0
Moduły używające pozycyjnego dostępu do ciągów z nawiasami klamrowymi $str{0} - usunięte w PHP 8.0
Moduły nieobsługujące nullable typów zwracanych - bardziej restrykcyjne od PHP 8.1+

Jak bezpiecznie zaktualizować PHP dla PrestaShop

Krok 1 - Audyt aktualnej konfiguracji

Zanim cokolwiek zmienisz, udokumentuj swoje obecne środowisko:

php -v                    # Aktualna wersja PHP
php -m                    # Załadowane rozszerzenia
php -i | grep memory      # Limit pamięci
php -i | grep max_exec    # Limit czasu wykonania

Krok 2 - Sprawdź kompatybilność modułów

Przejrzyj każdy zainstalowany moduł. Sprawdź dokumentację dewelopera modułu pod kątem obsługi wersji PHP. Jeśli moduł nie był aktualizowany od ponad dwóch lat, prawdopodobnie jest niekompatybilny z PHP 8.x.

Krok 3 - Najpierw przetestuj na stagingu

Nigdy nie aktualizuj PHP na serwerze produkcyjnym bez testów. Utwórz kopię staging swojego sklepu i przetestuj z nową wersją PHP. Sprawdź:

Strony front office ładują się prawidłowo
Strony produktów, kategorii, strony CMS
Proces koszyka i zamówienia kończy się poprawnie
Moduły płatności przetwarzają transakcje testowe
Funkcjonalność back office działa (edycja produktów, zarządzanie zamówieniami)
Wszystkie moduły firm trzecich działają prawidłowo
Zadania cron wykonują się bez błędów

Krok 4 - Aktualizacja z planem wycofania

Większość dostawców hostingu pozwala na zmianę wersji PHP z panelu sterowania (cPanel, Plesk, DirectAdmin). Zachowaj poprzednią wersję PHP dostępną do szybkiego wycofania, jeśli pojawią się problemy.

Krok 5 - Wyczyść wszystkie cache po aktualizacji

Po zmianie wersji PHP wyczyść każdą warstwę cache:

# Wyczyść cache PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Wyczyść skompilowane szablony Smarty
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Jeśli używasz OPcache, uruchom ponownie PHP-FPM
systemctl restart php8.3-fpm

# Wyczyść cache CDN (Cloudflare, itp.)

Najlepsze praktyki konfiguracji PHP dla PrestaShop

Niezależnie od wybranej wersji PHP, te ustawienia są niezbędne dla optymalnej wydajności PrestaShop:

; Zalecane ustawienia php.ini
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Ustawienia OPcache (krytyczne dla wydajności)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Wymagane rozszerzenia
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Uwagi dla deweloperów modułów

Jeśli rozwijasz moduły PrestaShop, musisz starannie rozważyć kompatybilność PHP:

Minimalna wersja PHP - Celuj w PHP 7.2 jako minimum dla modułów, które powinny działać na PrestaShop 8.0+, lub PHP 8.1 dla modułów przeznaczonych wyłącznie dla PrestaShop 9.
Używaj PHPStan lub Psalm - Narzędzia analizy statycznej wykrywają niekompatybilności wersji PHP, zanim zrobią to Twoi użytkownicy.
Unikaj składni specyficznej dla wersji - Funkcjonalności takie jak wyrażenia match (PHP 8.0), enums (PHP 8.1) i właściwości readonly (PHP 8.1) ograniczają Twój moduł do tych wersji PHP i wyższych.
Testuj na wielu wersjach - Używaj kontenerów Docker z różnymi wersjami PHP, aby testować moduł na całym zakresie kompatybilności.

Często zadawane pytania

Czy mogę uruchomić PrestaShop 1.7 na PHP 8?

Nie. Żadna wersja PrestaShop 1.7 oficjalnie nie obsługuje PHP 8.0 ani nowszego. Chociaż niektórzy użytkownicy zastosowali łatki, aby częściowo to uruchomić, nie jest to wspierane i będzie powodować problemy przy aktualizacjach. Właściwą drogą jest migracja do PrestaShop 8.x.

Czy powinienem używać PHP 8.4 z PrestaShop 8.1?

Niezalecane. PrestaShop 8.1 został opracowany i przetestowany głównie z PHP 8.1. Chociaż PHP 8.2 jest częściowo obsługiwany w późniejszych wersjach 8.1.x, PHP 8.4 wprowadza zmiany, które mogą powodować problemy ze starszymi komponentami Symfony. Pozostań przy PHP 8.1 dla PrestaShop 8.x.

O ile szybszy jest PHP 8.x w porównaniu z 7.x?

Benchmarki pokazują, że PHP 8.1 jest około 20-30% szybszy niż PHP 7.4 dla typowych obciążeń PrestaShop. Kompilator JIT zapewnia największą korzyść przy zadaniach obliczeniowych. Dla operacji związanych z I/O (zapytania do bazy danych, odczyt plików) poprawa jest mniejsza, ale nadal mierzalna.

Czy aktualizacja PHP wymaga aktualizacji PrestaShop?

Niekoniecznie, ale obie rzeczy idą w parze. Możesz zaktualizować PHP w obsługiwanym zakresie dla swojej wersji PrestaShop bez aktualizacji samego PrestaShop. Jednak jeśli chcesz używać nowoczesnej wersji PHP (8.3+), będziesz potrzebować PrestaShop 8.1 lub 9.x.

Przeczytaj pełną odpowiedź

Lazy Loading w 2026: co przeglądarki obsługują natywnie, a co wymaga modułu

Lazy loading to technika optymalizacji wydajności, która odwleka ładowanie zasobów poza ekranem do momentu, gdy użytkownik przewinie w ich pobliże. W 2026 roku natywne wsparcie przeglądarek dla lazy loadingu znacząco dojrzało, ale wciąż istnieją scenariusze, w których właściciele sklepów PrestaShop potrzebują dodatkowych modułów lub niestandardowych implementacji. Ten przewodnik wyjaśnia dokładnie, co przeglądarki obsługują samodzielnie, jakie luki pozostają i jak wdrożyć najlepszą strategię lazy loading dla Twojego sklepu PrestaShop.

Co natywny lazy loading obejmuje w 2026

Atrybut HTML loading="lazy" jest teraz obsługiwany przez ponad 95% przeglądarek na świecie. Obejmuje to Chrome (od v77), Firefox (od v75), Safari (od v15.4), Edge (od v79) i wszystkie przeglądarki oparte na Chromium.

Jak działa natywny lazy loading

Dodanie loading="lazy" do tagu <img> lub <iframe> mówi przeglądarce, aby odroczyła ładowanie tego zasobu do momentu, gdy znajdzie się w określonej odległości od viewportu.

<img src="obraz-produktu.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nazwa produktu">

Co przeglądarki obsługują natywnie

Funkcja	Natywne wsparcie	Uwagi
Obrazy (`<img>`)	Tak - wszystkie główne przeglądarki	Użyj `loading="lazy"`
Iframes (`<iframe>`)	Tak	Użyj `loading="lazy"`
Responsywne obrazy (`<picture>`)	Tak	`loading="lazy"` na wewnętrznym `<img>`
Obrazy srcset	Tak	Działa z `loading="lazy"`

Czego przeglądarki NIE obsługują

Funkcja	Natywne wsparcie	Potrzebne rozwiązanie
Obrazy tła CSS	Nie	IntersectionObserver API lub moduł
Elementy wideo	Nie	Niestandardowy JavaScript lub moduł
Efekty placeholder/blur-up	Nie	Biblioteka JavaScript lub moduł
Dynamicznie ładowana treść/AJAX	Nie	Lazy loading oparty na JavaScript

Implementacja natywnego lazy loadingu w PrestaShop

Dla motywów PrestaShop 8.x i 9.x

Nowoczesne motywy PrestaShop (jak Hummingbird dla PS 9) często zawierają natywny lazy loading domyślnie. Aby zweryfikować lub dodać go do swojego motywu, edytuj pliki szablonów.

{* Przed - bez lazy loadingu *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Po - z natywnym lazy loadingiem *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Krytyczna zasada: nigdy nie stosuj lazy loading do obrazów above-the-fold

Najczęstszym błędem lazy loadingu jest stosowanie go do obrazów widocznych bez przewijania. To w rzeczywistości pogarsza wydajność, ponieważ przeglądarka opóźnia ładowanie treści, które użytkownik widzi natychmiast.

Obrazy, które NIE powinny być lazy ładowane:

Logo Twojego sklepu
Obrazy hero/baner na górze strony
Pierwsze 1-2 obrazy produktów na stronach kategorii

<img src="hero-baner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Baner letniej wyprzedaży">

Kiedy potrzebujesz modułu: obrazy tła CSS

Motywy PrestaShop często używają obrazów tła CSS dla sliderów, banerów i nagłówków kategorii. Atrybut loading="lazy" nie działa dla teł CSS.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Kiedy potrzebujesz modułu: efekty placeholder

Efekt blur-up (LQIP) - Załaduj najpierw małą, rozmytą wersję
Ekrany szkieletowe - Szare bloki placeholder odpowiadające wymiarom
Placeholdery dominującego koloru - Użyj dominującego koloru obrazu jako tła

Wpływ na wydajność PrestaShop i Core Web Vitals

LCP - Lazy loading obrazów above-the-fold POGARSZA LCP
CLS - Obrazy bez atrybutów width/height powodują przesunięcia układu
INP - Mniej jednocześnie ładowanych zasobów poprawia interaktywność

<!-- ŹLE - powoduje przesunięcie układu -->
<img src="produkt.jpg" loading="lazy" alt="Produkt">

<!-- DOBRZE - rezerwuje miejsce -->
<img src="produkt.jpg" loading="lazy" 
     width="400" height="400" alt="Produkt">

Rekomendacje specyficzne dla PrestaShop

Strony z listą produktów

Lazy ładuj wszystkie obrazy produktów oprócz pierwszego rzędu. Zastosuj fetchpriority="high" do pierwszego rzędu.

Strony szczegółów produktu

Główny obraz produktu powinien być ładowany eager z fetchpriority="high". Miniatury galerii mogą być lazy ładowane.

Strona główna

Obrazy slidera above the fold powinny być ładowane eager. Bloki modułów below the fold powinny używać lazy loadingu.

Podsumowanie: Moduł vs. Natywny

Scenariusz	Rozwiązanie
Standardowe obrazy produktów	Natywne `loading="lazy"` - bez modułu
Obrazy tła CSS	Moduł lub JS z IntersectionObserver
Placeholdery blur-up/LQIP	Moduł lub biblioteka JS
Lazy loading wideo	Niestandardowy JS
Osadzenia YouTube/Vimeo	Natywne `loading="lazy"` na iframe
Obrazy treści CMS	Moduł do automatycznego dodawania atrybutu

Przeczytaj pełną odpowiedź

Przekierowania .htaccess w PrestaShop: pisanie regul bez psucia sklepu

Plik .htaccess jest jednym z najpotezniejszych i najbardziej niebezpiecznych plikow w Twojej instalacji PrestaShop. Jeden zle umieszczony znak moze wylaczyc caly Twoj sklep. Ale opanowanie przekierowan .htaccess jest niezbedne dla SEO.

Jak PrestaShop uzywa .htaccess

PrestaShop automatycznie generuje i zarzadza plikiem .htaccess. Gdy wlaczysz przyjazne URLe w ustawieniach SEO i URLe, PrestaShop zapisuje reguly przepisywania miedzy dwoma komentarzami znacznikowymi.

Krytyczna zasada - Nigdy nie dodawaj niestandardowych przekierowan wewnatrz tego bloku. PrestaShop nadpisze je przy nastepnej regeneracji. Umieszczaj swoje reguly PRZED blokiem PrestaShop.

Typy przekierowan

301 - Przekierowanie stale

Uzywaj gdy strona zostala trwale przeniesiona. Wyszukiwarki przenoszą wartosc SEO na nowy URL.

302 - Przekierowanie tymczasowe

Uzywaj gdy strona jest tymczasowo niedostepna.

410 - Gone (Usuniety)

Uzywaj gdy strona zostala trwale usunieta bez zamiennika.

Podstawowa skladnia przekierowan

# Przekieruj pojedynczy URL
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# Przekieruj stary URL produktu
Redirect 301 /stary-produkt.html https://twojsklep.com/pl/nowy-produkt.html

Przekierowania oparte na wzorcach z RewriteRule

RewriteEngine On
RewriteRule ^stary-folder/(.*)$ https://twojsklep.com/nowy-folder/$1 [R=301,L]

Typowe scenariusze przekierowan PrestaShop

Scenariusz 1 - Migracja z innej platformy

# WooCommerce do PrestaShop
RewriteRule ^product/stary-slug/?$ https://twojsklep.com/pl/nowy-url.html [R=301,L]

Scenariusz 2 - Wymuszenie HTTPS i WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Reguly ktore moga zepsuc PrestaShop

Nieskonczone petle przekierowan

Najniebezpieczniejszy blad. Zawsze uzywaj warunkow do zapobiegania petlom.

# NIEBEZPIECZNE
RewriteRule ^(.*)$ https://twojsklep.com/$1 [R=301,L]

# BEZPIECZNE
RewriteCond %{HTTP_HOST} !^www\.twojsklep\.com$ [NC]
RewriteRule ^(.*)$ https://www.twojsklep.com/$1 [R=301,L]

Psucie dostepu do back office

# BEZPIECZNE - wyklucz admin i API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules [NC]
RewriteRule ^(.*)$ https://twojsklep.com/pl/$1 [R=301,L]

Bezpieczne testowanie przekierowan

# Zawsze najpierw zrob kopie
cp .htaccess .htaccess.backup

# Testuj z curl
curl -I -L https://twojsklep.com/stara-strona.html

Gdzie umieszczac niestandardowe reguly

# TWOJE PRZEKIEROWANIA TUTAJ (przed blokiem PrestaShop)
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# ~~start~~ Blok PrestaShop
# ... automatycznie generowane reguly ...
# ~~end~~ Blok PrestaShop

Kiedy uzywac modulu

Rozwaz modul przekierowan gdy nietechniczny personel musi zarzadzac przekierowaniami, masz setki przekierowan lub potrzebujesz automatycznego wykrywania 404.

Przeczytaj pełną odpowiedź

Metoda	Chroni przed	Koszt
.htaccess	Znane scrapery	Bezplatnie
fail2ban	Brute force	Bezplatnie
Nginx	Nadmierne zapytania	Bezplatnie
CAPTCHA	Spam	Bezplatnie
Cloudflare Free	Boty, DDoS	Bezplatnie

Jak dzialaja szablony e-mail PrestaShop

PrestaShop wysyla e-maile transakcyjne w kazdym kluczowym momencie sciezki klienta: utworzenie konta, potwierdzenie zamowienia, powiadomienie o wysylce, reset hasla i inne. Te e-maile sa generowane z plikow szablonow przechowywanych na serwerze i sa w pelni konfigurowalne. Zrozumienie dzialania systemu szablonow to pierwszy krok do tworzenia profesjonalnych, markowych e-maili z potwierdzeniem zamowienia, ktore wzmacniaja tozsamosc Twojego sklepu.

Kazdy e-mail PrestaShop sklada sie z dwoch plikow szablonow: wersji HTML dla klientow pocztowych obslugujecych formatowanie oraz wersji tekstowej (TXT) dla klientow, ktore tego nie obsluguja. Oba pliki musza istniec, aby e-mail zostal wyslany poprawnie. Wersje HTML zobaczy zdecydowana wiekszosc klientow. Wersja TXT sluzy jako rozwiazanie awaryjne i jest rowniez uzywana przez narzedzia dostepnosci oraz niektore firmowe filtry pocztowe.

Szablony e-mail znajduja sie w strukturze katalogow mails/. Dokladna lokalizacja zalezy od tego, czy uzywasz e-maili rdzenia, e-maili nadpisanych przez motyw, czy e-maili specyficznych dla modulow. Zrozumienie tej hierarchii jest kluczowe, poniewaz PrestaShop sprawdza wiele lokalizacji dla kazdego szablonu i uzywa pierwszego znalezionego.

Struktura katalogow szablonow e-mail

PrestaShop organizuje szablony e-mail w specyficznej hierarchii katalogow. Gdy musi wyslac e-mail, przeszukuje te lokalizacje w kolejnosci priorytetu:

Nadpisania na poziomie motywu (najwyzszy priorytet)

Szablony w /themes/twoj-motyw/mails/pl/ (gdzie pl to kod ISO jezyka) maja priorytet nad wszystkimi innymi lokalizacjami. Jesli chcesz dostosowac szablon e-mail bez modyfikowania plikow rdzenia, tutaj powinny trafic Twoje niestandardowe szablony. Takie podejscie przetrwa aktualizacje PrestaShop, poniewaz pliki motywu nie sa nadpisywane podczas aktualizacji rdzenia.

Szablony rdzenia (domyslne)

Domyslne szablony znajduja sie w /mails/pl/ w katalogu glownym PrestaShop. Sa to szablony dostarczane z PrestaShop i uzywane, gdy nie istnieje nadpisanie motywu. Bezposrednia edycja tych plikow dziala, ale nie jest zalecana, poniewaz zmiany zostana utracone po aktualizacji PrestaShop.

Szablony specyficzne dla modulow

Moduly wysylajace wlasne e-maile przechowuja szablony w /modules/nazwa-modulu/mails/pl/. Na przyklad e-maile z powiadomieniami o zamowieniach wysylane przez rdzennie moduly platnosci sa przechowywane w ich odpowiednich katalogach modulow. Mozesz je nadpisac, umieszczajac zmodyfikowane kopie w katalogu mails/ motywu z ta sama nazwa pliku.

Podkatalogi jezykowe

Kazdy katalog mails/ zawiera podkatalogi dla kazdego zainstalowanego jezyka, uzywajac kodu ISO jezyka: en dla angielskiego, fr dla francuskiego, de dla niemieckiego i tak dalej. Gdy PrestaShop wysyla e-mail, uzywa szablonu z katalogu odpowiadajacego preferencji jezykowej klienta. Jesli szablon nie istnieje w jezyku klienta, PrestaShop wraca do jezyka domyslnego.

Anatomia szablonu potwierdzenia zamowienia

E-mail z potwierdzeniem zamowienia to najwazniejszy e-mail transakcyjny wysylany przez Twoj sklep. To plik o nazwie order_conf.html (i towarzyszacy mu order_conf.txt) w katalogu mails. Przyjrzyjmy sie jego strukturze.

Struktura szablonu HTML

Szablony e-mail PrestaShop sa samodzielnymi dokumentami HTML. Nie uzywaja zewnetrznych plikow CSS, poniewaz wiekszosc klientow pocztowych usuwa zewnetrzne arkusze stylow. Wszystkie style musza byc inline CSS. Typowy szablon potwierdzenia zamowienia zawiera nastepujace sekcje:

Dokument zaczyna sie od standardowego doctype HTML i sekcji head. Body zawiera uklad oparty na tabelach (poniewaz klienty pocztowe maja slaba obsluge nowoczesnych metod ukladu CSS jak flexbox i grid). W tym ukladzie znajdziesz sekcje naglowka z logo sklepu, glowny obszar tresci ze szczegolami zamowienia, tabele produktow z kazdym zamowionym produktem, podsumowanie cen z sumami czesciowymi i calkowitymi, informacje o wysylce, szczegoly metody platnosci oraz stopke z danymi kontaktowymi sklepu i informacjami prawnymi.

System zmiennych

PrestaShop uzywa prostego systemu zamiany zmiennych w szablonach e-mail. Zmienne sa ujete w nawiasy klamrowe: {nazwa_zmiennej}. Gdy e-mail jest generowany, PrestaShop zastepuje kazda zmienna jej rzeczywista wartoscia. Szablon potwierdzenia zamowienia uzywa tych kluczowych zmiennych:

{firstname} i {lastname} zawieraja imie i nazwisko klienta. {order_name} to numer referencyjny zamowienia (jak ABCDEF123). {shop_name} to nazwa sklepu skonfigurowana w panelu administracyjnym. {shop_url} to adres URL sklepu. {shop_logo} to sciezka do logo sklepu. {date} to data zamowienia. {payment} to uzyta metoda platnosci. {total_paid} to calkowita zaplacona kwota. {delivery_company} i {delivery_address} zawieraja informacje o przewozniku i adresie dostawy.

Dla listy produktow PrestaShop uzywa specjalnej skladni blokowej. Sekcja elementow produktowych jest opakowana w petle, ktora powtarza sie dla kazdego produktu w zamowieniu: {items} zawiera wstepnie sformatowany HTML dla calej tabeli listy produktow, wlaczajac nazwy produktow, ilosci, ceny i wszelkie szczegoly personalizacji.

Referencja dostepnych zmiennych

Aby zobaczyc wszystkie dostepne zmienne dla konkretnego szablonu e-mail, sprawdz kod PHP wysylajacy e-mail. Dla potwierdzenia zamowienia sprawdz klase PaymentModule (w /classes/PaymentModule.php). Metoda validateOrder() buduje tablice zmiennych szablonu. Kazdy klucz w tablicy odpowiada nazwie zmiennej, ktorej mozesz uzyc w szablonie.

Czesto dostepne zmienne w e-mailach potwierdzenia zamowienia obejmuja: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} i {total_products}.

Personalizacja szablonu potwierdzenia zamowienia

Krok 1: Utworz nadpisanie motywu

Nigdy nie edytuj bezposrednio plikow szablonow rdzenia. Zamiast tego skopiuj szablon do katalogu mails motywu:

Skopiuj /mails/pl/order_conf.html do /themes/twoj-motyw/mails/pl/order_conf.html. Zrob to samo dla order_conf.txt. Jesli katalog mails/pl/ nie istnieje w motywu, utworz go.

Jesli Twoj sklep obsluguje wiele jezykow, skopiuj szablony do kazdego katalogu jezykowego. Twoje angielskie potwierdzenie zamowienia trafia do /themes/twoj-motyw/mails/en/order_conf.html i tak dalej.

Krok 2: Modyfikuj uklad HTML

Otworz szablon HTML w edytorze tekstu (nie w edytorze wizualnym, ktory moze dodac niechciany kod). HTML e-mailowy rozni sie od HTML webowego w kilku waznych aspektach:

Uzywaj tabel do ukladu, nie divow. Klienty pocztowe, szczegolnie Outlook, maja bardzo ograniczona obsluge CSS. Uklad trzech kolumn musi uzywac <table> z trzema elementami <td>, nie kolumn CSS czy flexboxa.

Uzywaj stylow inline na kazdym elemencie. Zamiast <p class="heading"> z oddzielnym arkuszem stylow, uzyj <p style="font-size:18px; font-weight:bold; color:#333333;">. Kazdy stylizowany element potrzebuje wlasnego atrybutu stylu inline.

Ustaw jawne szerokosci na tabelach i komorkach. Klienty pocztowe nie zawsze respektuja szerokosci procentowe. Uzyj stalej szerokosci dla glownej tabeli tresci (600 pikseli to standard) z procentowymi kolumnami wewnetrznymi.

Uzywaj bezpiecznych czcionek webowych. Nie wszystkie klienty pocztowe obsluguja niestandardowe czcionki. Trzymaj sie Arial, Helvetica, Georgia, Times New Roman, Verdana lub Trebuchet MS. Mozesz sprobowac zaladowac niestandardowa czcionke jako fallback, ale zawsze okresl bezpieczna czcionke webowa jako koncowy fallback.

Krok 3: Dodaj swoj branding

Zastap domyslny naglowek PrestaShop brandingiem swojego sklepu. Obejmuje to zazwyczaj aktualizacje logo (zmienna {shop_logo} automatycznie uzywa logo sklepu, ale mozesz chciec specjalnej wersji e-mailowej), zmiane koloru tla naglowka na zgodny z marka, dodanie schematu kolorow marki do naglowkow i linkow oraz dolaczenie sloganu sklepu lub krotkiego komunikatu marketingowego.

Utrzymuj ogolna strukture prosta. Zbyt skomplikowane projekty e-maili rozpadaja sie w roznych klientach pocztowych. Czysty, jednokolumnowy uklad z kolorami marki i logo jest bardziej efektywny i niezawodny niz rozbudowany wielokolumnowy projekt.

Krok 4: Dostosuj tabele produktow

Domyslna tabela produktow w potwierdzeniu zamowienia PrestaShop jest funkcjonalna, ale podstawowa. Mozesz ja ulepszyc, dodajac obrazy produktow (uzyj bezwzglednych URL do obrazow hostowanych na serwerze, nie sciezek wzglednych), dodajac linki do stron produktow, aby klienci mogli latwo zamowic ponownie lub zostawic opinie, dodajac niestandardowe pola jak szacowane daty dostawy lub spersonalizowane wiadomosci, oraz dostosowujac styl tabeli do marki.

Dodajac obrazy produktow, utrzymuj je male (50 do 80 pikseli szerokosci) i zawsze dodawaj atrybut alt. Niektore klienty pocztowe domyslnie blokuja obrazy, a tekst alternatywny zapewnia, ze klienci moga nadal zidentyfikowac produkty.

Dodawanie niestandardowych pol do e-maili zamowien

Domyslne zmienne PrestaShop pokrywaja standardowe informacje o zamowieniu, ale mozesz chciec dolaczyc dodatkowe dane jak zdobyte punkty lojalnosciowe, szacowana date dostawy, spersonalizowane podziekowanie lub rekomendacje produktow powiazanych.

Dodawanie zmiennych przez modul

Najczystszym sposobem dodania niestandardowych zmiennych jest modul podlaczajacy sie do procesu wysylania e-maili. Utworz modul rejestrujacy hook actionEmailSendBefore (dostepny od PrestaShop 1.7.6) lub hook actionGetExtraMailTemplateVars. W handlerze hooka dodaj niestandardowe zmienne do tablicy zmiennych szablonu:

Funkcja hooka otrzymuje tablice zmiennych szablonu przez referencje. Mozesz dodac nowe zmienne do tej tablicy i staja sie one dostepne w szablonie przy uzyciu standardowej skladni {nazwa_zmiennej}. Na przyklad po dodaniu loyalty_points do tablicy w hooku, mozesz uzyc {loyalty_points} w szablonie HTML potwierdzenia zamowienia.

Uzywanie istniejacych danych z bazy

Mozesz pobierac dowolne dane z bazy PrestaShop do zmiennych e-mail. Czeste przyklady obejmuja calkowita liczbe zamowien klienta (aby wyswietlic "Dziekujemy za 5. zamowienie!"), saldo punktow lojalnosciowych klienta, niestandardowe pola produktow przechowywane w cechach lub atrybutach produktow oraz informacje o magazynie lub dostawcy zamowionych produktow.

Konfiguracja wielojezyczna e-maili

Jesli Twoj sklep obsluguje klientow w wielu jezykach, kazdy szablon e-mail potrzebuje wersji dla kazdego jezyka. PrestaShop automatycznie wybiera jezyk na podstawie preferencji klienta, ale musisz dostarczyc szablony.

Tworzenie szablonow specyficznych dla jezyka

Dla kazdego jezyka obslugiwanego przez sklep utworz katalog w folderze mails motywu: /themes/twoj-motyw/mails/en/, /themes/twoj-motyw/mails/fr/, /themes/twoj-motyw/mails/de/ i tak dalej. Skopiuj i przetlumacz kazdy plik szablonu do odpowiedniego katalogu.

Nie uzywaj automatycznego tlumaczenia e-maili transakcyjnych. Te e-maile reprezentuja komunikacje sklepu z klientami, a slabe tlumaczenia podkopuja zaufanie. Kazda wersje jezykowa powinna napisac lub sprawdzic native speaker.

Obsluga jezykow od prawej do lewej

Jesli obslugiwane sa jezyki takie jak arabski lub hebrajski, szablony e-mail potrzebuja wsparcia RTL (od prawej do lewej). Dodaj dir="rtl" do glownego elementu tabeli i dostosuj wyrownanie tekstu oraz padding w stylach inline. Utworz oddzielne szablony dla jezykow RTL zamiast probowac uzywac jednego szablonu dla obu kierunkow.

Formatowanie dat i walut

PrestaShop automatycznie formatuje daty i wartosci walut zgodnie z ustawieniami jezyka i waluty klienta. Zmienne {date}, {total_paid} i inne sformatowane wartosci juz odzwierciedlaja prawidlowa lokalizacje. Jednak jesli dodajesz niestandardowe zmienne z datami lub wartosciami walut, upewnij sie, ze sa prawidlowo sformatowane dla jezyka docelowego.

Konfiguracja SMTP dla niezawodnej dostarczalnosci

Najlepszy szablon e-mail na swiecie jest bezuzyteczny, jesli e-maile nie docieraja do skrzynki odbiorczej. Domyslna konfiguracja e-mail PrestaShop uzywa wbudowanej funkcji PHP mail(), ktora jest nieniezawodna dla e-maili transakcyjnych. Wiekszosc tych e-maili trafia do folderu spam lub jest calkowicie odrzucana przez nowoczesnych dostawcow poczty.

Dlaczego SMTP jest wazne

SMTP (Simple Mail Transfer Protocol) z odpowiednia autoryzacja jest kluczowe dla dostarczalnosci e-maili. Gdy wysylasz e-maile przez funkcje PHP mail(), e-mail pochodzi z adresu IP serwera bez zadnej autoryzacji. Dostawcy poczty jak Gmail, Outlook i Yahoo widza to jako sygnial ostrzegawczy i czesto klasyfikuja takie e-maile jako spam.

Z SMTP e-maile sa wysylane przez uwierzytelniony serwer pocztowy z odpowiednimi rekordami SPF, DKIM i DMARC. To dowodzi serwerom pocztowym, ze e-mail jest legalny i autoryzowany przez Twoja domene.

Konfiguracja SMTP w PrestaShop

Przejdz do Zaawansowane > E-mail w panelu administracyjnym PrestaShop. Zmien metode z "Uzyj funkcji mail() PHP" na "Ustaw wlasne parametry SMTP". Wprowadz dane serwera SMTP: adres serwera, port (typowo 587 dla TLS lub 465 dla SSL), typ szyfrowania, nazwe uzytkownika i haslo.

Popularni dostawcy SMTP dla PrestaShop obejmuja Gmail SMTP (smtp.gmail.com, port 587, TLS, wymaga hasla aplikacji przy wlaczonym 2FA), Amazon SES (przystepny cenowo dla duzych wolumenow), SendGrid (hojny darmowy plan), Mailgun (przyjazny dla programistow z dobrym logowaniem) oraz serwer SMTP Twojego dostawcy hostingu (sprawdz ustawienia u swojego hosta).

Testowanie konfiguracji SMTP

Po skonfigurowaniu SMTP uzyj przycisku "Wyslij testowy e-mail" na dole strony konfiguracji e-mail. Wprowadz wlasny adres e-mail i sprawdz, czy testowy e-mail dotarl do skrzynki (nie do spamu). Jesli testowy e-mail nie dotarl, sprawdz dane SMTP, upewnij sie, ze serwer moze polaczyc sie z serwerem SMTP na skonfigurowanym porcie (niektore firmy hostingowe blokuja porty wychodzace 25 i 587) oraz sprawdz, czy dostawca SMTP wymaga okreslonych ustawien bezpieczenstwa.

Rekordy SPF, DKIM i DMARC

Dla maksymalnej dostarczalnosci skonfiguruj te rekordy DNS dla swojej domeny. SPF (Sender Policy Framework) okresla, ktore serwery sa uprawnione do wysylania e-maili w imieniu domeny. DKIM (DomainKeys Identified Mail) dodaje podpis cyfrowy do e-maili potwierdzajacy, ze zostaly wyslane z Twojej domeny. DMARC (Domain-based Message Authentication, Reporting, and Conformance) informuje serwery odbiorcze, co robic z e-mailami niespelniajacymi sprawdzen SPF lub DKIM.

Dostawca SMTP dostarczy konkretne rekordy DNS do dodania. Na przyklad przy korzystaniu z SendGrid otrzymasz rekordy SPF i DKIM podczas procesu uwierzytelniania domeny. Dodaj je jako rekordy TXT w ustawieniach DNS domeny.

Testowanie szablonow e-mail

Wysylanie testowych e-maili

PrestaShop nie ma wbudowanej opcji podgladu konkretnych szablonow e-mail. Aby przetestowac szablon potwierdzenia zamowienia, musisz zlozyc prawdziwe zamowienie testowe. Utworz testowe konto klienta, dodaj produkty do koszyka i sfinalizuj zamowienie testowa metoda platnosci. Jesli masz skonfigurowany modul platnosci sandbox, uzyj go. W przeciwnym razie metody platnosci przelewem bankowym lub czekiem pozwalaja sfinalizowac zamowienie bez rzeczywistego przetwarzania platnosci.

Testowanie w roznych klientach pocztowych

Renderowanie e-maili dramatycznie rozni sie miedzy klientami pocztowymi. To co wyglada idealnie w Gmail, moze byc uszkodzone w Outlooku. Przetestuj szablony co najmniej w Gmail (web), Outlook (desktop i web), Apple Mail, Yahoo Mail i przynajmniej jednej mobilnej aplikacji pocztowej. Uslugi jak Litmus lub Email on Acid automatyzuja to testowanie, renderujac e-mail w dziesieciach klientow pocztowych jednoczesnie, ale sa to uslugi platne.

Czeste problemy z renderowaniem

Jesli e-mail wyglada zle w Outlooku, jest to prawie na pewno problem CSS. Outlook uzywa silnika renderowania Microsoft Word dla e-maili HTML, ktory ma niezwykle ograniczona obsluge CSS. Nie obsluguje obrazow tla na komorkach tabeli (uzyj kolorow tla), paddingu na elementach blokowych (uzyj paddingu komorek tabeli), max-width (uzyj stalych szerokosci), margin do centrowania (uzyj align="center" na tabelach) ani CSS float.

Dla responsywnosci mobilnej opakuj tabele tresci w kontener z max-width:600px i dodaj media query w bloku stylu head (obslugiwana przez niektore klienty pocztowe), ktora ustawia szerokosci tabel na 100% na malych ekranach. To nie jest idealny responsywny design, ale zapobiega przewijaniu poziomemu na wiekszosci urzadzen mobilnych.

Czeste problemy i rozwiazywanie

Brakujace obrazy w e-mailach

To najczestszy problem z szablonami e-mail. Obrazy w e-mailach musza uzywac bezwzglednych URL (zaczynajacych sie od https://), nie sciezek wzglednych. Jesli szablon odwoluje sie do /img/logo.png, zmien na https://www.twojadomena.pl/img/logo.png. Zmienna {shop_logo} automatycznie generuje bezwzgledny URL, ale wszystkie obrazy dodane recznie musza uzywac pelnych URL.

Sprawdz rowniez, czy obrazy sa dostepne spoza sieci. Jesli sklep jest za zapora lub uwierzytelnianiem HTTP, klienty pocztowe nie moga zaladowac obrazow. Przetestuj otwierajac URL obrazu w prywatnym oknie przegladarki.

Uszkodzony uklad po edycji

HTML e-mailowy jest kruchy. Pojedynczy niezamkniety tag lub brakujaca komorka tabeli moze zniszczyc caly uklad. Zawsze waliduj HTML po edycji. Policz otwierajace i zamykajace tagi table, tr i td. Kazdy <table> potrzebuje </table>, kazdy <tr> potrzebuje </tr>, a kazdy <td> potrzebuje </td>. Upewnij sie, ze kazdy wiersz w tabeli ma taka sama liczbe komorek (lub uzywa colspan).

Zmienne nie sa zastepowane

Jesli w wyslanych e-mailach widzisz literalny tekst {nazwa_zmiennej} zamiast rzeczywistych wartosci, sprawdz nazwe zmiennej pod katem literowek. Nazwy zmiennych sa wrazliwe na wielkosc liter. Sprawdz rowniez, czy zmienna istnieje dla konkretnego typu e-maila. Nie wszystkie zmienne sa dostepne we wszystkich szablonach. Zmienne specyficzne dla zamowien jak {order_name} sa dostepne tylko w e-mailach zwiazanych z zamowieniami.

E-maile nie sa wysylane

Jesli e-maile nie sa wysylane, sprawdz panel administracyjny PrestaShop w Zaawansowane > E-mail. Mozesz tam zobaczyc dziennik wyslanych e-maili. Jesli dziennik pokazuje bledy, sprawdz konfiguracje SMTP. Jesli zaden e-mail nie pojawia sie w dzienniku, e-mail moze nie byc w ogole wyzwalany. Sprawdz, czy przejscia statusow zamowien sa skonfigurowane do wysylania e-maili (Zamowienia > Statusy > edytuj status > zaznacz "Wyslij e-mail do klienta").

Sprawdz rowniez dziennik bledow PHP serwera pod katem bledow zwiazanych z e-mailami. Czeste problemy to wylaczona funkcja PHP mail() przez dostawce hostingu, bledy uwierzytelniania SMTP z powodu zmienionego hasla oraz problemy z polaczeniem sieciowym miedzy serwerem a serwerem SMTP.

E-maile trafiaja do spamu

Nawet przy poprawnej konfiguracji SMTP e-maile moga nadal trafiac do spamu. Najczestsze przyczyny to brakujace lub nieprawidlowe rekordy SPF/DKIM/DMARC, tresc e-maila wyzwalajaca filtry spam (nadmierne uzycie duzych liter, slowa wyzwalajace spam jak "za darmo" czy "dzialaj teraz", zbyt duzo obrazow z mala iloscia tekstu), wysylanie z adresu IP o zlej reputacji (czeste przy hostingu wspoldzielonym) oraz domena adresu nadawcy niezgodna z domena serwera SMTP.

Najpierw napraw rekordy DNS, potem przejrzyj tresc e-maili. Uzyj narzedzia takiego jak mail-tester.com do analizy e-maili pod katem wyzwalaczy spamu. Wyslij testowy e-mail na podany adres, a otrzymasz szczegolowy raport pokazujacy, co moze powodowac klasyfikacje jako spam.

Nadpisania e-maili specyficzne dla motywu

Niektore motywy PrestaShop zawieraja wlasne szablony e-mail pasujace do designu motywu. Jesli motyw ma szablony w /themes/twoj-motyw/mails/, automatycznie nadpisuja one szablony rdzenia.

Sprawdzanie szablonow e-mail motywu

Sprawdz w katalogu aktywnego motywu, czy istnieje folder mails. Jesli istnieje, motyw dostarcza niestandardowe szablony e-mail. Te szablony zazwyczaj pasuja do schematu kolorow i designu naglowka/stopki motywu, zapewniajac wizualna spojnosc e-maili z witryma sklepu.

Dostosowywanie szablonow e-mail motywu

Jesli motyw dostarcza szablony e-mail, edytuj te zamiast kopiowac z katalogu mails/ rdzenia. Szablony motywu moga uzywac innej struktury HTML lub zawierac dodatkowe CSS specyficzne dla systemu designu motywu. Rozpoczecie od wersji motywu zapewnia wizualna spojnosc.

Synchronizacja szablonow z aktualizacjami motywu

Aktualizujac motyw, sprawdz czy aktualizacja zawiera zmiany w szablonach e-mail. Jesli tak, Twoje dostosowania moga zostac nadpisane. Przed aktualizacja zrob kopie zapasowa dostosowanych szablonow. Po aktualizacji porownaj nowe szablony z kopiami i ponownie zastosuj dostosowania do zaktualizowanych wersji. Jest to zmdune, ale konieczne, aby zachowac zarowno dostosowania, jak i ewentualne ulepszenia lub poprawki dewelopera motywu.

Dobre praktyki dla e-maili potwierdzenia zamowienia

Dobrze zaprojektowany e-mail z potwierdzeniem zamowienia robi wiecej niz tylko potwierdza transakcje. Buduje zaufanie, zmniejsza liczbe zapytan do obslugi klienta i tworzy mozliwosci zaangazowania.

Umiesc wyraznie widoczny numer referencyjny zamowienia na gorze. Klienci potrzebuja tego numeru kontaktujac sie z obsluga lub sledzac zamowienie. Wymien kazdy produkt z nazwa, iloscia, cena i wszelkimi opcjami lub personalizacjami. Dolacz pelne zestawienie sumy czesciowej, kosztow wysylki, podatkow, rabatow i sumy calkowitej. Pokaz adres dostawy, aby klienci mogli go zweryfikowac i natychmiast skontaktowac sie w razie bledu. Podaj uzyta metode platnosci i odpowiednie szczegoly transakcji. Udostepnij link do strony sledzenia zamowienia lub historii zamowien w koncie klienta. Dodaj dane kontaktowe obslugi klienta, aby wiedzieli jak sie skontaktowac w razie problemow.

Utrzymuj design czysty i przyjazny dla urzadzen mobilnych. Ponad polowa wszystkich e-maili jest czytana na urzadzeniach mobilnych. Uzyj jednokolumnowego ukladu, duzego czytelnego tekstu (minimum 14px dla tresci) i przyciskow z odpowiednimi celami dotykowymi (minimum 44px wysokosci). E-mail z potwierdzeniem zamowienia odzwierciedla profesjonalizm sklepu. Zainwestuj czas, aby zrobic to dobrze.

Przeczytaj pełną odpowiedź

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Przeczytaj pełną odpowiedź

Cookie	Dostawca	Cel	Czas
PrestaShop-*	PrestaShop	Zarządzanie sesją i funkcjonalność koszyka	Sesja
PHPSESSID	PHP	Identyfikator sesji PHP	Sesja
mprcr_consent	MPR Cookies Revolution	Przechowuje preferencje zgody na pliki cookie	365 dzień/dni
mprcr_version	MPR Cookies Revolution	Śledzi wersję konfiguracji zgody	365 dzień/dni

Cookie	Dostawca	Cel	Czas
TawkConnectionTime	Tawk.to	Suivi du temps de connexion de la session de chat	Sesja
__tawkuuid	Tawk.to	Identifie les visiteurs de chat recurrents	6 miesiąc/e