Optymalizacja PrestaShop: jak przyspieszyć sklep i co daje efekt

Optymalizacja PrestaShop w praktyce zaczyna się od jednego pytania: dlaczego sklep ładuje się wolno i co skraca ten czas najbardziej. Odpowiedź jest nudniejsza, niż sugerują poradniki. W sklepach, które działają od kilku lat, prędkość odbiera zwykle pięć rzeczy: wyłączony albo nieskuteczny cache, brak reverse proxy przed sklepem, nieprzygotowane obrazy, rozrośnięta baza danych i moduły odpytujące zewnętrzne usługi w trakcie generowania strony. Reszta to detale.

Ten przewodnik prowadzi przez przyspieszanie sklepu w kolejności, która daje efekt najszybciej: od pomiaru, przez cache i serwer, po zasoby front-endu. Na końcu pokazuje, co robić, gdy sklep jest już szybki, a zamówień nie przybywa, bo to druga połowa tego samego problemu.

Ile powinien ładować się sklep na PrestaShop

Progi nie są kwestią opinii. Google publikuje je jako Core Web Vitals i mierzy na realnym ruchu, nie w laboratorium:

Definicje i metodologię opisuje dokumentacja Google na web.dev. Progi dotyczą każdego szablonu osobno, a nie sklepu jako całości, i to jest pierwsza rzecz, którą warto sobie uświadomić. Druga: dotyczą osobno telefonu i komputera, a różnica bywa duża, o czym piszemy przy wydajności mobilnej PrestaShop. Strona główna bywa szybka, bo jest zbuforowana i prosta. Karta produktu i listing kategorii, czyli szablony odpowiadające za sprzedaż, zachowują się zupełnie inaczej.

Drugie rozróżnienie, bez którego łatwo wydać pieniądze nie tam, gdzie trzeba: czas odpowiedzi serwera to nie to samo co czas wyświetlenia treści. Pierwszy zależy od bazy, cache i kodu PHP. Drugi od tego, co dzieje się już w przeglądarce: od obrazów, czcionek, skryptów i kolejności ich ładowania. Sklep bywa wolny w jednej z tych warstw i całkiem sprawny w drugiej, a każda wymaga innych prac i innych ludzi.

Optymalizacja PrestaShop zaczyna się od pomiaru, nie od zmian

Bez punktu odniesienia cała praca kończy się dyskusją, czy „jest szybciej”. Zbierz trzy rzeczy, zanim ktokolwiek dotknie konfiguracji. Zajmuje to jeden dzień.

Pomiar z realnego ruchu, nie z testu

Wskaźnik z pojedynczego testu laboratoryjnego mierzy jedną symulowaną wizytę na jednym łączu. Optymalizacja pod ten wynik potrafi pogorszyć doświadczenie realnego użytkownika, na przykład przez odroczenie zasobów, które są mu potrzebne od razu. Zbieraj dane od użytkowników i rozbijaj je osobno na stronę główną, listing kategorii, kartę produktu i checkout.

Rozbicie na urządzenia

Ruch mobilny w większości sklepów detalicznych przeważa, a wyniki na telefonie są wyraźnie gorsze. Uśredniony pomiar ukrywa problem, który występuje tylko na jednym typie urządzeń. Osobna uwaga dla weryfikacji na produkcji: cache stron trzyma odrębne wersje dla desktopu i dla urządzeń mobilnych, więc „działa u mnie” nie znaczy „działa dla klienta”.

Liczba zapytań do bazy na wyświetlenie strony

To pojedyncza liczba, która rozstrzyga więcej niż jakikolwiek wynik punktowy. Zmierz ją na trzech szablonach: stronie głównej, listingu kategorii z włączonymi filtrami i karcie produktu. Listing generujący wielokrotnie więcej zapytań niż strona główna wskazuje wprost na nawigację fasetową albo na moduł odpytujący bazę w pętli po produktach. Zanim zamówisz mocniejszy serwer, sprawdź tę liczbę. Mocniejsza maszyna tylko przesuwa moment, w którym problem wróci.

Pięć minut, które zastępuje połowę audytu

Zanim sięgniesz po narzędzia, wykonaj jedno ćwiczenie: wejdź na własny sklep z telefonu, przez sieć komórkową, poza domem i poza biurem. Nie przez wi-fi i nie na urządzeniu, na którym sklep jest już w pamięci podręcznej. Przejdź od strony głównej przez wyszukiwarkę do karty produktu i dodaj coś do koszyka.

