web.dev a Lighthouse: czym różnią się pomiary i kiedy używać każdego narzędzia?

web.dev to serwis Google z dokumentacją, poradnikami i narzędziami do poprawy jakości stron internetowych. Właściciel witryny znajdzie tam informacje o wydajności, dostępności i SEO, a narzędzie Measure pozwala uruchomić raport oparty na PageSpeed Insights. Google podaje, że web.dev/measure korzysta z PageSpeed Insights API, aby zapewnić bardziej spójne wyniki między tymi usługami (stan na 10.2026).

Raport PageSpeed Insights pokazuje audyty, wskazówki i laboratoryjny wynik Lighthouse. Może też prezentować dane terenowe CrUX, czyli zbiorcze pomiary doświadczeń użytkowników Chrome, jeśli dla strony lub domeny dostępne są dane. Brak danych CrUX dla konkretnego adresu nie oznacza, że strona nie działa; oznacza, że raport nie udostępnia reprezentatywnych danych dla tego zakresu.

W sklepie uruchom osobne pomiary dla karty produktu, kategorii i koszyka, ponieważ każdy szablon może ładować inne skrypty i obrazy. Wynik strony głównej nie opisuje automatycznie całej ścieżki zakupowej. Jeśli sklep działa na WordPressie, pomiar i kolejność zmian przy przyspieszaniu WordPressa pomagają uporządkować diagnozę. Gdy analiza wskazuje na problemy wydajnościowe w sklepie, optymalizacja szybkości WooCommerce może objąć diagnozę i wdrożenie uzgodnionych poprawek.

Lighthouse jest narzędziem audytującym stronę, a web.dev jest serwisem, który udostępnia dokumentację i narzędzia związane z jakością stron. Lighthouse można uruchomić w Chrome DevTools, wierszu poleceń lub automatyzacji; raport obejmuje między innymi audyty wydajności, dostępności, SEO i dobrych praktyk. PageSpeed Insights korzysta z Lighthouse do pomiaru laboratoryjnego i osobno pokazuje dostępne dane CrUX.

Tabela pokazuje, które narzędzie wybrać zależnie od pytania i rodzaju wyniku. PageSpeed Insights pozwala wybrać strategię mobile albo desktop, ale nie zastępuje testu na fizycznym telefonie.

Wniosek: Lighthouse wykonuje audyt, PageSpeed Insights przedstawia audyt i dostępne dane CrUX, a web.dev udostępnia dokumentację oraz narzędzia. Dokumentacja Google opisuje uruchamianie Lighthouse w DevTools, przez CLI i jako moduł Node (stan na 10.2026).

Strategia mobile w PageSpeed Insights określa sposób analizy, a nie urządzenie, na którym właściciel sklepu uruchomił narzędzie. Aby sprawdzić dotyk, menu, warianty i formularz koszyka, otwórz sklep na fizycznym telefonie. Opis Core Web Vitals i sposobów poprawy wyników pomaga przełożyć raport na wskaźniki doświadczenia użytkownika.

Porównywalny pomiar wymaga badania tego samego adresu, szablonu i strategii urządzenia w podobnych warunkach. Zapisuj datę i to, czy analizujesz mobile, czy desktop, ponieważ zmiana adresu albo ustawień może zmienić wynik.

Stosujemy następującą procedurę:
1. Wybierz reprezentatywny adres, na przykład kartę produktu lub kategorię, i zanotuj używany szablon.
2. Uruchom PageSpeed Insights dla adresu w strategii mobile, a następnie wykonaj osobny raport dla desktopu.
3. Powtórz każde badanie kilka razy i zachowaj raporty zamiast opierać wniosek na jednym przebiegu.
4. Zapisz datę, adres URL, strategię, stan wdrożenia i istotne zmiany, takie jak aktywna promocja lub nowy skrypt.
5. Sprawdź stronę na fizycznym telefonie, aby ocenić dotyk, menu, wybór wariantu i formularz koszyka.

Przed i po wdrożeniu zachowaj te same adresy oraz strategie. Po zmianie głównego zdjęcia porównaj kartę tego samego produktu, a po modyfikacji checkoutu sprawdź ten sam etap koszyka. Poradnik optymalizacji LCP, INP i CLS omawia wskaźniki używane do oceny doświadczenia użytkownika.

Raport mobile i test na telefonie odpowiadają na różne pytania. Raport Lighthouse symuluje określone warunki analizy, natomiast telefon ujawnia zachowanie dotykowe, wpływ przeglądarki i błędy widoczne w realnym procesie zakupu.

Wyniki różnią się, gdy narzędzia mierzą inne dane albo uruchamiają test w odmiennych warunkach. Lighthouse kontroluje warunki testu, natomiast CrUX agreguje pomiary rzeczywistych wizyt z różnych urządzeń, sieci i lokalizacji.

Tabela pokazuje typowe przyczyny rozbieżności oraz sposób sprawdzenia, czy wskazują na problem użytkownika.

Tabela pomaga odróżnić różnicę metody pomiaru od problemu wymagającego naprawy. Jeśli wynik Lighthouse jest słaby, a dane terenowe dobre, sprawdź powtarzalność testu i jego warunki. Jeśli wyniki terenowe są słabe, szukaj wzorca w szablonach i urządzeniach użytkowników.

CrUX bazuje na doświadczeniach użytkowników Chrome, a raport może obejmować adres URL lub dane zagregowane dla domeny. Brak danych konkretnej podstrony nie wyklucza raportu dla domeny, a dobry wynik domeny nie potwierdza, że każda karta produktu działa równie sprawnie (dokumentacja web.dev, stan na 10.2026).

