Wydajność PrestaShop: mierz, diagnozuj i usprawniaj sklep

Od czego byśmy zaczęli

Właściwa poprawka zależy od istniejącego sklepu: jego motywu, modułów, integracji, danych katalogu, hostingu i ruchu. Dwa sklepy z tym samym wynikiem szybkości mogą wymagać przeciwnych zmian. Odtworzylibyśmy wolną stronę, oddzielili czas serwera od pracy przeglądarki i wskazali zapytania, wywołania modułów lub skrypty, które zużywają ten czas. Jeśli dominuje SQL, przetestuj ukierunkowaną zmianę zapytania lub indeksu na środowisku testowym, zanim zmienisz ustawienia serwera. Jeśli baza danych czeka na dysk lub rywalizuje o pamięć, najpierw oceń obciążenie hostingu. Jeśli dokument dociera szybko, ale strona nadal jest wolna w użyciu, zajmij się obrazami, CSS i JavaScript.

Praktyczna ścieżka jest taka sama dla większości poprawek: odtwórz problem na odizolowanej kopii testowej z realistycznymi danymi, przećwicz tam zmianę z przetestowaną drogą powrotu, wdróż ją jako zaplanowaną zmianę i powtórz te same pomiary w sklepie produkcyjnym. Porównuj równoważne żądania przed każdą zmianą i po niej, aby każdy wynik można było jej przypisać.

Dobierz pierwszy test do objawu

Poproś programistę o ślad wykonania żądania wskazujący kosztowne operacje, odpowiedzialny komponent, proponowaną zmianę i porównanie przed zmianą i po niej. Zrzut rozmiaru bazy danych lub pojedynczy wynik testu szybkości nie dostarczają takich dowodów.

Jeśli chcesz, aby takie przypisanie przyczyn wykonano dla Twojego sklepu, PrestaShop Speed & Core Web Vitals Audit śledzi rzeczywiste żądania przez serwer, bazę danych i przeglądarkę i zwraca uszeregowany plan poprawek; zmiany kodu, konfiguracja serwera i zakup hostingu są poza jego zakresem i wycenia się je osobno.

Ustal punkt odniesienia i odczytuj właściwe wskaźniki

Przetestuj stronę główną, popularną kategorię, produkt, koszyk i finalizację zakupów oraz każdy wolny ekran panelu administracyjnego. Uwzględnij wyszukiwanie i filtry, jeśli mają znaczenie dla Twojego sklepu. Zapisz URL, wersję rdzenia i PHP, motyw, włączone moduły, urządzenie, lokalizację, profil połączenia, stan klienta, język, walutę, stan zgody, stan pamięci podręcznej i warunki ruchu.

Do kontrolowanych zmian i profilowania używaj kopii testowej z realistycznymi danymi katalogu. Wykonaj kilka porównywalnych testów i zapisz medianę oraz rozrzut. Porównuj osobno nowego odwiedzającego, powracającą przeglądarkę i zalogowanego klienta oraz uwzględnij żądania bez pamięci podręcznej: szybkie trafienie w publiczną pamięć podręczną nie dowodzi, że koszyk lub finalizacja zakupów działają szybko. Zalogowanie do panelu administracyjnego nie włącza automatycznie profilowania ani nie przyspiesza żądań sklepu.

Obecne wartości docelowe Core Web Vitals to LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1, oceniane w 75. percentylu osobno dla urządzeń mobilnych i komputerów. INP zastąpił FID w marcu 2024 r.

LCP dotyczy największej kwalifikującej się widocznej treści, często obrazu lub bloku tekstu. INP dotyczy responsywności interakcji. CLS dotyczy nieoczekiwanych przesunięć układu. Diagnozuj rzeczywisty element, zdarzenie lub przesunięcie zamiast zakładać przyczynę na podstawie samego wskaźnika.

Wynik Wydajność Lighthouse to złożony wskaźnik laboratoryjny, a nie współczynnik konwersji czy prognoza pozycji. Audyt ładowania obejmuje Total Blocking Time; zwykły test ładowania strony nie ocenia bezpośrednio rzeczywistego INP. Dostępność, Sprawdzone metody i SEO to osobne kategorie audytu, nie pełna certyfikacja tych obszarów. Przeczytaj wyjaśnienie punktacji i poszczególne ustalenia.

Standardowa instalacja GA4 nie zbiera automatycznie Core Web Vitals ani nie udostępnia dawnych raportów szybkości witryny Universal Analytics. Dodaj jawne pomiary web-vitals lub RUM oraz potrzebne zdarzenia i raportowanie. Dziel wyniki według typu strony, urządzenia i rynku, z odpowiednią ochroną prywatności.

Obok pomiarów szybkości utrzymuj pomiary biznesowe. Raport Akamai o handlu detalicznym z 2017 r. powiązał w swoim badaniu opóźnienie 100 milisekund ze spadkiem konwersji o 7%. Ten historyczny wynik nie jest wzorem do prognozowania korzyści Twojego sklepu.

Odizoluj kopię testową i przygotuj drogę powrotu

Odizoluj kopię testową, zanim uruchomią się odtworzona aplikacja, procesy robocze lub zadania cykliczne. Zapewnij jej osobną bazę danych, sandboxowe miejsca docelowe płatności i integracji, testową skrzynkę pocztową i kontrolowany dostęp z zewnątrz. Ogranicz dostęp do skopiowanych danych klientów, aby testy wydajności i pamięci podręcznej nie mogły wywołać wiadomości do prawdziwych klientów ani operacji biznesowych.

Zanim usuniesz rekordy, dodasz indeksy, przebudujesz tabele lub zmienisz silnik albo konfigurację bazy danych, wykonaj spójne kopie zapasowe plików i bazy, przetestuj odtworzenie na środowisku testowym i udokumentuj wycofanie zmian. Przećwicz samą zmianę, uwzględniając blokady, wymagania dotyczące miejsca na dysku i przerwę w działaniu usługi, aby wdrożenie produkcyjne przebiegało według znanej procedury w zaplanowanym czasie. Jeśli nie kontrolujesz serwera, poproś hosting o wprowadzenie konfiguracji.

Utrzymuj kopię jak najbliżej produkcji: te same wydania PrestaShop, PHP i bazy danych, ten sam motyw i moduły oraz reprezentatywne dane. Sprzęt środowiska testowego rzadko odpowiada serwerowi produkcyjnemu, więc używaj go do porównań przed zmianą i po niej, a następnie potwierdź zysk w sklepie produkcyjnym tymi samymi żądaniami bazowymi.

Oddziel czas połączenia, pracę serwera i przeglądarki

TTFB obserwowany przez klienta obejmuje pracę przed nadejściem dokumentu, taką jak DNS, nawiązanie połączenia, TLS, przekierowania i droga żądania oraz odpowiedzi. Nie jest bezpośrednim zegarem wykonania PHP. Waiting w DevTools mierzy inny przedział. Skorzystaj z podziału czasu TTFB, aby zinterpretować używane narzędzie.

Ten przykład powłoki pobiera jedną stronę i wypisuje skumulowane czasy curl. Zastąp przykładowy URL rzeczywistym adresem sklepu:

