Optymalizacja Google PageSpeed - checklista

Dlaczego PageSpeed wpływa na SEO i konwersję

Szybkość strony internetowej to nie tylko kwestia komfortu użytkownika - to fundamentalny czynnik wpływający zarówno na pozycję w wynikach wyszukiwania Google, jak i na konwersję.

Google oficjalnie potwierdził, że Page Experience (w tym Core Web Vitals) jest czynnikiem rankingowym. Strony, które ładują się szybciej, mają wyższe pozycje w SERP (Search Engine Results Pages).

Wpływ na konwersję - liczby nie kłamią

Badania pokazują dramatyczny wpływ czasu ładowania na biznes:

• 1 sekunda opóźnienia = 7% mniej konwersji (Amazon research)
• Strony ładujące się powyżej 3 sekund tracą 53% użytkowników (Google)
• Poprawa prędkości o 0.1s zwiększa konwersję o 8% (Deloitte)
• Pinterest zmniejszył czas ładowania o 40% = 15% więcej organicznego ruchu

Dla e-commerce każda sekunda to dosłownie pieniądze. Strona generująca 100 000 zł dziennie może stracić 2.5 mln zł rocznie przez opóźnienie 1 sekundy.

Mobile-first indexing

Od 2021 Google domyślnie indeksuje wersje mobilne stron. Oznacza to, że:

• Wydajność na urządzeniach mobilnych jest kluczowa
• Strona wolna na mobile = niska pozycja w Google (nawet jeśli desktop jest szybki)
• Optymalizacja pod 3G/4G (nie tylko WiFi) jest obowiązkowa

User Experience = Business Success

Szybka strona to:

• Wyższe pozycje w Google (więcej organicznego ruchu)
• Niższy bounce rate (użytkownicy zostają)
• Więcej konwersji (szybszy checkout = więcej sprzedaży)
• Lepsza reputacja marki (profesjonalizm)
• Niższe koszty reklam (wyższy Quality Score w Google Ads)

Czym są wskaźniki Core Web Vitals

Core Web Vitals to 3 kluczowe metryki Google mierzące rzeczywiste doświadczenie użytkownika:

1. LCP - Largest Contentful Paint

Co mierzy: Czas do wyświetlenia największego elementu na stronie (zazwyczaj hero image lub główny nagłówek)

Standardy:

• Dobry: < 2.5s
• Wymaga poprawy: 2.5s - 4s
• Słaby: > 4s

Jak poprawić:

• Optymalizacja obrazów (WebP/AVIF, odpowiedni rozmiar)
• Preload kluczowych zasobów
• Szybszy serwer (hosting)
• CDN dla statycznych plików
• Usunięcie render-blocking resources

2. FID - First Input Delay (obecnie INP - Interaction to Next Paint)

Co mierzy: Czas od pierwszej interakcji użytkownika (klik, tap) do reakcji przeglądarki

Standardy (INP):

• Dobry: < 200ms
• Wymaga poprawy: 200ms - 500ms
• Słaby: > 500ms

Jak poprawić:

• Minimalizacja JavaScript
• Code splitting (ładowanie JS tylko gdy potrzebny)
• Web Workers (przeniesienie obliczeń poza main thread)
• Debouncing/throttling event handlerów
• Usunięcie niepotrzebnych bibliotek JS

3. CLS - Cumulative Layout Shift

Co mierzy: Stabilność wizualna strony (czy elementy "skaczą" podczas ładowania)

Standardy:

• Dobry: < 0.1
• Wymaga poprawy: 0.1 - 0.25
• Słaby: > 0.25

Jak poprawić:

• Definiowanie width/height dla obrazów i video
• Rezerwowanie miejsca dla dynamic content (reklamy, embeds)
• Preload fontów (unikanie FOIT/FOUT)
• Unikanie wstawiania treści powyżej istniejącej (unless triggered by user)

Gdzie sprawdzić Core Web Vitals?