Dla sklepu najważniejsze są LCP, INP i CLS, ponieważ opisują ładowanie głównej treści, reakcję na działanie użytkownika i stabilność układu. Ocena wydajności Lighthouse pomaga wykryć problemy laboratoryjne, ale nie zastępuje oceny tych wskaźników na rzeczywistych wizytach.

LCP mierzy czas wyświetlenia największego widocznego elementu treści, na przykład głównego zdjęcia produktu. INP ocenia opóźnienie reakcji na interakcje, takie jak wybór wariantu lub otwarcie koszyka. CLS opisuje nieoczekiwane przesunięcia elementów, które mogą skierować kliknięcie na inny przycisk.

Powiąż wskaźnik z szablonem i działaniem klienta. Słaby LCP na karcie produktu może wynikać z dużego zdjęcia głównego, a wysoki INP z ciężkiego skryptu filtrów lub wariantów. CLS w koszyku może wiązać się z elementem, który ładuje się po narysowaniu strony. Diagnostyka Core Web Vitals w WordPressie opisuje analizę wskaźników w kontekście szablonów.

Zalecamy ustalać priorytet według wpływu na zakup, liczby dotkniętych szablonów i możliwości bezpiecznej poprawki. Nie poprawiaj wyniku Lighthouse kosztem funkcji sklepu; sprawdź, czy problem utrudnia wybór produktu, dodanie do koszyka albo płatność.

Poprawkę rozpocznij od połączenia konkretnego audytu z zasobem i szablonem, którego dotyczy. Komunikat o dużym JavaScript nie przesądza, czy należy usunąć skrypt, opóźnić jego wykonanie, czy ograniczyć go do wybranych podstron.

Postępuj według kolejnych kroków:
1. Wybierz powtarzalny problem z raportu i zapisz adres URL oraz wpływ na wskaźnik.
2. Zidentyfikuj zasób lub skrypt wskazany w audycie, na przykład obraz LCP, arkusz CSS albo skrypt zewnętrzny.
3. Sprawdź, czy zasób jest potrzebny na karcie produktu, kategorii i koszyku, czy tylko na wybranym szablonie.
4. Wprowadź zmianę na stagingu, czyli kopii sklepu przeznaczonej do testowania.
5. Powtórz pomiar na tym samym adresie i strategii oraz sprawdź ścieżkę zakupu na telefonie.

Przy diagnozie cache zacznij od zrozumienia, jak cache przyspiesza stronę WWW. Nieprawidłowe reguły mogą utrudnić aktualizację koszyka lub statusu zamówienia. Jeśli raport wskazuje problem z serwerem, CDN lub regułami cache, wiedza o tym, czym jest Cloudflare i jak działa, pomaga rozdzielić ustawienia infrastruktury od zmian w kodzie.

Z naszych wdrożeń wynika, że wskazówki z raportu zyskują wartość, gdy przypiszemy je do konkretnego szablonu i procesu biznesowego. Wdrożenie zmian w WooCommerce może wymagać oceny skryptów, obrazów i cache w całym procesie zakupu.

Najczęstszym błędem jest traktowanie jednego wyniku Lighthouse jako ostatecznej oceny całego sklepu. Wynik zależy od warunków testu, a poszczególne szablony mogą ładować różne zasoby.

Unikaj tych praktyk:
- porównywania strony produktu z raportem strony głównej;
- wyciągania wniosków z jednego przebiegu bez sprawdzenia powtarzalności;
- optymalizowania wyniku punktowego bez weryfikacji zakupów i działania funkcji;
- ignorowania CrUX, gdy dostępne są dane terenowe;
- uznawania symulacji mobile za test na fizycznym telefonie.

Google opisuje Core Web Vitals jako jeden z elementów doświadczenia strony i wyjaśnia, że dobre wyniki raportów nie gwarantują wysokiej pozycji w wyszukiwarce (dokumentacja Google Search, stan na 10.2026). Oceniaj wydajność razem z dostępnością, bezpieczeństwem i skutecznością procesu zakupowego, a score Lighthouse traktuj jako narzędzie diagnostyczne.

Analizę warto zlecić, gdy słabe wskaźniki powtarzają się w danych terenowych, problemy pojawiły się po wdrożeniu albo proste zmiany nie poprawiają działania sklepu. Eskalacja ma sens również wtedy, gdy ciężki motyw, integracje lub skrypty zewnętrzne utrudniają wskazanie przyczyny.

Zakres audytu powinien obejmować reprezentatywne adresy, pomiary laboratoryjne i terenowe, identyfikację zasobów, ocenę wpływu na szablony oraz plan napraw. W sklepie warto sprawdzić produkt, kategorię, koszyk i checkout, ponieważ poprawa strony głównej nie musi zmienić doświadczenia zakupowego.

Po diagnozie zapisz stan przed zmianą, plan działań i pomiar kontrolny po wdrożeniu. Przy większych zmianach zalecamy wdrożenie etapowe, aby przypisać rezultat do konkretnej poprawki i cofnąć ją, jeśli pogorszy działanie sklepu. Jeśli potrzebujesz wykonawcy, zleć optymalizację szybkości sklepu WooCommerce, aby połączyć wyniki pomiarów z konkretnymi szablonami i poprawkami.

• Cache na stronie www: jak działa i kiedy przyspiesza ładowanie
• Gzip i Brotli - jak włączyć kompresję strony WWW i sprawdzić efekt?
• Jak CDN może poprawić wydajność Twojego sklepu internetowego
• Optymalizacja stron z dynamicznymi tabelami danych pod szybkość i SEO
• Core update Google: co oznacza dla SEO i jak ocenić wpływ aktualizacji na stronę