Panel klienta
Analiza szybkości

Audyt szybkości i Core Web Vitals

Mierzę, co realnie spowalnia Twoją stronę lub sklep - i nie tylko na stronie głównej, ale na kategorii, karcie produktu i checkoucie, czyli tam, gdzie klient podejmuje decyzję. Dostajesz listę konkretnych przyczyn i kolejność napraw.

Zamów audyt na WhatsApp Zobacz przykładowy raport →
Co sprawdzam

Zakres audytu

Core Web Vitals

LCP, INP i CLS na danych terenowych i w teście - co psuje wynik i dla kogo.

Hosting i konfiguracja

Czas odpowiedzi serwera, wersja PHP, cache po stronie serwera - fundament, którego nie zastąpi wtyczka.

Motyw i frontend

Ciężkie motywy, slidery, nadmiar CSS/JS, fonty i animacje, które nie pomagają sprzedaży.

Zdjęcia i multimedia

Rozmiary, formaty, kompresja, lazy loading z głową i obraz LCP.

Cache i baza danych

Warstwy cache bez mieszania danych klientów oraz porządek w bazie.

Skrypty i wtyczki

Co ładuje się niepotrzebnie na każdej podstronie i blokuje renderowanie.

Jak pracuję

Realna robota, nie raport z automatu

Wchodzę w kod, mierzę szybkość w DevTools, sprawdzam serwer po SSH i czytam dane z GA4. Tak wygląda audyt w praktyce.

Core Web Vitals - CrUX mobile p75 LCP p75 4,1 s INP p75 287 ms CLS p75 0,21 Udział wizyt z dobrym LCP (próg 2,5 s) Mob 4G Mob 3G Desktop Próg
Dane terenowe p75: tylko 34% wizyt mobilnych ładuje LCP w normie (Google liczy userów, nie Lighthouse)
waterfall-zasobow.har ZasóbRozmiarCzas / blokada hero.jpg (LCP) 1,8 MB 2,9 s pobieranie app.bundle.js 642 KB render-blocking main.css 318 KB render-blocking 6x fonty WOFF 410 KB FOIT 800 ms jquery + 4 wtyczki 290 KB parse 340 ms
Waterfall: element LCP to hero 1,8 MB, a 960 KB JS+CSS blokuje render
hosting-ttfb.txt 123467 $ curl -w TTFB -o /dev/null -s URLTTFB: 1,420s <- PHP renderuje za każdym razemServer: PHP 7.4 (EOL, brak OPcache)x-cache: MISS <- CF nie cache HTML--- po: PHP 8.3 + OPcache + cache ---TTFB: 0,180s (-1,24 s) /* TTFB 1,42 s zjada budżet LCP przed renderem */
Serwer oddaje pierwszy bajt po 1,42 s (PHP 7.4 bez cache) - PHP 8.3 + OPcache tną do ~0,18 s
Wycinek z raportu

Każdy problem z priorytetem, wpływem i rekomendacją

audyt-szybkosci.pdf - str. 12 / 30
  • P1
    Element LCP to hero 1,8 MB bez kompresji

    Największy obraz nad linią zgięcia ładuje się 2,9 s; WebP/AVIF + fetchpriority=high ścina LCP o ok. 2 s na mobile.

  • P1
    TTFB 1,42 s - PHP 7.4 (EOL) bez OPcache i cache HTML

    Serwer renderuje stronę od zera przy każdym wejściu; PHP 8.3 + OPcache + cache strony zbija TTFB do ~0,18 s.

  • P1
    960 KB JS+CSS blokuje render (render-blocking)

    app.bundle.js 642 KB i main.css 318 KB wstrzymują malowanie; defer, podział bundla i critical CSS odblokowują render o ~600 ms.

  • P2
    CLS 0,21 - skoki layoutu od obrazów i fontów bez wymiarów

    Brak width/height na obrazach i swap fontów przesuwa treść; rezerwacja miejsca i font-display:optional schodzi poniżej 0,1.

  • P2
    INP 287 ms - ciężki JS blokuje wątek główny

    jQuery + 4 wtyczki (290 KB) i długie zadania >200 ms opóźniają reakcję na klik; usunięcie nieużywanych skryptów zbija INP pod 200 ms.

Co dostajesz

Konkretny dokument, nie lista z narzędzia

Audyt robię ręcznie - narzędzie pokazuje objawy, ale nie powie, co realnie blokuje sprzedaż i od czego zacząć. Dostajesz dokument na około 30 stron: znalezione problemy z priorytetami (P1/P2/P3), wyjaśnienie dlaczego to ważne i konkretną kolejność napraw. Tak, żebyś wiedział, co zrobić najpierw, żeby najszybciej odzyskać ruch i pieniądze.

Zobacz pełny przykładowy raport Cennik audytów
Powiązane

Zobacz też

Optymalizacja i szybkość Czym są Core Web Vitals i jak je poprawić Co realnie skraca czas ładowania sklepu

Chcesz wiedzieć, co konkretnie poprawić u siebie?

Napisz na WhatsApp, czym się zajmujesz. Zacznę od ręcznego audytu (2500 zł) z listą priorytetów - bez obietnic, na konkretach.

Napisz na WhatsApp Formularz kontaktowy
WhatsApp