Wydajność strony: prawdziwy audyt Lighthouse w 30 sekund
Wdrożyłeś świeży landing page i chcesz wiedzieć, czy nie jest „ciężki jak cegła". Klient pyta, czemu jego sklep ładuje się 9 sekund. Pokazujesz prezentację konkurencji i potrzebujesz cyfry („oni mają 38, Wy będziecie mieli 95"). Wszystkie te sytuacje mają jedną wspólną odpowiedź: audyt Lighthouse.
To narzędzie pyta Google PageSpeed Insights API (czyli silnik Lighthouse, ten sam, którego używa Google Search Console) o pełny raport: 4 oceny 0-100 (Wydajność, Dostępność, Sprawdzone praktyki, SEO), Core Web Vitals (LCP, INP, CLS, FCP, TTFB, Speed Index) i listę konkretnych rzeczy do naprawy (np. „obrazek 1.2 MB blokuje renderowanie, oszczędzisz 2.8 s").
Skąd dane? Pomiar laboratoryjny robi Google z chmurowego centrum w USA na symulowanym 4G + smartphone klasy średniej. Jeśli strona ma dane od użytkowników z Chrome CrUX (Chrome User Experience Report, publiczna baza wydajności rzeczywistych użytkowników), to wartości INP i TTFB pochodzą z prawdziwych odwiedzin. Dla mniejszych stron CrUX zwykle nie ma próbki - wtedy widzisz tylko liczby laboratoryjne.
Mobile vs Desktop: to nie ten sam audyt. Mobile używa wolniejszej maszyny (Moto G4, throttling) i wolniejszego internetu (4G ~1.6 Mbps z latencją 150 ms), więc oceny są zawsze niższe. Google uznaje mobile za priorytet w rankingu (mobile-first indexing od 2019), więc na to patrz w pierwszej kolejności.
Jak używać
- Wklej URL strony, którą chcesz przebadać. Możesz wkleić bez `https://`, dopisze sam. Musi to być publiczny URL - Google nie zobaczy `localhost`, `.local` ani stron za loginem.
- Wybierz strategię: Mobile (domyślne, ważniejsze dla SEO) albo Desktop (porównawczo, łatwiej dostać 90+). Audytuj obie, jeśli budżet na to pozwala - często mobile jest dramatycznie wolniejsze.
- Kliknij Uruchom audyt i poczekaj 10-30 sekund. Google fizycznie wczytuje stronę w wirtualnej przeglądarce, mierzy każdy krok i liczy wynik. To nie jest cache - za każdym razem nowy pomiar.
- Patrzysz na 4 koła (Wydajność, Dostępność, Sprawdzone praktyki, SEO). Zielony = 90-100, żółty = 50-89, czerwony = 0-49. Google traktuje zielony jako „dobrze", reszta to do poprawy.
- Pod kołami masz Core Web Vitals: LCP (Largest Contentful Paint, kiedy ekran wygląda już „gotowo"), INP (Interaction to Next Paint, jak szybko strona reaguje na klik), CLS (Cumulative Layout Shift, czy treść skacze podczas ładowania), FCP, TTFB, Speed Index.
- Na dole lista możliwości - konkretne rzeczy do naprawy posortowane od najważniejszej. Każda mówi, ile sekund/MS oszczędzisz, np. „skompresuj obrazki: -2.1 s". Bierz pierwsze 3 z czerwoną plakietką High, reszta to drobiazgi.
- Re-run po wdrożeniu poprawki: nowy pomiar, porównujesz wynik. Open in PageSpeed Insights otwiera oficjalny raport Google na pagespeed.web.dev (te same dane, więcej detali).
Kiedy się przydaje
Sześć sytuacji, w których to narzędzie wygrywa zwykłą rozmowę:
- Pre-deploy regression check. Robisz duży refactor frontu (Next.js update, nowa biblioteka komponentów, podmiana CMS). Przed pushem na produkcję sprawdzasz, czy wynik nie spadł poniżej 90. Jeśli spadł - wiesz, że trzeba sprawdzić, co dodaliście (zwykle: za duży JS bundle albo niezoptymalizowane obrazki).
- Demo konkurenta klientowi. Spotkanie sprzedażowe, chcesz pokazać, że obecny dostawca klienta robi słabe strony. Wpisujesz URL ich strony i URL ich konkurencji, widać 38 vs 92. Klient zaczyna słuchać, bo cyfry od Google nie są do podważenia.
- Diagnoza „dlaczego sklep wolno chodzi". Klient pisze, że konwersja spadła, podejrzewa szybkość. Robisz audyt: LCP 6.8 s (powinien być pod 2.5 s), w opportunities widać „zbyt duże obrazy hero (3.4 MB)". Rozwiązujesz w pół dnia.
- Audyt SEO przed migracją. Klient migruje WordPress na Shopify / Webflow / własny stack. Robisz audyt obecnej strony przed i nowej po: porównujesz każdą z 4 ocen. SEO mówi Ci, czy meta tagi, alt teksty i sitemap są na miejscu. Best Practices - czy nie ma mixed content, deprecated API itd.
- Sprawdzenie hostingu / CDN. Zmieniasz dostawcę z OVH na Vercel. Robisz audyt z mobile + desktop przed i po. TTFB (Time To First Byte) pokaże od razu, czy serwer szybciej odpowiada. LCP - czy obrazki ładują się szybciej (CDN cache).
- Sprawdzanie WCAG i dostępności. Klient publiczny musi mieć zgodność WCAG 2.1 AA. Audyt Accessibility pokaże: kontrasty, alt teksty, role ARIA, focusy. Pełny audyt WCAG to więcej, ale Lighthouse łapie ~80% problemów technicznych.
Potrzebujesz więcej kontekstu? Sprawdzanie certyfikatu SSL potwierdzi, że HTTPS jest prawidłowo skonfigurowany (warunek Best Practices = 100). Sprawdzanie DNS pokaże, czy serwer odpowiada przez właściwe rekordy. Podgląd Open Graph - czy meta tagi social-share działają tak, jak Lighthouse od Ciebie wymaga.