Hosting WordPress em 2026, cloud vs edge vs tradicional

Em 2026, «servidor» raramente significa uma caixa física num bastidor. É um recurso distribuído: origem, cache, workers e rede. Para WordPress, a arquitetura de hosting define velocidade, resiliência e o custo operacional da equipa, mais do que o tema ou o page builder.

Referências úteis enquanto lê: administração avançada no servidor, cache na Cloudflare e page experience no Search Central.

#Hosting gerido, cloud ou edge para WordPress

Nenhum modelo «mata» os outros. Um media site em Lisboa com leitores no Brasil e na Alemanha precisa de edge. Uma intranet WordPress só em Porto pode viver num gerido bem afinado.

#Vantagens e limites do hosting WordPress gerido

O gerido de 2026 (contentores, staging com um clique, WAF de origem) está longe do shared hosting de há uma década.

Pontos fortes

• Backups e restores testáveis sem inventar scripts
• Updates de core/PHP acompanhados pelo fornecedor
• Support que fala WordPress, não só Linux genérico
• Staging e clonagem de ambientes

Pontos fracos

• Teto de PHP workers e I/O quando a loja dispara no Black Friday
• Menos liberdade para sidecars (filas, search externos) sem add-ons
• Preço por «facilidade» em vez de por milhão de pedidos

Sinais de que ainda serve

• TTFB estável sob carga editorial normal
• Cache de página (plugin ou servidor) com hit ratio alto em páginas públicas
• Object cache (Redis/Memcached) disponível e ligado

Num projeto PT-PT com catálogo WooCommerce moderado, um gerido com Redis e page cache cobriu o pico de campanha sem migrar para Kubernetes. O trabalho útil foi reduzir plugins e consultas N+1, não trocar de logótipo no painel do host.

#WordPress na cloud com AWS, GCP ou Azure

Correr em AWS, GCP, Azure ou equivalente com contentores ou VMs auto-escaláveis.

Pontos fortes

• Escala horizontal de web/PHP sob pico
• Separação clara: web, base de dados gerida, object cache, storage de media
• Observabilidade (métricas de fila, saturação de CPU, slow queries)

Pontos fracos

• Precisa de alguém que entenda redes, IAM e backups
• Fácil gastar em recursos ociosos se o auto-scale estiver mal calibrado
• WordPress não é «stateless» por magia: uploads e cron precisam de desenho

Checklist cloud mínimo

1. Base de dados gerida com backups pontuais e PITR se o risco o exigir
2. Object cache partilhado entre instâncias
3. Media em object storage com CDN à frente
4. PHP workers dimensionados pelo tempo de pedido, não pelo «número de visitas»
5. Cron real (sistema) em vez de só wp-cron disparado por tráfego

#O que o edge hosting resolve no WordPress

Edge reduz latência porque o conteúdo cacheável vive perto do utilizador. PHP e MySQL/MariaDB continuam na origem na maioria dos sites editoriais.

O que o edge faz bem

• Cache de HTML para anónimos
• Assets (CSS, JS, imagens) com TTL longo e versionamento
• Mitigação de bots e WAF antes da origem
• Terminação TLS perto do cliente

O que o edge não resolve sozinho

• Checkout WooCommerce altamente dinâmico sem regras de bypass
• Admin (wp-admin): deve ir à origem com cuidado
• Consultas lentas na base de dados
• Temas que geram HTML único por visitante sem estratégia de cache

Arquiteturas «WordPress no edge» sem origem clássica existem (workers, stores externos), mas são um produto à parte. Para a maior parte das empresas PT e EU, o padrão vencedor é origem estável + edge inteligente.

#Que versões de PHP e base de dados o WordPress recomenda

Antes de comparar fornecedores, confirme os requisitos de base. Na página de requisitos, o WordPress.org recomenda PHP 8.3 ou superior, MySQL 8.0 ou superior ou MariaDB 10.11 ou superior, e suporte de HTTPS. São recomendações para o alojamento, não uma garantia de que todos os seus plugins suportam a mesma versão.

Na prática, daqui saem três perguntas para um fornecedor novo: que versão de PHP corre hoje em produção, quando chega a seguinte e se é possível escolher a versão por ambiente, para testar a nova em staging antes de mudar a produção. Um plano gerido que o prende a um ramo antigo de PHP deixa-lhe um projeto de atualização no calendário do fornecedor, não no seu.

#Quantos PHP workers o WordPress precisa

Um PHP worker é um processo (ou thread, em algumas stacks) que trata um pedido de cada vez. O número de workers vezes o tempo médio de processamento define o teto de pedidos por segundo antes de a fila crescer e o TTFB subir.

