Szybkość sklepu internetowego: co realnie skraca czas ładowania

Od czego zależy wydajność sklepu

Wydajność sklepu internetowego to wynik działania wielu elementów jednocześnie. Przeglądarka musi pobrać dokument HTML, arkusze CSS, skrypty JavaScript, obrazy, czcionki i inne zasoby, a serwer musi wcześniej przygotować odpowiedź.

Na końcowy czas wpływają między innymi:

• hosting i czas odpowiedzi serwera,
• sposób generowania stron,
• baza danych,
• cache,
• rozmiar obrazów,
• liczba i wielkość skryptów,
• arkusze CSS,
• czcionki,
• zewnętrzne narzędzia,
• reklamy i analityka,
• sposób ładowania zasobów,
• urządzenie użytkownika,
• jakość połączenia internetowego.

Dlatego nie istnieje jedna optymalizacja, która automatycznie przyspieszy każdy sklep. Najpierw trzeba ustalić, co faktycznie jest wąskim gardłem.

Core Web Vitals i rzeczywiste doświadczenie użytkownika

Core Web Vitals to zestaw metryk używanych do oceny wybranych aspektów doświadczenia użytkownika. Obejmują między innymi szybkość ładowania głównej treści, responsywność oraz stabilność wizualną.

Obecny zestaw Core Web Vitals obejmuje LCP, INP i CLS. Google wskazuje, że metryki te mają pomagać oceniać rzeczywiste doświadczenie użytkowników na stronach internetowych.

Jak czytać te wskaźniki w sklepie, skąd biorą się różnice między testem a danymi użytkowników i od czego zacząć poprawki, opisuje przewodnik po Core Web Vitals w sklepie.

LCP

Largest Contentful Paint, LCP, mierzy czas potrzebny do wyrenderowania największego elementu treści widocznego w początkowym widoku strony.

Jeżeli LCP jest słaby, trzeba ustalić, jaki element jest jego źródłem. Może to być obraz hero, duży blok tekstowy albo inny element zależny od sposobu budowania strony.

Nie należy więc optymalizować wszystkich obrazów tylko dlatego, że LCP jest za wysoki. Najpierw trzeba znaleźć element odpowiadający za wynik.

INP

Interaction to Next Paint, INP, odnosi się do responsywności strony na interakcje użytkownika.

Problem może wynikać między innymi z ciężkiego JavaScriptu, długich zadań wykonywanych przez główny wątek przeglądarki lub zbyt dużej liczby operacji wykonywanych po interakcji.

W sklepie może to być szczególnie widoczne podczas otwierania menu, filtrowania produktów, zmiany wariantu, dodawania produktu do koszyka albo obsługi formularza.

CLS

Cumulative Layout Shift, CLS, mierzy nieoczekiwane przesunięcia elementów podczas ładowania strony.

Jeżeli przycisk zakupu przesuwa się w momencie ładowania obrazu lub reklamy, użytkownik może przypadkowo kliknąć inne miejsce. Dlatego stabilność wizualna jest również elementem użyteczności sklepu.

Hosting i czas odpowiedzi serwera

Jeżeli serwer długo przygotowuje odpowiedź HTML, optymalizacja obrazów po stronie przeglądarki nie rozwiąże głównego problemu.

Czas odpowiedzi może zależeć od:

• wydajności CPU,
• dostępnej pamięci,
• konfiguracji serwera WWW,
• bazy danych,
• wersji PHP lub innego środowiska wykonawczego,
• cache,
• obciążenia serwera,
• kodu aplikacji,
• zewnętrznych żądań wykonywanych podczas generowania strony.

Nie wybieraj hostingu tylko po parametrach sprzętowych

Liczba rdzeni i ilość pamięci nie wystarczą do oceny hostingu.

Dwa serwery o podobnych parametrach mogą zapewniać różne czasy odpowiedzi ze względu na konfigurację, obciążenie, oprogramowanie i sposób działania aplikacji.

