Twój agent AI właśnie zyskał supermoce Core Web Vitals
Połącz Claude Code z danymi polowymi CoreDash. Znajduje on najgorsze wąskie gardło wśród milionów ładowań stron, śledzi główną przyczynę w przeglądarce Chrome i pisze poprawkę. Nie raport. Konkretną linię kodu, która wymaga zmiany.
Zainstaluj w 2 minuty Rozpocznij darmowy okres próbny CoreDash »
Narzędzia AI do wydajności mają problem z danymi
Większość agentów AI optymalizuje pod kątem Lighthouse. Syntetycznego wyniku na symulowanym urządzeniu, którego Google nie używa do rankingów. Twoi rzeczywiści użytkownicy korzystają z budżetowych telefonów, niestabilnych połączeń i na kontynentach, których Twoja maszyna deweloperska nigdy nie widziała.
Lighthouse to nie Twój sygnał rankingowy
Google opiera ranking na danych polowych CrUX od rzeczywistych użytkowników Chrome z 28 dni. Idealny wynik Lighthouse i oblewający wynik polowy zdarzają się cały czas. 52% stron mobilnych nie zalicza co najmniej jednego Core Web Vitals w danych polowych.
Ślepi agenci wprowadzają ślepe poprawki
Bez danych rzeczywistych użytkowników, agent AI nie wie, która strona jest wolna, który element jest wąskim gardłem, ani czy jego poprawka pomogła. Optymalizuje symulację i na tym kończy. Twoi faktyczni użytkownicy mają inne zdanie.
Ręczne dochodzenie zajmuje godziny
Segmentacja danych. Stawianie hipotez. Uruchomienie śledzenia (trace). Potwierdzenie. Przygotowanie poprawki. Doświadczony inżynier wydajności (senior performance engineer) spędza od 2 do 4 godzin nad jednym problemem. Pomnóż to przez każdą wolną stronę w Twojej witrynie.
Dwa źródła prawdy: Dane polowe spotykają się z dowodami z przeglądarki
CWV Superpowers łączy dane rzeczywistych użytkowników CoreDash z ukierunkowanymi śladami (traces) z Chrome. Dane polowe mówią co działa wolno. Chrome mówi dlaczego.
CoreDash mówi agentowi, co działa wolno
CoreDash śledzi każde załadowanie strony od każdego rzeczywistego użytkownika. Każda metryka przypisana jest do konkretnego elementu powodującego problem. Bez próbkowania, bez limitów.
Gdy CoreDash zgłasza LCP na poziomie 4,2 sekundy z opóźnieniem ładowania (Load Delay) pochłaniającym 52% całkowitego czasu na div.hero > img.main, agent wie dokładnie, gdzie szukać. To nie są zgadywanki. To pomiar z milionów rzeczywistych sesji.
Umiejętność ta odpytuje ponad 25 wymiarów CoreDash: element LCP, typ elementu, stan priorytetu, rozkład faz, cel interakcji INP, skrypty LOAF, przesuwający się element CLS, typ urządzenia, typ odwiedzającego, prędkość sieci, trendy z 7 dni.
Chrome mówi agentowi, dlaczego działa wolno
CWV Superpowers odwiedza stronę z emulacją mobilną: Fast 3G, 4-krotne dławienie CPU (throttling). Śledzi tylko fazę wąskiego gardła, którą zidentyfikował CoreDash.
Opóźnienie ładowania (Load Delay) to wąskie gardło? Agent bada kaskadę sieciową (network waterfall) pod kątem luk w odkrywaniu zasobów. Opóźnienie renderowania (Render Delay)? Szuka blokujących skryptów i opóźnień w ładowaniu fontów.
Rezultat: zrzuty ekranu w formie taśmy filmowej (filmstrip), kaskada sieciowa (network waterfall) i ukierunkowane dowody, które wyjaśniają główną przyczynę ujawnioną przez Twoje dane polowe.
Rozumowanie proporcjonalne, a nie wartości bezwzględne
Lighthouse mówi, że "Opóźnienie renderowania (Render Delay) wynosi 350ms". Czy to jest problem? Nie wiadomo. CWV Superpowers identyfikuje wąskie gardło jako fazę pochłaniającą największy procent całkowitego czasu.
INP wynosi 350ms. Input Delay 70ms (20%), Processing 80ms (23%), Presentation 200ms (57%). Presentation to wąskie gardło, nawet jeśli 200ms brzmi dobrze w izolacji. Naprawienie tego przynosi efekty. Optymalizacja Input Delay będzie ledwo zauważalna.
Zapobiega to najczęstszemu błędowi w pracy nad wydajnością: naprawianiu niewłaściwych rzeczy.

