Darmowe & Open Source

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 »
CWV Superpowers diagnozujące Core Web Vitals za pomocą danych rzeczywistych użytkowników CoreDash

Trusted by market leaders · Client results

dpg mediaaleteiaadevintamonarchsnvhappyhorizonperionwhowhatwearerasmusmcworkivaebaysaturnmarktplaatsnina careloopearplugskpncomparemy work featured on web.devnestlefotocasaharvardvpn

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.

Dane monitorowania rzeczywistych użytkowników CoreDash napędzające diagnozę agenta AI

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.

Śledzenie z Chrome DevTools pokazujące kaskadę sieciową dla wąskiego gardła LCP

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.

Rozbicie na fazy pokazujące proporcjonalną identyfikację wąskiego gardła
Rzeczywisty przykład

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).


Raport wydajności HTML z CWV Superpowers
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

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.

Licencja MIT

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