• Google PageSpeed Insights: pagespeed.web.dev
• Google Search Console: Raport "Page Experience"
• Chrome DevTools: Zakładka Lighthouse
• Web Vitals Extension: Chrome Extension od Google

Optymalizacja obrazów (formaty WebP/AVIF, lazy load)

Obrazy to często 50-70% całkowitego rozmiaru strony - ich optymalizacja ma największy wpływ na PageSpeed.

1. Nowoczesne formaty obrazów

WebP - 30% mniejsze pliki niż JPEG/PNG

• Obsługa: 96%+ przeglądarek (2025)
• Stratna i bezstratna kompresja
• Wsparcie dla przezroczystości

AVIF - 50% mniejsze pliki niż JPEG

• Obsługa: 85%+ przeglądarek
• Najlepsza kompresja, ale wolniejsze kodowanie
• Idealne dla hero images

Implementacja z fallback:

2. Lazy Loading - ładowanie obrazów on-demand

Native lazy loading:

Przeglądarki automatycznie ładują obrazy dopiero gdy zbliżają się do viewport.

Uwaga: NIE stosuj lazy loading dla:

• Hero images (above the fold)
• Logo
• Obrazów krytycznych dla LCP

3. Responsive images - srcset i sizes

Zamiast ładować 3000px obraz na mobile 375px:

Przeglądarka automatycznie wybiera optymalny rozmiar dla urządzenia.

4. Kompresja obrazów - narzędzia

• ImageOptim (Mac): bezstratna kompresja
• Squoosh (web): squoosh.app - Google tool
• TinyPNG/TinyJPG: tinypng.com
• Sharp (Node.js): automatyzacja w build process

5. Preload hero image

Dla obrazu wyświetlanego od razu (above the fold):

Minimalizacja CSS, JS i HTML

Dlaczego minimalizacja jest ważna?

Niezoptymalizowany kod to:

• Białe znaki, wcięcia, komentarze = zbędne bajty
• Długie nazwy zmiennych = większy plik
• Nieużywane style/funkcje = marnowany bandwidth

Efekt minimalizacji: 30-60% mniejsze pliki

1. Minimalizacja CSS

Narzędzia:

• cssnano: autoprefixer + minifikacja
• PurgeCSS: usuwa nieużywane style
• clean-css: standalone minifier

Przykład z PurgeCSS (Next.js/Tailwind):

// tailwind.config.js
module.exports = {
  purge: ['./src/**/*.{js,jsx,ts,tsx}'],
  // Bootstrap CSS: 150kB → 15kB po purge
}

2. Minimalizacja JavaScript

Narzędzia:

• Terser: standard w Webpack/Vite
• esbuild: ultra-szybka minifikacja
• UglifyJS: legacy projects

Tree shaking - usuwanie dead code:

// Zamiast:
import _ from 'lodash'; // Cała biblioteka: 500kB

// Lepiej:
import debounce from 'lodash/debounce'; // Tylko funkcja: 5kB

3. Code splitting - ładuj tylko to, co potrzebne

Route-based splitting (React/Next.js):

import dynamic from 'next/dynamic';

const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => 
Loading...
});

// HeavyComponent ładuje się tylko gdy komponent jest renderowany

4. Minimalizacja HTML

Narzędzia:

• html-minifier: dla static sites
• Next.js / Vite: automatyczna minifikacja w production

Oszczędność: 10-20% rozmiaru HTML (białe znaki, komentarze)

5. Critical CSS - inline above-the-fold styles

Above-the-fold content renderuje się natychmiast. Pozostałe style ładują asynchronicznie.

Kompresja GZIP/Brotli i cache przeglądarki

1. Kompresja GZIP/Brotli - 70-90% mniejsze pliki

GZIP (standard)

• Obsługa: 100% przeglądarek
• Kompresja: 70-80%
• Szybka

Brotli (Google, nowszy)

• Obsługa: 95%+ przeglądarek
• Kompresja: 80-90% (lepiej niż GZIP)
• Nieco wolniejsza, ale warto

