Page Speed com Orçamento Limitado: As Otimizações Que Mais Importam

As otimizações que mais importam

Como consultor de Core Web Vitals, recebo muitos pedidos diferentes de suporte para page speed. E sim, às vezes não há um grande orçamento. Se esse for o caso, preciso ser ainda mais eficiente com meu tempo e realizar apenas otimizações de alto ganho e baixo esforço que realmente melhorem os Core Web Vitals.

Última revisão por Arjen Karel em março de 2026

Os números falam por si. De acordo com o Web Almanac de 2025, apenas 48% das origens mobile passam em todos os três Core Web Vitals. A página mobile mediana pesa 2,6 MB, com 632 KB de JavaScript (dos quais 251 KB não são utilizados). Estes são problemas que você pode corrigir sem um grande orçamento.

Dica de Core Web Vitals: Minha Consultoria sob demanda é a maneira mais econômica de obter ajuda especializada. Marque uma sessão de 2 horas (€300) e eu diagnosticarei seus problemas de Core Web Vitals, corrigirei os problemas mais urgentes e darei uma estratégia clara para o resto. Eu me preparo antes de conversarmos, para que nenhum tempo seja desperdiçado.

Marque uma sessão!

1. Descubra os problemas primeiro

Ao otimizar o desempenho web com um orçamento limitado, precisamos ter certeza absoluta de que estamos otimizando da forma mais eficaz possível. Isso significa que primeiro precisamos saber qual é o verdadeiro problema.

Podemos usar a excelente e gratuita ferramenta PageSpeed Insights para consultar os dados do CrUX. Os dados do CrUX são a única fonte de dados que importa, pois essa é a fonte de dados que o Google usa.

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

Serei claro sobre a auditoria do Lighthouse! Neste momento, não nos importamos com o Lighthouse. Por que? Porque ele não mede os Core Web Vitals. Claro, o Lighthouse é uma ferramenta de teste incrível e sinta-se à vontade para explorar todas as suas sugestões, mas como estamos com um orçamento limitado, nosso foco é ser aprovado nos Core Web Vitals. Não nos importamos em passar em testes sintéticos agora!

Voltando aos dados do CrUX. Aqui estão algumas diretrizes a seguir se você estiver com o orçamento apertado. Comece a investigar os Core Web Vitals nesta ordem exata e concentre-se nesses problemas primeiro!

• Se você estiver reprovando no Time to First Byte, corrija isso primeiro!
• Se você estiver reprovando no First Contentful Paint, corrija os recursos que bloqueiam a renderização (adie scripts e otimize estilos)
• Se você estiver reprovando no Largest Contentful Paint, priorize os recursos necessários para esse LCP (como fontes ou imagens)
• Se você estiver reprovando na CLS, adicione largura e altura a todas as imagens, encontre e remova transições CSS e reserve espaço para elementos renderizados tardiamente (como anúncios, filtros de produtos, etc.)
• Se você estiver reprovando no Interaction to Next Paint, provavelmente está usando muito JavaScript na hora errada. Remova scripts e plugins desnecessários, use uma ferramenta de RUM como o CoreDash para encontrar os scripts mais lentos

2. Otimize suas imagens

As imagens representam 911 KB da página mobile mediana, de acordo com o Web Almanac de 2025. Isso é mais de um terço do peso total da página. E 57% das imagens de LCP ainda são servidas como JPG quando o WebP seria menor com a mesma qualidade. Com orçamento limitado, a otimização de imagens oferece o maior impacto com o menor esforço.

Converta imagens para WebP gratuitamente

Existem muitas ferramentas, soluções e plugins gratuitos disponíveis que permitem converter imagens para formatos mais novos, rápidos e modernos como o WebP. Para o WordPress, por exemplo, eu sugeriria o excelente e gratuito WebP Express.

Implemente o lazy loading

O lazy loading sinalizará ao navegador que uma imagem não deve ser carregada até que esteja quase na janela de visualização visível (viewport). Se você tem 15 imagens em uma página e apenas 3 estão na parte visível da página, você pode adicionar com segurança loading="lazy" às imagens que não estão na viewport visível.

Existem 2 maneiras de resolver isso. A primeira é habilitar o lazy loading em seu CMS. Isso adicionará lazy loading a todas as imagens. Em seguida, consulte a documentação sobre como remover o lazy loading para as imagens que são visíveis e importantes. A outra maneira é adicionar manualmente loading="lazy" às imagens abaixo da dobra (below-the-fold). 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" a uma tag de imagem, sinalizamos ao navegador que essa imagem é mais importante que outras imagens e deve ser baixada primeiro. E embora existam maneiras melhores que incluem pré-carregamento de imagem e 103 Early Hints, definir a prioridade de busca (fetchpriority) é simples, rápido e eficaz! Basta identificar a imagem mais importante da sua página, editar o template e adicionar fetchpriority="high" à imagem:

<img fetchpriority="high" src="image.jpg" width="800" height="600">