url='https://example.com/'
curl --silent --show-error --output /dev/null   --write-out 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n'   "$url"

Wartości są mierzone od rozpoczęcia transferu, nie są niezależnymi czasami do zsumowania. Sprawdzaj przekierowania osobno lub jawnie je zapisuj. Powtarzaj przy kontrolowanych stanach pamięci podręcznej i lokalizacjach geograficznych.

Skrypt przeglądarki pobrany po pierwszym bajcie dokumentu nie może opóźnić tego bajtu. Może opóźnić renderowanie, interakcje lub późniejsze żądania. Moduł PHP wykonujący zdalne żądanie API przed wysłaniem HTML może opóźnić odpowiedź serwera. Sam wykres żądań przeglądarki nie zidentyfikuje tego modułu PHP.

Użyj odpowiedniego profilera

Aby profilować starszą część PrestaShop, włącz _PS_DEBUG_PROFILING_ w config/defines.inc.php na kopii testowej z ograniczonym dostępem:

define('_PS_DEBUG_PROFILING_', true);

Załaduj odpowiednie typy stron i sprawdź czas SQL, powtarzane wywołania, hooki i pamięć w zakresie raportu. Później przywróć flagę na false. _PS_MODE_DEV_ to osobny przełącznik trybu deweloperskiego i raportowania błędów. Nie jest przełącznikiem starszego profilowania ani polityką kompilacji Smarty.

Pasek Symfony obejmuje żądania obsługiwane przez kernel Symfony. Jego panel Doctrine nie dowodzi pełnego objęcia starszych zapytań SQL Db. Potwierdź objęte pomiarem ścieżki bazy i hooków, zanim przypiszesz całą pracę modułowi.

Sprawdzenie publicznego URL może ocenić dostępność i czasy przeglądarki. Wewnętrzna liczba zapytań, współczynnik trafień pamięci podręcznej i czasy modułów wymagają autoryzowanego dostępu lub mechanizmów pomiarowych. Nawet zwykłe pobrania strony mogą tworzyć logi, dane analityczne lub wpisy pamięci podręcznej, więc uzgodnij zakres testu i liczbę żądań.

Sprawdzaj ustawienia produkcyjne bez ich utożsamiania

W Zaawansowane → Wydajność przeglądaj każde ustawienie osobno i testuj jego efekt. W publicznym sklepie produkcyjnym wyłącz tryb deweloperski i profilowanie.

Odroczony lub asynchroniczny JavaScript i zasoby zdalne mogą pozostawać poza zwykłym łączeniem CCC. Surowe tagi emitowane przez hook mogą omijać zarządzanie zasobami. Gdy zmiana CCC psuje działanie, wyodrębnij dotknięty pakiet lub zależność na środowisku testowym i popraw rejestrację; nie pozostawiaj niedziałających zakupów w produkcji.

Wyłączaj podejrzane moduły na środowisku testowym i porównuj pomiary. Zwykłe hooki wyłączonych modułów są pomijane przez kontrole wykonania w PrestaShop. Odinstalowuj wyłącznie faktycznie niechciane moduły po sprawdzeniu ich procedury odinstalowania i zachowaniu potrzebnych ustawień lub danych.

Wybierz zgodną wersję PHP i sprawdź OPcache oraz hosting

Używaj utrzymywanej gałęzi PHP obsługiwanej przez dokładną wersję PrestaShop, motyw i moduły. Obecna macierz PrestaShop 9 zaleca PHP 8.4 dla 9.0 i PHP 8.5 dla 9.1. Sprawdź też terminy utrzymania PHP. PHP 8.1 zakończył oficjalne wsparcie 31 grudnia 2025 r. Nie przenoś PrestaShop 1.7.8 na PHP 8 jako uniwersalnego sposobu przyspieszenia.

Potwierdź, że OPcache działa dla PHP obsługującego WWW, nie tylko dla programu wiersza poleceń. Przechowuje skompilowany kod bajtowy, dzięki czemu kolejne żądania unikają ponownego parsowania plików PHP. JIT to osobna opcja; nie zakładaj, że wyjaśnia wydajność sklepu lub musi być włączony.

1. Sprawdź używaną i wolną pamięć, internowane ciągi znaków, buforowane skrypty i klucze przy reprezentatywnym obciążeniu.
2. Sprawdź cache_full, zmarnowaną pamięć oraz liczniki restartów z powodu braku pamięci, zapełnienia tablicy haszującej i ręcznych restartów przez opcache_get_status(), jeśli hosting na to pozwala.
3. Dobierz pamięć i pojemność skryptów na podstawie tych odczytów. Pełna pamięć podręczna może przestać przyjmować skrypty i zaplanować restart; nie działa jak prosta pamięć stale usuwająca pojedyncze wpisy.
4. Udokumentuj zachowanie przy wdrożeniu. Przy opcache.validate_timestamps=1 sprawdzanie znaczników czasu działa według konfiguracji, w tym opcache.revalidate_freq. Przy wyłączonej walidacji zmienione pliki wymagają jawnego unieważnienia lub resetu/restartu odpowiedniej pamięci podręcznej PHP WWW.

Reset CLI zwykle nie czyści OPcache serwera WWW. Czekanie sześćdziesięciu sekund nie jest uniwersalną procedurą resetu. Użyj ustawień OPcache i pól statusu, aby ustalić kontrolowaną politykę, i zachowuj prywatność punktów diagnostycznych.

W PHP-FPM sprawdź zajęte procesy, kolejki, pm.max_children, pamięć procesów i logi przekroczeń czasu. Więcej procesów może pogorszyć presję pamięci lub rywalizację o bazę. Sprawdzaj obciążenie CPU i czas steal, użycie swap, oczekiwanie na dyskowe I/O i opóźnienia bazy w godzinach szczytu. Narzędzia takie jak free -m, vmstat 1 5 i iostat -xz 1 5 mogą pomóc administratorowi skorelować objawy.

Nie dobieraj hostingu wyłącznie według liczby zamówień dziennie. Znaczenie mają równoczesne przeglądanie katalogu, filtry, importy, zadania cron, kombinacje i finalizacja zakupów. Porównaj zużycie zasobów i czasy odpowiedzi przy oczekiwanym obciążeniu szczytowym przed zmianą hostingu lub dodaniem zasobów. Zobacz hosting PrestaShop.

Gdy dowody wskazują na limity wydajności lub odtwarzania, PrestaShop Hosting & Infrastructure Audit analizuje obciążenie i daje pisemną ocenę, czy ulepszyć obecny hosting, czy przeprowadzić migrację; prace na serwerze i sama migracja to osobne zadania. Wybierz ścieżkę migracji na podstawie istniejących modułów, integracji, motywu i danych. Przy przeprowadzce na inny hosting z zachowaniem obecnej konfiguracji przetestuj odizolowaną kopię na nowym serwerze. Jeśli ocena wskazuje na przebudowę sklepu, zwykle bezpieczną ścieżką jest czysta instalacja docelowa na środowisku testowym, zgodne komponenty i przećwiczona migracja danych. Zaplanuj końcową synchronizację danych i przełączenie oraz udokumentuj, jak wycofanie zmian zachowa zamówienia złożone po uruchomieniu.

