Dimensão do Core/Dash: Tipo de Dispositivo

Dimensão: Tipo de Dispositivo (d)

A dimensão Tipo de Dispositivo divide seus dados de Real User Monitoring em duas categorias: mobile e desktop. Este é o primeiro filtro mais importante em qualquer investigação de desempenho, porque mobile e desktop são ambientes de computação fundamentalmente diferentes. CPUs diferentes, condições de rede diferentes, tamanhos de viewport diferentes, motores de navegador diferentes.

Se você analisa dados agregados do Core Web Vitals sem filtrar por tipo de dispositivo, está calculando a média de duas populações que quase não têm nada em comum. Essa média é enganosa, na melhor das hipóteses.

A Lacuna de Desempenho Móvel

Os dispositivos móveis representam cerca de 62% do tráfego web global, segundo a Statista (2025). Ainda assim, o mobile tem desempenho consistentemente inferior ao desktop. Segundo o 2025 Web Almanac, apenas 48% das origens móveis passam em todos os três Core Web Vitals, em comparação com 56% no desktop. Essa é uma diferença de 8 pontos percentuais.

A lacuna existe porque os dispositivos móveis enfrentam três restrições que os desktops não têm:

• CPU throttling: Um celular Android intermediário tem cerca de 3 a 5 vezes menos poder de processamento do que um desktop. O JavaScript que executa em 50ms no desktop pode levar 200ms no mobile, empurrando o INP para além do limiar "bom".
• Latência de rede: Conexões móveis (4G/5G) têm tempos de ida e volta maiores e mais variação do que conexões cabeadas. Isso infla o TTFB e o LCP Load Delay.
• Tamanho da viewport: Telas menores mudam qual elemento se torna o LCP. A imagem hero do seu desktop pode encolher e ficar abaixo de um bloco de texto no mobile, mudando completamente o alvo de otimização.

Distribuição de Tipo de Dispositivo no CoreDash

Nos projetos do CoreDash, a divisão típica de tráfego é de 65% mobile e 35% desktop. Sites de e-commerce inclinam-se ainda mais para o mobile (70% a 75%), enquanto produtos SaaS B2B frequentemente veem uma divisão de 50/50 ou até mesmo a dominância do desktop.

A lacuna de desempenho nos dados do CoreDash reflete a tendência global. O p75 do LCP no mobile tem média de 2,8s, comparado a 1,9s no desktop. Para o INP, a lacuna é ainda maior: o p75 no mobile fica em torno de 220ms, enquanto o desktop flutua perto de 120ms.

Análise Específica por Métrica

Largest Contentful Paint (LCP)

O LCP no mobile é quase sempre pior do que no desktop. A causa primária é o Load Delay: os navegadores móveis descobrem a imagem do LCP mais tarde porque o HTML demora mais para chegar (TTFB mais alto) e o preload scanner compete com mais concorrência de recursos em uma CPU mais lenta. Se o seu LCP no desktop está abaixo de 2,0s, mas no mobile passa de 3,0s, o problema raramente é o arquivo da imagem em si. É o pipeline de entrega.

Interaction to Next Paint (INP)

É aqui que a diferença entre dispositivos pesa mais. Manipuladores de eventos JavaScript que parecem instantâneos em um i7 de desktop podem bloquear a main thread por mais de 300ms em um Snapdragon 665. Filtre por mobile, ordene pelo impacto no INP e você encontrará as interações exatas que quebram em celulares reais. Vejo isso constantemente: desenvolvedores testam em MacBook Pros e entregam interações que são inutilizáveis nos dispositivos que 65% dos seus usuários realmente carregam consigo.

Cumulative Layout Shift (CLS)

As diferenças de CLS entre tipos de dispositivos geralmente têm origem no design responsivo. Espaços de anúncios que reservam espaço no desktop podem colapsar ou redimensionar no mobile. Métricas de fallback de fontes que se alinham no desktop causam mudanças visíveis em viewports menores. Fontes web são renderizadas de forma diferente em navegadores mobile e desktop, e a densidade física de pixels afeta o arredondamento de subpixels.

Fluxo de Trabalho de Depuração

1. Comece toda investigação com o filtro de dispositivo: Antes de olhar para qualquer outra dimensão, divida por Tipo de Dispositivo. Se o seu LCP agregado for de 2,5s, você poderá encontrar o desktop em 1,8s e o mobile em 3,1s. O "problema" é exclusivamente do mobile.
2. Compare as distribuições, não apenas o p75: Verifique a distribuição de bom/precisa melhorar/ruim para cada tipo de dispositivo. Um desktop com 85% de "bom" e um mobile com 45% de "bom" contam uma história completamente diferente daquela contada apenas pelo p75.
3. Combine com outras dimensões: Depois de isolar o tipo de dispositivo, adicione um segundo filtro. Tipo de Dispositivo + País revela se a lacuna móvel é global ou se está concentrada em regiões com redes mais lentas. Tipo de Dispositivo + Tipo de Navegação mostra se as navegações de voltar/avançar no mobile estão sendo armazenadas em cache corretamente.

Regra Prática de Engenharia

• LCP no mobile abaixo de 2,5s: Este é o limiar que o Google usa para "bom". Se o seu desktop passa, mas o mobile falha, foque em reduzir o Load Delay (fetchpriority, preload) e o TTFB (cache de borda, CDN).
• INP no mobile abaixo de 200ms: Teste cada recurso interativo em um dispositivo Android intermediário real. O throttling de CPU do Chrome DevTools (4x) se aproxima disso, mas testar em um dispositivo real é melhor.
• Nunca otimize apenas para desktop: Se o seu tráfego móvel excede 50% (e quase certamente excede), o desempenho móvel é o seu sinal de ranqueamento de busca. O Google usa dados móveis do CrUX para ranqueamento.

O Tipo de Dispositivo não é um filtro opcional. É a primeira pergunta que você faz: "Este é um problema de mobile ou de desktop?" Toda decisão de otimização flui dessa resposta.