Site lento: o que realmente trava o carregamento e o que dá para resolver

Quase toda empresa descobre que o site é lento pelo caminho errado: um cliente comenta, ou o relatório de anúncios mostra que muita gente clicou e pouca gente chegou. O dono abre o site no computador do escritório, a página carrega em dois segundos e o assunto morre ali.

O problema é que o seu site, no seu computador, na sua internet, já está em cache. Quem está avaliando a empresa pela primeira vez abre o site em um celular de três anos, no 4G da rua, sem nada guardado. É essa a visita que conta, e é ela que costuma esperar sete, oito, dez segundos por uma tela que nunca termina de montar.

Este texto é sobre o que realmente pesa no carregamento e sobre o que dá para corrigir sem refazer nada. Nem tudo é ajuste fino: parte é decisão de plataforma e de hospedagem, e vale saber a diferença antes de pagar por otimização que não vai resolver.

O que site lento quer dizer para quem está esperando

Velocidade de site não é um número só. Quem está do outro lado passa por três momentos diferentes, e cada um deles pode falhar sozinho:

• A tela em branco. O tempo entre tocar no link e ver qualquer coisa. Se passa de dois ou três segundos, boa parte das pessoas volta antes de o site existir para elas.
• A tela que aparece incompleta. O texto está lá, mas a imagem principal ainda não, o menu está desmontado e o logo salta de lugar quando a fonte termina de carregar.
• A tela que não responde. Tudo parece pronto, a pessoa toca no botão e nada acontece, porque o navegador ainda está processando script.

O terceiro é o mais perigoso, porque parece defeito e não lentidão. A pessoa toca duas, três vezes, o formulário envia duplicado ou ela desiste achando que o site está quebrado. Do lado de fora, lentidão e erro são a mesma coisa, e o efeito é sempre maior no celular, que é de onde vem a maior parte do tráfego hoje.

Os três números pelos quais o Google mede

O Google resumiu essa experiência em três indicadores, que aparecem em qualquer ferramenta de medição com nomes em inglês. Vale conhecer os três, porque eles apontam para causas diferentes:

• LCP (maior elemento visível). Quanto tempo leva até o principal bloco da tela aparecer, que geralmente é a imagem de destaque ou o título grande. A meta é até 2,5 segundos. Quando está ruim, a causa costuma ser imagem pesada ou servidor lento para responder.
• INP (resposta ao toque). Quanto o site demora para reagir quando a pessoa clica ou toca. A meta é até 200 milissegundos. Quando está ruim, a causa é excesso de script rodando ao mesmo tempo.
• CLS (deslocamento de layout). O quanto a página pula enquanto carrega. A meta é abaixo de 0,1. Quando está ruim, é imagem sem tamanho declarado, banner que entra depois ou fonte que troca no meio.

Esses três compõem o que o Google chama de Core Web Vitals, e eles entram como fator de classificação na busca. Não são o fator principal, e melhorar velocidade sozinho não coloca ninguém em primeiro lugar. Mas eles funcionam como desempate: entre duas páginas parecidas em conteúdo, a que abre melhor no celular leva vantagem. E quando o site fica ruim a ponto de as pessoas voltarem para a busca, isso o Google enxerga de outras formas, como já comentamos no checklist de quando o site some do Google.

Como medir o seu site em dez minutos

Dá para ter um diagnóstico honesto sem contratar ninguém. Três passos, nesta ordem:

1. PageSpeed Insights. Abra a ferramenta gratuita do Google, cole o endereço de uma página do seu site e escolha a aba de celular, que é a que importa. Ela devolve os três indicadores acima e uma lista de oportunidades.
2. Olhe primeiro os dados de campo. No topo do relatório, quando existe, aparece a experiência real de quem visitou o site nos últimos 28 dias. Esse bloco vale mais que a nota colorida de baixo, que é um teste de laboratório em um aparelho simulado. Site pequeno pode não ter dados de campo suficientes, e aí o laboratório é o que há.
3. Search Console. Se o site está cadastrado, o relatório de Core Web Vitals mostra quais grupos de páginas são o problema. É o que separa um defeito pontual de um defeito de template.

