Optymalizacja szybkości działania sklepu internetowego

Kilka sekund obniża sprzedaż

Klienci sklepów internetowych rzadko czekają cierpliwie. Dłuższe ładowanie strony przekłada się bezpośrednio na porzucone koszyki — i jest to jeden z niewielu parametrów technicznych o tak bezpośrednim wpływie na przychód.

Co sprawdzamy w pierwszej kolejności

1. Zdjęcia produktów — rozmiar, format i to, czy są przeskalowane.
2. Liczbę i jakość zainstalowanych rozszerzeń.
3. Pamięć podręczną: czy w ogóle działa i co obejmuje.
4. Bazę danych: indeksy, rozmiar, zapytania wykonywane przy każdej stronie.
5. Serwer i jego parametry wobec rzeczywistego ruchu.
6. Skrypty zewnętrzne dodane do sklepu przez lata.

Zdjęcia

To przyczyna numer jeden i najprostsza do usunięcia. Fotografie wgrywane w oryginalnym rozmiarze potrafią ważyć kilkadziesiąt razy więcej niż potrzeba. Przeskalowanie i zmiana formatu daje zwykle największą pojedynczą poprawę w całym sklepie.

Skrypty zewnętrzne

Narzędzia analityczne, czaty, systemy opinii i piksele reklamowe dokładane przez lata. Każdy z nich opóźnia wyświetlenie strony. Przeglądamy je i usuwamy te, z których nikt już nie korzysta — bywa, że to połowa.

Pomiar zamiast wrażeń

Mierzymy czasy ładowania rzeczywistych stron produktów przed zmianami i po nich, a nie strony głównej. To ona jest zwykle najlepiej zoptymalizowana i najmniej odwiedzana.

Serwer

Wymianę na mocniejszy proponujemy jako ostatni krok, nie pierwszy — po wyczerpaniu zmian, które nic nie kosztują.

Wolny sklep nie zawsze działa wolno w ten sam sposób

Przed rozpoczęciem optymalizacji trzeba ustalić, gdzie dokładnie pojawia się opóźnienie. Czasem długo trwa oczekiwanie na pierwszą odpowiedź serwera, a po jej otrzymaniu strona wyświetla się sprawnie. W innym przypadku dokument strony zostaje pobrany szybko, lecz przeglądarka długo przetwarza arkusze stylów, skrypty i obrazy. Zdarza się również, że strona produktu wygląda na gotową, ale przyciski przez pewien czas nie reagują. Każdy z tych wariantów wskazuje na inną grupę przyczyn.

Osobno analizuje się spowolnienie występujące tylko w koszyku, podczas logowania albo na etapie składania zamówienia. Takie podstrony zwykle generują treść indywidualnie dla konkretnej sesji, czyli bieżącej wizyty użytkownika. Nie można więc obsługiwać ich dokładnie tak samo jak publicznej strony kategorii. Przyczyną może być integracja z płatnościami, przewoźnikiem, systemem magazynowym albo mechanizmem wyliczającym rabaty.

Istotne jest także rozróżnienie stałej niskiej wydajności od okresowych przeciążeń. Jeżeli sklep zwalnia wyłącznie podczas kampanii reklamowej, publikacji newslettera lub importu produktów, sprawdza się wykorzystanie zasobów właśnie w tym czasie. Test wykonany kilka godzin później może nie pokazać problemu. Dlatego diagnoza powinna uwzględniać zachowanie sklepu pod rzeczywistym obciążeniem, a nie tylko wynik pojedynczego pomiaru.

Strona produktu wymaga osobnej analizy

Strona produktu zwykle łączy wiele elementów: galerię zdjęć, warianty, stan magazynowy, opinie, produkty podobne oraz informacje o dostawie. Każdy element może wymagać dodatkowego zapytania do bazy danych albo uruchomienia kolejnego skryptu. Przy rozbudowanym katalogu nawet poprawnie działająca funkcja może stać się obciążeniem, jeżeli jest wykonywana wielokrotnie przy każdym otwarciu strony.

Sprawdzane jest, które dane muszą być pobierane na bieżąco, a które można przygotować wcześniej i przechować w pamięci podręcznej. Pamięć podręczna, nazywana także cache, przechowuje gotowy wynik wcześniejszych obliczeń. Dzięki temu serwer nie musi za każdym razem budować tej samej części strony od początku. Trzeba jednak prawidłowo określić zasady odświeżania, aby po zmianie ceny, dostępności albo opisu klient nie zobaczył nieaktualnych danych.

W galerii produktowej znaczenie ma nie tylko rozmiar plików. Przeglądarka nie powinna pobierać od razu wszystkich fotografii, jeżeli część z nich znajduje się poza widocznym obszarem. Pomaga w tym leniwe ładowanie, czyli pobieranie obrazu dopiero wtedy, gdy staje się potrzebny. Mechanizm powinien być jednak wdrożony ostrożnie. Główne zdjęcie produktu musi pojawić się bez zbędnego opóźnienia, ponieważ stanowi podstawową część widoku.

