Audyt wydajności sklepu B2B - checklista i proces

Etap 1 - Lab data

Synthetic testing - kontrolowane środowisko, powtarzalne.

Narzędzia:

• Google PageSpeed Insights - najprostsze, Lighthouse + CrUX, mobile + desktop
• Lighthouse DevTools - szczegółowo, możliwość zmiany throttling
• WebPageTest.org - najwięcej szczegółów (waterfall, comparison, multi-location)

Test set:

• Homepage
• Top 3 kategorie (z PLP)
• Top 5 PDP (mix popularnych)
• Checkout (jeśli można symulować bez zamówienia)
• Strona logowania
• Search results page

Każdy URL × mobile + desktop × throttled (Slow 4G) + bez throttle = ~40-60 testów.

Co zbierać:

• Core Web Vitals (LCP, INP, CLS)
• Total Blocking Time (TBT)
• Speed Index
• Lista issues z Lighthouse (audits failed)
• WebPageTest waterfall (co konkretnie się ładuje wolno)

Etap 2 - Field data

Real user data z Chrome User Experience Report (CrUX) i Real User Monitoring.

Google Search Console:

• Core Web Vitals report
• Segmenty by URL pattern (PLP vs. PDP vs. Other)
• Mobile vs. desktop
• 28-dniowe okno

PageSpeed Insights - CrUX section. Real user metrics dla konkretnego URL. Lepsze niż Lighthouse (real users na real urządzeniach).

Real User Monitoring (RUM):

• Cloudflare Browser Insights (jeśli używasz CF)
• Datadog RUM
• Sentry Performance
• Custom: web-vitals.js (5 KB lib od Google)

Co sprawdzić:

• LCP / INP / CLS distribution (median, p75, p95, p99)
• Per device type (mobile / desktop / tablet)
• Per network (4G, 3G, slow)
• Per geographic region
• Per logged-in status (jeśli mierzysz)
• Per page type

Klucz: porównaj lab vs. field. Lighthouse 90/100, ale CrUX czerwony = problem dla real users (starsze urządzenia, słabsze sieci).

Etap 3 - Server-side profiling

Frontend nie jest jedynym źródłem latencji. Backend zazwyczaj największym.

Narzędzia APM:

• New Relic APM - kompleksowe, drogie
• Datadog APM - średnio droższe
• Tideways - dedykowane dla PHP, używane głównie w Magento/Shopware
• Blackfire - profiler PHP, gdy potrzebujesz wejść głębiej w wąskie gardło
• Sentry Performance - tańszy, integruje z error tracking

Co mierzyć:

• Average response time per route
• p95 / p99 response time
• Slowest endpoints
• DB query time per request
• External calls (ERP, cache, search)
• Memory usage
• CPU usage

MySQL slow query log:

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = ON;

Analiza po godzinie / dniu (mysqldumpslow, pt-query-digest):

• Top 10 najwolniejszych queries
• Top 10 najczęstszych queries
• Queries bez indeksów
• Queries z full table scan

Cache hit ratios:

• Redis: INFO memory, własne metryki per klucz
• Varnish: varnishstat (cache_hit, cache_miss)
• CDN: dashboard providera

Integracje:

• Czas wywołań do ERP (per endpoint)
• Hit ratio cache (Redis)
• Latency per integration call
• Error rate per integration

Etap 4 - Architektura

Audyt architektoniczny - co da się poprawić strukturalnie.

Checklist:

Hosting:

• Specyfikacja serwera (CPU, RAM, disk)
• Czy disk to NVMe (krytyczne dla DB)
• Czy hosting bare-metal / VPS / cloud
• Czy są wąskie gardła (CPU/IO/network bound)

Cache layers:

• Czy jest Varnish (lub odpowiednik)
• Czy jest Redis i osobne instance per użycie
• Czy używany CDN
• Hit ratio per warstwa

Search:

• Magento: Elasticsearch / OpenSearch wersja, konfiguracja
• Czy używany dla wszystkich PLP
• Reindex strategy

Database:

• MySQL config (innodb_buffer_pool_size, max_connections)
• Czy są read replicas
• Indeksy na często queryowanych kolumnach

Code quality:

• Czy są deweloperzy code review
• Czy CI/CD ma performance gates
• Liczba third-party modułów (im więcej, tym więcej ryzyk)

Etap 5 - Synteza i priorytetyzacja

Z czterech etapów masz listę 50-100 znalezisk. Priorytetyzacja:

Impact/Effort matrix:

	Niski effort	Średni effort	Wysoki effort
