Jak realnie mierzyć wydajność aplikacji? 3 metryki, które faktycznie mają znaczenie

Każdy, kto kiedykolwiek pracował przy aplikacji webowej, słyszał mantrę: „szybkość strony to podstawa”. Problem w tym, że większość firm mierzy prędkość tak, jakby mierzyła prędkość samochodu za pomocą temperatury oleju – niby coś mówi, ale nie do końca wiadomo czy to jest to.

W audytach, które przeprowadzam dla klientów JurskiTech, regularnie widzę zespoły, które patrzą na Lighthouse na 100, a użytkownicy i tak narzekają, że aplikacja „laguje”. Albo skupiają się na czasie ładowania strony, podczas gdy prawdziwy problem leży w interaktywności. Dlaczego tak się dzieje? Bo branża marketingowa wykreowała kilka lat temu kult szybkości ładowania, który dziś nie ma wiele wspólnego z rzeczywistym doświadczeniem użytkownika.

Google próbuje to zmienić od 2020 roku, wprowadzając Core Web Vitals – ale nawet tam wiele firm dalej patrzy na zastępcze metryki. W tym artykule pokażę trzy wskaźniki, które realnie decydują o tym, czy Twoja aplikacja jest postrzegana jako szybka, czy wręcz przeciwnie – i jak je praktycznie poprawić.

1. First Input Delay (FID) / Interaction to Next Paint (INP) – opóźnienie reakcji na interakcję

Zacznijmy od najważniejszego: czy Twoja aplikacja reaguje na kliknięcie? Wiele stron ładuje się błyskawicznie, ale gdy użytkownik chce coś zrobić – kliknąć przycisk, otworzyć menu, wpisać tekst – następuje sekunda martwej ciszy. To jest właśnie First Input Delay (FID) – czas od momentu interakcji do rozpoczęcia jej obsługi przez główny wątek przeglądarki.

W 2024 roku Google zastąpiło FID nową metryką – Interaction to Next Paint (INP), która mierzy opóźnienie dla wszystkich interakcji, nie tylko pierwszej. Jeśli INP przekracza 200 ms, aplikacja jest odbierana jako „opóźniona”. Jeśli przekracza 500 ms – użytkownicy zaczynają klikać wielokrotnie, irytować się i odchodzić.

Dlaczego większość firm to ignoruje? Bo narzędzia takie jak Lighthouse nie zawsze pokazują realne wartości FID/INP – one szacują na podstawie symulacji. Prawdziwe dane zbierasz jedynie z pola (RUM – Real User Monitoring). I tu pojawia się pierwszy błąd: firmy optymalizują pod kątem testów syntetycznych, a nie rzeczywistego zachowania użytkowników.

Jak to poprawić? Przede wszystkim audyt kodu JavaScript: zbyt wiele bibliotek, nieoptymalne nasłuchiwacze zdarzeń, blokujący rendering CSS. Kluczowe jest „code splitting” – dzielenie kodu na mniejsze fragmenty wczytywane na żądanie. Użyj narzędzi takich jak Webpack Bundle Analyzer, by zidentyfikować „ciężkie” fragmenty. W JurskiTech często stosujemy też technikę „idle until urgent” – pozwalając przeglądarce przetwarzać kod tylko wtedy, gdy jest faktycznie potrzebny.

Praktyczny przykład: pracowałem niedawno z SaaS-em z branży fintech. Ich panel klienta ładował się w 1,2 s (według Lighthouse), ale INP wynosił 800 ms. Przyczyną była ogromna biblioteka chartingowa wczytywana od razu, podczas gdy pierwsze interakcje użytkownika dotyczyły logowania. Po odroczeniu ładowania wykresów do momentu wejścia w zakładkę raportów, INP spadł do 150 ms. Wzrost konwersji? +12%.

2. Time to Interactive (TTI) – czas do pełnej interaktywności

TTI to metryka, która mówi, po jakim czasie użytkownik może w pełni korzystać z aplikacji – czyli wszystkie elementy są wyświetlone, a główny wątek nie jest zablokowany. Jest to istotne zwłaszcza dla aplikacji single-page (SPA), gdzie początkowy HTML jest często „pustą skorupą”, a cała treść dostarczana jest przez JavaScript.

