▸ // spis treści
Audyt wydajności strony zwykle wygląda tak: otwierasz DevTools, klikasz Lighthouse, czekasz, potem ręcznie grzebiesz w zakładce Network, sprawdzasz nagłówki cache, szukasz co blokuje render. Godzina klikania — a i tak połowę rzeczy przeoczysz.
Testowałem skilla performance-audit do Claude Code, który robi to wszystko jednym poleceniem. Agent sam steruje przeglądarką, zbiera trace, odpala Lighthouse, czyta nagłówki sieci i wypluwa raport z priorytetami. Sprawdziłem go na własnej stronie — damianslimak.pl. I znalazł błąd, którego sam bym nie zauważył, bo liczby i tak były zielone.
Z tego artykułu dowiesz się:
- co realnie robi skill performance-audit (i czego nie robi),
- jak go włączyć krok po kroku,
- jak działa jego workflow — od trace'u do gotowego raportu,
- jaki konkretny błąd wykrył na szybkiej, dobrze zoptymalizowanej stronie.
Czym jest performance-audit
To skill do Claude Code — gotowy zestaw instrukcji, który uczy agenta jednej konkretnej roboty. Ten robi audyt wydajności dowolnego URL-a. Stworzył go Krzysiek Radzikowski.
Pod spodem korzysta z serwera chrome-devtools-mcp — to most między Claude a prawdziwą przeglądarką Chrome. Agent nie zgaduje, tylko realnie odpala stronę, nagrywa performance trace i czyta te same dane, które widzisz w DevTools.
Efekt: zamiast klikać, piszesz "zrób audyt wydajności strony X" i dostajesz gotowy raport z listą napraw według ważności.
Jak go włączyć
Trzy rzeczy muszą być na miejscu.
1. Serwer chrome-devtools-mcp — rejestrujesz go w Claude Code:
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --isolated --headlessFlagi mają znaczenie:
- "--isolated" — świeży profil przeglądarki, żeby "zimny" load był naprawdę zimny (bez cache z poprzednich wizyt),
- "--headless" — bez otwierania okna,
- nigdy nie dawaj "--slim" — obcina narzędzia performance i network, na których cały skill stoi.
2. Gdzie zapisują się analizy — audyt zrzuca wszystko do folderu, który wskażesz: surowy trace, dane pomiarowe i gotowy raport w Markdown. Możesz z góry podać katalog na wyniki, więc pliki nie mieszają się z projektem — po robocie masz jedno miejsce z całą analizą.
3. Polecenie — piszesz zwyczajnie, po ludzku:
zrób audyt wydajności dla https://damianslimak.pl
Skill sam się uruchamia, bo jego opis łapie frazy typu "audyt wydajności", "Core Web Vitals", "Lighthouse", "sprawdź szybkość strony".
Jak to działa — krok po kroku
Skill prowadzi agenta przez ustalony workflow. To nie czarna skrzynka — każdy etap to konkretne narzędzie DevTools i konkretne dane.
W praktyce dla mojej strony agent:
- ustawił środowisko (desktop, a osobno mobile z throttlingiem),
- nagrał trace ładowania — stąd Core Web Vitals,
- odpalił Lighthouse na mobile,
- wstrzyknął skrypt zbierający szczegóły (rozmiary zasobów, DOM, higienę obrazów, fonty),
- rozbił LCP na fazy, żeby wiedzieć co konkretnie opóźnia pierwszy duży element,
- przeczytał nagłówki cache i protokół każdego requestu,
- zajrzał do konsoli po błędy,
- złożył z tego raport z listą napraw według ważności.
Całość — kilka minut, bez mojego klikania.
Co wyszło na damianslimak.pl
Najpierw twarde liczby z Lighthouse (wersja mobilna):
- SEO: 100/100 — pełny schema.org, poprawne meta, kanoniczne linki,
- Accessibility: 95/100 — prawie ideał, jeden realny błąd,
- Best Practices: 81/100 — obniżone przez rzeczy spoza mojego kodu.
Core Web Vitals z trace'u (laboratoryjnie):
- LCP: 178 ms (próg "dobry" to poniżej 2500 ms),
- CLS: 0,0035 (próg poniżej 0,1),
- TTFB: 1 ms, FCP: 180 ms.
Strona jest szybka, bo stoi na statycznym Astro, serwerze LiteSpeed z HTTP/3, kompresją Brotli i cache "immutable" na rok. Google Tag Manager jest zepchnięty do web workera przez Partytown, więc nie obciąża głównego wątku. Wzorcowa higiena.
I tu najciekawsza rzecz: skill sam znalazł jeden błąd sprzeczny z resztą.
Zdjęcie w hero (to z headshotem) jest największym elementem na ekranie — czyli element LCP. A ma ustawione "loading=lazy" i brak "fetchpriority=high". Mówiąc prościej: przeglądarka traktuje najważniejszy obraz strony jak coś, co może poczekać. To opóźnia jego wykrycie i załadowanie.
Rozbicie LCP na fazy pokazuje to czarno na białym:
Te 41 ms "Load Delay" to bezpośredni koszt "lazy" na obrazie, który wcale nie powinien być leniwy. Przy szybkim łączu to drobiazg — ale na wolniejszym mobilnym te milisekundy się mnożą.
Fix jest jednolinijkowy: dla obrazu LCP zmień "loading=lazy" na "loading=eager" i dodaj "fetchpriority=high". W Astro wystarczy oznaczyć obraz jako priorytetowy.
Drugi realny problem — dostępność. Mobilne menu ma atrybut "aria-hidden=true", ale w środku trzyma klikalne, fokusowalne linki. Dla czytnika ekranu to sprzeczność. Jeden atrybut "inert" na zamkniętym menu naprawia jednocześnie wynik Accessibility (95 na 100) i drzewo dostępności dla agentów AI.
Jak wygląda raport
Na końcu dostajesz gotowy plik Markdown — z metrykami, znaleziskami i planem napraw w podziale na priorytety. Poniżej dwa fragmenty wygenerowane przez skilla (wklejam surowo, tak jak wyszły).
Plan działania z priorytetami:
## Plan działania (priorytety)
**P0 — Krytyczne (w tym tygodniu)**
- Element LCP (ds_headshot.webp): usuń loading="lazy", dodaj
fetchpriority="high". Efekt: skrócenie Resource Load Delay (~41 ms),
stabilniejszy LCP na wolniejszych łączach mobilnych.
**P1 — Ważne (następny sprint)**
- Menu mobilne (aria-hidden="true") zawiera fokusowalne linki →
dodaj atrybut "inert". Naprawia Accessibility (95→100) i drzewo
dostępności dla agentów AI.
- CookieConsent.css jest render-blocking → kandydat do odroczenia.
**P2 — Nice to have (backlog)**
- 7 plików woff2 (~105 kB) w initial load — rozważ subset/redukcję wag.Werdykt końcowy w formie tabeli:
| Obszar | Ocena | Uwagi |
|-----------------|-------|----------------------------------------------|
| LCP | ✅ | 178 ms; fix: eager + fetchpriority na obrazie |
| CLS | ✅ | 0,0035 — tylko dekoracyjne mikro-przesunięcia |
| TTFB | ✅ | LiteSpeed, cache HTML + Brotli |
| Third-party | ✅ | GTM offloadowany przez Partytown — wzorcowo |
| Image delivery | ⚠️ | obraz LCP lazy + bez fetchpriority |
| Accessibility | ⚠️ | 95 — fokusowalne linki w ukrytym menu |Nie musisz nic interpretować z surowych danych — skill sam nazywa problem, podaje spodziewany efekt i konkretny fix.
Skill to nie wyrocznia
Ważne, żeby to jasno powiedzieć: ten skill jest bardzo dobry we wczesnej fazie audytu, ale nie zastępuje pełnego audytu, który wykona osoba techniczna. To wciąż tylko skill — potrafi coś przeoczyć, czegoś nie zrobić, nie jest wyrocznią. Za to techniczne rzeczy sprawdza rzetelnie i automatyzuje robotę, która wcześniej zajmowała po prostu dużo więcej czasu.
Do jednorazowego sprawdzenia albo szybkiego przeglądu — działa świetnie od ręki. Ale jeśli ktoś chciałby używać go na stałe, w pracy z klientami, zalecałbym dostosować go pod siebie i dorzucić kilka opcji, które realnie się przydają:
- Tryb "przed/po" — porównanie dwóch audytów tego samego URL-a (efekt wdrożonych napraw w liczbach),
- Batch — jedno polecenie, lista adresów, zbiorczy raport (całe menu albo mapa strony naraz),
- Własne progi — twoje thresholdy zamiast domyślnych Google (np. surowsze dla sklepu),
- Stały folder na raporty — z datą w nazwie, żeby budować historię wyników,
- Integracja z CI — audyt po każdym deployu i alert, gdy wynik spadnie.
Skill jest dobrą bazą. Traktuj go jak fundament, nie gotowca — i dopiero wtedy naprawdę zaczyna pracować za ciebie.
Efekt — dla kogo to jest
Więc co to realnie daje?
- Oszczędność czasu: to, co ręcznie zajmuje godzinę klikania po DevTools, agent robi w kilka minut i nic nie pomija.
- Priorytety, nie lista życzeń: raport nie mówi "masz 40 rzeczy do poprawy", tylko "napraw najpierw to jedno, bo daje największy efekt".
- Powtarzalność: ten sam audyt odpalisz na 10 podstronach albo na stronie klienta przed i po zmianach — zawsze według tej samej metody.
Komu się przyda: każdemu, kto ma stronę i nie chce zgadywać, gdzie leży problem. Freelancerowi robiącemu audyt dla klienta. Właścicielowi sklepu, który wie, że wolna strona to porzucone koszyki. Mnie — bo znalazł błąd, którego sam bym nie zauważył, skoro liczby i tak były zielone.
To jest dokładnie ten rodzaj roboty, o którym mówię od lat: nudną, powtarzalną, wymagającą skupienia czynność oddajesz robotowi. Ty patrzysz na wynik i podejmujesz decyzję.
Zatrudnij roboty, uwolnij ludzi.
P.S. Skill nie jest idealny — w dokumentacji miał kilka rozjazdów z realnym API narzędzia (inny format parametru ekranu, nieistniejąca opcja throttlingu, mylące info że Lighthouse zwraca też wynik Performance, którego akurat nie zwraca). Nic, co blokuje robotę, ale gdybym go wdrażał na stałe — najpierw bym te opisy poprawił. Uczciwie: testuję narzędzia zanim je polecę, i mówię też o rysach.