Audyt Google Lighthouse dla PrestaShop: Interpretacja każdego wyniku

Co mierzy Google Lighthouse

Google Lighthouse to zautomatyzowane narzędzie audytowe wbudowane w Chrome DevTools, które ocenia strony internetowe w czterech głównych kategoriach: Wydajność, Dostępność, Najlepsze praktyki i SEO. Każda kategoria generuje wynik od 0 do 100, a każdy wynik jest obliczany na podstawie konkretnych metryk i testów o różnych wagach. Zrozumienie, co te wyniki rzeczywiście oznaczają dla sklepu PrestaShop — i jakie są realistyczne cele — jest niezbędne, zanim zaczniesz poświęcać czas na optymalizację.

Lighthouse działa w dwóch środowiskach. Dane laboratoryjne (lab data) pochodzą ze środowiska symulowanego z kontrolowanym dławieniem sieci i spowolnieniem procesora. Dane terenowe (field data) pochodzą od rzeczywistych użytkowników poprzez Chrome User Experience Report (CrUX). Wyniki, które widzisz uruchamiając Lighthouse w Chrome DevTools, to dane laboratoryjne. Wyniki, których Google używa do celów rankingowych (Core Web Vitals), pochodzą z danych terenowych. To rozróżnienie ma znaczenie, ponieważ wyniki laboratoryjne i terenowe często znacznie się różnią, a optymalizacja pod jedno niekoniecznie poprawia drugie.

Dla sklepów PrestaShop Lighthouse jest szczególnie odkrywczy, ponieważ domyślna konfiguracja PrestaShop i większość motywów nie są zoptymalizowane pod współczesne standardy wydajności. Typowy niezoptymalizowany sklep PrestaShop uzyskuje wyniki między 15 a 40 w Wydajności, 60 do 80 w Dostępności, 70 do 85 w Najlepszych praktykach i 75 do 90 w SEO. Te bazowe wyniki mówią, gdzie leżą największe szanse na poprawę.

Wynik Wydajności: Najbardziej złożona kategoria

Wynik Wydajności to ważona kompozycja sześciu metryk. Każda metryka uchwyca inny aspekt szybkości ładowania i interaktywności strony. Zrozumienie poszczególnych metryk jest znacznie bardziej przydatne niż skupianie się na ogólnej liczbie.

Largest Contentful Paint (LCP)

LCP mierzy moment, w którym największy widoczny element treści kończy renderowanie. Na stronie produktu PrestaShop jest to zazwyczaj główne zdjęcie produktu. Na stronie kategorii może to być pierwszy obraz produktu lub baner kategorii. Google uznaje LCP za dobry, gdy wynosi poniżej 2,5 sekundy, wymaga poprawy między 2,5 a 4 sekund, i jest słaby powyżej 4 sekund.

Problemy z LCP specyficzne dla PrestaShop obejmują przewymiarowane obrazy produktów serwowane bez odpowiedniego responsywnego wymiarowania, blokujące renderowanie CSS z modułów ładowanych na każdej stronie, czasy odpowiedzi serwera spowolnione przez niezoptymalizowane zapytania bazodanowe (szczególnie na stronach kategorii z wieloma produktami) oraz JavaScript modułów zewnętrznych opóźniający potok renderowania.

Aby poprawić LCP w PrestaShop, zacznij od optymalizacji obrazów. Upewnij się, że obrazy produktów są prawidłowo wymiarowane dla każdego kontekstu (nie serwuj obrazu 2000x2000 gdy obszar wyświetlania to 400x400). Włącz lazy loading dla obrazów poniżej widocznej części strony, ale upewnij się, że obraz LCP NIE jest ładowany leniwie, ponieważ opóźnia to jego renderowanie. Zaimplementuj wskazówki preload dla obrazu LCP używając tagu <link rel="preload"> w nagłówku strony. Po stronie serwera włącz OPcache, skonfiguruj cache zapytań MySQL i upewnij się, że hosting ma odpowiednie zasoby.

Cumulative Layout Shift (CLS)

CLS mierzy stabilność wizualną. Za każdym razem, gdy widoczny element zmienia pozycję po początkowym renderowaniu, przyczynia się do wyniku CLS. Google uznaje CLS za dobry, gdy jest poniżej 0,1, wymaga poprawy między 0,1 a 0,25, i jest słaby powyżej 0,25.