To pokazuje rzeczy, których nie widać w żadnym raporcie, bo nie generują zdarzeń: baner ładujący się sekundę po reszcie strony i przesuwający treść w dół, zdjęcie produktu doładowujące się dopiero po przewinięciu, przycisk dodania do koszyka reagujący z opóźnieniem. Zespół pracujący codziennie na szybkim łączu i na zbuforowanej wersji sklepu tych rzeczy po prostu nie zobaczy.

Zapisz wyniki razem z datą i warunkami pomiaru. Bez tego po kwartale nie da się rozstrzygnąć, czy praca była warta pieniędzy. Jeśli nie chcesz zbierać tego samodzielnie, dokładnie tym jest audyt e-commerce.

Co spowalnia sklep na PrestaShop najczęściej

Lista jest krótka i powtarza się między sklepami. Kolejność odpowiada temu, jak często dana rzecz okazuje się główną przyczyną.

Trzy pierwsze pozycje odpowiadają za większość przypadków i wszystkie trzy da się zaadresować bez pisania kodu. To jest powód, dla którego warto zacząć właśnie od nich.

Warto też wiedzieć, jak odróżnić te przyczyny od siebie bez zgadywania. Każda zostawia inny ślad w pomiarze i wystarczą trzy porównania.

Serwer czy przeglądarka

Jeśli czas odpowiedzi serwera jest wysoki, a od jego otrzymania do wyświetlenia treści mija niewiele, pracujesz nad cache, bazą i hostingiem. Jeśli odwrotnie, serwer odpowiada szybko, a strona wyświetla się z opóźnieniem, przyczyna leży w obrazach, skryptach i kolejności ładowania. Ta jedna para liczb dzieli cały projekt na dwie zupełnie różne ścieżki.

Stale czy tylko pod obciążeniem

Sklep równomiernie powolny o każdej porze wskazuje na konfigurację albo hosting. Sklep, który zwalnia w godzinach szczytu i wraca do formy w nocy, wskazuje na brak reverse proxy albo na wyczerpywanie się zasobów serwera. To rozróżnienie rozstrzyga, czy potrzebujesz zmiany ustawień, czy zmiany infrastruktury.

Wszędzie czy tylko na listingu

Gdy strona główna i karta produktu działają sprawnie, a listing kategorii wyraźnie odstaje, przyczyną jest niemal zawsze nawigacja fasetowa na rozbudowanym katalogu atrybutów. To nie jest problem serwera i mocniejsza maszyna go nie usunie. Rozwiązaniem jest ograniczenie liczby filtrów do tych, których klienci realnie używają, oraz przypisanie zestawów filtrów do konkretnych kategorii zamiast pokazywania wszystkiego wszędzie. Cały ten wątek rozkładamy w tekście o wydajności listingu PrestaShop.

Cache i reverse proxy: największa pojedyncza oszczędność

PrestaShop ma własny mechanizm buforowania szablonów i zestaw ustawień, które łączą oraz kompresują pliki stylów i skryptów. To warstwa pierwsza i najtańsza. Jej włączenie bywa jedyną zmianą, jakiej sklep potrzebował, a zdarza się być wyłączona, bo ktoś kiedyś diagnozował problem i nie wrócił do ustawień.

Warstwa druga to reverse proxy przed sklepem, czyli Vinyl cache, znany do 2026 roku jako Varnish Cache. Jest to standard branżowy, nie autorskie rozwiązanie. Serwuje gotowe strony bez uruchamiania PHP i bez odpytywania bazy, co zmienia charakter sklepu pod obciążeniem: czas odpowiedzi przestaje rosnąć wraz z ruchem.

Co psuje cache i jak to rozpoznać

Najczęstszy problem nie polega na braku cache, tylko na jego omijaniu. Element wyświetlający treść zależną od zalogowanego użytkownika, licznik koszyka renderowany po stronie serwera albo moduł rekomendacji potrafi wyłączyć buforowanie całej strony. Sklep ma wtedy skonfigurowany cache i nie korzysta z niego na tych szablonach, na których zależy najbardziej.

