Skip to content

Skorzystaj z bezpłatnego audytu technicznego Twojej technologi. [Poznaj szczegóły]

Blog
Optymalizacja Optymalizacja wydajności PrestaShop

Dlaczego listing kategorii jest najwolniejszą stroną sklepu

Autor

Rafał Skotarczak

Opublikowano

10 sierpnia 2026 r.

Aktualizacja

10 sierpnia 2026 r.

Z artykułu dowiesz się

  1. Listing musi policzyć zbiór wyników i przeliczyć dostępne wartości każdego filtra, więc kosztuje wielokrotnie więcej niż karta produktu

  2. Liczniki przy wartościach filtrów są najdroższym elementem całego mechanizmu

  3. Sto dwadzieścia wartości koloru w katalogu z pięciuset produktami to cztery konwencje zapisu, nie bogata oferta

  4. Jeśli liczba zapytań rośnie proporcjonalnie do liczby produktów na stronie, któryś moduł odpytuje bazę w pętli

  5. Ujednolicenie wartości atrybutów i ograniczenie filtrów to praca zespołu handlowego, nie wykonawcy

Wydajność listingu PrestaShop jest w większości sklepów najsłabszym punktem całego serwisu i jednocześnie najrzadziej mierzonym. Strona główna bywa prosta i dobrze zbuforowana, karta produktu wyświetla jeden rekord, a listing kategorii z włączoną nawigacją fasetową potrafi generować zapytania do bazy liczone w setkach. Klient widzi to jako sklep, który zwalnia dokładnie w momencie przeglądania oferty.

Najgorsze w tym jest to, że problem narasta razem z rozwojem firmy. Im większy katalog i im bogatszy opis produktów, tym wolniejszy listing, więc sklep zwalnia właśnie wtedy, gdy zaczyna się rozkręcać.

Dlaczego listing kategorii jest najwolniejszą stroną sklepu

Karta produktu odpytuje bazę o jeden produkt. Listing musi wykonać coś znacznie trudniejszego: znaleźć zbiór produktów spełniających warunki, policzyć, ile ich jest, ustalić dostępne wartości każdego filtra dla tego zbioru i przy każdej wartości podać liczbę pasujących pozycji.

Ostatni element jest tym, który kosztuje najwięcej. Liczniki przy filtrach, informujące klienta, ile produktów kryje się pod każdą wartością, wymagają przeliczenia zbioru dla każdej opcji osobno. Przy czterech filtrach po pięć wartości to dwadzieścia dodatkowych obliczeń przy każdym wyświetleniu strony, a każde zawężenie uruchamia je od nowa.

Do tego dochodzą trzy czynniki, które mnożą problem:

  • Liczba wartości atrybutów. Katalog, w którym kolor występuje w stu dwudziestu wariantach zapisu, generuje sto dwadzieścia pozycji filtra i tyle samo przeliczeń.
  • Moduły dokładające zapytania w pętli. Element wyświetlający przy każdym produkcie dostępność w sklepach stacjonarnych albo liczbę opinii dokłada jedno zapytanie na produkt. Listing z pięćdziesięcioma pozycjami to pięćdziesiąt dodatkowych zapytań.
  • Brak buforowania. Listing z filtrami ma tyle wariantów, ile kombinacji, więc trafność cache jest z natury niska. Każde nowe zawężenie to strona generowana od zera.

Wydajność listingu PrestaShop: jak ją zmierzyć

Potrzebujesz trzech liczb i wszystkie zbierzesz w kwadrans.

Liczba zapytań do bazy na wyświetlenie

Zmierz ją na trzech stronach: głównej, listingu bez filtrów i tym samym listingu po zaznaczeniu dwóch filtrów. Porównanie tych trzech wartości mówi wszystko. Jeśli listing generuje wielokrotnie więcej zapytań niż strona główna, wiesz, gdzie leży koszt. Jeśli zaznaczenie filtrów zwielokrotnia tę liczbę jeszcze raz, wiesz, że to nawigacja fasetowa, a nie sam katalog.

Czas odpowiedzi z filtrami i bez

