Chrome DevTools Coverage: jak znaleźć nieużywany CSS i JavaScript

Coverage w Chrome DevTools pomaga znaleźć CSS i JavaScript, który jest pobierany przez przeglądarkę, ale nie jest używany w danym widoku. To nie jest automatyczny przycisk „usuń kod”, tylko punkt startowy do optymalizacji ładowania strony.

Największa wartość Coverage pojawia się przy ciężkich stronach WordPress, sklepach, landing pages z builderów i aplikacjach, które ładują jeden duży bundle dla każdej podstrony. Raport pozwala zobaczyć, które pliki są problemem i czy warto rozbijać kod, usuwać wtyczki, opóźniać skrypty lub przepisać fragment frontendu.

Szybka odpowiedź: co oznacza czerwony kod w Coverage?

Czerwony fragment w raporcie Coverage oznacza kod, którego Chrome nie wykonał podczas konkretnego testu. To nie znaczy, że kod jest zawsze zbędny. Może być potrzebny po kliknięciu menu, otwarciu koszyka, walidacji formularza albo na innym breakpointcie. Dlatego Coverage trzeba testować scenariuszami, nie tylko pierwszym ładowaniem strony.

Jak uruchomić Coverage krok po kroku

1. Otwórz stronę w Chrome.
2. Wejdź w DevTools: F12 albo Ctrl+Shift+I.
3. Otwórz Command Menu: Ctrl+Shift+P.
4. Wpisz Show Coverage i wybierz panel Coverage.
5. Kliknij przycisk nagrywania i odśwież stronę.
6. Wykonaj realny scenariusz: otwórz menu, przewiń, kliknij CTA, sprawdź formularz.
7. Zatrzymaj nagrywanie i posortuj pliki po bajtach niewykorzystanego kodu.

Oficjalna dokumentacja Chrome opisuje Coverage jako narzędzie do wykrywania nieużywanego JavaScript i CSS. W praktycznym audycie warto połączyć je z Lighthouse, Network i Performance, bo sam procent unused code nie mówi jeszcze, czy użytkownik realnie odczuwa problem.

Jak interpretować wyniki bez głupich błędów

Wynik Coverage	Możliwe znaczenie	Co sprawdzić dalej
Duży plik JS, 70-90% unused	Bundle ładuje funkcje niepotrzebne w pierwszym widoku	Code splitting, dynamic import, opóźnienie widgetów
Duży CSS z motywu/buildera	Strona ładuje style dla wielu komponentów, których nie używa	Critical CSS, usunięcie modułów, mniejszy motyw
Skrypt czatu/analityki jako unused	Kod czeka na interakcję lub zgodę cookies	Czy da się ładować po zgodzie albo po interakcji
Kod menu mobilnego unused na desktopie	Normalne, zależne od breakpointu	Powtórzyć test na mobile
Dużo unused po jednej podstronie	Aplikacja współdzieli bundle między trasami	Sprawdzić inne podstrony i routing

Praktyczny workflow optymalizacji

1. Zrób dwa nagrania: cold load i scenariusz użytkownika

Najpierw nagraj zwykłe wejście na stronę. Potem nagraj scenariusz: wejście, scroll do sekcji, otwarcie menu, kliknięcie formularza, interakcja z kalkulatorem. Różnica między tymi nagraniami pokazuje, który kod jest naprawdę martwy, a który odpala się po interakcji.

2. Grupuj problemy według źródła

• Motyw lub builder: zwykle problem z CSS i komponentami ładowanymi globalnie.
• Wtyczki: formularze, slidery, popupy i czaty często ładują kod na każdej stronie.
• Własny bundle: sprawdź dynamic import, route-level splitting i ciężkie biblioteki.
• Third-party: tag manager, heatmapy, reklamy, piksele i widgety.

3. Nie usuwaj pliku tylko dlatego, że jest czerwony

Coverage pokazuje użycie w danym momencie, a nie pełną mapę produktu. Jeżeli usuniesz CSS odpowiedzialny za stan błędu formularza, może wyglądać dobrze w teście, ale rozpaść się przy walidacji. Dlatego po każdej zmianie trzeba zrobić smoke test kluczowych stanów.

Mini-kalkulacja: gdzie jest największy zysk?

Do szybkiej priorytetyzacji użyj prostego wzoru:

potencjalny_zysk = niewykorzystane_kB × wpływ_na_pierwszy_widok × częstość_występowania

Najpierw tnij rzeczy, które są duże, ładują się na każdej stronie i blokują pierwszy widok. Mały unused fragment w panelu administracyjnym nie jest tak ważny jak globalny skrypt 250 kB na każdej podstronie usługowej.

Checklista przed wdrożeniem zmian

