Sklep internetowy, który ładuje się dłużej niż 3 sekundy, traci realnych klientów na etapie samego wejścia na stronę. Właściciele e-commerce często reagują na to migracją na droższy hosting, co bywa strzałem w płot, jeśli problem leży gdzie indziej, na przykład w kodzie, bazie danych czy sposobie serwowania grafik. W tym artykule pokazuję konkretne techniki, które da się wdrożyć w istniejącym sklepie, bez zmiany infrastruktury.
Szybka odpowiedź
Przyspieszenie sklepu internetowego bez zmiany hostingu jest możliwe dzięki optymalizacji zapytań SQL, wdrożeniu wielopoziomowego cache (strony, obiektów, opcode), lazy loadingowi obrazków oraz redukcji liczby i wagi zapytań HTTP. Te techniki potrafią skrócić czas ładowania o 50-70% bez migracji serwera i bez zmiany planu hostingowego.
Najważniejsze wnioski
- Cache na poziomie strony, obiektów i opcode PHP daje największy i najszybszy zauważalny efekt, często w ciągu kilku godzin wdrożenia.
- Nieindeksowane kolumny w bazie danych i zapytania typu N+1 to najczęstsza przyczyna wolnych stron produktowych i kategorii w sklepach na WooCommerce, PrestaShop i Magento.
- Lazy loading obrazków i wideo poniżej pierwszego ekranu realnie skraca czas do interaktywności strony, ale trzeba go testować, bo źle wdrożony psuje Core Web Vitals.
- Redukcja liczby zapytań HTTP (łączenie plików CSS/JS, usuwanie nieużywanych wtyczek) często daje większy skok wydajności niż droższy serwer.
- Optymalizacja wydajności sklepu to proces iteracyjny, nie jednorazowa akcja, wymaga regularnego monitorowania metryk po każdej zmianie w katalogu produktów czy wtyczkach.
Cache: pierwsza linia obrony przed wolnym sklepem
Większość silników e-commerce (WooCommerce, PrestaShop, Magento, Shopware) generuje strony dynamicznie, odpytując bazę danych przy każdym wejściu użytkownika. Bez cache serwer wykonuje identyczną pracę setki razy dziennie dla tej samej strony kategorii, co jest czystym marnotrawstwem zasobów.
Cache całych stron
Full page cache zapisuje wygenerowaną wersję HTML strony i serwuje ją bezpośrednio, bez odpytywania bazy danych, dopóki treść się nie zmieni. W Magento to Varnish, w WooCommerce popularne są wtyczki typu WP Rocket czy LiteSpeed Cache, w PrestaShop wbudowany moduł cache lub Redis. Efekt bywa spektakularny: strony, które ładowały się 4-5 sekund, po wdrożeniu cache spadają do 0,5-1 sekundy.
Pułapka, na którą warto uważać: sklepy z dynamiczną zawartością (ceny personalizowane, stan magazynowy w czasie rzeczywistym, koszyk) wymagają wykluczenia niektórych fragmentów strony z cache lub zastosowania cache z częściową inwalidacją (ESI, hole punching). Bez tego klienci mogą widzieć nieaktualne ceny lub stany produktów.
Cache obiektów i opcode
Object cache (Redis lub Memcached) przechowuje w pamięci wyniki kosztownych operacji, na przykład listy produktów w kategorii czy wyniki filtrowania. Opcode cache (OPcache w PHP) eliminuje potrzebę ponownej kompilacji kodu PHP przy każdym żądaniu. Włączenie OPcache to jedna z najprostszych zmian konfiguracyjnych, a często jest domyślnie wyłączona lub źle skonfigurowana na współdzielonym hostingu.
W jednym z projektów, który wdrażaliśmy w EXOLAB, sklep na Magento miał wyłączony Redis dla cache sesji i katalogu produktów. Samo włączenie i poprawna konfiguracja skróciły czas generowania strony kategorii z 2,8 sekundy do 400 milisekund, bez dotykania serwera.
Optymalizacja zapytań SQL: gdzie naprawdę tkwi problem
Wolna baza danych to najczęstsza, ale najrzadziej diagnozowana przyczyna wolnego sklepu. Symptomy są zdradliwe: strona ładuje się szybko przy małym katalogu produktów, ale drastycznie zwalnia po dodaniu kilku tysięcy pozycji.
Indeksy i brakujące klucze
Kolumny używane w warunkach WHERE, JOIN i ORDER BY (SKU, kategoria, status produktu, data dodania) powinny mieć indeksy. Ich brak sprawia, że baza przeszukuje całą tabelę przy każdym zapytaniu, co przy tabeli z 50 tysiącami produktów oznacza realne opóźnienie liczone w setkach milisekund na jedno zapytanie.
Problem N+1
Klasyczny błąd w sklepach opartych na frameworkach z ORM: strona listy produktów wykonuje jedno zapytanie o produkty, a potem dla każdego produktu osobne zapytanie o cenę, stan magazynowy czy zdjęcia. Przy 20 produktach na stronie to 21 zapytań zamiast 2-3. Rozwiązanie to eager loading, czyli pobranie wszystkich potrzebnych danych w jednym zoptymalizowanym zapytaniu z odpowiednimi JOIN-ami.
Analiza slow query log
Włączenie logu wolnych zapytań (slow query log w MySQL) i przegląd zapytań trwających powyżej 200-300 milisekund pokazuje konkretne miejsca do naprawy. To praca detektywistyczna, ale zwykle 3-4 najgorsze zapytania odpowiadają za 70% problemów z wydajnością bazy.
Lazy loading i optymalizacja grafik
Zdjęcia produktów to zwykle największa część wagi strony sklepu internetowego, często 60-80% całkowitego rozmiaru. Lazy loading oznacza, że obrazki poniżej pierwszego ekranu (below the fold) nie są ładowane, dopóki użytkownik nie przewinie strony w ich stronę.
Wdrożenie jest proste technicznie: atrybut loading="lazy" w tagu img jest wspierany natywnie przez wszystkie nowoczesne przeglądarki, bez potrzeby dodatkowych bibliotek JavaScript. Ważne, żeby nie stosować lazy loadingu do obrazka w pierwszym widoku (hero image czy główne zdjęcie produktu), bo to pogarsza metrykę Largest Contentful Paint, kluczową dla Core Web Vitals i rankingu w Google.
Drugim elementem jest konwersja do formatu WebP lub AVIF, które przy tej samej jakości wizualnej dają pliki 25-35% mniejsze niż JPEG. Wdrożenie responsywnych obrazków (atrybut srcset) dodatkowo zapewnia, że telefon nie ściąga zdjęcia w rozdzielczości 4K przeznaczonego na duży monitor.
| Technika | Redukcja wagi strony | Złożoność wdrożenia |
|---|---|---|
| Lazy loading obrazków | 20-40% (czas ładowania początkowego) | Niska |
| Konwersja do WebP/AVIF | 25-35% wagi grafik | Średnia |
| Responsywne obrazki (srcset) | 15-30% na urządzeniach mobilnych | Średnia |
| Kompresja bez utraty jakości | 10-20% wagi grafik | Niska |
Redukcja zapytań HTTP i minifikacja zasobów
Każdy plik CSS, JavaScript czy font to osobne zapytanie HTTP, a każde zapytanie to opóźnienie, zwłaszcza na połączeniach mobilnych. Typowy sklep z 15-20 aktywnymi wtyczkami czy modułami generuje 60-80 zapytań tylko dla samych zasobów statycznych.
Minifikacja i łączenie plików CSS i JS w mniejszą liczbę zoptymizowanych plików to podstawa. Większość platform e-commerce ma wbudowane lub dostępne jako wtyczki narzędzia do tego (np. wbudowana minifikacja w Magento 2, wtyczki typu Autoptimize w WordPressie). Trzeba jednak testować po każdej zmianie, bo agresywne łączenie plików JS może zepsuć funkcjonalność, jeśli skrypty mają zależności ładowane w konkretnej kolejności.
Audyt wtyczek i modułów to często najbardziej niedoceniana czynność. W jednym audycie sklepu na WooCommerce znaleźliśmy 6 aktywnych wtyczek, które nie były używane od ponad roku, a każda ładowała własne pliki CSS i JS na każdej podstronie. Ich usunięcie skróciło czas ładowania o 1,2 sekundy, bez żadnej zmiany w kodzie czy infrastrukturze.
Priorytetyzacja: co wdrożyć najpierw
Nie każda technika daje taki sam zwrot z włożonego czasu. Jeśli sklep ma ograniczony budżet na optymalizację wydajności sklepu, najlepiej zacząć od cache stron i obiektów, bo to zmiana konfiguracyjna, a nie programistyczna, i przynosi efekt w ciągu godzin. Następnie warto zrobić audyt slow query log i naprawić 3-5 najgorszych zapytań SQL, co zwykle zajmuje 1-2 dni pracy programisty backendowego.
Lazy loading i optymalizacja grafik to kolejny krok, dobry do wdrożenia równolegle z pracami nad backendem, bo dotyczy frontendu i nie wymaga zmian w bazie danych. Na końcu redukcja zapytań HTTP i audyt wtyczek, bo wymaga najwięcej testów regresyjnych, żeby nie zepsuć funkcjonalności sklepu przy usuwaniu niepotrzebnych zasobów.
Najczęściej zadawane pytania
Czy zmiana hostingu jest konieczna, żeby przyspieszyć sklep internetowy?
Zwykle nie. W większości sklepów problemy z wydajnością wynikają z niezoptymalizowanego kodu, złych zapytań SQL, braku cache i nadmiernej liczby zapytań HTTP, a nie z samego hostingu. Zmiana serwera bez usunięcia tych problemów da tylko chwilową poprawę.
Jak szybko można zauważyć efekty optymalizacji sklepu?
Wdrożenie cache i lazy loadingu daje efekty praktycznie od razu, często w ciągu jednego dnia pracy. Optymalizacja zapytań SQL i refaktoryzacja kodu wymagają więcej czasu na testy, ale efekty widać zwykle w ciągu tygodnia.
Czy lazy loading obrazków wpływa na SEO?
Wpływa pozytywnie, o ile jest wdrożony poprawnie z atrybutem loading=lazy i odpowiednimi wymiarami obrazków. Źle wdrożony lazy loading może pogorszyć Largest Contentful Paint, więc warto go testować w Google PageSpeed Insights.
Ile może kosztować optymalizacja wydajności sklepu bez zmiany infrastruktury?
To zależy od skali problemów, ale w typowym sklepie na Magento, PrestaShop czy WooCommerce audyt plus wdrożenie podstawowych technik (cache, SQL, lazy loading) to zwykle kilkanaście do kilkudziesięciu godzin pracy programisty.
Czy CDN jest potrzebny, jeśli już mam dobry hosting?
CDN i dobry hosting to dwie różne warstwy optymalizacji. Hosting odpowiada za przetwarzanie żądań po stronie serwera, a CDN skraca czas dostarczenia statycznych plików do użytkownika. Warto mieć oba, niezależnie od jakości serwera.
Słowniczek
Full page cache
Mechanizm zapisujący wygenerowaną wersję HTML strony, dzięki czemu kolejne żądania nie wymagają ponownego odpytywania bazy danych i generowania treści od zera.
Lazy loading
Technika ładowania zasobów (zwykle obrazków i wideo) dopiero w momencie, gdy stają się widoczne dla użytkownika, a nie od razu przy wczytywaniu strony.
N+1 query problem
Błąd wydajnościowy, w którym aplikacja wykonuje jedno zapytanie o listę obiektów, a następnie osobne zapytanie dla każdego z nich, zamiast pobrać wszystko w jednym zoptymalizowanym zapytaniu.
OPcache
Rozszerzenie PHP przechowujące skompilowany kod w pamięci, eliminujące potrzebę ponownej kompilacji skryptów przy każdym żądaniu HTTP.
Core Web Vitals
Zestaw metryk Google (m.in. Largest Contentful Paint, Cumulative Layout Shift) mierzących wrażenia użytkownika związane z szybkością i stabilnością ładowania strony.
