Site lento no PageSpeed é o sinal mais claro de quando migrar para Cloudflare no WordPress: o momento chega quando o PageSpeed Insights aponta LCP e TTFB ruins nos estáticos, enquanto a origem ainda gera HTML lento. A CDN reduz latência de DNS, SSL e arquivos na borda, mas não substitui PHP-FPM, plugins ou MySQL saturados. Para migrar com segurança, siga estes passos:
- Meça o TTFB na origem sem CDN e compare com o relatório do Google.
- Faça backup completo do WordPress e anote os nameservers atuais.
- Aponte o DNS para a Cloudflare com proxy laranja só no A/CNAME do site.
- Defina SSL Full (strict) e exclusões de cache em wp-admin, login e cookies.
- Ative cache de estáticos; só depois teste cache de HTML anônimo.
- Reavalie LCP, CLS e INP no PageSpeed com o mesmo hostname e proxy ativo.
Pré-requisitos
Backup íntegro e acesso ao painel DNS são obrigatórios antes de qualquer troca de nameserver. Sem isso, um apontamento errado derruba o site e o e-mail no mesmo instante.
- Acesso de administrador ao WordPress e ao painel da hospedagem (cPanel, DirectAdmin ou SSH).
- Conta Cloudflare no plano gratuito ou superior, com o domínio seudominio.com.br adicionado.
- PHP 8.4+ na origem, com OPcache ativo; WordPress e plugins atualizados.
- Certificado válido na origem (Let's Encrypt ou equivalente) para SSL Full (strict).
- Permissão para alterar nameservers no registrador e registros A, AAAA, CNAME, MX e TXT.
- Ferramentas locais: curl, resolvectl e um navegador em aba anônima para testar login.
- Ambiente de origem em Debian 13, AlmaLinux 10 ou equivalente, com Nginx 1.28+ ou Apache estável e suporte a HTTP/3 e Brotli.
Sinais claros de site lento no PageSpeed para migrar ao Cloudflare
PageSpeed Insights deixa de ser ruído quando o laboratório e o campo repetem o mesmo padrão: LCP alto em imagens e CSS, TTFB do documento ainda aceitável ou, ao contrário, HTML lento e estáticos já leves. Nesses dois cenários a decisão muda. Se o HTML chega rápido da origem e o atraso está em JPEG, JS e fontes, a borda da Cloudflare costuma valer o apontamento. Se o primeiro byte do HTML já passa de um segundo sem CDN, o gargalo é servidor, PHP ou banco — a CDN mascara estáticos e não cura a origem.
Sinais objetivos para migrar: visitantes distantes da origem com latência alta de DNS e TLS; muitas requisições de /wp-content/uploads; tema com CSS e JS bloqueantes que a minify e o cache de borda podem aliviar; ataques de bots batendo em wp-login.php. Sinais para não migrar ainda: checkout WooCommerce quebrando com cache de cookie, redireciono HTTP/HTTPS em loop, ou wp-admin instável. Nesses casos primeiro estabilize a origem. Se a hospedagem compartilhada já satura CPU, avalie o comparativo entre hospedagem de sites e VPS antes de esperar milagre da CDN.
Confirme o hostname que o Google testa. Relatório em www.seudominio.com.br com proxy cinza e produção em seudominio.com.br com proxy laranja geram notas diferentes. O PageSpeed precisa bater no mesmo endereço que o usuário vê. Anote LCP, CLS, INP e o campo "tempo de ida e volta da conexão" para comparar depois do proxy.
Como decidir a migração para Cloudflare no dia a dia
No cotidiano, migre quando você já otimizou imagens, desativou plugins pesados e o laboratório ainda acusa atraso de rede e de ativos. Não migre no mesmo dia de troca de tema, importação de loja ou alteração de permalinks. Faça a mudança de DNS em janela de baixo tráfego, com TTL baixo nas 24 horas anteriores, e mantenha o IP de origem 203.0.113.10 documentado para rollback.
Diagnosticar TTFB e origem antes de ligar o proxy
TTFB na origem é o filtro que evita atribuir à Cloudflare um problema de PHP-FPM ou de consulta MySQL. Meça duas vezes: uma resolvendo o hostname público e outra forçando o IP da hospedagem, para isolar a borda.
No Debian 13, teste o documento completo e o primeiro byte:
curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://seudominio.com.br/Output esperado:
dns:0.012 connect:0.045 tls:0.090 ttfb:0.280 total:0.410Forçe a origem, ignorando o DNS público:
curl -s -o /dev/null -w "ttfb_origem:%{time_starttransfer}\n" --resolve seudominio.com.br:443:203.0.113.10 https://seudominio.com.br/Output esperado:
ttfb_origem:0.310Se ttfb_origem for alto e o HTML enorme, abra consultas lentas no MariaDB 11.8+, revise object cache e o pool do PHP-FPM. Cloudflare ajuda o LCP de imagem; não reduz tempo de wp_query pesada. Confira também mistos HTTP/HTTPS e canônicos. O guia como redirecionar um site HTTP para HTTPS evita Flexible SSL com redirect na origem, combinação que infla TTFB e gera loop.
Liste plugins com impacto em cada request (estatística, popup, slider, tradutor). Desative um a um em staging. Meça de novo o TTFB. Só então ligue o proxy laranja. Se o banco estiver em outro host, valide firewall para o IP da Cloudflare e para o IP real 203.0.113.10, senão o PageSpeed verá timeout na origem.
Apontar DNS, proxy laranja e SSL Full strict
Nameservers corretos e proxy só no tráfego web separam um cutover limpo de uma queda de e-mail. Na zona da Cloudflare, o registro A de seudominio.com.br e o CNAME de www devem ficar laranja. MX, SPF, DKIM e DMARC permanecem cinza. Consulte o guia de zona DNS com registros A, MX, CNAME e TXT antes de apagar entradas antigas.
Atenção: alterar nameservers no registrador propaga de minutos a 48 horas. Não apague a zona antiga até resolver A, WWW, FTP e correio. Se o e-mail estiver no mesmo domínio, um MX laranja quebra a entrega.
SSL/TLS no painel: Full (strict). Flexible faz o visitante usar HTTPS e a origem HTTP, o que o WordPress interpreta como URL insegura e dispara redirect. Em wp-config.php mantenha:
define('FORCE_SSL_ADMIN', true);
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}Restaure o IP real do cliente para logs e Fail2Ban, senão todos os hits parecem vir da rede Cloudflare (198.51.100.0/24 nos exemplos). No Nginx 1.28+ use o módulo realip com os ranges oficiais; no Apache, RemoteIPHeader CF-Connecting-IP. Libere o firewall da origem apenas para os ranges da Cloudflare na 80/443 e mantenha SSH restrito ao seu IP.
Após o apontamento, confira resolução:
resolvectl query seudominio.com.brOutput esperado:
seudominio.com.br: 104.16.0.1
104.16.0.2Os IPs devem ser anycast da Cloudflare, não 203.0.113.10. O origin IP continua só no registro A "cinza" de backup ou no painel, nunca exposto em página de erro.
Cache de página, APO, Rocket Loader e Core Web Vitals
LCP melhora quando HTML anônimo e estáticos saem da borda, desde que cookies de sessão não sejam cacheados. Cache Level: Standard. Em Cache Rules (ou Page Rules legadas), bypass para /wp-admin*, /wp-login.php, preview, /carrinho*, /checkout* e quando o cookie wordpress_logged_in_* existir. Cache de HTML só para GET anônimo. TTL de estáticos alto em /wp-content/uploads, /wp-includes e CSS/JS versionados.
Para WordPress em 2026, o Cloudflare APO (Automatic Platform Optimization) é a opção mais completa de WPO: cacheia HTML na borda com detecção nativa de cookies de sessão, compatível com WooCommerce e carrinho, e integra Early Hints para pré-carregamento de recursos críticos. Combine APO com Brotli para compressão superior ao gzip nos ativos estáticos e garanta HTTP/3 ativo no painel para reduzir latência no Brasil.
Rocket Loader e Auto Minify de JavaScript quebram Elementor, Gutenberg e gateways de pagamento com frequência. Ative minify de CSS/HTML primeiro, teste o checkout, depois JS. Polish/WebP ajuda LCP de imagem se o tema não gerar srcset duplicado. Early Hints e HTTP/3 na borda reduzem latência no Brasil sem tocar na origem.
Na origem, continue o trabalho que a CDN não faz: imagens no tamanho de exibição, fontes com font-display, menos JS no above-the-fold, object cache (Redis) e consultas estáveis. Cloudflare sozinho não fecha Core Web Vitals. Combine bypass de admin, otimização de mídia e desativação de plugins de estatística no front. Depois do cache, rode o PageSpeed no mesmo URL, em 4G e cabo, logado e deslogado. Se o INP piorar, desative Rocket Loader imediatamente.
Purge seletivo após publicar post: purge by URL, não purge everything a cada edição. Purge global no horário de pico reaquece a origem e devolve a lentidão que você tentou corrigir no PageSpeed.
Problemas comuns e como resolver
Sintoma: redirecionamento infinito após ligar o proxy
Causa: SSL Flexible com force HTTPS no WordPress ou no servidor, ou siteurl em HTTP.
Solução: mude para Full (strict), corrija siteurl/home para https://seudominio.com.br e confira X-Forwarded-Proto. Limpe cache da Cloudflare e cookies do navegador. Teste em aba anônima.
Sintoma: wp-admin lento ou logout constante
Causa: Page Rule cacheando HTML autenticado ou Rocket Loader alterando scripts do painel.
Solução: bypass de cache em /wp-admin e /wp-login.php, desative Rocket Loader, preserve cookies wordpress_ e woocommerce_. Confirme que o PageSpeed e você testam o hostname com proxy laranja.
Sintoma: nota do Google piora com Cloudflare ligado
Causa: HTML cacheado com CSS antigo, minify quebrando CSS crítico, ou origem bloqueando IPs de medição.
Solução: purge por URL, desative minify de JS, libere crawlers e ranges da Cloudflare no firewall. Recalcule TTFB na origem; se continuar alto, otimize PHP-FPM e banco antes de novo teste de laboratório.
Sintoma: e-mail para de chegar depois da migração de DNS
Causa: MX ou SPF apontados com proxy laranja, ou nameservers trocados sem copiar registros TXT.
Solução: MX e TXT cinza, reimporte SPF/DKIM, aguarde TTL. Não use CNAME na raiz para correio.
Perguntas frequentes sobre WordPress lento e Cloudflare
Como saber se a lentidão do WordPress é da origem ou do Google PageSpeed?
Meça o TTFB sem CDN e compare com o relatório do PageSpeed Insights. Se o HTML demora na origem e os estáticos já estão leves, o gargalo é servidor, PHP ou banco. Cloudflare ajuda estáticos e edge, mas não substitui origem lenta.
Quando vale colocar Cloudflare em um WordPress lento no Google?
Vale quando imagens, CSS e JS pesam no LCP e o DNS/SSL na borda reduz latência. Não espere milagre se consultas MySQL, plugins ou PHP-FPM saturam a origem. Combine cache de página, minify e proxy laranja só após backup e teste de login.
Cloudflare sozinho resolve Core Web Vitals do WordPress?
Não. A CDN reduz latência de ativos e pode cachear HTML anônimo, mas LCP, CLS e INP ainda dependem de tema, scripts e banco. Use cache bypass em wp-admin e carrinho, otimize imagens e desative plugins pesados na origem.
O proxy da Cloudflare pode piorar a lentidão no Google?
Sim, se o SSL estiver em Flexible com redireciono na origem, se Page Rules cachearem o admin ou se o IP real do servidor for bloqueado. Use Full (strict), exclusões de cache no login e confirme que o PageSpeed testa o mesmo hostname com proxy ativo.
O que diagnosticar antes de otimizar WordPress com Cloudflare?
Verifique TTFB na origem, queries lentas, PHP-FPM, plugins e tamanho de HTML. No Cloudflare, confira modo SSL, cache level, Rocket Loader e regras que quebrem cookies. Só então ative cache de estáticos e, se estável, cache de HTML para visitantes anônimos.
Conclusão
PHP-FPM e banco saudáveis continuam sendo o chão da performance; a Cloudflare entra quando a borda realmente encurta DNS, TLS e estáticos rumo ao PageSpeed. Use a lista abaixo como fechamento operacional.
- Só aponte o proxy laranja depois de medir TTFB na origem e de ter backup e SSL válido.
- Mantenha Full (strict), bypass de admin/login/carrinho e MX cinza para não trocar lentidão por indisponibilidade.
- Reavalie LCP, CLS e INP no mesmo hostname; se o HTML continuar lento, otimize origem antes de novo purge global.
Leia também
- passo a passo: desativar WP-Cron sem quebrar WordPress
- Passo a passo: MariaDB é MySQL? escolha o banco certo
- Solucionar lentidão no WordPress: causas reais e correções
Precisa de ajuda com WordPress lento e Cloudflare?
Se a origem ainda satura CPU ou o DNS do domínio precisa de revisão junto com o CMS, a equipe pode orientar hospedagem adequada ao WordPress e o cutover da CDN sem chute no SSL.
