Reduzir requests HTTP no WordPress é diminuir quantos arquivos, scripts, estilos, fontes e imagens, o navegador precisa baixar para montar a página, porque cada um é uma ida ao servidor que custa tempo. Com o Perfmatters, você desativa o que não é usado e adia o que pode esperar, sem reescrever o tema. O resultado é uma página de melhor performance, com menos idas ao servidor e um carregamento mais leve. Este guia faz parte do hub de performance WordPress da FULL e mostra o passo a passo real, da medição dos requests à validação do ganho.

O que são requests HTTP e por que eles pesam

Requests HTTP são as requisições que o navegador faz ao servidor para baixar cada recurso da página, um script, um estilo, uma fonte ou uma imagem, e cada uma adiciona tempo ao carregamento. Quanto mais arquivos a página pede, mais idas e vindas acontecem antes de tudo aparecer na tela.

Na prática, um tema e vários plugins enfileiram dezenas de scripts e estilos, muitos deles inúteis na maioria das páginas, e cada um vira uma requisição. Com o Perfmatters, você corta os que não servem e adia os que podem esperar. Nos atendimentos da FULL sobre performance no WordPress, o tropeço campeão é desativar um script no site inteiro sem testar, e descobrir tarde que ele era necessário em uma página específica, como o checkout.

Legenda: cada arquivo na lista é uma requisição que o navegador faz para montar a página.

Quando vale reduzir requests em vez de só ativar cache

Vale reduzir requests quando a página carrega muitos scripts de plugins, quando o cache sozinho não resolveu a lentidão ou quando o relatório de performance aponta excesso de recursos, e vale focar só no cache quando a página já é enxuta e o gargalo é o tempo de servidor. A redução de requests rende quando há excesso de arquivos enfileirados.

Use este teste antes de mexer. Diga SIM à redução de requests se a sua página pede dezenas de scripts e estilos, muitos de plugins que só atuam em telas específicas, e o carregamento está pesado. Diga NÃO se a página já é leve e a lentidão vem do servidor, porque aí o ganho está em cache e otimização de entrega. O encaixe ideal é o site cheio de plugins que enfileiram recursos. Os Core Web Vitals mostram se o excesso de requests está pesando.

Pré-requisitos antes de reduzir os requests

Antes de reduzir os requests você precisa de três peças no lugar, o Perfmatters ativo para controlar os recursos, uma ferramenta de medição para ver os requests antes e depois, e a disposição de testar página a página, e a falta de qualquer uma leva a cortar no escuro e quebrar recursos. Sem medir antes, você não sabe quanto realmente ganhou.

Checklist de prontidão antes de começar:

• Perfmatters instalado e ativo no site.
• Uma ferramenta de medição de requests, como o teste de velocidade.
• Um backup do site antes de desativar recursos.
• A lista das páginas críticas a testar, como checkout e contato.
• A medição inicial dos requests, para comparar depois.
• Paciência para testar cada mudança em vez de cortar tudo de uma vez.
• Acesso de administrador para o Script Manager do Perfmatters.

Pense nos requests como a lista de compras de uma receita: cada item é uma ida ao mercado, e quanto mais idas, mais demora o jantar. O Perfmatters é o cozinheiro que revisa a lista e corta o que não entra no prato de hoje. Mas cortar um ingrediente essencial estraga a receita, então a revisão precisa ser página a página, não no escuro.

Como reduzir os requests HTTP em 5 passos

Reduzir os requests segue cinco passos, da medição inicial à validação do ganho, e respeitar a ordem evita o erro mais comum: desativar scripts no site inteiro sem testar onde eles são usados. Cada passo corta um excesso com segurança. Confirme antes que o Perfmatters está ativo e você tem um backup, porque desativar recursos pode quebrar páginas.

Passo 1: Meça os requests atuais

Antes de cortar qualquer coisa, rode um teste de velocidade e anote quantos requests a página faz hoje, porque é essa linha de base que vai mostrar o ganho real depois. Use uma ferramenta que liste os recursos carregados, separando scripts, estilos, fontes e imagens. Identifique de onde vêm os arquivos, o tema ou cada plugin, para saber o que atacar. Esse passo evita cortar no escuro: medir antes e depois é o que prova que a otimização funcionou. Reserve um tempo para entender o relatório, porque ver quais plugins enfileiram mais recursos já aponta onde está o maior excesso a reduzir nos próximos passos.

Passo 2: Desative os recursos globais inúteis

No Perfmatters, desligue os recursos que o WordPress carrega por padrão e que a maioria dos sites não usa, como os scripts de emojis, os embeds e as query strings nos assets, porque cada um é uma requisição que some sem prejuízo visível. Esses itens são seguros de desativar na maior parte dos casos e dão um ganho rápido. Ative as opções de desativação no painel do Perfmatters. Confira a página após cada mudança para garantir que nada essencial quebrou. Esse passo colhe os ganhos fáceis primeiro: são recursos globais raramente necessários, então desligá-los reduz requests sem o risco das otimizações mais cirúrgicas que vêm a seguir.

Passo 3: Use o script manager para desativar por página

Abra o Script Manager do Perfmatters e desative, página por página, os scripts de plugins que não atuam ali, porque é assim que você corta com precisão sem quebrar telas onde o recurso é necessário. Um plugin de formulário, por exemplo, só precisa carregar na página que tem o formulário, não no site inteiro. Use a regra de exceção para manter o script onde ele é usado. Teste cada página crítica após desativar. Esse é o passo de maior ganho e maior risco: desligar um script global sem a exceção certa quebra o recurso, então trabalhe com cuidado e teste sempre, página a página, em vez de cortar tudo de uma vez.

