Configuração do servidor para um site rápido: cache, PHP, compressão

No servidor, um site fica mais rápido principalmente com cinco coisas: cache no servidor (Redis ou Memcached), limites do PHP adequados, compressão GZIP ou Brotli, índices no banco de dados e o servidor web certo, além de um monitoramento que avise quando algo piora. Em uma hospedagem compartilhada você mesmo altera parte disso (valores do PHP, .htaccess, índices); o restante só é possível em um servidor próprio. Meça o TTFB antes e depois de cada mudança em vez de confiar em porcentagens prometidas.

Abaixo, cada ajuste vem com um comando para conferir, os valores padrão oficiais e uma tabela do que o cliente de hospedagem compartilhada pode alterar.

Cache no nível do servidor: respostas prontas na memória

Fazer cache é simplesmente guardar respostas já prontas. Em vez de gerar a mesma página ou repetir a mesma consulta para cada visitante, o resultado fica na memória. O navegador e o PHP também fazem cache, mas o cache no servidor atua mais a fundo.

As opções mais populares são Redis e Memcached: um buffer entre o banco de dados e o site que entrega da RAM os resultados de consultas repetidas. Quanto isso acelera o seu site precisa ser medido: compare o TTFB antes e depois de ativar o cache com curl -o /dev/null -s -w "TTFB: %{time_starttransfer} s\n" https://your-site/. O guia web.dev do Google considera bom um TTFB de 0,8 segundo ou menos e ruim acima de 1,8 segundo (verificado em 30.10.2026).

Onde ativar depende do tipo de hospedagem. Na hospedagem compartilhada, Redis ou Memcached só estão disponíveis se o provedor os oferecer como serviço; você não consegue instalá-los. Em um servidor próprio você instala o serviço e depois conecta a aplicação a ele (no WordPress, com um plugin de cache de objetos).

• Redis: mais estruturas de dados (listas, hashes, conjuntos) e persistência opcional em disco
• Memcached: cache chave-valor simples e multithread para strings e objetos
• Tempo de vida do cache (TTL): depende da frequência com que os dados mudam: conteúdo que quase não muda pode ficar horas em cache, dados que mudam muito, só minutos
• Limite de memória: defina quanta RAM o cache pode ocupar (maxmemory no Redis, -m no Memcached)

Confira a carga de CPU antes e depois de ativar o cache, no painel da hospedagem ou com top no servidor. Quanto mais consultas idênticas o site faz, maior o efeito.

Configuração do PHP: os parâmetros que importam

O arquivo php.ini tem dezenas de diretivas, mas cinco delas causam a maioria dos problemas em sites com CMS:

Os valores padrão e as regras de tamanho (upload_max_filesize menor que post_max_size, post_max_size menor que memory_limit) vêm do manual do PHP (verificado em 30.10.2026). A coluna de exemplo é uma referência, não uma norma: defina o que o seu site realmente precisa e o que o seu plano permite. O comando php -i | grep -E "memory_limit|upload_max_filesize|post_max_size" ou a função phpinfo() mostra os valores atuais. Se já aparecem erros, veja nossos guias sobre o erro Allowed memory size exhausted e sobre como aumentar o upload_max_filesize.

Na hospedagem compartilhada, o php.ini principal pertence ao provedor. Os valores de cada site normalmente são alterados no painel de controle, em um arquivo .user.ini na raiz do site (quando o PHP roda via FastCGI ou PHP-FPM, veja a página do manual do PHP sobre .user.ini) ou com php_value no .htaccess (quando o PHP roda como módulo do Apache), e sempre dentro dos limites definidos pelo provedor. memory_limit e max_execution_time também podem ser definidos no código com ini_set(); upload_max_filesize, post_max_size e max_input_vars não (modo INI_PERDIR). Por padrão, o PHP relê o .user.ini a cada 300 segundos, então uma mudança pode levar até 5 minutos para valer. Em um servidor próprio você edita o php.ini ou o pool do PHP-FPM e reinicia o PHP-FPM.

Importante: não altere valores às cegas. Guarde uma cópia das configurações originais: um valor errado pode derrubar o site inteiro.

Compressão: arquivos de texto mais leves

O site envia HTML, CSS e JavaScript para o navegador. Texto se comprime bem: o servidor reduz os arquivos antes de enviar e o navegador os descompacta sem que o usuário perceba. É a compressão GZIP ou Brotli.

Se o site é servido pelo Apache com mod_deflate, bastam algumas linhas no .htaccess:

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

Se quem entrega as respostas é o Nginx (sozinho ou como proxy na frente do Apache), o .htaccess não controla a compressão: ela é definida na configuração do Nginx. Segundo a documentação do nginx.org, a diretiva gzip vem desativada por padrão, e o Brotli não faz parte dos módulos padrão do Nginx. Na hospedagem compartilhada isso cabe ao provedor; em um servidor próprio você mesmo ativa.

O quanto a transferência diminui depende dos seus arquivos, então confira você mesmo. O comando curl -sI -H "Accept-Encoding: gzip, br" https://your-site/ | grep -i content-encoding deve retornar gzip ou br. Se a linha não aparecer, a compressão não está funcionando.

O gtmetrix.com e o pagespeed.web.dev também mostram o tamanho dos arquivos e apontam recursos sem compressão.