Znajdź wolne zapytania SQL i poprawnie odczytuj EXPLAIN

Poproś administratora bazy danych, aby najpierw zapisał dokładny silnik i wydanie: ustawienia MySQL i MariaDB nie są wymienne. Korzystaj z istniejącego monitoringu zapytań, jeśli jest dostępny. W przeciwnym razie włącz log wolnych zapytań bazy z progiem dobranym na podstawie czasów żądań i obciążenia. Na przykład krótkie okno diagnostyczne może zaczynać się od:

[mysqld]
slow_query_log = 1
long_query_time = 0.5

Poproś administratora bazy danych o skonfigurowanie dozwolonego miejsca zapisu logu, limitu miejsca, rotacji, kontroli dostępu i daty usunięcia. Treść zapytań może zawierać dane osobowe. Zbieraj reprezentatywny ruch i zadania cykliczne z właściwego okresu dużego obciążenia zamiast stałego czasu dla każdego sklepu, a następnie w razie potrzeby zatrzymaj lub dostosuj szczegółowe logowanie. Logowanie zapytań bez indeksów i filtry minimalnej liczby badanych wierszy mogą pomóc, ale mogą też tworzyć szum i dodatkową pracę lub wykluczać istotne małe zapytania; skanowanie małej tabeli nie jest automatycznie błędem. Sprawdź działanie logu bazy danych dla swojej wersji.

Podsumuj log za pomocą mysqldumpslow lub pt-query-digest, jeśli te narzędzia są zainstalowane i obsługują format Twojego logu. Zastąp ścieżkę rzeczywistym plikiem i przechowuj raporty w miejscu z ograniczonym dostępem:

mysqldumpslow -s t -t 20 /path/to/slow-query.log
pt-query-digest /path/to/slow-query.log

Szereguj według łącznego czasu, liczby wywołań, badanych wierszy i czasu blokad, a także najwolniejszego pojedynczego wykonania: powtarzane umiarkowane zapytanie może kosztować więcej w skali strony lub okresu dużego obciążenia niż jedno wolniejsze zapytanie. Zanim zinterpretujesz ranking, sprawdź tryb sortowania podsumowania, bo lista uporządkowana według średniego czasu odpowiada na inne pytanie niż lista według czasu łącznego. Przed dostrajaniem zapisz dokładne zapytanie, wartości parametrów, ilość danych i kontekst sklepu, a raporty zanonimizuj przed udostępnieniem.

Próg rejestrowania również ukrywa pracę: powtarzane zapytania poniżej progu mogą nie pojawić się w logu, nawet gdy ich łączny koszt ma znaczenie. Na przykład każde pobranie opinii może kończyć się poniżej progu, ale wykonywać się ponownie dla każdej karty produktu, podczas gdy zaplanowany eksport dodaje jedno odosobnione wolne zapytanie niezwiązane z tą stroną. Zestaw wolne żądanie z profilowaniem aplikacji, używając ograniczonego w czasie zapisu zamiast nieograniczonego logowania, i przypisz oba wzorce do ich wywołujących, zanim zdecydujesz, która zmiana poprawi żądanie klienta.

Użyj rzeczywistego zapytania z wolnego żądania wraz z jego kontekstem sklepu, języka i klienta i sprawdź jego plan na kopii testowej z reprezentatywnymi danymi. Ten przykład tylko do odczytu dla kategorii używa domyślnego prefiksu, sklepu 1, języka 1 i kategorii 42. Pokazuje formę, a nie zapytanie generowane przez Twój zainstalowany moduł listy lub filtrów. Odczytuje cenę i status właściwe dla sklepu z product_shop i ogranicza przetłumaczone dane do tego samego sklepu:

EXPLAIN SELECT p.id_product, pl.name, ps.price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
JOIN ps_product_lang pl ON pl.id_product = p.id_product
  AND pl.id_shop = ps.id_shop
JOIN ps_category_product cp ON cp.id_product = p.id_product
WHERE ps.id_shop = 1 AND pl.id_lang = 1
  AND cp.id_category = 42 AND ps.active = 1
ORDER BY ps.date_add DESC;

Zwykłe EXPLAIN szacuje plan bez wykonywania zapytania. Polecenia analizy oparte na wykonaniu mogą je uruchomić; przed użyciem potwierdź działanie polecenia dla swojego silnika i wydania.

Przed dodaniem indeksu sprawdź istniejące. Dobierz kolejność kolumn indeksu złożonego pod kątem warunków równości, zakresów, sortowania i ponownego użycia lewego prefiksu. Zasada „najbardziej selektywna kolumna najpierw” nie jest uniwersalna. Dodane indeksy zajmują miejsce i zwiększają pracę przy zapisie, więc porównaj korzyść przy odczycie z kosztem zapisu. Testuj zmiany schematu na środowisku testowym, przećwicz zarówno ich wprowadzenie, jak i wycofanie, oraz zaplanuj blokady i miejsce tymczasowe.

Tabela opinii odpytywana według produktu, statusu zatwierdzenia i kolejności wyświetlania pokazuje, dlaczego projekt indeksu wymaga znajomości całego wzorca dostępu. Indeks pasujący do tego odczytu w sklepie może nie pasować do listy w panelu administracyjnym filtrowanej według sklepu. Zanim zatwierdzisz indeks, poproś o zmierzone plany dla obu przypadków oraz o wpływ na importy opinii i zapisy moderacji.

Przykład diagnostyki: wolna filtrowana kategoria

1. Zapisz wybrane filtry, kolejność sortowania, sklep, język, walutę i stan klienta. Odtwórz żądanie bez cache na reprezentatywnych danych testowych.
2. Wskaż zapytania odpowiadające za wybór produktów, liczniki filtrów, obliczanie cen i dodatki modułów. Oddziel powtarzane wywołania od pojedynczych kosztownych zapytań.
3. Sprawdź rzeczywiste złączenia, ograniczenia, istniejące indeksy i plan dla kosztownego wzorca. Powyższy przykład kategorii pokazuje tylko składnię; o tym przypadku decydują własne zapytania modułu filtrów.
4. Zaproponuj zmianę tego zapytania, indeks lub ograniczenie powtarzanej pracy odpowiedzialnego modułu. Przećwicz ją, mając już przygotowaną spójną kopię zapasową i plan wycofania.
5. Powtórz te same działania filtrowania i sortowania. Porównaj czas żądania, częstotliwość zapytań i plany, a następnie sprawdź wyniki produktów, liczniki filtrów i ceny klienta.

Zbadaj ceny, filtry i powtarzane odczyty

Ceny specjalne i reguły koszyka

Wybór ceny specjalnej zależy od produktu, kombinacji, sklepu, waluty, kraju, grupy, klienta, koszyka, ilości i dat, z regułami priorytetu i kolejności. Próg ilościowy musi odpowiadać żądanej ilości; from_quantity >= 1 nie jest poprawnym warunkiem wyboru. W diagnostycznym SQL ujmuj zarezerwowane kolumny dat jako `from` i `to`. Profiluj natywne wywołanie wyceny zamiast zastępować jego logikę wyboru niepełnym zapytaniem i nie wklejaj na produkcję zapytania cenowego ani indeksu z innego sklepu: niepełny przykład może dać błędny wynik biznesowy.