• Przetestuj desktop i mobile oddzielnie.
• Sprawdź menu, formularze, koszyk, popupy, cookie banner i slidery.
• Porównaj Network: liczba requestów, rozmiar JS/CSS, cache headers.
• Uruchom Lighthouse albo PageSpeed jako potwierdzenie, nie jako jedyne źródło prawdy.
• Po deployu sprawdź konsolę błędów i najważniejsze ścieżki użytkownika.

Przykład: strona firmowa na WordPressie z ciężkim builderem

Typowy wynik Coverage dla strony z buildera wygląda tak: jeden duży plik CSS motywu, kilka plików JS od slidera, formularza, popupu, mapy i analityki, z czego większość nie jest używana w pierwszym widoku. To nie znaczy, że wszystko można usunąć. Oznacza, że trzeba sprawdzić, które elementy są globalne, a które powinny ładować się tylko tam, gdzie występują.

Dobre szybkie wygrane to wyłączenie skryptów wtyczek na podstronach, które ich nie używają, opóźnienie czatu do pierwszej interakcji, zamiana ciężkiego slidera na statyczny hero i rozdzielenie CSS dla krytycznych sekcji. W małej stronie usługowej te zmiany potrafią dać większy efekt niż zmiana hostingu.

Co robić z wynikami dla CSS?

CSS bywa zdradliwy, bo klasy mogą aktywować się dopiero po hoverze, błędzie formularza, otwarciu menu lub zmianie breakpointu. Dlatego zamiast ręcznie usuwać czerwone linie z pliku, lepiej zacząć od źródła nadmiaru:

• czy motyw ładuje style dla wszystkich komponentów na każdej podstronie?
• czy biblioteka UI importuje cały pakiet zamiast pojedynczych komponentów?
• czy stary CSS z poprzednich wersji projektu nadal jest podpinany?
• czy critical CSS dla pierwszego widoku można ograniczyć do realnie używanych klas?

W projektach Tailwind problem wygląda inaczej: trzeba sprawdzić content paths, safelistę i to, czy produkcyjny build faktycznie usuwa nieużywane klasy.

Co robić z wynikami dla JavaScriptu?

Dla JS najczęściej warto szukać dużych bibliotek ładowanych zbyt wcześnie. Mapy, wykresy, edytory WYSIWYG, galerie, heatmapy i chat widgety rzadko muszą startować w pierwszym widoku. Jeśli użytkownik ma najpierw przeczytać nagłówek i kliknąć CTA, nie ma powodu blokować mu strony kodem, którego może nigdy nie użyć.

1. Przenieś ciężkie komponenty do dynamic import.
2. Ładuj widgety dopiero po zgodzie cookies albo po interakcji.
3. Sprawdź, czy biblioteka pozwala importować tylko używane moduły.
4. Usuń stare polyfille, jeśli grupa przeglądarek już ich nie wymaga.
5. Porównaj wynik Coverage po każdej zmianie, nie po całym refactorze naraz.

Coverage a Core Web Vitals

Coverage nie jest metryką Core Web Vitals, ale pomaga znaleźć przyczyny. Duży nieużywany CSS może opóźniać renderowanie, ciężki JS może pogarszać INP, a third-party scripts mogą wpływać na TBT w Lighthouse. Jeśli po optymalizacji Coverage nie poprawia się LCP albo INP, problem może leżeć gdzie indziej: w obrazach, serwerze, fontach, cache lub kolejności renderowania.

FAQ: Chrome DevTools Coverage

Czy można automatycznie usunąć wszystko, co jest czerwone?

Nie. Czerwony kolor oznacza „nieużyte w tym teście”, a nie „niepotrzebne zawsze”. Najpierw wykonaj scenariusze użytkownika i sprawdź różne breakpointy.

Czy Coverage działa tylko dla JavaScriptu?

Nie. Panel pokazuje zarówno JavaScript, jak i CSS. Przy CSS trzeba jednak szczególnie uważać na stany interaktywne i responsywność.

Jaki wynik jest dobry?

Nie ma jednej magicznej wartości. Dla strony usługowej dobrym celem jest mało kodu krytycznego w pierwszym widoku, szybkie LCP i brak ciężkich globalnych skryptów. Procent unused code traktuj jako sygnał do analizy, nie jako KPI sam w sobie.

Kiedy Coverage daje największy efekt?

Coverage jest szczególnie przydatny, gdy strona ma problem z LCP, INP, ciężkim JavaScriptem lub builderem, który ładuje wszystko wszędzie. Jeśli optymalizacja ma być częścią większego audytu, warto połączyć ją z SEO technicznym i przebudową krytycznych szablonów.

Źródło bazowe: dokumentacja Chrome DevTools Coverage.