PageSpeed Insights - jak prawidłowo interpretować wyniki
PageSpeed Insights to najpopularniejsze narzędzie do testowania szybkości strony. Jednak wiele osób błędnie interpretuje wyniki, skupiając się na ogólnym score zamiast na konkretnych metrykach. Poznaj jak czytać raporty PSI i na co naprawdę zwracać uwagę.
Krótka odpowiedź
Field data vs. Lab data
Field data (dane terenowe):
- Rzeczywiste dane od użytkowników odwiedzających Twoją stronę
- Zbierane przez Chrome UX Report (CrUX)
- 75. percentyl z ostatnich 28 dni
- TO są dane używane przez Google do rankingu
Lab data (dane laboratoryjne):
- Symulacja wykonana przez Lighthouse
- Stałe warunki: emulowany mobile, 4G, mid-tier device
- Powtarzalne, ale nie odzwierciedlające rzeczywistości
- Przydatne do debugowania
Dlaczego różnice:
- Field: różne urządzenia, połączenia, lokalizacje użytkowników
- Lab: idealne warunki, ale na słabym wirtualnym urządzeniu
- Field może być lepszy lub gorszy niż Lab
Co robić gdy nie ma Field data:
- Strona musi mieć wystarczający ruch
- Nowe strony nie mają danych przez ~28 dni
- Polegaj na Lab data, ale z rezerwą
Core Web Vitals - co naprawdę liczy się dla SEO
LCP (Largest Contentful Paint):
- Czas ładowania największego elementu w viewport
- Dobry: ≤ 2.5s | Słaby: > 4.0s
- Najczęstsza przyczyna: duże obrazy, wolny serwer
INP (Interaction to Next Paint):
- Responsywność na interakcje użytkownika
- Zastąpił FID w 2024
- Dobry: ≤ 200ms | Słaby: > 500ms
- Przyczyna: ciężki JavaScript
CLS (Cumulative Layout Shift):
- Niestabilność layoutu (przeskoki elementów)
- Dobry: ≤ 0.1 | Słaby: > 0.25
- Przyczyna: obrazy bez wymiarów, reklamy, fonty
W PSI patrzysz na:
1. Sekcja "Discover what your real users are experiencing" (Field data)
2. Status każdej metryki (zielony/żółty/czerwony)
3. Jeśli wszystkie zielone - nie ma problemu, nawet przy niskim score
Interpretacja Lighthouse score
Skala 0-100:
- 90-100: Dobry (zielony)
- 50-89: Do poprawy (pomarańczowy)
- 0-49: Słaby (czerwony)
Jak jest obliczany:
- LCP: 25% wagi
- TBT (Total Blocking Time): 30% wagi
- CLS: 25% wagi
- FCP: 10% wagi
- Speed Index: 10% wagi
Dlaczego score bywa mylący:
- Możesz mieć score 60 z świetnymi Core Web Vitals
- Lub score 90 ale słabe field data
- Score jest dla Lab data - optymalizuj pod rzeczywistych użytkowników
Na co patrzeć zamiast score:
- Core Web Vitals status (Pass/Fail)
- Field data jeśli dostępne
- Konkretne zalecenia Lighthouse
Różne wyniki przy każdym teście:
- To normalne - Lab data ma warancję
- Testuj 3-5 razy i bierz medianę
- Lub używaj WebPageTest z wieloma przebiegami
Praktyczne podejście do optymalizacji
Priorytety:
1. Napraw czerwone Core Web Vitals w Field data
2. Popraw pomarańczowe do zielonych
3. Dopiero potem optymalizuj Lab data / score
Sekcja "Opportunities":
- Pokazuje szacowany zysk czasowy
- Sortuj po potencjalnym wpływie
- Zacznij od największych możliwości
Sekcja "Diagnostics":
- Szczegółowe informacje o problemach
- Nie wszystko jest równie ważne
- Skup się na tym co wpływa na Core Web Vitals
Czego NIE robić:
- Nie optymalizuj na ślepo pod score
- Nie ignoruj Field data na rzecz Lab data
- Nie spędzaj godzin na zyskach < 0.1s
- Nie niszcz UX dla kilku punktów score
Monitoring:
- Testuj regularnie (co tydzień/miesiąc)
- Używaj Search Console > Core Web Vitals
- Śledź trendy, nie pojedyncze pomiary
Alternatywne narzędzia:
- WebPageTest - szczegółowa diagnostyka
- GTmetrix - inne perspektywy
- Lighthouse w Chrome DevTools - lokalne testy