Przeglądaj nieaktywne lub wygasłe promocje zgodnie z polityką firmy. Odpowiednie natywne wybory reguł koszyka już filtrują aktywność i daty, więc do wykluczenia reguły nie trzeba jednocześnie jej dezaktywować i ustawiać minionej daty. Zachowuj reguły nadal potrzebne dla zamówień, raportowania lub ważnych kampanii.

Mierz obliczanie reguł na reprezentatywnych koszykach. Zanim połączysz nakładające się reguły, poproś sprzedawcę o potwierdzenie zamierzonych kombinacji i zachowania po wygaśnięciu, a następnie ponownie przetestuj rabaty i sumy na koszykach spełniających i niespełniających warunków.

Liczebności filtrów i wyszukiwanie

Profiluj zainstalowaną implementację wyszukiwania fasetowego i jej rzeczywiste zapytania liczące. Nie zakładaj jednego zapytania na każdą możliwą wartość filtra. Porównaj żądane liczniki z filtrami, z których klienci naprawdę korzystają, i sprawdź, czy pomaga ograniczenie nieużywanych filtrów, poprawa indeksu lub użycie własnej pamięci podręcznej integracji. Usunięcie przydatnego filtra tylko po to, by poprawić wynik testu, zmienia ścieżkę zakupową.

Gdy potrzebna jest przebudowa, używaj obsługiwanej operacji indeksowania. PrestaShop 9.1 dodał polecenie wyszukiwania z opcjami pełnej przebudowy i zakresu sklepu:

php bin/console prestashop:search:index --full --shop-id=1

Sprawdź pomoc zainstalowanego polecenia przed użyciem na innej wersji. Indeksowanie wyszukiwania w panelu jest alternatywą dla wersji bez tego polecenia. Przy zewnętrznym silniku wyszukiwania nadal mogą działać komponenty korzystające z natywnego wyszukiwania lub natywne mechanizmy awaryjne; nie opróżniaj natywnych tabel wyszukiwania tylko dlatego, że zainstalowano inny silnik.

Praca N+1

Hook listy pytający o opinie osobno dla każdego produktu powtarza pracę wraz ze wzrostem wyniku. Gdy funkcja na to pozwala, zbierz ID produktów, pobierz zagregowane dane jednym prawidłowo ograniczonym zapytaniem i wykorzystuj je podczas renderowania. Uwzględnij przypisanie do sklepu i warunki widoczności, sprawdzaj ID i obsłuż pustą listę. Porównuj wynik, a także liczbę zapytań.

Poproś o propozycję pobierania zbiorczego, która wyjaśnia, jak zbierane są ID produktów z listy, jak hook wyświetlania ponownie wykorzystuje wyniki i dlaczego to ponowne użycie nie może mieszać sklepów ani wartości zależnych od klienta. Sprawdź dokładny hook i dostępne dane produktu dla zainstalowanego modułu i wydania. Umieść poprawkę w odpowiedzialnym module lub jego obsługiwanych punktach rozszerzeń, aby przetrwała aktualizacje. Liczba produktów, reguł lub zainstalowanych modułów nie jest automatycznym powodem do usunięcia ani zastąpienia.

Przy pracy ze zdalnymi API najpierw porównaj czas bazy danych z czasem oczekiwania na zewnętrzne API: wolne wywołanie dostawcy lub ERP wymaga innej poprawki niż brakujący indeks. Zapisz zachowanie przy przekroczeniu czasu i błędach. Buforuj i odświeżaj dane poza żądaniem odwiedzającego, jeśli wymagania co do ich aktualności na to pozwalają. Stawki w finalizacji zakupów, stany magazynowe czy kontrole płatności mogą wymagać bieżących danych, więc nie usuwaj wymaganych kontroli w czasie rzeczywistym tylko po to, by poprawić wynik testu.

Dostrajaj pamięć i trwałość bazy na podstawie pomiarów

Bufor InnoDB (buffer pool) przechowuje strony danych i indeksów. Dobieraj jego rozmiar z uwzględnieniem systemu operacyjnego, procesów PHP, Redis i buforów połączeń bazy: większy bufor może zaszkodzić sklepowi, jeśli reszta serwera zacznie korzystać ze swapu. Dedykowany serwer bazy danych i wspólny serwer WWW i bazy wymagają różnych budżetów, a nie stałego procentu zainstalowanej pamięci. Sam rozmiar bazy danych nie dowodzi, że aktywny zbiór roboczy się mieści.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Pobierz dwie próbki w reprezentatywnym odstępie czasu. Dla skumulowanych liczników odczytów bufora, wolnych zapytań i tabel tymczasowych używaj różnic między próbkami. Threads_connected odczytuj jako bieżącą liczbę połączeń, a Max_used_connections jako najwyższą liczbę jednoczesnych połączeń od uruchomienia lub odpowiedniego resetu; ich różnice nie mierzą obciążenia połączeniami. Jeśli zmiana liczby żądań odczytu jest niezerowa, hit_ratio_percent = (1 - delta_reads / delta_read_requests) * 100, gdzie delta_reads to zmiana Innodb_buffer_pool_reads, a delta_read_requests zmiana Innodb_buffer_pool_read_requests. Odrzucaj odstępy obejmujące restart serwera lub reset liczników i porównuj równoważne obciążenia zamiast sum zebranych od różnych dat restartu. Wysoki współczynnik może współistnieć z kosztownymi zapytaniami, a niższy nie uzasadnia automatycznie dokupienia RAM. Zestawiaj odczyty fizyczne, opóźnienia dysku i presję pamięci; większa pamięć podręczna może przyspieszyć powtarzane odczyty, ale nie naprawi długotrwałego zapisu ani oczekiwania na blokadę.

Pozostaw innodb_flush_log_at_trx_commit=1 jako normalne, trwałe ustawienie. Ustawienie 2 może spowodować utratę niedawno zatwierdzonych transakcji po awarii systemu operacyjnego lub zaniku zasilania. Nie poświęcaj trwałości zamówień dla niezmierzonego zysku z dostrajania; każda propozycja osłabienia zapisu przy zatwierdzaniu wymaga jawnej decyzji biznesowej dotyczącej utraty danych i odtwarzania.

Stosuj konfigurację właściwą dla wersji. MySQL 8 usunął pamięć podręczną zapytań (query cache). MariaDB zachowuje własną implementację, ale przed jej włączeniem przetestuj rywalizację i korzyść dla obciążenia i nie zmieniaj silnika wyłącznie dla szybkości. MariaDB 10.6 usunęła innodb_buffer_pool_instances. MySQL 8.0.30 wprowadził innodb_redo_log_capacity w miejsce starszej praktyki ustalania rozmiaru logu redo; korzystaj z aktualnej dokumentacji logu redo i zmiennych obsługiwanych przez Twój serwer.