Wiele firm myli TTI z Largest Contentful Paint (LCP) – czyli momentem wyświetlenia największego elementu. LCP może być niskie, ale TTI wysokie, jeśli zaraz po wyrenderowaniu obrazka przeglądarka zaczyna przetwarzać duże skrypty. Użytkownik widzi stronę, ale nie może nic kliknąć.

Dlaczego to boli biznes? Jeśli prowadzisz sklep internetowy i aplikacja jest interaktywna dopiero po 5 sekundach, użytkownik zdąży już przejść do konkurencji. Badania Google pokazują, że wzrost TTI z 2 do 5 sekund zwiększa współczynnik odrzuceń o 30%.

Jak poprawić TTI? Lista działań jest prosta, ale wymaga dyscypliny: ogranicz JavaScript, wczytuj go asynchronicznie, używaj lazy loading dla komponentów, unikaj blokujących skryptów zewnętrznych (np. czat na żywo, systemy analityczne). W jednym z projektów dla klienta z branży e-commerce zredukowaliśmy TTI z 6,2 s do 1,8 s poprzez usunięcie nieużywanych wtyczek i przeniesienie skryptów analitycznych do Web Workera. Efekt? Wzrost konwersji o 15%.

Warto też rozważyć technikę „progressive hydration” (np. w frameworkach takich jak React czy Vue), czyli stopniowe aktywowanie komponentów w miarę potrzeby. Zamiast hydratować całą aplikację od razu, robisz to partiami. To szczególnie ważne w aplikacjach z dynamiczną treścią.

3. Cumulative Layout Shift (CLS) – stabilność wizualna

CLS mierzy, jak bardzo układ strony „skacze” podczas ładowania. Każdy zna to uczucie: czytasz artykuł, nagle wyskakuje obrazek, reklama przesuwa tekst, klikasz w reklamę zamiast w przycisk. To właśnie CLS. Google uznało to za jeden z kluczowych wskaźników Core Web Vitals, i słusznie – destabilizacja wizualna drażni użytkowników i prowadzi do błędnych kliknięć.

Dlaczego większość firm ignoruje CLS? Bo wydaje się, że to detal. Jednak w praktyce CLS powyżej 0,25 może oznaczać nawet 20% spadek konwersji w e-commerce. W sklepie, gdzie klient chce dodać produkt do koszyka, a przycisk nagle się przesuwa, użytkownik najprawdopodobniej zamknie zakładkę.

Jak poprawić CLS? Podstawowa zasada: zawsze rezerwuj miejsce dla elementów, które ładują się później – obrazków, wideo, reklam, a także czcionek (poprzez font-display: swap lub optional). Używaj atrybutów width i height w znacznikach img, unikaj dynamicznego wstrzykiwania treści nad już widoczną zawartością.

Przykład z autopsji: w jednym z landing page’ów dla klienta z branży fintech CLS wynosił 0,45. Powód? Biblioteka animacji wczytywała się z opóźnieniem i powodowała przesunięcie całej sekcji hero. Po zarezerwowaniu dla niej stałej wysokości i dodaniu placeholdera, CLS spadł do 0,05. Wzrost zapytań ofertowych o 8%.

Mierzenie, które ma sens

Podsumowując: nie daj się zwariować wyścigowi o jak najniższy LCP czy perfekcyjny wynik Lighthouse. Te metryki są ważne, ale tylko jako część większego obrazu. Jeśli Twoja aplikacja ma niski LCP, ale wysoki INP i TTI, użytkownicy i tak będą narzekać. Podobnie, CLS może zniweczyć pierwsze dobre wrażenie, gdy strona już się załaduje.

Kluczem jest monitorowanie rzeczywistej wydajności użytkowników (RUM) i koncentracja na wskaźnikach, które faktycznie korelują z behawiorem – INP, TTI, CLS. W JurskiTech zawsze doradzamy klientom, by zainwestowali w narzędzia takie jak Google Analytics z raportem Core Web Vitals, Sentry dla performance, lub własne skrypty zbierające metryki po stronie klienta.

Wydajność to nie sprint, to maraton. Ale startując z dobrymi metrykami, masz szansę dobiec na podium, zanim konkurencja w ogóle zda sobie sprawę, że ścigają się w złym kierunku.