Pięć kroków: Od "coś działa wolno" do poprawki w kodzie
Zadaj mu pytanie. Pięć kroków później masz poprawkę popartą dowodami od rzeczywistych użytkowników.
1. Odkrywanie
Skanuje Twoje dane CoreDash w poszukiwaniu najgorszych stron i metryk. Priorytetyzuje słabe oceny, ruch mobilny, strony o dużym natężeniu ruchu oraz wyniki p75, które ukrywają długi ogon słabych rezultatów.
2. Diagnoza
Rozbija metrykę na fazy. LCP: TTFB, Load Delay, Load Time, Render Delay. INP: Input Delay, Processing, Presentation. Nazywa wąskie gardło na podstawie wartości procentowych.
3. Śledzenie w Chrome (Trace)
Odwiedza stronę z emulacją mobilną. Śledzi tylko fazę wąskiego gardła z kroku 2. Przechwytuje kaskadę sieciową (network waterfall), zrzuty ekranu (filmstrip) oraz dowody na zasoby blokujące renderowanie.
4. Główna przyczyna (Root Cause)
Łączy oba źródła dowodów w jedno stwierdzenie: element, przyczynę, metryki CoreDash oraz to, co potwierdził Chrome. Bez niedomówień.
5. Poprawka lub raport
Twój wybór. Zastosuj poprawkę w kodzie z plikiem, linią, elementem, przed/po. Wygeneruj samodzielny raport HTML z wykresami i dowodami. Lub jedno i drugie.

Diagnoza: Rozbicie na fazy dla każdego Core Web Vitals
Nie tylko wyniki. Każda metryka rozbita na fazy przy użyciu przypisania dla rzeczywistych użytkowników z CoreDash.
LCP: Largest Contentful Paint
Rozbicie na 4 fazy: TTFB, Load Delay, Load Time, Render Delay. Identyfikuje, która faza pochłania największą część całkowitego czasu.
Przypisanie elementu: dokładny element LCP, jego typ (obraz, tekst, obraz tła, wideo) i stan priorytetu (fetchpriority, lazy loading).
Typowe poprawki: dodanie wskazówki preload, usunięcie lazy loading z sekcji hero, optymalizacja formatu obrazu, naprawa skryptu blokującego renderowanie.
INP: Interaction to Next Paint
Rozbicie na 3 fazy: Input Delay, Processing, Presentation. Jedyna metryka, której nie można symulować w laboratorium. Dane polowe są jedynym źródłem.
Przypisanie skryptu: Long Animation Frames (LOAF) wskazuje dokładny plik JavaScript i czas trwania. Do tego stan załadowania strony, gdy nastąpiła interakcja.
Typowe poprawki: yield do głównego wątku (main thread), odroczenie ewaluacji, podzielenie event handlerów, content-visibility dla dużych drzew DOM.
CLS: Cumulative Layout Shift
5 wzorców przyczyn: obrazy bez wymiarów, podmiana fontów (font swaps), dynamicznie wstrzykiwana treść, późno ładujące się zasoby, animacje CSS na właściwościach układu.
Wielowymiarowość: porównuje mobile z desktop, nowych z powracającymi użytkownikami, szybkie z wolnymi sieciami, aby zawęzić przyczynę.
Typowe poprawki: dodanie width/height, font-display: optional, rezerwacja min-height, użycie transform zamiast top/left.

Jak wygląda oświadczenie o głównej przyczynie (Root Cause)
Nie brzmi to "rozważ optymalizację swoich obrazów". To jest rzeczywisty wynik. Wystarczająco szczegółowy, aby go przejrzeć i scalić (merge).
Główna przyczyna:
Obraz LCP div.hero-banner > img.product-main na /product/running-shoes-42 został odkryty o 1 980 ms za późno, ponieważ brakuje w nim wskazówki preload i nie ma fetchpriority="high".
Dowody z CoreDash:
LCP wynosi 3 820 ms (słabo) na urządzeniach mobilnych, w p75. Load Delay to wąskie gardło wynoszące 1 980 ms (52% całości). Stan priorytetu: 3 (brak preloada). Trend: pogorszenie o +340 ms w ciągu 7 dni.
Dowody z Chrome:
Kaskada sieciowa (network waterfall) pokazuje lukę 1 940 ms między pierwszym bajtem HTML a żądaniem obrazu. Obraz jest odwoływany tylko w CSS, niewidoczny dla skanera preload.
Poprawka:
Dodaj <link rel="preload" href="/images/hero.jpg" as="image" fetchpriority="high"> do templates/product.html w linii 12. Ustaw fetchpriority="high" na elemencie img w linii 47.
Standardowa porada AI:
"Rozważ dodanie fetchpriority do obrazu LCP i zapewnij odpowiedni preload krytycznych zasobów."
CWV Superpowers:
Element: div.hero-banner > img.product-main
Plik: templates/product.html, linia 47
Dowody: 52% czasu LCP przypada na Load Delay (CoreDash p75). 1 940 ms luki w odkrywaniu zasobu (kaskada Chrome).
Poprawka: Zmiana 2 linii kodu z podglądem różnic przed/po (diff).
Raporty: Wrzuć je na Slacka, załącz do Jiry
Samodzielny plik HTML. Brak zależności. Bez etapu budowania. Jeden plik ze wszystkim wewnątrz (inline).

