O essencial
- Os dados de campo valem mais do que a pontuação de laboratório. Um teste perfeito não significa nada se os utilizadores reais estão a ter uma experiência lenta.
- Corrija primeiro o LCP — é a métrica que falha na maioria dos sites e costuma ter uma causa identificável.
- A velocidade é um limiar, não uma corrida. Depois de estar na faixa boa, mais otimização compra conversão, não posições.
- A maior parte dos sites perde desempenho em imagens e scripts de terceiros — e ambos se corrigem sem reconstruir nada.
O trabalho de desempenho atrai um desperdício muito particular: semanas a subir uma pontuação de 78 para 94 numa página que ninguém visita, enquanto a página de categoria que gera receita demora seis segundos a ficar utilizável num telemóvel. A pontuação subiu, o negócio não deu por nada, e toda a gente concluiu que a velocidade não interessa.
Este artigo trata de fazer trabalho de desempenho que compensa, usando a plataforma Semalt para ver que templates são de facto lentos para utilizadores reais: como ler os dois tipos de dados, que métrica corrigir primeiro e como saber quando parar.
Laboratório e campo: a distinção que decide tudo
Existem dois tipos de medição e respondem a perguntas diferentes. Confundi-los é a origem da maioria das más decisões nesta área.
| Dados de laboratório | Dados de campo | |
|---|---|---|
| O que são | Um carregamento simulado, em condições controladas | Utilizadores reais, ao longo de um período |
| Bons para | Depurar e comparar antes e depois de uma alteração | Saber se existe sequer um problema |
| Fraqueza | Nada parecido com uma sessão real: sem carrinho, sem sessão, cache fria ou quente por acaso | Movem-se devagar; dizem o quê, não o porquê |
| Quando discordam | Ganha o campo. É a população que gera receita. | |
A consequência prática: use os dados de campo para decidir se e onde agir, e os de laboratório para diagnosticar e verificar a correção. Quem trabalha ao contrário otimiza páginas que ninguém visita, em condições que ninguém experimenta.
Parâmetros de trabalho da abordagem descrita a seguir.
Que métrica corrigir primeiro
Três métricas interessam — e não têm a mesma probabilidade de ser o seu problema.
- Largest Contentful Paint — comece aqui
Quanto tempo até o conteúdo principal estar visível. Falha na maioria dos sites e costuma ter uma causa dominante: uma imagem de destaque não otimizada, um tipo de letra ou folha de estilos que bloqueia a renderização, ou uma resposta lenta do servidor em páginas sem cache. Identifique qual das três e identificou a correção.
- Cumulative Layout Shift — segundo, e normalmente fácil
Conteúdo a saltar enquanto a página carrega. Quase sempre espaços de publicidade, incorporações ou imagens sem dimensões declaradas. A correção é reservar o espaço em CSS — barata e raramente polémica.
- Resposta à interação — por último, e a mais difícil
Quão depressa a página responde a um toque ou clique. Significa JavaScript, o que significa uma conversa de engenharia sobre o que está a correr e se precisa mesmo. Deixe para depois de resolver as duas primeiras.
Agrupe por template, não por URL. A afirmação útil nunca é "o site está lento". É "o template de categoria tem um problema de LCP em telemóvel". Ordenar os resultados do crawl por template transforma uma lista de milhares de URL lentos em três ou quatro problemas reais, cada um com um único sítio onde se corrige.
Imagens: a maior causa isolada
Na maioria dos sites que auditamos, as imagens explicam mais do problema do que tudo o resto somado — e as correções são bem conhecidas e aborrecidas.
O que fazer
- Servir formatos modernos — WebP ou AVIF — com alternativa
- Dimensionar as imagens ao tamanho de exibição, não ao do upload
- Definir largura e altura explícitas para nada saltar
- Carregamento diferido abaixo da dobra, nunca no destaque
O que causa o problema
- Uma fotografia de 4000px exibida a 600px
- Quarenta miniaturas em resolução total numa grelha de categoria
- Diferir a imagem de destaque, o que atrasa diretamente o LCP
- Imagens de fundo em CSS, que o browser descobre tarde
O terceiro ponto da direita é um autogolo clássico. O carregamento diferido é aplicado a todas as imagens sem distinção, incluindo a do topo da página — precisamente o elemento pelo qual a medição de LCP está à espera. O resultado é um site que pontua pior depois de uma ronda de otimização do que antes.
Scripts de terceiros
A segunda grande causa, e a que exige uma conversa de negócio e não técnica. Cada ferramenta de analítica, widget de chat, incorporação de avaliações, mapa de calor, banner de consentimento e etiqueta de remarketing acrescenta peso — e cada um foi acrescentado por alguém que, com razão, o achou inofensivo.
O exercício que funciona é um inventário anual: listar todos os scripts de terceiros, nomear a pessoa que os quer, e perguntar o que se partiria se fossem removidos. Na nossa experiência, um terço da lista não tem dono atual — e remover esses itens produz uma melhoria mensurável sem contrapartida nenhuma.
Para o que fica, a estratégia de carregamento conta. Nada que não seja necessário à renderização inicial deve bloqueá-la — diferir, carregar na interação, ou carregar depois do conteúdo principal. Um widget de chat que aparece dois segundos depois não perde nada; um widget de chat que atrasa a página prejudica todos os visitantes.
Antes do browser: resposta do servidor e cache
A otimização do front-end leva as atenções, mas uma parte substancial dos sites lentos já é lenta antes de um único byte de HTML chegar ao browser. Se o servidor demora quase um segundo a começar a responder, tudo o que vem a seguir herda esse atraso — e nenhum trabalho de imagens o recupera.
Três causas explicam quase tudo nos sites que vemos. Páginas dinâmicas sem cache, em que cada visita reconstrói o mesmo resultado a partir da base de dados — a correção é cache de página e, num site de conteúdo, é praticamente gratuita. Consultas à base de dados que cresceram com o site, sobretudo em páginas de categoria e listagem, onde uma consulta inocente fica cara com dez mil registos. E alojamento partilhado simplesmente sobrelotado, que não é um problema técnico mas de compra.
Há um guia completo sobre o tema em Ligações internas.
O diagnóstico é rápido. Meça o tempo até ao primeiro byte numa página que de certeza não está em cache, e depois numa que devia estar. Se as duas forem lentas, olhe para o alojamento. Se só a sem cache for lenta, olhe para a cache e para as consultas. Se as duas forem rápidas e os utilizadores continuarem a queixar-se, o problema está no browser e aplicam-se as secções anteriores.
Um aviso sobre plugins de cache: criam frequentemente os seus próprios problemas, sobretudo com ficheiros combinados e minificados que partem o layout de forma intermitente ou servem conteúdo desatualizado depois de uma atualização. Quando um site desenvolve bugs visuais misteriosos que aparecem a uns visitantes e a outros não, a camada de cache é o primeiro sítio a verificar, não o último.
Mais uma coisa que vale a pena verificar já que está aí: se o mesmo template se comporta de forma diferente para visitantes autenticados e anónimos. Em sites com contas, a cache aplica-se muitas vezes só ao tráfego anónimo — o que significa que a experiência que a sua equipa vê com sessão iniciada não tem relação nenhuma com a que os motores de busca e os visitantes de primeira vez recebem. É uma razão comum para uma equipa insistir que o site é rápido enquanto os dados de campo discordam.
Ver também: Dados estruturados na prática.
A velocidade é um limiar, não uma competição
É aqui que se desperdiça a maior parte dos orçamentos de desempenho. Ser mais rápido do que o limiar bom não o coloca acima de um concorrente que também está acima dele — a métrica deixa de diferenciar assim que se passa.
O que continua a melhorar para lá desse ponto é a conversão, o que é uma razão legítima para continuar mas com outra justificação e outro responsável. Seja explícito sobre qual está a defender. "Isto vai melhorar as posições" deixa de ser verdade assim que está na faixa boa; "isto vai melhorar a finalização de compras" pode continuar a ser verdade e é mensurável.
Cuidado com otimizar a página errada. A página inicial é a mais testada e a menos representativa da maioria dos sites. Teste os templates que recebem tráfego de pesquisa e geram receita — normalmente uma página de categoria ou de serviço, e em telemóvel, porque é aí que se concentram o tráfego e os problemas.
Analisamos isto em detalhe em Imagens e vídeo.
Medir o efeito com honestidade
O trabalho de desempenho tem uma propriedade incómoda: demora semanas a aparecer nos dados de campo, e nessa altura já mudaram outras coisas. Dois hábitos mantêm a atribuição limpa.
Lance as alterações de desempenho como um lote distinto, separado de lançamentos de conteúdo ou de design, com a data registada. Se o trabalho de velocidade, um redesign e uma atualização de conteúdo caírem na mesma quinzena, ninguém consegue dizer o que causou o quê.
E registe a medição de laboratório imediatamente antes e depois, nos mesmos templates, como prova de que a alteração fez o que devia. Os dados de campo confirmam quatro semanas depois; a medição de laboratório é o que lhe diz, entretanto, que o deploy funcionou mesmo.
Uma nota sobre a realidade local
Duas observações específicas de sites que servem Portugal. A qualidade da ligação móvel varia bastante fora dos principais corredores urbanos, o que significa que testar numa ligação rápida no centro de Lisboa subestima sistematicamente o problema para uma fatia relevante do público. Quando os dados de campo mostram uma diferença grande entre a mediana e os percentis mais lentos, essa diferença costuma ser geografia e não equipamento.
A segunda é sobre alojamento. Muitos sites de empresas portuguesas correm em alojamento partilhado com resposta lenta do servidor, e nenhuma otimização de front-end compensa um servidor que demora 800 milissegundos a começar a responder. Verifique primeiro o tempo de resposta do servidor: se for mau, a melhoria de desempenho mais barata disponível é muitas vezes mudar de alojamento e não otimizar seja o que for.
Uma sequência realista
Veja os dados de campo por template e identifique quais estão realmente a falhar para utilizadores reais. Corrija a causa do LCP no pior template comercial — normalmente imagens ou um recurso que bloqueia a renderização. Reserve espaço para tudo o que salta. Depois faça o inventário dos scripts de terceiros e remova o que não tem dono.
Essa sequência resolve a maior parte dos problemas reais de desempenho e raramente exige reconstruir nada. O que exige é escolher as páginas por receita e não por qual é mais fácil de testar.
Se nunca separou os dados de desempenho por template, é esse o primeiro passo útil. Abra o painel, corra um crawl e veja que grupo de templates carrega os piores números em telemóvel.
Perguntas frequentes
As Core Web Vitals afetam as posições?
São um fator, mas de limiar e não de competição. Estar na faixa boa conta; ser duas vezes mais rápido do que outro site que já está na faixa boa não o coloca acima dele. A relevância e a qualidade do conteúdo pesam confortavelmente mais. Para lá do limiar, mais trabalho deve justificar-se pela conversão e não pelas posições.
A minha pontuação é 95 mas o site parece lento. Porquê?
Porque o teste correu em condições que nenhum visitante real tem: sem sessão, sem carrinho, sem banner de consentimento, sem scripts de terceiros a disparar, numa ligação rápida. Os dados de campo refletem o que os utilizadores reais viveram ao longo de um período, incluindo quem estava num equipamento antigo na sua hora de maior tráfego. Quando laboratório e campo discordam, é o campo que descreve os seus clientes.
Que métrica devemos corrigir primeiro?
O LCP, em quase todos os casos. É a métrica que mais falha e costuma ter uma causa única e identificável: uma imagem de destaque não otimizada, um tipo de letra ou folha de estilos que bloqueia a renderização, ou uma resposta lenta do servidor. O deslocamento de layout vem a seguir e é normalmente barato de corrigir. A resposta à interação vem por último, porque implica trabalho de JavaScript.
Devemos diferir o carregamento de todas as imagens?
Tudo o que está abaixo da dobra, sim. A imagem de destaque, nunca — diferir o elemento que o LCP está a medir atrasa exatamente aquilo que está a ser medido, e há sites que pontuam pior depois de aplicarem carregamento diferido sem distinção. Combine com dimensionamento correto, formatos modernos e dimensões explícitas, que juntos fazem mais do que o carregamento diferido sozinho.
Abra o painel do Semalt
Auditoria, posições, dados da concorrência e relatórios num só lugar. Entre e veja números reais do seu domínio em poucos minutos.
Entrar no SemaltOu veja primeiro a visão geral dos serviços em semalt.com.
