Wymiar Core/Dash: Typ urządzenia

Wymiar: Typ urządzenia (d)

Wymiar Typ urządzenia dzieli twoje dane RUM na dwie kategorie: mobile i desktop. To najważniejszy, pierwszy filtr w każdej analizie wydajności. Mobile i desktop to fundamentalnie różne środowiska obliczeniowe: inne procesory, inne warunki sieciowe, inne rozmiary viewportu i inne silniki przeglądarek.

Jeśli patrzysz na zagregowane dane Core Web Vitals bez filtrowania po typie urządzenia, uśredniasz dwie populacje, które nie mają ze sobą prawie nic wspólnego. Taka średnia w najlepszym wypadku wprowadza w błąd.

Mobilna luka wydajności

Urządzenia mobilne generują około 62% globalnego ruchu w sieci według Statista (2025). Mimo to mobile stale osiąga gorsze wyniki niż desktop. Według 2025 Web Almanac tylko 48% mobilnych pochodnych (origins) zalicza wszystkie trzy Core Web Vitals, w porównaniu do 56% na desktopie. To luka rzędu 8 punktów procentowych.

Ta luka istnieje, ponieważ urządzenia mobilne mierzą się z trzema ograniczeniami, których nie ma desktop:

• CPU throttling: Średniej klasy telefon z Androidem ma około 3–5 razy mniejszą moc obliczeniową niż desktop. JavaScript, który wykonuje się w 50 ms na desktopie, na komórce może zająć 200 ms, co wypycha INP poza „dobry” próg.
• Opóźnienia sieciowe: Połączenia mobilne (4G/5G) charakteryzują się wyższym czasem RTT i większą zmiennością niż połączenia przewodowe. To podbija TTFB i LCP Load Delay.
• Rozmiar viewportu: Mniejsze ekrany zmieniają to, który element staje się LCP. Twój desktopowy obraz hero na komórce może zmniejszyć się i spaść pod blok tekstu, co całkowicie zmienia cel optymalizacji.

Rozkład typów urządzeń w CoreDash

W projektach CoreDash typowy podział ruchu to 65% mobile i 35% desktop. Witryny e-commerce mocniej skręcają w stronę mobile (70–75%), podczas gdy produkty B2B SaaS często odnotowują podział 50/50 lub nawet dominację desktopu.

Luka wydajności w danych CoreDash odzwierciedla globalny trend. Dla mobile p75 LCP wynosi średnio 2,8 s w porównaniu do 1,9 s na desktopie. W przypadku INP różnica jest jeszcze większa: mobilny p75 to około 220 ms, podczas gdy desktopowy oscyluje wokół 120 ms.

Analiza poszczególnych wskaźników

Largest Contentful Paint (LCP)

LCP na urządzeniach mobilnych jest prawie zawsze gorszy niż na desktopie. Główną przyczyną jest Load Delay: mobilne przeglądarki później odkrywają obraz LCP, ponieważ HTML dociera dłużej (wyższy TTFB), a preload scanner musi konkurować o ograniczone zasoby wolniejszego CPU. Jeśli twój desktopowy LCP wynosi poniżej 2,0 s, ale na mobile przekracza 3,0 s, problem rzadko tkwi w samym pliku obrazu. Winny jest proces dostarczania.

Interaction to Next Paint (INP)

Tutaj różnica między urządzeniami uderza najmocniej. Obsługa zdarzeń JavaScript, która na desktopowym procesorze i7 wydaje się natychmiastowa, na Snapdragonie 665 może zablokować main thread na ponad 300 ms. Odfiltruj ruch mobilny, posortuj według wpływu na INP, a znajdziesz dokładnie te interakcje, które nie działają na prawdziwych telefonach. Widzę to stale: deweloperzy testują kod na MacBookach Pro i wypuszczają interakcje nie do użytku na urządzeniach, które nosi przy sobie 65% ich użytkowników.

Cumulative Layout Shift (CLS)

Różnice w CLS między typami urządzeń zazwyczaj wynikają z responsywnego projektowania. Miejsca na reklamy rezerwujące przestrzeń na desktopie mogą się zapadać lub zmieniać rozmiar na urządzeniach mobilnych. Metryki czcionek fallback, które pasują na desktopie, powodują widoczne przesunięcia na mniejszych viewportach. Fonty sieciowe renderują się inaczej w przeglądarkach mobilnych i desktopowych, a fizyczna gęstość pikseli wpływa na zaokrąglanie subpikseli.

Schemat debugowania

1. Zaczynaj każdą analizę od filtra urządzeń: Zanim sprawdzisz jakikolwiek inny wymiar, podziel dane według Device Type. Jeśli twój zagregowany LCP wynosi 2,5 s, możesz odkryć, że desktop ma 1,8 s, a mobile 3,1 s. „Problem” leży wyłącznie po stronie mobile.
2. Porównuj rozkłady, a nie tylko p75: Sprawdź rozkład wskaźników good/needs-improvement/poor dla każdego typu urządzenia. Desktop z 85% dobrych wyników i mobile z 45% dobrych wyników pokazują zupełnie inny obraz sytuacji niż sam p75.
3. Łącz wymiary ze sobą: Gdy wyizolujesz już typ urządzenia, dodaj drugi filtr. Device Type + Country pokaże, czy luka mobilna jest globalna, czy dotyczy tylko regionów z wolniejszą siecią. Device Type + Navigation Type zdradzi, czy mobilne nawigacje wstecz/w przód korzystają z cache.

Praktyczne zasady

• Mobilny LCP poniżej 2,5 s: To próg określony przez Google jako „dobry”. Jeśli desktop go zalicza, a mobile nie, skup się na skróceniu Load Delay (fetchpriority, preload) oraz obniżeniu TTFB (edge caching, CDN).
• Mobilny INP poniżej 200 ms: Przetestuj każdą interakcję na prawdziwym telefonie z Androidem ze średniej półki. Dławienie procesora (CPU throttling 4x) w Chrome DevTools daje pewne przybliżenie, ale testy na fizycznym sprzęcie są lepsze.
• Nigdy nie optymalizuj wyłącznie pod desktop: Jeśli twój ruch mobilny przekracza 50% (a prawie na pewno tak jest), wydajność na komórkach staje się twoim sygnałem rankingowym. Google używa do rankingu mobilnych danych CrUX.

Device Type to nie jest opcjonalny dodatek. To pierwsze pytanie, jakie musisz zadać: „Czy to problem na urządzeniach mobilnych, czy na desktopie?”. Każda decyzja optymalizacyjna wynika właśnie z tej odpowiedzi.