Duas armadilhas na hora de medir. A primeira é testar só a página inicial, que costuma ser a mais cuidada. Meça também a página de produto, a de serviço e a de contato, porque são elas que recebem quem vem do Google e do anúncio. A segunda é medir uma vez e tirar conclusão: rode duas ou três vezes, porque o teste varia.

E vale o teste que nenhuma ferramenta faz. Pegue um celular comum, desligue o wi-fi, abra o site pelo 4G e cronometre até conseguir ler alguma coisa.

Imagem: a causa mais comum e a mais fácil de corrigir

Na maior parte dos sites de empresa, imagem é mais da metade do peso da página, e quase sempre por um motivo banal: a foto foi enviada como saiu da câmera ou do celular, com 4.000 pixels de largura e vários megabytes, para ser exibida em um espaço de 800 pixels. O navegador baixa tudo e joga o excedente fora.

O que resolve, na ordem de impacto:

• Redimensionar antes de subir. Nenhuma imagem de site precisa passar de 2.000 pixels de largura, e a maioria vive bem com 1.200.
• Comprimir. Uma foto bem comprimida fica entre 100 KB e 300 KB sem diferença visível na tela. Se as suas estão em megabytes, esse é o ganho mais barato disponível.
• Usar formato moderno. WebP e AVIF entregam a mesma qualidade com bem menos peso que JPEG, e todos os navegadores atuais aceitam.
• Carregar sob demanda. Imagem que está lá embaixo não precisa ser baixada antes de alguém rolar até ela. É o carregamento preguiçoso, hoje uma linha de código por imagem.
• Declarar largura e altura. Isso não deixa a página mais rápida, mas impede que ela pule quando a imagem chega, que é metade do problema de deslocamento de layout.

Um detalhe que muita gente inverte: a imagem principal da primeira tela é a única que não deve esperar. Ela é justamente o que o LCP mede. Carregamento preguiçoso nela atrasa exatamente o número que se quer melhorar.

Scripts de terceiros: o peso que entrou sem ninguém notar

Aqui está a causa que mais surpreende o dono do site, porque nada disso foi instalado por um desenvolvedor: foi sendo colado no site ao longo dos anos, um código de cada vez.

A lista típica de uma empresa pequena: Google Analytics, Gerenciador de Tags, pixel do Facebook, pixel do Google Ads, botão flutuante de WhatsApp, chat de atendimento, banner de cookies, mapa incorporado, vídeo do YouTube na página inicial e um ou dois selos de segurança. Cada um parece leve. Juntos, costumam pesar mais que todo o resto do site.

O problema não é só o tamanho. É que esses arquivos vêm de servidores que não são seus, e o seu site fica esperando a resposta deles. Um chat com servidor lento atrasa a sua página, e não há nada no seu servidor que conserte isso.

O que fazer é menos técnico do que parece:

• Liste tudo que está instalado e pergunte, item por item, quem olhou aquele dado nos últimos seis meses. Ferramenta que ninguém abre é peso puro.
• Tire pixel de campanha encerrada. É comum achar pixel de três anos atrás carregando em todas as páginas.
• Vídeo na página inicial deve entrar como imagem com botão de play, e só carregar o player depois do clique.
• Chat e botão flutuante podem entrar segundos depois do resto, ou só quando a pessoa rola a página.
• Mapa incorporado costuma virar bem uma imagem com link para o aplicativo de mapas.

Plugins, temas e o site que foi crescendo

Sites construídos sobre temas prontos com muitos plugins têm um padrão de envelhecimento conhecido: cada recurso novo chegou como uma instalação a mais, e cada instalação trouxe os próprios arquivos de estilo e de script, que passam a carregar em todas as páginas mesmo quando o recurso só é usado em uma. O sintoma é o site que faz pouca coisa e mesmo assim baixa dezenas de arquivos.

O tema pesado é parente disso: temas vendidos como universais carregam todos os recursos possíveis porque não sabem quais você vai usar, e você paga o peso de todos para usar três.

