Page speed com orçamento curto: as otimizações mais importantes
Aprenda a melhorar os Core Web Vitals com estratégias de baixo custo
As otimizações mais importantes
Como consultor de Core Web Vitals, recebo todo tipo de pedido de suporte em pagespeed. E sim, às vezes o orçamento é curto. Nesses casos, preciso ser ainda mais eficiente com o tempo e focar apenas em otimizações de alto impacto e baixo esforço que realmente mexem nos Core Web Vitals.
Última revisão por Arjen Karel em março de 2026
Os números comprovam isso. Segundo o Web Almanac de 2025, apenas 48% das origens no celular passam nos três Core Web Vitals. A página mediana no celular pesa 2,6 MB, com 632 KB de JavaScript (sendo 251 KB não utilizados). São problemas que você resolve sem gastar muito.
Table of Contents!
- As otimizações mais importantes
- 1. Identifique os problemas primeiro
- 2. Otimize as imagens
- 3. Corrija o cache do navegador
- 4. Considere a Cloudflare (até o plano gratuito ajuda)
- 5. Hospede o máximo possível no próprio servidor
- 6. Adie os scripts
- 7. Otimize as fontes
- 8. Cache, cache, cache
- 9. Escolha a hospedagem de forma estratégica
- 10. Monitore a performance
DICA de Core Web Vitals: A minha Consultoria On-Call é o jeito mais econômico de conseguir ajuda especializada. Agende uma sessão de 2 horas (€300): eu diagnostico os problemas de Core Web Vitals, corrijo o que for mais urgente e defino uma estratégia clara para o restante. Eu me preparo antes da chamada para não perder tempo.
Agende uma sessão!
1. Identifique os problemas primeiro
Ao otimizar a performance web com pouco orçamento, precisamos ter certeza absoluta de que o trabalho é o mais eficaz possível. Isso significa descobrir qual é o problema real antes de qualquer coisa.
Dá para usar o excelente e gratuito PageSpeed Insights para consultar os dados do CrUX. Os dados do CrUX são a única fonte que importa, já que é essa fonte que o Google usa.


Abaixo da pontuação do CrUX, você verá a auditoria do Lighthouse.

