Alojamento WordPress NVMe: desempenho e escolha
Um alojamento WordPress NVMe pode acelerar sites com muitas consultas à base de dados, mas não garante uma boa pontuação no PageSpeed. A resposta do WordPress soma rede, PHP, base de dados, cache e, só depois, disco.

Os dados de cada fornecedor estão na página de hosting NVMe; aqui ficam o método e os custos.
O que limita a velocidade do WordPress
Quando um visitante pede uma página fora da cache, o servidor executa o núcleo do WordPress, o tema e os plugins, faz dezenas de consultas à base de dados e só então devolve HTML. Na maioria dos sites, PHP e consultas dominam este tempo. O disco entra quando o código não está no OPcache ou os dados não estão em memória. Por isso, um plugin mal escrito anula qualquer vantagem de armazenamento.
5 tipos de sites WordPress
- Blogue ou revista. Conteúdo público, fácil de pôr em cache. O essencial é a cache de página e a otimização de imagens; o NVMe acrescenta pouco à experiência de quem lê os artigos.
- Site institucional. Poucas páginas e formulários de contacto. Um plano de entrada com bom suporte e centro de dados próximo serve; atenção às cópias de segurança e às atualizações.
- Loja WooCommerce. Carrinho, checkout e conta não usam cache de página. Cada encomenda escreve na base de dados, e aqui NVMe, PHP workers e cache de objetos fazem diferença mensurável.
- Área de membros ou cursos. Utilizadores autenticados recebem páginas personalizadas. É o cenário mais exigente em workers e RAM, onde um plano cloud ou VPS gerido costuma fazer sentido.
- Multisite ou agência. Muitos sites partilham os recursos da mesma conta, e o pico de um afeta os restantes. Procure limites claros de CPU e I/O e a possibilidade de separar sites críticos.
Caching, PHP workers e base de dados
Há três níveis de cache: de página (HTML final, via LiteSpeed Cache, WP Super Cache ou servidor), de objetos (consultas em Redis ou Memcached) e OPcache (código PHP compilado). Com os três ativos, a maioria das visitas nem chega ao disco.

Os PHP workers são os processos que geram páginas fora da cache; cada pedido ocupa um até terminar, e quando estão todos ocupados os seguintes entram em fila. Na base de dados, controle as opções em autoload, elimine transientes expirados e confirme índices: uma consulta sem índice é lenta em qualquer disco.
Exemplo: capacidade de PHP workers
Pressupostos ilustrativos: um plano com 6 workers e páginas sem cache que demoram 0,5 s a gerar. Capacidade teórica máxima: 6 ÷ 0,5 = 12 pedidos por segundo. Com cache de objetos, o tempo desce para 0,4 s e a capacidade sobe para 6 ÷ 0,4 = 15. Um disco mais rápido só altera esta conta na fração do tempo que é espera de I/O.
Como testar o alojamento
Use o período de reembolso para medir. A tabela explica o que cada métrica mostra e o que não prova.
| Métrica | Método de teste | O que significa | O que não prova |
|---|---|---|---|
| TTFB | curl ou DevTools, 10 ou mais pedidos, com e sem cache | Tempo até o servidor começar a responder | Velocidade percebida total; que o disco seja a causa |
| LCP (Core Web Vitals) | PageSpeed Insights e dados CrUX | Tempo até surgir o maior elemento visível | Qualidade do alojamento isolada; depende muito do front-end |
| Pedidos por segundo | k6 em staging, com carga gradual | Capacidade antes de se formar fila | Comportamento com tráfego real e CDN |
| Tempo de consultas | Query Monitor por página | Peso da base de dados na resposta | Velocidade do disco, se os dados vêm da memória |
| Uso de CPU, RAM e I/O | Painel de recursos (cPanel/hPanel) | Se a conta atinge os limites do plano | Desempenho do hardware do servidor |
| Tempo de backup ou restauro | Cronometrar um ficheiro de tamanho conhecido | Débito real de I/O da conta | Latência de consultas pequenas |
Plano de teste em 10 passos

