Otimize os Core Web Vitals para dispositivos de baixo desempenho

Otimize os Core Web Vitals para dispositivos de baixo desempenho

Os Core Web Vitals devem fazer parte de um benchmark objetivo para a qualidade de um site. Na prática, não são! As métricas estão intimamente ligadas aos dispositivos que os usuários utilizam. Se uma empresa vende produtos ou serviços de alto padrão, seus clientes tendem a possuir celulares rápidos, desktops e conexões confiáveis.
Contraste isso com empresas voltadas para compradores preocupados com os custos ou mercados emergentes. Seus públicos dependem de celulares antigos, processadores fracos ou condições de rede ruins.
O mesmo site que passa com facilidade por um teste em um iPhone de última geração tem dificuldades para carregar de forma aceitável em um Android de nível médio ou em países com conectividade de baixa largura de banda.

Última revisão por Arjen Karel em março de 2026

Os números contam a história

De acordo com o Web Almanac 2025, apenas 48% das origens mobile passam nos Core Web Vitals, contra 56% no desktop. A maior discrepância é o INP: 97% das origens desktop passam, mas apenas 77% no mobile. Essa diferença de 20 pontos percentuais é quase inteiramente causada por CPUs mais lentas em dispositivos Android.

A mediana do Total Blocking Time no mobile é de 1.916 milissegundos. Desktop? 92 milissegundos. Essa é uma proporção de 20:1. Se seus scripts rodam bem no seu MacBook, eles absolutamente não rodam bem em um celular econômico.

De acordo com a pesquisa de Alex Russell, cerca de 30% dos dispositivos em uso são de baixo desempenho (4 núcleos ou menos, 4 GB de RAM ou menos). Esses dispositivos têm um desempenho single-core que é até 9x mais lento do que um iPhone atual. Nos dados de RUM do CoreDash, vemos que sites otimizados para dispositivos de baixo desempenho passam nos Core Web Vitals em 62% dos carregamentos de página mobile, em comparação com apenas 41% para sites que testam apenas em hardware de ponta.

Passo 1: Gerar um Client Capability Score

Para avaliar se um visitante está usando um dispositivo de alto ou baixo desempenho, um Client Capability Score pode ser calculado diretamente no navegador. Esta pontuação varia de 0 (extremamente limitado) a 100 (hardware de ponta). Na prática, qualquer dispositivo com pontuação abaixo de 40 deve ser classificado como ruim.

A função abaixo calcula o Client Capability Score usando indicadores de hardware e rede que se correlacionam fortemente com dados de RUM do mundo real e Core Web Vitals do Google. Uma pontuação mais alta indica que o dispositivo é mais capaz de entregar um desempenho de página rápido com menos restrições de recursos.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Dica sobre Core Web Vitals: Essas otimizações ajudam a todos. Mas se alguém está em uma conexão lenta ou usando um dispositivo com memória limitada, elas importam muito mais. As desvantagens de ignorá-las aparecem mais rápido.
Veja o download de imagens. Em uma conexão normal, eles geralmente representam cerca de 10% do tempo do Largest Contentful Paint. Em uma conexão lenta, isso pode dobrar sem muito esforço. É por isso que não colocamos a otimização de imagens no topo da lista para a maioria dos usuários, mas ao lidar com visitantes com baixa largura de banda ou restrição de memória, isso rapidamente se torna uma prioridade.

Habilite HTTP/3 com QUIC e 0-RTT

Visitantes longe dos seus servidores ou presos em redes lentas enfrentam altos tempos de ida e volta (RTT). O HTTP/3, junto com o QUIC e 0-RTT, melhora diretamente a velocidade da sua conexão inicial. Esta é uma otimização importante para todos os visitantes, mas especialmente crítica para visitantes com baixa largura de banda. De acordo com o Cloudflare Radar, o HTTP/3 agora lida com 21% do tráfego global da web. Se você usa a Cloudflare, pode habilitar o HTTP/3 no painel da Cloudflare.

• Configuração de conexão mais rápida: O QUIC consolida os handshakes de transporte e criptografia em um só. O 0-RTT vai além: visitantes recorrentes enviam dados imediatamente, ignorando totalmente os handshakes.
• Menor latência para usuários recorrentes: O 0-RTT permite que os clientes retomem as sessões e enviem solicitações sem pausas. Centenas de milissegundos economizados, especialmente valiosos para usuários distantes ou mobile.
• Resiliente em longas distâncias: O HTTP/3 (sobre UDP) contorna o head-of-line blocking do TCP. O QUIC lida com perda de pacotes e redes instáveis de forma mais elegante. Isso faz uma diferença real para conexões intercontinentais ou móveis instáveis.

Comprima imagens mais agressivamente do que seu designer gostaria