Nie wklejaj na każdy serwer uniwersalnych wartości wątków I/O, połączeń, buforów sortowania czy tabel tymczasowych. Alokacje na połączenie i współbieżność mogą wyczerpać pamięć, a jednoczesne zwiększanie buforów i limitów połączeń mnoży to ryzyko pod obciążeniem. Pozostaw Performance Schema dostępne do diagnostyki, chyba że zmierzone ograniczenia uzasadniają zmianę; dostrajaj instrumentację zamiast wyłączać ją jako ogólną regułę produkcyjną. Korzystaj z jego zapytań monitorujących tylko wtedy, gdy wymagana instrumentacja jest dostępna. Analizuj Table_locks_waited razem z diagnostyką blokad właściwą dla silnika; nie jest to pełna miara oczekiwania na blokady wierszy InnoDB.

Dla każdej proponowanej zmiany poproś hosting o bieżące ustawienie, zmierzone ograniczenie, proponowaną wartość, oczekiwaną korzyść i procedurę wycofania. Na serwerze współdzielonym z PHP zwiększenie bufora musi zostawić miejsce dla zajętych procesów PHP i importów. Na dedykowanym serwerze bazy danych nadal liczą się opóźnienia dysku, jednoczesne połączenia i praca kopii zapasowych.

Czyść tabele tylko według uzgodnionej polityki retencji

Mierz wzrost tabel i retencję osobno od dostrajania zapytań, a wzrost oceniaj razem z rzeczywistym kosztem zapytań i rozmiarem kopii zapasowych. Aktywność odwiedzających i tworzenie koszyków zależą od włączonych funkcji i zachowań. Niektóre konkretne ścieżki czyszczenia już istnieją, w tym czyszczenie stron połączeń. Do retencji koszyków, gości i logów z uwzględnieniem zależności skorzystaj z poradnika konserwacji bazy danych.

Stare dane wizyt, wyszukiwania, logi poczty, porzucone koszyki i wygasłe reguły cenowe mogą być kandydatami do usunięcia, ale najpierw sprawdź zależności raportowania, obsługi klienta, odzyskiwania koszyków i integracji oraz uzgodnij zakres przechowywania z osobami, które korzystają z tych rekordów. Stary koszyk bez zamówienia nie zawsze można bezpiecznie usunąć. Retencja to decyzja biznesowa, a nie uniwersalna liczba dni.

Mając gotowe kopie zapasowe, przetestowane uruchomienie na środowisku testowym i plan wycofania, Database Cleanup oferuje wybór obszarów, okresy przechowywania, podgląd wierszy i symulację przed usunięciem. Nie dotyka zamówień, kont klientów, aktywnych produktów ani koszyków powiązanych z zamówieniami, a w trybie multistore ogranicza czyszczenie do wybranych sklepów. Jeśli problem obejmuje też osierocone obrazy i nieużywane pliki, Cleanup Revolution dodaje te obszary, czyszczenie z podglądem, ustawienia przechowywania i limit wierszy na uruchomienie. Usunięte przez niego obrazy można odzyskać z kosza z datami przez wybrany okres, co nie jest obietnicą odzyskania każdego usuniętego rekordu, a konta bez zamówień wymagają osobnego podwójnego potwierdzenia. Wybierz narzędzie na podstawie zakresu konserwacji, zamiast domyślnie instalować oba.

Przejrzyj dokładną listę kandydatów, zatwierdź kontrolowaną pierwszą partię, a następnie sprawdź działanie sklepu, liczby kandydatów i historię uruchomień, zanim zaplanujesz kolejne. Obszary chronione przez narzędzie czyszczące nie zastępują Twojej własnej kopii zapasowej. InnoDB może ponownie wykorzystać zwolnione miejsce, ale usunięcie wierszy niekoniecznie zwraca miejsce systemowi operacyjnemu, a przebudowa tabeli może wymagać dodatkowego miejsca i blokad. Rutynowe OPTIMIZE TABLE po każdym czyszczeniu jest zbędne, a opróżnianie indeksu wyszukiwania nie jest porządkowaniem; jeśli wyszukiwanie wymaga przebudowy, użyj obsługiwanej operacji indeksowania dla swojego wydania.

Ogranicz pracę z obrazami, arkuszami stylów i JavaScript

Sprawdź rzeczywisty element LCP i łańcuch żądań. Dopasuj wymiary generowanych obrazów do rozmiaru wyświetlania, gęstości pikseli urządzenia i potrzeb powiększania. Nie ma uniwersalnego limitu rozmiaru obrazu źródłowego ani gwarantowanej oszczędności formatu. Rezerwuj wymiary obrazów, aby ograniczać przesunięcia, i pozwól widocznym obrazom priorytetowym ładować się szybko, odraczając odpowiednie obrazy poza ekranem.

Regeneruj odpowiednie miniatury po zmianie typów obrazów. Najpierw wykonaj kopię obrazów. W PrestaShop 9.1+ php bin/console prestashop:thumbnails:regenerate products --delete usuwa istniejące miniatury produktów przed ich odbudowaniem. Duże przebudowy uruchamiaj poza szczytem. Aby wznowić przerwane wykonanie, pomiń --delete, dzięki czemu istniejące pliki pozostaną, a brakujące zostaną wygenerowane. Wcześniejsze wersje wymagają obsługiwanego narzędzia panelu lub dostarczonego osobno. Zapis WebP rozpoczął się w 8.0; generowanie wielu formatów, w tym AVIF, pojawiło się w 8.1 jako funkcja eksperymentalna. Potwierdź obsługę serwera i motywu oraz sprawdź format dostarczany przeglądarce. Zobacz optymalizację obrazów.

Krytyczny CSS to zestaw stylów potrzebnych dla początkowego obszaru widocznego. Wygeneruj go dla reprezentatywnych stron i wariantów responsywnych, osadź zweryfikowany podzbiór i odpowiednio załaduj pozostały CSS. Zachowaj style awaryjne i testuj menu, banery zgody, warianty językowe oraz dynamicznie dodawane treści. Niepełne wyodrębnienie może powodować migotanie, przesunięcia lub brak elementów sterujących.

Ograniczaj nieużywany CSS i JavaScript na podstawie pomiarów wszystkich potrzebnych stanów. Pokrycie z jednego początkowego widoku nie dowodzi, że selektor można bezpiecznie usunąć. Porównaj slider ze statycznym banerem głównym tam, gdzie zachowanie slidera niewiele wnosi, a następnie przetestuj rzeczywisty wynik.

Dla klasycznych skryptów zewnętrznych defer odracza wykonanie do zakończenia parsowania, zachowując kolejność skryptów odroczonych; async służy niezależnej pracy, której kolejność ukończenia może się zmieniać. Żadne nie usuwa kosztu wykonania. Opcja rejestracji JavaScript w PrestaShop ma nazwę w liczbie mnogiej:

['position' => 'bottom', 'priority' => 200, 'attributes' => 'defer']

Przekaż te opcje do registerJavascript() przy rejestracji własnego zasobu. Rejestruj go tylko na stronach, które go potrzebują. Testuj zależności i każdą dotkniętą interakcję po zmianie kolejności lub czasu wykonania. Łącz zdublowane trackery i prawidłowo kontroluj usługi, które nie są niezbędne.

Przeprowadź audyt fontów, ikon i motywu