Sposób diagnozy i rozłożenie tej liczby na składniki opisujemy w tekście o czasie odpowiedzi serwera PrestaShop. Rozpoznanie zajmuje minutę: pobierz tę samą stronę dwa razy z rzędu i porównaj czasy odpowiedzi. Jeśli drugie pobranie nie jest wyraźnie szybsze, strona nie jest serwowana z cache. Powtórz to dla strony głównej, listingu i karty produktu, bo każdy szablon może zachowywać się inaczej.

Rozwiązaniem nie jest rezygnacja z dynamicznych elementów, tylko wyjęcie ich poza buforowaną stronę i dociąganie osobno. Licznik koszyka i personalizowane rekomendacje mogą doładować się po wyświetleniu strony, nie blokując jej generowania.

Czego nie wolno buforować

Lista jest krótka i trzeba ją ustalić przed wdrożeniem, nie po pierwszym zgłoszeniu od klienta. Poza buforowaniem zostają: koszyk, wszystkie kroki checkoutu, konto klienta wraz z historią zamówień, wyniki wyszukiwania wewnętrznego oraz każda strona pokazująca indywidualne ceny. Ostatni punkt jest szczególnie ważny w sprzedaży hurtowej, gdzie cennik zależy od zalogowanej firmy, a pomyłka oznacza pokazanie jednemu kontrahentowi warunków drugiego.

Drugą rzeczą do ustalenia jest sposób unieważniania cache. Zmiana ceny albo stanu magazynowego musi trafić do klienta natychmiast, a nie po wygaśnięciu wpisu. Sklep bez tego mechanizmu sprzedaje towar, którego nie ma, i pokazuje ceny sprzed promocji. Automatyczne czyszczenie po zapisie produktu jest tu minimum, a przy imporcie z systemu ERP trzeba je wywołać osobno, bo import zwykle omija ścieżkę, która wyzwala to zdarzenie.

Serwer i baza danych

Hosting współdzielony jest tanim startem i twardym sufitem. Objaw jest charakterystyczny: czas odpowiedzi serwera pozostaje wysoki niezależnie od tego, co zmieniasz w sklepie, a wieczorami bywa gorszy niż rano, bo zasoby dzielisz z innymi. Żadna optymalizacja po stronie aplikacji tego nie przeskoczy.

Warto przy tym odróżnić dwie liczby, które brzmią podobnie. Czas odpowiedzi przy pojedynczej wizycie mówi o konfiguracji. Czas odpowiedzi przy dwudziestu jednoczesnych wizytach mówi o tym, ile sklep uniesie. Sklep bywa poprawny w pierwszym pomiarze i rozsypuje się w drugim, a to właśnie drugi decyduje o tym, co się stanie w tygodniu największej sprzedaży.

Po stronie bazy danych sklepy z historią mają zwykle ten sam zestaw problemów. Tabele logów i statystyk rosną latami i nikt ich nie czyści. Porzucone koszyki oraz sesje gości zajmują wielokrotnie więcej miejsca niż realne zamówienia. Po dołożeniu własnych pól brakuje indeksów na kolumnach używanych do filtrowania, więc panel i listingi zwalniają razem z katalogiem.

Rodzaje hostingu i co realnie zmieniają

Przejście na mocniejszy serwer bez administracji bywa zmianą pozorną. Sam VPS nie ma skonfigurowanego reverse proxy, nie ma dobranych limitów PHP i nie ma monitoringu, więc sklep dostaje więcej zasobów i nadal marnuje ich większość. Wartość jest w konfiguracji, nie w parametrach.

Warto to rozdzielić, bo to dwie różne rozmowy i dwa różne budżety. Czyszczenie i indeksy to praca jednorazowa o przewidywalnym zakresie. Zmiana hostingu to decyzja na lata, którą podejmuje się raz i której nie warto odkładać, jeśli pomiar wskazuje na serwer. Parametry, na których nie warto oszczędzać, oraz pracę na samej bazie rozkładamy osobno, w ramach usługi optymalizacja wydajności PrestaShop.

Obrazy, skrypty i style

Gdy serwer odpowiada szybko, a strona nadal wyświetla się z opóźnieniem, przyczyna leży w przeglądarce. W sklepach dominuje jedna: obrazy. Pełny zakres prac nad nimi opisujemy przy optymalizacji obrazów PrestaShop, a warstwę stylów, skryptów i czcionek przy optymalizacji skryptów PrestaShop.