Przykład: HTML 100kB – Brotli 15kB

Konfiguracja serwera (Apache .htaccess):

# Brotli (jeśli dostępny)

  AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/javascript application/javascript


# GZIP (fallback)

  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript

Nginx:

gzip on;
gzip_types text/css application/javascript image/svg+xml;
gzip_min_length 1000;

2. Browser Cache - nie pobieraj tego samego dwa razy

Cache-Control headers (Apache):

  ExpiresActive On

  # Images
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"

  # CSS/JS
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"

  # HTML (nie cachuj)
  ExpiresByType text/html "access plus 0 seconds"

Versioning - cache busting:

3. Service Workers - offline-first caching

Progressive Web Apps (PWA) mogą cachować zasoby lokalnie:

// service-worker.js
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      return response || fetch(event.request);
    })
  );
});

Optymalizacja fontów i preload

Problem: Web Fonts blokują renderowanie

FOIT (Flash of Invisible Text): Tekst niewidoczny podczas ładowania fontu

FOUT (Flash of Unstyled Text): Tekst wyświetla się w fallback font, potem zmienia

1. Preload fontów - priorytetowe ładowanie

Przeglądarka ładuje font od razu, nie czeka na parsowanie CSS.

2. font-display: swap - FOUT zamiast FOIT

@font-face {
  font-family: 'Inter';
  src: url('/fonts/Inter-Regular.woff2') format('woff2');
  font-display: swap; /* Pokazuj tekst natychmiast w fallback font */
}

3. Subsetting - usuń nieużywane glify

Pełny font Inter: 300kB. Tylko Latin + cyfry + podstawowe znaki: 40kB.

Narzędzia:

• glyphhanger: automatyczne subsetting
• Google Fonts: parametr ?text= (tylko wybrane znaki)

4. Variable Fonts - jeden plik zamiast wielu

Zamiast:

• Inter-Regular.woff2 (40kB)
• Inter-Medium.woff2 (42kB)
• Inter-Bold.woff2 (43kB)
• Razem: 125kB

Variable Font:

• Inter-Variable.woff2 (65kB) - wszystkie wagi w jednym pliku

5. Self-hosting vs Google Fonts

Google Fonts (CDN):

• + łatwe w użyciu
• + Caching cross-site (jeśli ktoś ma font z innej strony)
• - Dodatkowe DNS lookup
• - GDPR concerns (data do Google)

Self-hosting:

• + Pełna kontrola
• + Preconnect/preload możliwe
• + GDPR-friendly
• - Musisz zarządzać plikami

W 2025: self-hosting + preload + woff2 = najszybsze

Eliminacja blokujących zasobów renderowania

Czym są render-blocking resources?

Zasoby, które blokują wyświetlenie strony:

• CSS w (blokuje renderowanie całej strony)
• Synchroniczny JavaScript w
• Web fonts (jeśli nie mają font-display: swap)

1. Async i defer dla JavaScript

Bez optymalizacji (blokuje renderowanie):

Defer (ładuje asynchronicznie, wykonuje po DOMContentLoaded):

Async (ładuje i wykonuje asynchronicznie, ASAP):

Best practice:

• defer: dla skryptów potrzebnych do interakcji ze stroną
• async: dla niezależnych skryptów (analytics, ads)

2. Critical CSS inline + async load reszty

3. Preconnect do external domains

Jeśli ładujesz zasoby z CDN/Google Fonts:

DNS lookup + TLS handshake wykonują się wcześniej.

4. Resource Hints - dns-prefetch, prefetch, prerender

• dns-prefetch: Rozwiązuje DNS, ale nie łączy (lżejsze niż preconnect)
• prefetch: Pobiera zasób w tle (dla następnej strony)
• prerender: Renderuje całą stroną w tle (dla bardzo prawdopodobnej nawigacji)

CDN i geolokalizacja treści

Czym jest CDN (Content Delivery Network)?

