Por que a velocidade do site importa e o que costuma deixá-lo lento

O site abre rápido no escritório, no Wi-Fi, no notebook do dono. Só que o cliente que vai ler o seu site não está no escritório: está numa fila de banco, com o celular de três anos atrás e um sinal que oscila. Para ele, a mesma página pode levar o triplo do tempo, e a decisão de ficar ou voltar para a busca acontece nesses segundos.

Velocidade, por isso, não é um capricho técnico. Mas também não é um assunto em que se deva sair mexendo às cegas. A ordem certa é medir, interpretar, achar o culpado e só então corrigir, e este artigo segue esse caminho.

Primeiro, medir do jeito certo

A ferramenta mais acessível é o PageSpeed Insights, gratuito, do Google: você cola o endereço e ele devolve dois tipos de informação que costumam ser confundidos:

• Dados de campo: medidos em visitantes reais, nos últimos 28 dias. Mostram como o site se comporta de verdade, com o aparelho e a conexão de quem acessa. Sites com pouco tráfego podem não ter dados de campo suficientes, e a ferramenta avisa quando é o caso;
• Dados de laboratório: uma simulação feita na hora pelo Lighthouse, que carrega a página uma vez, num celular simulado e numa rede controlada. Servem para investigar e comparar antes e depois de uma mudança, mas não representam todos os visitantes, e por isso podem divergir dos dados de campo.

Teste a versão para celular, que costuma ser a pior. E não se assuste com uma nota que oscila alguns pontos entre uma medição e outra: ela varia por natureza. O que importa é a tendência e, principalmente, o que a ferramenta aponta como causa.

Os três números que o Google acompanha

O Google resume a experiência de carregamento em três métricas, chamadas Core Web Vitals. Para cada uma, há um limite considerado "bom", avaliado no percentil 75 das visitas (ou seja, três de cada quatro visitantes precisam ter uma experiência pelo menos assim):

Métrica	O que mede, em palavras simples	Considerado bom
LCP (maior elemento visível)	Quanto tempo leva até aparecer o conteúdo principal da página, como a imagem de destaque ou o título grande	até 2,5 segundos
INP (interação com a próxima pintura)	O tempo entre o toque ou clique do visitante e a página reagir	até 200 milissegundos
CLS (mudança de layout)	O quanto o conteúdo "pula" enquanto carrega, como quando o botão desce na hora em que você vai clicar	até 0,1

Se um destes está no vermelho, já se sabe por onde começar: LCP alto costuma indicar imagem ou servidor pesados; INP alto aponta para scripts demais travando o aparelho; CLS alto aponta para imagens, anúncios ou fontes que ocupam espaço só depois de carregar.

Velocidade ajuda no Google? Ajuda, mas sem milagre

O Google afirma que os Core Web Vitals são usados pelos seus sistemas de ranking, e também que um bom resultado nessas métricas não garante posição alta: a relevância do conteúdo pesa mais, e uma página lenta com a melhor resposta ainda pode aparecer à frente de uma rápida e fraca. Tratar velocidade como "o segredo do SEO" é exagero.

O argumento mais forte é o do visitante. Um estudo encomendado pelo Google, feito com dezenas de marcas, mediu o efeito de tornar a versão móvel apenas 0,1 segundo mais rápida: no varejo, a conversão subiu 8,4%; em viagens, 10,1%. São empresas grandes, com milhões de sessões, e não se deve esperar os mesmos percentuais num site pequeno. O que o estudo mostra é a direção: até diferenças que a pessoa nem percebe conscientemente mudam o comportamento.

Onde costuma estar o peso

O Web Almanac 2025, que analisa milhões de páginas, indica que uma página inicial típica pesa algo entre 2,5 e 3 MB, e que as imagens são a maior fatia desse peso. Isso combina com o que se vê em sites de pequenas empresas.

Imagens

É o primeiro lugar a olhar. Os problemas mais comuns:

• Foto enviada direto da câmera, com milhares de pixels de largura exibida em uma área de 400. Reduza para o tamanho em que ela aparece;
• Formato antigo. WebP e AVIF costumam comprimir melhor que JPEG e PNG e funcionam nos navegadores atuais. Mantenha JPEG ou PNG como alternativa quando preciso;
• Uma imagem para todas as telas. O atributo srcset permite oferecer versões de tamanhos diferentes, e o navegador escolhe a adequada;
• Imagem sem largura e altura declaradas, que faz o conteúdo pular quando carrega (é a causa clássica de CLS alto);
• Carregamento tardio na imagem principal. O "lazy-load" é ótimo para as imagens que ficam abaixo da primeira tela, e prejudicial para a imagem maior do topo, que deve carregar o quanto antes. Quem recomenda isso é a própria documentação do Google.

Scripts de terceiros

Chat, pixels de anúncio, mapas incorporados, vídeos, botões de redes sociais, ferramentas de mapa de calor: cada um é um pedaço de código de outra empresa, que seu site precisa baixar e executar, e sobre o qual você não tem controle. Faça uma lista do que está instalado, e para cada item pergunte: alguém usa? Já tomamos alguma decisão com esses dados? Se a resposta for "não sei", é candidato a sair. Os que ficam devem carregar de forma assíncrona, para não travar o resto da página.

Fontes

Fontes personalizadas são uma fonte comum de atraso e de texto "piscando". Prefira poucos pesos e estilos (cada um é um arquivo), formato WOFF2 e uma configuração de exibição (font-display) que mostre o texto com uma fonte provisória enquanto a definitiva carrega.

Servidor e hospedagem

Antes de a página começar a aparecer, o servidor precisa responder. O Google recomenda que a maioria dos sites busque um tempo de resposta (TTFB) de 0,8 segundo ou menos. Se esse número está alto de forma consistente, mexer em imagens não resolve tudo: aí entram a hospedagem, a forma como o site gera as páginas e o uso de cache, que evita refazer o trabalho a cada visita. Arquivos que raramente mudam, como imagens e folhas de estilo, podem ficar guardados no navegador do visitante por muito tempo. Quem cuida do site precisa saber configurar isso.

Plugins e temas pesados

Em sites feitos sobre plataformas com muitos plugins, cada extensão acrescenta código que roda em todas as páginas, mesmo as que não precisam dele. Se o seu site tem uma dezena de plugins que "alguém instalou um dia", a limpeza costuma render ganhos expressivos.

O que não costuma adiantar

• Perseguir a nota 100. Ela é um indicador, não um objetivo. Uma nota 85 com bom desempenho de campo é melhor que uma 100 em laboratório e uma experiência ruim na vida real;
• Trocar de hospedagem sem medir. Se o TTFB já é baixo, o problema está em outro lugar e a mudança custa dinheiro sem resolver;
• Ajustes minúsculos antes do grande peso. Reduzir 3 KB de código enquanto há uma imagem de 4 MB no topo não muda nada;
• Medir uma vez só. Meça, mude uma coisa, meça de novo. Só assim se sabe o que funcionou.

Uma ordem prática para começar

1. Rode o PageSpeed Insights na página inicial e na página mais acessada, na versão móvel;
2. Anote os três números (LCP, INP, CLS) e o que a ferramenta lista como maiores oportunidades;
3. Reduza e converta as imagens do topo da página;
4. Remova scripts e plugins sem uso;
5. Verifique cache e tempo de resposta do servidor com quem cuida da hospedagem;
6. Meça de novo, na mesma página, e compare.

Quase sempre os dois ou três primeiros passos concentram a maior parte do ganho. Se o resultado continuar ruim depois deles, o problema é estrutural (a forma como o site foi construído), e aí vale uma conversa técnica sobre o que refazer, em vez de acumular remendos.

Velocidade é só uma parte da experiência no celular. O artigo Site no celular: o que conferir antes de publicar cobre o resto: leitura, toque, formulários e contato. Se o seu site está lento e você quer uma opinião de quem constrói sites, conte o caso pelo formulário de briefing.