Otimização do banco de dados: índices e consultas lentas

O banco de dados é o coração de qualquer site dinâmico e muitas vezes é o que o deixa lento. O problema mais comum são índices ausentes: estruturas que permitem encontrar linhas sem ler a tabela inteira.

Imagine uma biblioteca sem catálogo: o livro está lá, mas é preciso vasculhar todas as estantes. Com um índice, o banco de dados sabe exatamente onde procurar.

O que fazer:

1. Abra o phpMyAdmin ou outra ferramenta de gerenciamento de banco de dados.
2. Verifique se as colunas usadas com frequência em buscas e junções (ID, user_id, status) têm índice.
3. Depois de exclusões em massa, execute OPTIMIZE TABLE table_name;. Em tabelas InnoDB, o MySQL recria a tabela e atualiza as estatísticas (ALTER TABLE … FORCE); o manual do MySQL desaconselha fazer isso como rotina.
4. Exclua tabelas que sobraram de plugins removidos e de versões antigas (depois de fazer um backup).
5. Ative o log de consultas lentas (slow query log) e veja quais consultas demoram demais. Ele vem desativado por padrão, o long_query_time é de 10 segundos e ativá-lo em tempo de execução exige o privilégio SYSTEM_VARIABLES_ADMIN. Por isso, na hospedagem compartilhada só o provedor pode ativá-lo; em um servidor próprio você define isso na configuração do MySQL.

Quanto maior a tabela, mais um índice ausente pesa: uma consulta instantânea em um banco pequeno passa a deixar o site inteiro lento em um banco grande.

Nginx ou Apache: qual servidor web escolher

O Apache é o servidor mais antigo e versátil, com configuração flexível por diretório (.htaccess). O Nginx é mais novo, orientado a eventos e entrega arquivos estáticos usando menos memória, mas não tem .htaccess e é configurado no servidor.

Em termos simples:

• Apache: com o MPM prefork, um processo por conexão; o MPM event, que é o padrão, trabalha com threads (documentação do Apache); flexível e bom para configurações complexas
• Nginx: arquitetura assíncrona: um processo worker atende milhares de conexões, rápido com arquivos estáticos
• A escolha depende da carga: um blog pequeno funciona bem com Apache, enquanto com muitas conexões simultâneas o Nginx economiza memória. Um meio-termo comum é o Nginx na frente do Apache.

Se você migrar totalmente para o Nginx, prepare-se para reescrever as regras do mod_rewrite na sintaxe do Nginx. Não é complicado, mas leva tempo.

Na hospedagem compartilhada, quem escolhe o servidor web é o provedor; você configura apenas o que o .htaccess e o painel permitem. A escolha entre Nginx e Apache é uma decisão para um servidor próprio.

Monitoramento: descobrir os problemas antes dos clientes

A configuração do servidor não é algo que se faz uma vez e se esquece. Depois de cada mudança, e depois regularmente, acompanhe estes indicadores:

• CPU e RAM: se a CPU bate no limite do plano por muito tempo, o site fica lento e pode responder com erro 504 Gateway Timeout
• Espaço em disco: com o disco quase cheio, o banco de dados pode não conseguir gravar novos dados
• Consultas ao banco: acompanhe as consultas lentas nos logs
• Disponibilidade: um serviço externo como o Pingdom avisa se o site cair de madrugada

Painéis de controle como cPanel e Plesk mostram o uso de disco e de tráfego; Google Cloud Monitoring e Datadog servem para projetos maiores. Quais indicadores acompanhar e como configurar alertas está no nosso guia de monitoramento do servidor de hospedagem.

O principal: otimizar é um trabalho contínuo. Mude uma coisa, meça e só então dê o próximo passo.

O que você pode mudar na hospedagem compartilhada e o que só no servidor próprio

Esta tabela responde à pergunta mais comum. Hospedagem compartilhada: o provedor administra o servidor. Servidor próprio (VPS ou dedicado): você administra tudo.

Os planos de hospedagem da RichHost rodam em discos NVMe com o painel de controle próprio e seu assistente de IA e servidores na Europa e nos EUA, a partir de US$ 8 por mês. Se o seu site usa WordPress, veja também como acelerar o WordPress.

Perguntas frequentes

Quais são os valores padrão do PHP para memória e uploads?

Segundo o manual do PHP: memory_limit 128M, max_execution_time 30 segundos, upload_max_filesize 2M, post_max_size 8M, max_input_vars 1000. O seu provedor pode usar outros valores; o phpinfo() mostra os reais.

Posso ativar o Redis na hospedagem compartilhada?

Só se o provedor oferecer Redis ou Memcached como serviço. Caso contrário, use o cache de páginas do CMS ou migre para um servidor próprio, onde você mesmo instala o Redis.

Devo rodar OPTIMIZE TABLE regularmente?

Não. No InnoDB o comando recria a tabela, e o manual do MySQL só o recomenda quando há desperdício real de espaço, por exemplo depois de excluir muitas linhas.

Como saber se a compressão funciona?

Execute o comando curl da seção sobre compressão: o cabeçalho content-encoding deve mostrar gzip ou br.

Qual TTFB é considerado bom?

O guia web.dev do Google considera bom 0,8 segundo ou menos e ruim acima de 1,8 segundo. Meça várias vezes e a partir da região onde estão os seus visitantes.