Model składa layout w kilka minut. Potem zostaje przegląd kodu, LCP, kontrast, obsługa klawiatury i pytanie, ile ta reszta kosztuje w wycenie. Piszemy o tej drugiej części: co konkretnie sprawdzić, co poprawić i jak wygląda różnica w liczbach.
poniżej: 1 komponent · 14 linijek · 5 uwag do znalezienia
// serwer: GET /api/items, klucz z process.env
fetch("/api/items") // klient: bez klucza.then(r => { if (!r.ok) throw new Error(r.status); return r.json(); })
.then(d => setItems(Array.isArray(d) ? d : []))
.catch(setBlad);useEffect(() => {
const ac = new AbortController();
fetch("/api/items", { signal: ac.signal }) /* … */
return () => ac.abort();
}, []); // raz, po montażu<dialog ref={ref} onClose={zamknij} aria-labelledby="tytul">
…
</dialog> // ref.current.showModal(): Escape i pułapka fokusu<img src={i.url} width={i.w} height={i.h}
alt={i.opis} loading="lazy" />Przesuń wartość po wygenerowaniu. Wynik po poprawkach liczymy z tego, co opisujemy w tekstach o hero, foncie, skryptach w head i obrazach bez wymiarów. Progi wg Google, ocena na 75. percentylu.
przykład modelowy
wartości do podmiany
profil mobilny, laboratorium
Wartość „po poprawkach” to model: LCP × 0,43 (min. 1,2 s), CLS × 0,2 (min. 0,02), INP × 0,45 (min. 80 ms). W tekstach zastępujemy go pomiarem z karty pomiaru.
Minimum, które sprawdzamy w każdym rozbiorze. Odhacz to, co masz w projekcie, a stan zostaje w przeglądarce tylko do zamknięcia karty.
każda pozycja ma tekst
z kodem przed i po
numer to linijka, od której
zaczyna się obszar w tym pliku
Co zatrzymać na review: zdublowany stan, zależność dorzucona bez potrzeby, brak walidacji wejścia, klucz wklejony do komponentu. Fragment przed poprawką i po niej, obok siebie.
Jakość kodu →Dlaczego wygenerowany layout wypada dobrze lokalnie i słabo w polu. Hero, fonty, skrypty w head, obrazy bez wymiarów - po kolei, z pomiarem przed i po zmianie.
Core Web Vitals →Kontrast, kolejność fokusu, etykiety pól, obsługa klawiatury w modalach i menu. Czego brakuje w typowym wygenerowanym komponencie i jak to sprawdzić, zamiast zgadywać.
Dostępność WCAG →Ile godzin realnie zostaje po wygenerowaniu makiety, jak zapisać to w wycenie i co oddać klientowi, żeby stronę dało się utrzymać bez autora pierwszej wersji.
Wycena i proces →7 tekstów w rejestrze
każdy z linijką pomiaru
INP zastąpił FID w marcu 2024. Jak zmierzyć trzy etapy interakcji na wygenerowanej stronie i który z nich naprawiać, zanim oddasz projekt klientowi.
Wycena z założeniem, że model zrobi połowę roboty, pomija przegląd i poprawki. Co dopisać do pozycji i jak policzyć własny współczynnik z repozytorium.
Przejmujesz stronę po innym wykonawcy: npm ci, wersja Node, sekrety, audyt zależności i test smoke. Sprawdzenia do zrobienia przed wyceną utrzymania.
Pięć wzorców, które modele powtarzają w generowanych komponentach: nieistniejące paczki, wyścig w useEffect, innerHTML bez ucieczki i testy na atrapie.
Profil do obsadzenia realnym developerem front-end. Każdy tekst z fragmentem kodu albo wynikiem pomiaru, nie z opinią. Ton praktyczny, bez zachwytu nad narzędziami: wynik przed i po, a nie deklaracje. Teksty powstają z pomocą modelu językowego i są oznaczone.
Piszemy z kodem i z pomiarem. Każdy tekst bierze jeden konkretny przypadek: fragment przed poprawką, fragment po, i to, co zmieniło się w wyniku. Liczby podajemy razem z warunkami pomiaru, żeby dało się je powtórzyć u siebie. Nie robimy rankingów narzędzi ani zestawień „top 10” - to samo zadanie wygląda inaczej w każdym stacku, więc opisujemy metodę, nie zwycięzcę. Jeśli czegoś nie da się sprawdzić, piszemy o tym wprost zamiast domykać tekst zgadywaniem.
Napisz, jeśli masz konkretny przypadek - wygenerowany komponent, który się psuje, słaby wynik Core Web Vitals albo problem z dostępnością - i chcesz, żeby powstał z tego rozbiór z kodem.