53% użytkowników opuszcza stronę, jeśli ładuje się dłużej niż 3 sekundy. Każda kolejna sekunda obniża konwersję o 7%. Google uwzględnia szybkość strony w rankingu od 2021 roku (Core Web Vitals). Wolna strona to nie problem techniczny, to problem biznesowy.

Zacznij od pomiaru

Zanim cokolwiek naprawisz, zmierz. Nie zgaduj, dane powiedzą Ci dokładnie, co jest problemem:

PageSpeed Insights: ocena Core Web Vitals + konkretne rekomendacje
GTmetrix: waterfall chart, TTFB, czas ładowania
Chrome DevTools, zakładka Network: co się ładuje, jak długo, w jakiej kolejności

Kluczowe metryki:

Metryka	Dobra	Wymaga poprawy	Zła
LCP (Largest Contentful Paint)	< 2.5s	2.5-4s	> 4s
FID (First Input Delay)	< 100ms	100-300ms	> 300ms
CLS (Cumulative Layout Shift)	< 0.1	0.1-0.25	> 0.25
TTFB (Time To First Byte)	< 200ms	200-600ms	> 600ms

1. Wolny TTFB, problem po stronie serwera

TTFB (Time To First Byte) to czas od wysłania żądania do otrzymania pierwszego bajtu odpowiedzi. Jeśli TTFB przekracza 500ms, problem jest na serwerze, nie na froncie.

Przyczyny:

Tani hosting współdzielony (setki stron na jednym serwerze)
Wolna baza danych (brak indeksów, duże tabele wp_options)
Brak OPcache (PHP kompiluje kod przy każdym żądaniu)
Brak cache stron (WordPress generuje HTML od zera przy każdej wizycie)

Rozwiązania:

Zmiana hostingu na szybszy (NVMe SSD, dedykowane zasoby)
Optymalizacja bazy danych: wp db optimize, usunięcie autoloadowanych opcji
Włączenie OPcache w php.ini
Instalacja cache (WP Super Cache, W3 Total Cache, LiteSpeed Cache)

2. Nieskompresowane obrazki

Zdjęcie z aparatu waży 3-5 MB. Na stronie z 10 takimi zdjęciami użytkownik musi pobrać 50 MB. Na mobilnym LTE to 10-15 sekund samego ładowania obrazków.

Rozwiązania:

Format WebP lub AVIF (50-70% mniejsze niż JPEG)
Lazy loading: loading="lazy" na tagach <img>
Odpowiedni rozmiar: nie serwuj 4000px szerokości w boksie 400px
CDN dla mediów (Cloudflare, BunnyCDN)

# Konwersja do WebP (cwebp)
cwebp -q 80 input.jpg -o output.webp

# Masowa konwersja
find uploads/ -name "*.jpg" -exec cwebp -q 80 {} -o {}.webp \;

WordPress: wtyczka ShortPixel lub Imagify konwertuje automatycznie przy uploadzeniu.

3. Render-blocking CSS i JavaScript

Pliki CSS i JS w <head> blokują renderowanie strony. Przeglądarka musi je pobrać i przetworzyć zanim wyświetli cokolwiek.

Diagnoza: PageSpeed Insights, sekcja "Eliminate render-blocking resources"

Rozwiązania:

Critical CSS inline w <head>, reszta asynchronicznie
JavaScript z atrybutem defer lub async
Usunięcie nieużywanych stylów i skryptów

<!-- Zamiast -->
<link rel="stylesheet" href="style.css">

<!-- Non-blocking -->
<link rel="preload" href="style.css" as="style" onload="this.rel='stylesheet'">

4. Za dużo wtyczek

Każda wtyczka WordPress dodaje:

Pliki PHP (wykonywane przy każdym żądaniu)
Pliki CSS i JS (ładowane na froncie)
Zapytania do bazy danych

30 wtyczek to potencjalnie 30 plików CSS, 30 plików JS i 50+ zapytań SQL na każde wyświetlenie strony.

Rekomendacja: Przeprowadź audyt. Dla każdej wtyczki zadaj pytanie: "czy strona działa bez niej?". Dezaktywuj, przetestuj, usuń zbędne. Zostaw 10-15 naprawdę potrzebnych.

