Wymiar Core/Dash: Możliwości Urządzenia i Klienta

Co mierzą te wymiary

CoreDash udostępnia dwa wymiary w kategorii Możliwości Urządzenia i Klienta (Device & Client Capability). Odpowiadają one na różne pytania, ale bezpośrednio się uzupełniają.

Device Memory (kod grupy m) raportuje przedział pamięci RAM, który przeglądarka zwraca z navigator.deviceMemory. Specyfikacja celowo zaokrągla wartość w dół do najbliższej potęgi liczby dwa i ogranicza wynik, dlatego zobaczysz wartości 0.25, 0.5, 1, 2, 4 lub 8+ GB zamiast dokładnych liczb. Takie zaokrąglenie jest zamierzone: ogranicza precyzję dostępną dla skryptów śledzących (fingerprinting), jednocześnie dając deweloperom użyteczny sygnał.

Client Capability Score (kod grupy ccs) to wskaźnik złożony, obliczany przez CoreDash na podstawie trzech sygnałów udostępnianych przez przeglądarkę: pamięci urządzenia, navigator.hardwareConcurrency (logiczne rdzenie procesora) oraz efektywnego typu połączenia z Network Information API. Wynikiem jest jeden z sześciu przedziałów:

Wskaźnik złożony jest znacznie bardziej użyteczny niż jakikolwiek pojedynczy sygnał w izolacji. Urządzenie z 4 GB RAM na połączeniu 2G zachowuje się zupełnie inaczej niż to samo urządzenie w sieci Wi-Fi. Połączenie pamięci, liczby rdzeni i typu połączenia w jedną skalę porządkową pozwala na filtrowanie i porównywanie danych o wydajności bez konieczności przeprowadzania osobnych analiz dla każdej zmiennej.

Wsparcie przeglądarek i pokrycie danych

navigator.deviceMemory to API dostępne wyłącznie w silniku Chromium. Firefox i Safari go nie udostępniają, co oznacza, że te przeglądarki zawsze raportują wartość Nieznane (Unknown - CCS 0) dla komponentu pamięci. W praktyce Chrome i przeglądarki oparte na Chrome odpowiadają za większość ruchu na systemie Android, a to właśnie na urządzeniach z Androidem koncentrują się problemy z małą ilością pamięci. Sygnał jest więc najbardziej dostępny dokładnie tam, gdzie ma to największe znaczenie.

Nagłówek HTTP Device Memory (Device-Memory) to osobny mechanizm, który pozwala serwerowi odczytać tę samą wartość z żądania negocjowanego za pomocą Accept-CH. CoreDash używa API JavaScript gromadzonego w czasie ładowania strony, dzięki czemu wartość jest przesyłana z beaconem RUM i nie wymaga po stronie serwera konfiguracji nagłówków.

Dlaczego możliwości urządzenia mają znaczenie dla Core Web Vitals

LCP to głównie problem z siecią i renderowaniem. INP to przede wszystkim problem procesora (CPU) i pamięci. Właśnie z powodu tego rozróżnienia, wymiar CCS jest najbardziej widoczny w danych INP.

Długie zadania (long tasks) w wątku głównym blokują reakcję na wejście. Na urządzeniu z 1 GB RAM przeglądarka jest już pod presją pamięci, zanim Twój JavaScript w ogóle zostanie uruchomiony: bardziej agresywne odśmiecanie pamięci, częstsze odrzucanie kart i mniejszy zapas na kompilację JIT przekładają się bezpośrednio na dłuższy czas trwania zadań. Witryna, która zalicza INP na nowoczesnym telefonie z wynikiem 180 ms, może z łatwością osiągać 400 ms na mocno ograniczonym (Constrained) urządzeniu.

Rozdział o wydajności w Web Almanac 2025 potwierdza ten trend: wskaźniki zdawalności INP na urządzeniach mobilnych osiągają ogółem 77%, ale w tej liczbie widać ogromną przepaść między urządzeniami o wysokiej i niskiej wydajności. Mniej więcej 29% użytkowników mobilnego internetu korzysta z urządzeń trzykrotnie słabszych niż obecne flagowce. Na większości rynków globalnych tacy użytkownicy nie stanowią wyjątków; są oni wręcz medianą odwiedzających.

