Medimos ~100 sites WordPress. A marca do host quase não importou — o cache sim
Publicado 30 de outubro de 2026
As pessoas escolhem host de WordPress como escolhem marca de carro — pela reputação, por quem todo mundo usa. Então fui ver se a reputação aparece nos números. A gente acompanha perto de cem sites nos stacks de sempre, e todos têm o PageSpeed medido. Agrupei pelo que de fato rodam e olhei as notas de mobile.
O nome do host se mostrou um previsor fraco. O que o site tinha rodando na frente, um previsor forte.
Os grupos, em números reais
Nota de performance mobile e field TTFB (o tempo que um visitante real espera pelo primeiro byte), na média de cada stack:
| Stack | Sites | Nota mobile | Field TTFB |
|---|---|---|---|
| nginx + WP Rocket | 20 | 79 | 702 ms |
| WP Engine + uma segunda camada de cache | 7 | 77 | 1.577 ms |
| WP Engine (EverCache) | 35 | 65 | 1.352 ms |
| nginx, sem page cache | 18 | 60 | 2.474 ms |
| Cloudflare na frente, sem cache de origem | 10 | 60 | 1.373 ms |
O que salta aos olhos
O grupo mais rápido não é o host mais chique — é um stack aberto bem ajustado. nginx puro com o WP Rocket fazendo cache de página inteira ficou em primeiro, e pela margem que importa: primeiro byte em 702 ms, menos de um terço do grupo sem cache. Sem precisar do prêmio da hospedagem gerenciada.
O stack gerenciado mais popular ficou no meio. WP Engine no EverCache — o maior grupo, com 35 sites — tirou 65 na média. Não é ruim, mas não é a vitória automática que a marca sugere. Você está pagando por confiabilidade e suporte, que são reais; você não está comprando um site rápido garantido.
Sem page cache é onde desanda. Os sites nginx sem cache tiraram 60 na média e um primeiro byte de 2,5 segundos — o pior TTFB do conjunto todo. Cada requisição montava a página do zero, por visitante.
Um CDN não salva uma origem sem cache. O grupo “Cloudflare na frente, nada cacheado atrás” teve o pior LCP de laboratório de todos — o CDN não entrega o que a origem não cacheia, então o primeiro byte lento só acontece em outro endereço.
A lição de verdade
Alinhando tudo, a divisão é limpa: os dois grupos mais rápidos tinham cache de página inteira de verdade; os dois mais lentos não tinham nenhum. A marca do host embaralhou um pouco a ordem. O cache decidiu.
Um adendo que merece aviso: sete sites rodavam dois caches de página ao mesmo tempo — um cache do host e o WP Rocket empilhados. Não prejudicou a nota aqui, mas é uma arma apontada pro próprio pé. Dois caches discordam sobre quando uma página está velha, e o bug que isso gera — uma mudança que você publicou e simplesmente não aparece — é um inferno de rastrear. Você quer um cache, configurado de propósito.
Como checar o seu
Seu primeiro byte é a pista. Rode o site no PageSpeed, ou só curl -w "%{time_starttransfer}\n" -o /dev/null -s https://seusite.com. Se der consistentemente mais de um segundo, você provavelmente não tem um page cache funcionando, não importa o que o host cobra. O Site Doctor reporta o stack e o field TTFB em cada scan, pra você ver onde de fato está — mas a linha de curl acima é de graça e te diz quase tudo.