Ta sama kategoria, dwa pomiary. Różnica jest ceną nawigacji fasetowej w Twoim sklepie. Warto ją znać przed rozmową o tym, czy filtry zostają w obecnej formie.

Liczba wartości w każdym filtrze

Wejdź w panelu na listę wartości jednego atrybutu i policz pozycje. Jeśli w katalogu z pięciuset produktami masz sto dwadzieścia wartości koloru, to nie jest bogata oferta, tylko cztery konwencje zapisu wprowadzone przez cztery źródła danych. Filtr zbudowany na takich wartościach nie zawęża wyników, tylko je rozdrabnia, a klient zaznaczający jedną pozycję widzi ułamek produktów, które powinien zobaczyć.

Co zrobić z filtrami

Alejka sklepowa: filtry mają zawęzić wybór w dwóch krokach

Kolejność jest ustalona, bo każdy krok zmniejsza pracę potrzebną w następnym.

Ujednolić wartości. Scalenie zapisów w atrybutach i cechach to zmiana niewidoczna dla klienta, a redukująca liczbę przeliczeń wprost. Zaczyna się od eksportu listy wartości i decyzji, które są tym samym. Nudne i skuteczne.

Ograniczyć liczbę filtrów do używanych. Dane masz w analityce. Filtry, których klienci nie klikają, wydłużają listę, obciążają zapytania i nie dają nic w zamian. Trzy filtry, po których klienci realnie zawężają wybór, są warte więcej niż dwanaście teoretycznie użytecznych.

Przypisać zestawy filtrów do kategorii. PrestaShop pozwala określić, które filtry pojawiają się w której kategorii. Filtr rozmiaru butów na listingu z torebkami nie ma po co się wyświetlać ani po co być przeliczany.

Rozważyć rezygnację z liczników. To decyzja handlowa, nie techniczna. Liczniki przy wartościach filtrów pomagają klientowi, ale są najdroższym elementem całego mechanizmu. W sklepach z bardzo dużym katalogiem bywa to jedyna zmiana, która realnie odblokowuje listing.

Praca na samej strukturze katalogu, czyli podział na kategorie, atrybuty i cechy, rozkłada się osobno i opisujemy ją w tekście o optymalizacji katalogu PrestaShop. Tutaj interesuje nas wyłącznie to, co ta struktura kosztuje w czasie generowania listingu.

Po stronie serwera i bazy

Gdy struktura jest już uporządkowana, a listing nadal odstaje, przyczyna leży w warstwie danych. Trzy rzeczy do sprawdzenia, wszystkie po stronie wykonawcy technicznego.

ObszarObjawKierunek
Brakujące indeksyzapytania filtrujące wolne mimo małego zbioru wynikówindeksy na kolumnach używanych do filtrowania
Moduły w pętliliczba zapytań rośnie proporcjonalnie do liczby produktów na stroniepobranie danych jednym zapytaniem zamiast wielu
Liczba produktów na stronielisting z setką pozycji wolniejszy niż dwie strony po pięćdziesiątdobrać wartość do realnego zachowania klientów

Drugi wiersz wykryjesz najprościej: policz zapytania na listingu z dziesięcioma produktami i z pięćdziesięcioma. Jeśli liczba rośnie proporcjonalnie, któryś moduł odpytuje bazę osobno dla każdego produktu. Wyłącz moduły partiami, żeby ustalić który, i zgłoś to jego autorowi albo rozważ zamiennik.

Trzeci wiersz jest decyzją, nie usterką. Więcej produktów na stronie skraca drogę klienta i zmniejsza liczbę przeładowań, ale wydłuża generowanie i transfer. Rozstrzygnięcie znajdziesz w danych: jeśli większość klientów nie przechodzi poza pierwszą stronę listingu, dołożenie produktów pomoże bardziej niż optymalizacja stronicowania.

Głębszą pracę na samej bazie, wraz z czyszczeniem rozrośniętych tabel, prowadzimy w ramach usługi optymalizacja wydajności PrestaShop.

Buforowanie listingu: co da się zbuforować

