Każda sekunda opóźnienia ma swoją cenę i nie ma tutaj jednej uniwersalnej kwoty — inaczej rozlicza się w sklepie z ruchem mobilnym, inaczej w B2B, a jeszcze inaczej na stronie firmowej zbierającej kilka leadów miesięcznie. Zadaniem zespołu jest wyliczyć tę stratę opierając ją na własnych danych, zanim zrobi to konkurencja.
Dla kogo jest ten artykuł? Dla właścicieli stron, marketerów i zespołów technicznych, które muszą uzasadnić inwestycję w performance konkretnymi liczbami. Nie chodzi o zaszczytne 100/100 w Lighthouse to narzędzie Google, które uruchamia techniczny test strony i wskazuje potencjalne problemy z wydajnością, SEO i dostępnością., tylko o znalezienie odpowiedzi na pytanie: ile pieniędzy zostawiasz na stole przez wolne ładowanie, opóźnioną reakcję interfejsu i skaczący layout?
Core Web Vitals jako metryki finansowe
Google opisuje Core Web Vitals to zestaw metryk Google oceniających realne doświadczenie użytkownika: LCP (szybkość ładowania), INP (responsywność) i CLS (stabilność wizualna). Wpływają na ranking i konwersję. jako zestaw metryk doświadczenia użytkownika, więc z perspektywy biznesu to trzy linie frontu, na których przegrywa się przychód:
- LCP, czyli Largest Contentful Paint, mierzy czas do wyrenderowania największego widocznego elementu — oznaczenie go preload przyspiesza jego załadowanie. — moment, w którym użytkownik faktycznie widzi główną treść.
- INP (Interaction to Next Paint) to Core Web Vital mierzący responsywność strony. Zastąpił FID i ocenia, ile czasu mija od interakcji użytkownika do najbliższego odrysowania ekranu, biorąc pod uwagę wszystkie interakcje w trakcie sesji. — czas, jaki strona potrzebuje, żeby zareagować na kliknięcie, tapnięcie albo wpisanie tekstu.
- CLS (Cumulative Layout Shift) to Core Web Vital mierzący nieoczekiwane przesunięcia elementów podczas ładowania i działania strony. Animacje psują go wtedy, gdy ruszają właściwości layoutowe albo gdy pojawiający się element nie ma zarezerwowanego miejsca. — skala, w jakiej interfejs ucieka pod palcem użytkownika.
Progi "good" według aktualnej dokumentacji Google: LCP do 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Werdykt zapada na 75. percentyl oznacza, że 75% użytkowników ma wynik taki sam lub lepszy, a 25% doświadcza gorszej wersji strony. danych terenowych — nie na pojedynczym teście z szybkiego laptopa w biurze. To różnica między oceną w warunkach laboratoryjnych a oceną na "polu walki".
Jak opóźnienie zamienia się w stratę
Mechanizm jest prosty, ale rzadko liczony do końca. Wolna strona strzela dwa razy — najpierw odsiewa użytkowników, którzy odpadają zanim zobaczą ofertę, potem dobija konwersję tych, którzy zostali, bo formularz, produkt albo CTA, czyli call to action, to przycisk lub link zachęcający do konkretnej akcji, np. wysłania formularza albo zakupu. pojawia się zbyt późno albo reaguje za wolno.
Performance nie jest wyłącznie zadaniem frontendu, ponieważ jeśli źródłem problemu jest ciężki motyw, wolny backend, niekontrolowane skrypty marketingowe albo obrazy bez właściwych rozmiarów — koszt ponosi cały lejek sprzedaży, od reklamy po finalizację zamówienia. To szalenie istotna sprawa, o której trzeba pamiętać.
Prosty wzór na koszt opóźnienia
Do wstępnej rozmowy wystarczy model scenariuszowy — twardy, jednoznaczny, gotowy do obrony przed zarządem:
Przykład: firma generuje 250 000 zł miesięcznie, a analiza pokazuje, że wolna strona zabiera 4% konwersji.
Ten wzór oczywiście nie jest precyzyjny, ale z grubsza daje obraz sytuacji, z której wykluwa się pytanie: czy opłaca się wydać 10 000 zł na audyt i poprawki, 40 000 zł na przebudowę frontendu albo więcej na pełną migrację?
Nie optymalizujesz sekundy, ale wartość ruchu, który już kupujesz albo zdobywasz organicznie.
Co pokazują wdrożenia
Najmocniejsze dowody pochodzą stamtąd, gdzie wydajność porównano w testach lub case studies — nie w samej korelacji. Materiały web.dev pokazują skalę, którą trudno zignorować:
- sprzedaży po 31% poprawie LCP w teście Vodafone
- +8%
- współczynnika konwersji po inwestycji Rakuten 24 w Core Web Vitals
- +33,13%
- porzuceń ładowania przy 70% lepszym LCP w Agrofy Market
- -76%
Oczywiście musimy mieć świadomość, że każdy projekt dostanie nieco inny zwrot. Dane jednak wyraźnie pokazują, że wydajność jest mierzalną dźwignią przychodu — najmocniejszą tam, gdzie ruch jest płatny, mobilny albo transakcyjny.
Co mierzyć przed decyzją o przebudowie
Zanim zlecisz migrację albo przepisywanie strony, zbierz minimalny pakiet rozpoznawczy:
- Dane terenowe pochodzą od prawdziwych użytkowników strony, a nie z jednego testu uruchomionego w narzędziu. z Google Search Console i PageSpeed Insights,
- rozkład urządzeń i źródeł ruchu w GA4,
- konwersję per źródło ruchu, szczególnie mobile i kampanie płatne,
- największy element LCP na najważniejszych szablonach,
- listę Skrypty 3rd-party pochodzą z zewnętrznych narzędzi, np. analityki, czatu, map, reklam albo heatmap. ładowanych przed interakcją użytkownika,
- TTFB, czyli Time To First Byte, mierzy czas od żądania do otrzymania pierwszego bajtu odpowiedzi z serwera. i zachowanie Cache przechowuje gotową odpowiedź lub zasób, żeby nie generować go od zera przy każdym wejściu użytkownika. dla stron ofertowych, kategorii i wpisów blogowych.
Kiedy wystarczy optymalizacja
Optymalizacja wystarcza, gdy problem jest lokalny: za duży obraz hero, brak width i height, fonty powodujące przesunięcia, za wcześnie ładowany czat, mapa albo narzędzie Heatmapa pokazuje, gdzie użytkownicy klikają, przewijają i zatrzymują uwagę na stronie.. To pojedyncze celne strzały, które są tańsze niż migracja, a efekty powinny nadejść po kilku tygodniach.
W Next.js standardowy arsenał to next/image, next/font, Code splitting to dzielenie kodu aplikacji na mniejsze paczki ładowane na żądanie, zamiast jednego wielkiego pliku. Next.js robi to automatycznie per trasa, więc użytkownik pobiera tylko kod potrzebny dla strony, którą faktycznie odwiedza., ograniczenie Client Components to komponenty React uruchamiane w przeglądarce użytkownika, więc zwiększają ilość JavaScriptu po stronie klienta. i przeniesienie tych najcięższych komponentów na serwer. Z kolei w Astro pilnujesz, żeby interaktywne wyspy nie oddziaływały na całą stronę i nie zaszkodziły jej własnym ciężarem.
Gdzie w tym rachunku pojawia się Astro
Astro nie jest „szybszym Next.js” ani uniwersalną odpowiedzią na każdy problem, ale jego przewaga pojawia się wtedy, gdy strona jest głównie związana z treścią. Może to być oferta usługowa, landing page PPC, blog, dokumentacja, baza wiedzy, strona lokalna albo katalog prostych podstron SEO. W takim układzie większość widoku może być zwykłym HTML-em, a JavaScript trafia tylko tam, gdzie naprawdę jest niezbędny.
To dobrze pasuje do rachunku kosztu sekundy, ponieważ wiele wolnych stron nie cierpi przez brak „mocniejszego frameworka”, tylko przez nadmiar kodu uruchamianego w przeglądarce. Jeśli strona ma przekonać użytkownika treścią, pokazać ofertę i zebrać lead, Astro pozwala zbudować lekki front bez płacenia za aplikacyjny runtime na każdej podstronie.
Najważniejsze są trzy scenariusze:
- migracja ciężkiego WordPressa albo page buildera na statyczne strony ofertowe,
- budowa landing page'y kampanijnych, gdzie każda sekunda wpływa na CAC,
- rozbudowa bloga lub content hubu bez dokładania JavaScriptu do każdego artykułu.
Astro nie zwalnia z myślenia o obrazach, fontach, analityce, formularzach i cache. Daje jednak dobry punkt startowy: mniej JavaScriptu domyślnie, prostszy model treści i wyraźną granicę między statyczną stroną a interaktywnym komponentem. Przy stronach marketingowych to często oznacza krótszą drogę do dobrego LCP, stabilniejszego CLS i niższego kosztu utrzymania.
Kiedy migracja ma sens
Migracja wchodzi do gry, gdy problem jest systemowy i tutaj odpowiednim przykładem jest klasyczny WordPress z niezliczoną ilością wtyczek, page builderem i powolnym hostingiem. Wymaga on ciągłej opieki, a każda kolejna optymalizacja łata tylko fragment frontu, ale nie rozwiązuje problemu systemowo. Co robisz wtedy? Zestawiasz koszt utrzymania obecnego systemu z kosztem przebudowy w Astro albo Next.js i podejmujesz odpowiednią decyzję na podstawie konkretnych liczb.
W praktyce wybór technologii zależy od tego, co ma robić strona po załadowaniu, ponieważ jeśli najważniejsze są szybkość, treść, SEO, formularz i kilka kontrolowanych interakcji, Astro jest naturalnym kandydatem. Natomiast w sytuacji, w której potrzebujesz panelu klienta, koszyka, personalizacji w czasie rzeczywistym, złożonego stanu aplikacji albo wielu ścieżek po stronie serwera, Next.js zwykle będzie rozsądniejszym wyborem.
Drugą stronę tego rachunku znajdziesz w kosztach utrzymania infrastruktury Astro i Cloudflare oraz w porównaniu Astro i Next.js pod landing page PPC.
