Migracja sklepu internetowego z PrestaShop 1.7 do PrestaShop 9 przynosi wiele korzyści związanych z wydajnością, bezpieczeństwem i nowoczesnym podejściem do zarządzania multimediami. W praktyce jednak może również ujawnić problemy, które nie są widoczne na etapie samej migracji danych.
Jednym z takich problemów jest gwałtowny wzrost liczby generowanych plików graficznych oraz rozmiaru katalogu img/p, szczególnie w sklepach posiadających dużą bazę produktów i zdjęć.
Poniższe case study opisuje rzeczywisty scenariusz dotyczący sklepu posiadającego około 30 000 produktów i 37 000 zdjęć produktowych.
Sytuacja początkowa
Parametry sklepu
- około 30 000 produktów,
- około 37 000 zdjęć produktów,
- migracja z PrestaShop 1.7 do PrestaShop 9,
- wdrożenie nowego szablonu Hummingbird.
Po migracji zauważyłem bardzo szybki wzrost zajętości przestrzeni dyskowej. Mimo że do sklepu nie były dodawane nowe produkty ani zdjęcia, katalog img/p stale zwiększał swój rozmiar.
Analiza problemu
Zmiana systemu typów zdjęć
W PrestaShop 1.7 standardowo wykorzystywane były typy zdjęć takie jak:
- cart_default
- home_default
- large_default
- medium_default
- small_default
PrestaShop 9 wraz z szablonem Hummingbird wprowadza nowy zestaw typów obrazów, m.in.:
- default_xs
- default_sm
- default_md
- default_lg
- default_xl
- oraz inne warianty wykorzystywane przez responsywny frontend.
Problem polega na tym, że w czystej instalacji Prestashop 9.1 aktywne pozostają jednocześnie:
- stare typy zdjęć wymagane przez Classic lub moduły zgodne z PrestaShop 1.7,
- nowe typy zdjęć wykorzystywane przez Hummingbird.
W efekcie system generuje miniatury dla obu zestawów.
Skala problemu
W analizowanym sklepie znajdowało się 37 000 zdjęć produktów, co musiało zostać przerobione na:
- 12 aktywnych typów miniatur,
- 1 plik oryginalny.
Łącznie daje to:
37 000 × 13 = 481 000 plików graficznych
Jednak w PrestaShop 9 dodatkowo obsługiwane są formaty:
- JPG / PNG
- WebP
- AVIF
Ostatecznie liczba plików wzrasta do:
37 000 × 12 × 3 (12 rozmiarów x 3 formaty) + 37 000 (oryginalne zdjęcia) = 1 369 000 plików
Prawie 1,4 miliona plików dla samych zdjęć produktowych.
Dodatkowy problem: generowanie WebP i AVIF „na żądanie”
Podczas analizy wyszło kolejne źródło wzrostu zajętości dysku.
W przeciwieństwie do klasycznego procesu regeneracji miniaturek: pliki WebP i AVIF nie są tworzone podczas dodawania zdjęć, zamiast tego w PrestaShop 9 są one generowane dopiero przy pierwszym wyświetleniu zdjęcia (dokładnie to całej karty produktu) w sklepie.
Przykładowy scenariusz
- Przenosimy zdjęcia ze starego sklepu do nowego, albo wgrywamy je na nowo.
- Rozmiar katalogu
img/pwydaje się stabilny. - Klienci zaczynają przeglądać produkty.
- Podczas pierwszego wejścia na kartę produktu generowane są brakujące pliki WebP i AVIF.
- Rozmiar katalogu zaczyna stale rosnąć.
Powoduje to sytuację, w której:
- przestrzeń dyskowa jest zajmowana stopniowo,
- monitoring serwera może nie wskazywać od razu źródła problemu,
- wygląda to jakby sklep „sam” produkował nowe pliki.
Wpływ formatu AVIF na wydajność
Choć format AVIF zapewnia bardzo dobrą kompresję, jego generowanie jest znacznie bardziej zasobożerne niż tworzenie plików WebP.
W zależności od:
- mocy procesora,
- liczby rdzeni CPU,
- konfiguracji PHP,
- użytej biblioteki do przetwarzania obrazów (GD/ImageMagick),
wygenerowanie kompletu wariantów AVIF dla dużej liczby zdjęć może trwać bardzo długo.
W analizowanym przypadku skutki obejmowały:
- zwiększone zużycie CPU,
- wzrost czasu odpowiedzi pierwszych odwiedzin produktów,
- okresowe przeciążenia serwera po wdrożeniu nowej wersji sklepu.
Rozwiązanie
Audyt wykorzystywanych typów zdjęć
Pierwszym krokiem było sprawdzenie:
- które rozmiary są rzeczywiście używane przez Hummingbird,
- które rozmiary są pozostałością po szablonie Classic,
- które rozmiary są wykorzystywane przez moduły zewnętrzne.
Analiza wykazała, że część typów miniaturek nie była już używana przez frontend sklepu.
Wyłączenie zbędnych typów zdjęć
Usunięcie 5-ciu nieużywanych typów obrazów, w efekcie liczba generowanych wariantów dla każdego zdjęcia została znacząco ograniczona.
Wyłączenie formatu AVIF
Format AVIF daje wiele możliwości, ale we wspomnianym sklepie jest już włączony format WebP, więc nie widziałem sensu w dublowaniu obrazów, tymbardziej że AVIF nie został jeszcze tak szeroko przyjęty jak WebP.
Efekt
Zmniejszenie rozmiaru katalogu img/p o około 27 GB.
Oprócz oszczędności miejsca uzyskano również:
- mniejszą liczbę plików w systemie,
- krótszy czas backupów,
- szybsze operacje synchronizacji danych,
- mniejsze obciążenie serwera podczas regeneracji zdjęć.
Problemy napotkane w trakcie optymalizacji
Nie wszystkie komponenty sklepu były gotowe na usunięcie starych typów miniaturek.
Część modułów nadal odwoływała się do historycznych nazw, takich jak:
home_default,cart_default,large_default.
Po wyłączeniu tych rozmiarów pojawiły się:
- brakujące zdjęcia w niektórych modułach,
- błędne ścieżki do obrazów,
- problemy z wyświetlaniem miniaturek w widgetach,
- a nawet błędy 500, które blokowały ładowanie np. strony produktu.
Działania naprawcze
Dla każdego modułu należało:
Opcja 1 – zmiana konfiguracji modułu
Jeżeli developer modułu przewidział taką możliwość, wystarczyło wskazać nowy typ obrazu, np.:
default_smdefault_mddefault_lg
zamiast starych odpowiedników.
Opcja 2 – modyfikacja kodu
W niektórych modułach konieczna była zmiana kodu.
Przykładowo: 'home_default’ zamienić na 'default_md’ lub inny rozmiar odpowiadający danemu zastosowaniu. Dopiero po przejrzeniu wszystkich modułów można było bezpiecznie usunąć niepotrzebne typy miniaturek.
Wnioski
Migracja z PrestaShop 1.7 do PrestaShop 9 wymaga nie tylko przeniesienia danych, ale również audytu konfiguracji obrazów.
Najważniejsze obserwacje:
- Domyślna konfiguracja może utrzymywać jednocześnie typy zdjęć dla Classic i Hummingbird.
- Liczba generowanych plików rośnie wykładniczo wraz z liczbą zdjęć, rozmiarów i formatów.
- WebP i AVIF mogą być generowane dynamicznie podczas działania sklepu, co powoduje dalszy wzrost zajętości dysku nawet bez dodawania nowych zdjęć.
- Generowanie AVIF jest kosztowne obliczeniowo i może wpływać na wydajność serwera.
- Przed usunięciem nieużywanych rozmiarów należy zweryfikować zgodność wszystkich modułów.
- W analizowanym sklepie ograniczenie liczby aktywnych typów zdjęć o 5 pozycji pozwoliło odzyskać około 27 GB przestrzeni dyskowej.
Rekomendacja
Po każdej migracji do PrestaShop 9 warto przeprowadzić audyt typów obrazów, zweryfikować rzeczywiste wykorzystanie miniaturek przez szablon i moduły oraz ograniczyć liczbę generowanych wariantów do absolutnego minimum. W dużych sklepach posiadających dziesiątki tysięcy zdjęć może to przynieść oszczędności liczone w dziesiątkach gigabajtów oraz znacząco ograniczyć obciążenie serwera.