Exemplo de cálculo: uma loja com 20 workers e 400 ms de tempo médio de PHP aguenta cerca de 50 pedidos por segundo antes de formar fila. Se cada página de produto sem cache de página demora 800 ms porque os plugins chamam APIs externas, a capacidade cai para metade. A solução raramente é «mais plugins»; costuma ser menos chamadas síncronas, melhor cache de página e mais workers só onde a medição o justifica.

Medidas práticas:

• Meça o tempo de fila do PHP-FPM (slowlog, APM) antes de duplicar workers.
• Separe o admin e o cron do frontend com pools próprios, se a plataforma o permitir.
• Não deixe o wp-cron correr em cada pedido do frontend; use o cron do sistema.
• Mantenha sessões e ficheiros temporários fora de discos locais lentos quando vários nós partilham a carga.

#Como afinar pm.max_children no PHP-FPM

Num servidor próprio ou na cloud, os workers são uma definição que lhe pertence. O manual do PHP para o FPM descreve três modos para pm: static dá um número fixo de processos filho, dynamic ajusta esse número entre pm.start_servers, pm.min_spare_servers e pm.max_spare_servers, e ondemand só lança processos quando chegam pedidos. Comum a todos é o pm.max_children, que segundo o manual «define o limite do número de pedidos simultâneos que serão servidos» (tradução própria).

Na prática, o teto é a memória: cada processo PHP ocupa RAM, e se pm.max_children vezes o tamanho típico de um processo ultrapassa a memória livre, troca fila por swap. Para ver onde se perde tempo, defina request_slowlog_timeout para alguns segundos. O FPM passa a escrever um backtrace de PHP no ficheiro slowlog por cada pedido mais lento, e vê qual plugin ou chamada externa está a prender o worker.

#Quando usar Redis ou Memcached no WordPress

O object cache guarda os resultados das chamadas wp_cache_* e objetos persistentes entre pedidos. Sem backend persistente, a cache só vive em memória durante um pedido. A documentação do WP_Object_Cache di-lo sem rodeios: «Por omissão, o object cache não é persistente» (tradução própria), e nada sobrevive entre carregamentos de página até instalar um backend persistente como drop-in em wp-content. Com Redis ou Memcached, opções, pontos quentes de postmeta e transients são reutilizados entre workers.

Ajuda mais em WooCommerce com muitos produtos e variações, em páginas com consultas WP_Query pesadas que não entram na cache de página, e em multisite ou sites com muitos plugins que leem opções repetidamente. Ajuda pouco em landings estáticas já cacheadas por inteiro no CDN, com plugins que contornam o object cache ou escrevem objetos enormes, e quando a base de dados já é o gargalo em checkouts com muitas escritas.

Defina TTLs de propósito, limpe chaves agressivas no deploy e acompanhe o hit ratio: «o Redis está ligado» sem percentagem de acertos é teatro. Mantenha o Redis na mesma região do PHP; um salto do object cache para outro continente custa mais do que poupa.

#O que a Cloudflare põe em cache por omissão à frente do WordPress

Muita gente assume que um CDN à frente do WordPress põe páginas inteiras em cache automaticamente. A própria documentação da Cloudflare sobre o comportamento de cache por omissão diz outra coisa: «O CDN da Cloudflare não põe HTML nem JSON em cache por omissão» (tradução própria). Sem regras próprias, os ficheiros entram em cache pela extensão, como imagens, CSS, JS, fontes e PDF, enquanto o HTML gerado pelo PHP vai à origem sempre.

A mesma página lista o que impede a cache mesmo depois de a ativar: um cabeçalho Set-Cookie vindo da origem, Cache-Control: private, no-store, no-cache ou max-age=0, e qualquer método de pedido que não seja GET. Para pôr HTML em cache, a Cloudflare recomenda uma Cache Rule que guarde tudo, ou Workers para lógica própria.

Para o WordPress, a consequência é que um plugin que define um cookie em todas as páginas torna a cache edge inútil sem aviso. Verifique os cabeçalhos de resposta de uma página de produto anónima antes de concluir que «o CDN não ajuda».

#Que páginas WooCommerce se podem pôr em cache no edge

O WooCommerce mistura páginas de catálogo cacheáveis com caminhos muito dinâmicos: carrinho, checkout, A minha conta, endpoints REST de gateways de pagamento, webhooks da SIBS, do MB WAY ou da Stripe. Uma cache edge que serve HTML anónimo para /produto/ está bem. Uma cache edge que serve o mesmo HTML a um utilizador com artigos no carrinho destrói a conversão.

A própria documentação do WooCommerce sobre plugins de cache define o limite: carrinho, A minha conta e checkout devem ficar fora da cache porque mostram informação do cliente concreto. A lista de cookies indicada é woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed e store_notice[notice id]. Se a camada de cache oferecer cache de base de dados, a documentação sugere também excluir _wc_session_. Use esta lista como ponto de partida da regra de bypass no edge, em vez de adivinhar.

