PageSpeed 99/100 w realnym sklepie PrestaShop 9.1 z 80+ modułami

Większość case studies PageSpeed oszukuje. Pokazują prawie pusty motyw demo z hero image, trzema produktami i bez realnych modułów, osiągają 100 punktów i nazywają to dowodem. To niczego nie dowodzi — każdy pusty PrestaShop wypada dobrze. Trudne pytanie, które naprawdę zadaje sobie właściciel sklepu, jest inne: czy sklep, który realnie pracuje — slidery, mega menu, one-page checkout, live search, blog, popupy, loyalty, analytics — nadal może być szybki? Ten wpis odpowiada na to na przykładzie naszego produkcyjnego sklepu, nie sandboxa.

mypresta.rocks działa na PrestaShop 9.1 z ponad 80 aktywnymi modułami, i nie są to lekkie moduły tylko od konfiguracji. To moduły, które dostarczają własny CSS i JavaScript, podpinają się pod front office i renderują widoczne, interaktywne elementy: animowane slidery, rozwijane mega menu, pełny one-page checkout, silnik bloga z komentarzami i udostępnianiem, widget live search, social feeds, galerie produktów, sales popupy, countdown timery, cookie-consent banner, loyalty, analytics dashboards. To dokładnie taki stack, który normalnie niszczy wynik PageSpeed. U nas zostaje na 99.

Ten artykuł to case study: realne liczby z naszej działającej strony głównej i sposób, w jaki zbudowany jest pipeline, który je daje. Celowo nie jest to ogólny poradnik "jak przyspieszyć PrestaShop" — mechanikę bazową opisują powiązane przewodniki, do których linkujemy przy konkretnych tematach, żebyś mógł wejść tak głęboko, jak potrzebujesz, bez powtarzania tego samego.

Wyniki mierzone przez Google — nie przez nas

Te liczby pochodzą z Google PageSpeed Insights, które uruchamia Lighthouse na infrastrukturze Google przeciwko naszej działającej stronie głównej. To nie są wyniki z lokalnego narzędzia, które można sobie podrasować; to dokładnie raport, który każdy merchant może sprawdzić w tej chwili.

Wynik Performance jest ważoną mieszanką metryk labowych Core Web Vitals, więc metryki stojące za liczbą są ważniejsze niż sama liczba. Oto pełne rozbicie dla obu typów urządzeń.

Liczy się kolumna mobile. Google indeksuje mobile-first i dławienie testu mobile ustawia na Slow 4G na telefonie ze średniej półki, co jest brutalne w porównaniu z desktopem na szybkim łączu. LCP 1.5s i CLS dokładnie 0 przy takim throttlingu — z 80+ modułami live — to wynik, który chcieliśmy pokazać. Co Ci to daje? Sklep, w którym strona jest używalna w okolicach jednej sekundy na realnym telefonie i realnej sieci, czyli tam, gdzie odbywa się większość ruchu i większość porzuceń.

Dlaczego 80+ modułów to sedno sprawy

Liczba modułów to zmienna, której wszyscy się boją i której prawie nikt nie benchmarkuje uczciwie. Każdy moduł front-office w PrestaShop zwykle dodaje trzy koszty: dodatkowy CSS, dodatkowy JavaScript i dodatkowe wykonanie hooków przy każdym renderowaniu strony. System CCC PrestaShop (Advanced Parameters → Performance — "Combine, Compress and Cache") redukuje i łączy kwalifikujące się CSS i JS, często do znacznie mniejszej liczby wygenerowanych plików — dokładna liczba zależy od tego, jak motyw i moduły rejestrują assety, typy media i wykluczenia — co rozwiązuje dużą część problemu liczby requestów, ale tworzy problem payloadu: w naszym sklepie połączony stylesheet miał przed obróbką ponad 850KB, a przytłaczająca większość to reguły, które nigdy nie odpalają na stronie głównej.