Listing bez filtrów buforuje się normalnie i powinien być serwowany z cache. Problem zaczyna się przy zawężeniach, bo każda kombinacja to osobny adres, a liczba kombinacji rośnie wykładniczo. Buforowanie wszystkiego zapełniłoby pamięć wariantami, których nikt nie odwiedza.

Rozsądny podział wygląda tak:

  • Listing bez filtrów i pierwsze strony kategorii buforuj normalnie, z długim czasem życia wpisu.
  • Popularne zawężenia, na które jest realny ruch, też warto buforować. Zwykle jest ich kilkanaście na cały sklep, nie setki.
  • Rzadkie kombinacje zostaw poza cache. Generowanie ich na żądanie jest tańsze niż utrzymywanie w pamięci wariantów odwiedzanych raz w miesiącu.

Osobna sprawa to unieważnianie. Zmiana ceny albo stanu magazynowego musi trafić do klienta natychmiast, a listing pokazuje oba. Sklep bez poprawnego unieważniania sprzedaje towar, którego nie ma, i wyświetla ceny sprzed promocji. Przy imporcie z systemu ERP czyszczenie trzeba wywołać osobno, bo import zwykle omija ścieżkę, która wyzwala to zdarzenie automatycznie.

Adresy powstające z kombinacji filtrów mają też konsekwencję poza wydajnością: trafiają do indeksu wyszukiwarek jako warianty tej samej treści. Ten wątek rozkładamy w tekście o optymalizacji SEO PrestaShop.

Sortowanie i stronicowanie

Dwa elementy listingu, które wyglądają na drobiazgi interfejsu, a mają wymierny koszt po stronie bazy.

Sortowanie wymaga uporządkowania całego zbioru wyników, nie tylko wyświetlanej strony. Sortowanie po cenie i po nazwie jest tanie, o ile kolumny mają indeksy. Sortowanie po popularności albo po ocenie bywa drogie, bo dane pochodzą z innych tabel i wymagają połączenia zbiorów. Jeśli któraś opcja sortowania wyraźnie spowalnia listing, sprawdź ją osobno, zanim uznasz, że problemem są filtry.

Warto też przejrzeć listę dostępnych opcji sortowania. Sklepy oferują ich zwykle sześć, a klienci używają dwóch. Każda niewykorzystana opcja to kolejny wariant strony do wygenerowania i kolejny adres w indeksie wyszukiwarki.

Stronicowanie jest tańsze niż się wydaje przy pierwszych stronach i drożeje wraz z numerem. Przeskok na stronę czterdziestą wymaga od bazy pominięcia wszystkich wcześniejszych rekordów, więc kosztuje wyraźnie więcej niż wyświetlenie pierwszej. W praktyce nie jest to problem, bo klienci rzadko wychodzą poza kilka pierwszych stron, ale bywa nim dla robotów indeksujących, które przechodzą listę do końca.

Rozstrzygnięcie o liczbie produktów na stronie znajdziesz w danych. Jeśli większość klientów nie przechodzi poza pierwszą stronę, zwiększenie liczby pozycji skraca im drogę i zmniejsza liczbę przeładowań. Jeśli przeglądają głębiej, lepiej zostawić mniejsze strony i zadbać o szybkie przechodzenie między nimi. Wariant z doładowywaniem kolejnych produktów przy przewijaniu bywa wygodny, ale utrudnia powrót do wcześniej oglądanego miejsca i komplikuje indeksowanie.

Kiedy katalog przerasta wbudowany mechanizm

Duży sklep z góry: katalog rośnie i listing zwalnia razem z nim

Wbudowana nawigacja fasetowa ma granice, ale wyznacza je nie liczba produktów, tylko liczba kombinacji wartości atrybutów. Sklep z dwudziestoma tysiącami produktów i czterema prostymi filtrami działa sprawnie. Sklep z dwoma tysiącami produktów opisanych trzydziestoma parametrami technicznymi bywa na granicy.