Warto mierzyć rzeczywisty czas odpowiedzi sklepu i porównywać go w różnych momentach oraz dla różnych typów stron.

Na co zwrócić uwagę przy hostingu sklepu

Sklep ma inne wymagania niż strona firmowa. Obsługuje produkty, warianty, koszyk, sesje, płatności, konta klientów, rabaty, stany magazynowe i integracje, więc przy wyborze hostingu sprawdź:

• czy obsługuje aktualną wersję PHP zgodną ze sklepem i jego dodatkami,
• czy baza danych działa stabilnie i czy serwer nie ma agresywnych limitów procesów,
• czy jest cache po stronie serwera, np. Redis albo podobne rozwiązanie,
• czy są kopie zapasowe i czy da się z nich łatwo odtworzyć sklep po awarii,
• czy zasoby można zwiększyć bez migracji całego sklepu,
• czy wsparcie techniczne zna Twoją platformę.

Przy większej liczbie produktów, wariantów i integracji najtańszy pakiet współdzielony zwykle staje się wąskim gardłem. Nie chodzi o najdroższy serwer, tylko o środowisko dopasowane do obciążenia konkretnego sklepu.

Aktualizacja PHP bez niespodzianek

Nowsza wersja PHP potrafi wyraźnie skrócić czas generowania strony, ale stare wtyczki, moduły i motywy mogą nie być z nią zgodne. Przed zmianą zrób pełną kopię plików i bazy, sprawdź nową wersję na kopii sklepu, a potem przejdź panel, koszyk, płatności, moduły dostawy i integracje z zewnętrznymi systemami.

Cache jako sposób ograniczenia pracy serwera

Cache pozwala wykorzystać wcześniej przygotowane dane lub wygenerowaną stronę zamiast wykonywać te same operacje przy każdym żądaniu.

W sklepie można spotkać różne poziomy cache, między innymi cache strony, obiektów, zapytań lub zasobów przeglądarki.

Cache strony

Jeżeli dana strona może być bezpiecznie cache’owana, serwer może zwrócić gotową odpowiedź bez pełnego wykonywania aplikacji.

Nie każda strona sklepu może jednak działać w taki sam sposób. Koszyk, konto klienta i inne elementy zależne od użytkownika wymagają szczególnej konfiguracji.

Błędnie skonfigurowany cache może powodować nie tylko problemy wydajnościowe, ale również wyświetlanie niewłaściwych danych.

Zasada jest prosta: cache nie może mieszać danych klientów. Z pełnego cache wyłącz koszyk, checkout i konto klienta, a ostrożnie traktuj produkty z dynamicznymi cenami lub personalizacją, promocje i rabaty zależne od klienta, stany magazynowe oraz moduły walut i języków. Jeżeli klient zobaczy cudzy koszyk, błędną cenę albo nieaktualną dostępność, optymalizacja jest po prostu zepsuta.

Cache przeglądarki

Przeglądarka może przechowywać zasoby, które nie zmieniają się często. Dzięki temu kolejna wizyta nie musi pobierać wszystkiego ponownie.

Warto odpowiednio ustawić nagłówki cache dla statycznych plików, pamiętając o strategii wersjonowania zasobów po ich zmianie.

Największe przyspieszenia zwykle wynikają z optymalizacji zasobów, cache i infrastruktury serwera.

Obrazy są częstym źródłem obciążenia

Duże zdjęcia produktów mogą stanowić znaczną część danych pobieranych przez przeglądarkę.

Problem nie zawsze polega na samym formacie. Liczy się również rozdzielczość obrazu, kompresja, sposób dostarczenia i to, czy użytkownik rzeczywiście potrzebuje pełnego rozmiaru.

Dobierz rozmiar do zastosowania

Jeżeli miejsce na stronie ma szerokość 400 pikseli, przesyłanie obrazu o szerokości kilku tysięcy pikseli może być niepotrzebnym obciążeniem.

