Este é o último artigo de uma série de dez, e ele consolida o que apareceu espalhado nos anteriores.
Não é uma lista genérica copiada de documentação. Cada item aqui saiu de um problema real que eu tive na loja ou em projeto de cliente, e vem com a justificativa de por que está na lista. Checklist sem justificativa vira ritual — a pessoa marca a caixa sem entender e desfaz na semana seguinte.
São 32 itens em cinco áreas, na ordem em que eu executaria.
A resposta curta
Se você só tiver tempo para cinco coisas, faça estas:
- Remova toda requisição a terceiro que não seja essencial
- Hospede a fonte no seu domínio, em
.woff2, comfont-display: swap - Declare largura e altura em toda imagem
- Meça em Slow 4G com cache desativado, sempre nas mesmas condições
- Estabeleça um teto de milissegundos para scripts de terceiros e respeite
Essas cinco resolvem a maior parte dos casos. O resto do artigo é o detalhamento.
Área 1 — Fontes
A área que mais rende ganho por esforço, e a mais negligenciada.
☐ Nenhuma requisição a fonts.googleapis.com
São duas origens externas e uma cadeia de três requisições antes do texto aparecer. O argumento do cache compartilhado morreu em 2020, quando os navegadores passaram a particionar cache por site. Detalhei o mecanismo completo em Google Fonts está destruindo o LCP da sua loja.
☐ Nenhum preconnect ou dns-prefetch para domínios de fonte externa
Se você removeu a fonte, essas linhas ficaram órfãs e continuam abrindo conexão à toa.
☐ Fonte servida do mesmo domínio do site
Elimina consulta DNS, handshake e negociação TLS de duas origens.
☐ Formato .woff2 apenas
Suporte universal em navegadores modernos e a melhor compressão. Gerar woff, ttf e eot só engorda o repositório.
☐ Subconjunto latin e latin-ext
Corta de 60% a 80% do arquivo ao remover alfabetos que o seu site nunca vai usar.
☐ Somente os pesos realmente usados
A maioria dos sites carrega cinco pesos e usa dois. Cada peso é um arquivo competindo por banda com a imagem do LCP.
☐ font-weight correto em cada bloco @font-face
Se dois arquivos declaram o mesmo peso, o navegador ignora um e sintetiza o negrito — que fica mais largo e mais feio que o real.
☐ font-display definido
Sem ele, o navegador esconde o texto por até três segundos esperando a fonte.
☐ preload só na fonte acima da dobra
Precarregar tudo compete com a imagem do LCP e atrasa justamente o que você quer acelerar.
☐ crossorigin presente na tag de preload
Sem esse atributo, mesmo na própria origem, o navegador baixa a fonte duas vezes.
Área 2 — Imagens
☐ width e height declarados em toda imagem
É o que reserva o espaço antes do carregamento e evita deslocamento de layout. Custa dois atributos e resolve a maior causa de CLS ruim.
☐ aspect-ratio reservado em blocos que carregam depois
Vale para carrossel, banner e qualquer área preenchida por JavaScript.
☐ loading="lazy" abaixo da dobra
E nunca na imagem do LCP — carregar a imagem principal preguiçosamente atrasa exatamente a métrica que você quer melhorar.
☐ decoding="async" em imagens não críticas
Libera a thread principal enquanto a imagem é decodificada.
☐ Formato moderno com alternativa
WebP ou AVIF com fallback, servidos conforme suporte do navegador.
☐ Dimensão real compatível com a exibida
Servir imagem de 3000px num espaço de 400px desperdiça banda proporcionalmente.
☐ Imagem do LCP precarregada quando for estática
Se você sabe qual é a imagem principal, avise o navegador cedo.
Área 3 — Scripts e terceiros
☐ Inventário de todos os domínios externos
Ordene a aba Network por Domain. Tudo que não é o seu domínio entra na conta.
☐ Custo de cada terceiro medido isoladamente
Bloqueie o domínio no DevTools, recarregue e compare o LCP. A diferença é o preço daquele serviço. O método completo está em O custo real, em milissegundos, de cada app instalado.
☐ Coluna Initiator conferida
Revela quem pediu cada recurso, incluindo apps carregando outros apps e resíduo de app já desinstalado.
☐ Teto de milissegundos definido para terceiros
Transforma "será que esse app é pesado?" em conta objetiva. App novo só entra se couber no orçamento, ou se outro sair.
☐ Nenhum script de terceiro bloqueando renderização
Se precisa existir, que seja async ou defer.
☐ Resíduo de app desinstalado removido do tema
Desinstalar do painel frequentemente não limpa o código injetado.
☐ Auditoria repetida a cada três meses
Apps se atualizam sozinhos e ganham peso sem aviso.
Área 4 — CSS e JavaScript próprios
☐ Nenhum @import no CSS
Cria cadeia sequencial: o navegador precisa baixar e interpretar o primeiro arquivo para descobrir o segundo.
☐ CSS crítico embutido, resto adiado
O que pinta a primeira tela vai inline; o resto carrega sem bloquear.
☐ JavaScript sem vazamento para escopo global
Envolva em IIFE ou módulo. Além de higiene, evita colisão com nomes reservados do navegador — um const top no escopo global, por exemplo, colide com window.top e derruba o script inteiro antes de executar.
☐ Nenhum framework carregado para pouca coisa
Biblioteca de 40 KB para animar três elementos é troca ruim.
☐ Especificidade de seletor sob controle
Regras que se anulam viram CSS morto que continua sendo baixado e interpretado.
☐ Nenhum console.log em produção
Não pesa muito, mas denuncia falta de revisão final.
Área 5 — Medição
☐ Sempre em Slow 4G, com cache desativado
Sem throttling você mede a sua internet, não a do cliente.
☐ Três medições, usando a mediana
Uma medição isolada varia demais por condição de rede.
☐ Mesmas condições antes e depois
Comparar medição com throttling contra medição sem prova nada.
☐ CLS verificado junto com LCP
Otimizações de fonte que melhoram LCP podem piorar CLS por causa da troca de tipografia.
☐ Medição em dispositivo real, não só emulado
Celular médio brasileiro processa JavaScript bem mais devagar que o seu computador emulando um celular.
A ordem que eu seguiria
Com o checklist completo em mãos, a sequência que dá resultado mais rápido:
Primeiro, terceiros. É onde estão os maiores ganhos isolados e as vitórias gratuitas — resíduo de app desinstalado e ferramenta que ninguém usa. Foi assim que recuperei 1.900 milissegundos de uma vez só.
Depois, fontes. Segundo maior ganho por esforço, e a correção leva menos de uma hora.
Então, imagens. Muito trabalho braçal, ganho consistente, e resolve CLS de quebra.
Por último, CSS e JavaScript próprios. Importante, mas costuma render menos que os três anteriores. Otimizar seu código enquanto três scripts de terceiro consomem dois segundos é enxugar gelo.
Medindo em todas as etapas. Sem medir antes e depois, você não sabe se melhorou — e vai acabar mantendo mudanças que não fizeram diferença.
O que fica de fora deste checklist
Sendo honesto sobre limites: esta lista cobre o que está no seu controle no front-end. Existem fatores relevantes fora dela.
Tempo de resposta do servidor. Se o servidor demora 800 ms para devolver o HTML, nenhuma otimização de front-end compensa. Isso é assunto de hospedagem, e a escolha entra em outro terreno — que tratei em Como escolher hospedagem lendo o contrato.
Consulta lenta no banco. Página que espera uma consulta pesada tem problema de back-end, não de tema.
Volume de dados da página. Listagem com 200 produtos por página é problema de arquitetura de informação, não de otimização.
Se você marcou todos os 32 itens e o site continua lento, o gargalo está em uma dessas três — e vale medir o tempo até o primeiro byte antes de continuar mexendo no front-end.
Perguntas frequentes
Por onde começar se o site está muito lento?
Pelos scripts de terceiros. É onde costumam estar os maiores ganhos isolados e as correções mais baratas, incluindo apps que ninguém usa e resíduo de app desinstalado. Meça o custo de cada domínio externo bloqueando um de cada vez.
Qual LCP é considerado bom?
Abaixo de 2,5 segundos é a faixa boa segundo o Google. Entre 2,5 e 4 segundos precisa melhorar, e acima de 4 segundos é ruim. Meça sempre na versão móvel com throttling, que é a condição em que a maioria dos visitantes brasileiros acessa.
Preciso de plugin de otimização?
Na maioria dos casos, não. Plugin de cache costuma conflitar com o cache do próprio host, e plugin de otimização de imagem faz o que atributos HTML e um bom processo de publicação resolvem. Cada plugin também é código adicional carregado. Prefira resolver no tema.
Com que frequência devo rodar essa auditoria?
A cada três meses para o checklist completo, e sempre que instalar qualquer coisa nova. Apps se atualizam sozinhos e podem ganhar peso sem aviso, então uma auditoria válida em janeiro pode não valer mais em maio.
Otimizar performance melhora o posicionamento no Google?
Melhora, mas indiretamente e menos do que se costuma prometer. Core Web Vitals é um fator entre muitos, e conteúdo relevante pesa mais. O ganho maior de performance é em conversão: página lenta perde visitante antes dele ver a oferta.
Vale a pena reescrever um tema pronto ou é melhor construir do zero?
Depende de quantos itens deste checklist o tema pronto viola. Se ele carrega três fontes externas, quatro bibliotecas e um construtor visual, reescrever costuma sair mais barato que corrigir. Se ele é razoavelmente enxuto e o problema está em apps instalados por cima, corrigir resolve.
Resumindo
Site rápido não é resultado de uma otimização genial. É resultado de trinta decisões pequenas, tomadas na ordem certa e verificadas com medição.
A ordem que rende mais: terceiros primeiro, fontes depois, imagens em seguida, código próprio por último. E medição em todas as etapas, sempre nas mesmas condições, porque sem comparação você não sabe o que funcionou.
Se depois de tudo isso o site continuar lento, o gargalo mudou de lugar — provavelmente para o servidor. E aí a conversa passa a ser sobre onde o site está hospedado, não sobre como o tema foi escrito.
Continue lendo em Performance: