Strony internetowe tyją

Mediana rozmiaru strony internetowej w 2025 roku przekracza 2,5 MB na urządzeniach mobilnych. Dla porównania, w 2015 roku było to około 1 MB, a w 2010 — poniżej 500 KB. Strony rosną, bo dodajemy coraz więcej: frameworki JavaScript, biblioteki UI, fonty, obrazy w wysokiej rozdzielczości, skrypty analityczne, widgety czatu, piksele reklamowe.

Problem polega na tym, że przepustowość sieci i moc urządzeń nie rosną w tym samym tempie, szczególnie poza wielkimi miastami i na rynkach rozwijających się. Strona ważąca 3 MB ładuje się komfortowo na światłowodzie, ale na połączeniu LTE w terenie — już niekoniecznie.

Performance budget to ustalony z góry limit na rozmiar i czas ładowania strony, którego zespół zobowiązuje się nie przekraczać. To narzędzie dyscypliny — każda nowa funkcja, każdy dodany skrypt musi zmieścić się w budżecie.

Jak ustalić budżet

Nie istnieje jeden uniwersalny budżet. Zależy on od grupy docelowej, typu strony i konkurencji. Ale istnieją sensowne punkty wyjścia.

Budżet wagowy — łączny rozmiar zasobów przesyłanych do przeglądarki:

  • HTML — poniżej 50 KB (po kompresji gzip)
  • CSS — poniżej 50 KB
  • JavaScript — poniżej 200 KB (to najbardziej kosztowny zasób — musi być pobrany, sparsowany i wykonany)
  • Obrazy — poniżej 500 KB łącznie (powyżej linii zawijania, tj. widocznej części strony)
  • Fonty — poniżej 100 KB (1-2 warianty jednego kroju)
  • Łącznie — poniżej 1 MB na pierwsze załadowanie

Te wartości pozwalają osiągnąć czas ładowania poniżej 3 sekund na połączeniu 3G (1,6 Mb/s) — standard, który Google uznaje za akceptowalny.

Budżet czasowy — metryki Web Vitals, które Google używa w rankingu:

  • LCP (Largest Contentful Paint) — poniżej 2,5 sekundy. To czas, po którym największy widoczny element (zwykle obraz lub nagłówek) jest w pełni wyrenderowany.
  • FID / INP (Interaction to Next Paint) — poniżej 200 milisekund. Czas od interakcji użytkownika (kliknięcie, dotknięcie) do odpowiedzi interfejsu.
  • CLS (Cumulative Layout Shift) — poniżej 0,1. Miara stabilności wizualnej — jak bardzo elementy strony przeskakują podczas ładowania.

Budżet żądaniowy — liczba żądań HTTP na pierwsze załadowanie strony. Zalecamy utrzymanie poniżej 30 żądań. Każde żądanie, nawet małe, to narzut na negocjację połączenia, DNS lookup i transfer nagłówków.

Co pożera budżet

JavaScript jest największym wrogiem wydajności. Nie dlatego, że pliki JS są największe (obrazy zwykle wygrywają wagowo), ale dlatego, że JavaScript musi być pobrany, sparsowany, skompilowany i wykonany — każdy z tych kroków zużywa czas i CPU. 200 KB JavaScriptu jest znacznie kosztowniejsze niż 200 KB obrazów.

Typowe źródła nadmiarowego JS:

  • Frameworki SPA (React, Angular) — często 100-300 KB samego frameworka, zanim dodamy kod aplikacji
  • Biblioteki UI (Material UI, Ant Design) — kolejne 100-200 KB
  • Skrypty analityczne (Google Analytics, Hotjar, Facebook Pixel) — 50-150 KB łącznie
  • Widgety czatu (Intercom, LiveChat) — 100-200 KB

Sam framework React z ReactDOM to około 130 KB (gzip). Dodajmy router, state management, bibliotekę UI — łatwo przekroczyć 500 KB JavaScriptu, nie napisawszy ani linii kodu biznesowego.

Obrazy to drugi największy konsument budżetu. Niezoptymalizowany PNG prosto z Photoshopa może ważyć 2-5 MB. Rozwiązania:

  • Format WebP lub AVIF zamiast PNG/JPEG — oszczędność 30-50%
  • Lazy loading — ładowanie obrazów poza widocznym obszarem dopiero przy scrollowaniu
  • Responsywne obrazy (srcset) — serwowanie mniejszych wersji na mniejsze ekrany
  • Kompresja — narzędzia jak Sharp, Squoosh czy ImageOptim

Fonty webowe potrafią dodać 200-400 KB, jeśli załadujemy pełny krój z wieloma wariantami. Rozwiązanie: font-display: swap (tekst widoczny natychmiast, font podmieniony po załadowaniu), subsetting (ładowanie tylko potrzebnych znaków) i ograniczenie do 1-2 wariantów.

Narzędzia do monitorowania

Lighthouse — wbudowany w Chrome DevTools audyt wydajności. Generuje raport z metrykami Web Vitals, identyfikuje problemy i sugeruje poprawki. Dostępny też jako CLI do integracji z CI/CD.

PageSpeed Insights (pagespeed.web.dev) — narzędzie Google łączące dane laboratoryjne (Lighthouse) z danymi polowymi (Chrome User Experience Report). Pokazuje, jak prawdziwi użytkownicy doświadczają Twojej strony.

WebPageTest (webpagetest.org) — zaawansowane testy z różnych lokalizacji, przeglądarek i prędkości połączenia. Generuje waterfall chart pokazujący kolejność i czas ładowania każdego zasobu.

bundlewatch i bundlephobia — narzędzia do monitorowania rozmiaru bundli JavaScript. Bundlewatch integruje się z CI/CD i blokuje merge, gdy rozmiar przekroczy limit. Bundlephobia (bundlephobia.com) pokazuje rozmiar pakietu npm przed jego zainstalowaniem.

Chrome DevTools / Network tab — najbardziej podstawowe narzędzie. Pozwala zobaczyć rozmiar każdego zasobu, czas ładowania i waterfall. Tryb throttling symuluje wolniejsze połączenia.

Egzekwowanie budżetu

Ustalenie budżetu bez mechanizmu egzekwowania to pobożne życzenie. Kilka sprawdzonych strategii:

  • Automatyczne testy w CI/CD — Lighthouse CI uruchamiany przy każdym pull requeście, blokujący merge przy przekroczeniu progów
  • Alerty — powiadomienia, gdy metryki produkcyjne spadną poniżej ustalonego poziomu
  • Przeglądy kodu — każda nowa zależność JavaScript wymaga uzasadnienia i analizy wpływu na budżet
  • Regularne audyty — comiesięczny przegląd rozmiaru strony i trendów

Podsumowanie

Performance budget to nie ograniczenie — to gwarancja jakości dla użytkowników. Strona, która ładuje się poniżej 2 sekund, nie tylko lepiej konwertuje, ale też zajmuje wyższe pozycje w Google i buduje profesjonalny wizerunek.

Nasze strony firmowe ważą poniżej 200 KB łącznie i ładują się w ułamku sekundy — bo serwujemy statyczny HTML z serwera Go, bez frameworków JS i z zoptymalizowanymi zasobami. Chcesz wiedzieć, ile waży Twoja strona i co można poprawić? Skontaktuj się z nami — przeprowadzimy bezpłatny audyt wydajności.