• Zdjęcia wgrywane w rozdzielczości aparatu. PrestaShop generuje miniatury, ale robi to z oryginału, a na karcie produktu przy powiększeniu bywa serwowany plik pełnowymiarowy. Ustal jeden rozsądny rozmiar oryginału i trzymaj się go przy imporcie.
• Format sprzed dekady. Nowoczesne formaty obrazów dają wyraźnie mniejsze pliki przy tej samej jakości. To zmiana konfiguracyjna, nie projektowa.
• Brak wymiarów w kodzie obrazu. Przeglądarka nie wie, ile miejsca zarezerwować, więc układ przeskakuje podczas ładowania. To jest dokładnie to, co mierzy CLS, a przy okazji powód kliknięć w niewłaściwe miejsce na telefonie.
• Odroczenie obrazu, który jest widoczny od razu. Leniwe ładowanie zastosowane do zdjęcia głównego na karcie produktu pogarsza LCP zamiast go poprawiać.

Przy skryptach obowiązuje jedna zasada porządkująca: sprawdź, co ładuje się na każdej stronie, choć jest potrzebne na jednej. Moduł obsługujący wyłącznie checkout dokładający swoje pliki do strony głównej to typowy przypadek. Osobno przejrzyj skrypty zewnętrzne dołożone przez marketing, bo one rzadko przechodzą przez czyjąkolwiek kontrolę, a potrafią blokować wyświetlanie treści.

Czcionki, o których nikt nie pamięta

Czcionki firmowe są w sklepach traktowane jak element identyfikacji, a zachowują się jak zasób blokujący. Przeglądarka wstrzymuje wyświetlenie tekstu do momentu pobrania pliku, więc klient patrzy na pustą stronę mimo że treść jest już gotowa. Dwie zmiany usuwają ten problem: wskazanie zastępczej czcionki systemowej na czas pobierania oraz ograniczenie zestawu do odmian, które są realnie używane. Sklepy potrafią ładować sześć odmian jednego kroju, korzystając z dwóch.

Osobno warto sprawdzić, skąd czcionki są pobierane. Serwowanie ich z własnego serwera zamiast z usługi zewnętrznej skraca ścieżkę o połączenie z obcym hostem, a przy okazji upraszcza kwestie zgody na przetwarzanie danych, bo przeglądarka nie odpytuje wtedy serwera spoza sklepu.

Skrypty dołożone przez marketing

Kody analityczne, piksele, czat, narzędzia do testów i mapy ciepła narastają latami i rzadko przechodzą przez czyjąkolwiek kontrolę techniczną. Każdy z nich dokłada połączenie do obcego serwera, a część potrafi blokować wyświetlanie treści, jeśli została wpięta wysoko w kodzie strony.

Przegląd wykonuje się raz i zajmuje popołudnie: wypisz wszystkie skrypty zewnętrzne, przy każdym ustal właściciela po stronie firmy i pytanie, na które odpowiada. Te bez właściciela wychodzą. Te, które zostają, przenieś do wczytywania asynchronicznego, żeby nie wstrzymywały renderowania. Narzędzie do testów porzucone po jednej kampanii potrafi zostać w kodzie na lata i kosztować przy każdym wyświetleniu strony.

CDN wchodzi na końcu tej listy, nie na początku. Ma sens, gdy sklep sprzedaje na kilka rynków albo gdy ruch jest wyraźnie rozproszony geograficznie. Dołożony do sklepu, który zwalnia z powodu bazy danych, nie zmieni nic poza fakturą.

Co prędkość zmienia w sprzedaży

Nie podamy tu procentu wzrostu konwersji, bo taka liczba zależy od branży, ceny produktu i źródła ruchu, a przepisana z cudzego badania mówi wyłącznie o cudzym sklepie. Warto natomiast rozumieć mechanizmy, przez które prędkość przekłada się na pieniądze, bo one są takie same wszędzie.

Ruch płatny. Kampanie prowadzą na kartę produktu i na listing, czyli na dokładnie te szablony, które w PrestaShop bywają najwolniejsze. Każda sesja utracona przed wyświetleniem treści to zapłacone kliknięcie bez szansy na sprzedaż. To najbardziej bezpośrednie przełożenie prędkości na budżet, jakie istnieje, i najłatwiejsze do policzenia we własnych danych.