Sklepy PrestaShop często cierpią na CLS spowodowany przez obrazy ładowane bez zdefiniowanych wymiarów (przeglądarka nie wie, ile miejsca zarezerwować, więc treść przeskakuje gdy obraz się załaduje), fonty webowe ładujące się i powodujące przepływanie tekstu (FOUT, Flash of Unstyled Text), dynamicznie wstrzykiwane banery lub paski powiadomień z modułów, banery zgody na ciasteczka wypychające treść strony w dół, oraz leniwie ładowane obrazy produktów w siatkach przesuwające otaczające produkty gdy się pojawiają.

Naprawienie CLS w PrestaShop wymaga ustawienia jawnych atrybutów width i height na wszystkich obrazach (lub użycia CSS aspect-ratio), preloadowania krytycznych fontów webowych z font-display: swap lub font-display: optional, rezerwowania miejsca na elementy dynamiczne jak banery ciasteczek używając CSS min-height, oraz zapewnienia, że moduły reklamowe lub promocyjne wstrzykują treść bez przesuwania istniejących elementów.

First Contentful Paint (FCP)

FCP mierzy moment pojawienia się pierwszego elementu treści na ekranie. Może to być tekst, obraz, SVG lub element canvas. Dla PrestaShop FCP jest silnie zależny od czasu odpowiedzi serwera (Time to First Byte) i ilości zasobów blokujących renderowanie (CSS i JavaScript), które muszą zostać pobrane zanim przeglądarka może cokolwiek wyrenderować.

Domyślna konfiguracja PrestaShop ładuje znaczną ilość CSS i JavaScript synchronicznie w nagłówku każdej strony. Każdy zainstalowany moduł może dodawać własne pliki CSS i JavaScript. Sklep z 30 modułami może ładować od 15 do 25 oddzielnych plików CSS i od 20 do 30 plików JavaScript zanim pojawi się jakąkolwiek treść. To bezpośrednio zwiększa FCP.

Total Blocking Time (TBT)

TBT mierzy łączny czas między FCP a Time to Interactive, w którym główny wątek był zablokowany wystarczająco długo, aby zapobiec responsywności na interakcje. Każde zadanie dłuższe niż 50 milisekund ma swój nadmiarowy czas wliczany do TBT. Na przykład 200-milisekundowe zadanie przyczynia się 150 milisekund do TBT.

Sklepy PrestaShop są znane z wysokich wartości TBT. Typowe przyczyny to jQuery i jego wtyczki wykonywane synchronicznie, JavaScript modułów wykonujący ciężkie manipulacje DOM przy ładowaniu strony, kod analityczny i śledzący z wielu modułów, skrypty stron produktowych inicjalizujące slidery, funkcje zoomu i selektory kombinacji jednocześnie, oraz widgety czatu i embedy mediów społecznościowych.

Zmniejszenie TBT wymaga odroczenia niekrytycznego JavaScriptu, rozbicia długich zadań na mniejsze asynchroniczne fragmenty, usunięcia nieużywanego JavaScriptu modułów i ładowania widgetów zewnętrznych po tym, jak strona stanie się interaktywna.

Speed Index

Speed Index mierzy, jak szybko widoczny obszar strony jest zapełniany. Uchwyca ogólny wizualny postęp ładowania strony. Strona, na której nagłówek, nawigacja i pierwszy rząd produktów pojawiają się szybko, ale reszta ładuje się stopniowo, będzie miała lepszy Speed Index niż strona, gdzie wszystko pojawia się naraz po długim opóźnieniu.

Dla PrestaShop Speed Index poprawia się, gdy priorytetyzujesz renderowanie treści powyżej linii zagięcia (above-the-fold). Oznacza to wstawianie krytycznego CSS inline (CSS potrzebny do renderowania widocznej części strony bez przewijania), odraczanie obrazów poniżej widocznej części i unikanie JavaScriptu blokującego renderowanie widocznej treści.

Interaction to Next Paint (INP)

INP zastąpił First Input Delay (FID) jako Core Web Vital w marcu 2024. Mierzy responsywność strony przez cały jej cykl życia, nie tylko przy pierwszej interakcji. Każde kliknięcie, dotknięcie i naciśnięcie klawisza jest mierzone, a najgorsza latencja interakcji (w przybliżeniu) staje się wartością INP. Google uznaje INP za dobry poniżej 200 milisekund.