Imagens de alta resolução travam o LCP, particularmente em dispositivos com poder de descompressão de GPU limitado. O Web Almanac 2025 mostra que a página inicial mobile mediana carrega 911 KB de imagens. Isso representa 42% do peso total da página. Em um dispositivo econômico com um downlink P75 de 9 Mbps, essas imagens competem diretamente com seus recursos críticos.

Em vez de ceder à estética, busque imagens menores e perceptualmente aceitáveis. WebP e AVIF ajudam, mas o lazy-loading e o fornecimento de tamanhos responsivos importam mais.

Uma regra clara: para hero images em dispositivos de baixo desempenho, mantenha-se abaixo de 100 KB. Se o designer objetar, ele deve testar o mesmo site em um celular Android de 100€ antes de argumentar mais.

Reduza o CSS ao que é estritamente necessário

Quando se trata de estilos, há apenas uma regra: faça uma limpa. Remova seletores não utilizados, reduza a especificidade e consolide regras redundantes.

Concentre-se em layouts previsíveis e consistentes, com o mínimo de sobrescrições. Use um pequeno conjunto de classes utilitárias em vez de estilos complexos específicos de componentes. Isso ajuda tanto na construção do CSSOM pelo navegador quanto na manutenibilidade para o desenvolvedor.

Para conteúdo acima da dobra, faça o inline apenas do que é absolutamente necessário. Faça o lazy-load do restante, mas mantenha a divisão mínima e clara. Você pode usar o Critical CSS Generator como ponto de partida, mas defina seu critical CSS manualmente e cirurgicamente para obter o melhor resultado.

Seja rigoroso com scripts

Com uma mediana de TBT mobile de 1.916 ms (um aumento de 58% ano após ano, de acordo com o Web Almanac 2025), o JavaScript é o maior problema isolado em dispositivos de baixo desempenho. A velocidade de rede P75 para dispositivos econômicos é de cerca de 9 Mbps de download com 100 ms de RTT. Cada kilobyte de JavaScript que você envia é analisado e executado em uma CPU que é 9x mais lenta do que a do celular em que você testa.

• Nenhum script deve bloquear a renderização: Garanta que todos os scripts não essenciais sejam não bloqueantes. Use atributos async ou defer nas suas tags <script>. Se um script não for essencial para o carregamento inicial da página ou para a interação do usuário, ele não deve ser síncrono. Para uma visão geral completa das técnicas de adiamento, veja 16 métodos para adiar o JavaScript.
• Agende scripts não críticos: Scripts que não são necessários de imediato devem ser agendados. Use requestIdleCallback para disparar scripts quando o navegador estiver ocioso. Isso permite que você descarregue tarefas pesadas sem interromper os caminhos críticos de renderização.
• Use o Client Capability Score para carregar scripts seletivamente: Use a pontuação para decidir o que carregar. Em dispositivos de baixo desempenho, reduza o número de scripts e escolha alternativas mais leves. Se o usuário tem memória limitada ou uma CPU mais antiga, não desperdice recursos carregando scripts pesados. Priorize o desempenho em vez de recursos de vaidade que podem impressionar em dispositivos de alto padrão, mas frustrar nos de baixo desempenho.

Use fontes do sistema ou, pelo menos, evite fontes personalizadas pesadas

Carregar fontes personalizadas adiciona latência e causa problemas de layout (jank). Em dispositivos com memória limitada, elas também podem aumentar desnecessariamente a pressão sobre a RAM. De acordo com o Web Almanac 2025, 88% dos sites carregam pelo menos uma web font, mas apenas 12% fazem o preload delas. A melhor opção para desempenho, font-display: optional, é usada por apenas 0,4% dos sites.

Fontes do sistema renderizam mais rápido, respeitam as configurações do usuário e reduzem o layout shift. Se o branding exigir tipografia personalizada, crie subconjuntos agressivamente e carregue as fontes mais tarde. Considere hospedar suas fontes localmente para que você controle a entrega.

Monitore com hardware real, não apenas testes sintéticos

Ferramentas de testes sintéticos (como Lighthouse, WebPageTest, etc.) simulam o estrangulamento (throttling), mas não imitam todas as peculiaridades de hardwares de baixo desempenho: problemas térmicos, throttling sob carga real, pausas de garbage collection e gargalos de armazenamento. Note que o PageSpeed Insights mudou seu throttling de CPU de 4x para 1,2x em dezembro de 2024, tornando as pontuações de laboratório ainda menos representativas do desempenho real de dispositivos econômicos.

Compre um celular Android barato e navegue no seu site. Se você não suporta fazer isso regularmente, use uma ferramenta de RUM como o CoreDash e segmente os dados por classe de dispositivo. Se o seu LCP no percentil 75 (P75) é bom no iPhone 15, mas terrível no Xiaomi Redmi 9, é hora de ser honesto sobre para quem você está otimizando.