Nunca ponha em cache pedidos POST, pedidos de carrinho via admin-ajax nem callbacks de pagamento, e mantenha a origem perto das integrações de pagamento e ERP: o edge não «muda» por magia a lógica PCI ou de sessão. Meça o TTFB em acertos e falhas de cache. O guia do web.dev sobre TTFB soma redirecionamentos, DNS, ligação e TLS e a espera até ao primeiro byte, e trata 0,8 segundos ou menos como bom e acima de 1,8 segundos como fraco, como orientação aproximada.

#RGPD e localização dos dados ao escolher hosting WordPress

Escolher hosting é também escolher um subcontratante. Antes de assinar, confirme a região principal da base de dados e dos ficheiros (por exemplo UE/EEE), lembrando que o «anycast global» de um CDN não é o mesmo que a localização dos dados pessoais; um acordo de tratamento de dados com lista clara de subcontratantes ulteriores; a base de transferência se os dados saírem do EEE (cláusulas contratuais-tipo, medidas suplementares); o que os logs e o APM guardam (emails, IP, números de encomenda) e durante quanto tempo; e quem do suporte tem acesso por SSH ou SFTP, e se isso fica registado.

Para fornecedores dos EUA existe mais uma base de transferência: a 10 de julho de 2023, a Comissão Europeia adotou uma decisão de adequação para o EU-US Data Privacy Framework. Segundo a página da Comissão sobre transferências de dados para os EUA, só abrange empresas que participam nesse quadro. Confirme se o seu fornecedor concreto de hosting ou CDN consta da lista de participantes, em vez de assumir que «os EUA estão cobertos».

Computação edge sobre dados pessoais (testes A/B, personalização) é tratamento. Chaves de cache com o ID do utilizador em centenas de pontos de presença aumentam a superfície de ataque. Mantenha o conteúdo pessoal na origem ou em camadas de vida curta e chaves bem controladas.

#Como substituir o wp-cron pelo cron do sistema

O WP-Cron não corre por relógio. É verificado quando alguém carrega uma página, por isso as tarefas agendadas atrasam-se em sites calmos e competem com os visitantes em sites movimentados. A documentação para programadores do WordPress mostra a solução em dois passos. Primeiro desliga o disparo por tráfego em wp-config.php:

define( 'DISABLE_WP_CRON', true );

Depois o agendador do sistema chama wp-cron.php com um pedido web. A documentação usa */15 * * * * como exemplo de 15 em 15 minutos e mostra uma chamada wget contra wp-cron.php. Escolha o intervalo pelas tarefas reais: uma loja com renovações de subscrições precisa de um intervalo mais curto do que um blog com artigos agendados. Num hosting gerido, pergunte como o fornecedor corre o cron antes de mudar algo, porque alguns já o fazem por si.

#Como montar CI/CD para o hosting WordPress

Sem CI/CD, o staging torna-se «FTP manual na quinta à noite». O código, os temas, os plugins próprios e as definições de infraestrutura devem passar por um pipeline: Git como fonte de verdade; build e testes em CI (PHPStan ou Psalm, PHPUnit para plugins próprios, lint do tema); deploy para staging com a mesma versão de PHP e as mesmas extensões da produção; smoke tests à página inicial, a uma página de produto, ao adicionar ao carrinho e ao login; produção com release atómico (novo diretório de release mais symlink) ou imagem de contentor com healthcheck; e migrações de base de dados por WP-CLI ou scripts controlados, nunca «editar em produção».

Segredos (chaves de API, palavras-passe da base de dados) ficam num vault ou no cofre de segredos da plataforma, não no Git. A purga do object cache e do CDN deve disparar depois do deploy, não depender de alguém se lembrar de limpar o Redis. No edge, faça deploy da configuração de Workers e do CDN a partir do mesmo repositório do código WordPress, com revisão das regras de cache que podem partir o checkout.

#Que hosting WordPress escolher para o seu site

#Como avaliar tráfego e equipa antes de escolher hosting

1. Mapa de tráfego: países, logged-in ratio, picos sazonais
2. Inventário de dinamicidade: loja, membership, personalização
3. Capacidade ops: quem faz deploy às 23h?
4. Prova: staging sob carga sintética antes do cutover
5. Plano B: rollback de DNS e de cache em minutos

Escolher o host é cerca de um quinto do trabalho. O resto é configuração: Nginx/OpenLiteSpeed, Redis, regras de cache, PHP versioning, e disciplina de plugins.

#Que hosting usar para WooCommerce, media sites e SaaS em Portugal

Uma loja WooCommerce com a maior parte dos clientes em Portugal e Espanha, picos em campanhas sazonais, e uma equipa de duas pessoas sem SRE: comece em gerido com Redis, page cache e staging. Adicione edge para assets e HTML anónimo quando o TTFB internacional doer. Não comece em Kubernetes «porque o pedido de proposta falava em cloud».