Pełny raport (z Chrome)
Kodowane kolorami karty metryk, wykresy podziału na fazy, zrzuty ekranu filmstrip w kluczowych momentach (first paint, LCP, loaded), kaskada sieciowa w SVG, analiza głównej przyczyny (root cause) oraz zalecana poprawka z kodem przed/po.
Raport tylko z danych RUM
Te same karty metryk i podział na fazy, plus przypisanie elementów i analiza głównej przyczyny. Brak filmstrip i kaskady (waterfall), ale jakość diagnozy jest identyczna, ponieważ dane polowe są źródłem prawdy.
Współpracuje z każdym klientem MCP
Claude Code: Pełna umiejętność ze zautomatyzowanym przepływem pracy (workflow). Odkrywanie, diagnoza, śledzenie z Chrome (tracing), poprawki w kodzie i raporty. Zalecane.
Cursor: Instalacja wtyczki z CoreDash MCP. Pełna diagnoza i poprawki w kodzie bezpośrednio w Twoim edytorze.
VS Code, Windsurf, Gemini CLI: Każdy klient obsługujący serwery HTTP MCP może połączyć się z CoreDash. Te same dane polowe, takie samo przypisywanie.
Client Success
Don't just take my word for it
Head of Platform, Adevinta
45% reduction in blocking time across 15 marketplaces. INP from 440ms to 64ms on Fotocasa alone. Google wrote up the results on web.dev.
Head of Engineering, Swift
"Layout shift on checkout eliminated entirely. Went from 0.4 to 0.02 CLS across mobile and desktop."
VP Product, Expedia Group
"We had 80+ third-party scripts and were failing CWV on every major property. Arjen got us passing without touching our ad revenue."
Head of Digital, Rituals
"We used to break performance every other sprint. He set up budgets in our pipeline. Haven't had a regression since."
Lead Developer, Alza
"Transferred knowledge to our engineering team. We can now diagnose and resolve performance issues independently."
VP Engineering, People Inc
"Seven brands, seven different stacks. Every single one got faster. No compromises on what makes each property unique."
Product Lead, Miro
"Our dashboards were choking on main-thread work. 25% reduction in CPU usage. Users noticed immediately."
Engineering Manager, Zalando
"Every other audit we've had gave us a list of problems. This one told us exactly what to fix first and why."
CTO, DPG Media
"He found bottlenecks in our component library that we'd missed for two years. Performance gains were visible within days."
VP Engineering, Loop
"Mobile load time down 800ms. 7% lift in checkout conversion. The ROI justified the investment immediately."
Działa w 2 minuty
Potrzebujesz konta CoreDash, do którego napływają dane. Darmowy plan (free tier) w zupełności wystarczy.
Claude Code
claude mcp add --transport http coredash \
https://app.coredash.app/api/mcp \
--header "Authorization: Bearer cdk_YOUR_API_KEY"
/install corewebvitals/cwv-superpowers
claude --chrome
Znajdź mój największy problem z CWV i go napraw. Pobierz swój klucz API z CoreDash → Project Settings → API Keys (MCP). Wyświetlany tylko raz. Przechowywany jako hash SHA-256. Tylko do odczytu (Read-only).
Cursor
/plugin-add cwv-superpowers
Dodaj CoreDash do .cursor/mcp.json:
{
"mcpServers": {
"coredash": {
"url": "https://app.coredash.app/api/mcp",
"headers": {
"Authorization": "Bearer cdk_YOUR_API_KEY"
}
}
}
} Inni klienci MCP
Endpoint: https://app.coredash.app/api/mcp
Nagłówek (Header): Authorization: Bearer cdk_YOUR_API_KEY
Działa z VS Code (tryb Copilot agent), Windsurf, Gemini CLI, Claude Desktop i każdym klientem HTTP MCP.
Open Source. Brak lock-in.
Orkiestrator, moduły diagnostyczne, logika śledzenia w Chrome i szablony raportów. Wszystko na GitHubie. Przeczytaj, jak to działa. Zrób forka. Rozszerzaj. Kontrybuuj.
Przestań zgadywać. Zacznij diagnozować.
Dochodzenie, które zajmuje doświadczonemu inżynierowi wydajności (senior performance engineer) od 2 do 4 godzin, teraz odbywa się w trakcie konwersacji. Agent odwala czarną robotę. Ty robisz przegląd i scalasz (merge).
Rozpocznij darmowy okres próbny Zobacz na GitHubie