Baza danych i rozszerzenia sklepu

Rozszerzenie może być potrzebne biznesowo, a jednocześnie powodować niepotrzebne obciążenie. Sama liczba dodatków nie przesądza o szybkości sklepu. Ważniejsze jest to, jakie operacje wykonują, kiedy się uruchamiają i czy ich funkcje nie dublują się. Niewielki moduł może przy każdym wyświetleniu produktu wykonywać kosztowne wyszukiwanie, podczas gdy bardziej rozbudowane rozszerzenie pozostaje praktycznie niewidoczne dla wydajności.

Analiza bazy danych obejmuje zapytania, które trwają najdłużej albo są wykonywane niepotrzebnie wiele razy. Zapytanie to polecenie służące do odczytania lub zapisania informacji, na przykład ceny produktu czy zawartości koszyka. Indeks bazy danych działa podobnie do uporządkowanego spisu i pozwala szybciej odnaleźć właściwe rekordy. Brak odpowiedniego indeksu może zmuszać system do przeglądania dużej części tabeli przy każdym żądaniu.

Nie usuwa się jednak danych ani rozszerzeń tylko dlatego, że wydają się zbędne. Najpierw ustala się ich funkcję, zależności i wpływ na zamówienia. Zmiany testuje się w kopii środowiska, czyli wersji sklepu przeznaczonej do bezpiecznego sprawdzania modyfikacji. Pozwala to wykryć konflikt przed wdrożeniem go w działającym sklepie.

Błędy popełniane podczas samodzielnego przyspieszania

Częstym błędem jest jednoczesne włączenie kilku mechanizmów pamięci podręcznej. Każdy z nich próbuje wtedy zarządzać tymi samymi plikami lub fragmentami stron. Efektem może być nie tylko brak poprawy, lecz także wyświetlanie starych cen, problemy z koszykiem albo losowe błędy po aktualizacji. Przed włączeniem kolejnego rozwiązania warto ustalić, które warstwy cache już działają na poziomie sklepu, serwera i sieci dostarczania treści.

Ryzykowne jest również automatyczne łączenie wszystkich plików JavaScript, czyli kodu wykonywanego w przeglądarce. Kolejność uruchamiania skryptów może mieć znaczenie dla wyboru wariantu, dodawania produktu do koszyka i obsługi płatności. Wynik testu szybkości może się poprawić, ale podstawowe funkcje sprzedażowe przestaną działać. Po każdej zmianie trzeba więc przejść pełną ścieżkę zakupową, a nie ograniczać kontroli do wyglądu strony głównej.

Kolejny błąd polega na usuwaniu plików lub tabel bazy danych bez potwierdzenia, do czego służą. Pozostałości po dawnych dodatkach rzeczywiście mogą zajmować miejsce, ale podobna nazwa nie jest wystarczającą podstawą do skasowania danych. Przed porządkowaniem wykonuje się kopię zapasową i sprawdza możliwość jej odtworzenia. Kopia, której nie da się poprawnie przywrócić, nie stanowi skutecznego zabezpieczenia.

Nie należy też oceniać efektu wyłącznie na komputerze osoby administrującej sklepem. Przeglądarka może przechowywać wcześniej pobrane pliki, a szybkie łącze może ukrywać ciężkie obrazy. Testy powinny obejmować pierwsze wejście bez zapisanej pamięci podręcznej oraz kolejne przejścia między kategorią, produktem, koszykiem i formularzem zamówienia.

Kiedy problem nie wynika z wydajności sklepu

Wolne wyświetlanie może być skutkiem lokalnego połączenia internetowego, przeciążonej sieci bezprzewodowej albo rozszerzenia zainstalowanego w przeglądarce. Jeżeli problem występuje tylko na jednym komputerze lub w jednej sieci, najpierw porównuje się działanie na innym urządzeniu i innym połączeniu. Pozwala to uniknąć modyfikowania sklepu z powodu usterki znajdującej się po stronie stanowiska użytkownika.

Podobnym objawem może być awaria zewnętrznej usługi. Strona czeka wtedy na odpowiedź systemu płatności, modułu opinii, narzędzia analitycznego albo integracji magazynowej. Sam serwer sklepu może odpowiadać prawidłowo. W takim przypadku optymalizacja kodu nie rozwiąże źródła problemu. Potrzebne jest ograniczenie czasu oczekiwania, zmiana sposobu komunikacji lub takie zaprojektowanie funkcji, aby niedostępność dodatku nie blokowała całej strony.

