Czym jest checkout w PrestaShop i jak działa domyślny proces zamówienia

W PrestaShop 1.7 i 8 zamówienie to pięć adresów obsługiwanych przez cztery kontrolery. Warto znać tę mapę, bo większość zgłoszeń „zgubione zamówienie” kończy się sprawdzeniem jednego z tych miejsc.

• /koszyk — CartController i szablon cart.tpl. Tu działa koszyk, przeliczenie VAT i reguły cenowe.
• /order — OrderController. Jeden kontroler obsługuje trzy kroki: dane, dostawę i płatność. W motywie classic odpowiadają im templates/checkout/order-address.tpl, order-carrier.tpl, order-payment.tpl oraz części _partials/step-*.tpl.
• /order-confirmation — OrderConfirmationController i order-confirmation.tpl. Zamówienie już istnieje w bazie, ten krok tylko je wyświetla.

Podział na szablony i logikę jest kluczowy przy diagnozie: układ pól zmienisz w pliku .tpl, ale walidację i zapis danych — w klasach. Za utworzenie zamówienia odpowiada PaymentModule::validateOrder(); dopiero po jego wywołaniu rekord pojawia się w Zamówienia > Zamówienia. Moduły płatności (Przelewy24, PayU, Stripe) rozszerzają PaymentModule, więc ich błędy nie są błędami rdzenia. Kolejność hooków i klasy opisuje dokumentacja dla deweloperów PrestaShop.

Przełącznik Zezwól na zamówienia od gości siedzi w Parametry sklepu > Ustawienia klientów. Nie chodzi o brak konta: PrestaShop i tak tworzy rekord klienta, ale bez hasła i z flagą gościa. Skutki są praktyczne — gość nie zaloguje się później, nie zobaczy historii zamówień i nie zapisze adresu na następny raz. Przy koszykach do 200 zł to zwykle dobry kompromis; przy B2B i zamówieniach cyklicznych wyłącz gościa i skróć formularz rejestracji do minimum.

Stan wdrożenia sprawdzasz w trzech miejscach: /order (czy kroki przechodzą bez zerwania), /order-confirmation (czy potwierdzenie się renderuje) i back-office Zamówienia > Koszyki, gdzie leżą koszyki, które nie stały się zamówieniami — z datą i kwotą. Dopięcie do tego pomiaru kroków opisuje nasze wdrożenie GA4 eCommerce w PrestaShop.

One-page checkout vs standardowy: co wybrać i jak to włączyć

Najpierw sprawdź, czy twój motyw w ogóle obsługuje tryb jednej strony. Przełącznik znajdziesz w Parametry sklepu > Ustawienia zamówień (w 1.6 było to Preferencje > Zamówienia), ale w części instalacji 1.7.x i w motywach kupionych od firm trzecich nie robi on nic, bo checkout jest nadpisany własnymi szablonami. Test: włącz opcję, wejdź na /order jako gość i policz przeładowania strony. Jedno oznacza, że OPC działa; trzy-cztery — że motyw gra swoje.

Co OPC realnie zmienia? Te same kontrolery, te same szablony, inne składanie kroków po stronie JS. Nie zmienia logiki walidacji ani sposobu liczenia stawek przewoźników.

Kiedy zostawić pięć kroków: koszyk B2B i zamówienia na fakturę z odroczonym terminem, skomplikowane warianty dostawy (kurier + paleta + punkt odbioru), klienci, którzy chcą zobaczyć koszt dostawy przed przejściem do płatności, oraz katalogi z konfigurowalnymi produktami.

Kiedy OPC pomaga: średnia wartość koszyka poniżej 150–200 zł, powyżej 60% ruchu z telefonów, 1–3 przewoźnicy i płatności express (BLIK, karta zapisana w przeglądarce). Zanim przełączysz OPC na ruchu mobilnym, sprawdź wydajność /order — formularz zamówienia z kilkoma skryptami płatności wypada najgorzej w Core Web Vitals i przy wolnym LCP klient nie dociera do podsumowania. Widełki czasowe: w gotowym motywie z natywnym wsparciem to 2–6 h (włączenie, test trzech ścieżek, poprawki CSS). Przepisanie szablonów, walidacji i obsługi błędów AJAX to 16–40 h — i wtedy warto najpierw uporządkować moduły, np. przez integracje płatności i dostaw z PrestaShop.