Sygnały, że dołożenie zewnętrznego silnika wyszukiwania i filtrowania jest uzasadnione:

  • listing z filtrami odpowiada zauważalnie wolniej niż reszta sklepu, mimo uporządkowanych wartości atrybutów i dołożonych indeksów
  • klienci zawężają wybór wieloma parametrami naraz, a wyniki mają aktualizować się bez przeładowania strony
  • liczniki przy wartościach filtrów są dla klientów istotne i nie da się z nich zrezygnować
  • oferta zmienia się na tyle często, że przeliczanie indeksów obciąża sklep w godzinach sprzedaży

Decyzję podejmij po wyczerpaniu tańszych warstw. Zewnętrzny silnik zbudowany na nieuporządkowanych danych da te same rozdrobnione filtry, tylko szybciej, a do kosztu sklepu dojdzie koszt utrzymania kolejnego elementu infrastruktury i synchronizacji danych między nim a katalogiem.

Listing na telefonie

Na telefonie listing kumuluje wszystkie problemy naraz: najwięcej zapytań po stronie serwera, najwięcej obrazów do pobrania i najsłabszy procesor do przetworzenia interfejsu filtrów. To zwykle najgorszy wynik w całym sklepie.

Trzy rzeczy, które pomagają najbardziej:

  • Miniatury we właściwym rozmiarze. Serwowanie zdjęcia kilkukrotnie szerszego, niż wyświetla je ekran telefonu, to najczęstsza pojedyncza strata na listingu.
  • Odroczenie zdjęć poniżej pierwszego ekranu, ale nie pierwszego rzędu miniatur, bo to on mierzy LCP.
  • Filtry jako warstwa otwierana na żądanie. Rozwinięta lista filtrów na małym ekranie odsuwa produkty poza zasięg wzroku, a jej kod i tak trzeba przetworzyć.

Szerzej o różnicach między urządzeniami piszemy w tekście o wydajności mobilnej PrestaShop.