Nie każda chwilowa przerwa oznacza też zbyt słaby serwer. Import dużego katalogu, tworzenie kopii zapasowej lub zadanie konserwacyjne może czasowo wykorzystać dostępne zasoby. Najpierw sprawdza się dzienniki systemowe, czyli zapisy zdarzeń i błędów, oraz harmonogram zadań wykonywanych automatycznie. Dopiero potem można wiarygodnie ocenić, czy potrzebna jest zmiana parametrów środowiska.

Jak bezpiecznie wprowadza się zmiany

Optymalizację dzieli się na małe etapy. Przed zmianą zapisywany jest wynik pomiaru i stan konfiguracji. Następnie wdrażana jest jedna grupa poprawek, po której ponownie sprawdza się strony produktów, kategorii, wyszukiwarkę, logowanie, koszyk i zamówienie. Taki sposób pozwala wskazać zmianę odpowiedzialną zarówno za poprawę, jak i za ewentualny błąd.

Oprócz szybkości kontroluje się poprawność danych oraz działanie procesów sprzedażowych. Skrócenie czasu generowania strony nie ma wartości, jeżeli klient nie może wybrać dostawy albo cena w koszyku różni się od ceny produktu. Ważne jest również zachowanie sklepu po aktualizacji platformy i rozszerzeń. Rozwiązanie oparte na przypadkowej modyfikacji plików może zostać nadpisane przy najbliższej aktualizacji.

Na końcu powstaje lista wykonanych zmian i elementów pozostawionych bez modyfikacji. Ułatwia to późniejszą administrację oraz ocenę nowych rozszerzeń. Gdy po pewnym czasie sklep ponownie zwolni, można porównać konfigurację z wcześniejszym stanem zamiast rozpoczynać analizę od początku.

Dodatkowe pytania dotyczące szybkości sklepu

Czy wysoki wynik automatycznego testu oznacza, że sklep jest już szybki?

Nie zawsze. Automatyczny test pomaga znaleźć problemy techniczne, ale nie zastępuje sprawdzenia prawdziwej ścieżki zakupowej. Strona może otrzymać korzystną ocenę, a mimo to długo wyszukiwać produkty albo czekać na przeliczenie koszyka. Wynik traktuje się jako część diagnozy, nie jako jedyny cel prac.

Czy każde rozszerzenie spowalnia sklep?

Każde rozszerzenie może wprowadzać dodatkowe operacje, lecz ich wpływ jest różny. Dobrze przygotowany moduł uruchamiany tylko tam, gdzie jest potrzebny, może mieć niewielkie znaczenie. Problemem są przede wszystkim dodatki wykonujące ciężkie operacje na każdej podstronie, dublujące funkcje lub wczytujące zasoby mimo braku widocznego elementu.

Czy sieć CDN rozwiąże problem z wolnym sklepem?

CDN, czyli rozproszona sieć serwerów dostarczających pliki użytkownikom, może przyspieszyć pobieranie zdjęć, arkuszy stylów i innych zasobów statycznych. Nie naprawi jednak powolnych zapytań do bazy, błędnego modułu koszyka ani oczekiwania na zewnętrzną integrację. Najpierw trzeba ustalić, która część procesu rzeczywiście powoduje opóźnienie.

Czy po optymalizacji trzeba nadal kontrolować wydajność?

Tak, ponieważ sklep zmienia się wraz z katalogiem, integracjami i aktualizacjami. Nowy szablon, moduł marketingowy lub sposób prezentacji zdjęć może ponownie zwiększyć obciążenie. Regularny pomiar tych samych typów podstron pozwala zauważyć pogorszenie, zanim zacznie ono wyraźnie utrudniać składanie zamówień.

Czy optymalizację można wykonywać podczas normalnej sprzedaży?

Część analizy można przeprowadzić bez zatrzymywania sklepu. Zmiany wpływające na bazę danych, mechanizm pamięci podręcznej lub proces zamówienia powinny jednak zostać wcześniej sprawdzone w środowisku testowym. Wdrożenie planuje się tak, aby możliwe było szybkie wycofanie modyfikacji, gdy pojawi się nieprzewidziana zależność.

Szybkość powinna wspierać zakup, a nie sam wynik testu

Dobrze przeprowadzona optymalizacja nie polega na mechanicznym usunięciu wszystkich dodatków ani na dążeniu do jednego wskaźnika. Jej celem jest sprawne przejście od listy produktów do potwierdzenia zamówienia, bez utraty potrzebnych funkcji i bez wyświetlania nieaktualnych danych. Najpierw lokalizuje się rzeczywiste źródło opóźnienia, następnie wprowadza mierzalne zmiany, a na końcu kontroluje cały proces sprzedażowy. Dzięki temu sklep staje się szybszy tam, gdzie ma to praktyczne znaczenie: przy wyborze produktu, pracy z koszykiem i finalizacji zakupu.