Najczęstsza pułapka: OPC plus moduł dostawy, który przed pokazaniem stawek wymaga pełnego adresu. Wtedy pierwszy XHR leci z pustym kodem pocztowym, moduł zwraca błąd, a klient widzi puste stawki albo kręcące się kółko. Diagnoza: DevTools > Network, filtr XHR na /order, odpowiedź serwera; potem przestawienie kolejności kroków w motywie albo wyłączenie OPC do czasu poprawki.

Konfiguracja zamówienia: gość, pola adresowe, walidacja i listwy dostaw

Zacznij od pól adresowych. W Międzynarodowy > Lokalizacja > Kraje > Polska > Edytuj ustawiasz dla każdego pola stan: wymagane, opcjonalne albo ukryte. W polskich sklepach Region (stan) prawie zawsze idzie na ukryte — nikt go nie wypełnia, a wymagane pole generuje porzucenia na kroku danych. NIP zostaw: włącz Tryb B2B w Parametry sklepu > Ustawienia klientów, wtedy pole NIP pojawia się w adresie i możesz uczynić je wymaganym. Osobno przemyśl telefon — jeśli wysyłasz nim powiadomienia o dostawie, oznacz jako wymagany; jeśli służy tylko marketingowi, zostaw opcjonalny.

Limity zamówienia: minimalna wartość koszyka jest w Parametry sklepu > Ustawienia zamówień i działa na poziomie całego sklepu. Maksymalnej wagi globalnie nie ma — siedzi w zakresach wagowych przewoźnika (Dostawa > Przewoźnicy > edycja > Rozmiary, wagi i kategorie). Tam też wykluczysz kategorię lub pojedynczy produkt z danego przewoźnika, np. hydraulikę z Paczkomatu albo meble z kuriera.

Walidacja: reguły i formaty siedzą w classes/Validate.php. Kody pocztowe reguluje wzór w Kraje > Polska (N = cyfra, L = litera; typowo NN-NNN). Test: wpisz 00-001 i 00001 — drugi wariant powinien zostać odrzucony; jeśli przechodzi, popraw wzór, żeby nie produkować błędnych adresów u kuriera. Uwaga na moduły weryfikujące NIP przez API — przy limicie zapytań odrzucają poprawne numery i klient utyka na kroku danych.

Koszyk po wylogowaniu PrestaShop domyślnie zachowuje, a opcja pokazywania go ponownie po zalogowaniu jest w Parametry sklepu > Ustawienia klientów. Zmiana kraju dostawy przelicza podatki z reguł podatkowych i stawki przewoźnika ze strefy — jeśli kraj należy do strefy bez reguły dla przewoźnika, dostawa zniknie, a klient zobaczy 0 zł albo puste pole. Chcesz wiedzieć, na którym polu ludzie się zatrzymują? Potrzebny jest DataLayer w PrestaShop, bo walidacja JS nie zostawia śladu w GA4.

Płatności i kurierzy w checkout: InPost, DPD, DHL, bramki płatności

Kolejność metod płatności w PrestaShop wynika z kolejności instalacji modułów. Rdzeń nie ma przełącznika „metoda domyślna” — żeby jedna z metod była zaznaczona na wejściu, trzeba to zrobić szablonem lub skryptem modułu. Konsekwencja praktyczna: preselekcja generuje zdarzenie jeszcze przed decyzją klienta, więc w pomiarze trzeba je odróżnić od realnego wyboru. Zacznij od Moduły → Płatność i sprawdź „Ograniczenia” każdego modułu: waluta, grupa klienta, kraj, przewoźnik.

Właśnie ograniczenia po przewoźniku wywalają checkout najczęściej. Przykład: PayPo ma sens przy paczkomacie, ale przy płatności za pobraniem klient finansuje zakup dwiema metodami jednocześnie — moduł powinien się wtedy schować. Podobnie raty przy koszyku za 50 zł. Testuj trzy koszyki: ~30 zł, ~300 zł, ~3000 zł, dla każdej pary przewoźnik + płatność.