3. Corrija o cache do seu navegador

Se você estiver usando uma hospedagem de baixo custo, é provável que o servidor web não esteja configurado de maneira ideal. Um dos erros que encontro regularmente é o cache do navegador mal configurado. Sem os cabeçalhos de cache adequados, os visitantes recorrentes baixam as mesmas imagens, scripts e folhas de estilo repetidas vezes. Isso é desperdício de largura de banda e de tempo.

Se você estiver usando o Apache como servidor web, basta criar um arquivo chamado .htaccess no diretório raiz do seu 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>

Enquanto estiver editando o arquivo .htaccess, habilite também a compactação GZIP. Isso compacta recursos baseados em texto (HTML, CSS, JavaScript) antes de enviá-los ao navegador. Na maioria dos sites, isso reduz o tamanho da transferência de 60 a 80%.

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript
  AddOutputFilterByType DEFLATE application/javascript application/json
</IfModule>

Se você estiver usando um servidor web diferente como o NGINX, entre em contato com o seu provedor de hospedagem e mostre a eles este artigo!

4. Considere o Cloudflare (mesmo o plano gratuito ajuda)

Mesmo no plano gratuito, o Cloudflare oferece muitos dos recursos importantes de desempenho. Se você estiver em uma hospedagem econômica, mudar seu DNS para o Cloudflare é uma das mudanças de maior impacto e menor esforço que você pode fazer. Para um passo a passo detalhado, veja o guia completo de configuração do Cloudflare.

No plano gratuito

1. DNS rápido. Os servidores DNS do Cloudflare são gratuitos e provavelmente superarão o desempenho dos servidores DNS do seu provedor de hospedagem de baixo custo. Os dados do CrUX do Web Almanac de 2025 mostram que apenas 44% das origens mobile têm um bom TTFB. Um DNS lento é um fator comum, e a mudança para o Cloudflare corrige isso instantaneamente.
2. HTTP/3 e Brotli. O Cloudflare usa os protocolos mais recentes e os métodos de compactação mais rápidos. Sem entrar em muitos detalhes, tenha certeza de que isso acelerará sua rede em pelo menos 10%.
3. Cache de navegador consistente. O Cloudflare tem um forte histórico quando se trata de armazenar em cache recursos estáticos. A configuração pronta para uso provavelmente é melhor do que a que você tem no momento.
4. Cache de borda (Edge caching) para recursos estáticos. O Cloudflare armazenará em cache versões de seus recursos estáticos, como imagens, scripts e arquivos CSS, e os servirá diretamente ao usuário final de sua rede de borda (edge network). Isso elimina a necessidade de viagens de ida e volta ao seu servidor de origem.
5. Rocket Loader. O Rocket Loader adiará o carregamento de scripts e lidará com as complicações que surgem disso. É um método rudimentar, mas se você não conseguir adiar scripts manualmente, isso provavelmente melhorará as métricas de pintura, como o Largest Contentful Paint. Nota: O Rocket Loader usa APIs de navegador obsoletas e o PageSpeed Insights pode sinalizá-lo. Se você vir esses avisos, considere adiar seus scripts manualmente.

No plano Pro

Uma das primeiras coisas que sempre digo quando vejo um plano gratuito do Cloudflare é "mude para o pro!". Se os $25 são algo que você pode pagar e está disposto a gastar em um site mais rápido, você provavelmente deveria considerar isso.

1. Todos os recursos gratuitos. Obviamente, o plano pro vem com todos os recursos gratuitos.
2. Cloudflare APO para WordPress. O APO para WordPress é uma solução completa que armazenará em cache suas páginas na rede de borda se os visitantes não estiverem logados. Isso pode acelerar enormemente o Time to First Byte.
3. Otimização de imagem com e sem perdas (Lossless e lossy). Uma das principais vantagens de usar a versão pro do Cloudflare é a otimização de imagem. O Cloudflare converterá e armazenará imagens no formato WebP e as servirá apenas aos visitantes que aceitarem esses formatos.

5. Hospede você mesmo o máximo que puder (Self host)

Outra otimização simples e eficaz é hospedar os recursos estáticos você mesmo. Em muitos sites, os recursos estáticos são hospedados em CDNs externas. Por exemplo, o jQuery é hospedado em https://code.jquery.com/, o Bootstrap é hospedado em https://cdn.jsdelivr.net e suas fontes são hospedadas em https://fonts.googleapis.com. Eu entendo o apelo. Essas CDNs se apresentam como fáceis e rápidas, mas usá-las é, na verdade, uma má ideia e deixará seu site mais lento.

A ideia de usar uma CDN compartilhada para esses tipos de arquivos fazia sentido quando os navegadores ainda podiam compartilhar esses arquivos entre sites. Esses dias já se foram. O resultado é que um novo visitante sempre precisa baixar o arquivo estático e é necessária uma nova conexão com um novo servidor para cada arquivo. E essas novas conexões com esses novos servidores podem consumir muito tempo extra.

