← Todos os artigos

Site lento no celular? O culpado quase sempre é o mesmo

Publicado em 19 de julho de 2026 · Por LW Forge · 3 min de leitura

Um site lento no celular raramente é lento por causa de código pesado. Na maioria dos casos, o navegador fica impedido de pintar qualquer coisa até um punhado de recursos terminar de baixar e executar. Numa conexão móvel limitada, essa espera pode passar de 8 segundos antes de o usuário ver um único pixel — e a maior parte dos visitantes desiste antes disso.

A boa notícia: o culpado quase sempre é o mesmo, dá para encontrá-lo com uma ferramenta gratuita e as correções não exigem reescrever o site.

O que deixa um site lento de verdade

Quando o navegador lê o <head> do seu HTML, ele para e espera cada <script> síncrono e cada folha de estilo antes de pintar a página. Esses são os chamados recursos que bloqueiam a renderização (render-blocking). Cada um é uma ida e volta ao servidor; empilhe alguns e você ergueu um muro entre o usuário e o conteúdo.

Os suspeitos de sempre:

  • Um framework de CSS em runtime (por exemplo, uma CDN que gera estilos no navegador em vez de entregar um arquivo pronto).
  • Folhas de estilo de fontes web carregadas de forma síncrona de um domínio de terceiros.
  • Qualquer <script src> no <head> sem defer ou async.
  • Imagens pesadas não bloqueiam o primeiro paint, mas atrasam o conteúdo principal — e contam na percepção de lentidão.

Site lento atrapalha no Google?

Atrapalha, por dois caminhos. O primeiro é direto: o Google mede a experiência de carregamento das páginas pelos Core Web Vitals — métricas como o LCP (quanto tempo o conteúdo principal demora para aparecer) — e usa isso como sinal de ranqueamento, especialmente no índice mobile-first.

O segundo caminho é ainda mais caro: conversão. Cada segundo a mais de carregamento derruba a taxa de quem preenche o formulário, compra ou liga. Um site lento perde duas vezes: aparece menos e converte menos quando aparece.

Como descobrir por que seu site está lento

Rode o PageSpeed Insights na sua página e leia a nota mobile, não a de desktop — é nela que o Google se baseia e é nela que os problemas aparecem primeiro.

Olhe três coisas:

  1. First Contentful Paint (FCP): quanto tempo até o primeiro elemento aparecer.
  2. Largest Contentful Paint (LCP): quanto tempo até o conteúdo principal aparecer. O bom é ficar abaixo de 2,5 s.
  3. O insight de "solicitações que bloqueiam a renderização" — ele estima, em milissegundos, quanto você economizaria removendo cada bloqueador.

As correções, da mais segura à mais ousada

  1. Entregue CSS pré-compilado. Se seus estilos são gerados em runtime, mova esse trabalho para o build. O navegador baixa um arquivo estático pequeno em vez de um script grande que precisa rodar antes.
  2. Torne as folhas de fonte não-bloqueantes. Carregue-as com um swap via media print: o texto aparece na hora com uma fonte de fallback e "sobe" quando a fonte web chegar.
  3. Adie seus scripts. Tudo que não é necessário para o primeiro paint pertence ao fim do body, ou leva defer.
  4. Converta imagens para WebP com fallback — mesmo conteúdo, uma fração do peso.

Nenhuma dessas exige reescrever o site. São mudanças cirúrgicas no <head> e no build.

Um caso real: dos 50 para os 70 sem reescrever nada

Fizemos exatamente esse exercício no nosso próprio site. Trocar o CSS gerado em runtime por um arquivo pré-compilado levou a nota de performance mobile de 56 para 73, com o FCP caindo de 8,9 s para 4,4 s e o LCP de 10,5 s para 4,5 s. Converter as imagens para WebP cortou 2,79 MB para 283 KB — cerca de 90% do peso. Tudo sem mudar uma linha do conteúdo.

O que sobrou (fontes de terceiros) virou a próxima rodada — performance é trabalho incremental, não big bang.

Performance é uma funcionalidade do produto, não um detalhe técnico. Se o seu site está lento e você quer um diagnóstico com plano de correção priorizado, é isso que fazemos.

Perguntas Frequentes

Site lento atrapalha no Google?

Atrapalha, de duas formas: os Core Web Vitals (como o LCP) são sinal de ranqueamento, especialmente no índice mobile-first, e cada segundo a mais de carregamento derruba a conversão.

Como descobrir por que um site está lento?

Rode o PageSpeed Insights e leia a nota mobile, olhando o FCP, o LCP (bom é abaixo de 2,5s) e o insight de "solicitações que bloqueiam a renderização".

Quais correções resolvem sem reescrever o site?

Entregar CSS pré-compilado em vez de gerado em runtime, tornar as folhas de fonte não-bloqueantes, adiar scripts não essenciais e converter imagens para WebP.

PerformanceCore Web VitalsWeb