Mapa punktów (InPost, DPD, DHL) to najbardziej wrażliwe miejsce. Potrzebujesz tokenu/klucza API operatora i kontraktu na usługę, a w module pola, do którego zapisuje się identyfikator punktu razem z nazwą i adresem. Test walidacji: przejdź checkout bez wybrania punktu — jeśli zamówienie powstaje bez identyfikatora, masz błąd konfiguracji, który wyjdzie dopiero przy nadawaniu paczki. Gdy API nie odpowiada (timeout, 429, brak tokenu), nie blokuj checkoutu: pokaż listę punktów z cache z ostatnich 24 h, a brak danych obsłuż jako wybór z listy tekstowej i zapisz zdarzenie w logu modułu.

Powrót z bramki: dla przekierowań zamówienie powstaje przed potwierdzeniem płatności, więc klient widzi je w statusie oczekiwania, a koszyk jest już skasowany. Drugi przypadek to płatność potwierdzona, ale zamówienie nie zapisało się (błąd walidacji po stronie modułu) — wtedy transakcja istnieje tylko w panelu bramki. Wykryjesz to porównaniem dziennym: zestawienie transakcji z panelu z zamówieniami w PrestaShop po kwocie i dacie. Webhook musi mieć publiczny adres, działać przy wyłączonym trybie serwisowym, odpowiadać 200 w kilka sekund, weryfikować podpis i być idempotentny — bramki ponawiają wysyłkę.

Checklista przed przełączeniem na produkcję: klucze produkcyjne, adres webhooka, whitelista IP, karty 3DS, waluta PLN, wyłączone wysyłki testowe do klientów, kopia zamówień testowych usunięta ze statystyk. Całość organizacyjnie opisujemy w materiale o integracjach z PrestaShop i organizacji wdrożenia; konfigurację modułów sprawdzasz w dokumentacji deweloperskiej PrestaShop.

Szybkość checkoutu: TTFB, LCP i dlaczego strona zamówienia łamie Core Web Vitals

Strona zamówienia nie ma prawa być cache’owana w pełni. Zawiera sesję, zawartość koszyka i token CSRF w formularzu, więc cache stron dla adresów z kontrolera order, order-confirmation i wszystkich z parametrem token musi być wyłączony. Jeśli używasz modułu cache lub CDN z regułami, dodaj wyjątki po nazwie kontrolera, a nie po samym /order — sklepy z niestandardowym checkoutem mają inne ścieżki. W Parametry zaawansowane → Wydajność sprawdź też CCC dla JavaScriptu: przy starszych modułach płatności łączenie plików psuje skrypty i checkout przestaje reagować, więc testuj z wyłączonym CCC.

LCP na kroku dostawy najczęściej psuje mapa punktów. Ładuj ją dopiero po wybraniu przewoźnika (przycisk „wybierz punkt” uruchamia widget), nie na starcie kroku — na mobile to często 300–600 kB JavaScriptu i główny powód LCP ponad 4 s. Skrypty bramek (3DS, fingerprint) wczytuj asynchronicznie z defer, ale skryptu modułu, który przelicza stawki dostawy przez AJAX, nie ruszaj: kolejność jego wykonania decyduje o tym, czy koszt dostawy się podstawi. Cel: TTFB poniżej 0,5 s, LCP poniżej 2,5 s, INP poniżej 200 ms — progi opisane w artykule web.dev o Web Vitals i w wytycznych Core Web Vitals.

Liczbę zapytań na kroku płatności zmierzysz w trybie debugowania: na dole strony pojawia się profil z listą zapytań SQL i czasem. Alternatywa bez wyłączania sklepu: slow query log MySQL z progiem 0,2 s plus SHOW FULL PROCESSLIST w trakcie testu. Jeśli krok płatności generuje 200+ zapytań, winne są zwykle reguły cenowe i przeliczanie koszyka, a nie sam moduł płatności.

Na mobile skróć formularz: w Klienci → Adresy odznacz pola, których nie potrzebujesz, dodaj atrybuty autocomplete (email, tel, postal-code, street-address, cc-number) i inputmode dla pól liczbowych, a fonty ustaw z font-display: swap, żeby zmiana kroku nie migała. Gdy problemem jest serwer, zobaczysz to po sygnałach: 5xx przy składaniu zamówienia, timeouty webhooków płatności, wolne zapisy do ps_orders, błędy „Too many connections” i backup w godzinach szczytu. Zamiana VPS na maszynę z lepszym dyskiem bywa tańsza niż pół roku optymalizacji modułów — kryteria wyboru wykonawcy opisaliśmy w tekście o tym, kogo wybrać do wdrożenia PrestaShop i ile to kosztuje.