Warto generować odpowiednie warianty obrazów i używać responsive images, aby przeglądarka mogła pobrać wersję odpowiadającą urządzeniu i miejscu wyświetlania.

Nowoczesne formaty

Formaty takie jak WebP i AVIF mogą pozwolić zmniejszyć rozmiar plików przy zachowaniu odpowiedniej jakości obrazu. Nie należy jednak zamieniać wszystkich obrazów automatycznie bez sprawdzenia jakości i kompatybilności całego procesu.

Lazy loading

Obrazy znajdujące się poza początkowym widokiem mogą być ładowane później.

Nie należy jednak bezrefleksyjnie stosować lazy loading do elementu będącego źródłem LCP. Najważniejszy obraz powinien być dostępny odpowiednio wcześnie.

Banery i slidery

Wiele sklepów pilnuje zdjęć produktów, a zapomina o banerach marketingowych, które często ważą najwięcej. Ustal prostą zasadę: każda grafika trafia do sklepu w rozmiarze dopasowanym do miejsca wyświetlania i po kompresji, a nie prosto z programu graficznego.

Duży slider na stronie głównej zwykle ciągnie ciężkie grafiki, dodatkowy JavaScript i animacje, a że stoi na samej górze, opóźnia pokazanie najważniejszej treści. Często lepiej działa jedna sekcja startowa: jasny komunikat, kategorie główne i najważniejsza oferta. Slider oceniaj praktycznie: czy pomaga klientowi kupić, czy tylko dobrze wygląda.

JavaScript i skrypty zewnętrzne

Skrypty JavaScript mogą wykonywać wiele operacji po stronie przeglądarki. Im więcej kodu trzeba pobrać, przetworzyć i wykonać, tym większe może być obciążenie urządzenia użytkownika.

W sklepie źródłem skryptów mogą być między innymi:

• system analityczny,
• tagi reklamowe,
• czaty,
• systemy opinii,
• narzędzia marketingowe,
• mapy,
• popupy,
• rekomendacje produktów,
• integracje z zewnętrznymi usługami.

Usuń nieużywane skrypty

Jednym z najprostszych sposobów ograniczenia obciążenia jest sprawdzenie, które skrypty są rzeczywiście potrzebne.

Jeżeli narzędzie zostało zainstalowane kilka lat temu i nie jest już wykorzystywane, jego usunięcie może być bardziej sensowne niż dalsza optymalizacja sposobu ładowania.

Nie ładuj wszystkiego od razu

Nie każdy skrypt musi być wykonywany natychmiast.

Część funkcji może zostać uruchomiona dopiero wtedy, gdy użytkownik skorzysta z określonej funkcji. W innych przypadkach można zmienić kolejność ładowania lub odroczyć wykonanie kodu.

Trzeba jednak zachować poprawność działania analityki, reklam, zgód i funkcji sklepu.

Audyt dodatków i integracji

Raz na jakiś czas przejdź przez listę wtyczek, modułów i zewnętrznych narzędzi z jednym pytaniem: czy to jest naprawdę potrzebne? Sprawdź, które są nieużywane albo dublują funkcje, które ładują skrypty na każdej stronie, które są stare i nieaktualizowane, które dodają zapytania do bazy, a które są krytyczne dla sprzedaży. W wielu sklepach wiszą dodatki wgrane kiedyś do testu, promocji czy popupu, których nikt już nie używa, a które nadal pracują.

Przy integracjach zewnętrznych pilnuj kilku zasad: ładuj skrypty tylko tam, gdzie są potrzebne, opóźniaj elementy niekrytyczne, sprawdź, czy ten sam tag nie jest wstawiony kilka razy, i kontroluj skrypty w checkoucie. Nowe narzędzia marketingowe powinny przechodzić test techniczny przed wdrożeniem.

CSS i czcionki

Arkusze CSS również wpływają na proces renderowania strony.

