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 ser parte de um referencial 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 premium, seus clientes tendem a ter telefones rápidos, desktops e conexões confiáveis. 
Contraste isso com empresas voltadas para consumidores atentos aos custos ou mercados emergentes. O público deles depende de telefones mais antigos, processadores fracos ou condições de rede ruins. 
O mesmo site que passa facilmente em um teste num iPhone top de linha sofre para carregar de forma aceitável em um Android intermediário ou em países com conectividade de baixa largura de banda. Este artigo examina como otimizar os Core Web Vitals para dispositivos de baixo desempenho.

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 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 se correlacionam fortemente com dados reais de RUM e dos Core Web Vitals do Google. Uma pontuação mais alta indica que o dispositivo é mais capaz de entregar um desempenho rápido da página com menos restrições de recursos e pode lidar com uma interação mais suave.

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 com baixa largura de banda ou restrição de memória, isso rapidamente se torna uma prioridade.

Ative o http/3 com QUIC e 0-RTT

• Configuração de conexão mais rápida: O QUIC condensa 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 sessões e enviem solicitações sem pausa. Centenas de milissegundos economizados — especialmente valioso para usuários distantes ou móveis.
• Resiliente a longas distâncias: O HTTP/3 (sobre UDP) evita o head-of-line blocking do TCP. O QUIC lida com perda de pacotes e redes instáveis de forma mais elegante — ideal para conexões móveis instáveis ou intercontinentais.

Comprima as imagens de forma mais agressiva do que seu designer gostaria

Imagens de alta resolução travam o LCP (Largest Contentful Paint), particularmente em dispositivos com poder limitado de descompressão de GPU. 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 imagens hero em dispositivos de baixo desempenho, mantenha-se abaixo de 100KB. Se o designer objetar, ele deve testar o mesmo site em um telefone Android de 100€ antes de continuar argumentando.

Reduza o CSS ao que é estritamente necessário

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

Concentre-se em layouts previsíveis e consistentes com o mínimo de substituições (overrides). 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 o conteúdo above-the-fold, coloque inline apenas o que é absolutamente necessário. Faça o lazy-load do resto, mas mantenha a divisão mínima e clara. Evite ferramentas que adivinham o que é "CSS crítico", defina isso de forma manual e cirúrgica.

Seja direto com os Scripts

• Nenhum script deve bloquear a renderização: Certifique-se de que todos os scripts não essenciais não sejam bloqueantes. Use os 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. Caso contrário, você está apenas jogando fora milissegundos preciosos.
•  Agende scripts não críticos Scripts que não são necessários de imediato devem ser agendados. Mas não os carregue ao acaso. Use as funções requestIdleCallback para acionar 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 seletivamente os scripts complementares (nice-to-have):  O Client Capability Score não é apenas uma métrica, mas uma ferramenta para otimizar a experiência do usuário.  Em dispositivos de baixo desempenho, reduza o número de scripts carregados 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 desempenho, mas frustrar nos de baixo desempenho.

Use fontes do sistema ou pelo menos evite fontes personalizadas pesadas

O carregamento de fontes personalizadas adiciona latência e trava o layout. Em dispositivos com memória limitada, eles também podem aumentar a pressão na RAM desnecessariamente.

As fontes do sistema renderizam mais rápido, respeitam as configurações do usuário e reduzem a mudança de layout (layout shift). Se o branding exigir tipografia personalizada, faça o subconjunto (subset) de forma agressiva e carregue as fontes por último.

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

Por fim, ferramentas de teste sintético (como Lighthouse, WebPageTest, etc.) simulam o estrangulamento (throttling), mas não imitam todas as peculiaridades do hardware de baixo desempenho: térmicas, estrangulamento sob carga real, pausas de garbage collection e gargalos de armazenamento.

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