- Crie uma cópia de staging. Teste com o mesmo tema, plugins e volume de dados do site real. Um WordPress vazio responde depressa em qualquer servidor e não serve para comparar alojamentos.
- Registe o ponto de partida. Meça TTFB, LCP e tempo de consultas no alojamento atual, nas mesmas páginas e horários que vai usar depois. Sem base de comparação, os números novos não dizem nada.
- Iguale PHP e OPcache. Use a mesma versão de PHP nos dois ambientes, de preferência 8.3 ou mais recente, com OPcache ativo. Uma diferença de versão pode explicar mais do que o disco.
- Meça o TTFB sem cache. Desative a cache de página ou use páginas excluídas, como o carrinho. Faça pelo menos dez pedidos seguidos e registe a mediana, não o melhor valor.
- Meça o TTFB com cache. Ative a cache e repita. Se o valor cai muito, a geração de páginas é o gargalo principal e a cache deve ser prioridade, independentemente do disco.
- Analise as consultas. Com o Query Monitor, identifique consultas lentas e plugins pesados. Corrija o que puder antes de concluir que precisa de um plano mais caro ou de NVMe.
- Faça um teste de carga moderado. Com k6, aumente gradualmente os utilizadores virtuais no staging e observe quando o TTFB começa a subir. Esse ponto indica o limite de workers ou de CPU.
- Cronometre um backup. Divida o tamanho em MB pelo tempo em segundos. O resultado mostra o débito de I/O real da conta e se corresponde ao limite anunciado pelo fornecedor.
- Verifique o painel de recursos. Depois dos testes, veja se houve faltas de CPU, memória ou I/O. Faltas repetidas indicam um plano pequeno para o site, seja ele SSD ou NVMe.
- Repita em horários diferentes. Teste de manhã, à tarde e à noite durante vários dias. No alojamento partilhado a carga dos vizinhos varia, e só a repetição mostra a estabilidade real.
Dez medições de TTFB seguidas a partir do terminal (endereço de exemplo):
for i in $(seq 1 10); do
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://staging.example.com/carrinho/
done
Custos e renovação
O custo real vê-se na renovação. Com dados oficiais da Dominios.pt (12/10/2026): o Startup NVMe custa 0,70 €/mês + IVA no 1.º ano, em contrato anual, e 6,95 €/mês + IVA sem promoção. Em dois anos: (0,70 × 12) + (6,95 × 12) = 8,40 € + 83,40 € = 91,80 € sem IVA, ou 112,91 € com IVA a 23 %. Na SiteGround, o StartUp passa de 2,99 € para 15,99 €/mês sem IVA. Inclua extras pagos à parte.
Se o site é de conteúdo e o orçamento é curto, um bom plano de SSD hosting pode chegar; a comparação de alojamento NVMe vs SSD ajuda a decidir.
Para quem é o alojamento WordPress NVMe
Adequa-se a
- Lojas WooCommerce com encomendas diárias.
- Áreas de membros, cursos e comunidades.
- Agências com vários sites WordPress na mesma conta.
Não se adequa a
- Blogues pequenos com cache de página.
- Quem espera uma pontuação de PageSpeed garantida.
- Sites com plugins pesados ainda por otimizar.
Decisão rápida
- ABlogue ou site institucional → plano de entrada com PHP recente e cache; NVMe é opcional.
- BLoja WooCommerce → NVMe, workers e RAM publicados e cache de objetos.
- CMembros ou tráfego autenticado alto → cloud ou VPS gerido com NVMe.
Calcule dois anos com IVA e compare os limites de PHP workers na página oficial.
Resumo
Um alojamento WordPress NVMe ajuda sobretudo lojas e áreas de membros, mas PHP, cache, workers e RAM decidem mais a velocidade. Teste com método, não prometa pontuações sem medir e compare custos de renovação com IVA.
FAQ
Que pontuação de PageSpeed posso esperar com NVMe?
Ninguém pode prometer um valor sem medir o seu site. A pontuação depende sobretudo de imagens, JavaScript, CSS e tema; o alojamento influencia o TTFB, só uma parte do LCP. Meça antes e depois, nas mesmas páginas.
Preciso de LiteSpeed para ter um WordPress rápido?
Não é obrigatório. LiteSpeed com LSCache é eficaz, mas Nginx com FastCGI cache ou um bom plugin de cache em Apache também servem páginas sem executar PHP. O importante é a cache de página bem configurada.
Quantos PHP workers precisa uma loja WooCommerce?
Depende do tráfego sem cache e do tempo de geração de cada página. Use a regra simples: capacidade = workers ÷ tempo médio por pedido. Uma loja pequena vive com poucos workers; campanhas e checkout simultâneo pedem mais.
A cache de objetos Redis está incluída nos planos partilhados?
Depende do fornecedor e do plano; nem sempre existe no partilhado de entrada. Confirme na página do plano ou com o suporte antes de contratar, sobretudo se gere uma loja WooCommerce ou uma área de membros.
Posso migrar o WordPress sem tempo de inatividade?
Na maioria dos casos, sim: copie ficheiros e base de dados, teste com um domínio temporário ou o ficheiro hosts e só depois altere o DNS. Reduza o TTL uns dias antes para acelerar a mudança.
