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 do site. Na prática, eles não são! As métricas estão intimamente ligadas aos dispositivos que os usuários utilizam. Se um negócio vende produtos ou serviços de alto padrão, seus clientes tendem a possuir celulares rápidos, desktops e conexões confiáveis.
Compare isso com negócios voltados para consumidores atentos aos custos ou mercados emergentes. O público deles depende de celulares antigos, processadores fracos ou condições de rede ruins.
O mesmo site que passa com folga em um teste num iPhone de ponta tem dificuldades para carregar de forma aceitável em um Android intermediário 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 de 2025, apenas 48% das origens mobile passam nos Core Web Vitals contra 56% no desktop. A diferença mais gritante é no INP: 97% das origens desktop passam, mas apenas 77% no mobile. Essa diferença de 20 pontos percentuais é causada quase que inteiramente por CPUs mais lentas em dispositivos Android.

O Total Blocking Time mediano no mobile é de 1.916 milissegundos. No 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.

Segundo a pesquisa de Alex Russell, cerca de 30% dos dispositivos no mundo real são de baixo desempenho (4 núcleos ou menos, 4GB de RAM ou menos). Esses dispositivos possuem desempenho single-core que é até 9x mais lento do que um iPhone atual. Em dados de RUM do CoreDash, vemos que sites otimizados para dispositivos de baixo desempenho passam nos CWV 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: Gere 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 primeira linha). 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 têm forte correlação com dados RUM do mundo real e dados de 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 de Core Web Vitals: Essas otimizações ajudam a todos. Mas se alguém estiver 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.
Tome como exemplo 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 de baixa largura de banda ou com restrição de memória, isso rapidamente se torna uma prioridade.

Habilite o HTTP/3 com QUIC e 0-RTT

Visitantes distantes de seus servidores ou presos em redes lentas enfrentam altos tempos de ida e volta (RTT). O HTTP/3, juntamente com o QUIC e 0-RTT, melhora diretamente sua velocidade de 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 web global. Se você usa o Cloudflare, pode habilitar o HTTP/3 no painel do Cloudflare.

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

Comprima imagens mais agressivamente do que seu designer gostaria

Imagens de alta resolução travam o LCP, particularmente em dispositivos com capacidade limitada de descompressão por GPU. O Web Almanac de 2025 mostra que a home page mobile mediana carrega 911KB 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 perceptivelmente aceitáveis. WebP e AVIF ajudam, mas fazer lazy-loading e servir tamanhos responsivos importam mais.

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

Reduza o CSS ao estritamente necessário

Quando se trata de estilos, há apenas uma regra: limpe a casa. Remova seletores não utilizados, reduza a especificidade e colapse as regras redundantes.

Concentre-se em layouts previsíveis e consistentes, com o mínimo de substituiçõ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 os desenvolvedores.

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

Seja contundente com scripts

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

• Nenhum script deve bloquear a renderização: Certifique-se de que todos os scripts não essenciais não sejam 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 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 exigidos antecipadamente devem ser agendados. Use requestIdleCallback para disparar scripts quando o navegador estiver ocioso. Isso permite descarregar tarefas pesadas sem interromper os caminhos de renderização críticos.
• 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 tiver memória limitada ou uma CPU mais antiga, não desperdice recursos carregando scripts pesados. Priorize o desempenho sobre recursos de vaidade que podem impressionar em dispositivos de alto desempenho, 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 jank no layout. Em dispositivos com memória limitada, eles também podem aumentar a pressão na RAM desnecessariamente. De acordo com o Web Almanac de 2025, 88% dos sites carregam pelo menos uma fonte web, mas apenas 12% fazem preload delas. A melhor opção para o desempenho, font-display: optional, é usada por apenas 0,4% dos sites.

As 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, faça um subset de forma agressiva e carregue as fontes mais tarde. Considere hospedar suas próprias fontes para controlar a entrega.

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

Ferramentas de teste sintético (como Lighthouse, WebPageTest, etc.) simulam throttling, mas não imitam todas as peculiaridades de hardware de baixo desempenho: problemas térmicos, throttling sob carga real, pausas de garbage collection e gargalos de armazenamento. Observe 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 verdadeiro desempenho em dispositivos econômicos.

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