1. Filtruj Network według Font przy wyłączonej pamięci podręcznej przeglądarki. Zapisz pliki, rozmiary transferu i inicjujące arkusze stylów.
2. Sprawdzaj obliczone style i Coverage na różnych typach stron i podczas interakcji, aby zidentyfikować używane rodziny, grubości, style i ikony.
3. Przeszukaj zarejestrowane zasoby, importy CSS i szablony aktywnego motywu. Motywy oparte na Classic zwykle używają templates/_partials/head.tpl; własne motywy mogą się różnić.
4. Usuwaj zbędne zasoby w utrzymywanym źródle motywu lub motywie potomnym. Sprawdzaj wszystkie obsługiwane języki, symbole walut i treści dynamiczne.

Classic i Hummingbird zawierają deklaracje fontów Material Icons. Sprawdź dostarczany CSS, zanim założysz, że któryś motyw wyeliminował fonty ikon. Sprawdź dokładną wersję i biblioteki dodane przez moduły. Podzbiór lub wybrane ikony SVG mogą ograniczyć nieużywane zasoby, ale zachowaj potrzebne symbole i dostępne etykiety.

Żądaj tylko używanych grubości i znaków fontu. WOFF2 i starannie wybrane podzbiory mogą ograniczyć transfer; oszczędności zależą od fontu i języków. Stos fontów systemowych eliminuje dodatkowe pobieranie fontów internetowych. Na przykład:

font-family: system-ui, -apple-system, "Segoe UI", sans-serif;

Dla zachowanych fontów wybierz odpowiednią politykę font-display. swap pokazuje tekst zastępczy podczas ładowania fontu, ale metryki mogą się zmienić i powodować przesunięcia. W miarę możliwości dopasuj metryki fontu zastępczego i przetestuj układ. W Google Fonts jawnie żądaj display=swap, jeśli jest potrzebne, i sprawdź zwrócony CSS; nie występuje to w każdym URL API. Zobacz wytyczne Fonts API.

Własny hosting licencjonowanych plików fontów eliminuje żądanie do zdalnego dostawcy i może wykorzystać połączenie z Twoim serwerem. Ładowanie zdalne nadal wymaga odpowiedniej oceny prywatności. Monachijska sprawa Google Fonts ze stycznia 2022 r. zakończyła się zasądzeniem 100 EUR odszkodowania cywilnego, a nie kary administracyjnej, jak wyjaśnia organ Dolnej Saksonii.

Aby porównać motywy, używaj tych samych danych i ustawień testowych, zgodnego motywu domyślnego i zapisanych stanów pamięci podręcznej. Zmiana motywu zmienia też funkcje i prezentację modułów, więc różnica jest eksperymentem, a nie dokładnym rozliczeniem wszystkich kosztów motywu. Wyłączaj pojedyncze efekty, fonty lub komponenty, aby zawęzić badanie. Utrzymywane zmiany przechowuj w motywie potomnym, gdy to odpowiednie.

W śladzie Performance sprawdzaj długie zadania JavaScript i ich stosy wywołań. Do diagnozowania ciągłego przeliczania układu używaj zdarzeń Layout/Recalculate Style i diagnostyki wymuszonych przeliczeń. Same czerwone oznaczenia tego nie dowodzą. Przy interpretacji śladu korzystaj z dokumentacji wydajności DevTools.

Sprawdź, co moduły rzeczywiście wykonują i ładują

Przygotuj dla każdej strony wykaz CSS/JS modułów, rozmiaru transferu i po dekodowaniu, żądań, wywołań zapytań, wykonania na serwerze i widżetów potrzebujących tych zasobów. Sama rejestracja hooków lub liczba modułów nie mówi o koszcie.

W kontekście jednego sklepu Wygląd → Pozycje pokazuje rejestracje hooków. Włącz Wyświetl hooki, których nie można pozycjonować, aby uwzględnić hooki akcji, takie jak actionFrontControllerSetMedia, obok hooków wyświetlania, takich jak displayHeader. PrestaShop obsługuje wyjątki kontrolerów dla rejestracji hooków, a moduł może warunkowo rejestrować zasoby. Hook bez widocznego HTML nadal może wykonywać wymaganą inicjalizację.

Filtrowanie Network po /modules/ to dobry początek. Pomija zasoby połączone przez CCC lub motyw, zasoby zdalne i pliki generowane dynamicznie. Śledź inicjatory i zawartość pakietów; w razie potrzeby tymczasowo wyłącz CCC na środowisku testowym na czas diagnostyki.

1. Znajdź kosztowne zasoby i wywołania serwera na wolnej stronie.
2. Sprawdź, gdzie pojawiają się ich funkcje. Opinie i przyciski listy życzeń mogą zasadnie wymagać zasobów na listach kategorii.
3. Zablokuj precyzyjnie dopasowany URL zasobu w eksperymencie przeglądarkowym, a następnie sprawdź niedziałające funkcje. Blokowanie wspólnej domeny sklepu nie izoluje modułu.
4. Wyłącz podejrzany moduł na środowisku testowym i powtórz te same testy. Blokowanie w przeglądarce nie usuwa pracy hooków serwera; eksperyment z wyłączeniem modułu zmienia również zachowanie strony.
5. Preferuj poprawioną warunkową rejestrację w module. Wyjątków hooków lub logiki wyrejestrowania i ponownej rejestracji używaj dopiero po sprawdzeniu zależności i inicjalizacji.
6. Ponownie sprawdź interakcje produktu, kategorii, konta, koszyka, finalizacji zakupów, zgody i urządzeń mobilnych.

Zachowuj działanie przydatnych funkcji, ograniczając ich zbędną pracę. Nie ma uniwersalnego budżetu dziesięciu milisekund na moduł ani procentowej oszczędności z audytu.

Wybierz warstwę pamięci podręcznej i testuj kwalifikację oraz unieważnianie

Dodawaj pamięć podręczną tam, gdzie pomiary pokazują powtarzaną pracę, której wynik można bezpiecznie użyć ponownie. Nowa pamięć podręczna zmienia obciążenie; nie zwalnia z mierzenia ani z utrzymania sprawnej ścieżki bez pamięci podręcznej.

Integracja Redis

Zainstaluj rzeczywistą usługę Redis, wymaganą obsługę PHP i adapter łączący zamierzoną ścieżkę pamięci podręcznej. Ustawienie ps_caching musi wskazywać zainstalowany adapter pamięci aplikacji; nie konfiguruje przechowywania sesji. Jeden z własnych adapterów używanych z Performance Revolution nazywa się MPRCacheRedis; stosuj procedurę instalacji obsługiwaną przez daną implementację.

Osobno konfiguruj przechowywanie sesji PHP lub Symfony, w tym politykę blokowania i awarii. Pliki cookie klientów i sesje PHP są różnymi mechanizmami, a przejście na Redis samo w sobie nie usuwa blokowania.

Podstawowe API zapisu do bazy danych w rdzeniu mogą wywoływać unieważnianie w adapterze, gdy pamięć podręczna jest włączona. Bezpośredni SQL, importy zewnętrzne i pamięci podręczne modułów mogą korzystać z innych ścieżek. Testuj aktualizacje cen, stanów, produktów, kategorii i konfiguracji każdą ścieżką zapisu, z której korzystasz. Sam Redis nie wie, które strony PrestaShop lub wyniki zapytań stały się nieaktualne. Testuj też wygasanie, jednoczesne żądania i zachowanie przy awarii usługi Redis.