To jest prawdziwy powód, dla którego ciężkie sklepy wydają się wolne — nie "za dużo modułów" jako moralna wada, tylko megabajty połączonego CSS/JS blokujące pierwszy paint, podczas gdy przeglądarka parsuje reguły i skrypty, których odwiedzający nigdy nie uruchomi. Jeśli chcesz wersję diagnostyczną — jak rozpoznać, która warstwa faktycznie boli — to osobny temat opisany w co naprawdę spowalnia PrestaShop oraz w workflow sprawdzania czy Twój sklep jest wolny i jak to sprawdzić. Tutaj chodzi o to, że zostawiliśmy wszystkie 80+ modułów i zaatakowaliśmy payload zamiast kasować funkcje.

Jak pipeline jest zbudowany, warstwa po warstwie

Nie ma jednego przełącznika. Wynik 99 to suma zdyscyplinowanego pipeline'u, który dotyka ścieżki renderowania na każdej warstwie. Poniżej pokazujemy, co robi każdy etap i, co ważniejsze, dlaczego przesuwa metryki — z linkami do głębszej teorii tam, gdzie osobny przewodnik omawia temat dokładniej.

Ekstrakcja Critical CSS i ładowanie async

Render-blocking CSS to największy wróg szybkiego first paint: przeglądarka niczego nie narysuje, dopóki nie ma stylesheetu. Wstawienie inline całego pliku 500KB+ byłoby gorsze, nie lepsze. Zamiast tego wyciągamy above-the-fold critical CSS dla strony i wstawiamy inline tylko ten mały fragment bezpośrednio w HTML; pełny połączony stylesheet jest potem ładowany asynchronicznie wzorcem media="print" onload, więc pobiera się w tle bez blokowania. Przeglądarka od razu maluje stronę na podstawie krytycznych styli inline, a potem przełącza się na pełny arkusz, kiedy dotrze. Korzyść: strona jest widoczna po około sekundzie zamiast czekać na pół megabajta CSS, a ponieważ krytyczny fragment już styluje to, co jest na ekranie, przełączenie nie powoduje żadnego layout shift.

Purge CSS

Przy 80+ modułach połączony CSS niesie tysiące selektorów, które nie pasują do niczego na danej stronie. Uruchamiamy PurgeCSS na realnym wyrenderowanym HTML kluczowych typów stron oraz na każdym pliku JavaScript i template w motywie i modułach, żeby klasy przełączane dynamicznie przetrwały. W naszym sklepie zmniejszyło to stylesheet z 852KB do 548KB — cięcie o 36%. Mniej CSS to mniej pobierania na Slow 4G, mniej parsowania na CPU ze średniej półki i szybsze, stabilne przełączenie bez przesunięć.

Dzielenie i odraczanie JavaScript

Nie cały JavaScript musi działać, zanim strona stanie się interaktywna. Dzielimy bundle JavaScript CCC na dwa:

• Sync bundle (~140KB / 41KB gzip): tylko core, którego strona naprawdę potrzebuje wcześnie — jQuery i skrypty core PrestaShop.
• Deferred bundle (~497KB / 111KB gzip): Bootstrap, skrypty motywu i niekrytyczne skrypty modułów, ładowane z atrybutem defer, żeby wykonały się po sparsowaniu dokumentu.

Odraczanie ciężkiego bundle'a trzyma go poza main thread w krytycznym oknie, co zbija Total Blocking Time do 110ms na mobile i 30ms na desktopie. TBT to metryka, na której sklepy z dużą liczbą modułów padają najczęściej, bo każdy skrypt modułu chce ruszyć naraz przy load.

Inteligentne, kontekstowe ładowanie assetów