A solução é hospedar esses arquivos de terceiros você mesmo. Fazer isso é fácil: basta baixar o arquivo, colocá-lo em seu servidor e alterar a referência a esse arquivo. Para fontes especificamente, veja como hospedar as fontes do Google Fonts você mesmo.

6. Adie seus scripts

Um enorme gargalo pode ser scripts de bloqueio no head da página. Esses scripts podem às vezes atrasar o carregamento da página em até 20 segundos! O Web Almanac de 2025 descobriu que apenas 15% das páginas mobile passam na auditoria de recursos de bloqueio de renderização. Isso mostra o quão difundido é esse problema.

Adiar esses scripts não é nada difícil. Basta adicionar defer à tag script e pronto. Se você puder, faça isso! Edite o template e altere seu script desta forma:

<!-- old blocking script tag -->
<script src="script.js"></script>

<!-- new deferred script tag -->
<script defer src="script.js"></script>

Mas há pegadinhas! Adicionar defer a tags de script pode causar todos os tipos de problemas e erros de dependência. E como você está com orçamento limitado, devo presumir que você não tem os meios para contratar um especialista em JavaScript para corrigir todos os problemas que possam ocorrer. Portanto, tente adiar seus scripts e verifique se há erros (pressione Ctrl+Shift+I no Chrome e verifique a guia console). Se não houver problemas após o teste, você é um dos poucos sortudos! Se houver problemas, você deve recorrer a uma das soluções a seguir. Para o panorama completo, veja 16 métodos para adiar o JavaScript.

Use o Rocket Loader

Como discutido, a versão gratuita do Cloudflare lhe dará acesso ao Rocket Loader. Isso adiará todos os scripts de uma página. De forma alguma é perfeito, mas na maioria das vezes fará um trabalho muito bom.

Use um plugin

A maioria dos sites baseados em CMS tem um enorme repositório de plugins. Existem muitos plugins por aí que permitem adiar o JavaScript e lidar com todas as complicações que podem vir ao adiar scripts.

7. Otimize suas fontes

Fontes web são um custo de desempenho oculto em sites com orçamento reduzido. A página mediana carrega 122 KB de arquivos de fontes de acordo com o Web Almanac de 2025. Se suas fontes são carregadas do Google Fonts, você está fazendo pesquisas de DNS e conexões TCP extras a cada primeira visita.

Duas correções gratuitas:

1. Hospede suas fontes você mesmo. Baixe os arquivos de fonte, coloque-os em seu próprio servidor e carregue-os de lá. Isso elimina a sobrecarga de conexão com fonts.googleapis.com e fonts.gstatic.com.
2. Adicione font-display: swap. Isso diz ao navegador para mostrar texto em uma fonte de fallback imediatamente enquanto a fonte web é baixada. Seus visitantes veem o conteúdo mais rapidamente e você evita o problema de texto invisível. Para a estratégia completa, veja como corrigir o texto invisível durante o carregamento de fontes web.

8. Cache, cache, cache

Quando você está com o orçamento apertado e não quer gastar muito com hospedagem, o cache é uma das maneiras mais eficazes de acelerar um site. O cache é especialmente eficaz contra um alto Time to First Byte. O cache pode ser feito em diferentes níveis.

Cache do lado do cliente: Configure seu servidor web para instruir os navegadores a armazenar em cache o máximo possível de recursos estáticos. Isso diminuirá a carga em seu servidor. (Veja o exemplo de .htaccess na seção 3.)

Cache de objeto: O cache de objeto pode ser usado para armazenar dados cuja regeneração pode ser computacionalmente cara, como o resultado de consultas complexas a bancos de dados. Peça ao seu provedor de hospedagem para instalar o Redis ou Memcached.

Cache de página inteira (Full page cache): Se você estiver usando um CMS, provavelmente desejará adicionar um cache de página inteira ao seu site. Para o WordPress, boas opções são o WP Fastest Cache ou o WP Core Web Vitals.

9. Faça escolhas estratégicas de hospedagem

Quando se trata de hospedagem, vale a pena pesquisar, e o host mais caro nem sempre é o mais rápido. Geralmente, você procura um plano de hospedagem que seja otimizado para o seu CMS, porque um faz-tudo não é mestre em nada. Procure uma hospedagem que inclua PHP 8+, HTTP/2 e armazenamento SSD no mínimo. Um bom host para WordPress com esses princípios básicos superará um host compartilhado genérico todas as vezes.

10. Monitore seu desempenho

Todas essas otimizações não valem nada se você não sabe se elas realmente funcionaram. Configure o Real User Monitoring para que você possa ver como os visitantes reais vivenciam o seu site, e não apenas como o Lighthouse o pontua em um laboratório. As pontuações de laboratório são úteis para depuração, mas os dados de campo de visitantes reais são o que o Google usa para classificação. O CoreDash rastreia os Core Web Vitals de usuários reais e lhe dirá exatamente onde você está.