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. Odpowiadają one na różne pytania, ale bezpośrednio się uzupełniają.

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

Wynik możliwości klienta (Client Capability Score) (kod grupy ccs) to wartość złożona obliczana 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:

Złożony wynik 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 połączone z siecią Wi-Fi. Połączenie pamięci, liczby rdzeni i typu połączenia w jedną skalę porządkową pozwala filtrować i porównywać dane dotyczące wydajności bez konieczności tworzenia osobnych zestawień dla każdej zmiennej.

Obsługa przez przeglądarki i pokrycie danych

Interfejs API navigator.deviceMemory jest dostępny wyłącznie w przeglądarkach opartych na silniku Chromium. Firefox i Safari go nie udostępniają, co oznacza, że te przeglądarki zawsze raportują stan Nieznany (CCS 0) dla komponentu pamięci. W praktyce Chrome i przeglądarki oparte na Chrome generują większość ruchu z systemu Android, a to właśnie tam najczęściej występują problemy z małą ilością pamięci. Sygnał ten jest więc najbardziej dostępny dokładnie tam, gdzie ma największe znaczenie.

Nagłówek HTTP Device Memory (Device-Memory) to oddzielny mechanizm, który pozwala serwerowi odczytać tę samą wartość z wynegocjowanego żądania Accept-CH. CoreDash korzysta z interfejsu API JavaScript pobieranego w momencie ładowania strony, dzięki czemu wartość przemieszcza się razem z pakietem danych RUM, nie wymagając konfiguracji nagłówków po stronie serwera.

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

LCP to przede wszystkim problem z siecią i renderowaniem. INP to głównie problem z procesorem i pamięcią. To właśnie ze względu na to rozróżnienie wymiar CCS jest najbardziej widoczny w danych INP.

Długie zadania w głównym wątku blokują reakcję na input. Na urządzeniu z 1 GB RAM przeglądarka odczuwa presję pamięci jeszcze zanim uruchomiony zostanie Twój kod JavaScript: bardziej agresywne odśmiecanie pamięci (garbage collection), częstsze odrzucanie kart i mniejszy zapas zasobów na kompilację JIT przekładają się bezpośrednio na dłuższy czas trwania zadań. Witryna, która przechodzi test INP na nowoczesnym telefonie z wynikiem 180 ms, może łatwo utknąć na 400 ms na urządzeniu mocno ograniczonym (Constrained).

Rozdział 2025 Web Almanac Performance potwierdza ten trend: odsetek udanych testów INP na urządzeniach mobilnych osiąga ogółem 77%, ale przepaść w tych statystykach między potężnymi urządzeniami a tymi z niższej półki jest bardzo szeroka. Około 29% mobilnych użytkowników sieci korzysta z urządzeń trzykrotnie słabszych niż obecne flagowce. Tacy użytkownicy na większości rynków globalnych to nie są wartości odstające; są oni medianą odwiedzających.

Wskaźnik CLS jest mniej wrażliwy na klasę sprzętu niż INP, ale urządzenia z wolnymi procesorami nadal mogą powodować przesunięcia układu (layout shifts), gdy czcionki lub późno ładujące się obrazy powodują przeliczenia układu (reflows), które kończą się po tym, jak przeglądarka wyrenderowała już klatkę.

Jak korzystać z CCS i Device Memory w CoreDash

Najbardziej produktywnym przepływem pracy jest rozpoczęcie od użycia CCS jako filtra, a następnie wykorzystanie Device Memory do potwierdzenia swojej hipotezy.

Najpierw otwórz zestawienie INP według CCS. Jeśli Twój 75. percentyl INP jest dobry dla bardzo wydajnych (CCS 1) i wydajnych (CCS 2) odwiedzających, ale psuje się w przypadku ograniczonych (CCS 3) i niżej, masz wąskie gardło na procesorze lub pamięci, a nie w sieci. Eliminuje to całą kategorię potencjalnych poprawek (preloading, wskazówki dotyczące połączeń, strojenie CDN) i skupia Twoją uwagę na czasie wykonywania JavaScript: długich zadaniach, ciężarze funkcji obsługi zdarzeń oraz skryptach stron trzecich, które uruchamiają się przy każdej interakcji.

Następnie filtruj według Device Memory, aby zobaczyć, które przedziały RAM generują najgorsze wyniki. Jeśli urządzenia z 1 GB odpowiadają za nieproporcjonalny udział słabych wyników INP, znasz już próg. Skrypty, które są akceptowalne przy 4 GB, mogą stać się kandydatami do opóźnienia lub usunięcia wyłącznie na podstawie tych danych.

W przypadku witryn o zasięgu globalnym połącz CCS z wymiarem Country (Kraj). Rynki Azji Południowej i Południowo-Wschodniej, Afryki Subsaharyjskiej oraz części Ameryki Łacińskiej mają wysokie nasycenie urządzeń mocno i bardzo ograniczonych. Zestawienie CCS przefiltrowane przez kraj pokaże Ci, gdzie różnica jest największa i pomoże ustalić priorytety rynkowe na początek.

Przedział Nieznany (CCS 0) obejmuje cały ruch z przeglądarek Firefox i Safari plus każdą sesję, w której interfejsy API nie zwróciły żadnej wartości. Nie ignoruj go. W witrynach o znaczącym udziale Firefoksa lub Safari, stan Nieznany może reprezentować jedną czwartą lub więcej wszystkich sesji. Nie oznacza to, że ci użytkownicy mają słabe urządzenia; oznacza to po prostu, że sygnał był niedostępny. Traktuj stan Nieznany jako osobny segment, zamiast wrzucać go do swojej wartości bazowej.

Co zrobić z danymi

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

• Profiluj swoje najdłuższe zadania na dławionym (throttled) urządzeniu w Chrome DevTools. Przypisanie zadań (Task Attribution) w panelu Performance wskaże, które skrypty są za nie odpowiedzialne.
• Przenieś niekrytyczne skrypty stron trzecich pod wyzwalacz interakcji lub widoczności, tak aby nie konkurowały o główny wątek w początkowym oknie ładowania.
• Zmniejsz rozmiar paczek JavaScript na krytycznych ścieżkach. Każdy kilobajt parsowany na urządzeniu o małej 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 podzielić długie zadania i dać przeglądarce szansę na przetworzenie zdarzeń pomiędzy fragmentami kodu.

CoreDash wyświetla wymiary CCS i Device Memory obok każdej metryki Core Web Vitals, abyś mógł potwierdzić, czy poprawka, która poprawiła INP na urządzeniach z wyższej półki, poprawiła również wskaźniki dla Twoich odwiedzających z mocno ograniczonym sprzętem, a nie tylko dla najbardziej optymalnych przypadków.