Najbardziej marnotrawny wzorzec w performance PrestaShop to wysyłanie JavaScriptu checkout i płatności do odwiedzających, którzy czytają bloga. Ładujemy kontekstowo: JavaScript checkoutu (180KB+ po minifikacji) jest w pełni odroczony na stronach innych niż checkout, na stronie głównej i stronach contentowych wciągany przez requestIdleCallback, żeby był gotowy w razie potrzeby, ale nigdy nie konkurował podczas first paint, a natychmiast ładowany tylko na stronach produktu, koszyka i checkout, gdzie faktycznie jest używany. JavaScript płatności Stripe jest całkowicie usunięty ze stron innych niż checkout. I co z tego? Klient wchodzący na wpis blogowy lub kategorię nie płaci kosztu pobrania i wykonania checkoutu, którego jeszcze nie używa.

Optymalizacja obrazów bez narzutu PHP

Obrazy zwykle są elementem LCP, więc decydują o najważniejszej metryce. Każdy obraz produktu i bannera jest serwowany jako AVIF przez content negotiation Apache — przełączenie na nowoczesny format dzieje się na poziomie web serwera, z zerowym narzutem PHP na request. Nasz batch converter przetworzył 5 399 obrazów i zmniejszył całkowity storage obrazów z 994MB do 44MB (95,6% mniej). Mobile hero banner kończy na 25KB, desktopowa wersja na 56KB, oba w jakości, po której nie zauważyłbyś kompresji.

Po stronie Apache to tylko content negotiation: podaj pre-generowany .jpg.avif albo .png.avif tylko wtedy, gdy przeglądarka zgłasza obsługę AVIF, i zachowaj Vary: Accept, żeby cache nie mieszał formatów.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/avif
  RewriteCond %{DOCUMENT_ROOT}/$1.$2.avif -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,E=avif:1,L]
</IfModule>

<IfModule mod_headers.c>
  Header append Vary Accept env=avif
</IfModule>

Wynik PageSpeed powstał przez redukcję payloadu, nie przez usuwanie modułów.

Jedna nieintuicyjna lekcja jest warta więcej niż dowolne ustawienie: preloadujemy tylko obraz LCP dla mobile i nic więcej. Na Slow 4G przy około 200KB/s każdy dodatkowy preload konkuruje z krytycznym CSS o tę samą wąską rurę. Preload fontu webowego albo desktopowego bannera faktycznie pogorszył nasz mobile FCP — zmierzyliśmy to, cofnęliśmy i ta powściągliwość jest częścią powodu, dla którego LCP ląduje na 1.5s.

Accessibility jako cel, nie efekt uboczny

Wynik Accessibility 97 jest zaprojektowany, nie przypadkowy. Wymagał trzymania każdego elementu w kontraście WCAG 2.1 AA (4.5:1 dla tekstu głównego, 3:1 dla dużego tekstu), widocznych focus indicators na elementach interaktywnych, poprawnej hierarchii nagłówków z ARIA labels i właściwego użycia narzędzia visually-hidden, żeby screen readery dostawały treść ukrytą wzrokowo. Dlaczego właściciel sklepu powinien się tym przejmować: ta sama dyscyplina, która czyni stronę dostępną — uczciwy kontrast, brak skoków layoutu, przewidywalny focus — utrzymuje CLS na 0 i chroni realnych klientów przed pomyłkami. Accessibility i conversion idą w tę samą stronę.

Czego to case study celowo nie obejmuje

Optymalizacja renderowania front-endu to tylko połowa szybkości sklepu. Druga połowa dzieje się na serwerze, zanim choć jeden bajt trafi do przeglądarki — czas zapytań do bazy, object caching, full-page caching i hosting — a każdy z tych tematów jest na tyle głęboki, że zasługuje na własny przewodnik, nie akapit tutaj. Opisanie ich osobno pozwala też uniknąć powtarzania tej samej rady w pięciu wpisach.

