Wymiar Core/Dash: Typ urządzenia

Wymiar: Typ urządzenia (d)

Wymiar Typ urządzenia dzieli dane z RUM (Real User Monitoring) na dwie kategorie: mobile oraz desktop. Jest to najważniejszy, pierwszy filtr w każdym badaniu wydajności, ponieważ środowiska mobilne i desktopowe są fundamentalnie różnymi środowiskami obliczeniowymi. Różne procesory, różne warunki sieciowe, różne rozmiary okna przeglądarki, różne silniki przeglądarek.

Jeśli analizujesz zagregowane metryki Core Web Vitals bez filtrowania według typu urządzenia, uśredniasz dwie populacje, które nie mają ze sobą prawie nic wspólnego. Taka średnia jest w najlepszym razie myląca.

Luka w wydajności mobilnej

Urządzenia mobilne odpowiadają za około 62% globalnego ruchu w sieci według Statista (2025). Mimo to, urządzenia mobilne konsekwentnie osiągają gorsze wyniki niż komputery stacjonarne. Według raportu 2025 Web Almanac, tylko 48% domen mobilnych zdaje wszystkie trzy metryki 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 napotykają na trzy ograniczenia, których nie mają komputery stacjonarne:

• Dławienie procesora (CPU throttling): Telefon z Androidem ze średniej półki ma około 3-5 razy mniejszą moc obliczeniową niż komputer stacjonarny. Kod JavaScript, który na desktopie wykonuje się w 50 ms, na urządzeniu mobilnym może zająć 200 ms, spychając INP poza próg „good”.
• Opóźnienia sieciowe (Network latency): Połączenia mobilne (4G/5G) charakteryzują się wyższymi czasami przesyłania pakietów w obie strony i większą zmiennością niż połączenia przewodowe. To zawyża TTFB oraz opóźnienie ładowania (Load Delay) LCP.
• Rozmiar okna przeglądarki (Viewport size): Mniejsze ekrany zmieniają to, który element staje się LCP. Twój główny obraz hero na desktopie może na urządzeniu mobilnym skurczyć się i wylądować poniżej bloku tekstu, całkowicie zmieniając cel optymalizacji.

Dystrybucja typów urządzeń w CoreDash

W projektach CoreDash, typowy podział ruchu to 65% mobile i 35% desktop. Strony e-commerce jeszcze silniej skłaniają się ku urządzeniom mobilnym (70-75%), podczas gdy produkty B2B SaaS często notują podział 50/50 lub wręcz dominację desktopu.

Luka wydajnościowa w danych CoreDash odzwierciedla globalny trend. LCP dla p75 na urządzeniach mobilnych wynosi średnio 2.8 s w porównaniu do 1.9 s na desktopie. W przypadku INP przepaść jest jeszcze większa: p75 dla urządzeń mobilnych oscyluje wokół 220 ms, podczas gdy na desktopie utrzymuje się blisko 120 ms.

Analiza specyficzna dla poszczególnych metryk

Largest Contentful Paint (LCP)

LCP na urządzeniach mobilnych jest niemal zawsze gorsze niż na desktopie. Główną przyczyną jest opóźnienie ładowania (Load Delay): przeglądarki mobilne odkrywają obraz LCP później, ponieważ HTML dociera dłużej (wyższe TTFB), a skaner wstępnego ładowania (preload scanner) konkuruje z większą liczbą zasobów na wolniejszym procesorze. Jeśli Twój LCP na desktopie wynosi poniżej 2.0 s, ale na urządzeniach mobilnych przekracza 3.0 s, problem rzadko leży w samym pliku obrazu. Winny jest proces dostarczania (delivery pipeline).

Interaction to Next Paint (INP)

To tutaj różnica między urządzeniami uderza najmocniej. Procedury obsługi zdarzeń JavaScript, które wydają się natychmiastowe na procesorze i7 w komputerze stacjonarnym, mogą zablokować wątek główny na ponad 300 ms na Snapdragonie 665. Przefiltruj dane pod kątem urządzeń mobilnych, posortuj według wpływu na INP, a znajdziesz dokładnie te interakcje, które psują się na prawdziwych telefonach. Widzę to bez przerwy: programiści testują na MacBookach Pro i wdrażają interakcje, które są nieużywalne na urządzeniach, które 65% ich użytkowników faktycznie nosi w kieszeni.

Cumulative Layout Shift (CLS)

Różnice w CLS między typami urządzeń zazwyczaj sprowadzają się do projektowania responsywnego (responsive design). Miejsca na reklamy, które rezerwują przestrzeń na desktopie, mogą się zapadać lub zmieniać rozmiar na urządzeniach mobilnych. Metryki czcionek fallback, które są dopasowane na desktopie, powodują widoczne przesunięcia w mniejszych oknach przeglądarki. Czcionki internetowe renderują się inaczej w przeglądarkach mobilnych i desktopowych, a fizyczna gęstość pikseli wpływa na zaokrąglanie subpikselowe.

Proces debugowania

1. Zaczynaj każde badanie od filtru urządzenia: Zanim spojrzysz na jakikolwiek inny wymiar, podziel dane według typu urządzenia (Device Type). Jeśli Twój zagregowany LCP wynosi 2.5 s, może się okazać, że na desktopie wynosi on 1.8 s, a na urządzeniach mobilnych 3.1 s. „Problem” dotyczy wyłącznie urządzeń mobilnych.
2. Porównuj rozkłady, nie tylko p75: Sprawdź rozkład good/needs-improvement/poor dla każdego typu urządzenia. Desktop z wynikiem 85% „good” i mobile z wynikiem 45% „good” opowiadają zupełnie inną historię niż sam percentyl p75.
3. Łącz z innymi wymiarami: Gdy już wyizolujesz typ urządzenia, dodaj drugi filtr. Typ urządzenia + Kraj (Country) ujawnia, czy luka mobilna ma charakter globalny, czy koncentruje się w regionach z wolniejszymi sieciami. Typ urządzenia + Typ nawigacji (Navigation Type) pokazuje, czy wsteczna i przednia nawigacja mobilna jest prawidłowo buforowana.

Inżynieryjna zasada ogólna

• Mobile LCP poniżej 2.5 s: To próg, którego Google używa dla oceny „good”. Jeśli desktop go zdaje, ale mobile oblewają, skup się na zmniejszeniu opóźnienia ładowania Load Delay (fetchpriority, preload) oraz TTFB (edge caching, CDN).
• Mobile INP poniżej 200 ms: Przetestuj każdą interaktywną funkcję na prawdziwym urządzeniu ze średniej półki z Androidem. Dławienie procesora (CPU throttling) w Chrome DevTools (4x) to dobre przybliżenie, ale testowanie na prawdziwym urządzeniu jest zawsze lepsze.
• Nigdy nie optymalizuj tylko pod kątem desktopu: Jeśli Twój ruch mobilny przekracza 50% (a prawie na pewno tak jest), to wydajność mobilna jest Twoim sygnałem w rankingu wyszukiwania. Google używa do rankingu danych CrUX dla urządzeń mobilnych.

Typ urządzenia nie jest tylko opcjonalnym, miłym dodatkiem w filtrowaniu. To pierwsze pytanie, jakie musisz zadać: „Czy jest to problem mobilny, czy desktopowy?”. Każda decyzja dotycząca optymalizacji wynika z tej odpowiedzi.