Site lento: o que realmente causa, na ordem em que vale corrigir (LCP, INP, CLS)

**Diagnóstico de site lento tem ordem**: imagem e fonte do topo, scripts de terceiros, JavaScript da aplicação e, só no fim, servidor e cache. Seguir essa sequência evita gastar uma semana trocando de hospedagem enquanto o que atrasa a página continua sendo um arquivo pesado no alto dela. E boa parte do que se chama de lentidão não é código ruim: é escopo que alguém aprovou por um motivo comercial.

— Não existe site lento genérico: **LCP** é quando o conteúdo principal aparece, **INP** é quanto a página demora a responder ao toque, **CLS** é o quanto o layout pula.

— A ordem que rende mais por esforço começa na imagem e na fonte acima da dobra — não na hospedagem.

— Cada Pixel, tag manager, chat e mapa embutido é um custo de velocidade que alguém escolheu pagar.

— A nota do PageSpeed Insights é laboratório; o que o buscador observa é campo, medido em celular e rede reais.

— Quando a causa é acúmulo de plugin e script, otimizar sem cortar escopo não resolve.

**Diagnóstico de site lento: LCP, INP, CLS e o que a nota do PageSpeed não diz**

**Core Web Vitals** são as três medidas que o Google usa para descrever a experiência de carregamento de uma página. Não é nota de qualidade do conteúdo nem do design.

Métrica: **LCP** (Largest Contentful Paint) · O que mede: Quando o conteúdo principal da tela aparece — em geral a imagem grande ou o título do topo · Causa habitual: Entrega de arquivo: peso, formato, espera

Métrica: **INP** (Interaction to Next Paint) · O que mede: Quanto a página demora a responder ao toque ou ao clique · Causa habitual: JavaScript ocupando o processador

Métrica: **CLS** (Cumulative Layout Shift) · O que mede: O quanto o layout pula enquanto a página carrega · Causa habitual: Espaço não reservado para imagem, fonte ou anúncio

O INP substituiu o FID e mede a interação inteira, do toque até a tela mudar, olhando a visita toda e não só o primeiro contato. É a métrica do botão que parece travado.

**Dado de laboratório** é uma simulação controlada — aparelho virtual, rede virtual, uma execução. Serve para comparar antes e depois de uma alteração. **Dado de campo** é o que aconteceu com visitantes reais, no aparelho e na rede deles, ao longo de semanas — o que o buscador observa.

Os dois discordam porque medem coisas diferentes. A nota de 0 a 100 vem do laboratório, e melhorá-la sem mexer no campo é otimizar o termômetro. O cenário que decide é celular em rede ruim, não o desktop com fibra onde o site costuma ser testado.

Página nova ou com pouco tráfego pode não ter dado de campo. Aí só resta o laboratório — com a ressalva escrita ao lado do número.

**Problema de entrega ou escolha de negócio: a separação que ordena tudo**

Antes de qualquer correção, separe o relatório em dois grupos: um tem conserto técnico, o outro depende de autorização.

— **Problema de entrega**: arquivo maior do que precisa, fonte carregada de outro servidor, ausência de cache, HTML que só existe depois que o JavaScript roda. Conserta-se sem ninguém decidir nada.

— **Problema de escolha**: o Pixel, o tag manager, o chat, o mapa embutido, o vídeo de fundo. Cada um entrou por um motivo comercial.

Mexer no segundo grupo é conversa com quem responde por marketing e vendas, e a pergunta deixa de ser "como deixar rápido" para virar "o que vale manter". Confundir os dois produz o relatório inútil: recomendações técnicas que ninguém pode executar, porque dependem de uma decisão que ninguém pediu.

**Primeiro alvo: a imagem e a fonte acima da dobra**

**Acima da dobra** é o que cabe na tela antes de qualquer rolagem. Em celular, bem menos do que o layout do desktop sugere — e é esse pedaço que decide o LCP.

— **Em página com imagem de topo, ela costuma ser o elemento LCP.** Servir uma foto de vários megabytes redimensionada por CSS é o defeito mais comum e o mais barato de corrigir: formato moderno, dimensão certa, versão para celular.

— **Fonte carregada de servidor externo** custa uma conexão a mais antes de o texto aparecer. Servir a fonte do próprio domínio encurta a espera; ajustar a fonte provisória para ocupar espaço parecido com a definitiva evita o salto na troca.