Sklepy PrestaShop często mają słaby INP na stronach produktów, gdzie kliknięcie atrybutu kombinacji wyzwala synchroniczne żądanie AJAX blokujące interfejs, na stronach kategorii, gdzie kliknięcia filtrów fasatowych powodują ciężkie przetwarzanie JavaScript, oraz na każdej stronie, gdzie JavaScript modułu monopolizuje główny wątek podczas interakcji użytkownika.

Wynik Dostępności

Wynik Dostępności ocenia, czy strona może być używana przez osoby z niepełnosprawnościami, w tym korzystające z czytników ekranu, nawigacji klawiaturowej lub innych technologii wspomagających. Lighthouse sprawdza konkretne elementy zgodności z WCAG 2.1 i przypisuje każdemu wagę na podstawie wpływu na użytkownika.

Typowe problemy z Dostępnością w PrestaShop

Brakujący tekst alt na obrazach to najczęstszy problem. Sklepy PrestaShop z tysiącami produktów często mają produkty przesłane bez opisów tekstu alt. Lighthouse oznacza każdy obraz bez atrybutu alt. Naprawa polega na dodaniu znaczącego tekstu alt do wszystkich obrazów produktów przez panel administracyjny, co również pomaga SEO.

Niewystarczający kontrast kolorów jest niezwykle powszechny w motywach PrestaShop. Projektant motywu mógł wybrać kolory, które wyglądają atrakcyjnie wizualnie, ale nie spełniają minimalnego współczynnika kontrastu WCAG 4.5:1 dla normalnego tekstu i 3:1 dla dużego tekstu. Typowe problemy to jasnoszary tekst na białym tle (często używany dla cen produktów, opisów lub linków w stopce), biały tekst na kolorowych przyciskach, gdzie kolor nie jest wystarczająco ciemny, oraz tekst zastępczy w polach wyszukiwania.

Brakujące etykiety formularzy dotyczą formularzy wyszukiwania, formularzy zapisu do newslettera i formularzy kontaktowych PrestaShop. Wiele motywów używa tekstu zastępczego jako jedynego wskazania przeznaczenia pola wprowadzania, ale tekst zastępczy nie jest dostępną etykietą. Każde pole musi mieć powiązany element <label>.

Nieprawidłowa hierarchia nagłówków jest powszechna, gdy motywy pomijają poziomy nagłówków (przeskakując z <h1> do <h3>) lub gdy moduły wstrzykują treść z poziomami nagłówków, które łamią kontur dokumentu strony.

Brakujące atrybuty ARIA na elementach interaktywnych jak menu rozwijane, okna modalne i interfejsy zakładek oznaczają, że czytniki ekranu nie mogą przekazać celu i stanu tych elementów użytkownikom.

Realistyczne cele Dostępności

Większość motywów PrestaShop z odpowiednim nakładem pracy może osiągnąć 85 do 95. Idealne 100 jest osiągalne, ale wymaga modyfikacji szablonów motywu, które mogą zostać nadpisane podczas aktualizacji. Skup się najpierw na elementach o największym wpływie: tekst alt obrazów, kontrast kolorów, etykiety formularzy i nawigacja klawiaturowa dla głównych ścieżek użytkownika (przeglądanie, dodanie do koszyka, kasa).

Wynik Najlepszych praktyk

Kategoria Najlepszych praktyk obejmuje ogólne sygnały jakości w programowaniu webowym: użycie HTTPS, unikanie przestarzałych API, brak błędów w konsoli i nagłówki bezpieczeństwa.

Typowe problemy z Najlepszymi praktykami w PrestaShop

Błędy w konsoli przeglądarki są oznaczane przez Lighthouse. Sklepy PrestaShop często mają błędy JavaScript wynikające z konfliktów modułów, przestarzałe wywołania funkcji jQuery lub nieudane żądania AJAX. Każdy błąd konsoli obniża wynik Najlepszych praktyk. Sprawdź konsolę przeglądarki na każdym typie strony (strona główna, kategoria, produkt, koszyk, kasa) i napraw lub wyeliminuj błędy.