Vou ser direto sobre a auditoria do Lighthouse: neste momento, não estamos nem aí para o Lighthouse. Por quê? Porque ele não mede os Core Web Vitals. Claro, o Lighthouse é uma ótima ferramenta de testes e você pode explorar todas as sugestões dele, mas com orçamento curto o objetivo é passar nos Core Web Vitals. Passar em testes sintéticos não interessa agora!
De volta aos dados do CrUX. Veja o roteiro a seguir se o orçamento for curto. Comece investigando os Core Web Vitals exatamente nesta ordem e foque nestes problemas primeiro:
- Se o Time to First Byte estiver reprovando, resolva isso primeiro!
- Se o First Contentful Paint estiver reprovando, corrija os recursos com render blocking (adicione defer nos scripts e otimize os estilos)
- Se o Largest Contentful Paint estiver reprovando, priorize os recursos necessários para o LCP (como fontes ou imagens)
- Se o CLS estiver reprovando, adicione width e height em todas as imagens, remova transições de CSS e reserve espaço para elementos que renderizam tarde (como anúncios, filtros de produtos etc.)
- Se o Interaction to Next Paint estiver reprovando, você provavelmente está executando JavaScript demais na hora errada. Remova scripts e plugins desnecessários e use uma ferramenta de RUM como o CoreDash para encontrar os scripts mais lentos
2. Otimize as imagens
As imagens representam 911 KB da página mediana no celular, segundo o Web Almanac de 2025. Isso é mais de um terço do peso total da página. Além disso, 57% das imagens de LCP ainda são entregues em JPG, quando o WebP seria menor com a mesma qualidade. Com orçamento curto, otimizar imagens traz o maior impacto com o menor esforço.
Converta imagens para WebP de graça
Existem muitas ferramentas, soluções e plugins gratuitos para converter imagens em formatos mais novos, rápidos e modernos, como o WebP. No WordPress, por exemplo, recomendo o excelente e gratuito WebP Express.
Implemente lazy loading
O lazy loading sinaliza ao navegador que uma imagem não deve ser carregada até estar perto da viewport visível. Se você tem 15 imagens em uma página e só 3 aparecem na parte visível da tela, pode adicionar loading="lazy" sem medo nas imagens fora da viewport.
Existem 2 formas de fazer isso. A primeira é ativar o lazy loading no CMS. Isso aplica o lazy loading em todas as imagens. Em seguida, consulte a documentação para saber como remover o lazy loading das imagens visíveis e importantes. A outra forma é adicionar loading="lazy" manualmente nas imagens abaixo da dobra. Para um guia completo, veja como adiar imagens fora da tela.
<img loading="lazy" src="image.jpg" width="800" height="600">
Defina o fetchpriority da imagem
Ao adicionar fetchpriority="high" à tag da imagem, avisamos ao navegador que essa imagem é mais importante que as outras e deve ser baixada primeiro. Embora existam opções melhores, como preload de imagens e 103 Early Hints, definir o fetchpriority é simples, rápido e eficiente! Basta identificar a imagem mais importante da página, editar o template e adicionar fetchpriority="high" na tag:
<img fetchpriority="high" src="image.jpg" width="800" height="600">
3. Corrija o cache do navegador
Se você usa uma hospedagem barata, é provável que o servidor web não esteja configurado da melhor forma. Um erro que encontro com frequência é o cache do navegador mal configurado. Sem os cabeçalhos de cache corretos, quem retorna ao site baixa as mesmas imagens, scripts e folhas de estilo repetidamente. Isso é desperdício de banda e de tempo.
Se você usa o Apache como servidor web, basta criar um arquivo chamado .htaccess no diretório raiz do site e adicionar estas linhas:
<FilesMatch "\.(ico|pdf|jpg|jpeg|png|webp|gif|css|js|woff|woff2)$">
<IfModule mod_headers.c>
Header set Cache-Control "max-age=172800, public, must-revalidate"
</IfModule>
</FilesMatch> Aproveite que está editando o arquivo .htaccess para ativar a compactação GZIP também. Ela compacta recursos em texto (HTML, CSS, JavaScript) antes do envio para o navegador. Na maioria dos sites, isso reduz o tamanho da transferência entre 60% e 80%.
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/css text/javascript AddOutputFilterByType DEFLATE application/javascript application/json </IfModule>
Se você usa outro servidor web, como o NGINX, entre em contato com a sua hospedagem e envie este artigo para eles!
4. Considere a Cloudflare (até o plano gratuito ajuda)
Mesmo no plano gratuito, a Cloudflare entrega muitos dos principais recursos de performance. Se a sua hospedagem é barata, migrar o DNS para a Cloudflare é uma das mudanças de maior impacto e menor esforço possíveis. Para ver o passo a passo detalhado, consulte o guia completo de configuração da Cloudflare.
No plano gratuito
- DNS rápido. Os servidores de DNS da Cloudflare são gratuitos e provavelmente superam os da sua hospedagem barata. Os dados do CrUX do Web Almanac de 2025 mostram que apenas 44% das origens no celular têm um bom TTFB. DNS lento é uma causa comum, e migrar para a Cloudflare resolve isso na hora.
- HTTP/3 e Brotli. A Cloudflare usa os protocolos mais recentes e os métodos de compactação mais rápidos. Sem rodeios: isso vai acelerar a rede em pelo menos 10%.
- Cache de navegador consistente. A Cloudflare tem um histórico excelente quando o assunto é cache de recursos estáticos. A configuração padrão provavelmente já é melhor do que a sua atual.
- Edge caching para recursos estáticos. A Cloudflare armazena versões dos seus recursos estáticos — como imagens, scripts e arquivos CSS — em cache e os entrega direto da rede de borda para o usuário final. Isso elimina requisições de ida e volta ao servidor de origem.
- Rocket Loader. O Rocket Loader adia o carregamento dos scripts e resolve as complicações decorrentes disso. É um método bruto, mas se você não puder adiar scripts manualmente, ele provavelmente vai melhorar métricas de renderização como o Largest Contentful Paint. Nota: o Rocket Loader usa APIs descontinuadas do navegador e o PageSpeed Insights pode acusar isso. Se vir esses avisos, prefira adiar os scripts manualmente.
No plano Pro
Uma das primeiras coisas que costumo dizer quando vejo o plano gratuito da Cloudflare é: "mude para o Pro!". Se você tem condições de pagar os US$ 25 e quer investir em um site mais rápido, considere o upgrade.
- Todos os recursos gratuitos. Obviamente, o plano Pro inclui todos os recursos do plano gratuito.
- Cloudflare APO para WordPress. O APO para WordPress é uma solução completa que armazena as páginas em cache na rede de borda para visitantes deslogados. Isso reduz o Time to First Byte de forma impressionante.
- Otimização de imagens com e sem perdas. Uma das grandes vantagens da versão Pro da Cloudflare é a otimização de imagens. A Cloudflare converte e guarda as imagens em WebP no cache, entregando-as apenas aos visitantes compatíveis com esses formatos.
5. Hospede o máximo possível no próprio servidor
Outra otimização simples e eficaz é hospedar recursos estáticos no próprio servidor. Em muitos sites, esses recursos ficam em CDNs externas. Por exemplo: o jQuery fica em https://code.jquery.com/, o Bootstrap em https://cdn.jsdelivr.net e as fontes em https://fonts.googleapis.com. Dá para entender o apelo. Essas CDNs parecem práticas e rápidas, mas usá-las é uma péssima ideia e só deixa o site mais lento.
A ideia de usar uma CDN compartilhada para esses arquivos fazia sentido quando os navegadores ainda podiam compartilhar esses arquivos entre sites diferentes. Esses dias ficaram para trás. O resultado é que cada novo visitante precisa baixar o arquivo estático do zero, abrindo uma nova conexão com um novo servidor para cada arquivo. E essas novas conexões custam um tempo precioso.
A solução é hospedar esses arquivos de terceiros no próprio servidor. Fazer isso é fácil: baixe o arquivo, coloque-o no seu servidor e altere a referência a ele no código. No caso específico das fontes, veja como hospedar o Google Fonts no próprio servidor.
6. Adie os scripts
Scripts bloqueantes no head da página podem ser um gargalo gigante. Às vezes, eles atrasam o carregamento da página em até 20 segundos! O Web Almanac de 2025 revelou que apenas 15% das páginas no celular passam na auditoria de recursos com render blocking. Isso mostra o quanto o problema é generalizado.
Adiar esses scripts não é nada difícil. Basta adicionar defer na tag script e pronto. Se puder, faça isso! Edite o template e altere o script assim:
<!-- tag antiga de script bloqueante --> <script src="script.js"></script> <!-- nova tag de script com defer --> <script defer src="script.js"></script>
Mas há pegadinhas! Adicionar defer em tags script pode gerar todo tipo de problema e erro de dependência. E como o orçamento é curto, suponho que você não tenha como contratar um especialista em JavaScript para resolver qualquer complicação que apareça. Então, teste o defer nos scripts e procure por erros (pressione Ctrl+Shift+I no Chrome e olhe a aba console). Se não houver problemas após os testes, considere-se uma exceção de sorte! Se houver falhas, recorra a uma das opções a seguir. Para um panorama completo, veja 16 métodos para adiar JavaScript.
Use o Rocket Loader
Como vimos, a versão gratuita da Cloudflare dá acesso ao Rocket Loader. Ele adia todos os scripts da página. Longe de ser perfeito, mas na maioria das vezes funciona muito bem.
Use um plugin
A maioria dos sites baseados em CMS conta com um vasto repositório de plugins. Existem várias opções disponíveis que adiam o JavaScript e cuidam de todas as complicações que podem surgir com o defer.
7. Otimize as fontes
As web fonts são um custo oculto de performance em sites com pouco orçamento. A página mediana carrega 122 KB em arquivos de fonte, segundo o Web Almanac de 2025. Se as fontes carregam do Google Fonts, você faz consultas de DNS e conexões TCP extras em cada primeira visita.
Duas correções gratuitas:
- Hospede as fontes no próprio servidor. Baixe os arquivos de fonte, coloque-os no seu servidor e carregue tudo de lá. Isso elimina o overhead de conexão com fonts.googleapis.com e fonts.gstatic.com.
- Adicione font-display: swap. Isso instrui o navegador a exibir o texto em uma fonte de fallback imediatamente enquanto a web font é baixada. Os visitantes veem o conteúdo mais rápido e você evita o problema do texto invisível. Para ver a estratégia completa, consulte como corrigir o texto invisível durante o carregamento de web fonts.
8. Cache, cache, cache
Quando o orçamento é curto e você não quer gastar muito com hospedagem, o cache é uma das formas mais eficientes de acelerar um site. Ele é especialmente eficaz contra um Time to First Byte alto. O cache pode ser aplicado em diferentes níveis.
Cache no cliente: Configure o servidor web para instruir os navegadores a guardar o máximo de recursos estáticos no cache. Isso diminui a carga no servidor. (Veja o exemplo do .htaccess na seção 3.)
Cache de objetos: O cache de objetos pode ser usado para armazenar dados caros de recalcular, como o resultado de consultas complexas ao banco de dados. Peça para a sua hospedagem instalar o Redis ou o Memcached.
Cache de página inteira: Se você usa um CMS, é recomendável adicionar cache de página inteira ao site. No WordPress, boas opções são o WP Fastest Cache ou o WP Core Web Vitals.
9. Escolha a hospedagem de forma estratégica
Quando o assunto é hospedagem, pesquisar vale a pena: o provedor mais caro nem sempre é o mais rápido. No geral, o ideal é procurar um plano otimizado para o seu CMS, porque quem tenta fazer de tudo não faz nada direito. Busque uma hospedagem que ofereça no mínimo PHP 8+, HTTP/2 e armazenamento em SSD. Uma boa hospedagem de WordPress com essa base supera qualquer compartilhada genérica com folga.
10. Monitore a performance
Todas essas otimizações não valem de nada se você não souber se elas realmente funcionaram. Configure o Real User Monitoring para ver como os visitantes reais vivenciam o site, e não apenas como o Lighthouse pontua com lab data. Pontuações de lab data são úteis para debugar, mas é o field data de visitantes reais que o Google usa para ranquear. O CoreDash acompanha os Core Web Vitals de usuários reais e diz exatamente em que ponto você está.
Seu score do Lighthouse não conta a história toda.
Seus usuários reais estão em Android com 4G. Analiso o que eles vivem de fato.
Analisar dados de campo