Velocidade da Página 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 velocidade da página. E sim, às vezes não há um grande orçamento. Se esse for o caso, preciso ser ainda mais eficiente com o 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 2025 Web Almanac, apenas 48% das origens móveis passam nos três Core Web Vitals. A página móvel mediana pesa 2,6 MB, com 632 KB de JavaScript (dos quais 251 KB não são utilizados). Esses são problemas que você pode corrigir sem um grande orçamento.

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

Reserve uma sessão!

1. Descubra os problemas primeiro

Ao otimizar o desempenho web com 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 problema real.

Podemos usar o excelente e gratuito 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.

Deixe-me ser 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, nos importamos em passar 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 serem seguidas se você estiver com orçamento limitado. Comece a investigar os Core Web Vitals exatamente nesta ordem e concentre-se nesses problemas primeiro!

• Se você estiver falhando no Time to First Byte, corrija isso primeiro!
• Se você estiver falhando no First Contentful Paint, corrija os recursos que bloqueiam a renderização (adie os scripts e otimize os estilos)
• Se você estiver falhando no Largest Contentful Paint, priorize os recursos que você precisa para esse LCP (como fontes ou imagens)
• Se você estiver falhando no CLS, adicione largura e altura a todas as imagens, encontre e remova transições CSS e reserve espaço para elementos de renderização tardia (como anúncios, filtros de produtos, etc.)
• Se você estiver falhando no Interaction to Next Paint, você 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 móvel mediana, de acordo com o 2025 Web Almanac. Isso é mais de um terço do peso total da página. E 57% das imagens de LCP ainda são veiculadas como JPG, quando o WebP seria menor na 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 permitirão converter imagens para formatos mais recentes, rápidos e modernos, como WebP. Para o WordPress, por exemplo, eu sugeriria o excelente e gratuito WebP Express.

Implemente o carregamento lento (lazy loading)

O carregamento lento 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ê tiver 15 imagens em uma página e apenas 3 estiverem na parte visível da página, poderá adicionar com segurança loading="lazy" às imagens que não estão na janela de visualização visível.

Existem 2 maneiras de lidar com isso. A primeira é habilitar o carregamento lento no seu CMS. Isso adicionará o carregamento lento a todas as imagens. Em seguida, consulte a documentação sobre como remover o carregamento lento das 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 a fetchpriority da imagem

Ao adicionar fetchpriority="high" a uma tag de imagem, sinalizamos ao navegador que esta imagem é mais importante do que outras imagens e deve ser baixada primeiro. E embora existam maneiras melhores que incluem o pré-carregamento de imagem e o 103 Early Hints, definir a fetchpriority é simples, rápido e eficaz! Basta identificar a imagem mais importante da sua página, editar o modelo 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 econômica, é provável que o servidor web não esteja configurado de forma otimizada. Um dos erros que encontro regularmente é o cache do navegador mal configurado. Sem 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 os 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 seu provedor de hospedagem e indique este artigo a eles!

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 alterações 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 os servidores DNS do seu provedor de hospedagem econômico. Os dados do CrUX do 2025 Web Almanac mostram que apenas 44% das origens móveis têm um bom TTFB. O DNS lento é um contribuinte 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 a certeza de que isso acelerará sua rede em pelo menos 10%.
3. Cache consistente do navegador. O Cloudflare tem um forte histórico quando se trata de armazenar em cache recursos estáticos. A configuração padrão 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 dos seus recursos estáticos, como imagens, scripts e arquivos CSS, e os servirá diretamente ao usuário final a partir de sua rede de borda. 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 a partir 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 descontinuadas e o PageSpeed Insights pode sinalizar isso. Se você vir esses avisos, considere adiar seus scripts manualmente.

No plano Pro

Uma das primeiras coisas que eu sempre digo quando vejo um plano gratuito do Cloudflare é "vá para o pro!". Se os $25 forem algo que você pode pagar e estiver disposto a gastar em um site mais rápido, você provavelmente deve 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á suas páginas em cache na rede de borda se os visitantes não estiverem logados. Isso pode acelerar enormemente o Time to First Byte.
3. Otimização de imagens sem perdas (lossless) e com perdas (lossy). Uma das principais vantagens de usar a versão pro do Cloudflare é a otimização de imagens. O Cloudflare converterá e armazenará as imagens em cache no formato WebP e as servirá apenas para visitantes que aceitarem esses formatos.

5. Hospede você mesmo o máximo que puder

Outra otimização simples e eficaz é hospedar (self-hosting) 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 atrativo. Essas CDNs se apresentam como fáceis e rápidas, mas usá-las é, na verdade, uma péssima ideia e deixará seu site mais lento.

A ideia de usar uma CDN compartilhada para esses tipos de arquivos era boa na época em que os navegadores ainda podiam compartilhar esses arquivos entre sites. Esses dias acabaram. O resultado é que um novo visitante sempre precisa baixar o arquivo estático e precisa de uma nova conexão com um novo servidor para cada arquivo. E essas novas conexões a esses novos servidores podem consumir muito tempo extra.

A solução é hospedar esses arquivos de terceiros por conta própria (self-host). Fazer isso é fácil: basta baixar o arquivo, colocá-lo no seu servidor e alterar a referência a este arquivo. Especificamente para fontes, veja como hospedar o Google Fonts você mesmo.

6. Adie seus scripts

Um grande gargalo podem ser os scripts que bloqueiam o cabeçalho (head) da página. Esses scripts às vezes podem atrasar o carregamento da página em até 20 segundos! O 2025 Web Almanac descobriu que apenas 15% das páginas móveis 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 modelo e altere seu script da seguinte forma:

<!-- 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 às tags de script pode causar todos os tipos de problemas e erros de dependência. E, como você está com o orçamento limitado, devo presumir que não tem recursos para contratar um especialista em JavaScript para consertar todos os problemas que possam ocorrer. Portanto, tente adiar seus scripts e verificar 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 seguintes soluções. Para ter uma visão completa, consulte os 16 métodos para adiar o JavaScript.

Use o Rocket Loader

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

Use um plugin

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

7. Otimize suas fontes

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

Duas correções gratuitas:

1. Hospede suas fontes você mesmo. Baixe os arquivos de fontes, coloque-os no 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 exibir imediatamente o texto com uma fonte de fallback enquanto a fonte da web é baixada. Seus visitantes veem o conteúdo mais rápido e você evita o problema do texto invisível. Para a estratégia completa, veja como consertar o texto invisível durante o carregamento de fontes da 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 Time to First Byte alto. O cache pode ser feito em diferentes níveis.

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

Cache de objetos: O cache de objetos pode ser usado para armazenar dados que podem ser computacionalmente caros para regenerar, como o resultado de consultas complexas a bancos de dados. Peça ao seu hoster para instalar o Redis ou Memcached.

Cache de página inteira: 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ê está procurando um plano de hospedagem que seja otimizado para o seu CMS, porque ser um pau para toda obra é ser mestre de nada. Procure uma hospedagem que inclua PHP 8+, HTTP/2 e armazenamento SSD no mínimo. Um bom host WordPress com esses recursos básicos sempre superará um host compartilhado genérico.

10. Monitore o seu desempenho

Todas essas otimizações não valem nada se você não souber se elas realmente funcionaram. Configure o Real User Monitoring para que você possa ver como os visitantes reais experimentam 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 (field data) 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á.