---
title: "Como acelerar o WordPress: guia de engenharia"
id: "594"
type: "post"
slug: "como-acelerar-wordpress"
published_at: "2026-10-06T20:00:50+00:00"
modified_at: "2026-10-06T20:22:47+00:00"
url: "https://danielpazwp.com/pt/como-acelerar-wordpress/"
markdown_url: "https://danielpazwp.com/pt/como-acelerar-wordpress.md"
excerpt: "A ordem que sigo para acelerar sites WordPress lentos: servidor, cache de página e de objetos, banco, depois LCP, INP e CLS, medidos em campo."
taxonomy_category:
  - "Performance"
---

[Performance](https://danielpazwp.com/pt/category/performance-pt/)
21 min de leitura

# Como acelerar o WordPress: guia de engenharia

A ordem que sigo para acelerar sites WordPress lentos: servidor, cache de página e de objetos, banco, depois LCP, INP e CLS, medidos em campo.

Publicado **06/10/2026**21 min de leitura

[Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/)

Para acelerar o WordPress, corrija na ordem em que o navegador recebe a página. Comece pela resposta do servidor: PHP com suporte e OPcache ligado, um cache de página que de fato entrega o HTML e um object cache persistente para o que não dá para cachear. Depois limpe o banco, principalmente as opções com autoload e as queries lentas. Só então vá para o front-end: imagem do LCP, CSS que bloqueia a renderização, JavaScript de plugins e de terceiros, fontes e deslocamentos de layout. Meça cada passo com dados de campo, não com nota de laboratório. A maioria dos sites lentos que audito precisa de menos plugins e de arquitetura melhor, não de mais um plugin de otimização.

Essa é a versão curta. O resto do guia é a versão longa: a ordem que sigo nas auditorias, quanto cada camada custa, como saber qual delas é o seu problema e onde se aprofundar. Se quiser entender primeiro o porquê dessa ordem, leia [por que o seu site WordPress é lento por motivos estruturais](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)
. Se você já sabe que o site está lento e precisa achar a causa, comece por [como descobrir por que o seu WordPress está lento](https://danielpazwp.com/pt/por-que-meu-wordpress-esta-lento/)
.

## O que significa “rápido” para um site WordPress?

Rápido tem definição, e ela vem das Core Web Vitals do Google medidas em visitantes reais. O Google pega o percentil 75 dos carregamentos de página numa janela móvel de 28 dias, a partir do Chrome UX Report (CrUX). A página passa quando as três métricas estão boas nesse percentil.

| Métrica | O que mede | Bom | Ruim |
| --- | --- | --- | --- |
| — | — | — | — |
| LCP (Largest Contentful Paint) | Quando o conteúdo principal aparece | ≤ 2,5 s | > 4 s |
| INP (Interaction to Next Paint) | Quão rápido a página responde a cliques, toques e teclas | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Quanto o layout pula | ≤ 0,1 | > 0,25 |
| TTFB (Time to First Byte), só diagnóstico | Quando chega o primeiro byte do HTML | ≤ 0,8 s | > 1,8 s |

O INP substituiu o FID como métrica de responsividade em março de 2024. O TTFB não é uma Core Web Vital, mas coloquei na tabela de propósito. No WordPress é ali que o problema costuma começar, porque nada aparece na tela antes de o HTML chegar. Explico tudo isso com mais detalhe em [Core Web Vitals no WordPress: o guia completo](https://danielpazwp.com/pt/core-web-vitals-no-wordpress/)
.

A outra metade da definição: rápido quer dizer rápido para os seus visitantes, no celular e na rede deles. Uma nota 98 no Lighthouse do seu notebook não diz isso. A diferença entre os dois tipos de dado é a maior fonte de confusão que vejo, por isso ela tem um artigo próprio: [dados de campo vs dados de laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/)
.

## Por onde começar para acelerar o WordPress?

Medindo, e medindo por template, não pelo site inteiro. Um site WordPress é um punhado de templates: home, página, post, arquivo, busca e, numa loja, produto, categoria, carrinho e checkout. Cada um tem um elemento LCP diferente, plugins diferentes rodando e um comportamento de cache diferente. A média esconde justamente o que reprova.

Esta é a rotina curta de medição que faço antes de mexer em qualquer coisa:

1. Abra o relatório de Core Web Vitals no Google Search Console e anote quais grupos de URL reprovam e em qual métrica.
2. Passe uma URL representativa de cada template no PageSpeed Insights e leia o bloco de dados de campo no topo antes de olhar a nota de laboratório.
3. Confira o TTFB de uma requisição cacheada e de uma sem cache em cada template. Requisição logada ou URL com query string costuma pular o cache.
4. Instale o Query Monitor numa cópia de homologação e olhe os templates mais lentos: quantidade de queries, queries lentas, chamadas de HTTP API e de qual plugin elas vêm.
5. Anote a linha de base. Sem ela você não consegue provar nada depois.

O lado do diagnóstico tem um passo a passo próprio em [por que meu WordPress está lento](https://danielpazwp.com/pt/por-que-meu-wordpress-esta-lento/)
, e as ferramentas estão comparadas em [ferramentas de Core Web Vitals](https://danielpazwp.com/pt/ferramentas-core-web-vitals/)
. Se preferir uma lista para ir marcando, use o [checklist de velocidade do WordPress](https://danielpazwp.com/pt/checklist-velocidade-wordpress/)
.

## Em que ordem corrigir?

De baixo para cima na pilha. Cada camada define um piso para as camadas de cima. Se o servidor leva 1,5 segundo para mandar o HTML, a melhor otimização de imagem do mundo ainda deixa só 1 segundo para renderizar o elemento LCP antes de estourar os 2,5 segundos. Então eu arrumo o piso primeiro.

| Camada | Sintoma típico | Primeira correção | Para se aprofundar |
| --- | --- | --- | --- |
| — | — | — | — |
| Hospedagem e PHP | TTFB alto até em páginas simples | PHP com suporte, OPcache, PHP workers suficientes | ajuste de PHP-FPM e OPcache |
| Cache de página | TTFB bom em algumas visitas e ruim em outras | Cache que entrega HTML sem subir o PHP, menos regras de bypass | melhor plugin de cache para WordPress |
| Object cache | Admin, carrinho, conta e busca lentos | Redis ou Memcached com um drop-in de object cache | Redis object cache no WordPress |
| Banco de dados | Tudo lento, e piorando com o tempo | Enxugar opções com autoload, corrigir queries lentas | otimização do banco de dados do WordPress |
| Front-end | TTFB bom, mas LCP, INP ou CLS ruins | Prioridade da imagem do LCP, menos CSS e JavaScript | LCP, INP, CLS |
| Terceiros | INP ruim, tarefas longas na thread principal | Remover, adiar ou trocar tags | INP no WordPress |

Essa ordem também economiza dinheiro. Uma correção no servidor ajuda todos os templates de uma vez. Uma correção no front-end costuma ajudar um template e, às vezes, um único elemento dele.

## A hospedagem faz mesmo diferença na velocidade do WordPress?

Faz, e ela define o limite de todo o resto. Muita gente me pede a melhor hospedagem WordPress para velocidade, e eu não respondo com uma marca. Respondo com uma lista do que conferir, porque a mesma empresa pode vender um plano rápido e um lento.

Quando avalio uma hospedagem para um projeto WordPress, olho:

- versões de PHP que ainda têm suporte oficial, e se é fácil trocar entre elas
- OPcache ligado com memória suficiente para o tamanho do código
- quantos PHP workers o plano permite e o que acontece com as requisições quando todos estão ocupados
- cache de página no servidor (cache FastCGI do Nginx, cache do LiteSpeed, Varnish ou equivalente), ou pelo menos suporte a um
- Redis ou Memcached disponível para object cache persistente
- data center perto da maioria dos seus visitantes, ou uma CDN capaz de cachear HTML na borda
- se você divide CPU e banco com outros clientes, e como isso aparece sob carga
- acesso a logs, ao slow log do PHP e, de preferência, a uma ferramenta de APM, para ver para onde vai o tempo

Hospedagem compartilhada pode servir para um site institucional com um bom cache de página. Deixa de servir quando a maior parte do tráfego não é cacheada: carrinho de WooCommerce, área de membros, painel de LMS, busca. Essas requisições rodam PHP e banco toda vez, e aí número de workers e CPU viram o limite real. O lado do servidor está detalhado em [TTFB no WordPress](https://danielpazwp.com/pt/ttfb-no-wordpress/)
 e em [ajuste de PHP-FPM e OPcache para WordPress](https://danielpazwp.com/pt/php-fpm-opcache-wordpress-pt/)
.

## Como configurar o cache no WordPress?

Pense no cache como três camadas separadas que resolvem problemas diferentes. Confundir as três é como alguém acaba com três plugins de cache e um site que continua lento.

- O cache de página guarda o HTML pronto e entrega para o próximo visitante anônimo sem rodar o WordPress. É o maior ganho de TTFB em sites de conteúdo.
- O object cache guarda resultados de queries e valores calculados entre uma requisição e outra. O WordPress já tem um object cache, mas por padrão ele só dura uma requisição. Um backend persistente como o Redis mantém esses dados entre requisições, o que ajuda as páginas que o cache de página não atende: usuários logados, carrinho, checkout, admin.
- O edge cache, normalmente uma CDN, mantém cópias dos arquivos estáticos e às vezes do HTML em pontos perto dos visitantes. Ele corta distância de rede, coisa que nenhum ajuste de servidor faz.

Explico como as três se encaixam, e quais um site precisa de verdade, em [page cache, object cache, edge cache: qual você realmente precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/)
. A configuração do object cache com Redis está passo a passo em [Redis object cache no WordPress](https://danielpazwp.com/pt/redis-object-cache-wordpress/)
.

### Qual plugin de cache usar?

O que combina com o seu servidor. Se a hospedagem roda LiteSpeed, o LiteSpeed Cache conversa direto com o cache do servidor. Em pilhas com Nginx ou Apache, um plugin que grava HTML estático ou um cache da própria hospedagem resolve. O que eu comparo é arquitetura: onde o cache fica, como funciona a limpeza, o que ele faz com CSS e JavaScript e como lida com usuário logado e WooCommerce. O comparativo longo está em [melhores plugins de cache para WordPress](https://danielpazwp.com/pt/melhor-plugin-de-cache-wordpress/)
, e os confrontos diretos são [WP Rocket vs LiteSpeed Cache](https://danielpazwp.com/pt/wp-rocket-vs-litespeed-cache-pt/)
, [FlyingPress vs WP Rocket](https://danielpazwp.com/pt/flyingpress-vs-wp-rocket-pt/)
 e [NitroPack vs WP Rocket](https://danielpazwp.com/pt/nitropack-vs-wp-rocket-pt/)
.

### Por que o cache de página não funciona?

Nas auditorias, o motivo mais comum para o cache “não funcionar” é que ele não está sendo usado. Confira isto antes de culpar o plugin:

- cookies gravados para todo visitante (ferramentas de consentimento, teste A/B, algumas configurações de analytics) que o cache trata como motivo para pular
- parâmetros de campanha como utm_source gerando cache miss em todo clique de anúncio
- tempo de vida do cache muito curto, ou uma limpeza que apaga tudo a cada post atualizado
- um plugin que abre sessão PHP em toda página
- duas camadas de cache brigando, por exemplo o cache de um plugin atrás do cache da hospedagem com regras diferentes

Leia os cabeçalhos da resposta. A maioria dos caches adiciona um cabeçalho que diz HIT ou MISS. Se as suas landing pages mostram MISS, a primeira correção é essa. O Site Health do WordPress também verifica se existe cache de página desde a versão 6.1, um jeito rápido de achar uma falha óbvia.

## Como evitar que o banco de dados deixe toda requisição lenta?

O WordPress guarda a maior parte da configuração na tabela wp_options. As opções marcadas com autoload são carregadas em toda requisição, com ou sem cache, logado ou não. Plugins vão aumentando essa lista e muitos nunca apagam suas linhas quando são desinstalados. Com os anos, os dados com autoload crescem, e toda requisição sem cache paga a conta. Desde o WordPress 6.6 o Site Health avisa quando as opções com autoload ficam grandes demais.

O que eu costumo encontrar e corrigir:

- opções com autoload deixadas por plugins removidos há muito tempo
- transients expirados acumulando em wp_options porque nada limpa
- tabelas wp_postmeta enormes, muitas vezes por causa de page builders, revisões ou WooCommerce em lojas que nunca migraram os pedidos para o HPOS
- queries sem índice utilizável, que aparecem no Query Monitor ou no slow query log do MySQL
- WP-Cron rodando nas visitas num site movimentado, em vez de um cron de verdade no sistema

Nada disso pede um “limpador de banco” que apaga coisas às cegas. Pede saber qual plugin é dono de quais linhas. O método, com comandos de WP-CLI, está em [otimização do banco de dados do WordPress: autoload da wp_options e além](https://danielpazwp.com/pt/otimizacao-banco-de-dados-wordpress/)
. Se a lentidão está mais no wp-admin de uma loja, leia [como resolver um admin do WooCommerce lento](https://danielpazwp.com/pt/admin-woocommerce-lento/)
.

## Como melhorar a performance do front-end no WordPress?

Quando o HTML chega rápido, o que sobra é o que o navegador precisa baixar, interpretar e executar. No WordPress isso vem de três lugares: o tema, os plugins e as tags de terceiros. Eu passo por métrica.

### Imagens e o elemento LCP

Na maioria das páginas WordPress o elemento LCP é uma imagem: o banner principal, a imagem destacada ou a primeira foto de produto. Corrija assim:

- garanta que a imagem do LCP não tenha lazy load (o WordPress aplica lazy load nas imagens por padrão e costuma pular a primeira, mas temas e builders podem passar por cima disso)
- coloque `fetchpriority="high"` nela; o WordPress 6.3 passou a adicionar isso à imagem que ele considera a provável LCP
- entregue um tamanho compatível com o espaço, usando o srcset que o WordPress já gera
- use formatos modernos: o WordPress aceita upload de WebP desde a 5.8 e de AVIF desde a 6.5
- não esconda o banner atrás de um slider ou de uma animação em JavaScript que atrasa a exibição

O método completo do LCP, incluindo como ler as quatro partes do tempo, está em [LCP no WordPress: causas e correções](https://danielpazwp.com/pt/lcp-no-wordpress/)
.

### CSS e bloqueio de renderização

A maioria dos temas e plugins carrega o CSS em todas as páginas, usando ou não. O CSS de um plugin de formulário na listagem do blog é o caso típico. As opções, da mais segura para a mais arriscada: tirar os arquivos dos templates que não precisam deles, colocar inline o CSS crítico da primeira dobra e remover o CSS não usado com uma ferramenta. É nessa última que vejo mais coisa quebrar, então teste em todos os templates e com usuário logado.

### JavaScript e INP

O INP é a métrica em que os sites WordPress reprovam com menos alarde, porque as ferramentas de laboratório quase não enxergam. As causas são tarefas longas na thread principal: sliders, mega menus, widgets de builder, chat, gerenciadores de tags, scripts de anúncio. O que ajuda:

- carregar scripts não essenciais com defer ou async; o WordPress 6.3 adicionou estratégias de carregamento ao wp_register_script e ao wp_enqueue_script
- tirar plugins que dependem de jQuery para fazer o que o CSS faz
- adiar chat, vídeo e embeds de redes sociais até o visitante interagir
- reduzir o tamanho do DOM, o que na prática quer dizer layouts mais simples e menos containers aninhados no builder

As opções de “atrasar todo o JavaScript” dos plugins de otimização podem jogar o custo para a primeira interação, que é exatamente o que o INP mede. Use com cuidado e confira o INP nos dados de campo depois. Mais em [INP no WordPress: como resolver interações lentas](https://danielpazwp.com/pt/inp-no-wordpress/)
.

### Fontes

Hospede localmente as fontes que você usa, carregue só os pesos necessários, faça preload da fonte do texto do LCP se houver uma e defina o font-display. A Font Library do WordPress 6.5 facilita hospedar fontes localmente em temas de blocos. A troca de fonte também pode mexer no layout, o que leva ao CLS.

### Deslocamentos de layout

No WordPress, o CLS costuma vir de imagens e embeds sem dimensões, espaços de anúncio e banners injetados acima do conteúdo, barras de cookie que empurram a página e trocas de fonte tardias. A correção é reservar espaço para tudo o que carrega depois. A lista completa está em [CLS no WordPress: como parar os deslocamentos de layout](https://danielpazwp.com/pt/cls-no-wordpress/)
.

## E os scripts de terceiros?

Eles merecem uma seção própria porque ficam fora do seu código e fora do seu cache. Analytics, gerenciador de tags, mapa de calor, chat, ferramenta de consentimento, rede de anúncios, widget de avaliações e pixels rodam todos na thread principal do visitante. Nas auditorias, muitas vezes são a maior fonte de INP ruim em sites que no resto estão bem construídos.

Meu processo é chato e funciona. Liste todas as tags que o site carrega. Para cada uma, pergunte quem usa aqueles dados e quando olhou pela última vez. Remova as que ninguém consegue defender. Carregue o resto depois que a página já está utilizável, quando o fornecedor permitir, e não deixe o gerenciador de tags virar um lugar onde qualquer um adiciona script sem revisão. Isso é tanto problema de governança quanto técnico, e por isso também falo disso em [WordPress enterprise](https://danielpazwp.com/pt/wordpress-enterprise/)
, onde o excesso de tags é a regra.

## O page builder está deixando o WordPress lento?

Pode estar, e o custo é quase todo no front-end: mais nós de DOM, mais CSS e mais JavaScript por página do que um tema de blocos precisa para o mesmo layout. Isso aparece no LCP e no INP. Um site em builder ainda pode passar nas Core Web Vitals. Exige disciplina: menos containers aninhados, menos widgets que carregam scripts próprios e uso das opções de performance do próprio builder.

Se o site já está no Elementor, os passos práticos estão em [como acelerar o Elementor](https://danielpazwp.com/pt/como-acelerar-elementor/)
. Se você está decidindo em que fazer a próxima versão, leia [Elementor vs Gutenberg em performance](https://danielpazwp.com/pt/elementor-vs-gutenberg-performance-pt/)
, que compara como cada um gera o markup e carrega os arquivos.

## O que muda no WooCommerce?

Uma loja tem mais páginas que não saem do cache de página: carrinho, checkout, minha conta e muitas vezes as páginas de produto para cliente logado. Isso devolve a carga para o PHP e o banco, então as camadas de servidor, object cache e banco pesam mais numa loja do que num blog.

O trabalho de sempre no WooCommerce inclui:

- object cache persistente, porque carrinho e sessão batem no banco o tempo todo
- conferir a requisição de cart fragments, que pode rodar em páginas que não precisam dela
- High-Performance Order Storage (HPOS), que tira os pedidos das tabelas de posts e postmeta
- templates de produto e categoria com muitas imagens e filtros, que precisam do mesmo trabalho de LCP de qualquer outra página
- uma análise separada do wp-admin, onde listas de pedidos, relatórios e extensões adicionam suas próprias queries

Os passos de front-end e servidor estão em [otimização de velocidade do WooCommerce](https://danielpazwp.com/pt/otimizacao-velocidade-woocommerce/)
, e o painel tem um post próprio: [admin do WooCommerce lento](https://danielpazwp.com/pt/admin-woocommerce-lento/)
.

## Quais recursos do core do WordPress já ajudam na velocidade?

O core recebeu bastante trabalho de performance nas versões recentes, boa parte vinda do WordPress Performance Team. Antes de instalar um plugin para alguma coisa, confira se o core já não faz.

| Recurso | Desde | O que faz |
| --- | --- | --- |
| — | — | — |
| Upload de WebP | 5.8 | Aceita e gera imagens WebP |
| Verificação de cache de página no Site Health | 6.1 | Avisa quando não encontra cache de página |
| fetchpriority em imagens | 6.3 | Adiciona fetchpriority=”high” à provável imagem do LCP |
| Estratégias de carregamento de scripts | 6.3 | Permite registrar scripts com defer ou async |
| Upload de AVIF | 6.5 | Aceita imagens AVIF quando o servidor suporta |
| Interactivity API | 6.5 | Um jeito padrão de adicionar interatividade aos blocos |
| Font Library | 6.5 | Gerencia e hospeda fontes localmente em temas de blocos |
| Verificação do tamanho do autoload no Site Health | 6.6 | Avisa quando as opções com autoload estão grandes demais |
| Speculative loading | 6.8 | Usa a Speculation Rules API para pré-carregar as próximas páginas prováveis |

O [plugin Performance Lab](https://wordpress.org/plugins/performance-lab/)
 é onde o Performance Team testa recursos antes de irem para o core. É um bom lugar para experimentar opções novas em homologação.

## Quais otimizações saem pela culatra?

Algumas correções melhoram o relatório e pioram o site. Desfaço estas nas auditorias com mais frequência do que gostaria:

- Empilhar plugins de otimização. Dois plugins minificando e combinando os mesmos arquivos, ou um plugin de cache em cima do cache da hospedagem com regras de limpeza diferentes, geram layout quebrado e página desatualizada. Escolha uma ferramenta por tarefa.
- Lazy load em tudo. Lazy load na imagem principal atrasa o LCP, às vezes bastante. Lazy load é para imagens abaixo da dobra.
- Preload demais. Um preload diz ao navegador “isto é o mais importante”. Com dez preloads nada é o mais importante, e a imagem do LCP espera na fila junto com fontes e scripts.
- Juntar todo o CSS e o JavaScript num arquivo só. Com HTTP/2 e HTTP/3, muitos arquivos pequenos deixaram de ser o problema que eram. Um pacote gigante muitas vezes faz cada página baixar o código de todas as outras.
- Atrasar scripts de que a página precisa. Se o menu, o botão de comprar ou a busca só funcionam depois que um script atrasado carrega, a primeira interação fica lenta e o INP piora.
- Limpar o banco com uma ferramenta de um clique em produção, sem backup e sem saber qual plugin é dono de qual tabela.
- Otimizar para a nota de laboratório. Tirar o banner de cookies ou o chat só para o user agent do Lighthouse é cloaking, e não muda nada para o visitante.

O que todas têm em comum: uma mudança feita sem medir o efeito nos visitantes reais. Por isso meço antes e depois de cada mudança, uma de cada vez, numa cópia de homologação quando a mudança é arriscada.

## Como é um projeto de aceleração na prática?

Quando trabalho num site, a sequência é mais ou menos a mesma, seja qual for o tamanho. Primeiro alguns dias de medição: dados de campo, testes de laboratório por template, tempos de servidor e um inventário de plugins e tags. Depois uma lista escrita de gargalos ordenada por impacto e esforço, com os itens de servidor e cache perto do topo porque ajudam todas as páginas. Em seguida a implementação em lotes pequenos, cada um publicado e conferido separadamente. Por fim, um mês acompanhando os dados de campo alcançarem as mudanças, por causa da janela de 28 dias.

A etapa de ordenar é a que as pessoas pulam. Dá vontade de começar pelo primeiro item do relatório do PageSpeed. Só que essa lista estima ganhos para uma URL num único teste de laboratório. Ela não diz nada sobre o que mexe nos seus dados de campo no site todo. Um TTFB lento em toda requisição sem cache raramente aparece no topo dessa lista, e muitas vezes é o maior ganho.

## Quantos plugins são demais?

Não existe um número. Já vi site rápido com uma lista longa de plugins e site lento com uma lista curta. O que importa é o que cada plugin faz em cada requisição: as queries que adiciona, os arquivos que carrega no front-end, as chamadas HTTP externas que faz, os crons que agenda. Um plugin ruim que chama uma API remota em todo carregamento de página custa mais do que vinte pequenos que não fazem nada no front-end.

O Query Monitor mostra queries e chamadas HTTP agrupadas por componente. O [guia de diagnóstico](https://danielpazwp.com/pt/por-que-meu-wordpress-esta-lento/)
 explica como usar isso para achar o plugin que está deixando o site lento, sem o velho truque de desativar tudo em produção.

## Como provar que o site ficou mais rápido, e manter assim?

Com os mesmos dados de campo que você usou na linha de base. Lembre da janela de 28 dias: o CrUX e o relatório do Search Console levam cerca de quatro semanas para refletir uma mudança por inteiro, então uma correção publicada hoje não mostra todo o efeito amanhã. As ferramentas de laboratório dão retorno rápido enquanto você trabalha. Os dados de campo dizem se funcionou para os visitantes.

Para manter o site rápido depois que o projeto acaba:

- adicione monitoramento de usuários reais (RUM) se puder, para ver regressões em dias e não em semanas
- rode o Lighthouse ou uma checagem parecida nos templates principais durante o deploy, para pegar regressões óbvias
- revise plugins e tags novos antes de irem para o ar, e não depois que o relatório ficar vermelho
- confira de novo os dados com autoload e as queries lentas algumas vezes por ano
- mantenha PHP e WordPress atualizados, porque os dois trazem melhorias de performance com frequência

Sites com muitos editores, vários times e uma lista longa de integrações precisam disso mais do que os outros. É boa parte do que quero dizer com [WordPress enterprise](https://danielpazwp.com/pt/wordpress-enterprise/)
: performance como processo com responsáveis, e não uma faxina de uma vez só.

## Perguntas frequentes

### Um plugin de cache basta para acelerar o WordPress?

Num site de conteúdo pequeno numa hospedagem decente, um cache de página bem configurado resolve a maior parte do TTFB. Ele não conserta um tema pesado, uma imagem de LCP mal otimizada nem scripts de terceiros, e não faz nada pelas páginas sem cache, como carrinho e painéis. O plugin de cache é uma camada do trabalho.

### Nota 100 no PageSpeed melhora o ranqueamento?

A nota do PageSpeed é um resultado de laboratório do Lighthouse e o Google não usa essa nota para ranquear. O Google usa as Core Web Vitals dos dados de campo como parte dos sinais de experiência na página. O objetivo é passar em LCP, INP e CLS para os visitantes reais. Uma nota verde no laboratório que não bate com os dados de campo não vale a perseguição.

### Quanto tempo leva para ver resultado depois de acelerar o WordPress?

As suas medições mudam na hora. Os dados de campo do CrUX, que alimentam o PageSpeed Insights e o Search Console, usam uma janela móvel de 28 dias, então conte com umas quatro semanas até os relatórios mostrarem a mudança por inteiro.

### Preciso de CDN?

Se os seus visitantes estão espalhados por regiões longe do servidor, uma CDN encurta a distância dos arquivos estáticos e, quando configurada para cachear HTML, da própria página. Se quase todos estão perto do servidor e o cache de página é rápido, a CDN ajuda menos. Meça o TTFB de onde os visitantes estão antes de decidir.

### Devo trocar o page builder pelo Gutenberg por velocidade?

Não automaticamente. Refazer o site custa caro, e um site em builder feito com disciplina pode passar nas Core Web Vitals. Se o site já vai ser redesenhado, um tema de blocos costuma entregar menos CSS e JavaScript para o mesmo layout. Compare os dois nos seus próprios templates antes.

## Quer outro olhar sobre o seu site?

Se você prefere que alguém encontre e ordene os gargalos, eu faço uma [auditoria de performance e Core Web Vitals no WordPress](https://danielpazwp.com/pt/auditoria-performance-wordpress/)
 que passa camada por camada, da resposta do servidor aos scripts de terceiros, com os dados de campo como referência. Para trabalho contínuo em sites maiores, veja como atuo como [especialista em performance WordPress](https://danielpazwp.com/pt/performance-wordpress/)
; a implementação fica com a [equipe da WebOption](https://weboption.com.br/performance-seguranca/)
.

[Trabalhe com o Daniel](https://danielpazwp.com/pt/#book)
[Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/)

[Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/)

## Artigos relacionados

[Todos os artigos](https://danielpazwp.com/pt/artigos/)

[Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/)
[Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/)
[Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)