— **Imagem, iframe e bloco de anúncio precisam de altura reservada.** É assim que o CLS cai sem tocar em mais nada.

— **Imagem abaixo da dobra carrega sob demanda; a do topo, nunca.** Adiar o elemento que define o LCP é o contrário do que se quer.

Esta etapa costuma resolver a maior parte de LCP e CLS sem negociar escopo com ninguém.

**Segundo alvo: Pixel, tag manager, chat e mapa embutido**

**Script de terceiro** é código carregado do servidor de outra empresa. Você não controla o tamanho dele, nem a velocidade, nem quando ele muda.

O **tag manager** é o caso mais traiçoeiro: parece um script só e é a porta por onde entram os outros, sem que ninguém revise a lista há meses. Widget de chat e mapa embutido costumam ser os arquivos mais pesados da página, e o mapa em geral fica no rodapé, carregando mesmo quando ninguém chega até lá.

Esses scripts atingem principalmente o INP: ocupam o processador enquanto a pessoa tenta tocar no botão.

1. Inventariar o que está instalado.

2. Remover o que ninguém consulta há meses.

3. Carregar depois do conteúdo o que precisa ficar.

4. Trocar o mapa embutido por imagem com link, e o chat por botão de WhatsApp — o mesmo raciocínio da [landing page sem formulário](/blog/landing-page-que-converte-whatsapp-pixel/).

O trade-off é declarável. O Pixel existe para medir conversão e alimentar campanha: medir é um custo de velocidade que se escolhe pagar. Se a empresa decidir manter tudo, está certo — desde que saiba o que está pagando.

**Depois: o JavaScript da aplicação e, por último, servidor e cache**

Em site institucional e landing page, o JavaScript próprio costuma ser a menor parcela do problema. Em **SPA** (aplicação de página única, o JavaScript monta a tela no navegador) a conversa muda: se o HTML chega vazio, o conteúdo principal só aparece depois que o pacote baixa e executa, e o LCP herda esse tempo.

Duas alavancas: entregar o HTML já renderizado e dividir o pacote para que cada página carregue só o que usa — caminho descrito em [SEO para SPAs React sem Next](/blog/seo-para-spas-react-sem-next/). E há o item que parece técnico e é de escopo: biblioteca pesada para efeito visual pequeno, como carrossel ou animação de rolagem.

**Cache** é a cópia guardada de uma resposta já calculada; **CDN** é a rede que guarda essa cópia perto de quem acessa. Servidor lento aparece no tempo até o primeiro byte, a espera antes de qualquer pixel. Quando o problema real são megabytes de imagem e uma lista de scripts de terceiro, um plano de hospedagem mais caro melhora frações e não muda a percepção de ninguém.

A exceção existe: aplicação com consulta pesada a banco, onde o servidor é o gargalo. Mesmo aí a correção é consulta e cache, não plano maior. Sem [instrumento que mostre onde o tempo vai](/blog/devops-observabilidade-e-confianca-entre-times-e-clientes/), trocar de hospedagem é palpite pago.

**Quando reescrever sai mais barato que otimizar**

Na maioria dos sites lentos a causa é acúmulo: plugin somado a plugin, script somado a script, tema pesado com página montada por construtor visual. Não é código malfeito — é sedimento. Otimizar sem cortar escopo economiza no lugar errado: comprimir a imagem de um site que carrega uma pilha de plugins não muda o total.

— **Sinais de que otimizar deixou de valer:** cada correção reabre outro defeito, ninguém sabe para que serve metade do que está instalado, e o construtor visual impede controlar o HTML entregue.

— **Sinais de que otimizar basta:** o site é simples, a estrutura é sã e o problema está concentrado em imagem, fonte e três scripts identificáveis.

Reescrever tem custo e risco próprios, a começar pelo [prazo, que só se estima depois do escopo fechado](/blog/prazo-entrega-software/). Se o site já recebe busca, exige [plano de migração com mapa de redirecionamento](/blog/plano-migracao-site/) escrito antes de qualquer linha de código. A conta é comparável: horas de otimização recorrente contra o valor de refazer enxuto, faixa que está no [guia de quanto custa criar um site](/blog/quanto-custa-criar-um-site-em-2026/).