Pomiar lejka: GA4, DataLayer i pytanie „gdzie dokładnie tracę klientów”

Zdarzenia GA4 dla checkoutu mają jasne znaczenie: view_cart wysyłasz, gdy klient otwiera koszyk, begin_checkout przy wejściu na pierwszy krok zamówienia, add_shipping_info po wybraniu przewoźnika i przejściu dalej, add_payment_info po zatwierdzeniu metody płatności, purchase dopiero na order-confirmation. Błąd numer jeden to wysyłanie add_shipping_info na klik w radio zamiast na przejście kroku — wtedy dwie osoby, które tylko oglądały listę kurierów, wyglądają jak porzucający na dalszym etapie.

W DataLayer musi trafić: currency, value (zgodne z kwotą zamówienia w PrestaShop, z dostawą i podatkiem), tablica items z item_id równym SKU/odniesieniu, nazwą, ceną po rabacie i ilością, a także shipping_tier (nazwa przewoźnika widoczna dla klienta) i payment_type. Braki, które widzimy najczęściej: brak waluty (GA4 przyjmuje domyślnie USD i przychód rozjeżdża się z fakturą), cena przed rabatem, wewnętrzne ID zamiast SKU oraz brak metody dostawy — bez niej nie odpowiesz, czy tracisz klientów na paczkomatach, czy na kurierze. Wdrożenie opisujemy szerzej w materiałach o GA4 eCommerce w PrestaShop i o DataLayer w PrestaShop bez chaosu.

Porzucenie na kroku dostawy i porzucenie na bramce to dwa różne problemy. W GA4 oba wyglądają jak wyjście z kroku 3, dopóki nie dodasz własnych zdarzeń: payment_redirect przed wyjściem do bramki i payment_return po powrocie. Dopiero z nimi rozdzielisz „nie chciał płacić online” od „bramka odrzuciła kartę”. Warto logować też checkout_error z kodem błędu walidacji.

Raport tygodniowy: Funnel exploration z czterema krokami, podział po urządzeniu, plus osobno koszyk → krok 1. Zamiast jednego „conversion rate” licz spadek procentowy między krokami; liczby rzędu 1000 sesji → 400 begin_checkout → 300 add_shipping_info → 180 add_payment_info → 120 purchase mówią, gdzie interweniować.

Pułapka duplikacji: powrót przyciskiem wstecz albo F5 na order-confirmation wysyła purchase ponownie. GA4 deduplikuje po transaction_id, ale tylko gdy identyfikator jest ten sam i nie zmieniasz go po drodze. Zabezpiecz się lokalnie: znacznik w localStorage z numerem zamówienia i blokada wysyłki na 30 dni. I nie uruchamiaj jednocześnie wbudowanego modułu GA4 i kontenera GTM — to najczęstsza przyczyna podwójnych zakupów w raportach.

Najczęstsze błędy i pułapki w PrestaShop checkout — i jak je wykryć

Trzy awarie odpowiadają za większość zamówień, które nie dochodzą do skutku: przewoźnik zniknął z listy, zamówienie kończy się błędem 500, płatność pobiera pieniądze dwa razy. Każdą da się zdiagnozować w kilkanaście minut, jeśli wiadomo, gdzie patrzeć.

Pusta stawka dostawy. Najczęstsza przyczyna to zmiana przypisania kraju do strefy w Międzynarodowe → Lokalizacja → Strefy albo dodanie kraju do strefy, do której żaden przewoźnik nie jest przypisany. PrestaShop nie pokazuje wtedy błędu — przewoźnik po prostu wypada z kroku „Dostawa”. Sprawdź w Przewoźnicy → Zakres i koszty, czy każda strefa z twojej konfiguracji ma przewoźnika, i przetestuj checkout dla Polski, Niemiec i kraju spoza UE. W Zaawansowane → Logi szukaj wpisów z „carrier”, na serwerze w error_log frazy „No carriers available”. Na środowisku testowym włącz _PS_MODE_DEV_ w config/defines.inc.php — produkcja ukrywa ostrzeżenia, które tam zobaczysz.

