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

O que essas dimensões medem

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

A Memória do Dispositivo (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 números exatos. Este arredondamento é intencional: ele limita a precisão disponível para scripts de fingerprinting enquanto ainda dá aos desenvolvedores um sinal utilizável.

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

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

Suporte de navegadores e cobertura de dados

O navigator.deviceMemory é uma API exclusiva do Chromium. O Firefox e o 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, o Chrome e os navegadores baseados no Chrome representam a maioria do tráfego Android, e os dispositivos Android são onde as condições de pouca memória se concentram. Portanto, o sinal está mais disponível precisamente onde ele é mais importante.

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

Por que a capacidade do dispositivo importa para os Core Web Vitals

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

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

O capítulo de Performance do Web Almanac de 2025 confirma a tendência: as taxas de aprovação do INP em dispositivos móveis chegam a 77% no geral, mas a lacuna entre dispositivos de alta potência e os de baixo custo nesse número é ampla. Aproximadamente 29% dos usuários da web móvel estão em dispositivos três vezes menos potentes que um modelo atual de ponta. Esses usuários não são pontos fora da curva na maioria dos mercados globais; eles são o visitante mediano.

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

Como usar CCS e Memória do Dispositivo no CoreDash

O fluxo de trabalho mais produtivo é começar com o CCS como um filtro e então usar a Memória do Dispositivo para confirmar a sua hipótese.

Primeiro, abra o seu detalhamento de INP por CCS. Se o seu INP no 75º percentil for bom para visitantes Muito Capazes (CCS 1) e Capazes (CCS 2), mas falhar para os Limitados (CCS 3) e inferiores, 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, dicas de conexão, otimização de CDN) e foca a sua atenção no tempo de execução do JavaScript: tarefas longas, peso do manipulador de input e scripts de terceiros que rodam a cada interação.

Depois, filtre por Memória do Dispositivo para ver quais buckets de RAM geram os piores resultados. Se dispositivos de 1 GB representarem uma parte desproporcional de pontuações de INP ruins, você sabe o limite. Scripts que são aceitáveis em 4 GB podem ser candidatos para adiamento ou remoção baseando-se apenas nesses dados.

Para sites com públicos globais, combine o CCS com a dimensão de 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. Um detalhamento de CCS filtrado por país mostrará a você onde a lacuna é maior e ajudará a priorizar qual mercado abordar primeiro.

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

O que fazer com os dados

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

• Faça o profiling das suas tarefas mais longas em um dispositivo estrangulado no Chrome DevTools. A Atribuição de Tarefas no painel de 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 concorram pela thread principal durante a janela inicial de carregamento.
• Reduza o tamanho do bundle de JavaScript nos caminhos críticos. Cada kilobyte processado em um dispositivo de pouca memória custa mais do que em um modelo de ponta porque o compilador JIT tem menos espaço para armazenar o código compilado em cache.
• Use scheduler.yield() ou setTimeout(0) para dividir tarefas longas e dar ao navegador a chance de processar eventos de input entre os pedaços.

O CoreDash exibe as dimensões CCS e Memória do Dispositivo juntamente com cada métrica dos Core Web Vitals para que você possa confirmar se uma correção que melhorou o INP em dispositivos de ponta também alterou os números para os seus visitantes Restritos, e não apenas para os seus usuários no melhor cenário possível.