Wysoki impact	DO NATYCHMIAST	DO TEGO KWARTAŁU	ROADMAP
Średni impact	QUICK WIN	DO TEGO KWARTAŁU	RAPORT
Niski impact	NICE TO HAVE	RAPORT	NIE ROBIMY

Przykład działań po macierzy:

Wysoki impact / niski effort (zrób od razu):

• Włącz Varnish (już jest infrastruktura)
• Dodaj fetchpriority="high" na LCP images
• Skróć TTL nie-krytycznych statyków

Wysoki impact / średni effort:

• Migracja MySQL search → Elasticsearch
• Hyvä Theme zamiast klasycznego frontend Magento
• Image optimization on CDN

Wysoki impact / wysoki effort:

• Headless commerce
• Microservices
• Migracja platform

Niski impact / niski effort:

• Drobne tweaki CSS, minor optimization
• Cleanup nieużywanych modułów

Niski impact / wysoki effort:

• Robisz tylko jeśli jest specyficzne uzasadnienie

Deliverable - raport audytu

Co dajesz klientowi po audycie:

1. Executive summary (1-2 strony).

• Aktualny stan (CWV, response times, główne problemy)
• Top 5 najmocniejszych działań
• Oczekiwany ROI

2. Detail findings (10-30 stron).

• Per area: lab data, field data, server-side, screenshoty
• Per finding: opis, impact, rekomendacja, effort estimate

3. Action plan (1-2 strony).

• Lista akcji z priorytetami
• Timeline (Q1, Q2, Q3...)
• Owners (kto za co)
• Monitoring po wdrożeniu

4. Performance budget.

• Targety LCP / INP / CLS per page type
• JS / CSS bundle size limits
• Total page weight

5. Monitoring plan.

• Co mierzyć (które tools, jakie metryki)
• Cadence (codziennie / tygodniowo / kwartalnie)
• Alerts (kto dostaje, na co reaguje)

Pułapki audytu

1. Tylko Lighthouse. Nie wystarczy. Lab vs. field divergence częsta.

2. Audyt tylko homepage. 5% ruchu vs. PLP/PDP (90% ruchu).

3. Audyt tylko dla niezalogowanych. B2B 80% czasu zalogowany.

4. Brak server-side analysis. Frontend audit pokazuje połowę obrazu.

5. Brak priorytetyzacji. Lista 50 rzeczy bez priorytetów = klient nic nie zrobi.

6. Brak follow-up. Audyt → raport → nic. Bez follow-up i monitorowania regresji wyniki znikną.

7. Audyt bez baseline. Bez „pomiar przed" nie wiesz „o ile poprawione".

Kto powinien robić audyt

Sklep własny:

• Dział IT / DevOps może zrobić audyt techniczny
• Brakuje często perspektywy „best practice z innych sklepów"
• Często audyt wewnętrzny jest emocjonalny („nasz kod jest dobry")

Konsultant zewnętrzny:

• Większa obiektywność
• Doświadczenie z innych projektów
• Koszt: 30-80 tys. zł za pełny audyt średniego sklepu
• Czas: 2-4 tygodnie

Hybryda:

• Konsultant prowadzi proces, robi analizę
• Zespół klienta dostarcza dane (logi, dostępy, konteksty)
• Najlepszy mix

FAQ

Ile kosztuje audyt wydajności sklepu B2B? 30-100 tys. zł zależnie od scope. Mniejszy sklep + tylko frontend audit: 20-40 tys. Pełny (front + back + arch): 50-100 tys. Czas: 2-4 tygodnie.

Czy audyt opłaca się dla małego sklepu? Dla małego (do 1 M zł obrotu) - często DIY z Lighthouse + community knowledge wystarcza. Dla średniego (5+ M zł) - audyt zewnętrzny opłaca się typowo (znalezienie nawet jednej zmiany dającej 10% conversion = ROI ×10).

Jak często powtarzać audyt? Pełny audyt: raz w roku. Mini-audyt (Lighthouse na 10 stron + Search Console): kwartalnie. Continuous monitoring: codziennie.

Czy audyt Lighthouse jest darmowy? Tak, PageSpeed Insights i Lighthouse DevTools darmowe. Ale nie zastąpią pełnego audytu.

Czy audyt obejmuje sugestie biznesowe? Powinien. Wydajność to nie tylko technika - czasem decyzja to „odpuszczamy moduł X bo dorzuca 800 ms, marketing nie ma ROI".

Co dalej

• Narzędzia, których realnie używam: Lista
• Core Web Vitals: Core Web Vitals
• Cache strategie: Cache strategie
• Pillar wydajności: Wydajność e-commerce