Ruch mobilny. Klient na telefonie działa w gorszych warunkach sieciowych i ma niższą tolerancję na czekanie. Ponieważ w większości sklepów detalicznych to on stanowi większość sesji, poprawa na urządzeniach mobilnych daje więcej niż ta sama poprawa na desktopie.

Widoczność organiczna. Core Web Vitals wchodzą w skład sygnałów oceniających doświadczenie na stronie. Ich waga jest mniejsza, niż sugerują branżowe nagłówki, ale przy zbliżonej jakości treści potrafią rozstrzygać. Praktyczny wniosek jest odwrotny do intuicyjnego: nie optymalizuj prędkości pod pozycje, bo to najdroższa możliwa motywacja. Optymalizuj ją pod klienta, a korzyść w wynikach wyszukiwania przyjdzie przy okazji.

Stabilność w szczycie. Osobna sprawa, o której łatwo zapomnieć poza sezonem. Sklep, który radzi sobie przez jedenaście miesięcy, potrafi nie unieść ruchu w tygodniu największej sprzedaży w roku. Kosztem nie jest wtedy gorsza konwersja, tylko niedostępność sklepu w jedynym momencie, który naprawdę się liczy.

Kolejność prac przy przyspieszaniu sklepu

Kolejność wynika z dwóch zasad. Najpierw to, co blokuje resztę. Przy porównywalnym efekcie wybieramy prace bez zmian w kodzie, bo są tańsze i odwracalne.

Etapy drugi i czwarty dają zwykle najwięcej na złotówkę i mieszczą się w pierwszym tygodniu. Etapu ósmego nie zaczynaj wcześniej: po uporządkowaniu cache część modułów przestaje być problemem, a inne dopiero wtedy widać wyraźnie. Sposób wyceniania pojedynczego modułu i porządkowania tej warstwy opisujemy przy okazji optymalizacji modułów PrestaShop.

Ile trwa przyspieszenie sklepu i od czego zależy

Pytanie wraca w każdej rozmowie i uczciwa odpowiedź brzmi: zależy od tego, na którym etapie z powyższej tabeli leży Twoja przyczyna. Dwa pierwsze etapy zamykają się w dniach, dwa ostatnie w tygodniach.

• Ustawienia cache i zasobów to godziny pracy i efekt tego samego dnia. Jeśli sklep miał je wyłączone, bywa to jedyna potrzebna zmiana.
• Obrazy to praca na danych, rozłożona na tyle, ile trwa przepuszczenie katalogu przez jeden proces. Przy dużym katalogu warto zacząć od stu najczęściej odwiedzanych produktów.
• Reverse proxy to konfiguracja serwera plus czas na wyłapanie stron, które nie mogą być buforowane. Koszyk i checkout wymagają wykluczenia, inaczej klienci zobaczą cudze koszyki.
• Baza danych i moduły wymagają środowiska testowego i pełnego przejścia ścieżki zakupowej po każdej partii zmian. To najdłuższy etap i jednocześnie ten, który najłatwiej odłożyć.

Największym pojedynczym czynnikiem opóźniającym nie jest żadna z tych prac, tylko brak środowiska testowego będącego kopią produkcji. Bez niego etapy piąty, szósty i ósmy są zakładem, a nie decyzją, więc zwykle w ogóle się ich nie zaczyna. Jeśli sklep takiego środowiska nie ma, to jest pierwsza rzecz do załatwienia, przed jakąkolwiek optymalizacją.

Najczęstsze błędy przy przyspieszaniu PrestaShop

Cztery rzeczy potrafią cofnąć efekt całej pracy albo wywołać awarię na produkcji. Każda z nich wydarzyła się w realnym sklepie.

Buforowanie koszyka i checkoutu. Reverse proxy wdrożone bez wykluczenia stron zależnych od sesji serwuje jednemu klientowi koszyk drugiego. Jest to jednocześnie awaria i incydent dotyczący danych osobowych, więc lista wykluczeń jest tu ważniejsza od samej konfiguracji.

Odroczenie zasobów potrzebnych od razu. Leniwe ładowanie zastosowane hurtowo obejmuje też zdjęcie główne karty produktu, czyli dokładnie ten element, który mierzy LCP. Wynik w teście rośnie, doświadczenie klienta się pogarsza.

