Site lento no celular: o que medir antes de mexer em qualquer coisa

Diante de "o site está lento no celular", a reação comum é agir: trocar de hospedagem, apagar fotos, tirar o vídeo do topo. Às vezes uma dessas coisas resolve. Mas sem medir antes, você não sabe qual — e as três custam tempo, dinheiro ou conteúdo que fazia falta. Este texto mostra o que medir e como ler o número, para que a mudança seja escolhida em vez de sorteada.

"Lento" precisa virar um número

Lentidão pode significar demora para ver o conteúdo principal ou para responder a uma interação. Aqui o foco é o carregamento visual; para atraso depois de tocar ou digitar, a investigação é outra. Essa distinção virou uma métrica com nome e definição pública, a LCP — Largest Contentful Paint, ou Maior Exibição de Conteúdo.

A documentação do web.dev define assim: a LCP informa o tempo de renderização da maior imagem, bloco de texto ou vídeo visível na janela de visualização, contado a partir do momento em que o usuário navegou até a página. Ela existe justamente porque métricas antigas, como load, não correspondiam ao que a pessoa vê na tela — uma página pode terminar de carregar tudo e ainda assim ter demorado para mostrar algo útil, ou o contrário.

O limite publicado

O material do web.dev traz um alvo explícito: para oferecer uma boa experiência, os sites devem ter LCP de 2,5 segundos ou menos. E acrescenta como esse alvo deve ser conferido: no 75º percentil dos carregamentos de página, segmentado entre celular e computador. Traduzindo: não é a sua visita que conta, é o comportamento típico de três em cada quatro visitas — e o número do celular é medido separado do número do computador.

Qual elemento a métrica está olhando

Saber isso muda a decisão, porque otimizar o elemento errado não move o número. Segundo a especificação citada no web.dev, entram na conta: elementos <img>, elementos <image> dentro de um <svg>, elementos <video>, elementos com imagem de fundo carregada por url() — e elementos de bloco que contêm texto.

Dois detalhes práticos saem daí:

• Texto também pode ser o elemento medido. O web.dev usa a página de resultados do Google como exemplo: o maior elemento é um parágrafo de texto, que aparece antes de qualquer imagem terminar de carregar. Se o seu bloco de texto do topo depende de uma fonte que demora a chegar, ele não é considerado renderizado durante o período de bloqueio da fonte — e o relógio continua correndo.
• O elemento medido pode mudar durante o carregamento. O navegador reporta um candidato assim que pinta o primeiro quadro e reporta outro toda vez que o maior elemento muda. Numa página com texto e uma foto grande, o texto costuma ser o primeiro candidato e a foto assume depois que carrega.

Há ainda um ponto que costuma inocentar a imagem e acusar a infraestrutura: o web.dev registra que a LCP inclui o tempo de configuração da conexão, de redirecionamento e outros atrasos de tempo até o primeiro byte. Se o servidor demora a responder, nenhuma compressão de foto conserta.

Laboratório e campo: dois números diferentes, os dois válidos

O web.dev separa as ferramentas em duas famílias, e confundi-las é a origem da maior parte das discussões inúteis sobre velocidade.

Campo

São dados de visitas reais. O web.dev lista o Relatório de Experiência do Usuário do Chrome, o PageSpeed Insights, o relatório de Core Web Vitals no Search Console e a biblioteca JavaScript web-vitals. É aqui que mora a resposta para "meus visitantes estão sofrendo?".

Laboratório

São testes controlados: Chrome DevTools, Lighthouse, PageSpeed Insights e WebPageTest. Rodam num ambiente definido por você e servem para diagnosticar e comparar antes/depois. É aqui que mora a resposta para "a minha mudança melhorou alguma coisa?".

Os dois números podem divergir, e isso é esperado, não é erro. A própria documentação avisa que os atrasos de rede incluídos na LCP podem ser significativos quando medidos em campo e levar a diferenças em relação ao laboratório. Um site pode ir bem no teste controlado e mal no mundo real — e é o mundo real que decide se a pessoa espera ou desiste.

Como medir, na prática

1. Escolha as páginas que importam. Normalmente três: a inicial, a página do serviço mais procurado e a de contato. Medir o site inteiro no primeiro dia dispersa a atenção.
2. Rode o teste de laboratório com celular selecionado. As ferramentas trazem perfis separados para celular e computador; o resultado de computador não responde à sua pergunta.
3. Simule condições de celular no navegador. O modo dispositivo do Chrome DevTools oferece limitação de CPU e limitação de rede, além da janela de visualização estreita. Isso aproxima o teste do aparelho modesto em rede móvel, que é o cenário do seu visitante.
4. Anote qual elemento foi apontado como LCP em cada página. Sem esse dado, a otimização vira tentativa.
5. Repita o mesmo teste depois de cada mudança, com a mesma ferramenta e o mesmo perfil. Comparar Lighthouse de ontem com campo de hoje não mede nada.

Duas armadilhas registradas na documentação e fáceis de cair: as ferramentas do Google não informam a LCP se a página foi carregada em segundo plano, porque o número não refletiria o tempo percebido; e o navegador para de reportar novos candidatos assim que o usuário interage com a página — tocar, rolar ou digitar encerra a medição. Se você rolar a página assim que ela abre, está medindo outra coisa.

Depois de medir

Com o elemento identificado, a lista de suspeitos encolhe. Se o LCP é uma imagem, o caminho passa por tamanho de arquivo, formato e prioridade de carregamento. Se é um bloco de texto, passa por fonte e por bloqueio de renderização. Se o atraso aparece concentrado antes do primeiro byte, entra o servidor — sem descartar as outras camadas, porque mais de uma pode contribuir ao mesmo tempo — e aí a conversa muda de endereço, para domínio, hospedagem e site.

Vale uma última separação. Lentidão e defeito são coisas diferentes: um formulário que não envia continua não enviando num site rápido. Se você ainda não passou o roteiro de conferência no aparelho, faça isso antes — está em como testar seu site no celular. E se a conclusão for que a estrutura da página é o problema de fundo, a página de sites sob medida explica como tratamos isso desde a construção.