Niepotrzebnie duże pliki, wiele bibliotek CSS i nieużywane reguły zwiększają ilość danych do pobrania oraz przetworzenia.

Czcionki mogą być kolejnym źródłem opóźnień. Warto ograniczyć liczbę rodzin i odmian fontów oraz zadbać o odpowiednie ładowanie.

Jeżeli własna czcionka nie jest dostępna natychmiast, należy sprawdzić, jak strona zachowuje się podczas jej ładowania i czy powoduje to przesunięcia lub opóźnienie wyświetlenia treści.

W obu platformach spowolnienia mogą wynikać z dodatków, zapytań, konfiguracji PHP lub serwera.

Baza danych i kod aplikacji

W dynamicznym sklepie czas odpowiedzi strony może zależeć od liczby i rodzaju zapytań do bazy danych.

Problem może pojawić się przy rozbudowanych filtrach, wyszukiwaniu produktów, sortowaniu, promocjach, wariantach lub modułach wykonujących wiele operacji.

Szukaj wolnych operacji

Zamiast zgadywać, który moduł spowalnia sklep, warto wykonać profilowanie i sprawdzić rzeczywisty czas operacji.

Można analizować między innymi:

• czas zapytań do bazy,
• liczbę zapytań,
• czas generowania strony,
• wykorzystanie pamięci,
• wywołania zewnętrznych usług.

Dopiero dane pozwalają ustalić, czy problem znajduje się w bazie, kodzie, module czy infrastrukturze.

Wydajność WooCommerce, PrestaShop i Shoper

Platforma ma znaczenie, ale sama nazwa systemu nie przesądza o szybkości sklepu.

WooCommerce działa w środowisku WordPress i może być rozbudowywany przez wiele wtyczek. Przy dużej liczbie rozszerzeń trzeba kontrolować ich wpływ na czas generowania strony i JavaScript.

PrestaShop również może być rozbudowywany przez moduły. Przy dużych katalogach szczególnie istotne są baza danych, wyszukiwanie, cache i sposób działania modułów.

Shoper jest rozwiązaniem SaaS, więc część infrastruktury pozostaje po stronie operatora platformy. Właściciel sklepu ma mniejszą kontrolę nad serwerem, ale również mniej obowiązków związanych z jego utrzymaniem.

Szczegółową diagnostykę dla konkretnych platform opisują osobne materiały: wydajność WooCommerce oraz wydajność PrestaShop i Shoper.

W każdym przypadku trzeba mierzyć konkretny sklep, ponieważ konfiguracja, katalog, szablon i integracje mogą mieć większy wpływ niż sama platforma.

CDN i dostarczanie zasobów

Content Delivery Network może przybliżyć statyczne zasoby do użytkownika i ograniczyć czas ich dostarczenia na większych odległościach.

CDN jest szczególnie przydatny przy obrazach, arkuszach CSS, JavaScript i innych zasobach statycznych.

Dla sklepu sprzedającego głównie w jednym kraju liczy się też lokalizacja serwera. Im bliżej głównej grupy klientów, tym krótsza droga odpowiedzi.

Nie rozwiązuje jednak problemu wolnego generowania strony po stronie serwera. Jeżeli HTML powstaje długo, trzeba poprawić backend lub zastosować odpowiedni cache.

Pomiar Core Web Vitals przed i po zmianach pozwala sprawdzić, czy optymalizacja przyniosła efekt.

Jak mierzyć wydajność

Do oceny wydajności warto korzystać z kilku źródeł danych.

Dane laboratoryjne

Narzędzia takie jak Lighthouse pozwalają wykonywać testy w kontrolowanych warunkach. Są przydatne do znajdowania problemów technicznych i porównywania zmian.

Nie pokazują jednak dokładnie doświadczenia każdego rzeczywistego użytkownika.

Dane rzeczywistych użytkowników

Dane terenowe, takie jak te wykorzystywane przy Core Web Vitals, pokazują doświadczenie użytkowników w rzeczywistych warunkach.

