Otimizar a velocidade de um site: ordem de trabalho prática
O trabalho de velocidade tem uma forma muito desigual: um punhado de intervenções explica a maior parte da melhoria na maioria dos sites, e são quase sempre imagens, resposta do servidor e scripts de terceiros.
Este guia cobre a ordem de trabalho, como medir se uma alteração ajudou, e as otimizações que normalmente não compensam.
Medir antes de mexer#
Otimizar sem medir significa corrigir o que é mais fácil em vez do que é lento. Duas medições, depois trabalho.
- Obtenha dados de campo de visitantes reais — o relatório de Core Web Vitals ou a sua própria monitorização.
- Corra um teste de laboratório nos três modelos principais, limitado a um telemóvel médio em 4G.
- Registe os números antes de começar. Sem linha de base não consegue dizer se algo ajudou.
- Identifique, por modelo, o maior ficheiro individual e o maior pedido bloqueante.
- Anote o Time to First Byte à parte: acima de 800 ms, nenhum trabalho de front-end o salva.
A ordem que compensa#
Aproximadamente por melhoria obtida por hora de esforço, num site institucional ou de conteúdo típico.
| Trabalho | Ganho típico | Esforço |
|---|---|---|
| Otimizar e dimensionar imagens | Grande | Baixo |
| Remover scripts de terceiros não usados | Grande | Baixo — sobretudo político |
| Ativar cache e CDN | Grande | Baixo |
| Resolver CSS e JS bloqueantes | Médio a grande | Médio |
| Reduzir o pacote de JavaScript | Médio a grande | Médio a alto |
| Corrigir consultas lentas à base de dados | Grande onde aplicável | Médio |
| Otimizar carregamento de tipos de letra | Médio | Baixo |
| Minificar e comprimir texto | Pequeno | Baixo — normalmente já ativo |
| Micro-otimizar seletores CSS | Insignificante | Não compensa |
Imagens: normalmente o maior ganho#
Na maioria dos sites, as imagens são a maior parte do peso da página, e a maioria é servida várias vezes maior do que é apresentada. É a melhoria grande mais barata que existe.
- Sirva WebP ou AVIF; ambos têm suporte amplo e são tipicamente 25 a 50 % menores do que JPEG com qualidade equivalente.
- Gere vários tamanhos e use srcset com sizes para que os telemóveis descarreguem ficheiros de telemóvel.
- Nunca sirva uma imagem de 2000 px numa caixa de 400 px — este erro isolado é extraordinariamente comum.
- Carregue de forma diferida tudo o que está abaixo da dobra, e nada acima dela.
- Automatize na construção ou no CMS. Imagens otimizadas à mão deixam de o estar assim que outra pessoa carregar uma.
- Remova metadados; o EXIF da câmara pode representar dezenas de kilobytes por ficheiro.
A automatização é o essencial. Uma ronda pontual de otimização perde validade em meses à medida que entra conteúdo novo, e ninguém repara até o peso ter duplicado.
Scripts de terceiros e servidor#
As duas áreas onde o problema costuma ser organizacional em vez de técnico: ninguém é dono do gestor de etiquetas, e ninguém é dono da escolha de alojamento.
| Problema | O que fazer |
|---|---|
| Gestor de etiquetas com etiquetas desconhecidas | Auditar cada uma; remover o que ninguém justifica |
| Widget de chat em todas as páginas | Carregar por interação, ou só onde é preciso apoio |
| Várias ferramentas de análise | Manter uma; cada uma é um script e uma ligação |
| Script de testes A/B a bloquear a renderização | Mover para o servidor, ou aceitar um flash e carregar async |
| TTFB lento em alojamento partilhado | Cache de página completa; subir de plano se persistir |
| Consultas sem cache | Colocar em cache as caras; criar índices para as frequentes |
| Sem CDN | Acrescentar um — a correção de latência global mais barata |
Os scripts de terceiros são a fonte mais fiável de lentidão inexplicada, porque mudam sem avisar e ficam fora do seu processo de publicação.
Perguntas frequentes
O que é um bom tempo de carregamento?
Os objetivos úteis são os limiares dos Core Web Vitals em vez de um número único: LCP abaixo de 2,5 segundos e Time to First Byte abaixo de 800 ms. O tempo total de carregamento é má medida, porque uma página pode ser utilizável muito antes de todos os ficheiros terminarem — e, num aparelho lento, inutilizável muito antes disso.
Um site mais rápido aumenta a conversão?
Normalmente sim, e o efeito é maior onde as páginas estão lentas e os visitantes usam redes móveis. O ganho de três segundos para dois é muito superior ao de um e meio para um. Se o site já é rápido, invista o esforço em conteúdo e clareza — o retorno é melhor.
As extensões de cache resolvem tudo?
Resolvem bem uma coisa real — trabalho repetido do servidor para a mesma página — e podem criar problemas novos, sobretudo com utilizadores autenticados, carrinhos e formulários. Também não fazem nada quanto a imagens demasiado grandes ou scripts de terceiros, que costumam ser os problemas maiores. Úteis, não suficientes.
Renderizar no servidor compensa em velocidade?
Se as suas páginas são hoje renderizadas apenas no navegador, sim: renderizar no servidor ou gerar estaticamente elimina uma ida e volta inteira antes de o conteúdo aparecer, e ajuda a indexação ao mesmo tempo. Se as páginas já são HTML gerado no servidor, a questão não se coloca — já tem a vantagem.
otimizar velocidade sitevelocidade páginadesempenho websiteotimização imagenscachecdn
