O seu site está lento e o GTMetrix mostra mais de 130 pedidos HTTP por página?

Este não é um número abstrato de um relatório. Cada pedido é uma chamada do navegador ao servidor para obter um ficheiro: um script, uma folha de estilos, uma imagem ou uma fonte. Quantos mais pedidos existirem, mais tempo os visitantes passam a olhar para um ecrã em branco. De acordo com a Portent, um atraso no carregamento de 0 para 3 segundos reduz a conversão em 2,5%. E cada segundo extra além disso custa mais 4,4%.

O problema dos pedidos HTTP não é existirem. É que a maioria dos sites em WordPress gera muito mais do que o necessário. Abaixo estão cinco passos específicos que reduzem o número de pedidos sem reescrever o seu site de raiz.

💡 Visão geral rápida:

• Remova plugins e temas não utilizados que criam pedidos extra em cada página
• Otimize imagens: comprima ficheiros, remova imagens não utilizadas, combine ícones em sprites
• Combine CSS e JavaScript em 1 ou 2 ficheiros e ative a minificação
• Configure o carregamento diferido para scripts que bloqueiam a renderização da página
• Ative a cache e a CDN para que os visitantes recorrentes não recarreguem o site inteiro

Passo 1. Remova o entulho

Cada plugin instalado traz ficheiros consigo. PHP, CSS, JavaScript: qualquer um destes cria um pedido HTTP quando a página carrega. Vinte plugins significam quase uma centena de pedidos só no arranque, antes de qualquer conteúdo.

A primeira coisa a fazer é uma auditoria. Abra Plugins → Plugins instalados e pergunte a si próprio com honestidade: quais são críticos para o funcionamento do site e quais estão ali apenas «por precaução»? Aquele analisador de SEO que instalou há um ano e abriu duas vezes é candidato a remoção. O plugin de ícones sociais também, se já adicionou os links no rodapé de qualquer forma.

Uma categoria à parte são os plugins que se ligam a servidores de terceiros. Chat ao vivo, rádio em streaming, notificações push. Cada um destes plugins cria pedidos HTTP externos adicionais para servidores de terceiros. Apague tudo o que o site pode dispensar para funcionar. Precisa dele uma vez por mês? Instale-o por um dia e depois remova-o.

A mesma regra aplica-se aos temas. Em Aparência → Temas, mantenha apenas o seu tema ativo e um de reserva (por exemplo, o tema padrão Twenty Twenty-Five). Apague os restantes.

Se um plugin for necessário, mas apenas numa página específica, carregue-o de forma seletiva. O Asset CleanUp: Page Speed Booster faz exatamente isto. É um plugin gratuito com mais de 100.000 instalações ativas e uma classificação de 4,7 no WordPress.org.

O plugin analisa a página, mostra uma lista de ficheiros CSS e JS carregados e permite-lhe desativar ficheiros específicos em páginas, tipos de conteúdo ou em todo o site. Precisa do Contact Form 7 apenas na página de contactos? Desmarque-o em todos os outros locais e os seus scripts não serão carregados onde o formulário não é usado.

🔗 Asset CleanUp no WordPress.org

Já agora, otimize a sua base de dados. Depois de limpar os plugins, as suas configurações e registos permanecem nas tabelas e também devem ser removidos. Verifique também links quebrados: cada redirecionamento é um pedido HTTP extra.

Para ver claramente a dimensão do problema antes e depois, teste o seu site no GTMetrix:

A primeira execução mostra a linha de base: número de pedidos, tamanho total da página, tempo de carregamento. Após cada passo deste artigo, execute o teste novamente. Assim verá quais as alterações que tiveram o maior impacto.

Passo 2. Otimize as imagens

As imagens são o maior «peso» numa página média de WordPress. De acordo com o HTTP Archive, as imagens representam cerca de 44% do tamanho total da página em computadores. E cada imagem é um pedido HTTP.

Comece por remover ficheiros não utilizados. Em Multimédia → Biblioteca, filtre por «Não anexado». Estas são imagens não anexadas a nenhum artigo. Se não forem usadas no tema ou no rodapé, apague-as.

De seguida vem a compressão. Plugins como o WP Compress tratam disto automaticamente: quando carrega uma imagem, esta passa por um otimizador na cloud, é comprimida sem perda visível de qualidade e convertida para WebP ou AVIF. Estes formatos são notoriamente mais leves do que o JPEG com a mesma qualidade visual. De acordo com a Google, o WebP reduz o tamanho do ficheiro em média 25 a 35% em comparação com o JPEG.

O WP Compress tem mais de 10.000 instalações ativas, uma classificação de 4,5 em 5 e mais de 1,1 milhões de downloads no WordPress.org. As primeiras 100 imagens são gratuitas, o suficiente para ver a diferença.

🔗 WP Compress no WordPress.org

A compressão por si só não reduz o número de pedidos HTTP. Mas reduz o tamanho de cada ficheiro, o que significa menos tempo para o transferir. Combinado com os outros passos, isto proporciona um aumento de velocidade notório.

Sprites CSS: um ficheiro em vez de dez

Se tiver uma dúzia de pequenos ícones numa página (redes sociais, setas, estrelas de classificação), cada um carrega como um pedido separado. Um sprite CSS resolve isto: todos os ícones são combinados num único ficheiro e o CSS exibe o fragmento necessário.

Funciona assim: cinco imagens significam cinco pedidos ao servidor. Essas mesmas cinco imagens combinadas num sprite significam um pedido. Ferramentas online como o CSS Sprite Generator podem criar sprites por si. São necessários conhecimentos básicos de CSS para definir a background-position de cada ícone.

Nota: se o seu servidor suportar HTTP/2, os ficheiros carregam de forma assíncrona dentro de uma única ligação. Nesse caso, a poupança do sprite é menos notória. Mas, na prática, uma dúzia de ícones num ficheiro ainda carrega mais rápido do que dez separados.

Passo 3. Combine e minifique CSS e JavaScript

Um site WordPress típico tem mais de 40 ficheiros JS e mais de 20 ficheiros CSS. Cada um é um pedido HTTP separado. Isso soma mais de 60 chamadas ao servidor apenas para scripts e estilos, todos a carregar antes de qualquer conteúdo aparecer.

A minificação remove tudo o que é desnecessário dos ficheiros: espaços, quebras de linha, comentários. O ficheiro fica mais leve, mas o número de pedidos HTTP permanece o mesmo.

A combinação funde vários ficheiros num só. Cinco ficheiros CSS passam a dois (um para o conteúdo acima da dobra, outro para todo o resto). Cinco ficheiros JS, a mesma coisa. E em vez de dez pedidos, fica reduzido a dois ou três.

A ferramenta gratuita mais popular para isto é o Autoptimize. Um plugin com um milhão de instalações ativas e uma classificação de 4,7. Nas definições, há três caixas de seleção: otimizar HTML, CSS e JS. Marque as três e veja resultados imediatos.

Para um controlo mais fino, existe o WP Rocket, uma solução premium que combina ficheiros, minifica-os e adiciona cache numa única interface.

Depois de combinar, verifique sempre o seu site em modo de navegação anónima: por vezes, a junção de ficheiros quebra o layout. Se algo parecer errado, desative a combinação para o ficheiro problemático e mantenha apenas a minificação.

🔗 Site oficial do WP Rocket

Mais uma nota: combinar ficheiros não é uma solução milagrosa. Se um plugin carregar scripts externos a partir de uma CDN (Google Fonts, reCAPTCHA, leitor do YouTube), não os pode combinar. Apenas pode adiá-los ou carregá-los de forma assíncrona, o que nos leva ao próximo passo.

Passo 4. Tratar dos scripts que bloqueiam a renderização

O navegador lê uma página de cima para baixo. Quando encontra <script src="..."> no <head>, interrompe a renderização, descarrega completamente o script e só depois continua. Os visitantes veem uma página em branco durante este tempo.

A solução é mover os scripts que não são necessários para renderizar o primeiro ecrã para o final da página, ou adicionar o atributo async/defer. A diferença:

• defer: o script carrega em segundo plano, mas é executado estritamente após a conclusão da análise do HTML e pela ordem em que são incluídos;
• async: o script carrega e é executado na primeira oportunidade, sem ordem garantida.

Para WordPress, existe um plugin gratuito chamado Async JavaScript. Adiciona async ou defer a scripts selecionados através de uma interface clara. Funciona sem configuração adicional, mas requer cautela: se um script adicionado com async precisar de ser executado antes de outro, a página pode quebrar.

Uma abordagem segura é testar num script, verificar o site em modo anónimo e depois passar ao próximo.

O WP Rocket também pode diferir scripts: vá a File Optimization → Load JavaScript deferred. Selecione "Deferred" e adicione o jQuery às exclusões, uma vez que a maioria dos temas e plugins de WordPress dependem dele.

Resultado: a página começa a ser renderizada mais cedo, mesmo que o número total de pedidos HTTP não tenha mudado. Os visitantes veem o conteúdo enquanto os restantes scripts carregam em segundo plano.

Passo 5. Ativar cache e CDN

A cache reduz diretamente os pedidos HTTP em visitas repetidas. A mecânica é simples: o navegador guarda ficheiros estáticos (CSS, JS, imagens, tipos de letra) localmente. No próximo carregamento da página, em vez de os solicitar ao servidor, vai buscá-los à cache. Zero pedidos HTTP para esse ficheiro.

A cache do lado do servidor é o nível seguinte: o servidor entrega uma página HTML já montada, em vez de executar dezenas de consultas PHP à base de dados. Plugins de cache (WP Rocket, Flying Press, W3 Total Cache) fazem isto automaticamente.

CDN (Content Delivery Network) é uma rede de servidores em todo o mundo. Em vez de ir buscar ficheiros ao seu alojamento nos Países Baixos para um visitante no Brasil, a CDN entrega-os a partir do nó mais próximo. Além disso, os fornecedores de CDN incluem frequentemente compressão, minificação e otimização de imagem de raiz.

Cloudflare é uma opção gratuita que cobre as necessidades básicas: CDN, proteção DDoS, SSL gratuito.

Instale o plugin Cloudflare para WordPress. Ele liga o seu site à CDN e fornece configurações básicas diretamente do painel de administração. Para um controlo mais fino, vá ao painel da Cloudflare: ative Auto Minify para CSS/JS/HTML, compressão Brotli e Rocket Loader para carregamento assíncrono de scripts.

🔗 Cloudflare no WordPress.org

Com cache e CDN, o número de pedidos HTTP para visitantes recorrentes cai drasticamente. Primeira visita: carga completa. Segunda visita: a maioria dos ficheiros vem da cache do navegador e do nó CDN mais próximo, sem qualquer chamada ao seu servidor.

Bónus: verifique se o seu servidor suporta HTTP/2

HTTP/2 é um protocolo que transfere vários ficheiros através de uma única ligação TCP. O navegador não espera que o ficheiro #1 termine de descarregar para solicitar o ficheiro #2; eles carregam em paralelo. Isto reduz o impacto de um elevado número de pedidos HTTP: 60 ficheiros sobre HTTP/2 carregam mais rápido do que os mesmos 60 sobre HTTP/1.1.

Verifique o seu servidor usando a ferramenta de teste HTTP/2 da KeyCDN. Introduza o seu domínio e clique em "Test." Um resultado de "HTTP/2 is supported" significa que o multiplexing está a funcionar.

Se o teste mostrar HTTP/1.1, contacte o seu fornecedor de alojamento. A maioria dos fornecedores de alojamento modernos (SiteGround, Cloudways, Kinsta) ativa o HTTP/2 por defeito. Em alojamento partilhado da década de 2010, isto pode não acontecer. Verifique também a sua versão do PHP: atualizar para uma versão moderna do PHP proporciona um aumento de desempenho notável, enquanto versões desatualizadas processam os pedidos significativamente mais devagar. Se o seu fornecedor de alojamento não atualizar nem o protocolo nem a versão do PHP, talvez seja altura de considerar mudar de fornecedor.

Se preferir o formato de vídeo, aqui está um guia visual para reduzir os pedidos HTTP no WordPress (12 minutos).

⁉️🤔 Perguntas frequentes

Quantos pedidos HTTP são considerados normais para WordPress?

Um intervalo de referência é de 30 a 60 por página. Qualquer valor acima de 80 a 90 exige otimização. O GTMetrix e o Pingdom mostram números específicos nos seus relatórios. Após aplicar os cinco passos deste artigo, é realista descer de 130 para 35 a 45 pedidos.

"Tenho um site em Elementor, e já tem mais de 100 pedidos. Isso é normal?"

Os construtores de páginas geram muito CSS e JS por natureza. O Elementor e o Divi adicionam 30 a 50 pedidos só por si. Isto não significa "aceite"; significa que o resto do seu site deve ser o mais limpo possível. Remova tudo o que não está relacionado com o construtor: plugins desnecessários, tipos de letra externos, imagens não otimizadas. Mantenha apenas o que realmente serve os seus visitantes.

O que importa mais: número de pedidos ou tamanho total da página?

Ambos. 20 pedidos de 1 MB cada significam um carregamento de página de 20 segundos. 100 pedidos de 5 KB cada podem carregar mais rápido, mas cada pedido incorre em sobrecarga para pesquisa de DNS, ligação TCP e handshake TLS. Em HTTP/2, esta diferença é atenuada. Em HTTP/1.1, é crítica. Otimize ambos: reduza a contagem de pedidos através da combinação de ficheiros e sprites, reduza o tamanho através de compressão e minificação.

Posso sobreviver sem plugins?

Parcialmente, sim. A minificação de CSS/JS pode ser configurada via Gulp ou Webpack durante o desenvolvimento do tema. O HTTP/2 é ativado ao nível do servidor (configuração Nginx/Apache). A cache pode ser feita através de regras do servidor. Mas para a maioria dos proprietários de sites WordPress, os plugins são o caminho mais prático: a configuração demora minutos, os resultados são imediatos e o risco de quebrar o site é menor.

Com que frequência devo reverificar o número de pedidos HTTP?

Após cada grande instalação ou atualização de plugin. Um novo plugin pode adicionar o seu CSS/JS a todas as páginas, e não vai notar até o site começar a ficar lento. Uma vez por mês é suficiente para verificações de rotina. O GTMetrix permite configurar monitorização automática com alertas quando o desempenho cai.

Preciso mesmo deste guia se já tenho um alojamento rápido?

O alojamento resolve parte do problema ao nível do servidor, mas não ao nível do código. Se um plugin inserir 15 scripts no <head> da página, nem os melhores servidores os farão carregar instantaneamente. O navegador continuará à espera. Um alojamento rápido dá-lhe uma vantagem inicial, mas o verdadeiro vencedor é quem também limpa o lado do cliente.

O que reduz realmente os pedidos HTTP e o que não reduz?

Vamos percorrer todos os passos sem ilusões:

• Limpar plugins e temas produz a melhoria mais notória. Cada plugin removido elimina o seu CSS, JS e chamadas externas. Na prática, desaparecem 10 a 30 pedidos após uma auditoria.
• A compressão de imagens reduz o tamanho dos ficheiros, mas o número de pedidos mantém-se. No entanto, o tempo total de carregamento diminui consideravelmente.
• Combinar CSS e JS reduz significativamente o número de pedidos. Desvantagem: pode quebrar o layout, pelo que deve verificar após cada alteração.
• Carregamento diferido de scripts: mesmo número de pedidos, mas a página torna-se visível mais cedo.
• Cache e CDN: para novos visitantes, a diferença é mínima. Para visitantes recorrentes, os carregamentos repetidos da página acontecem sem um único pedido ao servidor.

Se tivéssemos de escolher exatamente três ações com maior impacto num site WordPress típico: (1) remover plugins desnecessários, (2) ativar a combinação de CSS/JS através do Autoptimize, (3) configurar a Cloudflare. São três passos que ocupam uma tarde em vez de uma semana, e verá os resultados nos números do GTMetrix logo no dia seguinte.