Quantos núcleos de CPU tem o plano? Quanta memória RAM oferece? O armazenamento é NVMe? São perguntas legítimas, mas insuficientes para avaliar um alojamento WordPress.
Dois planos com recursos anunciados e preços semelhantes podem comportar-se de forma muito diferente. A diferença aparece sobretudo quando o website recebe pedidos simultâneos, consulta a base de dados, processa encomendas ou executa integrações. A escolha deve partir do trabalho que o WordPress precisa de realizar, e não apenas da tabela comercial do fornecedor.
Comece pela utilização real do website
Um website institucional com páginas públicas, poucos formulários e cache eficiente tem necessidades distintas de uma loja WooCommerce com clientes autenticados, filtros de produtos, finalização de compras e sincronizações com sistemas externos.
Imagine dois websites com 10 000 visitas mensais. No primeiro, a maioria das páginas pode ser entregue a partir da cache, sem executar PHP em cada visita. No segundo, uma parte considerável dos pedidos exige processamento individual: pesquisar produtos, consultar preços específicos, atualizar o carrinho ou finalizar uma encomenda. O número de visitas é igual; a carga sobre o servidor pode ser muito diferente.
Antes de comparar propostas, identifique o que acontece nas páginas públicas, no painel de administração e nas tarefas executadas em segundo plano. Considere também as importações, os utilizadores autenticados e as chamadas a serviços externos. É essa combinação, incluindo os períodos de maior atividade, que determina a capacidade necessária.
CPU, RAM, processos PHP, base de dados e disco
As especificações técnicas interessam, mas devem ser analisadas em conjunto. Uma quantidade elevada de memória não compensa um limite baixo de processos PHP, tal como um disco rápido não resolve uma integração externa demorada.
| Recurso | O que interessa confirmar |
|---|---|
| CPU | Capacidade de processamento efetivamente disponível, limites de utilização contínua e eventual partilha de recursos. |
| Memória RAM | Memória disponível para PHP, base de dados, cache e serviços; limites por conta e utilização excessiva de memória de troca (swap). |
| Processos PHP | Quantos pedidos dinâmicos podem ser tratados em simultâneo e o que acontece quando se atinge esse limite. |
| Base de dados | Versão, memória, configuração, ligações disponíveis e eficiência das consultas. |
| Armazenamento | Espaço, latência, capacidade de leitura/escrita e possíveis limites ou contenção, para além da indicação «SSD» ou «NVMe». |
Porque é que os processos PHP merecem atenção?
Em alojamentos com PHP-FPM, os pedidos PHP são executados por processos de trabalho. A diretiva pm.max_children define o máximo de processos de um determinado conjunto (pool) que podem atender pedidos simultâneos. Quando todos estão ocupados, novos pedidos podem ficar em espera.
Isto tem impacto especial em operações que não beneficiam de cache de página, como a finalização de compras, determinadas pesquisas, pedidos AJAX e ações no painel de administração. Não existe um número universal de processos PHP adequado a todos os websites: contam a duração dos pedidos, o consumo de memória, a CPU e a concorrência real. Aumentar o limite sem capacidade disponível pode agravar a pressão sobre o servidor.
Uma utilização elevada de CPU também merece diagnóstico. Pode resultar de tráfego legítimo, mas igualmente de consultas ineficientes, tarefas agendadas, importações, pedidos automatizados ou código problemático. Comprar mais recursos pode aliviar os sintomas sem corrigir a origem.
Versões atuais e configuração da base de dados
Segundo os requisitos recomendados pelo WordPress, o alojamento deve disponibilizar PHP 8.3 ou superior, MariaDB 10.11 ou superior ou MySQL 8.0 ou superior, além de HTTPS. Estas são referências de compatibilidade e segurança, não uma garantia de desempenho.
Confirme que o fornecedor mantém versões com suporte de segurança e permite atualizar o PHP de forma controlada, depois de verificar a compatibilidade dos plugins e do tema. Nos projetos com WooCommerce, catálogos extensos ou muitas operações dinâmicas, a configuração e o comportamento da base de dados podem ter tanto peso como os recursos anunciados.
Que tipos de cache estão incluídos?
A palavra «cache» abrange mecanismos diferentes. Saber que um plano «inclui cache» é pouco esclarecedor se não for possível identificar quais são as camadas disponíveis e como estão configuradas.
| Camada | Função e limite principal |
|---|---|
| Cache de página | Reutiliza páginas já geradas, reduzindo trabalho do WordPress em pedidos adequados. Não deve servir indiscriminadamente conteúdo personalizado. |
| Cache de objetos persistente | Permite reutilizar determinados dados e resultados entre pedidos, reduzindo consultas repetidas; depende da aplicação e da configuração. |
| PHP OPcache | Guarda código PHP compilado em memória e evita parte do processamento repetido. Não corrige consultas lentas nem chamadas externas demoradas. |
| Cache do navegador e CDN | Pode reutilizar ficheiros estáticos, como imagens, CSS e JavaScript. Algumas CDN também guardam HTML, quando configuradas para esse efeito. |
Numa loja WooCommerce, o carrinho, a conta do cliente e a finalização da compra exigem regras de cache próprias, porque apresentam informação associada a cada utilizador. A configuração incorreta destas exceções pode causar falhas funcionais e até exposição de informação.
Serviços como a Cloudflare podem reduzir latência, pedidos ao servidor de origem e determinados tipos de tráfego indesejado. Mas a CDN não substitui o processamento PHP, a base de dados nem a capacidade necessária para operações dinâmicas.
Tarefas agendadas e limites que o plano não destaca
O desempenho não depende apenas das visitas. O WordPress também executa tarefas agendadas através do WP-Cron; o WooCommerce e vários plugins utilizam ainda o Action Scheduler para gerir operações em segundo plano. Sincronizações de produtos, envio de notificações, importações e integrações podem competir pelos mesmos recursos que atendem os visitantes.
O WP-Cron é normalmente desencadeado por pedidos ao website, pelo que a execução pode atrasar-se quando não há tráfego. Em projetos que exigem maior previsibilidade, interessa saber se o alojamento permite configurar um agendador de tarefas do sistema e acompanhar tarefas pendentes ou falhadas.
Há ainda limites menos visíveis nas fichas comerciais: utilização sustentada de CPU, memória por processo, operações de leitura/escrita, número de ficheiros (inodes), ligações, tempos de execução, transferências e tamanho de carregamentos. Esses limites são normais; o problema é desconhecer a sua existência ou as consequências de os atingir.
Sempre que possível, avalie o alojamento com operações representativas do projeto, não apenas com a rapidez de uma página inicial em cache. Numa loja, por exemplo, interessa observar a pesquisa, o painel de administração, a finalização da compra e as importações durante períodos de maior utilização.
Alojamento partilhado, VPS ou servidor dedicado?
Não existe uma hierarquia automática em que um servidor dedicado seja sempre a melhor escolha. Um bom alojamento partilhado e gerido pode funcionar melhor para um website empresarial do que uma VPS com mais recursos anunciados, mas sem configuração e manutenção adequadas.
No alojamento partilhado, vários clientes utilizam a mesma infraestrutura, geralmente com limites definidos por conta. Uma VPS oferece um ambiente virtual isolado e maior controlo, embora os recursos garantidos e a forma como a CPU é partilhada dependam do fornecedor. Um servidor dedicado disponibiliza uma máquina física para o projeto, mas só se justifica quando as necessidades e a operação o exigem.
A distinção entre alojamento gerido e autogerido é igualmente importante. Quem atualiza o sistema, configura os serviços, acompanha alertas, aplica correções de segurança e responde a incidentes? Num serviço gerido, parte dessas responsabilidades pode estar incluída; numa solução autogerida, ficam a cargo da empresa ou do seu parceiro técnico.
Mais controlo é útil quando existe capacidade para o exercer. Caso contrário, pode traduzir-se em mais custos e risco operacional.
Segurança, recuperação e suporte técnico
Cópias de segurança e ambiente de testes
Antes de contratar, confirme se as cópias de segurança incluem ficheiros e base de dados, com que frequência são realizadas, durante quanto tempo ficam disponíveis e se existe uma cópia fora da infraestrutura principal. Verifique ainda os custos de recuperação, a possibilidade de restauro autónomo e se o procedimento pode ser testado.
A existência de cópias de segurança não prova que um website possa ser recuperado com segurança. Numa loja online, restaurar uma base de dados antiga pode eliminar encomendas ou alterações posteriores à cópia. O plano de recuperação deve ter em conta a atividade do negócio.
Um ambiente de testes (staging) facilita a validação de atualizações e alterações antes de chegarem ao website público. Convém, porém, conhecer o processo de cópia e publicação: dados pessoais, envio acidental de emails e substituição de encomendas recentes são riscos que precisam de controlo.
Segurança, visibilidade e âmbito do suporte
Um alojamento empresarial deve assegurar HTTPS com certificados válidos, manutenção do ambiente do servidor, isolamento adequado entre contas, controlo de acessos e medidas de resposta a incidentes. Ter uma firewall não dispensa nenhuma destas responsabilidades.
É igualmente útil dispor de registos de erros e métricas sobre PHP, CPU, memória, base de dados, espaço e tarefas agendadas. Sem esta informação, torna-se mais difícil distinguir um problema do servidor de uma falha num plugin, tema ou integração.
O anúncio «suporte 24/7» também deve ser interpretado com cuidado. Um fornecedor pode resolver problemas de rede, certificados e disponibilidade do servidor, mas não diagnosticar código WordPress ou falhas de uma loja WooCommerce. A fronteira entre o suporte do alojamento e o trabalho da equipa técnica deve estar definida, sobretudo quando o site está acessível, mas uma operação crítica deixou de funcionar.
Localização, crescimento e custo real
A proximidade geográfica influencia a latência. Para um website com público sobretudo em Portugal, um centro de dados europeu costuma ser uma opção sensata, sem ter necessariamente de estar em território nacional. A qualidade da rede, a CDN e o tipo de pedidos são tão relevantes como a localização: uma CDN aproxima conteúdo em cache, mas não elimina o tempo de processamento na origem.
Considere também a evolução do projeto. Se o número de encomendas ou integrações aumentar, será possível ampliar os recursos ou mudar de plano sem uma migração complexa? E, se for necessário sair do fornecedor, conseguirá obter ficheiros, base de dados e cópias de segurança, bem como manter o controlo do domínio e do DNS?
O email profissional e o envio de mensagens transacionais não precisam de estar associados ao alojamento web. Separar serviços pode facilitar a gestão e reduzir dependências, desde que as integrações fiquem bem configuradas.
Por fim, compare o custo total, e não apenas a mensalidade. Um plano de 20 € pode exigir trabalho de administração e serviços adicionais que outro de 80 € já inclui; o preço mais elevado, por sua vez, não garante melhor desempenho. Verifique renovação, manutenção, cópias de segurança, monitorização, apoio técnico, migração e recuperação.
Lista de verificação antes de contratar
Ao pedir propostas, procure respostas concretas a estas questões:
- Utilização: o plano foi avaliado para as operações reais do website, incluindo utilizadores autenticados e períodos de maior carga?
- Ambiente técnico: quais são as versões disponíveis de PHP e base de dados? Existem OPcache e opções adequadas de cache de página e de objetos?
- Capacidade e limites: que recursos são efetivamente disponibilizados, quantos processos PHP podem executar e o que acontece quando se atingem os limites?
- Operações agendadas: é possível configurar tarefas do sistema e verificar falhas no WP-Cron ou no Action Scheduler?
- Recuperação: qual é a frequência e retenção das cópias de segurança, onde são guardadas e como se testa o restauro?
- Gestão e segurança: quem mantém o servidor atualizado, acompanha alertas e responde a incidentes?
- Diagnóstico e suporte: existem registos e métricas acessíveis? O suporte cobre apenas a infraestrutura ou também problemas do WordPress?
- Evolução e saída: como se aumentam recursos, como se migra para outro fornecedor e quais são os custos efetivos de renovação e serviços adicionais?
Conclusão
Escolher alojamento para WordPress exige relacionar a utilização real do website com a capacidade do servidor, os limites aplicados e a qualidade da operação. CPU, RAM e NVMe são indicadores úteis, mas não substituem uma avaliação dos pedidos dinâmicos, da base de dados, das tarefas agendadas e da recuperação em caso de falha.
O melhor alojamento não é necessariamente o plano com mais recursos. É o que oferece capacidade adequada, responsabilidades claras, meios de diagnóstico e um caminho de crescimento compatível com o projeto.
