Audyt wydajności i bezpieczeństwa
Audyt to przegląd kodu, bazy danych i konfiguracji serwera, który identyfikuje wąskie gardła spowalniające sklep oraz luki bezpieczeństwa, zanim staną się realnym problemem. W e-commerce każda sekunda ładowania przekłada się bezpośrednio na konwersję.
Core Web Vitals
Czas ładowania
Poniżej 1 sekundy
Dług technologiczny hamuje Twój biznes
Sklepy internetowe "puchną" z czasem. Instalowanie przypadkowych wtyczek, brak aktualizacji, ciężkie zdjęcia i błędy w kodzie sprawiają, że klienci uciekają do konkurencji, a Google obniża Twoje pozycje w wyszukiwarce. Audyt to też naturalny punkt startowy przed SLA - wiesz co obejmujesz opieką, zamiast kupować kota w worku.
Wyższe Pozycje SEO
Google oficjalnie promuje szybkie strony (Core Web Vitals). Optymalizacja kodu to najtańszy sposób na poprawę widoczności organicznej.
Większa Konwersja
Amazon wyliczył, że każde 100ms opóźnienia to spadek sprzedaży o 1%. Szybki sklep buduje zaufanie i zachęca do zakupów.
Bezpieczeństwo Danych
Stare wersje PrestaShop, luki w modułach i błędy w PHP to otwarte drzwi dla hakerów. Audyt pozwala wykryć i załatać dziury, zanim będzie za późno.
Audyt ma sens, jeśli...
Sklep ładuje się ponad 3 sekundy
Google PageSpeed poniżej 50, klienci odchodzą zanim strona się załaduje, a kampanie Ads nie zwracają się tak jak powinny.
Nie wiesz co siedzi w Twoim kodzie
Sklep był robiony przez poprzednią agencję lub kilku programistów. Nikt nie wie dlaczego coś działa tak jak działa.
Planujesz kampanię lub sezon
Black Friday, wyprzedaż kolekcji, duży budżet na reklamy. Nie chcesz stracić ruchu przez wolny sklep lub awarię serwera pod obciążeniem.
Chcesz podpisać SLA, ale najpierw sprawdzić stan
Audyt to naturalny punkt startowy przed opieką miesięczną. Wiesz co obejmujesz, zamiast kupować kota w worku.
Miałeś włamanie lub podejrzane zdarzenia
Klienci zgłaszają problemy z płatnościami, Google ostrzega przed stroną, hosting zablokował konto. Audyt bezpieczeństwa wyjaśni co i dlaczego.
Zakres prac optymalizacyjnych
Optymalizacja Backend i Bazy Danych
Problem wolnego sklepu rzadko leży w "dużych zdjęciach". Częściej to wolne zapytania SQL i brak cache. Wchodzę głęboko w kod i serwer.
- Optymalizacja zapytań MySQL (indeksowanie)
- Wdrożenie Cache serwerowego (Redis / Varnish)
- Aktualizacja wersji PHP (np. z 7.4 na 8.2)
- Czyszczenie bazy ze śmieci (logi, statystyki)
$ mysql-slow-query-log analyze
! Found query taking 4.5s (join on `ps_orders`)
$ optimizing table indexes...
✓ Query time reduced to 0.02s
$ service redis-server start
✓ Cache Hit Rate: 95%
Lżejszy Frontend
Mniej skryptów, szybsze ładowanie.
Core Web Vitals (Frontend)
Poprawiam wyniki w Google PageSpeed Insights. Sprawiam, że strona ładuje się błyskawicznie na telefonach, co jest kluczowe dla współczesnego klienta.
- Konwersja formatów zdjęć do WebP / AVIF
- Minifikacja plików CSS i JavaScript
- Lazy Loading (ładowanie zdjęć przy przewijaniu)
- Usunięcie nieużywanych modułów i skryptów
Code Review i Refaktoryzacja
Twój sklep był robiony przez kilku programistów i nikt nie wie, jak działa? Wykonuję audyt jakości kodu. Usuwam "spaghetti code", poprawiam luki bezpieczeństwa i przygotowuję system do dalszego rozwoju.
Dlaczego to ważne?
Zły kod utrudnia wdrażanie nowych funkcji. Naprawa długu technologicznego sprawia, że przyszłe zmiany będą tańsze i szybsze.
Maintainability Index: A
Co dostajesz w raporcie?
Każde znalezisko ma priorytet, opis przyczyny i konkretną rekomendację. Bez żargonu - wiesz co naprawić i dlaczego.
Ładuje zewnętrzną czcionkę Google Fonts na każdej podstronie
Dlaczego spowalnia: Dodatkowe zapytanie DNS do googleapis.com blokuje renderowanie strony i dodaje ~160ms do TTFB.
Rekomendacja: Self-host czcionki lokalnie + preconnect hint w <head>.
N+1 zapytań SQL na stronie potwierdzenia zamówienia
Dlaczego spowalnia: Każdy produkt w zamówieniu generuje osobne SELECT. Przy 15 produktach = 15 zapytań zamiast 1. Mierzalny czas: +2.1s.
Rekomendacja: Przepisanie na jedno zapytanie z JOIN lub cache'owanie wyniku w Smarty.
3 banery w formacie JPEG, łącznie 2.4 MB bez kompresji
Dlaczego spowalnia: Czas transferu na mobilnym 4G: ~3.8s. Blokuje LCP (Largest Contentful Paint), core metric Google.
Rekomendacja: Konwersja do WebP (oszczędność ~75%), dodanie atrybutu loading="lazy" na slide 2 i 3.
CSS i JS ładowane globalnie, mimo że widoczny tylko na karcie produktu
Dlaczego spowalnia: Zbędne 28 KB na każdej innej podstronie (home, kategoria, checkout).
Rekomendacja: Warunkowe ładowanie tylko na hookach product page. Oszczędność: ~28 KB / podstronę.
Jak przeprowadzam audyt?
Dostęp i Analiza
Nadaję uprawnienia do kodu i serwera. Tworzę kopię sklepu (Staging), aby nie pracować na żywym organizmie.
Raport Błędów
Otrzymujesz dokument z listą problemów, ich priorytetem (Krytyczne/Zalecane) i estymacją czasu naprawy.
Wdrożenie Poprawek
Po akceptacji wdrażam optymalizacje. Czyszczę bazę danych, konfiguruję cache i refaktoryzuję kod.
Weryfikacja
Zestawiam dla Ciebie wyniki "Przed" i "Po". Weryfikuję realne czasy ładowania oraz nowe wyniki w Google PageSpeed.
TTFB z 2,5s do 0,3s. Bez zmiany serwera.
Sklep PrestaShop, typowe środowisko shared hostingu, żadnych zmian sprzętowych. Trzy miejsca w kodzie: sitemap generowana w czasie rzeczywistym, problem N+1 w zapytaniach SQL i 8 000 kategorii ładowanych do widżetu UI. Po naprawie każdego z nich - czas do pierwszego bajtu spadł o ponad 88%.
Czytaj pełny opis na blogu
Szczegóły techniczne i dyskusja również na LinkedIn.
TTFB przed i po
2,5s
przed
0,3s
po
TTFB · bez zmiany serwera
Co dalej po audycie?
Dług technologiczny wymaga przebudowy? Sprawdź wdrożenia. Kod jest stabilny? Naturalnym krokiem jest stała opieka SLA z gwarantowanymi czasami reakcji.
Pytania i odpowiedzi (Audyt)
Czy optymalizacja może zepsuć sklep?
Nie, ponieważ wszystkie prace wykonuję najpierw na kopii testowej (środowisko Staging). Dopiero po przetestowaniu zmian wdrażam je na sklep produkcyjny.
O ile przyspieszy mój sklep?
To zależy od stanu wyjściowego. W jednym z udokumentowanych przypadków TTFB spadł z 2,5s do 0,3s (ponad 88%) wyłącznie przez naprawę trzech miejsc w kodzie, bez zmiany serwera. Skala poprawy jest inna dla każdego sklepu, ale każdy audyt kończy się zestawieniem wyników przed i po.
Czy audyt obejmuje też bezpieczeństwo?
Tak. Sprawdzam wersję PHP, zainstalowane moduły pod kątem znanych podatności CVE (baza Friends of Presta i NVD/NIST), konfigurację SSL, tryb debug oraz domyślny adres panelu admina. Jeśli podejrzewasz włamanie lub infekcję malware, oddzielnie realizuję usługę odwirusowania.
Jak długo trwa audyt?
Sam raport przygotowuję zazwyczaj w ciągu 2-3 dni roboczych od otrzymania dostępów. Czas wdrożenia poprawek zależy od liczby wykrytych problemów i ich złożoności.
Czy muszę od razu naprawić wszystkie wykryte problemy?
Nie. Raport zawiera priorytety: Krytyczne, Zalecane i Optymalizacja. Możesz zdecydować, że na start wdrażamy tylko elementy krytyczne, a resztą zajmiemy się w kolejnym kroku lub w ramach stałej opieki SLA.
Czym różni się jednorazowy audyt od stałej opieki SLA?
Audyt to zdjęcie RTG: diagnozuję aktualny stan sklepu i dostarczam raport z listą problemów do naprawy. SLA to ubezpieczenie na bieżąco: monitoring, backupy, gwarantowany czas reakcji na awarie i cykliczne aktualizacje. Wiele firm zaczyna od audytu, a następnie przechodzi na SLA po ustabilizowaniu środowiska.