Publiczny toolkit audytuje jeden route i pokazuje ci o nim prawdę. Metoda za nim odpaliła na trzech platformach ecommerce - takich z koszykami, selektorami wariantów, krokami płatności i setką routes. To jest część o przepaści między jednym a drugim.
Najpierw - tool coś znajdujący
Część 1 była czystą stroną. Pięć A, nic do naprawienia - co robiło pointę o kłamiącym pojedynczym score, ale nie jest specjalnym demem. Więc toolkit shippuje slow-demo: celowo źle zbudowaną stronę Nuxt 3, gdzie każdy problem jest wymyślony na potrzebę i jasno oznaczony jako syntetyczny. Zero danych klienta, nigdy. Tylko kształt prawdziwych patternów.
Wycelowany w nią, sam deterministyczny statyczny pass znajduje siedem anti-patternów, bez przeglądarki i bez modelu:
runtimeCompiler: true w configu Nuxt, components: { global: true }, obrazek bez width i height, obrazek bez atrybutu loading, watch z deep: true i dwie zależności - lodash i moment - zadeklarowane i nigdy nieimportowane.
Oto raport, który drukuje statyczny pass, najpierw nagłówek:
- Core Web Vitals: unmeasured (odpal z
--urlpo zmierzoną ocenę) - Lighthouse perf: n/a (run tylko na source)
- Provisional findings grade: C (64/100)
| Area | Grade | Score | Findings |
|---|---|---|---|
| bundle | B | 81 | 4 |
| runtime | A | 95 | 1 |
| network | A | 100 | 0 |
| ssr-hydration | A | 100 | 0 |
| assets | B | 88 | 2 |
Quick Wins (Impact x Effort 6-9):
| Problem | Area | File/Resource | Impact | Effort | Score | Fix |
|---|---|---|---|---|---|---|
runtimeCompiler: true ships the Vue template compiler to the client. | bundle | examples/slow-demo/nuxt.config.ts:6 | 3 | 3 | 9 | Remove runtimeCompiler and precompile templates at build time, unless runtime templates are genuinely required. |
<img> is missing explicit width/height, which can cause layout shift (CLS). | assets | examples/slow-demo/pages/index.vue:8 | 3 | 3 | 9 | Add intrinsic width and height (or aspect-ratio) so the browser reserves space before the image loads. |
Global component registration (global: true) forces every component into the entry bundle. | bundle | examples/slow-demo/nuxt.config.ts:10 | 2 | 3 | 6 | Drop global: true and rely on Nuxt auto-import / explicit imports so components code-split per route. |
Medium (Impact x Effort 3-5):
| Problem | Area | File/Resource | Impact | Effort | Score | Fix |
|---|---|---|---|---|---|---|
Deep watcher (deep: true) recursively tracks every nested property. | runtime | examples/slow-demo/pages/index.vue:40 | 2 | 2 | 4 | Watch a specific getter/key, use shallowRef/shallowReactive, or restructure state so a deep watch is unnecessary. |
<img> has no loading attribute. | assets | examples/slow-demo/pages/index.vue:8 | 1 | 3 | 3 | Add loading=“lazy” for below-the-fold images; keep the LCP/above-the-fold image eager. |
| Dependency “lodash” is never imported in source (candidate for removal). | bundle | - | 1 | 3 | 3 | Confirm it is not used in config/runtime, then remove it. |
| Dependency “moment” is never imported in source (candidate for removal). | bundle | - | 1 | 3 | 3 | Confirm it is not used in config/runtime, then remove it. |
Każdy ma lokalizację (nuxt.config.ts:6, index.vue:8), impact w treści komunikatu, konkretny fix i score Impact x Effort, który sortuje go do Quick Wins, Medium albo Low. To cały raport, którego dev potrzebuje: gdzie, co, jak i w jakiej kolejności.
To te pewne - pattern-matchowalne bez uruchamiania czegokolwiek. Druga połowa metody pojawia się dopiero w pełnym audycie, z URL-em do zmierzenia: pięciu AI specjalistów czyta zmierzony floor i source i dorzuca to, co wymaga interpretacji, nie pattern-matchingu. Style object literal w v-for, którego statyczna reguła nie może bezpiecznie zgłosić. Seria niezależnych awaitów, które miały być równoległe. Payload ciągnący każde pole, gdy potrzebuje trzech. To decyzje osądu na wierzchu pomiaru i dokładnie to, czego statyczny pass celowo nie zgaduje.
Ten split to cała architektura w jednym przykładzie. Statyczny pass łapie to, co na pewno złe, sam, szybko. Specjaliści, czytając prawdziwe pomiary, łapią to, co kontekstowo złe. Żaden nie zrobi roboty drugiego.
Mały, uczciwy moment
Przy budowaniu statycznego passa slow-demo złapało buga w moim własnym analyzerze. Check na deep watcher matchował deep: true wszędzie, gdzie się pojawiło - włącznie ze zwykłymi obiektami danych, które nie mają nic wspólnego z watcherem Vue. False positive. Fixture go ujawnił, a fix to wymóg, żeby match siedział obok faktycznego watch().
Wspominam, bo tool, który znajduje problemy, trzeba trzymać przy standardzie, który ustawia. Fixture, który demonstruje tool, jednocześnie go przetestował pod obciążeniem, i był błędny, zanim był poprawny. Po to jest dogfooding.
Linia między public a Pro
Wszystko, co opisałem, to publiczny toolkit, AGPL-3.0, klonuj i odpalaj. To kompletna metoda na jednym route: deterministyczny floor, pięciu specjalistów, split nagłówek, guided fix walkthrough. Jeśli chcesz zrozumieć, jak działa context-first performance audit, jest tam całe, działające, na prawdziwych pomiarach.
Czym nie jest, to produkcyjne zlecenie. Trzy audyty ecommerce, z których przyszedł ten distylat, potrzebowały rzeczy, które nie należą do publicznego single-route toola:
Wiele routes, audytowanych jako zestaw, z findingami zdeduplikowanymi w poprzek - bo ten sam rozdęty payload na czterdziestu stronach produktów to jeden root cause, nie czterdzieści findings.
Lokalny runtime - specjaliści odpalający przez Ollama na maszynie, zero source wychodzącego poza budynek - bo niektóre repozytoria klientów nie mogą wysłać kodu do hostowanego modelu, kropka.
Prawdziwy auto-fix engine z verifier loop - zaaplikuj zmianę, zmierz ponownie, potwierdź, że metryka faktycznie się ruszyła - zamiast guided walkthrough, który shippuje publiczny tool.
Specjaliści React, Svelte i Angular, bo publiczny v0.1 jest uczciwie Vue/Nuxt-first, a wolę zshippować jeden framework zrobiony porządnie niż cztery zrobione na zgadywankę.
To jest linia Pro. Nie funkcje schowane za paywallem dla samego chowania - części, które mają sens dopiero w skali produkcyjnej, na prawdziwych ograniczeniach klienta, z latami audytowania ecommerce, które zakodowali niszowi specjaliści.
Druga połowa mieszka gdzie indziej
Jedna rzecz, którą te trzy audyty obejmowały, a której ten tool celowo nie robi: backend. Load testing, telemetria serwera, root-cause bazy i wyszukiwarki, log mining - to wszystko była prawdziwa robota na tych platformach i nic z tego nie pasuje do frontendowego performance toola. To inny produkt o innym kształcie i dostanie własną historię kiedy indziej. Frontendowy audyt udający też load test to dwa narzędzia zrobione źle. Ten zostaje uczciwy co do swojej krawędzi: audytuje frontend i mówi to wprost.
Czemu /perf:fix po prostu tego nie naprawia
Publiczny tool ma komendę /perf:fix i jest celowo skromna. Przeprowadzi cię przez finding - wyjaśni, co źle, pokaże before i after, da ci zaaplikować - i auto-zaaplikuje najwyżej jedną-dwie trywialne mechaniczne zmiany jako demo. loading="lazy" tu, font-display: swap tam.
Tak wygląda jeden finding, kiedy /perf:fix go pokazuje - gdzie, co, jak i z jakim priorytetem, wszystko z własnego raportu toola:
| Gdzie | Co | Jak | Priorytet |
|---|---|---|---|
| assets / index.vue:8 | <img> bez width/height (ryzyko CLS) | Dodaj intrinsic width/height albo aspect-ratio | Quick Win (Impact 3 x Effort 3 = 9) |
Reszty nie auto-zaaplikuje i to decyzja projektowa, nie brakująca funkcja.
Performance fixy są w większości architektoniczne. Rozbicie bundla, przebudowa hydration, zrównoleglenie request waterfalla, dodanie route rules - to decyzje z trade-offami, nie mechaniczne patche. WCAG toolkit nauczył mnie tej lekcji w innej domenie: auto-fixowalna część prawdziwych findings jest mała, a uczciwy framing to taki, że tool odkrywa i wyjaśnia, a człowiek decyduje. Każdy, kto sprzedaje ci AI auto-fixujące performance, sprzedaje ci tool, który pewnie pogorszy twoją stronę.
Więc tool znajduje, mierzy, robi root-cause i ustawia priorytety. Ty naprawiasz. Jeśli chcesz kogoś, kto naprawiał to na trzech produkcyjnych platformach ecommerce - to jest ta rozmowa.
Gdzie to zostawia serię
Trzy części, jedna teza, udowodniona na prawdziwych pomiarach od początku do końca.
Pojedynczy performance score kłamie, a moje własne portfolio to udowodniło - C na score, zielono na każdym vitalu, A na każdym obszarze. Floor pod spodem jest deterministyczny i stabilny - score, werdykt i ocena identyczne między runami - co w ogóle pozwala ufać AI na wierzchu. A metoda skaluje od tego jednoroute’owego distylatu do multi-route, multi-framework, lokalnego runtime’u produkcyjnej roboty - części, która nigdy nie miała zmieścić się w publicznym repo.
Publiczny toolkit to edukacja. Produkcyjne zlecenie to nisza. Oba są uczciwe co do tego, które jest które.
Więcej o tierze Pro i konsultingu: sdet.it/uslugi.
Seria #04 kończy się tutaj.
#FromTheField