• Baza danych i obciążenie zapytań. Wolna warstwa zapytań ogranicza to, jak szybki może wydawać się dowolny front-end, a sklep szybki pierwszego dnia robi się cięższy wraz ze wzrostem tabel. Mechanika jest w performance tuning od zapytań bazy danych po full-page cache, a perspektywa "dlaczego z czasem degraduje" w czyszczeniu bazy danych.
• Full-page caching. Serwowanie zcache'owanej strony HTML omija PHP i bazę dla powtarzalnych anonimowych wejść — co moduły FPC naprawdę robią i jakie mają trade-offy, opisujemy w wyjaśnieniu modułów full-page cache dla PrestaShop.
• Server-side object caching z Redis. Dlaczego pomaga i czego się spodziewać, jest w Redis dla PrestaShop, a praktyczna konfiguracja w konfiguracji Redis cache i zyskach performance.
• Hosting. Najszybszy front-end nadal stoi na serwerze; co naprawdę ma znaczenie, a co jest marketingiem, opisujemy w wyborze hostingu dla PrestaShop.

Jak odtworzyć to we własnym sklepie

Jeśli weźmiesz powyższe liczby i spróbujesz zweryfikować zmianę w swoim sklepie, zrób to w sposób odporny na krytykę, nie taki, który sam Cię oszuka. Zanim czegokolwiek dotkniesz, uruchom PageSpeed Insights na stronie, na której Ci zależy, i zapisz cztery metryki labowe napędzające wynik — LCP, TBT, CLS i Speed Index — osobno dla mobile i desktop, bo ruszają się niezależnie. Wprowadzaj jedną kategorię zmian naraz (CSS, potem JS, potem obrazy), testuj ponownie i zostaw zmianę tylko wtedy, gdy metryka, w którą celowała, faktycznie się poprawiła. Lekcja z preloadem powyżej jest ostrzeżeniem: zmiana, która brzmi jak optymalizacja, może pogorszyć mobile FCP, a złapiesz to tylko wtedy, gdy mierzysz przed i po, zamiast wierzyć broszurze.

Jedno uczciwe zastrzeżenie do samych wyników: wyniki labowe PageSpeed różnią się o kilka punktów między uruchomieniami i zależą od testowanej strony oraz bieżącego obciążenia serwera. Traktuj 99 jako "konsekwentnie świetnie", nie stałą wartość — stabilny jest kształt wyniku: mobile LCP poniżej 2 sekund i prawie zerowy CLS w pełnym funkcjonalnie sklepie.

Gdzie wchodzą moduły

Powód, dla którego to case study istnieje, jest prosty: każda technika powyżej nie jest jednorazowym rozwiązaniem zbudowanym ręcznie tylko dla naszej strony i schowanym dla siebie — jest spakowana. W konfiguracji zmierzonej w tym case study moduł Performance Revolution jest pipeline'em stojącym za tymi liczbami — live PageSpeed report naszej strony głównej jest dowodem: ekstrakcja critical CSS i async swap, purge CSS, podział JavaScript na sync/deferred, kontekstowe odraczanie checkout i Stripe oraz dostarczanie obrazów AVIF. Co to oznacza dla Ciebie? Dostajesz front-end optimization, która zrobiła ten wynik 99, konfigurowaną z back office zamiast płacić developerowi za ręczną przebudowę render pipeline'u — a ponieważ działa na warstwie asset-pipeline, zamiast forkować motyw, nie pęka przy kolejnej aktualizacji.

Front-end to połowa stacku, więc łączymy go z Instant Redis do server-side object caching — front-end pipeline sprawia, że strona renderuje się szybko, kiedy PHP już ją wyprodukuje, a Redis sprawia, że PHP produkuje ją szybciej. Razem obejmują obie połowy problemu szybkości, które opisuje ten wpis i jego serwerowe odpowiedniki.

Wniosek jest wąski i uczciwy: realny sklep PrestaShop 9.1 z 80+ aktywnymi, ciężkimi front-endowo modułami może osiągać 99/100 w tym samym teście Google, którego używasz do oceny własnego sklepu. Nie wymaga to usuwania funkcji ani pustego motywu demo. Wymaga atakowania payloadu assetów zamiast listy funkcji, mierzenia każdej zmiany na profilu mobile, który Google faktycznie waży, i traktowania warstw serwerowych — bazy danych, full-page cache, Redis, hostingu — jako drugiej połowy pracy, nie dodatku na koniec.