Strona pomocy Redis Cache Manager & Monitor opisuje kontrolę połączenia, zarządzanie kluczami i osobne przełączniki dla przechowywanych danych, sesji i stron dla gości. Wymagana jest działająca usługa Redis; przetestuj każdą włączoną integrację, unieważnianie i zachowanie przy awarii na środowisku testowym.

Buforowanie całych stron

Pierwszy odwiedzający z pustą pamięcią przeglądarki może otrzymać trafienie z rozgrzanej współdzielonej pamięci stron. Kwalifikujące się trafienia mogą omijać kosztowną pracę bazy i ograniczać TTFB, nawet gdy podstawowa ścieżka zapytań jest wolna. Chybienia i wykluczone lub prywatne żądania nadal potrzebują sprawnej aplikacji.

Moduł aplikacji nadal uruchamia PHP na swojej ścieżce pamięci podręcznej. Prawidłowo skonfigurowany zewnętrzny reverse proxy lub pamięć FastCGI mogą omijać PHP przy trafieniach. Traktuj ich czasy jako różne pomiary. Ustal jawną politykę kwalifikacji obejmującą metodę żądania, rozpoznany kontroler, parametry zapytania, host/sklep, język, walutę i każdy czynnik wpływający na publiczną treść.

Pomijaj koszyk, finalizację zakupów, konto, logowanie, panel administracyjny, API, AJAX i odpowiedzi spersonalizowane, chyba że obsługuje je specjalnie zaprojektowany mechanizm izolacji. Respektuj odpowiedzi private/no-store i zachowanie ustawiania plików cookie. Czarna lista angielskich fragmentów URL pomija przetłumaczone ścieżki i kontrolery w parametrach zapytania.

Testuj dwiema przeglądarkami i różnymi stanami klientów. Sprawdzaj klucze pamięci, warianty zgody i brak przenoszenia prywatnych treści między odwiedzającymi. Testuj unieważnianie przy edycjach produktów, cenach, stanach magazynowych, zmianach kategorii, początku i końcu promocji oraz importach zewnętrznych. TTL to świadoma tolerancja nieaktualności, a nie pełne unieważnianie.

Czyszczenie na podstawie tagów i dynamiczne fragmenty mogą pomóc, jeśli są zaimplementowane. ESI, hydratacja w przeglądarce i zastępowanie placeholderów w PHP to różne techniki. Obsługiwane buforowanie aplikacji, placeholdery po stronie serwera, cele krytycznego CSS i zakres profilowania opisuje strona pomocy Performance Revolution. Moduł mierzy też rzeczywiste czasy ładowania stron u klientów i może dostarczać kwalifikujące się strony publiczne przez opcjonalny Cloudflare, z publicznymi kopiami rozróżnianymi według języka, waluty, kraju i urządzenia oraz odświeżaniem stron, których dotyczy zmiana ceny lub stanu; koszyk, finalizacja zakupów, konta i wizyty zalogowanych użytkowników korzystają ze sklepu na żywo. Potwierdź jego dopasowanie do istniejącej pamięci podręcznej, motywu i własnych integracji na środowisku testowym.

Lista kontrolna odbioru pamięci podręcznej

• Rozgrzej kwalifikującą się publiczną stronę produktu, a następnie zmień jego cenę i stan zwykłymi ścieżkami aktualizacji sklepu, w tym przez ERP lub importy zbiorcze, jeśli z nich korzystasz. Sprawdź, kiedy publiczna kopia się zaktualizuje.
• Zmień język, walutę i kraj dostawy. Przetestuj ceny grup klientów i niestandardowe prezentacje cen; wyklucz stronę lub kontekst, dla których nie da się bezpiecznie potwierdzić rozdzielenia wariantów.
• Dodaj produkt do koszyka, zaloguj się oraz otwórz strony konta i finalizacji zakupu. Sprawdź, czy dane osobiste są poprawne dla każdego odwiedzającego i czy prywatne odpowiedzi nie są używane ponownie.
• Przećwicz na środowisku testowym wygasanie, jednoczesne chybienia pamięci podręcznej i awarię usługi pamięci podręcznej. Potwierdź, że ścieżka awaryjna pozostaje poprawna, a odbudowa nie przeciąża serwera źródłowego.
• Zapisz, która warstwa odpowiada za każdą buforowaną odpowiedź i jak ją unieważnić. Potwierdź, że inne proxy lub CDN nie mogą zachować kopii po odświeżeniu cache aplikacji.

Buforowanie statyczne i rozgrzewanie

Aktualne wpisy w pamięci podręcznej przeglądarki mogą pozwolić uniknąć komunikacji sieciowej. Walidacja ETag zwykle wykonuje żądanie warunkowe. Stosuj długą ważność tylko z odpowiednią strategią wdrażania wersjonowanych zasobów; czyszczenie na serwerze nie może usunąć pamięci każdej przeglądarki. CDN może dostarczać publiczne zasoby blisko odwiedzających, ale sprawdzaj TLS, CORS dla fontów, nagłówki buforowania i unieważnianie.

Czyść tylko dotknięte warstwy za pomocą obsługiwanych narzędzi. Po wdrożeniu rozgrzewaj ważne kwalifikujące się strony przy ograniczonej współbieżności i obciążeniu. Nie zakładaj, że włączenie buforowania wyrenderowanych szablonów przenosi skompilowane pliki PHP szablonów do Redis. Rozgrzewanie serwera źródłowego i węzłów CDN to osobne prace, a rozgrzewanie może zwiększać obciążenie. Porównuj świadomie zimne i ciepłe przebiegi zamiast ukrywać różnicę.

Poradnik pamięci całych stron, Redis i CDN omawia te warstwy dokładniej.

Obsłuż kombinacje i spowolnienia panelu administracyjnego

Pojemność katalogu zależy od kombinacji, powiązań, obrazów, cech, filtrów, cen i importów, a także liczby produktów. Nie ma jednego praktycznego limitu liczby produktów dla każdego sklepu. Testuj obciążenie kopii testowej z realistycznymi danymi i ruchem.

Sześć rozmiarów, osiem kolorów i pięć wykończeń daje 240 kombinacji, jeśli wygenerowano każdą z nich. Sprawdź największe zbiory tymi zapytaniami tylko do odczytu, zastępując w razie potrzeby domyślny prefiks:

SELECT id_product, COUNT(*) AS combinations
FROM ps_product_attribute
GROUP BY id_product
ORDER BY combinations DESC
LIMIT 20;

SELECT id_product, COUNT(*) AS stock_rows
FROM ps_stock_available
WHERE id_product_attribute <> 0
GROUP BY id_product
ORDER BY stock_rows DESC
LIMIT 20;

Zapytanie o wiersze stanów liczy zapisane wiersze we wszystkich ich zakresach; nie jest sumą stanów odizolowaną dla sklepu. Przy interpretacji sprawdź przypisanie do sklepu lub grupy.