A pergunta útil não é quantos plugins existem, é quantos aparecem na página. Um plugin de nota fiscal que roda no painel administrativo não pesa para o visitante. Um construtor visual de páginas pesa em todas.

A hospedagem: o teto que nenhum ajuste fura

Existe um número que nenhuma otimização de imagem resolve: o tempo que o servidor leva para começar a responder. Se o seu servidor gasta 1,5 segundo só para enviar o primeiro byte, a página já começa 1,5 segundo atrasada, com qualquer imagem e qualquer tema.

As causas usuais são três. Hospedagem compartilhada barata demais, com centenas de sites no mesmo servidor disputando processador. Servidor distante do público, o que se resolve com CDN, uma rede de cópias do site espalhadas geograficamente. E ausência de cache, que faz o servidor remontar a mesma página do zero para cada visitante.

Isso se mistura com confiabilidade, e os dois vêm do mesmo lugar: hospedagem escolhida pelo menor preço da tabela, assunto do texto sobre hospedagem, backup e site fora do ar. O essencial: quando o gargalo é o servidor, trocar de servidor é o conserto, e não há ajuste que substitua.

Na loja virtual, lentidão tem preço direto

Em site institucional, lentidão custa orçamento que não foi pedido. Em loja virtual, ela custa carrinho abandonado, e o efeito se acumula porque a pessoa passa por várias páginas antes de comprar. Três pontos concentram o problema:

• A página de categoria, com dezenas de fotos de produto carregando ao mesmo tempo. É onde o carregamento sob demanda mais rende.
• A busca interna, que consulta o banco a cada digitação e, com catálogo grande, trava a loja inteira.
• O checkout, que junta cálculo de frete, verificação de estoque, meio de pagamento e antifraude, cada um dependendo de um serviço externo. É a tela mais lenta e a mais cara de perder, assunto do texto sobre o checkout que perde venda.

Quando a lentidão vem da própria plataforma e não do que foi instalado sobre ela, o caminho deixa de ser otimização e passa a ser migração de plataforma, que é uma decisão maior e precisa ser tomada com esse dado na mão.

O que resolver esta semana e o que só se resolve refazendo

Nem toda lentidão justifica um site novo, e separar as duas listas evita gastar no lugar errado. Dá para resolver sem mexer na estrutura:

1. Comprimir e redimensionar as imagens das páginas mais visitadas.
2. Remover scripts de terceiros que ninguém usa mais.
3. Adiar chat, botão flutuante e vídeo para depois do carregamento principal.
4. Ligar cache de página e compressão no servidor.
5. Declarar tamanho de imagem e reservar espaço para banners, o que corrige o pulo da tela.
6. Colocar uma CDN na frente do site.

Esses seis itens costumam cortar metade do tempo de carregamento, e levam dias, não meses.

Só se resolve com decisão maior:

1. Tema pesado que carrega tudo em toda página. Trocar de tema é reconstruir o visual.
2. Acúmulo de plugins que se sobrepõem, herdado de fornecedores diferentes.
3. Hospedagem que responde devagar mesmo com o site vazio.
4. Plataforma que não permite mexer no que importa.

Uma regra prática para decidir: se o servidor já demora mais de um segundo para responder com o site em repouso, comece pela hospedagem. Otimizar imagem antes disso é pintar parede com infiltração.

Velocidade é parte do mesmo problema de ser encontrado

Site rápido não traz visita sozinho: ele preserva a visita que já foi conquistada. Quem investe em busca local, conteúdo e anúncio está pagando para trazer gente, e a velocidade decide quanto dessa gente chega até o formulário, como comentamos ao falar de site e SEO local.

Por isso lentidão é cara de um jeito difícil de enxergar: não aparece como despesa, aparece como resultado abaixo do esperado em tudo ao mesmo tempo.

Se o seu site está devendo aqui, a NSWeb mede, separa o que é ajuste do que é estrutura e executa os dois, da hospedagem ao desenvolvimento. Fale com a gente.

Perguntas frequentes