Czym jest PageSpeed Insights (PSI)?
PageSpeed Insights to darmowe narzędzie od Google, które analizuje wydajność strony WWW i daje praktyczne rekomendacje poprawy. Raport PSI łączy dwa źródła danych:
- Lab data (Lighthouse) — testy uruchamiane w kontrolowanym środowisku laboratoryjnym (emulacja urządzenia i sieci), dostarczające szczegółowych metryk i waterfall’a;
- Field data (CrUX — Chrome User Experience Report) — agregowane, realne metryki od użytkowników Chrome, pokazujące jak strona zachowuje się u rzeczywistych użytkowników w różnych lokalizacjach i warunkach sieciowych.
PSI występuje w formie webowego interfejsu (https://pagespeed.web.dev/), jako API (PageSpeed Insights API) oraz jako narzędzie wbudowane w Chrome DevTools (Lighthouse).
Co mierzy PageSpeed Insights — kluczowe metryki i sekcje
Raport PSI jest podzielony na kilka głównych części:
1. Wynik „Performance” (0–100)
To złożona ocena oparta na wielu metrykach Lighthouse; 90–100 = zielony, 50–89 = pomarańczowy, 0–49 = czerwony.
2. Core Web Vitals (najważniejsze metryki UX)
- LCP — Largest Contentful Paint: czas do wyrenderowania największego widocznego elementu (tekst/obraz). Cel: < 2.5s.
- INP (Interactive to Next Paint) / wcześniej FID — First Input Delay: opóźnienie reakcji strony na pierwszą interakcję użytkownika; FID był wcześniej używany, teraz Google preferuje INP jako metrykę dłuższej interakcji. Cel: niski (FID < 100ms, INP — zależnie od definicji).
- CLS — Cumulative Layout Shift: miara przesunięć układu (niespodziewanych skoków elementów). Cel: < 0.1.
3. Inne metryki wydajności (lab & dodatkowe)
- FCP — First Contentful Paint: czas do pierwszego renderowanego fragmentu treści.
- Speed Index: jak szybko treść wizualna staje się widoczna.
- TBT — Total Blocking Time: całkowity czas blokowania głównego wątku (ważne jako proxy dla FID).
- Time to Interactive (TTI): czas do stanu, gdy strona jest interaktywna.
- TTFB — Time to First Byte: czas od żądania do pierwszego bajtu odpowiedzi od serwera (ważne dla backendu i sieci).
4. Opportunities (sugestie przyspieszenia)
Lista proponowanych optymalizacji z szacunkową oszczędnością czasu ładowania (np. „Zoptymalizuj obrazy”, „Usuń nieużywany JavaScript”, „Zmniejsz czas reakcji serwera”).
5. Diagnostics (diagnostyka)
Szczegółowe informacje techniczne (np. rozmiar zasobów, liczba żądań, użycie pamięci, szczegóły na temat render-blocking resources).
6. Passed audits / Best Practices
Lista zgodności z praktykami (np. HTTPS, obrazki responsywne, bezpieczne linki z „noopener”, itp.) i wynik SEO (podstawowe kontrole).
Jak korzystać z PageSpeed Insights — krok po kroku
- Wchodzisz na https://pagespeed.web.dev/i wpisujesz URL (może być strona główna lub podstrona).
- Wybierasz zakładkę „Mobile” lub „Desktop” — PSI wykona testy z ustawieniami odpowiednimi dla urządzenia (mobile ma wolniejszą, throttled sieć i device emulation).
- Odczytujesz wynik Performance i Core Web Vitals — zwłaszcza LCP, INP/FID, CLS.
- Przeglądasz sekcję Opportunities — sortuj sugestie według wpływu i kosztu wdrożenia.
- Przechodzisz do Diagnostics, analizujesz rozmiary zasobów, waterfall network i problematic scripts.
- Możesz uruchomić Lighthouse lokalnie (DevTools) albo skonfigurować testy w CI (Lighthouse CI, PageSpeed Insights API).
- Porównuj lab data z field data w zakładce „Field data” — jeśli brak danych CrUX, oznacza to że strona nie ma wystarczającej ilości ruchu od użytkowników Chrome aby wygenerować statystyki.
Co sugeruje PageSpeed Insights — praktyczne rekomendacje
PSI poda konkretne wskazówki, najczęściej:
- Optymalizuj obrazy: zmniejsz rozdzielczości, używaj WebP/AVIF, ustaw
srcsetiloading=lazy. - Kompresja i transfer: włącz Brotli/Gzip na serwerze, ustaw nagłówki cache-control, użyj CDN.
- Usuń nieużywany JS i CSS: kod dzielony (code-splitting), dynamiczne importy, usuwanie bibliotek których nie używasz.
- Zminimalizuj render-blocking resources: defer/async dla skryptów, preload/prefetch dla kluczowych zasobów, critical CSS.
- Szybki backend: zmniejsz TTFB przez optymalizację bazy danych, cache (Redis, OPcache), szybszy serwer lub CDN.
- Zoptymalizuj czcionki: preload, font-display: swap.
- Zmniejsz liczbę requestów: łączenie zasobów (rozważ HTTP/2 benefits), minimalizacja third-party scripts.
Każda sugestia zwykle zawiera estimate poprawy (np. «możesz zaoszczędzić 1,2 s»).
Zalety PageSpeed Insights
- Darmowy, oficjalny od Google — daje wgląd w to, co Google uważa za ważne.
- Łączy dane lab i field — jednocześnie widzisz, cosyntetyczne testy pokazują i jak realni użytkownicy odczuwają stronę.
- Szczegółowe, praktyczne wskazówki — listy konkretnych auditów i opportunites.
- API i integracja CI — możliwość automatycznych testów i monitoringu zmian wydajności.
- Wspiera Core Web Vitals — metryki które Google używa jako sygnały rankingowe.
Wady i ograniczenia PageSpeed Insights
- Lab test = emulacja, nie rzeczywistość — Lighthouse emuluje device+network; wynik może różnić się od realnego doświadczenia.
- Sample bias w CrUX — field data pochodzi od użytkowników Chrome, więc nie obejmuje wszystkich przeglądarek. Dla stron o małym ruchu CrUX może nie mieć danych.
- Ograniczona liczba lokalizacji lab — testy laboratoryjne uruchamiane są z określonych datacenter Google i mogą nie oddawać specyfiki geograficznej użytkowników.
- Sugestie nie zawsze priorytetowe — estymowane oszczędności są przybliżone; trzeba ocenić koszt wdrożenia vs. realne korzyści.
- Może promować optymalizacje, które nie pasują do specyfiki biznesu — np. agresywna minifikacja czy lazy-loading, które mogą wpływać na UX (np. SEO dynamic content).
Czy lokalizacja serwera WWW (odległość) wpływa na wynik PageSpeed Insights?
Tak i nie — rozbijmy to:
Wpływ na Field data (CrUX):
- Field data odzwierciedla realne czasy użytkowników z ich lokalizacji sieciowych. Jeżeli większość użytkowników jest geograficznie daleko od serwera lub ISP stosuje słabe trasy, to CrUX pokaże gorsze metryki (wyższe LCP/TTFB). CDN, geograficzne rozproszenie serwerów i edge caching usuwają ten problem.
Wpływ na Lab data (Lighthouse/PSI test):
- Lab testy uruchamiane są z serwerów Google w określonym regionie (zachowują emulację sieci: ograniczenie przepustowości, latencję). Lighthouse emuluje wolne urządzenie i sieć, więc efekt fizycznej odległości serwera jest zredukowany, ale nie całkowicie — np. TTFB zmierzony w labie może być wyższy jeśli rzeczywisty backend odpowiada wolno. Jednak sam fakt, że testy są uruchamiane z chmury Google oznacza, że wyniki lab są porównywalne pomiędzy testami, ale nie zawsze reprezentatywne dla konkretnego regionu geograficznego Twoich użytkowników.
W praktyce: odległość serwera wpływa na realne doświadczenie (field data) i na TTFB w lab, dlatego warto:
- stosować CDN dla statycznych assetów,
- umieszczać backendy bliżej użytkowników (multi-region),
- rozważyć edge computing i caching.
Diagnostyka i deeper dive — co sprawdzać w praktyce
- Waterfall (DevTools / WebPageTest) — zobacz kolejność żądań, które elementy blokują render, gdzie są opóźnienia. PSI pokazuje uproszczony widok; do szczegółowego śledzenia używaj WebPageTest i Chrome DevTools.
- Server timing — mierz czas serwera (middleware) i dodaj nagłówki
Server-Timingby powiązać backend z frontem. - Measure RUM — wdroż Real User Monitoring (GA4, NewRelic RUM, SpeedCurve) by uzyskać pełną perspektywę.
- Lighthouse CI / PageSpeed API — uruchamiaj testy w CI dla krytycznych URL w różnych wersjach (pull requests), aby unikać regresji.
Jak traktować wynik 100 (jak na screenie)
Wynik 100 (pełna zieleń) to świetny rezultat, szczególnie jeśli Core Web Vitals są w zielonej strefie. Jednak:
- Nie oznacza że nie ma nic do zrobienia — sprawdź field data (CrUX), best practices, i SEO; utrzymanie wyniku wymaga monitoringu.
- Uwaga na fluktuacje — cache, A/B testing, ad networks i third-party scripts mogą powodować zmienność wyników.
Integracja z procesem deweloperskim (CI/CD)
- Uruchamiaj Lighthouse CI lub PageSpeed API jako krok w CI by blokować merge, jeżeli metryki spadną (np. LCP > 2.5s).
- Użyj BigQuery + CrUX/GA4 do długoterminowego monitoringu.
- Automatycznie generuj raporty i alerty (Slack/email) w przypadku regresji.
Ciekawostki i praktyczne insighty
- PSI używa Lighthouse — a Lighthouse od wersji 6+ zawiera metryki Core Web Vitals i algorytm oceny.
- CrUX to baza z rzeczywistymi użytkownikami Chrome — to jedna z najlepszych baz do porównania doświadczeń.
- Google traktuje Core Web Vitals jako sygnał rankingowy — ale to tylko jeden z wielu; content i relevancy nadal decydują o pozycji w SERP.
- API: PageSpeed Insights API pozwala testować setki URL tygodniowo (z limitami) i integrować wyniki z narzędziami devops.
- Lighthouse lokalnie vs w chmurze: lokalne Lighthouse (DevTools) bazuje na Twoim środowisku; PSI uruchamia test z kontrolowanego środowiska, co ułatwia porównania.
Rekomendacje praktyczne — co zrobić po teście PSI
- Priorytetyzuj Core Web Vitals: LCP → INP/FID → CLS.
- Wdroż caching (CDN), OPcache, Redis, kompresję (Brotli).
- Optymalizuj obrazy i czcionki.
- Usuń/odłóż ładowanie niekrytycznego JS, defer/async, code-splitting.
- Monitoruj field data i integruj testy w CI.
- Użyj WebPageTest dla testów geograficznych i waterfallów; porównuj z działaniami PSI.
Podsumowanie
PageSpeed Insights to potężne, darmowe narzędzie, które łączy Laboratoryjny Lighthouse i realne metryki CrUX, dostarczając praktycznych rekomendacji poprawy wydajności i UX. Wynik 100 to świetny sygnał, ale nie koniec pracy — warto uzupełniać PSI o WebPageTest, RUM i testy geograficzne. Lokalizacja serwera wpływa na realne doświadczenie i wyniki field data, a w labie wpływ jest mniejszy dzięki emulacji, ale TTFB i backend nadal mają znaczenie.