Sieć serwerów rozmieszczonych globalnie, które cachują statyczne pliki (obrazy, CSS, JS) blisko użytkownika.

Dlaczego CDN przyspiesza stronę?

• Niższa latencja: Użytkownik w Warszawie łączy się z serwerem we Frankfurcie (10ms), nie w San Francisco (150ms)
• Offload serwera: Twój hosting nie musi obsługiwać requestów o obrazy/CSS
• HTTP/2 + HTTP/3: CDN automatycznie używają najnowszych protokołów
• DDoS protection: Bonus - ochrona przed atakami

Najpopularniejsze CDN w 2025

1. Cloudflare (darmowy plan)

• Darmowy dla stron małych/średnich
• Auto-minifikacja CSS/JS
• Brotli compression
• 285 lokalizacji

2. BunnyCDN (płatny, tani)

• 3,69 zł/TB (bardzo tani)
• świetna wydajność w Europie
• Edge storage (hosting obrazów na CDN)

3. Cloudinary (obrazy/video)

• Automatyczna konwersja do WebP/AVIF
• On-the-fly image resizing
• Lazy load + responsive images out-of-the-box

4. Vercel Edge Network (dla Next.js/Vercel apps)

• Automatyczny CDN dla deploymentów
• Edge Functions (serverless na CDN)

Implementacja CDN - przykład

Bez CDN:

Z CDN:

WordPress + CDN

Wtyczki automatyczne:

• W3 Total Cache: integracja z Cloudflare/BunnyCDN
• WP Rocket: automatyczne przepisywanie URL do CDN

Server response time – hosting i konfiguracja

TTFB (Time To First Byte) - kluczowa metryka

TTFB to czas od requestu do pierwszego bajtu odpowiedzi serwera.

Standardy:

• Dobry: < 200ms
• Średni: 200-500ms
• Słaby: > 500ms

1. Wybór hostingu - nie oszczędzaj

Shared Hosting (tani, wolny)

• TTFB: 500-1500ms
• Cena: 20-50 zł/mies
• Problem: dzielisz zasoby z setkami innych stron

VPS (dobry balans)

• TTFB: 100-300ms
• Cena: 100-300 zł/mies
• Dedykowane zasoby CPU/RAM

Cloud Hosting (AWS, Google Cloud, DigitalOcean)

• TTFB: 50-150ms
• Cena: od 50 zł/mies (skalowalny)
• Auto-scaling pod obciążeniem

Managed WordPress Hosting (WP Engine, Kinsta)

• TTFB: 100-200ms
• Cena: 300-1000 zł/mies
• Zoptymalizowane pod WordPress + auto-cache

2. Server-side caching

Opcache (PHP):

Cachuje skompilowany bytecode PHP - 3-5x szybsze wykonanie

Redis/Memcached:

Cachuje wyniki zapytań do bazy danych

// WordPress + Redis
define('WP_REDIS_HOST', 'localhost');
define('WP_REDIS_PORT', 6379);

Full-page caching:

Serwuje HTML z cache, bez wykonywania PHP/DB queries

• WordPress: WP Rocket, W3 Total Cache
• Custom: Varnish Cache (advanced)

3. Database optimization

Indeksy:

Zapytania do bazy bez indeksów = pełne skanowanie tabeli = wolno

-- Dodaj indeks dla często używanych kolumn
CREATE INDEX idx_post_date ON posts(post_date);

Query optimization:

• Limit results (LIMIT 10)
• Unikaj SELECT * (pobieraj tylko potrzebne kolumny)
• Użyj EXPLAIN do analizy wolnych queries

4. HTTP/2 i HTTP/3

HTTP/1.1 (legacy):

• 1 request per connection
• Head-of-line blocking

HTTP/2:

• Multiplexing (wiele requestów na jednym connection)
• Header compression
• 2-3x szybsze ładowanie multiple resources

HTTP/3 (QUIC):

