Czas ładowania kosztuje odwiedzających: Często cytowane badanie Google (DoubleClick, „The Need for Mobile Speed", 2016) wykazało, że 53% mobilnych wizyt jest przerywanych, jeśli ładowanie trwa dłużej niż 3 sekundy. Ta liczba nie jest już świeża, więcej powiedzą Ci Twoje własne dane w Analytics. Core Web Vitals są od 2021 roku oficjalnym czynnikiem rankingowym w wyszukiwarce Google. Na Google Ads wpływają tylko pośrednio: Google wskazuje szybsze ładowanie jako sposób na poprawę jakości strony docelowej, a ta jest jednym z trzech składników Quality Score Twoich Google Ads.
Czym są Core Web Vitals?
Core Web Vitals to trzy mierzalne metryki, których Google używa do oceny doświadczenia użytkownika na Twojej stronie:
LCP: Largest Contentful Paint
Co to: Jak długo trwa załadowanie największego widocznego elementu (obraz, wideo, blok tekstu)?
✅ Dobrze: ≤ 2,5 sekundy
⚠️ Wymaga poprawy: 2,5 – 4,0 sekundy
❌ Źle: > 4,0 sekundy
INP: Interaction to Next Paint
Co to: Jak szybko strona reaguje na akcje użytkownika (kliknięcie, dotknięcie, wpisanie)?
✅ Dobrze: ≤ 200 milisekund
⚠️ Wymaga poprawy: 200 – 500 milisekund
❌ Źle: > 500 milisekund
Dlaczego ważne: INP zastąpił FID (First Input Delay) jako Core Web Vital w 2024. Mierzy całą interaktywność, nie tylko pierwszą interakcję.
CLS: Cumulative Layout Shift
Co to: Jak bardzo przesuwają się widoczne elementy podczas ładowania?
✅ Dobrze: ≤ 0,1
⚠️ Wymaga poprawy: 0,1 – 0,25
❌ Źle: > 0,25
Wpływ na SEO i Google Ads
Rankingi SEO
Page Experience według Google Search Central:
Brak jednego sygnału rankingowego "Page Experience"
Core Web Vitals (LCP, INP, CLS) są używane
przez systemy rankingowe Google
Do tego punkty samooceny jak HTTPS, dobre wyświetlanie
na urządzeniach mobilnych, brak natrętnych interstitiali
→ Przy podobnie dobrych treściach:
Lepsze Page Experience może przeważyć szalę
Test zgodności z urządzeniami mobilnymi i raport „Obsługa na urządzeniach mobilnych” w Search Console Google wycofał pod koniec 2023 roku. Wyświetlanie na urządzeniach mobilnych sprawdzisz dziś na przykład w Lighthouse. Lighthouse pokazuje też wynik dostępności: dlaczego 100 oznacza tam tylko, że testy automatyczne niczego nie znalazły, wyjaśniam w artykule BFSG i dostępność stron docelowych.
Quality Score Google Ads
Landing Page Experience = jeden z trzech składników Quality Score
Wolna strona docelowa:
→ Odwiedzający odchodzą, zanim zobaczą ofertę
→ Słabsza jakość strony docelowej
→ Niższa jakość reklamy, zwykle wyższy CPC
→ Mniej kliknięć na budżet
Szybka strona docelowa:
→ Odwiedzający od razu widzą to, co obiecała reklama
→ Lepsza jakość strony docelowej
→ Wyższa jakość reklamy, zwykle niższy CPC
→ Więcej kliknięć na budżet
Przykład obliczeniowy (fikcyjne liczby, Quality Score nigdy nie zależy wyłącznie od czasu ładowania):
Te same słowa kluczowe, ta sama reklama, ten sam budżet:
Strona A: LCP 5,2s → Quality Score 5 → CPC: 19,80 PLN (~€4,50)
Strona B: LCP 1,8s → Quality Score 8 → CPC: 12,30 PLN (~€2,80)
Wynik: około 60% więcej kliknięć za ten sam budżet (19,80 PLN / 12,30 PLN)
Optymalizacja LCP
Najczęstsze problemy LCP
Problem 1: Nieskompresowane obrazy
❌ hero-image.jpg: 2,4 MB, 4000x3000px
→ Czas ładowania: 3,8 sekundy (na 4G)
✅ hero-image.webp: 120 KB, 1200x800px
→ Czas ładowania: 0,4 sekundy (na 4G)
Rozwiązanie:
<!-- Nowoczesny format + responsywne rozmiary -->
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="..." width="1200" height="800"
loading="eager" fetchpriority="high">
</picture>
Problem 2: CSS/JS blokujące renderowanie
Rozwiązanie:
<!-- Krytyczny CSS inline w head -->
<style>
/* Tylko CSS dla treści powyżej linii zagięcia */
.hero { ... }
.nav { ... }
</style>
<!-- Resztę załaduj asynchronicznie -->
<link rel="preload" href="/styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
Problem 3: Wolny serwer (TTFB)
Cele TTFB:
✅ Dobrze: < 200ms
⚠️ OK: 200-500ms
❌ Źle: > 500ms
Rozwiązanie:
- Użyj CDN (Cloudflare, Vercel Edge)
- Włącz cache po stronie serwera
- Zoptymalizuj zapytania do bazy danych
- Ulepsz hosting
Optymalizacja INP
Najczęstsze problemy INP
Problem 1: Ciężkie wykonywanie JavaScript
// ❌ Źle: Wszystko w głównym wątku
button.addEventListener('click', () => {
processLargeDataset(data); // 500ms ciężkie obliczenia
updateUI();
});
// ✅ Lepiej: Podziel z requestAnimationFrame
button.addEventListener('click', () => {
showLoadingState(); // UI aktualizuje się natychmiast
requestAnimationFrame(() => {
processLargeDataset(data);
updateUI();
});
});
Problem 2: Za dużo JavaScript firm trzecich
Typowe skrypty firm trzecich:
- Google Tag Manager: ~80KB
- Google Analytics: ~45KB
- Facebook Pixel: ~60KB
- Widget czatu: ~200KB
- Baner cookies: ~100KB
Łącznie: ~485KB JavaScript → zabójca INP!
Optymalizacja CLS
Najczęstsze problemy CLS
Problem 1: Obrazy bez wymiarów
<!-- ❌ Problem CLS: Obraz nie ma ustalonego rozmiaru -->
<img src="photo.jpg" alt="...">
<!-- ✅ Rozwiązanie: Podaj szerokość i wysokość -->
<img src="photo.jpg" alt="..." width="800" height="600">
Problem 2: Dynamicznie wstawiane treści
❌ Baner cookies wskakuje → wszystko się przesuwa
❌ Baner reklamowy ładuje się późno → treść skacze w dół
❌ Widget czatu pojawia się → układ się zmienia
Szybkie wygrane: Natychmiast wykonalne optymalizacje
1. Optymalizuj obrazy (Największa dźwignia!)
✅ Format: WebP lub AVIF zamiast JPEG/PNG
✅ Kompresja: 80% jakości zwykle wystarczy
✅ Responsywność: Różne rozmiary dla różnych ekranów
✅ Lazy loading: Lazy load obrazów poniżej viewportu
✅ Wymiary: Zawsze podawaj width/height
Narzędzie: squoosh.app (bezpłatne, w przeglądarce)
2. Optymalizuj CSS & JavaScript
✅ Krytyczny CSS inline w <head>
✅ Minifikuj CSS/JS
✅ Usuń nieużywany CSS/JS
✅ Ładuj skrypty z defer lub async
✅ Code splitting (ładuj tylko to co potrzebne)
3. Optymalizuj serwer
✅ Użyj CDN (Cloudflare, Vercel, Netlify)
✅ Ustaw nagłówki cache (Cache-Control)
✅ Włącz kompresję GZIP/Brotli
✅ Włącz HTTP/2 lub HTTP/3
4. Optymalizuj czcionki
✅ Ładuj tylko potrzebne warianty czcionek
✅ Używaj formatu WOFF2
✅ Ustaw font-display: swap lub optional
✅ Preload dla najważniejszych czcionek
Checklist: Optymalizacja Core Web Vitals
LCP ✅:
- Obraz hero skompresowany (WebP/AVIF, < 200KB)
- Krytyczny CSS inline
- Czcionki preloaded z font-display: swap
- CDN włączony
- TTFB < 200ms
INP ✅:
- JavaScript zminimalizowany i podzielony
- Skrypty firm trzecich zredukowane
- Ciężkie obliczenia przeniesione z głównego wątku
- Rozmiar DOM < 1.500 elementów
CLS ✅:
- Wszystkie obrazy/wideo z width/height
- Miejsce zarezerwowane na reklamy/banery
- Czcionki nie powodują przesunięcia układu
- Dynamiczne treści niczego nie przesuwają
Podsumowanie
Szybka strona = lepsze rankingi + niższe koszty Google Ads + więcej konwersji
Kolejność priorytetów:
- Optymalizuj obrazy (największa pojedyncza dźwignia)
- Wyeliminuj zasoby blokujące renderowanie
- Włącz CDN i caching
- Zredukuj i zoptymalizuj JavaScript
- Zapobiegaj CLS przez wymiary i rezerwację miejsca
Czego realnie możesz się spodziewać: Dobrze zoptymalizowana strona (wszystkie Core Web Vitals na zielono) pomaga Twoim rankingom i doświadczeniu strony docelowej, a przez to pośrednio także Twoim kosztom Google Ads. Stałych wartości procentowych nikt nie może Ci rzetelnie obiecać: ile to da, zależy od tego, jak wolna była wcześniej Twoja strona i jak silna jest konkurencja.
Twoja strona ładuje się zbyt wolno? Zarezerwuj bezpłatną 20-minutową rozmowę wstępną i opisz mi krótko swoją sytuację. Jeśli i tak planujesz relaunch, moje pakiety znajdziesz w zakładce Web Development.
FAQ o szybkości strony & Core Web Vitals
Czym są Core Web Vitals i dlaczego są ważne?
Core Web Vitals to trzy metryki zdefiniowane przez Google: LCP (szybkość ładowania), INP (czas reakcji) i CLS (stabilność wizualna). Mierzą faktyczne doświadczenie użytkownika na Twojej stronie. Od 2021 roku są oficjalnym czynnikiem rankingowym Google. Strony z dobrymi Core Web Vitals mają lepsze szanse na wyższe organiczne rankingi i niższe CPC Google Ads.
Jak zmierzyć moje Core Web Vitals?
Najlepiej przez PageSpeed Insights (pagespeed.web.dev): zobaczysz tam zarówno dane od prawdziwych użytkowników, jak i wyniki symulacji. Google Search Console pokazuje ogólną wydajność wszystkich URL-i. Do szczegółowych analiz: Chrome DevTools (zakładka Lighthouse). Wszystkie narzędzia są bezpłatne.
Jaka jest najważniejsza szybka wygrana dla lepszej wydajności?
Optymalizacja obrazów! To prawie zawsze największa pojedyncza dźwignia. Konwertuj obrazy na WebP lub AVIF, kompresuj do 80% jakości, używaj responsywnych rozmiarów (srcset) i lazy load obrazów poniżej viewportu. Jeśli hamulcem były duże, nieskompresowane obrazy, z mojej praktyki już samo to często wyraźnie poprawia LCP.
Czy Core Web Vitals wpływają na mój Quality Score Google Ads?
Pośrednio tak. Jakość strony docelowej (Landing Page Experience) jest jednym z trzech składników Quality Score, a Google wprost wymienia szybsze ładowanie jako sposób na jej poprawę. Wolna strona traci odwiedzających, zanim zobaczą Twoją ofertę, i osłabia właśnie ten składnik. Ponieważ Google uwzględnia jakość reklamy w każdej aukcji, a według Google reklamy o wyższej jakości zwykle kosztują mniej za kliknięcie, szybka strona docelowa może pośrednio obniżyć Twój CPC. O ile, zależy od Twojego konta i konkurencji.
Co zrobić gdy mój CMS (WordPress itp.) jest wolny?
5 natychmiastowych działań: 1) Zainstaluj plugin cache (WP Rocket, W3 Total Cache), 2) Automatycznie konwertuj obrazy na WebP (ShortPixel, Imagify), 3) Dezaktywuj i usuń nieużywane pluginy, 4) Włącz CDN (Cloudflare Free), 5) Zaktualizuj wersję PHP. Jeśli to nie wystarczy: ulepsz hosting ze współdzielonego na zarządzany WordPress hosting.