Brakujące nagłówki bezpieczeństwa obniżają wynik. PrestaShop domyślnie nie ustawia nagłówków takich jak Content-Security-Policy, X-Content-Type-Options, Permissions-Policy czy Referrer-Policy. Dodanie ich przez .htaccess lub konfigurację serwera WWW poprawia wynik Najlepszych praktyk i bezpieczeństwo witryny.

Przestarzałe API generują ostrzeżenia, gdy starsze motywy lub moduły PrestaShop używają API JavaScript wycofanych przez przeglądarki. Typowe przykłady to document.write(), synchroniczny XMLHttpRequest i nasłuchiwanie zdarzenia unload. Zwykle znajdują się w starszych modułach, które nie zostały zaktualizowane pod współczesne standardy przeglądarek.

Mieszana treść (ładowanie zasobów HTTP na stronie HTTPS) jest surowo oznaczana. Zdarza się, gdy zasoby modułów, zewnętrzne fonty lub piksele śledzące używają URL-i HTTP. Upewnij się, że wszystkie zasoby ładują się przez HTTPS.

Obrazy bez jawnych atrybutów width i height (co również wpływa na CLS w Wydajności) są tutaj również oznaczane. Motywy PrestaShop używające wyłącznie CSS do wymiarowania obrazów bez ustawiania atrybutów HTML uruchamiają ten test.

Realistyczne cele Najlepszych praktyk

Dobrze utrzymany sklep PrestaShop powinien celować w 90 do 100. Większość problemów z Najlepszymi praktykami jest prosta do naprawienia poprzez konfigurację serwera i czyszczenie modułów.

Wynik SEO

Audyt SEO sprawdza podstawowe wymagania technicznego SEO. Jest to najłatwiejsza kategoria do uzyskania wysokiego wyniku, ponieważ testy są proste, a PrestaShop obsługuje wiele z nich domyślnie.

Co Lighthouse sprawdza w SEO

Audyt weryfikuje, czy strona ma prawidłowy tag <title>, meta opis, prawidłowy meta tag viewport, czy linki mają opisowy tekst (nie tylko "kliknij tutaj"), czy strona nie jest zablokowana przed indeksowaniem, czy obrazy mają atrybuty alt, czy dokument ma prawidłowy hreflang jeśli obsługuje wiele języków, czy rozmiar czcionki jest czytelny na urządzeniach mobilnych i czy cele dotykowe (przyciski, linki) są odpowiednio wymiarowane i rozmieszczone.

Typowe problemy SEO w PrestaShop

Brakujące lub zduplikowane meta opisy są powszechne na stronach kategorii, szczególnie tych generowanych automatycznie. PrestaShop pozwala ustawiać meta opisy per kategoria i per produkt, ale wielu właścicieli sklepów zostawia te pola puste podczas masowych importów produktów.

Nieopisowy tekst linków pojawia się, gdy motywy używają ogólnego tekstu jak "Czytaj więcej" lub "Szczegóły" dla linków produktowych bez dodatkowego kontekstu. Zarówno czytniki ekranu, jak i Lighthouse oznaczają takie linki.

Małe cele dotykowe wpływają na użytkowników mobilnych. Motywy PrestaShop ze zwartymi siatkami produktów na urządzeniach mobilnych mogą mieć linki i przyciski zbyt blisko siebie lub zbyt małe. Google zaleca minimalny cel dotykowy o wymiarach 48x48 pikseli CSS z co najmniej 8 pikselami odstępu między sąsiednimi celami.

Zablokowane zasoby mogą powodować, że Lighthouse zgłasza niedostępność plików JavaScript lub CSS. Zdarza się to, gdy robots.txt blokuje dostęp do katalogów z zasobami. Domyślny robots.txt PrestaShop czasami blokuje katalogi zawierające pliki CSS lub JavaScript potrzebne do renderowania.

Realistyczne cele SEO

Sklep PrestaShop powinien celować w 90 do 100 w audycie SEO. Większość elementów to proste poprawki konfiguracyjne. Jedynym ciągłym wyzwaniem jest tekst alt obrazów w sklepach z dużymi katalogami i historycznymi importami, które pomijały tekst alt.

Dane laboratoryjne vs. dane terenowe

Zrozumienie różnicy między danymi laboratoryjnymi a terenowymi jest kluczowe dla prawidłowej interpretacji wyników Lighthouse i ustalania priorytetów optymalizacji.

Dane laboratoryjne (Lighthouse)

Gdy uruchamiasz Lighthouse z Chrome DevTools lub linii poleceń, tworzy on symulowane środowisko. Dławi połączenie sieciowe (typowo do wolnego 4G o prędkości około 1,6 Mbps z latencją 150 ms) i spowalnia procesor (typowo 4-krotne spowolnienie). To symulowane środowisko daje spójne, powtarzalne wyniki, ale nie odzwierciedla doświadczenia żadnego konkretnego rzeczywistego użytkownika.

Dane laboratoryjne są przydatne do debugowania konkretnych problemów, porównywania wyników przed i po optymalizacji, oraz identyfikowania konkretnych wąskich gardeł w procesie ładowania. Ale wyniki nie powinny być traktowane jako reprezentacja rzeczywistego doświadczenia użytkownika.

Dane terenowe (CrUX)

Chrome User Experience Report (CrUX) zbiera rzeczywiste dane wydajnościowe od użytkowników Chrome, którzy wyrazili zgodę na raportowanie statystyk użytkowania. Te dane są agregowane na 75. percentylu, co oznacza, że raportowana wartość reprezentuje doświadczenie 75 procent użytkowników będących na tym poziomie lub lepszych od tego progu.

Dane terenowe to właśnie te, których Google faktycznie używa jako sygnałów rankingowych poprzez Core Web Vitals. Możesz zobaczyć swoje dane terenowe w Google Search Console w raporcie Core Web Vitals, w PageSpeed Insights (który pokazuje zarówno dane laboratoryjne, jak i terenowe) oraz poprzez API CrUX lub zbiór danych BigQuery.

Dlaczego wyniki się różnią

Wyniki laboratoryjne są zazwyczaj niższe niż wyniki terenowe dla sklepów PrestaShop, ponieważ Lighthouse stosuje agresywne dławienie. Sklep na szybkim serwerze z CDN może uzyskać 35 w trybie laboratoryjnym Lighthouse, ale mieć całkowicie akceptowalne metryki terenowe, ponieważ prawdziwi użytkownicy na przyzwoitych połączeniach doświadczają sklepu znacznie szybciej niż symulowane wolne środowisko 4G. I odwrotnie, sklepy z problemami, które manifestują się tylko w warunkach rzeczywistych (błędy JavaScript z konkretnych wersji przeglądarek, spowolnienia widgetów zewnętrznych lub latencja geograficzna do użytkowników oddalonych od serwera) mogą mieć lepsze wyniki laboratoryjne niż terenowe.

Co priorytetyzować

Dla celów rankingowych Google priorytetyzuj dane terenowe i Core Web Vitals (LCP, INP, CLS). Do debugowania i pracy optymalizacyjnej używaj danych laboratoryjnych, ponieważ są spójne i dają szczegółowe informacje diagnostyczne. Jeśli Twoje dane terenowe pokazują pozytywne Core Web Vitals, ale Twój laboratoryjny wynik Wydajności to 40, Twoi użytkownicy są w porządku i Google Cię nie ukarze. Jeśli Twój wynik laboratoryjny to 90, ale dane terenowe pokazują negatywne Core Web Vitals, masz problem, którego testowanie laboratoryjne nie wychwytuje.

Realistyczne cele wyników dla PrestaShop

Ustalenie realistycznych celów zapobiega zmarnowanemu wysiłkowi w pogoni za malejącymi zwrotami. Oto osiągalne cele dla typowego sklepu PrestaShop 1.7 lub 8.x.

Wydajność: 50 do 75 (Mobile), 80 do 95 (Desktop)

Mobilne wyniki Wydajności powyżej 75 są niezwykle trudne do osiągnięcia dla sklepów PrestaShop z bogatymi stronami produktów, wieloma modułami i dynamiczną treścią. Dławiona symulacja mobilna jest surowa. Wynik 50 do 65 na urządzeniach mobilnych z pozytywnymi Core Web Vitals w danych terenowych to dobry rezultat. Wyniki desktopowe 85 do 95 są osiągalne przy standardowych optymalizacjach.

Nie gań się za mobilnym wynikiem Wydajności 100. Wysiłek potrzebny do przejścia z 70 do 100 na urządzeniach mobilnych typowo wymaga usunięcia funkcjonalności, której Twój sklep potrzebuje (zoom obrazów produktów, dynamiczne aktualizacje koszyka, selektory kombinacji). Zamiast tego skup się na spełnieniu progów Core Web Vitals w danych terenowych.

Dostępność: 85 do 95

Ten zakres jest osiągalny z poprawkami szablonów motywu i dyscypliną w treści. Główny bieżący wysiłek to zapewnienie, że wszystkie nowe produkty mają tekst alt i że nowe moduły nie wprowadzają regresji dostępności.

Najlepsze praktyki: 90 do 100

Osiągalne z konfiguracją serwera, czyszczeniem błędów konsoli i aktualizowaniem modułów. Ten wynik ma tendencję do degradacji w czasie, gdy dodawane są nowe moduły, więc regularne monitorowanie pomaga.

SEO: 90 do 100

Najłatwiejszy do osiągnięcia i utrzymania. Większość elementów to jednorazowe poprawki konfiguracyjne.

Lista kontrolna działań optymalizacyjnych

Ta lista kontrolna priorytetyzuje optymalizacje według wpływu, zaczynając od zmian, które dają największe poprawy wyników przy najmniejszym wysiłku.

Wysoki wpływ, niski wysiłek

Włącz funkcję CCC (Combine, Compress, Cache) PrestaShop w ustawieniach Wydajności, aby scalać i minifikować pliki CSS i JavaScript. Dodaj atrybuty width i height do wszystkich obrazów w szablonach motywu. Ustaw jawne wymiary na obrazach produktów. Włącz cache przeglądarki przez odpowiednie nagłówki cache w konfiguracji serwera. Kompresuj zasoby tekstowe za pomocą Gzip lub Brotli. Usuń lub wyłącz moduły, których aktywnie nie używasz. Dodaj nagłówki bezpieczeństwa do konfiguracji serwera.

Wysoki wpływ, średni wysiłek

Zaimplementuj wstawianie krytycznego CSS inline dla treści powyżej linii zagięcia. Odrocz niekrytyczny JavaScript z atrybutem defer lub async. Optymalizuj i prawidłowo wymiaruj obrazy produktów (serwuj różne rozmiary dla różnych kontekstów używając srcset). Preloaduj krytyczne zasoby (obraz LCP, główne pliki fontów). Napraw wszystkie błędy konsoli przeglądarki. Dodaj brakujący tekst alt do wszystkich obrazów produktów i kategorii.

Średni wpływ, wyższy wysiłek

Zaimplementuj CDN dla zasobów statycznych i obrazów. Przejdź na bardziej wydajnościowo zorientowany motyw PrestaShop, jeśli Twój obecny motyw jest fundamentalnie wolny. Optymalizuj wydajność po stronie serwera (indeksy bazodanowe, OPcache, Redis do cache). Zaimplementuj serwowanie obrazów WebP z fallbackiem na JPEG. Audytuj i optymalizuj JavaScript modułów zewnętrznych pod kątem blokowania głównego wątku.

Monitorowanie w czasie

Jednorazowy audyt Lighthouse jest mniej wartościowy niż regularne monitorowanie. Wyniki zmieniają się w miarę dodawania produktów, instalowania modułów, aktualizowania motywów i modyfikowania konfiguracji. Skonfiguruj zautomatyzowane testowanie Lighthouse przy użyciu narzędzi takich jak API Google PageSpeed Insights, web.dev Measure lub self-hosted Lighthouse CI. Uruchamiaj testy co najmniej raz w tygodniu i po każdej znaczącej zmianie w sklepie.

Śledź zarówno ogólne wyniki, jak i poszczególne metryki. Spadek wyniku Wydajności z 65 do 55 jest niepokojący, ale wiedza, że został spowodowany przez regresję CLS z nowo zainstalowanego modułu banera, jest użyteczna i prowadzi do konkretnych działań. Bez śledzenia na poziomie metryk zgadujesz przyczyny.

Zwróć szczególną uwagę na Core Web Vitals w Google Search Console. Google aktualizuje te dane co miesiąc, a jakakolwiek regresja z "Dobrych" do "Wymaga poprawy" lub "Słabych" może wpłynąć na Twoje pozycje w wyszukiwarce. Skonfiguruj alerty o zmianach Core Web Vitals, aby móc zareagować, zanim wpływ stanie się widoczny w danych o ruchu.