Mogą różnić się między urządzeniami, lokalizacjami, sieciami i typami stron.

Google wskazuje, że dane dotyczące rzeczywistych użytkowników są istotnym źródłem informacji o doświadczeniu ze stroną.

Porównuj przed i po

Najważniejszy jest pomiar przed zmianą oraz po jej wdrożeniu.

Jeżeli zmniejszysz rozmiar obrazów, sprawdź, czy rzeczywiście poprawił się LCP lub czas pobierania. Jeżeli usuniesz skrypt, sprawdź INP i zachowanie strony. Jeżeli zmienisz hosting, porównaj czas odpowiedzi serwera.

Nie każda optymalizacja daje widoczny efekt w każdej metryce.

Jak analizować raport Lighthouse

Nie należy optymalizować punktów w Lighthouse jako celu samego w sobie.

Jeżeli raport wskazuje duży obraz, sprawdź, czy jest on elementem LCP i ile faktycznie waży. Jeżeli wskazuje nieużywany JavaScript, ustal, z którego narzędzia pochodzi i czy można go usunąć.

Jeżeli pojawia się problem z czasem odpowiedzi serwera, przejdź do analizy backendu zamiast skupiać się na kompresji obrazów.

Raport jest narzędziem diagnostycznym. Najpierw trzeba zrozumieć problem, potem wprowadzić zmianę.

Kolejność optymalizacji sklepu

Dobrą praktyką jest zaczynanie od problemów o największym wpływie.

Zanim zaczniesz, zrób pełną kopię zapasową sklepu i przygotuj środowisko testowe. Zmiany w cache, motywie czy modułach najpierw sprawdzaj na kopii.

1. Zmierz podstawowe wartości

Sprawdź czas odpowiedzi serwera, LCP, INP, CLS oraz wielkość i liczbę pobieranych zasobów.

2. Znajdź największe zasoby

Sprawdź obrazy, JavaScript, CSS, fonty i inne pliki odpowiedzialne za największą część transferu.

3. Sprawdź backend

Jeżeli serwer długo przygotowuje HTML, przeanalizuj aplikację, bazę danych, moduły i cache.

4. Uporządkuj obrazy

Dopasuj rozmiary, formaty i sposób ładowania do miejsca wykorzystania.

5. Usuń zbędny JavaScript

Usuń nieużywane narzędzia i ogranicz kod wykonywany na starcie strony.

6. Popraw CSS i fonty

Ogranicz zbędne zasoby i sprawdź sposób ich ładowania.

7. Skonfiguruj cache

Wykorzystaj cache tam, gdzie jest bezpieczny i rzeczywiście ogranicza pracę serwera.

8. Ponownie zmierz wynik

Porównaj dane z tym samym typem strony i podobnymi warunkami testu.

Po zmianie sprawdź zakupy, nie tylko wynik

Da się podbić wynik testu i jednocześnie popsuć sklep: opóźnić skrypty tak agresywnie, że formularz płatności przestaje działać, albo połączyć pliki JavaScript w sposób, który psuje filtry. Po każdej optymalizacji przejdź więc prawdziwą ścieżkę zakupową:

• dodanie produktu do koszyka i zmiana ilości,
• kod rabatowy, wybór dostawy i płatności,
• złożenie testowego zamówienia,
• wyszukiwarka, filtry, formularze i konto klienta.

Sklep ma być szybszy, ale nadal stabilny. Szybkości nie kupuje się kosztem sprzedaży.

Wydajność strony głównej, kategorii i produktu

Nie powinno się oceniać sklepu na podstawie jednej strony.

Strona główna może mieć duże banery i wiele sekcji. Kategoria może ładować listę produktów, filtry i sortowanie. Karta produktu może zawierać galerie, warianty, rekomendacje i dodatkowe integracje.

Każdy typ strony może więc mieć inne źródło problemu.

Warto przygotować osobny zestaw testów dla:

