Szybkość strony — jak poprawić czas ładowania i dlaczego to ważne
Każda sekunda opóźnienia w ładowaniu strony kosztuje Cię 7% konwersji. Strona, która ładuje się 5 sekund zamiast 1, traci niemal 30% potencjalnych klientów — zanim zobaczą jakąkolwiek treść. Szybkość to nie luksus. To fundament.
Szybkość strony to pieniądze — dosłownie
Nie musisz wierzyć na słowo. Oto twarde dane:
- Amazon odkrył, że 100ms opóźnienia kosztuje 1% sprzedaży. Przy ich skali to setki milionów dolarów rocznie.
- Google potwierdził, że szybkość strony jest czynnikiem rankingowym. Wolniejsze strony spadają w wynikach wyszukiwania.
- 53% użytkowników mobile opuszcza stronę, jeśli ładuje się dłużej niż 3 sekundy (Google Research).
- Walmart zanotował 2% wzrost konwersji za każdą sekundę poprawy czasu ładowania.
Dla przeciętnej firmy to oznacza jedno: szybkość strony bezpośrednio wpływa na liczbę klientów i przychody. Nie pośrednio, nie „może kiedyś" — bezpośrednio i mierzalnie.
A mimo to średnia strona firmowa w Polsce ładuje się 4-6 sekund na mobile. To jest 3-5 sekund za dużo.
Core Web Vitals — metryki, które naprawdę się liczą
Google od 2021 roku oficjalnie ocenia strony pod kątem trzech metryk zwanych Core Web Vitals. To nie jest „kolejna rzecz do optymalizacji". To czynnik rankingowy, który wpływa na Twoje pozycje w wynikach wyszukiwania.
LCP (Largest Contentful Paint) — czas do wyświetlenia głównej treści
Co mierzy: Ile czasu mija od kliknięcia linku do momentu, gdy największy element strony (nagłówek, obraz hero) jest widoczny na ekranie.
Cele:
| Wynik | Ocena |
|---|---|
| Do 2.5s | Dobry (zielony) |
| 2.5-4.0s | Wymaga poprawy (pomarańczowy) |
| Powyżej 4.0s | Słaby (czerwony) |
Najczęstsze przyczyny wolnego LCP:
- Duże, niezoptymalizowane obrazy (najczęstsza przyczyna)
- Wolna odpowiedź serwera (TTFB)
- Blokujący render CSS/JavaScript
- Brak preloadowania krytycznych zasobów
FID / INP (First Input Delay / Interaction to Next Paint) — responsywność
Co mierzy: Ile czasu mija od momentu, gdy użytkownik kliknie przycisk lub link, do momentu, gdy przeglądarka zacznie reagować. Od marca 2024 Google zastąpił FID bardziej wymagającą metryką INP (Interaction to Next Paint).
Cele INP:
| Wynik | Ocena |
|---|---|
| Do 200ms | Dobry |
| 200-500ms | Wymaga poprawy |
| Powyżej 500ms | Słaby |
Najczęstsze przyczyny wolnego INP:
- Ciężki JavaScript blokujący main thread
- Zbyt wiele event listenerów
- Duże frameworki (Angular, nieoptymalizowany React)
- Third-party skrypty (analityka, chat, remarketing)
CLS (Cumulative Layout Shift) — stabilność wizualna
Co mierzy: Czy elementy strony „skaczą" podczas ładowania. Klikasz przycisk „Wyślij", ale nagle ładuje się reklama nad nim i klikasz w nią zamiast w formularz.
Cele:
| Wynik | Ocena |
|---|---|
| Do 0.1 | Dobry |
| 0.1-0.25 | Wymaga poprawy |
| Powyżej 0.25 | Słaby |
Najczęstsze przyczyny wysokiego CLS:
- Obrazy bez zdefiniowanych wymiarów (width/height)
- Fonty, które zmieniają rozmiar tekstu po załadowaniu (FOUT)
- Dynamicznie wstrzykiwane treści (reklamy, popupy)
- Embedy bez zarezerwowanej przestrzeni
Jak sprawdzić szybkość swojej strony
Zanim zaczniesz optymalizować, musisz wiedzieć, gdzie stoisz. Trzy narzędzia, które musisz znać:
1. PageSpeed Insights (pagespeed.web.dev) Oficjalne narzędzie Google. Pokazuje wyniki Core Web Vitals, zarówno dane laboratoryjne (symulacja), jak i dane z pola (real user data). Zawsze patrz na dane mobilne — to na nich bazuje Google przy rankingu.
2. Google Search Console Sekcja „Core Web Vitals" pokazuje, ile Twoich stron spełnia progi, a ile nie. To widok na cały serwis, nie na pojedynczą stronę.
3. Lighthouse (w Chrome DevTools) Naciśnij F12 → zakładka Lighthouse → Generate report. Szczegółowa analiza z konkretnymi rekomendacjami. Pamiętaj: testuj w trybie incognito (rozszerzenia przeglądarki fałszują wyniki).
Optymalizacja obrazów — najszybszy sposób na przyspieszenie strony
Obrazy to najczęstsza przyczyna wolnego ładowania. Na przeciętnej stronie firmowej obrazy stanowią 50-70% całego rozmiaru strony. Optymalizacja obrazów to najszybszy i najłatwiejszy sposób na poprawę Core Web Vitals.
Format: WebP lub AVIF
| Format | Rozmiar (vs PNG) | Jakość | Wsparcie przeglądarek |
|---|---|---|---|
| PNG | 100% (bazowy) | Bezstratna | 100% |
| JPEG | 30-50% | Stratna | 100% |
| WebP | 25-35% | Stratna/bezstratna | 97%+ |
| AVIF | 15-25% | Stratna/bezstratna | 93%+ |
WebP to minimum w 2026 roku. Obraz, który w PNG waży 2MB, w WebP waży 500-700KB, a w AVIF 300-500KB — przy porównywalnej jakości wizualnej.
Responsywne obrazy (srcset)
Nie serwuj obrazu 2000px szerokości na telefonie z ekranem 375px. Użyj atrybutu srcset, żeby przeglądarka automatycznie dobrała odpowiedni rozmiar:
<img
src="hero-800.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, 50vw"
width="800" height="450"
alt="Opis obrazu"
loading="lazy"
/>
Lazy loading
Obrazy poniżej widocznego ekranu nie muszą się ładować od razu. Dodaj loading="lazy" — przeglądarka załaduje je dopiero, gdy użytkownik zbliży się do nich scrollem.
Wyjątek: Obraz hero (LCP element) powinien mieć loading="eager" lub fetchpriority="high" — musi się załadować jak najszybciej.
Wymiary obrazów
Zawsze definiuj width i height w HTML. Bez tego przeglądarka nie wie, ile miejsca zarezerwować, i content „skacze" po załadowaniu obrazu (CLS).
JavaScript — cichy zabójca szybkości
Obrazy są widocznym problemem. JavaScript jest niewidocznym, ale często poważniejszym. Średnia strona firmowa ładuje 500KB-2MB JavaScriptu, z czego połowa to third-party skrypty (analityka, remarketing, chat, social media).
Audyt JavaScriptu
Otwórz Chrome DevTools → Network → filtruj JS. Posortuj po rozmiarze. Zdziwisz się, ile ładujesz i jak mało z tego naprawdę potrzebujesz.
Konkretne techniki redukcji
1. Lazy loading third-party skryptów. Google Analytics, Facebook Pixel, Hotjar — nie muszą się ładować natychmiast. Załaduj je po interakcji użytkownika (scroll, kliknięcie) lub z opóźnieniem 3-5 sekund.
2. Code splitting. Nie ładuj całej aplikacji na każdej stronie. Next.js i Astro robią to automatycznie — każda strona ładuje tylko kod, którego potrzebuje.
3. Tree shaking. Importujesz całą bibliotekę, żeby użyć jednej funkcji? Nowoczesne bundlery (webpack, esbuild, Rollup) usuwają nieużywany kod — ale tylko jeśli importujesz selektywnie: import { debounce } from 'lodash-es', nie import _ from 'lodash'.
4. Usunięcie nieużywanych skryptów. Zainstalowałeś czat, ale go wyłączyłeś? Skrypt nadal się ładuje. Miałeś kampanię remarketingową 2 lata temu? Pixel nadal trackuje. Wyczyść.
5. Zamiana frameworka na lżejszy. Jeśli Twoja strona to głównie statyczny content (blog, landing page), nie potrzebujesz React z 140KB runtime. Astro wysyła 0KB JavaScript domyślnie. Next.js z 'use client' tylko tam, gdzie trzeba — to rozsądny kompromis.
Serwer i hosting — fundament, którego nie przeskoczysz
Możesz optymalizować obrazy i JavaScript do perfekcji, ale jeśli serwer odpowiada po 2 sekundach — nic nie pomoże.
TTFB (Time to First Byte)
To czas od żądania przeglądarki do pierwszego bajta odpowiedzi serwera. Cel: poniżej 200ms.
| Typ hostingu | Typowe TTFB | Komentarz |
|---|---|---|
| Shared hosting (najtańszy) | 500-2000ms | Współdzielone zasoby, nieprzewidywalna wydajność |
| VPS | 100-500ms | Dedykowane zasoby, trzeba samemu zarządzać |
| CDN + static hosting | 20-100ms | Pliki serwowane z najbliższego edge location |
| Vercel / Netlify | 30-80ms | Automatyczny CDN, idealne dla Next.js/Astro |
Jeśli Twoja strona jest statyczna (SSG), CDN to gamechanger. Zamiast jednego serwera w Warszawie, Twoja strona jest serwowana z dziesiątek lokalizacji na świecie. Użytkownik w Krakowie dostaje pliki z Krakowa, nie z Amsterdamu.
Kompresja: gzip vs Brotli
Serwer powinien kompresować odpowiedzi. Brotli kompresuje o 15-20% lepiej niż gzip i jest wspierany przez 97%+ przeglądarek.
HTTP/2 i HTTP/3
HTTP/2 pozwala na pobieranie wielu plików jednocześnie (multiplexing). HTTP/3 dodaje QUIC — szybsze nawiązywanie połączenia. Większość nowoczesnych hostingów wspiera oba. Jeśli Twój hosting nadal używa HTTP/1.1 — zmień hosting.
Fonty — detal, który robi różnicę
Fonty to subtelna, ale realna przyczyna problemów z CLS i LCP.
Problem: FOUT i FOIT
- FOUT (Flash of Unstyled Text): Tekst wyświetla się w foncie systemowym, potem przeskakuje na custom font. Powoduje CLS.
- FOIT (Flash of Invisible Text): Tekst jest niewidoczny do momentu załadowania fontu. Użytkownik widzi pustą stronę.
Rozwiązania
1. font-display: swap — wyświetl tekst natychmiast w foncie systemowym, zamień na custom font po załadowaniu. Eliminuje FOIT.
2. Preload krytycznych fontów:
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
3. Ogranicz liczbę fontów. Maksymalnie 2 fonty (nagłówki + body text). Każdy dodatkowy font to dodatkowe 20-100KB do załadowania.
4. Używaj formatów WOFF2. WOFF2 kompresuje o 30% lepiej niż WOFF. Nie ładuj TTF ani OTF w przeglądarce.
5. Subset fontów. Jeśli używasz polskich znaków — załaduj tylko Latin Extended, nie wszystkie 5000 glifów.
CSS — optymalizacja, o której się zapomina
CSS rzadko jest głównym winowajcą, ale potrafi obniżyć wyniki.
1. Critical CSS inline. Styl potrzebny do renderowania above-the-fold powinien być w tagu <style> w <head>, nie w zewnętrznym pliku. Eliminuje render-blocking CSS.
2. Usunięcie nieużywanego CSS. Typowa strona na WordPressie ładuje 200-500KB CSS, z czego 70%+ jest nieużywane. Narzędzia: PurgeCSS, Coverage tab w Chrome DevTools.
3. Minimalizacja. cssnano, clean-css — usuwają komentarze, białe znaki, skracają nazwy kolorów. 15-30% redukcji rozmiaru.
4. Unikanie @import. @import w CSS powoduje sekwencyjne ładowanie (waterfall). Użyj <link> w HTML lub bundluj CSS w build step.
Checklist optymalizacji szybkości
Przejdź przez tę listę punkt po punkcie:
Obrazy:
- Format WebP lub AVIF
- Responsywne rozmiary (srcset)
- Lazy loading na obrazach poniżej fold
- Zdefiniowane width/height
- Hero image z fetchpriority="high"
JavaScript:
- Third-party skrypty ładowane z opóźnieniem
- Code splitting (każda strona ładuje tylko swój kod)
- Brak nieużywanych skryptów
- Bundle size poniżej 200KB (gzipped)
Serwer:
- TTFB poniżej 200ms
- Kompresja Brotli
- HTTP/2 lub HTTP/3
- CDN
Fonty:
- Max 2 fonty
- Format WOFF2
- font-display: swap
- Preload krytycznych fontów
CSS:
- Critical CSS inline
- Usunięcie nieużywanego CSS
- Minimalizacja
Cele:
- LCP poniżej 2.5s na mobile
- INP poniżej 200ms
- CLS poniżej 0.1
- Lighthouse Performance 90+ na mobile
Szybkość a SEO — dlaczego Google obchodzi, jak szybko ładuje się Twoja strona
Google oficjalnie potwierdza, że szybkość strony jest czynnikiem rankingowym. Ale wpływ jest subtelniejszy, niż myślisz.
Bezpośredni wpływ: Core Web Vitals to jeden z wielu sygnałów rankingowych. Przy porównywalnej jakości treści, szybsza strona wygrywa.
Pośredni wpływ (ważniejszy): Wolna strona → wyższy bounce rate → krótszy czas na stronie → niższy CTR na wynikach → Google interpretuje to jako „niską jakość" → pozycje spadają. To efekt domina.
Crawl budget: Google ma ograniczony czas na crawlowanie Twojej strony. Jeśli każda strona odpowiada po 3 sekundach, Google zaindeksuje mniej stron niż przy odpowiedzi 200ms. Szczególnie istotne dla dużych serwisów. Więcej o tym w naszym artykule o podstawach SEO i audycie SEO.
Podsumowanie — szybkość to nie optymalizacja, to standard
W 2026 roku szybka strona nie jest przewagą konkurencyjną — wolna strona jest wadą. Użytkownicy oczekują, że strona załaduje się w mniej niż 2 sekundy. Google oczekuje, że Core Web Vitals będą na zielono. Każda sekunda opóźnienia to realna strata klientów i pozycji.
Dobra wiadomość: większość problemów z szybkością da się rozwiązać w 1-2 dni. Optymalizacja obrazów, lazy loading, CDN — to nie rocket science. To higiena.
Chcesz wiedzieć, ile tracisz przez wolną stronę? Zamów bezpłatny audyt szybkości — sprawdzimy Core Web Vitals Twojej strony i pokażemy konkretne miejsca do poprawy.