Wydajesz budżet na kampanie, influencerów i lejki mailowe. Ruch rośnie, użytkownicy wchodzą na stronę i zderzają się ze ścianą. Strona ładuje się cztery sekundy, zmiana baneru promocyjnego zajmuje tydzień, a podczas najważniejszej wyprzedaży w roku serwer zwraca błąd 503.
To nie jest pech, tylko rachunek za dług technologiczny. Nazwa brzmi jak problem działu IT, ale skutki są w całości biznesowe: niższe pozycje w wyszukiwarce, wolniejsza reakcja na rynek i przepalone budżety reklamowe. Poniżej pokazujemy cztery obszary, w których ten dług narasta najczęściej, oraz to, co realnie da się z nimi zrobić.
Czym jest dług technologiczny w sklepie internetowym
Zaniedbania w infrastrukturze rzadko objawiają się nagłą awarią. To proces powolnej degradacji. Sklep działa, ale z każdym miesiącem staje się cięższy, wolniejszy i trudniejszy w utrzymaniu.
Każdy moduł zainstalowany „na szybko”, każdy snippet trackingowy wrzucony bez sprawdzenia wpływu na wydajność i każda odłożona aktualizacja to zaciągnięcie pożyczki. Spłacasz ją codziennie, w postaci utraconych konwersji i wydłużonego czasu wdrażania zmian. Kiedy konkurencja reaguje na zmianę rynkową w kilka godzin, Twój zespół marketingu czeka w kolejce do działu technicznego.
Core Web Vitals, czyli jak dług technologiczny uderza w SEO
Google ocenia stronę między innymi po trzech metrykach: LCP (czas załadowania największego elementu), INP (responsywność na interakcje użytkownika) i CLS (stabilność wizualna układu). To zestaw obowiązujący od marca 2024 roku, kiedy INP zastąpił wcześniejsze FID.
Ważny szczegół, który zmienia sposób myślenia o tych wskaźnikach: Google nie mierzy ich robotem indeksującym. Sygnał opiera się na danych polowych z Chrome User Experience Report, zbieranych od realnych użytkowników przeglądarki, w oknie kroczącym obejmującym 28 dni. Konsekwencja jest praktyczna. Po wdrożeniu poprawek nie zobaczysz efektu następnego dnia, tylko po kilku tygodniach, gdy nowe pomiary wypełnią okno.
Widzieliśmy sklep, który rok wcześniej miał LCP na poziomie około 1,4 sekundy, a po kilkunastu miesiącach dokładania modułów i skryptów zszedł do 4 do 5 sekund, czyli z wyniku dobrego do przedziału ocenianego jako słaby. Nic się przy tym nie zepsuło. Po prostu każda kolejna integracja dołożyła własne pliki CSS i JavaScript, które przeglądarka musi przetworzyć, zanim pokaże treść.
Warto mieć świadomość, że rynek jako całość idzie w drugą stronę. Według Web Almanac 2025 odsetek witryn z dobrym wynikiem Core Web Vitals na urządzeniach mobilnych wzrósł z 36 procent w 2023 roku do 48 procent w 2025. Sklep, który stoi w miejscu, nie utrzymuje pozycji, tylko cofa się względem konkurencji.
Skąd bierze się nadmiar plików w PrestaShop
Częsty argument brzmi: sklep ma czterdzieści kilka modułów, więc jest przeładowany. Ta liczba sama w sobie niczego nie dowodzi. Oficjalna dokumentacja PrestaShop wymienia 58 modułów natywnych dołączanych do wydania, tak samo dla wersji 8 i 9. Sklep z czterdziestoma aktywnymi modułami ma ich zatem mniej niż świeżo postawiona instalacja.
Problemem nie jest liczba, tylko zachowanie. Wiele modułów rejestruje własne pliki CSS i JavaScript globalnie, czyli na każdej podstronie, niezależnie od tego, czy ich funkcja jest tam w ogóle używana. Moduł obsługujący wyłącznie kartę produktu potrafi ładować swoje zasoby także na stronie głównej, w koszyku i na blogu. Przy kilkudziesięciu modułach daje to dziesiątki plików, z których na konkretnej podstronie potrzebna jest garstka.
Leczy się to trzema rzeczami: przeglądem, które moduły rejestrują zasoby globalnie, ograniczeniem ładowania do kontrolerów, na których dana funkcja faktycznie działa, oraz usunięciem modułów, które nie pełnią już żadnej funkcji biznesowej. Szerzej opisujemy ten proces w materiale o optymalizacji aplikacji PrestaShop.
Czas wdrożenia zmian, czyli marketing czekający na programistę
Marketing chce dodać baner na stronie głównej, zmienić układ strony kategorii albo opublikować landing pod kampanię. W zadbanym sklepie to kwestia godzin. W sklepie z długiem technologicznym, dni albo tygodni.
Powód pierwszy leży w szablonie. Motywy pisane bez myśli o elastyczności zamieniają każdą zmianę w ryzyko, bo modyfikacja w jednym miejscu wywołuje błąd w zupełnie innym. Kiedy do tego dochodzi brak porządnego wersjonowania albo zaśmiecone repozytorium, nikt w zespole nie potrafi powiedzieć, co można bezpiecznie ruszyć. Efekt jest taki, że programiści zaczynają unikać zmian, a nie je wdrażać.
Powód drugi to brak warstwy zarządzania treścią. Jeśli zmiana baneru, bloku tekstowego albo sekcji na stronie głównej wymaga edycji plików szablonu, każda taka operacja przechodzi przez zgłoszenie, kolejkę zadań i wdrożenie. Proste polecenie „zmień baner na nową promocję” zamienia się w kilkudniowy proces, a testowanie kilku wariantów komunikatu przestaje być w praktyce możliwe.
To jest realna forma długu technologicznego, tylko rzadko tak nazywana. Nie widać jej w żadnej metryce wydajnościowej, a bezpośrednio ogranicza tempo działań marketingowych. Rozwiązaniem jest warstwa, która oddaje zespołowi marketingu kontrolę nad treścią bez udziału programisty. W naszych wdrożeniach odpowiada za to Moduł Zarządzanie boksami, dostępny w standardzie WayBox. Efekt biznesowy jest prosty: zmiana komunikacji przestaje być zadaniem dla działu IT.
Przestarzały stack technologiczny
Utrzymywanie starych wersji oprogramowania bywa przedstawiane jako oszczędność. W praktyce jest odwrotnie, bo koszt narasta i płacisz go w innym miejscu.
Aktualizacja PHP, czyli ile realnie można zyskać
Podniesienie wersji PHP bywa opisywane jako darmowy skok wydajności o kilkadziesiąt procent. Rzeczywistość jest bardziej zróżnicowana i warto znać prawdziwe liczby, żeby nie budować oczekiwań, których migracja nie spełni.
W testach Kinsty (ApacheBench, włączony OPcache, aktualizacja z grudnia 2025) przejście z PHP 7.4 na 8.2 daje dla WordPressa około 5 procent poprawy przepustowości, ze 139 do 146 żądań na sekundę. Dla WooCommerce, czyli aplikacji e-commerce z realną logiką biznesową, ta sama zmiana daje już około 24 procent, z 44 do 55 żądań na sekundę. Kierunek jest więc jednoznaczny, a im cięższa aplikacja, tym większy zysk, ale przedział zależy od tego, co dokładnie mierzymy.
Ważniejsze od samego procentu jest to, że sklepy z długiem technologicznym nie mogą z tej poprawy skorzystać. Migracja wymaga wcześniejszego uporządkowania kodu: usunięcia funkcji wycofanych, poprawienia typowania i sprawdzenia zgodności wszystkich modułów. W ekosystemie PrestaShop blokują ją zwykle moduły zewnętrzne napisane w starych wzorcach. Sklep zostaje zamrożony na wersji, która traci wsparcie bezpieczeństwa, a każdy kolejny miesiąc zwiększa koszt późniejszego wyjścia.
Zależności, które nikt już nie potrzebuje
Przestarzałe moduły potrafią ładować kilka wersji biblioteki jQuery jednocześnie, blokując renderowanie strony. Dokładają polyfille, czyli kod obsługujący przeglądarki, których nie ma już na rynku. Ładują też fonty synchronicznie z zewnętrznych źródeł, zatrzymując wyświetlanie treści do czasu odpowiedzi cudzego serwera.
Skala pojedynczego polyfilla to kilkadziesiąt kilobajtów, więc nie jest to problem wagi strony. Problemem jest moment: te pliki blokują renderowanie, czyli opóźniają pokazanie czegokolwiek użytkownikowi, i wprost pogarszają LCP.
Brak strategii cache
Sklep bez warstwy buforowania generuje pełne renderowanie strony dla każdego odwiedzającego. Przy każdym wejściu serwer odpytuje bazę danych, przetwarza logikę biznesową i składa szablon od zera.
Przy zwykłym ruchu to działa. Problem zaczyna się, gdy marketing odpala kampanię. Wysyłka do stu tysięcy subskrybentów przy średniej rynkowej klikalności rzędu 2 procent oznacza mniej więcej dwa do trzech tysięcy dodatkowych sesji, z czego około połowa przypada na pierwszą godzinę lub dwie. Czy będzie to dla Twojego serwera skok dwukrotny czy dziesięciokrotny, zależy wyłącznie od tego, ile ruchu masz na co dzień. Sklep bez cache tego nie wytrzymuje: baza nie nadąża, procesor dobija do stu procent, a klienci zamiast koszyka widzą błąd 503. Budżet zainwestowany w ściągnięcie tego ruchu zostaje przepalony.
Vinyl Cache i CDN
Prawidłowo zaprojektowana architektura rozwiązuje to systemowo, dwiema warstwami.
Vinyl Cache (dawniej Varnish) to reverse proxy stojący przed aplikacją. Serwuje gotowe odpowiedzi z pamięci RAM, całkowicie omijając cykl PHP, zapytania do bazy i renderowanie szablonu. W naszych wdrożeniach zdejmuje z serwera aplikacyjnego około 90 procent ruchu, czyli dziewięć wejść na dziesięć obsługiwanych jest bez wysiłku serwera. Obciążenie w szczycie spada z około 100 procent do około 20, a czas otwarcia strony z 3 do 5 sekund poniżej pół sekundy.
CDN przejmuje dystrybucję zasobów statycznych: obrazów, plików CSS i JavaScript oraz fontów. To razem około 70 procent wagi typowej strony, według pomiarów Web Almanac 2025. Serwowane są z węzłów położonych geograficznie blisko użytkownika, co skraca czas pobierania niezależnie od obciążenia Twojego serwera.
Efekt złożenia obu warstw jest taki, że silnik PrestaShop przetwarza wyłącznie to, co naprawdę wymaga przetworzenia: koszyk, konto klienta i finalizację zamówienia. Cały katalog, czyli strona główna, kategorie i karty produktów, jest serwowany z cache. Dla porównania skali: sam dokument HTML to mediana około 22 kilobajtów, czyli poniżej jednego procenta wagi strony. Cała reszta to zasoby, które nie muszą w ogóle dotykać aplikacji.
Wdrożeniem tej architektury zajmuje się usługa WayBooster.
Bezpieczeństwo, czyli dług, który wystawia rachunek jednorazowo
Poprzednie trzy obszary kosztują stopniowo. Bezpieczeństwo działa inaczej: latami nie widać nic, a potem rachunek przychodzi w całości.
Wektorem ataku są moduły, nie rdzeń
Historia PrestaShop pokazuje to wyraźnie. W lipcu 2022 roku doszło do masowej kampanii wykorzystującej łańcuch podatności oznaczony jako CVE-2022-31181, o ocenie krytyczności 9,8 w skali CVSS. Atakujący łączyli wstrzyknięcie SQL z wstrzyknięciem kodu do mechanizmu cache, co pozwalało wykonać dowolny kod PHP, a w praktyce podmienić formularz płatności i przechwytywać dane kart klientów.
Zgodnie z oficjalnym komunikatem PrestaShop podatne były wersje od 1.6.0.10 wzwyż. Wersje 1.7.8.2 i nowsze były bezpieczne, ale tylko pod jednym warunkiem: jeśli sklep nie używał modułu z własną podatnością na wstrzyknięcie SQL. Typowym przykładem takiego modułu był Wishlist w wersjach od 2.0.0 do 2.1.0, z osobnym numerem CVE-2022-31101. Rdzeń załatano w wersji 1.7.8.7, moduł w 2.1.1.
Wniosek z tej historii jest praktyczny: aktualny rdzeń nie wystarcza. Wystarczy jeden nieaktualizowany moduł od zewnętrznego dostawcy, żeby otworzyć drzwi.
Oficjalne moduły też mają błędy
W październiku 2025 roku poprawki otrzymał moduł PrestaShop Checkout, czyli komponent oficjalny, nie zewnętrzny. Najpoważniejsza z trzech podatności, CVE-2025-61922 o ocenie 9,1, pozwalała przez brak walidacji w płatności ekspresowej zalogować się na konto klienta na podstawie samego adresu e-mail. Druga, CVE-2025-61923, umożliwiała odczyt dowolnego pliku z serwera, ale wymagała już posiadania konta w panelu administracyjnym. Wszystkie naprawiono w wersjach 4.4.1 oraz 5.0.5 modułu.
Dlaczego to jest problem procesu, a nie jednorazowej naprawy
Standardowa instalacja PrestaShop nie ma centralnego mechanizmu informowania o podatnościach w modułach zewnętrznych. Producent wydaje łatkę, publikuje ją w swoim kanale, a właściciel sklepu nie ma jak się o tym dowiedzieć, o ile sam tego nie śledzi. Między publikacją poprawki a jej wgraniem mijają zwykle miesiące, a czasem lata.
Dlatego bezpieczeństwo nie jest zadaniem, które się odhacza, tylko procesem: stałym śledzeniem nowych podatności dla każdego zainstalowanego komponentu, oceną, które z nich faktycznie dotyczą Twojej konfiguracji, i wdrażaniem poprawek w kontrolowanym oknie. W ramach WayCare odpowiada za to Tarcza WayShield, która filtruje ruch, zanim dotrze do PrestaShop, uzupełniona o codzienne skanowanie aplikacji pod kątem znanych podatności oraz uwierzytelnianie dwuskładnikowe na panelu administratora.
Jeśli chcesz wiedzieć, jak takie zaniedbania wyglądają w praktyce, opisaliśmy pięć najczęstszych z nich, wraz z konkretnymi znaleziskami z audytów, w materiale o problemach technicznych w PrestaShop.
Ile kosztuje udany atak
Skutki wykraczają poza koszt naprawy. Wyciek danych klientów uruchamia obowiązki wynikające z RODO, w tym zgłoszenie incydentu organowi nadzorczemu w ciągu 72 godzin. Za naruszenie obowiązku zapewnienia bezpieczeństwa przetwarzania z artykułu 32 grozi kara do 10 milionów euro lub do 2 procent całkowitego rocznego światowego obrotu, zależnie od tego, która kwota jest wyższa. Wyższy próg, do 20 milionów euro lub 4 procent obrotu, dotyczy naruszenia podstawowych zasad przetwarzania, a organy nadzorcze często kwalifikują wyciek jednocześnie na obu podstawach.
Do tego dochodzą konsekwencje, których nie widać w kalkulacji ryzyka: konieczność poinformowania klientów o wycieku, oznaczenie domeny jako niebezpiecznej w mechanizmach ochrony przeglądarek, co odcina ruch organiczny budowany latami, oraz przestój sklepu na czas usuwania skutków.
Od czego zacząć
Dług technologiczny ma tę własność, że najtaniej spłaca się go wcześnie. Kolejność, którą stosujemy, wygląda tak.
- Zmierz stan wyjściowy. Core Web Vitals z danych polowych, nie z jednorazowego testu w narzędziu laboratoryjnym. Do tego czas odpowiedzi serwera i lista modułów rejestrujących zasoby globalnie.
- Sprawdź, na czym stoisz. Wersja PrestaShop, wersja PHP, data ostatniej aktualizacji każdego modułu. Ta lista zwykle jest krótsza i starsza, niż zakłada zespół.
- Zacznij od warstwy, która nie wymaga ruszania kodu. Cache i CDN dają największy efekt przy najmniejszym ryzyku regresji, bo nie zmieniają aplikacji.
- Dopiero potem wchodź w kod. Porządkowanie modułów, migracja PHP i refaktoryzacja to prace o realnym ryzyku, więc wykonuje się je na środowisku testowym i z planem wycofania zmian.
Punkt pierwszy i drugi możesz przejść samodzielnie. Jeśli wolisz mieć to opisane z priorytetami i harmonogramem, robimy to w ramach bezpłatnego audytu technicznego PrestaShop, który obejmuje dziewięć obszarów i kończy się raportem z rekomendacjami na 30, 90 i 365 dni.