Um media site com artigos longos, comentários moderados e leitores no Brasil: priorize edge de HTML para anónimos, origem na EU por compliance, e object cache agressivo. Comentários e pré-visualizações precisam de bypass documentado. Um intranet WordPress só para colaboradores num único escritório: edge ajuda pouco; foque isolamento, VPN ou SSO, e backups testados.

Um SaaS com WordPress só no marketing site e a app noutro stack: trate o marketing como site cacheável quase estático na borda, com formulários e thank-you pages como exceções. Não misture a app e o CMS no mesmo auto-scale sem necessidade, porque os padrões de carga são diferentes e os rollbacks também.

#Custo real do hosting WordPress gerido, cloud e edge

O preço do painel é a parte visível. O custo real inclui horas de quem responde às 23h, tempo a diagnosticar 502 sem logs, e risco de um pico sem workers. Gerido compra horas de equipa. Cloud compra flexibilidade e exige disciplina. Edge compra latência geográfica e exige regras claras. Escolha pelo custo total de posse operacional, não pelo slide do fornecedor.

#Como medir TTFB e cache hit ratio no hosting

1. TTFB por região: meça em PT, BR, DE, não só no painel do host
2. Cache hit ratio: HTML e assets em separado
3. Fila / saturação de PHP workers: picos de admin-ajax e cron
4. Tempo de consulta p95: object cache ligado de verdade?
5. Taxa de erro 5xx na origem durante deploy

Se o TTFB na origem já é alto, edge só esconde o problema para visitantes em cache. Corrija consultas e plugins primeiro; veja os nossos serviços de otimização de velocidade WordPress.

#Como migrar WordPress para outra arquitetura de hosting

Trocar de arquitetura é um projeto, não um toggle. Inventarie DNS, certificados, cron, e-mail transacional, e webhooks de pagamento. Clone para staging na arquitetura nova. Corra uma passagem de carga sintética nas URLs quentes. Só depois mude TTL de DNS e prepare rollback. Limpe cache de edge em coordenação com o cutover: HTML antigo com URLs de staging é um clássico embaraçoso.

Documente regras de bypass: carrinho, checkout, my-account, preview, admin. Sem isso, o edge «acelera» o site ao partir vendas. Meça hit ratio na primeira semana e ajuste TTLs; valores agressivos demais escondem publicações editoriais, valores tímidos demais gastam origem à toa.

#O que verificar antes de mudar o DNS do WordPress

Antes de apontar DNS definitivo, confirme: PHP na versão suportada pelo WordPress e pelos plugins críticos; object cache autenticado entre nós; media a servir pela CDN com URLs canónicas corretas; cron a correr por sistema e não só por visitas; alertas de 5xx e de saturação de workers; bypass de cache para preview e para fluxos de compra; e um restore de backup ensaiado na semana anterior. Sem restore ensaiado, o backup é ficção.

Na borda, confirme TTL por tipo de conteúdo, purga automatizada no publish, e que Set-Cookie não está a destruir hit ratio em páginas que deveriam ser públicas. Uma origem saudável com edge disciplinado supera uma origem cara mal configurada.

Resumo operacional: meça antes de migrar, ensaie o restore, documente o bypass, e só depois discutir o logótipo do fornecedor. Arquitetura boa é a que a equipa consegue operar sob stress, não a que ganha um slide de marketing.

#Erros comuns de cache e cloud no WordPress

• Migrar para cloud «porque é moderno» sem object cache partilhado entre nós
• Pôr tudo em cache na borda e partir o carrinho
• Confiar em page-cache de plugin + CDN sem documentar regras de bypass
• Deixar wp-cron na origem saturada enquanto o edge serve HTML antigo
• Escolher edge sem logs de origem legíveis quando algo falha

#Conclusão

Em 2026 não existe um único «melhor hosting WordPress». Existe o melhor encaixe entre audiência, picos, equipa e orçamento operacional. Gerido tradicional continua válido. Cloud brilha com picos e controlo. Edge multiplica o alcance geográfico quando a origem já está sã.

Não construa um site corporativo em solo instável. Meça TTFB e hit ratio, depois escolha a arquitetura, e não o contrário. Se a origem está doente, a borda só maquila o sintoma. Se a equipa não opera cloud, um gerido bem afinado supera um cluster mal amado.

O hosting atual atrasa conversões ou deploys? Peça uma auditoria de infraestrutura à WPPoland e saia com um plano escrito, não com um slogan. Levamos tráfego real, inventário de dinamicidade e capacidade ops para a mesa, e só depois falamos de fornecedor.

Do lado da entrega mantemos este tema sob auditoria Core Web Vitals.