• strony głównej,
• kategorii,
• wyników wyszukiwania,
• karty produktu,
• koszyka,
• checkoutu.

Sprawdź też panel administracyjny, wersję mobilną, sklep po zalogowaniu i sklep z produktami w koszyku. Strona może działać szybko dla gościa, a zwalniać dla zalogowanego klienta albo przy kilku wariantach i regułach rabatowych w koszyku.

Kategorie

Kategorie są zwykle najbardziej obciążone: pokazują wiele produktów, miniatury, ceny, etykiety, filtry, sortowanie i dodatkowe bloki. Najczęstsze problemy to zbyt wiele produktów ładowanych naraz, ciężkie miniatury, wolne filtry i sortowanie, rozbudowany opis nad listą, dodatkowe karuzele oraz ładowanie wariantów dla każdego produktu.

Karta produktu

Klient ma od razu widzieć nazwę, zdjęcie, cenę, warianty, dostępność i przycisk zakupu. Spowalniają ją zwykle ogromne zdjęcia galerii, wiele miniatur ładowanych od razu, ciężkie moduły opinii, sekcje cross-sell ładowane zbyt wcześnie, osadzone filmy i skrypty marketingowe. Nie wycinaj elementów sprzedażowych tylko dlatego, że są ciężkie. Najpierw sprawdź, czy da się je załadować później.

Checkout

Checkout powinien być najczystszą technicznie częścią sklepu. Sprawdź, czy pola formularza ładują się szybko, czy walidacja działa poprawnie, czy metody dostawy nie przeliczają się zbyt długo, czy kody rabatowe nie powodują błędów i czy na tym etapie nie ładują się zbędne skrypty reklamowe ani popupy.

Co daje największy efekt

Największe efekty często pochodzą z usunięcia konkretnego wąskiego gardła, a nie z dziesiątek kosmetycznych zmian.

Jeżeli serwer potrzebuje dużo czasu na wygenerowanie strony, priorytetem jest backend i cache. Jeżeli strona pobiera ogromne obrazy, trzeba poprawić ich rozmiar i sposób dostarczania. Jeżeli urządzenie długo wykonuje JavaScript, trzeba ograniczyć lub zoptymalizować kod.

Dlatego kolejność powinna wynikać z danych.

W małym sklepie zwykle najwięcej dają zdjęcia, cache, porządek w dodatkach i hosting. Przy dużym katalogu z wieloma wariantami i filtrami najczęściej kategorie, baza danych i moduły filtrujące. Jeżeli problem pojawia się głównie przy finalizacji zakupu, zacznij od checkoutu, płatności, dostaw i skryptów śledzących.

Wydajność a sprzedaż

Szybsza strona może ułatwić użytkownikowi przejście przez proces zakupowy, ale nie należy zakładać, że każda poprawa techniczna automatycznie zwiększy sprzedaż.

Jeżeli sklep jest wolny podczas przeglądania produktów, poprawa czasu ładowania może ograniczyć tarcie. Jeżeli problem występuje podczas checkoutu, priorytetem może być responsywność formularza i płatności.

Warto więc połączyć dane techniczne z danymi biznesowymi. Sprawdź, czy problemy z wydajnością występują na stronach, które generują dużą część ruchu lub sprzedaży.

Wydajność sklepu najlepiej traktować jako proces pomiaru, diagnozy i weryfikacji. Najpierw ustalasz, czy problem dotyczy serwera, cache, obrazów, CSS, JavaScriptu czy zewnętrznych usług. Następnie wprowadzasz zmianę, mierzysz jej efekt i dopiero wtedy przechodzisz do kolejnego problemu. Core Web Vitals pomagają ocenić doświadczenie użytkownika, ale pełna diagnoza wymaga również analizy infrastruktury, aplikacji i konkretnych stron sklepu. Dzięki temu optymalizacja nie sprowadza się do poprawiania wyniku jednego narzędzia, lecz do rzeczywistego skracania czasu oczekiwania i poprawy działania sklepu.