Audytowałem ostatnio performance trzech platform ecommerce. Takich z koszykiem, wariantami produktu i krokiem płatności, gdzie wolna strona to utracony przychód. Potem zdestylowałem metodę w tool, odpaliłem najpierw na własnym portfolio i dostałem C.
Spojrzałem na zmierzone Core Web Vitals. Wszystkie zielone. LCP 991 ms. CLS zero. TTFB 42 ms. No to jak - wolno czy szybko?
Ta sprzeczność to cały powód, dla którego ten tool pokazuje dwie liczby tam, gdzie większość narzędzi pokazuje jedną.
Setup
Cel to portfolio.sdet.it. Strona tak chuda, jak się da: statyczne Astro, 3.3 KB JavaScriptu, 21.7 KB całości, sześć requestów. Zero runtime frameworka w przeglądarce. Zero hydration. Nic wymyślnego.
Tool to sdet-perf-toolkit v0.1 - audyt frontend performance, który najpierw mierzy w prawdziwej przeglądarce, a dopiero potem pozwala AI interpretować pomiar. Odpala Lighthouse pięć razy w headless Chrome i bierze medianę, wstrzykuje web-vitals przez Playwright, czyta resource trace, parsuje bundle. Zmierzony floor jest pierwszy. AI nigdy nie zmyśla liczby.
Odpaliłem na własnej stronie. Dogfooding zanim ktokolwiek zobaczy tool. Oto nagłówek:
Core Web Vitals: PASS (LCP good · CLS good · TTFB good · INP unmeasured)
Lighthouse perf: 72/100 (lab, throttled)Zmierzone Core Web Vitals stojące za tym PASS:
| Metric | Value | Rating | Role |
|---|---|---|---|
| LCP | 991 ms | good | core |
| CLS | 0.000 | good | core |
| TTFB | 42 ms | good | supporting |
Pass na vitalsach. 72 na Lighthouse. C, jeśli sprowadzisz to do jednej litery.
I teraz część, która ma znaczenie. Tool ocenia pięć obszarów - bundle, runtime, network, SSR/hydration, assets. Każdy wrócił z A. Zero findings. Każdy.
Pięć A i jedno C. Ta sama strona. Ten sam audyt. Ta sama sekunda.
Która liczba kłamie
Żadna. Mierzą różne rzeczy i o to właśnie chodzi.
Core Web Vitals to to, co czuje użytkownik i co rankuje Google. LCP 991 ms znaczy, że główna treść maluje się szybko. CLS zero znaczy, że nic nie skacze przy ładowaniu. Dobre, według progów Google, z zapasem.
Lighthouse performance score to diagnostyka labowa. Dominuje w nim Total Blocking Time, a na tej stronie TBT wyszło około 1740 ms. Ta jedna metryka ściąga composite score do 72, mimo że każdy vital przechodzi.
Uczciwy odczyt: strona jest szybka dla użytkownika, a metryka labowa jest z czegoś niezadowolona. Pojedyncza ocena C wyprałaby ten niuans w kłamstwo. Pojedyncza setka wyprałaby go w drugą stronę. Dwie osie mówią prawdę.
Ale chciałem wiedzieć, z czego lab jest niezadowolony. Liczba, której nie umiesz wyjaśnić, to liczba, której nie możesz ufać.
Kopanie
Trace collector jest dokładnie do tego. Otwiera stronę w Playwright, scrolluje, czeka aż się ustabilizuje, czyta Resource Timing API plus buforowany long-task observer. Prawdziwe timingi, prawdziwy render-blocking status, prawdziwa atrybucja main-thread.
Odpaliłem trzy razy na żywej stronie. Stabilne do pięciu milisekund.
Te 1740 ms blocking time mapuje się na jeden long task, około 810 ms. Atrybucja: unknown. To przeglądarka robiąca własną robotę - parsing, style, layout, paint. Nie mój JavaScript. Nie third-party. Nie ma czego obwiniać; cała strona wysyła 3.3 KB JS-a.
Co się naprawdę dzieje: Lighthouse odpala z 4x throttlingiem CPU, żeby zasymulować średni telefon. Pod tym throttlingiem własny pass przeglądarki na parsing i layout rozciąga się na tyle, żeby zarejestrować się jako long task. TBT to liczy. Score leci w dół. Prawdziwy użytkownik na prawdziwej maszynie nigdy tego nie odczuje jako long task - i dlatego field vitals wracają zielone.
Jest tu uczciwy limit i go nazwę. Long Tasks API atrybuuje self-work jako unknown i nie rozbije tego drobniej. Przypięcie tego do parsing-kontra-layout-kontra-paint wymaga pełnego CDP performance trace, cięższego niż to, co robi v0.1. Więc mogę ci powiedzieć, że long task to self-work przeglądarki pod throttlingiem. Nie umiem jeszcze powiedzieć, która mikrosekunda poszła gdzie. To roadmap, i wolę to powiedzieć, niż udawać, że tool wie więcej, niż wie.
Lekcja
O to tu naprawdę chodzi.
Gdyby tool pokazał tylko “Grade: C”, odszedłbyś z przekonaniem, że moje portfolio jest wolne. Nie jest. Każdy vital, który mapuje się na user experience, jest zielony, a każdy obszar, jaki tool umie zaudytować, wrócił czysty.
Gdyby pokazał tylko “Lighthouse: 100” - czego nie robi, ale mnóstwo narzędzi goni za tą liczbą - nie nauczyłbyś się nic o zachowaniu TBT pod throttlingiem, które na cięższej stronie naprawdę ma znaczenie.
Performance score to nie performance verdict. Score to przydatny sygnał labowy. Vitalsy to prawda użytkownika. Oceny obszarów to miejsce, gdzie jest robota, albo - jak tu - gdzie jej nie ma. Potrzebujesz wszystkich i potrzebujesz ich osobno, bo w momencie, w którym uśrednisz je w jedną literę, wyrzuciłeś jedyną informację wartą posiadania.
Dlatego nagłówek to split, nie ocena. To jedyna decyzja projektowa w tym toolu, na której mi najbardziej zależy, a moje własne portfolio jest dowodem. Strona, która dostaje C, a zasługuje na pięć A, to cały argument w jednym screenshocie.
| Area | Grade | Score | Findings |
|---|---|---|---|
| bundle | A | 100 | 0 |
| runtime | A | 100 | 0 |
| network | A | 100 | 0 |
| ssr-hydration | A | 100 | 0 |
| assets | A | 100 | 0 |
Co jest pod maską
Pomiar, który opisywałem, to deterministyczny floor: Lighthouse mediana z pięciu, synthetic web-vitals, resource trace, bundle parse, plus statyczny pass po source dla tych kilku anti-patternów, które złapiesz bez przeglądarki. Nic z tego nie dotyka modelu. To ten sam nudny, powtarzalny pomiar, który uważny inżynier zrobiłby ręcznie - tyle że odpala się w dwie minuty i daje tę samą odpowiedź dwa razy.
Na tym floorze siedzi pięciu AI specjalistów, jeden na obszar, każdy czyta zmierzony output i source, żeby wyjaśnić root cause i ustawić priorytety. Na moim portfolio nie mieli nic do powiedzenia, bo nie było co naprawiać. Na stronie faktycznie źle zbudowanej mają sporo - i o tym jest część 2.
Ta kolejność to teza, która ma nazwę, do której wracam: context before LLM. Najpierw zmierz. Pozwól modelowi interpretować to, co zmierzone. Nigdy nie pozwól mu zgadywać liczb. Ta sama dyscyplina trzymała się przez trzy produkcyjne audyty ecommerce, gdzie zła liczba nie kosztuje cię oceny - kosztuje klienta checkoutu.
Jutro
Część 2: architektura w całości i rzecz, którą najbardziej musiałem udowodnić, zanim czemukolwiek z tego zaufałem - że zmierzony floor jest stabilny. Odpaliłem ten sam audyt dwa razy, mediana z pięciu za każdym, jeden po drugim. Identyczny score, identyczna ocena, identyczny pass - taka stabilność, jaką możesz postawić przed klientem. Pokażę liczby, pięciu specjalistów i czemu split nagłówek bije pojedynczą ocenę, jak już zobaczysz, co pojedyncza ocena ukrywa.
#FromTheField