Jak czytać wynik audytu wydajności — Lighthouse, CrUX i plan poprawek

1. Sprawdź adres, źródło, urządzenie i datę

Zacznij od tego, co rzeczywiście zmierzono. Strona główna, karta produktu i koszyk mają inne zasoby oraz zachowanie. Potwierdź adres końcowy po przekierowaniach, profil telefonu lub komputera i datę pomiaru. Data utworzenia raportu nie musi być datą testu wydajności: narzędzie może wykorzystać zapisany wynik z cache.

W raporcie SEO źródłem może być wcześniejszy DoSieci Speed Check, PageSpeed Insights lub lokalny Lighthouse. Dostępność źródeł zależy od próby. Nie traktuj ich jako trzech niezależnych pomiarów, które zawsze wykonano równocześnie. Przy ponownym badaniu sprawdź, czy wynik jest świeży i czy zachowano porównywalny profil.

Ocena SEO DoSieci, ogólna ocena szczegółowego audytu i wynik performance Lighthouse to różne podsumowania. Odczytuj nazwę karty, zamiast porównywać same liczby 0–100. Wysoki wynik w jednej kategorii nie rozstrzyga o całej witrynie.

Szczegółowy DoSieci Speed Check pokazuje ocenę ogólną i sześć kategorii DoSieci: wydajność, techniczne SEO, metadane, dostępność, udostępnianie oraz dobre praktyki. To osobne podsumowanie od czterech surowych kategorii Lighthouse: Performance, Accessibility, Best Practices i SEO. Porównuj zawsze tę samą kategorię i metodę obliczeń.

2. Rozdziel laboratorium od danych użytkowników

Lighthouse wykonuje kontrolowany test i dostarcza wskazówek diagnostycznych. Pomaga odtworzyć problem oraz sprawdzić zmianę, ale pojedyncza próba nie opisuje wszystkich urządzeń, połączeń i sesji. CrUX agreguje doświadczenia rzeczywistych użytkowników Chrome. W PageSpeed Insights obejmuje poprzedni 28-dniowy okres zbierania danych.

Sprawdź, czy dane użytkowników dotyczą badanego URL-a, czy całego originu, czyli wspólnego protokołu, hosta i portu. Wynik originu może obejmować wiele podstron. Brak próbki nie oznacza wyniku zero ani dowodu wolnego działania. Przyczyną może być niewystarczająca ilość kwalifikujących się danych; nie wyciągaj z tego samego komunikatu wniosku o liczbie wszystkich klientów.

Znaczenie tych dwóch źródeł i ograniczenia próbki opisuje dokumentacja PageSpeed Insights.

3. Co oznaczają LCP, INP, CLS i TBT

Dobre progi Core Web Vitals to LCP do 2,5 s, INP do 200 ms i CLS do 0,1. W ocenie doświadczeń użytkowników odnosimy je do 75. percentyla, z uwzględnieniem urządzenia. W raporcie DoSieci sumaryczna ocena zestawu wymaga danych wszystkich trzech metryk; brakująca wartość pozostaje nieustalona. PageSpeed Insights stosuje udokumentowany wyjątek: przy niewystarczającej próbce INP może ocenić zestaw na podstawie dobrego LCP i CLS. Dlatego komunikaty dwóch narzędzi mogą się różnić. Zobacz definicje i progi Web Vitals oraz wyjaśnienie TBT i jego relacji do INP.

4. Powiąż problem z konkretną przyczyną

W rozdziale Największe zasoby i element LCP oraz dowodach Lighthouse znajdź plik, element lub etap, który może odpowiadać za opóźnienie. Lista największych transferów jest punktem startowym. Największy plik nie musi być przyczyną LCP, a najmniejszy skrypt może blokować ważną interakcję.

• Wolne LCP: sprawdź odpowiedź serwera, odkrywanie głównego zasobu, jego pobieranie i moment wyświetlenia. Dla obrazu oceń rozmiar, wariant dla urządzenia i sposób ładowania. Instrukcja diagnozy LCP pomaga rozdzielić te etapy.
• Wysokie CLS: sprawdź rezerwowanie miejsca pod obrazami, osadzeniami i dynamicznymi blokami. Element wskazany jako przesunięty może być skutkiem zmiany wyżej na stronie. Poradnik CLS omawia także różnice między ładowaniem a dalszą wizytą.
• Słaba reakcja lub wysokie TBT: przeanalizuj długie zadania i skrypty. Powiąż je z działaniem, które rzeczywiście jest opóźnione. Diagnoza INP zaczyna się od znalezienia problematycznej interakcji.

Szacowanych oszczędności nie sumuj jak gwarantowanego zysku: rekomendacje mogą dotyczyć tych samych zasobów i zależeć od siebie.

5. Zmień jedną grupę ustawień i sprawdź działanie

Przygotuj kopię konfiguracji i materiałów. W CMS ustal, który komponent dostarcza zasób: motyw, wtyczka, blok edytora czy zewnętrzna integracja. Zacznij od zmiany uzasadnionej dowodem, na przykład odpowiedniego wariantu obrazu, naprawy zarezerwowanego miejsca albo ograniczenia niepotrzebnego skryptu na konkretnej podstronie.

Nie wyłączaj wszystkich wtyczek i skryptów na działającym sklepie. Łączenie, opóźnianie i usuwanie zasobów może wpłynąć na menu, formularz, analitykę lub koszyk. Po publikacji przetestuj te elementy. Pamięć podręczna musi respektować prywatne oraz dynamiczne widoki. Nie włączaj globalnego cache dla kont i koszyków bez sprawdzenia zasad aplikacji.

Jeżeli problem dotyczy odpowiedzi serwera, zbierz czas, adres i okoliczności oraz sprawdź aplikację, cache i logi z administratorem. Słaby wynik sam w sobie nie dowodzi, że potrzebujesz droższego hostingu. Praktyczne kroki dla CMS znajdziesz także w poradniku przyspieszania WordPressa.

6. Oceń efekt i zachowaj porównywalne warunki

Zapisz stary raport, datę wdrożenia i dokładny zakres zmiany. Powtórz test tego samego adresu w tym samym profilu. Gdy wynik się waha, wykonaj kilka porównywalnych prób i oceniaj typowy rezultat oraz konkretne metryki, zamiast wybierać najlepszy pojedynczy wynik. Sprawdź, czy narzędzie nie pokazuje nadal wcześniejszego pomiaru.

CrUX nie jest natychmiastowym testem wdrożenia: okno danych może obejmować wizyty sprzed poprawki. Osobno zweryfikuj działanie strony na telefonie i kluczowe ścieżki użytkownika. Większa punktacja bez sprawnego formularza lub zakupu nie jest udaną optymalizacją. Nie przeliczaj zmiany Lighthouse bezpośrednio na pozycje w Google lub obiecaną sprzedaż.