• Błąd 500 przy składaniu zamówienia. Trzy typowe źródła: moduł płatności lub kuriera wykonuje w walidacji zamówienia zewnętrzne wywołanie API i przekracza limit czasu; suma modułów przekracza memory_limit na tanim hostingu; po aktualizacji brakuje kolumn, które moduł dodawał we własnej metodzie install(). Punkt startowy to error_log z pełnym stack trace i zgodność wersji PHP z dokumentacją deweloperską PrestaShop.
• Podwójne zamówienia. Dwa wiersze w ps_orders dla tego samego id_cart w odstępie 2–5 sekund oznaczają podwójne kliknięcie albo powrót z bramki płatności i odświeżenie. Moduł płatności powinien blokować przycisk po pierwszym kliknięciu i przekazywać token idempotencji. Sprawdź zapytaniem: SELECT id_cart, COUNT(*) FROM ps_orders GROUP BY id_cart HAVING COUNT(*) > 1.
• Stary koszyk w sesji. Klient dodaje produkt, ty w tym czasie zmieniasz cenę, wagę albo kombinację w back office — checkout liczy kwotę z chwili dodania. Konflikt wyjdzie dopiero na płatności. Test: dodaj produkt do koszyka, zmień jego cenę, wróć do koszyka i przejdź do kroku dostawy.
• Nadpisane order-*.tpl. Po aktualizacji rdzenia lub motywu pliki w /themes/twoj-motyw/templates/checkout/ zostają stare. Zrób diff katalogu szablonów przed wdrożeniem (git, rsync -n) — różnice w order-confirmation.tpl i order-detail.tpl łapie się w minutę.

Kiedy postawić własny moduł checkoutu, a kiedy wystarczy konfiguracja

Punkt wyjścia: większość sklepów nie potrzebuje własnego checkoutu, tylko uporządkowanej konfiguracji i jednego dobrze wybranego modułu. Własny kod zaczyna się opłacać, gdy twoja logika sprzedaży nie mieści się w standardowych polach formularza.

Sygnały, że nadszedł czas na własny moduł:

• Wycena, której nie da się zapisać w regułach przewoźnika — np. stawka zależna jednocześnie od wagi, objętości paletowej i kodu pocztowego, liczona zapytaniem do zewnętrznego API.
• Rezerwacja stanu w ERP w trakcie zamówienia, przed potwierdzeniem płatności. Standardowy checkout nie ma na to miejsca — potrzebujesz własnego kroku.
• Nietypowa dostawa: okna czasowe, wybór punktu odbioru z zewnętrznej bazy, dostawa w konkretnych godzinach.

Pułapka modułu z marketplace. Działa w demo na motywie klasycznym, a potem okazuje się, że nadpisuje ten sam hook displayPaymentTop co moduł płatności, a autor nie wydał nowej wersji od dwóch lat. Koszt ukryty pojawia się nie przy zakupie, tylko przy pierwszej aktualizacji PrestaShop: motyw się rozjeżdża, support milczy, a ty płacisz za łatanie cudzego kodu.

Widełki do budżetu: konfiguracja 4–12 h, własny krok dostawy 40–80 h, przepisanie całego checkoutu 120–200 h. Licz to nie w izolacji, ale względem kosztu porzuceń. Przy 1000 zamówieniach miesięcznie i 2% porzuceń na kroku dostawy to 20 zamówień. Jeśli każde wymaga telefonu i ręcznego doliczenia stawki, a obsługa zajmuje 15 minut przy 100 zł/h, mówimy o 500 zł miesięcznie straconych tylko na samej obsłudze — nie licząc klientów, którzy nie wrócą.

Utrzymanie. Własny moduł to nie plik na serwerze, tylko zobowiązanie: kto reaguje po wydaniu nowej wersji PrestaShop, kto testuje po zmianie PHP, jaki jest czas reakcji. Ustal to przed startem, bo później brak SLA jest droższy niż sam kod. Sposób liczenia budżetu na całe wdrożenie rozkładamy w materiale o tym, ile realnie kosztuje wdrożenie sklepu na PrestaShop.

Lista kontrolna przed startem i po każdej aktualizacji

Testuj w stałej kolejności: koszyk → dane → dostawa → płatność → mail → ERP/magazyn. Nie przechodź dalej, dopóki poprzedni krok nie działa na wszystkich kombinacjach. Błąd w kroku dostawy maskuje problem z płatnością i tracisz czas na diagnozie złego elementu.