Łączenie plików bez sprawdzenia sklepu. Opcje łączenia i kompresji skryptów potrafią rozłożyć konfigurator produktu albo wybór punktu odbioru w checkoucie. Po ich włączeniu przejdź pełną ścieżkę zakupową, nie tylko stronę główną.

Pełne czyszczenie cache na produkcji w godzinach ruchu. Jednoczesne unieważnienie wszystkiego zmusza serwer do wygenerowania każdej strony od nowa, więc sklep zwalnia dokładnie wtedy, gdy chciałeś go przyspieszyć. Cache czyść punktowo, dla konkretnych adresów.

Gdy sklep jest już szybki, a zamówień nie przybywa

Prędkość usuwa przeszkodę, ale nie tworzy sprzedaży. Sklep potrafi ładować się w sekundę i nie sprzedawać, bo klient nie znajduje produktu w nawigacji albo odpada na trzecim kroku koszyka. Gdy pomiar pokazuje, że progi Core Web Vitals są spełnione, a lejek nadal się sypie, przyczyna leży w jednym z sześciu pozostałych obszarów.

Rozstrzyga to jedno ćwiczenie: policz sesje na każdym etapie w liczbach bezwzględnych, od listingu przez kartę produktu i koszyk aż po zamówienie. Największy spadek między dwoma sąsiednimi etapami wskazuje obszar.

Klienci wchodzą na listing i wychodzą bez kliknięcia w produkt. Problem leży w strukturze kategorii, atrybutów i filtrów, a nie w prędkości. Typowy objaw to filtry prowadzące do pustych wyników albo drzewo kategorii, którego nikt w firmie nie potrafi narysować z pamięci. Rozkładamy to w tekście o optymalizacji katalogu PrestaShop.

Duży udział wyszukiwań kończy się zerem wyników. Indeks nie zna słów, których używają klienci, albo nie zawiera pól, po których szukają: symbolu producenta, kodu EAN, nazwy marki. O wyszukiwarce wewnętrznej PrestaShop piszemy osobno, bo w tym obszarze efekt widać najszybciej ze wszystkich.

Ruch dochodzi do koszyka i nie kończy zamówienia. Najczęściej odpowiada za to koszt dostawy ujawniony dopiero po podaniu adresu albo walidacja odrzucająca poprawne dane, na przykład numer telefonu ze spacjami. Temat rozwijamy przy optymalizacji checkoutu PrestaShop.

Wyszukiwarki indeksują wiele wariantów tej samej strony. PrestaShop generuje adresy z kilku źródeł naraz, a nawigacja fasetowa dokłada do tego kombinacje filtrów. To warstwa adresów kanonicznych, duplikatów i przekierowań, czyli zakres optymalizacji SEO PrestaShop.

Każda zmiana w sklepie trwa długo i psuje coś innego. Koszt siedzi w warstwie nadpisań i modułów dokładanych przez lata przez różnych wykonawców. Sposób jej zinwentaryzowania i uporządkowania opisujemy przy optymalizacji modułów PrestaShop.

Zespół prowadzi arkusz równolegle do panelu. To najmocniejszy sygnał, jaki istnieje, i zawsze oznacza konkretną lukę w konfiguracji albo w integracji. Procesy obsługi zamówień, statusy i uprawnienia porządkujemy w tekście o optymalizacji back office PrestaShop.

Każdy z tych obszarów ma własne narzędzia i własne osoby po stronie firmy. Prędkość i moduły wymagają wykonawcy technicznego, katalog i wyszukiwarka są pracą zespołu handlowego, a back office w pierwszych krokach nie wymaga programisty w ogóle. To rozdzielenie skraca projekt bardziej niż jakakolwiek metodyka, bo pozwala prowadzić kilka wątków równolegle zamiast ustawiać je w kolejce do jednego wykonawcy.

Czego nie optymalizować

Wyniku punktowego narzędzia. Sto punktów w teście laboratoryjnym przy LCP powyżej progu na realnym ruchu oznacza, że optymalizowano test, a nie sklep. Liczy się pomiar od użytkowników.

Stron bez ruchu. Sekcja informacyjna z kilkunastoma wizytami miesięcznie nie zasługuje na ten sam nakład co karta produktu.

Milisekund poniżej progu. Skrócenie LCP z 2 s do 1,8 s nie zmieni wyniku sprzedażowego. Te same pieniądze wydane na obszar, w którym lejek realnie się sypie, zwrócą się wielokrotnie.

Aktualizacji wersji jako celu samego w sobie. Ma sens, gdy odblokowuje konkretną rzecz: wsparcie bezpieczeństwa, wymaganą wersję PHP, funkcję potrzebną w sprzedaży. Wykonana bez tego powodu przenosi wszystkie istniejące modyfikacje na nowe podłoże i zabiera czas potrzebny gdzie indziej.

Jak utrzymać prędkość po zakończeniu prac

Sklep wraca do stanu sprzed optymalizacji szybciej, niż się do niego dochodziło. Nowy moduł marketingowy dokłada skrypty, kampania wymusza baner z dużym zdjęciem, integracja dopisuje atrybuty i listing zaczyna generować więcej zapytań. Bez punktu kontrolnego po kilku miesiącach zostaje ten sam obraz co na początku.

• Alert na progu, nie przegląd w kalendarzu. Powiadomienie, gdy LCP na karcie produktu przekroczy 2,5 s albo gdy czas odpowiedzi serwera wzrośnie. Reagujesz na zmianę, nie na datę.
• Pomiar przed i po przy każdym nowym module. Czas generowania strony i liczba zapytań do bazy. Moduł, który nie zarabia na swój koszt, nie wchodzi.
• Reguła dla zdjęć. Jeden ustalony rozmiar oryginału przy imporcie. To najczęstsza droga, którą prędkość wycieka z powrotem.
• Kontrola cache po każdym wdrożeniu. Dwa pobrania tej samej strony i porównanie czasów. Kwadrans, a wyłapuje sytuację, w której nowy element zaczął omijać buforowanie.

W sklepach rozwijanych intensywnie ten nadzór zamyka się w stałej opiece technicznej, gdzie przegląd wydajności jest częścią umowy, a nie osobnym zleceniem. Zakres takiej współpracy opisujemy przy okazji wsparcia technicznego PrestaShop. Same progi alertów i dziennik zmian rozkładamy w tekście o monitoringu wydajności PrestaShop.

Co z tego wynika dla Twojego sklepu

Jeśli masz zebrać z tego tekstu jedną rzecz: zmierz czas odpowiedzi serwera i LCP osobno, na karcie produktu i na listingu kategorii, z realnego ruchu. Ta jedna para liczb rozstrzyga, czy pracujesz nad cache i serwerem, czy nad obrazami i skryptami. Bez niej każda decyzja jest zgadywaniem, a zgadywanie w tym obszarze bywa drogie.

Druga rzecz: prędkość jest warunkiem, nie celem. Sklep szybki i nieuporządkowany sprzedaje gorzej niż wolniejszy sklep z sensowną nawigacją i checkoutem, który nie odrzuca poprawnych danych. Dlatego po domknięciu progów Core Web Vitals warto od razu policzyć lejek i sprawdzić, gdzie leży kolejny największy spadek.

Trzy rzeczy warto rozstrzygnąć, zanim prace ruszą, bo każda potrafi je zatrzymać w połowie. Czy istnieje środowisko testowe będące kopią produkcji, bo bez niego zmiany w cache i modułach są zakładem. Kto po stronie firmy decyduje o kompromisach między wyglądem a prędkością, bo ta rozmowa zawsze się pojawia. I jaka liczba ma się poprawić oraz o ile, żeby po kwartale dało się powiedzieć, czy było warto.

Kompromis między wyglądem a prędkością zasługuje na osobne zdanie, bo to on najczęściej blokuje projekt. Karuzela na stronie głównej z sześcioma zdjęciami w pełnej rozdzielczości, wideo w tle nagłówka i trzy kroje pisma to decyzje projektowe, które mają swoją cenę mierzoną w sekundach. Nikt z zespołu technicznego nie usunie ich samodzielnie, bo to nie jest jego decyzja. Wskazanie osoby, która może ją podjąć, jest warunkiem, żeby prace nie zatrzymały się na etapie czwartym.

Na koniec rzecz, o którą warto zapytać każdego wykonawcy przed rozpoczęciem współpracy: jak zmierzy efekt swojej pracy i co pokaże na koniec. Odpowiedź „poprawimy wynik w narzędziu” oznacza optymalizowanie testu. Odpowiedź „porównamy LCP i czas odpowiedzi z realnego ruchu na karcie produktu, przed i po” oznacza, że rozmawiacie o tym samym.