Usuwaj niemożliwe warianty, ograniczaj zbędne wymiary lub dziel bardzo duży produkt, gdy odpowiada to zachowaniom zakupowym. Opcje niewymagające niezależnego stanu lub ceny mogą lepiej pasować do personalizacji lub konfiguratora. Przed zmianą modelu sprawdź konsekwencje dla URL, obrazów, cen i stanów.

Duże formularze i importy mogą osiągać limity max_input_vars, post_max_size, pamięci lub czasu żądań. Dziel synchronizację stanów i importy na partie oraz przebudowuj odpowiednie indeksy wyszukiwania i filtrów obsługiwanymi narzędziami po istotnych zmianach.

Profiluj ekrany administracyjne osobno. Jeśli wolny jest tylko pulpit, przetestuj jego statystyki, kanały informacji i opcjonalne widżety. Jeśli wolny jest Menedżer modułów, sprawdź metadane i żądania do usług zdalnych. Integracje Marketplace zależą od wersji i instalacji; Marketplace nie jest dołączany do projektu open source od wersji 8.

Jeśli wolne są zarówno sklep, jak i panel administracyjny, sprawdź wspólne zasoby PHP, bazy i hostingu. Ten objaw nie dowodzi nadmiernego rozrostu bazy. Przed usuwaniem danych sprawdź zapisywalność katalogów pamięci podręcznej, powtarzane przebudowy, OPcache, kolejki procesów, opóźnienia bazy i odpowiednie hooki modułów.

Skaluj operacje według zmierzonego obciążenia

Oddzielnie śledź infrastrukturę, zgodność stanów magazynowych i obciążenie pracowników. Miesięczna liczba zamówień nie wyznacza poziomu hostingu ani nie czyni buforowania całych stron obowiązkowym. Stosunek ruchu do zamówień i nagła współbieżność różnią się między sklepami.

Mierz czas powtarzalnych zadań: obsługi statusów, kompletacji, wysyłki, wiadomości klientów, zwrotów i eksportów księgowych. W przykładowym planowaniu 100 zamówień miesięcznie po sześć minut każde zajmuje dziesięć godzin pracy miesięcznie. Używaj własnych zmierzonych czasów i uwzględniaj wyjątki przed wyborem automatyzacji.

Rozróżniaj natywny status zamówienia, powiadomienia klientów i wewnętrzny status procesu w dowolnym module. Advanced Order Fulfilment może łączyć zdarzenia z własnymi krokami procesu, zespołami i przypomnieniami; natywne zmiany statusów i e-maile o wysyłce do klientów sprawdzaj osobno.

Korzystaj z natywnego procesu Obsługi klienta dla wiadomości, które faktycznie do niego trafiają. Osobny moduł formularza może przechowywać własne zgłoszenia i powiadomienia, więc potwierdź każdą integrację z helpdeskiem. Kierowanie zgłoszeń z konkretnych formularzy opisuje strona pomocy Better Contact Form.

Uzgadniaj stany między zamówieniami, zwrotami i innymi kanałami sprzedaży. Przeglądaj działania zbiorcze na zamówieniach i filtrowane eksporty, w tym uprawnienia i wpływ na powiadomienia. Pracownikom pakującym, obsłudze i administratorom zapewnij indywidualne konta z dostępem odpowiednim do roli.

Rozdzielaj serwery bazy i WWW tylko wtedy, gdy pomiary uzasadniają niezależne zasoby. Uwzględniaj opóźnienia sieci, bezpieczne połączenie, kopie i odtwarzanie, ustawienia połączeń i testy wdrożenia. Sama zmiana konfiguracji nie jest pełnym planem migracji. Przy ocenie marży na dodatkowych zamówieniach uwzględniaj pracowników, oprogramowanie, infrastrukturę, opłaty i zwroty.

Utrzymuj regularny monitoring i proces wdrażania

• Zapisuj powtarzalne testy laboratoryjne i wskaźniki rzeczywistych użytkowników dla reprezentatywnych typów stron wraz z zachowaniem trafień i chybień pamięci podręcznej.
• Monitoruj dostępność, błędy, kolejki procesów PHP, CPU, pamięć, I/O, opóźnienia zapytań, połączenia i pojemność pamięci podręcznej. Ustawiaj alerty względem punktu odniesienia.
• Przeglądaj podsumowania wolnych zapytań, wzrost tabel i retencję. Używaj narzędzi takich jak PMM lub panel bazy, gdy odpowiadają potrzebom operacyjnym; automatyczne sugestie nadal wymagają testów obciążenia.
• Po zmianie modułu, motywu lub katalogu, dużym imporcie lub zmianie ruchu porównaj zasoby, wywołania, obciążenie zapytaniami i interakcje z punktem odniesienia. Przechowuj pełne raporty i krótki dziennik zmian.
• Podczas wdrożenia czyść dotknięte warstwy PrestaShop, stosuj udokumentowaną politykę OPcache WWW, unieważniaj zmienione zasoby i rozgrzewaj wyłącznie w kontrolowanym budżecie.
• Sprawdź od początku do końca błędy przeglądarki, wyświetlanie obrazów, nawigację, filtry, koszyk, płatność i potwierdzenie oraz upewnij się, że ceny, stany i integracje nadal działają jak wcześniej.
• Przeglądaj trendy rzeczywiste po zebraniu wystarczających danych. Nie oceniaj ruchomego raportu rzeczywistych danych na podstawie jednego testu laboratoryjnego lub kilku dni.

Wybieraj kolejną zmianę według zmierzonego kosztu, ryzyka i wpływu na klientów. Po niej testuj ponownie i zachowuj drogę wycofania. Szybszy wynik testu jest przydatny tylko wtedy, gdy katalog, ceny, wybory prywatności i zakupy nadal działają poprawnie.

Pytania właścicieli przed zapłatą za prace nad szybkością

Czy najpierw kupić więcej pamięci lub większy pakiet? Zapytaj, które zmierzone oczekiwanie by to usunęło i czego potrzebują inne usługi na serwerze. Więcej pamięci nie naprawi wolnego zapytania, wywołania zewnętrznego ani pracy przeglądarki.

Czy duża tabela potrzebuje kolejnego indeksu? Tylko wtedy, gdy rzeczywisty wzorzec dostępu zyskuje na tyle, by uzasadnić koszt miejsca i zapisu. Przetestuj kandydata na środowisku testowym przy realnym obciążeniu.

Czy najpierw wyczyścić bazę danych? Tylko tam, gdzie wskazuje na to zmierzony koszt, na przykład rosnąca tabela w wolnym zapytaniu lub w oknie kopii zapasowej, i tylko według uzgodnionej polityki retencji.

Czy można zacząć od cache? Rozważ to, gdy pomiary wskazują szansę ograniczenia powtarzanej pracy publicznych stron. Zachowaj poprawność prywatnych scenariuszy, przetestuj unieważnianie i utrzymaj akceptowalną ścieżkę bez cache; kolejność zmian wynika z pomiarów.

Kiedy powtórzyć przegląd? Po istotnych zmianach modułów lub katalogu, importach, zmianach ruchu lub pogorszeniu zapisanych ścieżek. Utrzymuj monitoring wystarczający, by taką zmianę zauważyć.