Quase toda empresa trata a velocidade do site como um assunto de programador. Alguma coisa técnica, que aparece em relatório com sigla em inglês e que se resolve depois, quando sobrar tempo. É um erro caro, porque velocidade não é uma característica do site. É o filtro que decide quantas das pessoas que você atraiu, muitas vezes pagando por elas, chegam a ver o que você tem para oferecer. Tudo o que acontece na sua página, da primeira frase ao botão de contato, só existe para quem esperou o carregamento terminar.
Velocidade não é detalhe técnico, é fator de receita
Imagine que você contratou um vendedor excelente para ficar na porta da sua loja. Ele conhece o produto, sabe conduzir a conversa, fecha bem. O detalhe é que ele demora cinco segundos para levantar a cabeça e olhar para quem entra. Nesses cinco segundos, uma parte das pessoas simplesmente vai embora. Elas não avaliaram o seu preço, não viram o seu portfólio, não leram o depoimento do cliente satisfeito. Elas saíram antes do começo.
É exatamente isso que um site lento faz, com a diferença de que na loja física você veria as pessoas saindo. No site, elas somem em silêncio, e o painel de estatísticas mostra apenas um número de visitas que parece razoável. Ninguém reclama de site lento. As pessoas voltam para o resultado de busca e clicam no concorrente, e essa é a razão pela qual o problema costuma passar anos sem ser notado dentro da empresa.
Sobre o tamanho exato dessa perda, é preciso honestidade. Circulam pela internet números muito específicos, do tipo tantos por cento de conversão perdida por cada segundo de atraso, quase sempre atribuídos a estudos antigos, feitos em contextos que não têm nada a ver com uma empresa de porte médio no interior de São Paulo. Não vamos repetir esses números aqui. O que se pode afirmar com segurança, porque é observável em qualquer conjunto de dados de tráfego, é a tendência: quanto mais tempo a página demora a aparecer, maior a proporção de visitantes que desiste, e essa curva é mais íngreme no começo. A diferença entre 1 e 3 segundos costuma custar bem mais que a diferença entre 6 e 8, porque quem esperou 6 segundos já demonstrou que tinha muito interesse.
Há ainda um efeito de percepção que raramente entra na conversa. Um site que abre instantaneamente comunica competência antes de qualquer texto ser lido. Um site que engasga, mostra um retângulo cinza e depois reorganiza tudo comunica improviso. Para negócios em que a confiança é o principal fator de decisão, como clínicas, escritórios de advocacia, contabilidade e construção, esse sinal silencioso vale muito. Tratamos disso com mais profundidade no guia sobre o que um site profissional precisa ter, onde velocidade aparece como um dos itens não negociáveis.
Por que no Brasil a velocidade pesa mais do que na média mundial
A maior parte do material sobre desempenho web disponível em português é tradução de conteúdo produzido nos Estados Unidos ou na Europa, onde o cenário de acesso é bem diferente do nosso. Isso importa, porque três características do mercado brasileiro fazem com que o mesmo site lento cause mais estrago aqui do que causaria lá.
1. O tráfego é dominado pelo celular
Em praticamente todos os projetos que acompanhamos, de clínicas a lojas virtuais, a maioria absoluta das visitas vem de aparelhos móveis, e em vários setores essa fatia supera quatro em cada cinco visitantes. Isso muda tudo, porque o celular é o pior ambiente possível para um site pesado: tela pequena, conexão variável, processador modesto e bateria como restrição. Quando o site é aprovado em uma reunião, olhando um monitor grande conectado à fibra do escritório, cria-se uma ilusão perigosa de que está tudo bem.
2. A qualidade da conexão varia muito, inclusive na mesma sessão
A discussão pública sobre internet no Brasil costuma girar em torno de velocidade contratada, mas o que afeta a navegação real é a instabilidade. A mesma pessoa passa do wi-fi de casa para os dados móveis no carro, entra em uma região com sinal fraco, pega um elevador, chega ao trabalho e volta para o wi-fi. Um site enxuto atravessa essas variações sem que o visitante perceba. Um site pesado transforma cada oscilação em uma tela branca, e telas brancas produzem desistência imediata.
3. O parque de aparelhos é mais antigo do que os relatórios sugerem
Este é o ponto mais subestimado de todos. Boa parte do custo de um site pesado não está no download, está no processamento. Cada script precisa ser interpretado e executado pelo aparelho, e um celular de entrada com três ou quatro anos de uso faz isso várias vezes mais devagar que um aparelho recente de topo de linha. Ou seja, o mesmo site que responde na hora no celular novo do dono da empresa pode travar por segundos no celular do cliente. É a diferença entre medir com a régua certa e medir com a régua conveniente.
Core Web Vitals em português simples: LCP, INP e CLS
Core Web Vitals é o nome que o Google deu a um conjunto pequeno de medidas que tentam traduzir, em números, o que uma pessoa comum sente ao abrir uma página. A escolha foi deliberadamente enxuta: em vez de dezenas de indicadores técnicos, três perguntas que qualquer um entende. Demorou para aparecer? Demorou para responder quando eu toquei? Ficou pulando de lugar enquanto eu lia?
| Métrica | O que mede, em português | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP | Quanto tempo até aparecer o conteúdo principal da tela, normalmente a imagem grande ou o título do topo | Até 2,5s | 2,5s a 4s | Acima de 4s |
| INP | Quando a pessoa toca em um botão ou menu, quanto tempo até a tela reagir de forma visível | Até 200ms | 200ms a 500ms | Acima de 500ms |
| CLS | O quanto o conteúdo se desloca sozinho durante o carregamento, fazendo a pessoa clicar no lugar errado | Até 0,1 | 0,1 a 0,25 | Acima de 0,25 |
| TTFB (apoio) | Quanto tempo o servidor leva para começar a responder, antes de qualquer conteúdo ser baixado | Até 0,2s | 0,2s a 0,8s | Acima de 0,8s |
| FCP (apoio) | Quanto tempo até aparecer qualquer coisa na tela, mesmo que ainda não seja o conteúdo principal | Até 1,8s | 1,8s a 3s | Acima de 3s |
Um detalhe importante sobre como o Google avalia: ele não usa a média dos seus visitantes, e sim um valor que representa a maioria deles, deixando de fora apenas os casos mais extremos. Na prática, isso significa que não adianta ter um site rápido para os visitantes de conexão boa e lento para o resto. A avaliação considera a experiência típica, o que empurra na direção certa: otimizar para o visitante mediano, não para o melhor caso.
Outra coisa que vale entender é que as três métricas quase nunca falham pelas mesmas razões. LCP costuma ser problema de peso e de ordem de carregamento, quase sempre ligado a imagens e ao tempo de resposta do servidor. INP é problema de processamento, ligado a excesso de código executando no aparelho. CLS é problema de construção, ligado a elementos que entram na página sem espaço reservado. Por isso o diagnóstico correto começa por saber qual das três está ruim, e não por aplicar uma lista genérica de otimizações.
Como medir o seu site hoje, sem depender de ninguém
A medição é gratuita, leva poucos minutos e não exige nenhum conhecimento técnico. O que exige é disciplina em olhar as coisas certas, porque as ferramentas mostram muita informação e a maior parte dela não é acionável para quem toma decisão de negócio.
- ✓Abra o PageSpeed Insights e cole o endereço da sua página mais importante, não só a página inicial.
- ✓Selecione a aba de dispositivos móveis. Ignore a de computador nesta primeira leitura.
- ✓Procure o bloco de dados de usuários reais no topo. Se ele existir, é a informação mais confiável do relatório.
- ✓Anote os três valores: LCP, INP e CLS. Compare com a tabela de referência deste guia.
- ✓Desça até o diagnóstico e olhe apenas as duas ou três oportunidades com maior economia estimada.
- ✓Repita o teste em uma página de serviço e, se houver loja, em uma página de produto.
- ✓Guarde a data e os números. Sem registro anterior, você não consegue provar melhoria depois.
O quarto passo merece um comentário. Muita gente testa apenas a página inicial e conclui que o site está bem. Só que a página inicial costuma ser a mais cuidada e frequentemente não é a que recebe mais visitas vindas do Google. As páginas de serviço, os artigos e as páginas de produto é que carregam o tráfego de busca, e são justamente as que acumulam imagens grandes e componentes adicionais ao longo do tempo. Se você vai testar uma página só, teste a que mais recebe visita, não a que mais orgulha.
Uma observação sobre variação entre testes. É normal que dois testes seguidos na mesma página deem notas diferentes, às vezes com diferença de dez pontos ou mais. Isso acontece porque o teste simulado depende de recursos compartilhados no momento da execução. Não entre em pânico com uma medição isolada e não comemore uma também. Rode três vezes e trabalhe com o valor do meio, ou melhor ainda, confie nos dados de usuários reais, que já são uma agregação de muitas visitas.
As ferramentas de medição e o que cada uma realmente conta
Existe uma confusão frequente entre dois tipos completamente diferentes de medição, e ela gera discussões improdutivas entre empresas e fornecedores. Dados de laboratório são simulações: a ferramenta abre a sua página em um ambiente controlado, com conexão e aparelho simulados, e mede. Dados de campo são coletados de visitantes reais ao longo de semanas. Os dois servem para coisas diferentes e nenhum substitui o outro.
| Ferramenta | O que ela conta bem | O que ela não conta | Quando usar |
|---|---|---|---|
| PageSpeed Insights | Nota simulada, diagnóstico detalhado e, quando há tráfego suficiente, dados de usuários reais | Não mostra a experiência de visitantes específicos nem o efeito em conversão | Primeiro diagnóstico e acompanhamento mensal |
| Search Console (relatório de experiência) | Como o Google enxerga o seu site inteiro, agrupando páginas por status | Não explica a causa de cada problema, apenas aponta os grupos afetados | Visão geral do site e prioridade por volume de páginas |
| Ferramentas de desenvolvedor do navegador | Ordem exata de carregamento, peso de cada arquivo e o que está travando o processamento | Reflete a sua máquina e a sua conexão, que são melhores que a média | Investigação técnica, depois do diagnóstico inicial |
| Testes de carregamento por região | Como o site se comporta a partir de diferentes localidades e conexões | Simulações também, e nem sempre com aparelhos representativos do Brasil | Quando o público é geograficamente disperso |
| Teste manual no celular real | A percepção humana, que é o que de fato importa para o visitante | Não gera número comparável nem histórico | Sempre, como validação final antes de aprovar |
As causas de lentidão em ordem de impacto
Depois de auditar dezenas de sites de pequenas e médias empresas brasileiras, o padrão que encontramos é surpreendentemente repetitivo. Não é que cada site tenha um problema exótico e único. É quase sempre a mesma sequência de causas, na mesma ordem, e as duas primeiras costumam explicar a maior parte do estrago.
| Causa | Frequência | Impacto típico | Dificuldade de corrigir | Métrica afetada |
|---|---|---|---|---|
| Imagens sem compressão e fora de escala | Muito alta | Muito alto | Baixa | LCP |
| Excesso de scripts de terceiros | Alta | Alto | Baixa a média | INP e LCP |
| Hospedagem lenta ou saturada | Média | Alto | Média | TTFB e LCP |
| Ausência de cache no servidor e no navegador | Alta | Médio a alto | Baixa | TTFB e LCP |
| Tema ou construtor visual pesado | Média a alta | Médio a alto | Alta | INP e LCP |
| Fontes carregadas de forma bloqueante | Alta | Médio | Baixa | LCP e CLS |
| Vídeos incorporados carregando de imediato | Média | Médio a alto | Baixa | LCP e INP |
| Elementos sem espaço reservado | Alta | Médio | Baixa | CLS |
| Plugins acumulados e sobrepostos | Média | Médio | Média | INP e TTFB |
| Código não usado carregando em todas as páginas | Média | Baixo a médio | Alta | INP |
| Redirecionamentos em cadeia | Baixa a média | Baixo a médio | Baixa | TTFB |
| Banco de dados sem manutenção | Baixa | Variável | Média | TTFB |
Repare no cruzamento entre as colunas de impacto e de dificuldade. As duas causas mais frequentes e de maior impacto, imagens e scripts, estão também entre as mais fáceis de corrigir. Isso é uma notícia excelente e ao mesmo tempo um pouco constrangedora para o mercado: significa que uma quantidade enorme de sites brasileiros está lenta por motivos que se resolvem em uma tarde de trabalho, e continua lenta porque ninguém olhou.
Imagens: o maior vilão e o mais barato de resolver
Se você fizer apenas uma coisa depois de ler este guia, que seja esta. Em site após site, a soma das imagens representa a maior fatia do peso total da página, muitas vezes com folga confortável sobre todo o resto junto. E a causa é quase sempre a mesma história: alguém exportou a foto direto do celular ou recebeu do fotógrafo em alta resolução, e subiu do jeito que estava.
O problema das dimensões
Uma foto de celular moderno costuma ter quatro mil pixels de largura. O espaço onde ela vai aparecer no site, em um celular, tem por volta de quatrocentos. Ou seja, o navegador baixa uma imagem dez vezes maior do que precisa, gasta banda e processamento para redimensioná-la e joga fora quase tudo. O visitante paga essa conta em segundos de espera e em consumo de dados móveis, sem receber nenhuma qualidade adicional em troca, porque a tela não consegue exibir aquele detalhe todo.
O problema do formato
Formatos antigos como JPEG e PNG continuam funcionando perfeitamente, mas foram criados em outra época. Formatos modernos como WebP e AVIF entregam a mesma qualidade visual com uma fração do peso, e são compreendidos por praticamente todos os navegadores em uso hoje. Converter o acervo de imagens de um site para um formato moderno costuma cortar uma parte substancial do peso sem que ninguém perceba diferença olhando.
O problema da prioridade
Há também uma questão de ordem, e não só de peso. A imagem que aparece no topo da página, aquela que normalmente define o LCP, deve ser carregada com prioridade máxima e nunca com carregamento adiado. Já as imagens que estão mais abaixo, que a pessoa só verá se rolar, devem ser adiadas. Inverter essa lógica é um erro comum e produz o pior dos dois mundos: a imagem principal demora e as de baixo competem por banda antes da hora.
- ✓Redimensione cada imagem para, no máximo, o dobro do tamanho em que ela aparece na tela.
- ✓Converta para formato moderno, como WebP, mantendo um formato tradicional apenas se houver necessidade específica.
- ✓Aplique compressão com qualidade entre 75 e 85. Acima disso o ganho visual é imperceptível e o peso dispara.
- ✓Defina largura e altura de todas as imagens no código, para reservar o espaço e evitar salto de layout.
- ✓Use carregamento adiado em tudo que fica abaixo da primeira tela, e nunca na imagem principal do topo.
- ✓Ofereça versões diferentes por tamanho de tela, para que o celular não baixe a versão de computador.
- ✓Substitua vídeos incorporados por uma imagem de capa que só carrega o player após o clique.
- ✓Revise o acervo antigo. Fotos de artigos e portfólio publicados anos atrás costumam ser as piores.
- ✓Evite imagens de fundo decorativas muito grandes, especialmente as que só aparecem no computador.
- ✓Remova imagens que não estão sendo exibidas em lugar nenhum, mas continuam sendo baixadas.
Scripts de terceiros: o vilão que ninguém vê
Se as imagens são o problema visível, os scripts de terceiros são o problema invisível, e por isso costumam ser ainda mais difíceis de resolver politicamente dentro da empresa. Ninguém defende uma foto pesada, mas todo mundo tem uma razão para manter o pixel de rastreamento de uma campanha que acabou em 2023.
Script de terceiro é qualquer código que o seu site carrega de um servidor que não é o seu: ferramenta de análise, pixel de anúncio, mapa incorporado, chat, avaliação de clientes, player de vídeo, botão de rede social, banner de cookies, mapa de calor, teste A/B, widget de agendamento. Cada um deles obriga o navegador a abrir uma conexão nova, esperar a resposta de outro servidor sobre o qual você não tem controle nenhum, e depois executar aquele código no aparelho do visitante.
O custo aparece em duas frentes. A primeira é o tempo de rede, que atrasa o carregamento principal. A segunda, mais grave e menos comentada, é o tempo de processamento: enquanto o celular executa aquele código, ele não consegue responder aos toques do visitante. É exatamente isso que o INP mede, e é por isso que o INP é a métrica que mais falha em sites cheios de ferramentas.
- ✓ Ferramenta de análise principal, porque sem dados você decide no escuro
- ✓ Pixel da plataforma onde você efetivamente anuncia hoje
- ✓ Chat ou WhatsApp, quando é o canal real de atendimento do negócio
- ✓ Avaliações de clientes, quando exibidas em página de decisão
- ✓ Agendamento online, quando substitui uma etapa manual do processo
- ✕ Pixels de plataformas onde você não anuncia mais
- ✕ Segunda e terceira ferramenta de análise medindo a mesma coisa
- ✕ Mapa de calor rodando permanentemente, e não por período de estudo
- ✕ Botões de compartilhamento em redes sociais, que quase ninguém usa
- ✕ Mapa interativo carregado de imediato em página que ninguém abre para ver o mapa
- ✕ Ferramentas testadas há anos e nunca removidas do código
A abordagem prática que recomendamos tem três etapas. Primeiro, faça um inventário completo: liste tudo que o site carrega de fora e escreva ao lado quem dentro da empresa usa aquilo e com que frequência. Segundo, remova sem cerimônia tudo que ficou sem dono. Na nossa experiência, essa etapa sozinha costuma eliminar de um terço a metade dos scripts. Terceiro, para os que ficarem, ajuste o carregamento para que entrem depois que o conteúdo principal já estiver na tela, e não antes.
Hospedagem e tempo de resposta do servidor
Toda visita começa com o navegador pedindo a página e esperando a resposta. Esse tempo de espera inicial, o TTFB, é o piso de tudo. Se o servidor leva um segundo e meio para começar a responder, não existe otimização de imagem capaz de fazer a página aparecer em dois segundos, porque o cronômetro já queimou a maior parte do orçamento antes de o trabalho começar.
As hospedagens compartilhadas mais baratas do mercado funcionam colocando muitos sites no mesmo servidor físico. Enquanto todos os vizinhos estão calmos, funciona bem. Quando um deles recebe um pico de tráfego ou executa alguma rotina pesada, a sua página fica lenta sem que nada tenha mudado do seu lado. Esse é o padrão mais frustrante de todos, porque o site parece bom em um teste e ruim em outro, e ninguém consegue explicar.
| Sinal observado | Provável causa | O que fazer |
|---|---|---|
| TTFB acima de 800ms de forma consistente | Hospedagem saturada ou plataforma pesada | Avaliar migração ou cache no servidor |
| TTFB bom, mas LCP alto | Peso da página, quase sempre imagens | Ir para a frente de imagens, não trocar de servidor |
| Lentidão em horários específicos | Vizinhança barulhenta em servidor compartilhado | Considerar plano dedicado ou outra hospedagem |
| Rápido no Sudeste, lento no Norte e Nordeste | Distância física do servidor | Ativar CDN para distribuir o conteúdo |
| Primeira visita lenta, seguintes rápidas | Ausência de cache no servidor | Ativar cache de página, ganho imediato |
| Site fora do ar em picos de acesso | Plano abaixo da necessidade real | Subir de plano antes da próxima campanha |
Vale um alerta sobre migração. Trocar de hospedagem mal feita pode custar muito mais caro que a lentidão que se pretendia resolver, especialmente se houver mudança de endereços no processo. Se a migração envolver também mudança de estrutura de URLs, leia antes o guia sobre como trocar de site sem perder posições no Google, porque perder o tráfego que você levou anos construindo em troca de meio segundo de carregamento seria um péssimo negócio.
Cache e CDN: entregar sem refazer o trabalho
Cache é a ideia mais simples e mais rentável do desempenho web: guardar o resultado de um trabalho já feito, para não precisar refazê-lo. Sem cache, cada visitante que abre a sua página institucional obriga o servidor a montar aquela página do zero, consultando banco de dados e processando código, mesmo que o conteúdo não mude há oito meses.
Existem várias camadas de cache e vale entender o papel de cada uma. O cache de servidor guarda a página pronta e a entrega direto, o que derruba o TTFB drasticamente. O cache de navegador instrui o aparelho do visitante a guardar imagens, fontes e arquivos de estilo por um período, para que a segunda visita seja quase instantânea. E o CDN distribui cópias do seu conteúdo por servidores espalhados geograficamente, para que quem acessa de longe receba a resposta de um ponto próximo.
Em um país do tamanho do Brasil, o CDN merece atenção especial. Um site hospedado em São Paulo atendendo um visitante em Manaus enfrenta uma distância física que se traduz em milissegundos de atraso em cada ida e volta, e uma página faz dezenas dessas viagens. Se o seu negócio atende o país inteiro, distribuir o conteúdo deixa de ser refinamento e passa a ser básico.
Fontes: leves no peso, pesadas no estrago
Fontes personalizadas raramente são o maior peso de uma página, mas causam um estrago desproporcional porque interferem no momento mais sensível do carregamento. Se o navegador precisa esperar o arquivo da fonte chegar antes de desenhar o texto, o visitante fica olhando para uma tela sem palavra nenhuma, mesmo que todo o resto já esteja pronto.
O comportamento oposto também incomoda: o navegador desenha o texto com uma fonte padrão e depois troca, fazendo tudo dar um pequeno salto e reorganizar. Isso alimenta o CLS e passa aquela sensação de site improvisado. O equilíbrio correto envolve escolher uma fonte de substituição com proporções parecidas, para que a troca seja quase imperceptível.
- Limite a quantidade. Duas famílias de fonte já é bastante para praticamente qualquer site de empresa. Cada peso adicional, como negrito extra ou itálico, é um arquivo a mais.
- Hospede as fontes no seu próprio domínio. Buscar em um servidor externo adiciona uma conexão nova e uma dependência que você não controla.
- Use formatos modernos de arquivo de fonte, que são bem mais leves que os antigos e universalmente compreendidos.
- Carregue com prioridade a fonte usada no topo, porque é ela que participa do LCP, e adie as demais.
- Configure a exibição para não bloquear o texto. É melhor o visitante ler com a fonte provisória do que não ler nada.
- Considere fontes do sistema em projetos onde a identidade visual não depende de uma tipografia específica. Elas custam zero em carregamento.
O layout que pula: como o CLS destrói conversão
De todas as métricas, o CLS é a que mais gente ignora e a que mais irrita o visitante na prática. Você já viveu isso: abre uma página no celular, começa a ler, vai tocar em um link e no instante do toque um banner carrega acima, empurra tudo para baixo e o seu dedo acerta outra coisa. É desagradável, e em uma página de compra ou de contato é diretamente destrutivo.
O mecanismo é sempre o mesmo: algum elemento entra na página depois que o resto já foi desenhado, e como ninguém reservou espaço para ele, tudo que estava embaixo se desloca. As causas mais comuns são imagens sem dimensões declaradas, banners e anúncios que chegam depois, avisos de cookies que aparecem no topo, conteúdo carregado de forma dinâmica e a troca de fonte que mencionamos há pouco.
| Situação | O que acontece com o visitante | Correção |
|---|---|---|
| Imagem sem largura e altura definidas | O texto pula quando a foto termina de carregar | Declarar as dimensões no código |
| Aviso de cookies aparecendo no topo | Toda a página desce e a pessoa perde a leitura | Posicionar de forma fixa, sem empurrar conteúdo |
| Banner ou promoção carregando depois | O botão foge no momento do toque | Reservar o espaço com altura mínima |
| Troca de fonte durante o carregamento | O texto redesenha e as linhas se reorganizam | Escolher fonte de substituição com métricas próximas |
| Conteúdo injetado por script externo | Blocos inteiros aparecem no meio da leitura | Reservar área ou carregar antes da exibição |
| Vídeo incorporado sem proporção definida | Um bloco grande surge e desloca todo o resto | Definir a proporção do contêiner |
INP: quando o clique demora a responder
O INP é a métrica mais recente das três e a que melhor captura a frustração real de quem navega no celular. Ela mede o intervalo entre a pessoa interagir com a página, tocando em um botão, abrindo um menu ou preenchendo um campo, e a tela reagir de forma visível. Um site pode carregar rápido e ainda assim ser péssimo nesse quesito, o que confunde bastante quem só olha a nota geral.
A causa é sempre a mesma: o processador do aparelho está ocupado executando código e não consegue atender ao toque. Como um navegador executa uma coisa de cada vez no que diz respeito à interface, qualquer tarefa longa trava tudo. Em um computador potente, essa tarefa some no meio de outras. Em um celular de entrada, ela vira meio segundo de tela congelada, e o visitante toca de novo achando que não funcionou.
- Reduza a quantidade de código executando. Cada script removido devolve processamento ao aparelho, e essa é a alavanca mais direta.
- Adie o que não é essencial para a primeira interação. Análises, pixels e widgets podem entrar depois que a página já responde.
- Desconfie de animações elaboradas. Efeitos que reagem à rolagem costumam consumir processamento continuamente, e o custo cresce em aparelhos modestos.
- Cuidado com menus e filtros que recalculam tudo. Em catálogos grandes, um filtro mal construído pode travar a tela por segundos.
- Teste em aparelho fraco de propósito. O INP é a métrica em que a diferença entre o celular do dono e o celular do cliente é mais brutal.
O que a plataforma do seu site limita, goste você ou não
Existe um limite de quanto você consegue acelerar um site sem mexer na fundação dele. Um construtor visual precisa carregar a estrutura genérica que permite arrastar e soltar elementos, e essa estrutura vem junto mesmo que a sua página use uma fração dos recursos disponíveis. Um WordPress com tema comercial pesado carrega bibliotecas para funções que talvez você nunca ative.
| Tipo de construção | Teto de desempenho | Esforço para chegar perto do teto | Observação |
|---|---|---|---|
| Construtor visual popular | Médio | Baixo | Você otimiza conteúdo, mas não o código base da plataforma |
| WordPress com tema pesado e muitos plugins | Baixo a médio | Alto | Muito esforço para ganhos modestos, sobreposição de funções |
| WordPress enxuto, tema leve, poucos plugins | Alto | Médio | Excelente relação custo-benefício quando bem disciplinado |
| Plataforma de e-commerce hospedada | Médio | Baixo a médio | Imagens de produto e aplicativos instalados dominam o resultado |
| Site feito sob medida em tecnologia moderna | Muito alto | Médio | Desempenho vem por construção, não por correção posterior |
| Página estática simples | Muito alto | Baixo | Ótimo para campanha, limitado quando o site precisa crescer |
Isso não significa que você precise trocar de plataforma. Significa que vale saber onde está o seu teto antes de contratar horas de otimização. Se o seu site está em um construtor e você já comprimiu imagens, limpou scripts e ainda assim ele fica na faixa mediana, é provável que você tenha chegado ao limite estrutural. Nesse ponto a conversa muda de natureza, e vale compará-la com o custo de reconstrução. Discutimos essas escolhas no guia sobre Wix ou WordPress e as faixas de investimento no guia sobre quanto custa criar um site profissional.
Quanto a velocidade rende por tipo de site
O impacto da velocidade não é igual em todo lugar. Ele depende de quanto tráfego a página recebe, de quão impaciente é a pessoa naquele momento e de quanto vale cada visitante perdido. Um site institucional de uma empresa que vende por indicação sofre menos do que uma loja virtual que compra tráfego todo dia.
| Tipo de site | Sensibilidade à velocidade | Onde a perda aparece | Prioridade de investimento |
|---|---|---|---|
| Loja virtual | Muito alta | Abandono no catálogo e no checkout, custo por venda maior | Máxima, afeta receita diretamente |
| Página de destino de campanha paga | Muito alta | Você paga o clique e perde antes da oferta aparecer | Máxima, cada segundo é dinheiro comprado |
| Site de serviço local | Alta | Visitante volta para a busca e clica no concorrente | Alta, especialmente em serviço de urgência |
| Blog e conteúdo | Média a alta | Menos páginas lidas por visita e menos retorno | Média, mas afeta o SEO no longo prazo |
| Site institucional de marca conhecida | Média | Percepção de marca e desistência menor | Média, o visitante já veio decidido |
| Portal com muito conteúdo | Alta | Custo de rastreamento pelo Google e abandono | Alta, o volume amplifica qualquer perda |
| Sistema ou área do cliente | Alta no INP | Frustração de uso e chamados no suporte | Alta, aqui o INP importa mais que o LCP |
O caso da página de campanha paga merece destaque, porque é onde a matemática fica mais brutal. Ali você comprou cada visitante, um por um, e a lentidão significa jogar fora exatamente aquilo que você acabou de pagar. Para quem investe em anúncios, otimizar a página de chegada costuma render mais que qualquer ajuste de segmentação, e é uma melhoria que se paga uma vez e rende para sempre. Se você opera loja virtual, vale cruzar isso com o que escrevemos na página de criação de loja virtual.
Plano de ação em ordem de prioridade
A tentação de quem descobre o assunto é fazer tudo ao mesmo tempo, e isso costuma dar errado por dois motivos. Primeiro, porque você perde a capacidade de saber o que funcionou. Segundo, porque a maior parte do ganho vem de poucas ações, e as demais consomem tempo desproporcional. A sequência abaixo é a que aplicamos em auditoria, e ela respeita a ordem de impacto por esforço.
- ✓Semana 1: medir e registrar. Anote LCP, INP e CLS de três páginas importantes, no celular.
- ✓Semana 1: inventariar scripts de terceiros e marcar quem usa cada um dentro da empresa.
- ✓Semana 1: comprimir e redimensionar as imagens das páginas mais visitadas, começando pela imagem do topo.
- ✓Semana 2: remover todos os scripts sem dono e adiar o carregamento dos que sobraram.
- ✓Semana 2: ativar cache de página no servidor e cache de navegador para arquivos estáticos.
- ✓Semana 2: declarar dimensões de imagem e reservar espaço para banners e avisos, para zerar os saltos de layout.
- ✓Semana 3: ajustar o carregamento de fontes e reduzir a quantidade de pesos e famílias.
- ✓Semana 3: substituir vídeos incorporados por capa com carregamento sob clique.
- ✓Semana 4: medir de novo nas mesmas páginas e comparar com o registro inicial.
- ✓Semana 4: só então avaliar hospedagem, CDN ou mudança de plataforma, com dados na mão.
Repare que a avaliação de hospedagem e de plataforma, que costuma ser a primeira coisa que alguém sugere, fica por último de propósito. São as decisões mais caras e mais arriscadas, e tomá-las antes de esgotar as intervenções baratas leva muita empresa a gastar milhares de reais para resolver um problema que se corrigia comprimindo trinta fotos.
Árvore de decisão: o que fazer no seu caso
Cinco mitos sobre velocidade que atrapalham decisões
Mito 1: nota 100 é a meta
Já tratamos disso, mas vale repetir porque é o mito mais caro. Os últimos pontos da nota custam desproporcionalmente e frequentemente exigem remover recursos úteis ao negócio. Passar nas três métricas com dados reais é o objetivo, e isso costuma acontecer bem antes da nota 100.
Mito 2: site rápido significa site feio
Essa crença vem de projetos em que a otimização foi feita cortando elementos visuais em vez de construir melhor. Um site pode ser visualmente rico e rápido ao mesmo tempo, desde que as imagens estejam no formato e no tamanho certos e que os efeitos não dependam de bibliotecas pesadas. O que costuma não caber é a combinação de vídeo de fundo em alta resolução com animações elaboradas e cinco ferramentas externas.
Mito 3: velocidade só importa para quem vende online
Serviços locais de urgência são justamente onde a impaciência é maior. Quem procura um chaveiro, um encanador, um pronto atendimento ou um guincho não espera. Nesses setores, ser o site que abre primeiro vale mais do que ser o site mais bonito, e frequentemente mais do que estar uma posição acima no resultado de busca.
Mito 4: basta ativar um plugin de otimização
Plugins de cache e otimização ajudam de verdade, principalmente na parte de cache. Só que eles não conseguem redimensionar decisões de construção, não removem scripts que você instalou e não corrigem um tema mal feito. Vários deles, aliás, oferecem opções agressivas que quebram o layout quando ativadas sem critério, e o resultado é um site rápido e defeituoso.
Mito 5: já otimizei uma vez, está resolvido
Velocidade é uma condição, não uma tarefa concluída. Sites engordam sozinhos: uma foto nova aqui, um pixel de campanha ali, um plugin instalado para resolver um problema pontual e nunca removido. Sem uma medição periódica, seis meses depois o site voltou ao ponto de partida. É por isso que tratamos desempenho dentro da manutenção mensal, e não como um serviço avulso vendido uma vez.
Perguntas frequentes
A referência prática que o próprio Google usa nos Core Web Vitals é que o maior elemento visível da tela apareça em até 2,5 segundos para a maioria dos visitantes, medido em celular e em conexão real. Entre 2,5 e 4 segundos o site entra na zona de melhoria, e acima de 4 segundos ele é classificado como ruim. Na prática, para negócios brasileiros, gostamos de trabalhar com uma meta um pouco mais dura: até 2 segundos no celular, porque isso deixa margem para o visitante que está numa conexão pior que a média. Vale reforçar que esse número não é sobre o site ficar totalmente pronto, e sim sobre o visitante ver conteúdo útil rápido. Um site que mostra o título, a foto principal e o botão de contato em 1,8 segundo e continua carregando detalhes em segundo plano é percebido como rápido, mesmo que o carregamento completo leve mais tempo.
Resumo
Velocidade do site não é um assunto de programador, é um assunto de receita. Ela funciona como um filtro na entrada do seu negócio digital, definindo quantas das pessoas que você atraiu, muitas vezes pagando por cada uma delas, chegam a ver a sua oferta. Por isso ela multiplica ou reduz o retorno de tudo o que você faz em marketing, ao mesmo tempo e sem fazer barulho.
As três medidas que importam respondem a perguntas humanas. O LCP pergunta se o conteúdo principal apareceu rápido, com meta de até 2,5 segundos no celular. O INP pergunta se a página reage quando a pessoa toca, com meta de até 200 milissegundos. O CLS pergunta se o conteúdo fica parado enquanto a pessoa lê. No Brasil, essas três perguntas pesam mais que na média mundial, porque o tráfego é dominado pelo celular, a conexão varia muito e boa parte dos aparelhos em uso é mais modesta do que os relatórios sugerem.
A conclusão prática mais útil deste guia é também a mais simples. Na maior parte dos sites de empresas brasileiras, imagens sem compressão e scripts de terceiros em excesso explicam juntos a maior fatia do problema, e ambos são baratos de resolver. Antes de trocar de hospedagem, antes de refazer o site e muito antes de aumentar a verba de anúncio, faça o básico: redimensione as fotos, converta para formato moderno, remova os scripts sem dono e ative cache. Meça antes e meça depois, sempre no celular, para saber o tamanho do que você ganhou.