**Velocidade é escopo, não serviço extra depois do go-live**

Performance não é otimização posterior. É consequência do que foi decidido no [escopo](/blog/escopo-de-projeto-de-software/), e faz parte tanto do SEO técnico de base — a fundação de todo [trabalho de conteúdo feito para buscar posição](/blog/seo-de-conteudo-para-marcas-de-tecnologia-e-servicos/) — quanto da [landing page que converte visita em agendamento](/blog/landing-pages-b2b-que-convertem-demonstracao-tecnica/). Site montado com peso sob controle desde o começo raramente precisa de otimização depois.

Na Projask, o que se entrega é HTML servido pronto, imagem dimensionada, fonte no próprio domínio e a lista honesta do que cada script de terceiro custa. Sem promessa de nota nem de posição — critério verificável é o que cabe em um [checklist para escolher quem vai fazer o site](/blog/como-escolher-fabrica-de-software-alinhada-a-seu-produto/). Quem quiser discutir um site que está lento, a conversa é pelo WhatsApp.

**Qual a ordem correta para corrigir um site lento?**

A ordem que rende mais por esforço começa na imagem e na fonte acima da dobra — não na hospedagem. Depois vêm os scripts de terceiros como Pixel, tag manager, chat e mapa embutido. Em seguida, o JavaScript da aplicação. E só no fim, servidor e cache. Essa sequência evita gastar semanas trocando de hospedagem enquanto o que atrasa a página continua sendo um arquivo pesado no topo dela.

**Scripts de rastreamento como Meta Pixel e widgets de chat deixam o site lento?**

Sim. Script de terceiro é código carregado do servidor de outra empresa, e você não controla o tamanho dele, a velocidade, nem quando ele muda. O tag manager é especialmente traiçoeiro porque parece um script só e é a porta por onde entram outros, muitas vezes sem revisão. Widget de chat e mapa embutido costumam ser os arquivos mais pesados da página.

Esses scripts atingem principalmente o INP, ocupando o processador do celular justamente enquanto a pessoa tenta tocar no botão. Cada um entrou por um motivo comercial — medir conversão, por exemplo, tem valor real. O importante é saber que é um custo de velocidade que se escolhe pagar.

**Qual a diferença entre dado de laboratório e dado de campo no PageSpeed Insights?**

Dado de laboratório é uma simulação controlada com aparelho virtual, rede virtual e uma execução. Serve para comparar antes e depois de uma alteração. Dado de campo é a medição do que aconteceu com visitantes reais, no aparelho e na rede deles, ao longo de semanas — é o que o buscador observa.

Os dois discordam com frequência porque medem coisas diferentes. A nota de 0 a 100 vem do laboratório, e melhorá-la sem mexer no campo é otimizar o termômetro. O cenário que decide é celular em rede ruim, não o desktop com fibra onde o site costuma ser testado.

**Quando vale mais reescrever o site do que otimizar o que já existe?**

Na maioria dos sites lentos a causa é acúmulo: plugin somado a plugin, script somado a script, tema pesado. Não é código malfeito — é sedimento. Otimizar sem cortar escopo economiza no lugar errado.

Sinais de que otimizar deixou de valer: cada correção reabre outro defeito, ninguém sabe para que serve metade do que está instalado, e o construtor visual impede controlar o HTML entregue. Sinais de que otimizar basta: o site é simples, a estrutura é sã e o problema está concentrado em imagem, fonte e três scripts identificáveis.

Reescrever tem custo e risco próprios, especialmente se o site já recebe busca — precisa de plano de migração com redirecionamentos. A conta é comparável: horas de otimização recorrente contra o valor de refazer enxuto.

**Trocar de hospedagem resolve site lento?**

Não costuma ser a solução principal. Servidor lento aparece no tempo até o primeiro byte, a espera antes de qualquer pixel, medida em frações de segundo. Quando o problema real são megabytes de imagem e uma lista de scripts de terceiro, um plano de hospedagem mais caro melhora frações e não muda a percepção de ninguém.

A exceção existe: aplicação com consulta pesada a banco, onde o servidor é de fato o gargalo. Mesmo aí a correção é consulta e cache, não plano maior. Sem instrumento que mostre onde o tempo vai, trocar de hospedagem é palpite pago.