Wydajność frontendu: od niewidzialnych luk w przeglądaniu kodu do wskaźników produktu
Dowiedz się, dlaczego samo przejście przeglądu kodu nie wystarcza, które Core Web Vitals są naprawdę istotne oraz jak mierzyć i naprawiać problemy wydajności React w rzeczywistych warunkach.
Przeszło przegląd kodu
Pożyczka kodowa jest w porządku. Logika jest poprawna. Wszystkie testy przeszły pomyślnie. Zatwierdził ją doświadczony inżynier.
Zatwierdzasz zmianę w czwartek po południu.
W piątek rano otrzymujesz wiadomość od menedżera produktu: „Ludzie mówią, że aplikacja działa wolno.”
Zaczynasz więc używać Chrome DevTools. Na swoim MacBook Pro, podłączonym do domowej łącza światłowodowego, z Chrome'em bez włączonych dziesiątek rozszerzeń, wszystko wygląda płynnie.
Jednak twoi użytkownicy nie mają takiego sprzętu jak ty.
Wielu z nich korzysta z urządzeń Android średniej półki sprzed kilku lat, łącząc się przez 4G, które często spada do poziomu 3G. Mogą znajdować się w Dżakarcie, Lagos lub Baku – miejscach, gdzie sama opóźniona łączność może dodawać od 200 do 400 milisekund do każdej prośby.
Dlaczego istnieje ta luka
Większość programistów front-end pracuje w niemal idealnych warunkach, a potem wprowadza swoje rozwiązania w znacznie bardziej chaotyczne środowiska. To niezgodność jest dokładnie tym miejscem, gdzie kiełkują problemy z wydajnością.
Oto co twoje codzienne środowisko programistyczne przed tobą ukrywa:
Zwalnianie CPU. Twoje maszynę do rozwoju wyposażono w dużą moc obliczeniową. Narzędzia Chrome DevTools mogą symulować spowolnienie CPU o 4 lub 6 razy, ale prawie nikt nie zadba o jego włączenie.
Warunki sieciowe. Testowanie na localhost oznacza zerową opóźnioność. Prawdziwi użytkownicy muszą radzić sobie z czasem przesyłania danych w przedziale od 100 do 500 milisekund. Operacja pobierania danych, która na twojej maszynie wydaje się natychmiastowa, może sparaliżować interfejs na całą sekundę po jego uruchomieniu.
Rozmiar pliku. Dodawanie biblioteki podczas programowania wydaje się bezkosztowe — nie widać żadnych kosztów. W środowisku produkcyjnym jednak ta sama zależność może zwiększyć początkowy rozmiar pliku o 80 KB, a użytkownik korzystający z 3G musi to wszystko pobrać, zanim cokolwiek zostanie wyświetlone.
Czas parsowania JavaScriptu. Umieszczenie pliku na urządzeniu to dopiero pierwszy krok. Następnie przeglądarka musi go przetworzyć i uruchomić. Na słabszym sprzęcie samo parsowanie pliku o rozmiarze 500 KB może zająć od 3 do 4 sekund.
W połączeniu te czynniki powodują rzeczywiste rozdźwięki pomiędzy tym, jak twoja aplikacja wydaje się tobie, a tym, jak wydaje się osobom, które ją faktycznie używają — a ten rozdźwięk zazwyczaj pozostaje niewidoczny, dopóki jakaś skarga nie ujawni go publicznie.
Dlaczego wydajność to decyzja produktowa
Inżynierowie frontendu często zaliczają kwestie wydajności do „detali technicznych“. Menedżerowie produktów często całkowicie je ignorują, dopóki nie staną się sytuacją awaryjną.
Ani jeden z tych podejść nie jest skuteczny.
Kwestie wydajności powinny być częścią rozmów o produkcie, ponieważ wpływają na wyniki, które firma faktycznie monitoruje.
Dochód. Amazon donosi, że każde dodatkowe 100 milisekund opóźnienia kosztuje ich około 1% sprzedaży. Przy dochodzie w wysokości miliarda dolarów dziennie oznacza to 10 milionów dolarów straty na każde 100 ms. Mniejsze firmy mają mniejsze kwoty, ale związek ten pozostaje niezmienny.
Zatrzymanie użytkowników. Ponad połowa odwiedzających przez urządzenia mobilne — 53% — opuszcza stronę, która ładowa się dłużej niż 3 sekundy. Rzadko składają skargi; po prostu odchodzą i już nie wracają.
SEO. Od 2021 roku Google uwzględnia Core Web Vitals w swoim algorytmie rankingu. Powolna praca strony powoduje jej spadek na liście wyników, co oznacza, że coraz mniej osób może ją znaleźć.
Dostępność. Szybkość jest również kwestią równości. Osoby korzystające ze starszych urządzeń i wolniejszych połączeń są w nierównym stopniu reprezentowane na rynkach rozwijających się oraz w grupach o niższych dochodach. Aplikacja, która jest powolna, faktycznie wyklucza część twojej publiczności.
Gdy skupisz rozmowę na przychodach, retencji, widoczności w wyszukiwarkach oraz dostępności, wydajność przestaje być traktowana jako opcjonalna i staje się podstawowym wymogiem.
Metryki, które naprawdę mają znaczenie
Nie można naprawić tego, czego nie mierzy się, a nie można zmierzyć tego, czego nie zdefiniowano. Właśnie dlatego wspólna terminologia dotycząca wydajności staje się niezbędna.
Core Web Vitals firmy Google stanowią obecnie najbardziej niezawodną ramę do tego celu.
LCP — Najdłuższy czas renderowania treści
Mierzy on czas potrzebny na wyrenderowanie największego widocznego elementu na stronie — mówiąc prościej, moment, w którym użytkownik odczuwa, że strona została „załadowana”.
Dobrze: mniej niż 2,5 sekundy. Wymaga poprawy: od 2,5 do 4 sekund. Słabo: ponad 4 sekundy.
Typowe przyczyny: zbyt duże, nieoptymalizowane obrazy, zasoby blokujące renderowanie oraz powolne odpowiedzi serwera.
INP — Czas od interakcji do kolejnego renderowania
Mierzy on opóźnienie pomiędzy akcją użytkownika — kliknięciem, dotknięciem lub naciśnięciem klawisza — a momentem, w którym ekran wykazuje odpowiedź wizualną. Zastąpił on FID (First Input Delay) jako standardowa miara interaktywności w 2024 roku.
Dobrze: poniżej 200 ms. Wymaga poprawy: od 200 do 500 ms. Słabo: powyżej 500 ms.
Zwykłe przyczyny: intensywne obliczenia wykonywane na głównej wątku oraz praca synchroniczna, która blokuje renderowanie.
CLS — Cumulative Layout Shift
Mierzy to, o ile treść niespodziewanie się przesuwa podczas ładowania strony. Wyniki wskazują wartości od 0 (brak przesunięć) wzwyż, przy czym wartości powyżej 1 uznawane są za poważne.
Dobrze: poniżej 0,1. Wymaga poprawy: od 0,1 do 0,25. Słabo: powyżej 0,25.
Zwykłe przyczyny: obrazy bez wyraźnie określonej szerokości i wysokości, treść dodawana dynamicznie po załadowaniu oraz czcionki webowe ładowane późno.
Jak mierzyć: Twoje narzędzia
Lighthouse (zacznij stąd)
Otwórz Chrome DevTools, przejdź do karty Lighthouse i przeprowadź audyt w profilu mobilnym z włączonym ograniczeniem wydajności.
Lighthouse podaje wynik w zakresie od 0 do 100 dla kategorii Wydajność, Dostępność, SEO oraz Najlepsze praktyki. To, co czyni go naprawdę przydatnym, to fakt, że wyjaśnia dlaczego otrzymałeś taki wynik i wskazuje, co należy naprawić najpierw.
# Or run it from the CLI for CI/CD integration
npm install -g lighthouse
lighthouse https://yourapp.com --output html --output-path report.html
Ważne: zawsze uruchamiaj Lighthouse w oknie incognito. Zainstalowane rozszerzenia przeglądarki mogą zniekształcić wyniki.
Profiler w React DevTools
To chyba najmniej używany narzędzie dostępne dla programistów React, mimo że jest jednym z najbardziej pouczających.
Aby go użyć, otwórz React DevTools, przejdź do karty Profiler, naciśnij „Record”, interaktywnie korzystaj z aplikacji, a następnie zatrzymaj nagrywanie.
Wynikiem jest wykres płomieniowy pokazujący każdą renderizację, która miała miejsce — które komponenty zostały uruchomione, co je spowodowało oraz ile czasu zajęła każda z nich.
What to look for:
- Components rendering more than they should
- Renders triggered by unrelated state changes
- Expensive components re-rendering on every keystroke
Biblioteka Web Vitals
Jeśli chcesz sprawdzić, jak Twoja aplikacja działa u rzeczywistych użytkowników, a nie tylko w lokalnym środowisku DevTools, biblioteka web-vitals jest odpowiednim rozwiązaniem:
import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(metric => {
// Send to your analytics service
console.log('LCP:', metric.value);
});onINP(metric => {
console.log('INP:', metric.value);
});onCLS(metric => {
console.log('CLS:', metric.value);
});
Taki podejście dostarcza danych ze sesji prawdziwych użytkowników, a nie liczb uzyskanych w sztucznych warunkach laboratoryjnych.
Ponowna renderizacja, o której nie wiedziałeś
Jednym z najtrudniejszych do wykrycia problemów wydajnościowych w React jest ten, który nie daje żadnych objawów. Zwykle wygląda tak:
// ❌ Problem: selecting the full user object
function Header() {
const user = useSelector(state => state.user);
return <div>{user.name}</div>;
}
Ten komponent będzie się ponownie renderował za każdym razem, gdy zmieni się jakakolwiek właściwość wewnątrz state.user, niezależnie od tego, czy komponent faktycznie odczytuje tę właściwość. Jeśli obiekt użytkownika zawiera dwadzieścia pól, a pięć z nich zmienia się często, Header będzie się renderował pięć razy częściej niż to konieczne.
// ✅ Fix: select only what you need
function Header() {
const name = useSelector(state => state.user.name);
return <div>{name}</div>;
}
Dzięki tej zmianie Header reaguje już tylko na zmiany w name. To mała modyfikacja, ale jej wpływ na wydajność jest rzeczywisty.
Ta sama logika odnosi się do Context:
// ❌ Problem: consuming the full context
function ThemeButton() {
const { theme, user, notifications } = useAppContext();
return <button className={theme}>Click</button>;
}
// ✅ Fix: split contexts by update frequency
const ThemeContext = createContext();
const UserContext = createContext();function ThemeButton() {
const theme = useContext(ThemeContext);
return <button className={theme}>Click</button>;
}
Lazy Loading: Przestań wysyłać kod, którego użytkownicy nie potrzebują
Częstym błędem w projektach React jest wysyłanie całego pliku aplikacji przy pierwszym załadunku strony — włączając kod dla tras, których użytkownik jeszcze nie otworzył i być może nigdy nie otworzy.
// ❌ Problem: all routes loaded upfront
import CheckoutPage from './pages/CheckoutPage';
import AdminDashboard from './pages/AdminDashboard';
import SettingsPage from './pages/SettingsPage';
function App() {
return (
<Routes>
<Route path="/checkout" element={<CheckoutPage />} />
<Route path="/admin" element={<AdminDashboard />} />
<Route path="/settings" element={<SettingsPage />} />
</Routes>
);
}
// ✅ Fix: lazy load each route
import { lazy, Suspense } from 'react';
const CheckoutPage = lazy(() => import('./pages/CheckoutPage'));
const AdminDashboard = lazy(() => import('./pages/AdminDashboard'));
const SettingsPage = lazy(() => import('./pages/SettingsPage'));function App() {
return (
<Suspense fallback={<PageSkeleton />}>
<Routes>
<Route path="/checkout" element={<CheckoutPage />} />
<Route path="/admin" element={<AdminDashboard />} />
<Route path="/settings" element={<SettingsPage />} />
</Routes>
</Suspense>
);
}
Dzięki takiemu rozwiązaniu każda trasa staje się oddzielnym fragmentem, dzięki czemu użytkownicy pobierają jedynie kod niezbędny do strony, którą faktycznie przeglądają. W większych aplikacjach sama ta zmiana może zmniejszyć początkowy rozmiar pliku o 40 do 60 procent.
Kiedy NIE optymalizować: pułapka useMemo
Większość przewodników dotyczących wydajności pomija ten aspekt: zbyt wczesna optymalizacja może negatywnie wpłynąć na kod.
useMemo i useCallback wiążą się z własnymi kosztami – zużyciem pamięci oraz porównywaniem zależności przy każdym renderowaniu. Jeśli użyjesz ich w niewłaściwym miejscu, możesz ostatecznie osiągnąć gorszą wydajność niż wcześniej.
// ❌ Unnecessary — this calculation is not expensive
function UserCard({ user }) {
const displayName = useMemo(
() => `${user.firstName} ${user.lastName}`,
[user.firstName, user.lastName]
);
return <div>{displayName}</div>;
}
// ✅ Just compute it — string concatenation is instant
function UserCard({ user }) {
const displayName = `${user.firstName} ${user.lastName}`;
return <div>{displayName}</div>;
}
// ✅ useMemo IS worth it here — genuinely expensive calculation
function DataGrid({ rows, filters }) {
const filteredRows = useMemo(
() => rows.filter(row => matchesAllFilters(row, filters)),
[rows, filters]
);
return <Table rows={filteredRows} />;
}
Zasada przewodnia: najpierw wykonaj profilowanie, zanim cokolwiek zmienisz, optymalizuj dopiero potem, a następnie ponownie zmierz wydajność, aby upewnić się, że naprawa przyniosła efekt. Nie polegaj na intuicji.
Jeśli narzędzie do analizy nie oznaczy żadnego komponentu jako wąskiego gardła, pozostaw go bez zapisania w pamięci — dodana złożoność nie jest warta wysiłku.
Optymalizacja obrazów: najprostsze rozwiązania
Obrazy są często główną przyczyną wolnego ładowania stron, a jednocześnie należą do najłatwiejszych problemów do naprawienia.
// ❌ Unoptimized: full-size image, no lazy loading
<img src="/hero-image.png" />
// ✅ Optimized: modern format, explicit dimensions, lazy loading
<img
src="/hero-image.webp"
width={1200}
height={600}
loading="lazy"
decoding="async"
alt="Hero image"
/>
Kilka nawyków może znacząco wpłynąć na efektywność:
Zmień format z PNG lub JPEG na WebP lub AVIF. WebP zazwyczaj zmniejsza rozmiar pliku o 25 do 35 procent w porównaniu z JPEG przy podobnej jakości. AVIF kompresuje pliki jeszcze bardziej, choć obsługa tego formatu w przeglądarkach nie jest jeszcze tak powszechna.
Zawsze określ wyraźnie atrybuty szerokości i wysokości. Dzięki temu przeglądarka nie będzie modyfikować układu po zakończeniu ładowania obrazu, co bezpośrednio poprawia wynik oceny CLS.
Zastosuj loading="lazy" do wszystkiego, co znajduje się poniżej obszaru widocznego. Przeglądarka wtedy czeka z pobieraniem tego obrazu, aż użytkownik zamierzy przewinąć stronę tak, by obraz stał się widoczny.
Dodaj decoding="async" do obrazów, które nie są kluczowe dla pierwszego odświeżenia strony. Dzięki temu przeglądarka może dekodować obraz na osobnym wątku, zamiast blokować proces renderowania.
Prawdziwe kompromisy
Żadna technika optymalizacji nie jest bezkosztowa. Oto szczery opis tego, co tracisz w zamian:
Rozdzielanie kodu według tras zmniejsza rozmiar początkowego pliku, ale powoduje niewielkie opóźnienie przy pierwszym przejściu użytkownika na nową trasę. Pobieranie obrazów w trybie lazy-loading przyspiesza początkowe ładowanie, ale sprawia, że obrazy pojawiają się stopniowo w miarę przewijania strony. Umieszczanie kosztownych obliczeń w funkcji useMemo zmniejsza liczbę ponownych renderowań, ale kosztem większej złożoności kodu i gorszej czytelności. Cacheowanie za pomocą Service Worker sprawia, że powtórne wizyty są niemal natychmiastowe, ale wymaga skomplikowanej logiki unieważniania cache’u. Renderowanie po stronie serwera lub generowanie statyczne zapewniają szybkie wyświetlenie strony i lepsze SEO, ale wymagają większej infrastruktury serwerowej oraz dodatkowej złożoności w procesie hydratacji.
Zasada leżąca u podstaw tego wszystkiego: nigdy nie optymalizuj czegoś na podstawie wskaźnika, którego faktycznie nie zmierzyłeś.
Ocena Lighthouse na poziomie 95 nie mówi nic o tym, czy rzeczywiści użytkownicy mają dobre doświadczenie. Wyposaż swoją aplikację w bibliotekę Web Vitals, zbieraj dane od rzeczywistych odwiedzających, zlokalizuj prawdziwy wąskie gardło, napraw to konkretny problem, a następnie zmierz ponownie, aby potwierdzić, że rozwiązanie zadziałało.
Praktyczna lista kontrolna
Zanim wdrożysz jakąkolwiek istotną funkcję, przejdź przez tę listę:
Performance Checklist
─────────────────────
□ Run Lighthouse on mobile with throttling (target score: 90+)
□ Check bundle size with webpack-bundle-analyzer or source-map-explorer
□ Verify all routes are lazy loaded
□ Confirm images use WebP/AVIF with explicit dimensions
□ Profile with React DevTools — no unnecessary re-renders
□ Check Core Web Vitals in production with web-vitals library
□ Test on a real mobile device, not just DevTools emulation
# Install bundle analyzer
npm install --save-dev webpack-bundle-analyzer
# Or for Vite
npm install --save-dev rollup-plugin-visualize
Wniosek
Poprawa wydajności to nie ostatnia akcja, którą wykonujesz przed wypuszczeniem aplikacji, ani warstwa dodawana dopiero wtedy, gdy funkcja już działa. To dyscyplina – zbiór nawyków i narzędzi wplecionych w twój codzienny proces pracy.
Inżynierowie tworzący najszybsze aplikacje nie są z natury bardziej utalentowani od tych, którzy tworzą wolne aplikacje. Po prostu dokonują bardziej spójnych pomiarów. Wiedzą, który narzędzie pasuje do danego problemu, i wdrożyli prosty schemat działania: najpierw przeprowadzić analizę, naprawić tylko to, na co wskazują dane, a następnie ponownie zmierzyć, aby potwierdzić, że to pomogło.
Aplikacja może przejść przez wszystkie przeglądy kodu i mimo to rozczarować prawdziwych użytkowników.
Mierz. Analizuj. Napraw to, co naprawdę ma znaczenie.
Literatura pokrewna
- Jak zmniejszyć rozmiar komponentów React poprzez eliminację nadmiernych elementów — Poznaj siedem konkretnych wzorców refaktoryzacji, które pozwalają rozbić obszerne komponenty React poprzez izolację stanu, pobierania danych, uprawnień i logiki ładowania, zamiast jedynie dzielenia plików.