Otrzymaj bezpłatną konsultację Twoich wyzwań


    Kolejność prac nad listingiem

    Każdy krok zmniejsza pracę potrzebną w następnym, więc odwracanie kolejności kosztuje czas.

    KrokKto wykonujeCharakter
    Pomiar zapytań: strona główna, listing, listing z filtramiwykonawca technicznykwadrans, bez zmian
    Ujednolicenie wartości atrybutówzespół handlowypraca na danych, rozłożona
    Ograniczenie filtrów do klikanychzespół handlowykonfiguracja, odwracalna
    Przypisanie zestawów filtrów do kategoriizespół handlowykonfiguracja
    Indeksy i przegląd zapytań modułówwykonawca technicznywymaga środowiska testowego
    Buforowanie popularnych zawężeńwykonawca technicznykonfiguracja serwera

    Dwa środkowe kroki są w całości po stronie zespołu, który już pracuje ze sklepem, i to one zwykle dają największą poprawę. To rzadka sytuacja w pracy nad wydajnością, gdzie większość zadań wymaga specjalistów, więc warto z niej skorzystać, zanim zamówisz cokolwiek na zewnątrz.

    Czego nie robić

    Nie usuwaj filtrów bez sprawdzenia danych. Filtr rzadko klikany może być tym, którego używa najbardziej wartościowa grupa klientów. Decyzję opieraj na udziale w zamówieniach, nie na samej liczbie kliknięć.

    Nie zwiększaj liczby produktów na stronie, żeby zmniejszyć liczbę odsłon. To pogarsza czas generowania i transfer, a zysk jest pozorny. Decyduj na podstawie tego, jak głęboko klienci realnie przeglądają listę.

    Nie zamawiaj mocniejszego serwera, zanim policzysz zapytania. Listing generujący ich setki będzie je generował także na szybszej maszynie. Kupujesz wtedy kilka miesięcy spokoju i wracasz do punktu wyjścia razem ze wzrostem katalogu.

    Ostatnia uwaga o kolejności: pomiar powtórz po każdym kroku, nie dopiero na końcu. Praca na danych katalogowych bywa żmudna i łatwo stracić poczucie, czy cokolwiek to daje. Liczba zapytań na listingu spadająca po ujednoliceniu wartości atrybutów jest tym dowodem, który utrzymuje zespół przy tej pracy do końca.

    Lista kontrolna

    • liczba zapytań na listingu porównana ze stroną główną i z listingiem po zawężeniu
    • wartości atrybutów ujednolicone, bez czterech zapisów tego samego koloru
    • filtry ograniczone do klikanych, przypisane do właściwych kategorii
    • żaden filtr nie prowadzi do pustego wyniku w kategorii, do której jest przypisany
    • liczba zapytań nie rośnie proporcjonalnie do liczby produktów na stronie
    • listing bez filtrów serwowany z cache, unieważnianie działa po zmianie ceny
    • miniatury w rozmiarze odpowiadającym wyświetlanemu, pierwszy rząd nieodroczony

    Listing jest tą stroną, na której klient decyduje, czy zostaje w sklepie. Warto ją mierzyć osobno od strony głównej, bo to dwa zupełnie różne obciążenia, a raport uśredniający oba pokazuje wynik, którego nie doświadcza żaden realny użytkownik. Kolejność wszystkich obszarów porządkuje przewodnik o optymalizacji PrestaShop.

    Zasady działania nawigacji fasetowej i sposób jej konfiguracji opisuje dokumentacja deweloperska PrestaShop.

    Najczęściej zadawane pytania

    • Dlaczego listing kategorii działa wolniej niż karta produktu?

      Karta produktu odpytuje bazę o jeden rekord. Listing musi znaleźć zbiór produktów, policzyć go, ustalić dostępne wartości każdego filtra i przy każdej podać liczbę pasujących pozycji. Przy czterech filtrach po pięć wartości to dwadzieścia dodatkowych obliczeń na każde wyświetlenie.

    • Czy warto zrezygnować z liczników przy filtrach?

      To decyzja handlowa, nie techniczna. Liczniki pomagają klientowi, ale są najdroższym elementem nawigacji fasetowej. W sklepach z bardzo dużym katalogiem bywa to jedyna zmiana, która realnie odblokowuje listing.

    • Ile produktów pokazywać na stronie listingu?

      Rozstrzygnięcie znajdziesz w danych. Jeśli większość klientów nie przechodzi poza pierwszą stronę, zwiększenie liczby pozycji skraca im drogę. Jeśli przeglądają głębiej, lepiej zostawić mniejsze strony i zadbać o szybkie przechodzenie między nimi.

    • Kiedy potrzebny jest zewnętrzny silnik filtrowania?

      Gdy listing odpowiada wolno mimo uporządkowanych wartości atrybutów i dołożonych indeksów, gdy klienci zawężają wybór wieloma parametrami naraz albo gdy liczniki są konieczne i nie da się z nich zrezygnować. Wcześniej wyczerp tańsze warstwy, bo silnik na nieuporządkowanych danych da te same rozdrobnione filtry.

    • Czy adresy z filtrami buforować?

      Listing bez filtrów i popularne zawężenia tak, rzadkie kombinacje nie. Generowanie ich na żądanie jest tańsze niż utrzymywanie w pamięci wariantów odwiedzanych raz w miesiącu. Pilnuj unieważniania po zmianie ceny i stanu magazynowego.

    O autorze

    Rafał Skotarczak

    Programista PHP z 6-letnim doświadczeniem we wdrożeniach platformy PrestaShop. Przekształca wizje biznesowe w stabilne, szybkie i dochodowe sklepy internetowe. W swojej codziennej pracy łączy techniczną wiedzę z zakresu optymalizacji kodu, konfiguracji serwerów oraz integracji systemów ERP i PIM z unikalnym podejściem do UX (User Experience). Przez ponad sześć lat skutecznie uruchomił, zmigrował i zoptymalizował dziesiątki e-sklepów, pomagając markom zwiększać konwersję i automatyzować procesy sprzedażowe. Na blogu dzieli się praktyczną wiedzą, analizami case studies oraz sprawdzonymi trikami, które pomagają właścicielom sklepów wycisnąć maksimum możliwości z ekosystemu PrestaShop.

    Czytaj dalej