Środowisko testowe. Chrome, Safari na iOS (tam najczęściej wychodzą problemy z autouzupełnianiem i klawiaturą numeryczną), Firefox, Edge. Desktop plus ekran 360 px. Zawsze w trybie incognito — sesja i cache potrafią pokazać checkout, którego klient już nie zobaczy. Wyłącz cache w Zaawansowane → Wydajność (Cache: Nie) albo wyczyść /var/cache/prod i /var/cache/dev.

Po każdej aktualizacji PrestaShop, motywu i każdego modułu płatności lub kuriera sprawdź:

• czy pliki order-*.tpl w motywie nie zostały nadpisane i zawierają nowe pola,
• czy ps_orders ma wszystkie kolumny wymagane przez moduły,
• czy webhooki płatności wracają i status zmienia się na „Płatność zaakceptowana”,
• czy mail potwierdzający faktycznie wychodzi (sprawdź skrzynkę, nie log modułu),
• czy zamówienie trafiło do ERP lub magazynu.

Kto za co odpowiada. Klient: dane karty, przeglądarka, rozszerzenia blokujące. Wykonawca: konfiguracja, moduły, serwer, logi. W zgłoszeniu podaj: adres URL, datę i godzinę z sekundami, id_cart i id_order, krok, na którym wystąpił błąd, wybrany kraj i metodę dostawy, wersję PrestaShop i PHP, treść błędu oraz informację, czy problem powtarza się w incognito na innym urządzeniu. Bez tego pierwsie pół godziny pracy idzie na odtwarzanie sytuacji, a nie na naprawę. Jeśli po testach chcesz sprawdzić, czy zamówienia faktycznie dochodzą do analityki, zacznij od poprawnego wdrożenia GA4 eCommerce w PrestaShop — bez tego nie odróżnisz porzucenia od błędu technicznego.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Zamówienia od gości — Sprawdź przełącznik w Preferencje > Zamówienia i wykonaj test w trybie incognito. Nazwa sekcji bywa inna w zależności od wersji PrestaShop.
• Wymagane pola adresowe — Przejrzyj listę obowiązkowych pól adresu i porównaj ją z tym, co realnie potrzebujesz do wysyłki i faktury.
• Pole NIP dla B2B — Dodaj je tylko wtedy, gdy wystawiasz faktury. Sprawdź, czy jego walidacja nie odrzuca poprawnych numerów z prefiksem PL.
• Minimalna wartość zamówienia — Ustawienie potrafi uciąć tanie zamówienia i część ruchu mobilnego. Sprawdź, czy próg nie jest przypadkiem zbyt wysoki dla Twojego koszyka.
• Limity wagi i wymiarów u przewoźników — W konfiguracji każdego przewoźnika sprawdź zakresy wagowe i wymiarowe. Poza nimi stawka nie pojawi się wcale.
• Strefy i przedziały cenowe dostawy — Sprawdź, czy każdy przedział ma przypisanego przewoźnika i czy strefa obejmuje wszystkie kraje, do których wysyłasz.
• Kolejność i domyślna metoda płatności — Zweryfikuj w podglądzie zamówienia, czy metoda domyślna nie ukrywa pozostałych przy konkretnej formie dostawy.
• Tryb testowy bramki płatności — Wykonaj transakcję testową, a następnie przełącz na produkcję i powtórz test na minimalnej kwocie realnej płatności.
• Punkty odbioru InPost i DPD/DHL — Sprawdź, czy wybór punktu jest walidowany po stronie sklepu i co dzieje się z koszykiem, gdy API mapy nie odpowiada.
• Zachowanie koszyka po wylogowaniu i zmianie kraju — Zmień kraj dostawy w trakcie zamówienia i sprawdź, czy stawki oraz podatki przeliczyły się od nowa, bez zdublowanych pozycji.
• Walidacja kodu pocztowego — Przetestuj format z myślnikiem, ze spacją i bez separatora. Sprawdź, czy reguła nie odrzuca poprawnych kodów.
• Statusy po powrocie z bramki — Porównaj status zamówienia w back-office z zapisem transakcji u operatora dla tej samej płatności.
• Wydajność strony /order — Zmierzenie TTFB i LCP osobno na kroku koszyka i płatności daje punkt odniesienia przed dodaniem kolejnych skryptów.
• Trzy przejścia testowe — Gość, nowy zarejestrowany i powracający klient — każde osobno, po czyszczeniu ciasteczek, z zapisem numerów zamówień.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• PrestaShop – dokumentacja dla deweloperów
• web.dev – Core Web Vitals