Core/Dash Dimensão: Dispositivo & Capacidade do Cliente

O que essas dimensões medem

O CoreDash expõe duas dimensões na categoria Dispositivo & Capacidade do Cliente. Elas respondem perguntas diferentes, mas se complementam diretamente.

Device Memory (código de grupo m) reporta o bucket de RAM que o navegador retorna de navigator.deviceMemory. A especificação deliberadamente arredonda para baixo para a potência de dois mais próxima e limita o resultado, então você verá valores de 0,25, 0,5, 1, 2, 4 ou 8+ GB em vez de valores exatos. Esse arredondamento é intencional: limita a precisão disponível para scripts de fingerprinting enquanto ainda fornece aos desenvolvedores um sinal utilizável.

Client Capability Score (código de grupo ccs) é um composto calculado pelo CoreDash a partir de três sinais expostos pelo navegador: device memory, navigator.hardwareConcurrency (núcleos lógicos de CPU) e o tipo de conexão efetiva da Network Information API. O resultado é um dos seis buckets:

A pontuação composta é mais útil do que qualquer sinal isolado. Um dispositivo com 4 GB de RAM em uma conexão 2G se comporta de forma muito diferente do mesmo dispositivo em Wi-Fi. Combinar memória, núcleos e tipo de conexão em uma escala ordinal única permite filtrar e comparar dados de desempenho sem executar uma análise separada para cada variável.

Suporte de navegador e cobertura de dados

navigator.deviceMemory é uma API exclusiva do Chromium. Firefox e Safari não a expõem, o que significa que esses navegadores sempre reportam Desconhecido (CCS 0) para o componente de memória. Na prática, Chrome e navegadores baseados em Chrome representam a maioria do tráfego Android, e dispositivos Android são onde as condições de pouca memória se concentram. Então o sinal está mais disponível exatamente onde mais importa.

O cabeçalho HTTP Device Memory (Device-Memory) é um mecanismo separado que permite ao servidor ler o mesmo valor de uma requisição negociada por Accept-CH. O CoreDash usa a API JavaScript coletada no momento do carregamento da página, então o valor viaja com o beacon RUM em vez de requerer configuração de cabeçalho no lado do servidor.

Por que a capacidade do dispositivo importa para Core Web Vitals

LCP é principalmente um problema de rede e renderização. INP é principalmente um problema de CPU e memória. Essa distinção é o motivo pelo qual a dimensão CCS aparece mais claramente nos dados de INP.

Tarefas longas na main thread bloqueiam a resposta a inputs. Em um dispositivo com 1 GB de RAM, o navegador já está sob pressão de memória antes mesmo do seu JavaScript executar: coleta de lixo mais agressiva, descartes de abas mais frequentes e menos margem para compilação JIT se traduzem diretamente em durações de tarefas mais longas. Um site que passa no INP em um telefone moderno com 180 ms pode facilmente ficar em 400 ms em um dispositivo Restrito.

O capítulo de Performance do 2025 Web Almanac confirma a tendência: as taxas de aprovação do INP mobile chegam a 77% no geral, mas a lacuna entre dispositivos de alto desempenho e de baixo custo nessa estatística é ampla. Aproximadamente 29% dos usuários mobile da web estão em dispositivos três vezes menos potentes que um flagship atual. Esses usuários não são outliers na maioria dos mercados globais; eles são o visitante mediano.

CLS é menos sensível à classe de hardware do que INP, mas dispositivos com CPUs lentas ainda podem produzir layout shifts quando fontes ou imagens de carregamento tardio causam reflows que completam após o navegador já ter confirmado um frame.

Como usar CCS e Device Memory no CoreDash

O fluxo de trabalho mais produtivo é começar com CCS como filtro e depois usar Device Memory para confirmar sua hipótese.

Primeiro, abra sua análise de INP por CCS. Se seu INP no 75º percentil é bom para visitantes Muito Capazes (CCS 1) e Capazes (CCS 2) mas falha para Limitados (CCS 3) e abaixo, você tem um gargalo de CPU ou memória em vez de um gargalo de rede. Isso descarta toda uma categoria de correções (preloading, connection hints, ajuste de CDN) e foca sua atenção no tempo de execução de JavaScript: tarefas longas, peso dos handlers de input e scripts de terceiros que executam em cada interação.

Depois filtre por Device Memory para ver quais buckets de RAM geram os piores resultados. Se dispositivos com 1 GB representam uma parcela desproporcional de pontuações ruins de INP, você conhece o limite. Scripts que são aceitáveis com 4 GB podem ser candidatos a adiamento ou remoção com base apenas nesses dados.

Para sites com audiências globais, combine CCS com a dimensão País. Mercados do Sul e Sudeste Asiático, África Subsaariana e partes da América Latina têm altas concentrações de dispositivos Restritos e Muito Limitados. Uma análise de CCS filtrada por país mostrará onde a lacuna é maior e ajudará a priorizar qual mercado abordar primeiro.

O bucket Desconhecido (CCS 0) cobre todo o tráfego Firefox e Safari mais qualquer sessão onde as APIs não retornaram valor. Não o ignore. Em sites com participação significativa de Firefox ou Safari, Desconhecido pode representar um quarto ou mais de todas as sessões. Não significa que esses usuários têm dispositivos ruins; significa que o sinal não estava disponível. Trate Desconhecido como um segmento separado em vez de incorporá-lo à sua linha de base.

O que fazer com os dados

Se visitantes CCS 3, 4 ou 5 representam mais de 15% do seu tráfego e seu INP está consistentemente acima de 200 ms, o conjunto de correções é específico:

• Profile suas tarefas mais longas em um dispositivo com throttling no Chrome DevTools. Task Attribution no painel Performance mostrará quais scripts são responsáveis.
• Mova scripts de terceiros não críticos para trás de um gatilho de interação ou visibilidade para que não compitam pela main thread durante a janela de carregamento inicial.
• Reduza o tamanho do bundle JavaScript em caminhos críticos. Cada kilobyte parseado em um dispositivo com pouca memória custa mais do que em um flagship porque o compilador JIT tem menos espaço para armazenar código compilado em cache.
• Use scheduler.yield() ou setTimeout(0) para quebrar tarefas longas e dar ao navegador uma chance de processar eventos de input entre os pedaços.

O CoreDash exibe as dimensões CCS e Device Memory junto com cada métrica Core Web Vitals para que você possa confirmar se uma correção que melhorou o INP em dispositivos de alto desempenho também moveu os números para seus visitantes Restritos, não apenas seus usuários no melhor cenário.