• UDP zamiast TCP
• Eliminuje head-of-line blocking całkowicie
• Lepsze na mobilnych sieciach (packet loss)

Jak włączyć: Większość nowoczesnych hostingów/CDN obsługuje automatycznie.

Usuwanie nieużywanych wtyczek i kodów

Problem: Bloat = powolna strona

Typowa strona WordPress:

• 30 wtyczek (z czego 10 nieużywanych)
• 5 różnych form builderów (bo testowaliśmy)
• jQuery + 3 różne wersje React (conflict hell)
• 500kB JavaScript, z czego 300kB nieużywane

1. Audyt wtyczek

Sprawdź każdą wtyczkę:

• Czy jest aktywnie używana?
• Czy można zastąpić lżejszą alternatywą?
• Czy funkcjonalność jest dostępna w motywie?

2. Usuwanie nieużywanego CSS/JS

WordPress dequeue:

// functions.php
function remove_unused_scripts() {
    wp_dequeue_script('jquery'); // Jeśli nie potrzebujesz jQuery
    wp_dequeue_style('contact-form-7'); // Jeśli nie używasz CF7
}
add_action('wp_enqueue_scripts', 'remove_unused_scripts');

3. Optymalizacja WordPress core

• Usuń emoji scripts (jeśli nie używasz)
• Wyłącz REST API (jeśli nie potrzebujesz)
• Usuń XML-RPC (bezpieczeństwo + wydajność)

Testy wydajności i monitoring

1. Narzędzia do testowania

Google PageSpeed Insights

• pagespeed.web.dev
• Core Web Vitals + sugestie
• Mobile i Desktop

GTmetrix

• Szczegółowy waterfall chart
• Historia wyników
• Monitoring alertów

WebPageTest

• Najbardziej szczegółowe testy
• Różne lokalizacje serwerów
• Film z ładowania strony

2. Monitoring ciągły

Google Search Console

• Raport "Page Experience"
• Core Web Vitals dla realnych użytkowników
• Alerty o problemach

Third-party monitoring

• Sentry: Performance monitoring
• New Relic: APM + frontend
• SpeedCurve: Continuous monitoring

3. Real User Monitoring (RUM)

Dane od prawdziwych użytkowników vs laboratoryjne testy:

• Różne urządzenia i sieci
• Rzeczywiste warunki (3G, 4G)
• Geolokalizacja użytkowników

Checklista: 15 punktów do szybszej strony

✅ Podstawowe optymalizacje (must-have)

1. Obrazy w WebP/AVIF z fallback - 30-50% mniejsze pliki
2. Lazy loading dla obrazów poniżej fold - szybsze initial load
3. Kompresja GZIP/Brotli - 70-90% mniejsze pliki
4. Browser cache (1 miesiąc dla assets) - nie pobieraj ponownie
5. Minifikacja CSS/JS/HTML - 30-60% mniejsze pliki

✅ Zaawansowane optymalizacje (pro-level)

6. CDN dla statycznych zasobów - niższa latencja
7. Critical CSS inline - natychmiastowy render above fold
8. Async/defer dla JavaScript - nie blokuj renderowanie
9. Preload fontów + font-display: swap - uniknij FOIT
10. Server-side caching (Redis/Opcache) - 3-5x szybsze PHP

✅ Ekspertowe optymalizacje (enterprise)

11. HTTP/3 (QUIC) na CDN - lepsze na mobilnych
12. Service Worker dla PWA - offline-first experience
13. Code splitting i tree shaking - ładuj tylko potrzebny kod
14. Database optimization + indeksy - szybsze zapytania
15. Continuous monitoring + alerting - utrzymuj wydajność

🎯 Cel: PageSpeed 90+ na mobile i desktop

Realistyczne cele:

• Strona wizytówka/blog: 90-95
• E-commerce: 85-90
• Portal/SaaS: 80-85

Pamiętaj: PageSpeed to maraton, nie sprint. Regularne monitorowanie i optymalizacja to klucz do długoterminowego sukcesu.