WordPress

Alojamento WordPress NVMe: desempenho e escolha

Atualizado e verificado: 12 de outubro de 2026 · Por: Redação Hosting NVMe Portugal

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.

NVMe-wordpress-hosting
Resposta curta: para WordPress, escolha primeiro PHP recente, cache de página, PHP workers suficientes e RAM para a base de dados; o NVMe é uma vantagem adicional, mais útil em WooCommerce e áreas de membros. Teste no período de reembolso com o plano de 10 passos abaixo e desconfie de pontuações prometidas.

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

  1. 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.
  2. 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.
  3. 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.
  4. Á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.
  5. 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.

caching-PHP-workers-and-database

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étricas para testar alojamento WordPress NVMe
MétricaMétodo de testeO que significaO que não prova
TTFBcurl ou DevTools, 10 ou mais pedidos, com e sem cacheTempo até o servidor começar a responderVelocidade percebida total; que o disco seja a causa
LCP (Core Web Vitals)PageSpeed Insights e dados CrUXTempo até surgir o maior elemento visívelQualidade do alojamento isolada; depende muito do front-end
Pedidos por segundok6 em staging, com carga gradualCapacidade antes de se formar filaComportamento com tráfego real e CDN
Tempo de consultasQuery Monitor por páginaPeso da base de dados na respostaVelocidade do disco, se os dados vêm da memória
Uso de CPU, RAM e I/OPainel de recursos (cPanel/hPanel)Se a conta atinge os limites do planoDesempenho do hardware do servidor
Tempo de backup ou restauroCronometrar um ficheiro de tamanho conhecidoDébito real de I/O da contaLatência de consultas pequenas

Plano de teste em 10 passos

10-step-test-plan
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.