Passo 4: Adie o que sobrar para liberar o carregamento

Para os scripts que precisam ficar, configure o adiamento no Perfmatters, deixando o JavaScript não crítico carregar depois do conteúdo principal, porque adiar libera a página para aparecer antes de tudo terminar de baixar. O carregamento adiado melhora a sensação de velocidade mesmo quando o número de arquivos não cai tanto. Ative o atraso e o adiamento de scripts com cuidado, testando a interação. Se o site começar a retornar erro de excesso de requisições por automações ou bots, veja como corrigir o erro 429 Too Many Requests no WordPress, que trata do limite de requisições ao servidor.

Passo 5: Re-meça e valide o ganho

Rode o teste de velocidade de novo e compare o número de requests com a linha de base do passo 1, confirmando que caiu e que nenhuma página crítica quebrou, porque só a comparação prova o ganho real. Navegue pelas telas importantes, como checkout e contato, para garantir que tudo funciona. Confira a página no celular, já que o mobile sente mais o peso dos requests. Se o banco fica lento com tantas consultas de plugins, veja como otimizar o wp_options para consultas lentas, que ataca o gargalo no servidor além dos requests do navegador.

Legenda: cada passo corta um excesso, da medição inicial à validação do ganho.

Erros comuns ao reduzir requests HTTP

Os três erros mais comuns ao reduzir requests são desativar scripts no site inteiro sem testar, não medir antes e depois, e adiar scripts críticos demais. O primeiro é o mais grave: desligar um script global sem conferir onde ele atua quebra recursos em páginas específicas, como um formulário ou um checkout que param de funcionar.

O segundo erro é cortar recursos sem medir os requests antes, ficando sem saber se a mudança realmente ajudou. A correção é sempre anotar a linha de base e comparar. O terceiro caso é adiar um script essencial para a primeira tela, o que faz a página aparecer quebrada por um instante. Quando o servidor responde com erro de requisição malformada após as mudanças, vale ver como corrigir o erro 400 Bad Request no WordPress.

Como manter a performance em produção

Manter a performance em produção exige cuidar de duas frentes, a revisão dos requests a cada plugin novo e a estabilidade das regras do Script Manager a cada atualização, porque um plugin novo enfileira mais recursos e uma atualização pode mudar os scripts que ele carrega. O site ganha plugins ao longo do tempo, então a redução de requests é manutenção contínua, não um ajuste único.

Sempre que instalar um plugin, meça de novo os requests e use o Script Manager para limitar onde ele carrega, porque cada novo plugin tende a enfileirar scripts no site inteiro. Depois de cada atualização, refaça um teste de velocidade nas páginas críticas. Para padronizar a otimização de performance em vários sites sem licença avulsa, o guia de o que está matando a sua performance mostra a rotina.

Como a FULL faz isso em escala

A FULL padroniza a redução de requests com Perfmatters porque acompanha mais de 150 mil sites WordPress, e sites pesados de plugins que enfileiram scripts demais aparecem o tempo todo, onde revisar os recursos de cada projeto na unha vira gargalo. Em vez de licença avulsa do Perfmatters por instalação, a ferramenta entra no bundle e o padrão de otimização de requests fica replicável de um site para outro.

No plano PRO da FULL, por R$849, o Perfmatters já vem no pacote para até dez sites, o que dá R$85 por site em vez de pagar cada licença separada. Para quem cuida de vários sites pesados, a gente vê isso trocar um custo recorrente espalhado por um padrão único: as mesmas regras de desativação e adiamento de scripts são exportadas e reaproveitadas de um projeto para outro, sem revisar os requests do zero a cada site. É a economia que só aparece quando o stack é o mesmo em toda a base.

Checklist final da redução de requests

O checklist final da redução de requests confirma, em uma passada, que a página ficou mais leve sem quebrar nada antes de você considerar a otimização pronta. Rode esta lista depois do passo 5 e a cada plugin novo, porque é a instalação de plugins que reintroduz requests.

Antes de declarar pronto, confirme:

• O número de requests inicial foi medido e anotado.
• Os recursos globais inúteis, como emojis e embeds, estão desativados.
• O Script Manager desativou os scripts onde eles não são usados.
• As páginas críticas, como checkout e contato, seguem funcionando.
• Os scripts não críticos foram adiados sem quebrar a primeira tela.
• A nova medição mostra menos requests que a linha de base.
• A página carrega bem no celular, não só no desktop.

Se qualquer item falhar, principalmente uma página crítica quebrada, volte ao passo correspondente antes de considerar a otimização pronta.

Perguntas frequentes sobre reduzir requests HTTP no WordPress

Próximos passos para um site mais leve

Reduzir requests HTTP no WordPress é, no fundo, fazer a página pedir menos ao servidor: meça a linha de base, desative os recursos globais inúteis, use o Script Manager por página e, acima de tudo, teste cada corte antes de seguir. Desativar scripts no site inteiro sem testar é o que quebra recursos específicos, então trabalhe página a página. Para padronizar o Perfmatters em vários sites sem licença avulsa, conheça os planos da FULL, e para continuar aprendendo, o FULL Academy reúne os tutoriais de WordPress em um só lugar.