CLS jest mniej podatne na klasę sprzętu niż INP, ale urządzenia z wolnymi procesorami wciąż mogą powodować przesunięcia układu (layout shifts), gdy czcionki lub późno ładujące się obrazy wywołują przeliczenia układu (reflows), które kończą się już po zatwierdzeniu klatki przez przeglądarkę.

Jak używać CCS i Device Memory w CoreDash

Najbardziej produktywny przepływ pracy to rozpoczęcie od CCS jako filtra, a następnie użycie Device Memory do potwierdzenia postawionej hipotezy.

Najpierw otwórz swój rozkład INP według CCS. Jeśli 75. percentyl INP jest dobry dla odwiedzających z urządzeniami bardzo wydajnymi (Very Capable - CCS 1) i wydajnymi (Capable - CCS 2), ale zawodzi dla urządzeń ograniczonych (Limited - CCS 3) i niższych, to masz wąskie gardło związane z procesorem (CPU) lub pamięcią, a nie z siecią. Eliminuje to całą kategorię poprawek (preloading, podpowiedzi połączeń, optymalizacja CDN) i skupia Twoją uwagę na czasie wykonywania JavaScript: długich zadaniach (long tasks), obciążeniu obsługi zdarzeń wejścia oraz skryptach stron trzecich, które uruchamiają się przy każdej interakcji.

Następnie przefiltruj dane po Device Memory, aby zobaczyć, które przedziały pamięci RAM generują najgorsze wyniki. Jeśli urządzenia z 1 GB RAM odpowiadają za nieproporcjonalnie duży udział słabych wyników INP, znasz już próg. Skrypty, które są akceptowalne przy 4 GB, na podstawie samych tych danych, mogą stać się kandydatami do odroczenia lub usunięcia.

W przypadku witryn o globalnym zasięgu, połącz CCS z wymiarem Country (Kraj). Rynki Azji Południowej i Południowo-Wschodniej, Afryka Subsaharyjska oraz części Ameryki Łacińskiej mają wysokie nagromadzenie urządzeń mocno i bardzo ograniczonych (Constrained i Very Limited). Zestawienie CCS przefiltrowane po kraju pokaże Ci, gdzie różnica jest największa i pomoże ustalić priorytety, którym rynkiem należy zająć się w pierwszej kolejności.

Przedział Nieznane (Unknown - CCS 0) obejmuje cały ruch z Firefoksa i Safari oraz każdą sesję, w której API nie zwróciły żadnej wartości. Nie ignoruj go. W witrynach ze znaczącym udziałem Firefoksa lub Safari, kategoria ta może stanowić jedną czwartą lub więcej wszystkich sesji. Nie oznacza to, że użytkownicy ci mają słabe urządzenia; to znaczy tylko, że sygnał był niedostępny. Traktuj Unknown jako odrębny segment, zamiast włączać go do swojej bazy odniesienia.

Co zrobić z tymi danymi

Jeśli odwiedzający z CCS 3, 4 lub 5 stanowią ponad 15% Twojego ruchu, a ich INP konsekwentnie przekracza 200 ms, zestaw poprawek jest bardzo konkretny:

• Profiluj swoje najdłuższe zadania na ograniczonym (throttled) urządzeniu w narzędziach Chrome DevTools. Przypisanie zadań (Task Attribution) w panelu Performance pokaże, które skrypty są za nie odpowiedzialne.
• Przesuń niekrytyczne skrypty stron trzecich pod wyzwalacze oparte na interakcji lub widoczności, tak aby nie konkurowały o wątek główny w początkowym oknie ładowania.
• Zmniejsz rozmiar paczek (bundle) JavaScript na ścieżkach krytycznych. Każdy kilobajt parsowany na urządzeniu z małą ilością pamięci kosztuje więcej niż na flagowcu, ponieważ kompilator JIT ma mniej miejsca na buforowanie skompilowanego kodu.
• Użyj scheduler.yield() lub setTimeout(0), aby rozbić długie zadania i dać przeglądarce szansę na przetwarzanie zdarzeń wejścia pomiędzy porcjami kodu.

CoreDash eksponuje wymiary CCS i Device Memory obok każdej metryki Core Web Vitals, dzięki czemu możesz potwierdzić, czy poprawka, która ulepszyła INP na zaawansowanych urządzeniach, polepszyła także wyniki odwiedzających korzystających z urządzeń mocno ograniczonych (Constrained), a nie tylko użytkowników z najlepszym sprzętem.