# Lista wtyczek z ilością zapytań DB (Query Monitor)
wp plugin install query-monitor --activate

5. Brak cache

Bez cache WordPress przy każdej wizycie:

Odbiera żądanie HTTP
Uruchamia PHP
Wykonuje 20-100 zapytań SQL
Buduje HTML
Zwraca odpowiedź

Z cache: serwer zwraca gotowy plik HTML. Różnica: z 2 sekund do 50 milisekund.

Warstwy cache:

Page cache: gotowy HTML (WP Super Cache, LiteSpeed Cache)
Object cache: wyniki zapytań DB w pamięci (Redis, Memcached)
OPcache: skompilowany PHP bytecode
CDN: statyczne pliki bliżej użytkownika

6. Ciężki motyw lub page builder

Elementor, WPBakery, Divi generują rozbudowany DOM. Prosta strona z nagłówkiem i trzema paragrafami może mieć 500+ elementów HTML i 200KB inline CSS.

Alternatywy:

Lżejsze motywy: GeneratePress, Kadence, Astra
Blokowy edytor Gutenberg (wbudowany, zero dodatkowego kodu)
Dedykowany motyw (najszybsza opcja, ale wymaga programisty)

Podsumowanie priorytetów

Priorytet	Działanie	Wpływ
1	Cache stron (page cache)	Największy skok wydajności
2	Optymalizacja obrazków (WebP + lazy load)	Drastyczne zmniejszenie transferu
3	Zmiana hostingu (jeśli TTFB > 500ms)	Rozwiązuje problem u źródła
4	Audyt wtyczek	Mniej zapytań DB i plików JS/CSS
5	Critical CSS + defer JS	Szybszy pierwszy render

Zacznij od pomiaru

Zanim cokolwiek naprawisz, zmierz. Nie zgaduj, dane powiedzą Ci dokładnie, co jest problemem:

PageSpeed Insights: ocena Core Web Vitals + konkretne rekomendacje
GTmetrix: waterfall chart, TTFB, czas ładowania
Chrome DevTools, zakładka Network: co się ładuje, jak długo, w jakiej kolejności

Kluczowe metryki:

Metryka	Dobra	Wymaga poprawy	Zła
LCP (Largest Contentful Paint)	< 2.5s	2.5-4s	> 4s
FID (First Input Delay)	< 100ms	100-300ms	> 300ms
CLS (Cumulative Layout Shift)	< 0.1	0.1-0.25	> 0.25
TTFB (Time To First Byte)	< 200ms	200-600ms	> 600ms

1. Wolny TTFB, problem po stronie serwera

TTFB (Time To First Byte) to czas od wysłania żądania do otrzymania pierwszego bajtu odpowiedzi. Jeśli TTFB przekracza 500ms, problem jest na serwerze, nie na froncie.

Przyczyny:

Tani hosting współdzielony (setki stron na jednym serwerze)
Wolna baza danych (brak indeksów, duże tabele wp_options)
Brak OPcache (PHP kompiluje kod przy każdym żądaniu)
Brak cache stron (WordPress generuje HTML od zera przy każdej wizycie)

Rozwiązania:

Zmiana hostingu na szybszy (NVMe SSD, dedykowane zasoby)
Optymalizacja bazy danych: wp db optimize, usunięcie autoloadowanych opcji
Włączenie OPcache w php.ini
Instalacja cache (WP Super Cache, W3 Total Cache, LiteSpeed Cache)

2. Nieskompresowane obrazki

Zdjęcie z aparatu waży 3-5 MB. Na stronie z 10 takimi zdjęciami użytkownik musi pobrać 50 MB. Na mobilnym LTE to 10-15 sekund samego ładowania obrazków.

Rozwiązania:

Format WebP lub AVIF (50-70% mniejsze niż JPEG)
Lazy loading: loading="lazy" na tagach <img>
Odpowiedni rozmiar: nie serwuj 4000px szerokości w boksie 400px
CDN dla mediów (Cloudflare, BunnyCDN)

# Konwersja do WebP (cwebp)
cwebp -q 80 input.jpg -o output.webp

# Masowa konwersja
find uploads/ -name "*.jpg" -exec cwebp -q 80 {} -o {}.webp \;

WordPress: wtyczka ShortPixel lub Imagify konwertuje automatycznie przy uploadzeniu.

3. Render-blocking CSS i JavaScript

Pliki CSS i JS w <head> blokują renderowanie strony. Przeglądarka musi je pobrać i przetworzyć zanim wyświetli cokolwiek.

Diagnoza: PageSpeed Insights, sekcja "Eliminate render-blocking resources"

Rozwiązania:

Critical CSS inline w <head>, reszta asynchronicznie
JavaScript z atrybutem defer lub async
Usunięcie nieużywanych stylów i skryptów

<!-- Zamiast -->
<link rel="stylesheet" href="style.css">

<!-- Non-blocking -->
<link rel="preload" href="style.css" as="style" onload="this.rel='stylesheet'">

4. Za dużo wtyczek

Każda wtyczka WordPress dodaje:

Pliki PHP (wykonywane przy każdym żądaniu)
Pliki CSS i JS (ładowane na froncie)
Zapytania do bazy danych

30 wtyczek to potencjalnie 30 plików CSS, 30 plików JS i 50+ zapytań SQL na każde wyświetlenie strony.

Rekomendacja: Przeprowadź audyt. Dla każdej wtyczki zadaj pytanie: "czy strona działa bez niej?". Dezaktywuj, przetestuj, usuń zbędne. Zostaw 10-15 naprawdę potrzebnych.

# Lista wtyczek z ilością zapytań DB (Query Monitor)
wp plugin install query-monitor --activate

5. Brak cache

Bez cache WordPress przy każdej wizycie:

Odbiera żądanie HTTP
Uruchamia PHP
Wykonuje 20-100 zapytań SQL
Buduje HTML
Zwraca odpowiedź

Z cache: serwer zwraca gotowy plik HTML. Różnica: z 2 sekund do 50 milisekund.

Warstwy cache:

Page cache: gotowy HTML (WP Super Cache, LiteSpeed Cache)
Object cache: wyniki zapytań DB w pamięci (Redis, Memcached)
OPcache: skompilowany PHP bytecode
CDN: statyczne pliki bliżej użytkownika

6. Ciężki motyw lub page builder

Elementor, WPBakery, Divi generują rozbudowany DOM. Prosta strona z nagłówkiem i trzema paragrafami może mieć 500+ elementów HTML i 200KB inline CSS.

Alternatywy:

Lżejsze motywy: GeneratePress, Kadence, Astra
Blokowy edytor Gutenberg (wbudowany, zero dodatkowego kodu)
Dedykowany motyw (najszybsza opcja, ale wymaga programisty)

Podsumowanie priorytetów

Priorytet	Działanie	Wpływ
1	Cache stron (page cache)	Największy skok wydajności
2	Optymalizacja obrazków (WebP + lazy load)	Drastyczne zmniejszenie transferu
3	Zmiana hostingu (jeśli TTFB > 500ms)	Rozwiązuje problem u źródła
4	Audyt wtyczek	Mniej zapytań DB i plików JS/CSS
5	Critical CSS + defer JS	Szybszy pierwszy render

Dlaczego Twoja strona wolno działa. Diagnoza i naprawa

Zacznij od pomiaru

1. Wolny TTFB, problem po stronie serwera

2. Nieskompresowane obrazki

3. Render-blocking CSS i JavaScript

4. Za dużo wtyczek

5. Brak cache

6. Ciężki motyw lub page builder

Podsumowanie priorytetów

Potrzebujesz pomocy?

Dlaczego Twoja strona wolno działa. Diagnoza i naprawa

Zacznij od pomiaru

1. Wolny TTFB, problem po stronie serwera

2. Nieskompresowane obrazki

3. Render-blocking CSS i JavaScript

4. Za dużo wtyczek

5. Brak cache

6. Ciężki motyw lub page builder

Podsumowanie priorytetów

Potrzebujesz pomocy?