Você ativa o plugin de posts relacionados, o bloco aparece bonito no fim do artigo, e duas semanas depois o cliente reclama que o site está lento. Ou pior: o painel de performance mostra o tempo de resposta subindo e você não sabe se a culpa é do plugin, do cache ou do banco. Posts relacionados WordPress é uma daquelas funcionalidades que parecem inofensivas e, em site com milhares de posts, cobram caro em consulta ao banco.
A pergunta que importa não é “qual o melhor plugin”, e sim “esse bloco se paga neste site?”. A resposta depende do tipo de conteúdo, do volume de posts e de quanto você está disposto a mexer em código. Este artigo traz a ordem de teste e o caso em que a receita comum falha.
O que o bloco de conteúdo relacionado entrega de verdade
Em site editorial, com muitos artigos e leitor que chega pelo Google, o bloco de conteúdo relacionado costuma ser uma das alavancas mais baratas para aumentar páginas por sessão. O leitor termina o texto, vê três títulos parecidos e clica em um. Isso reduz a taxa de rejeição e aumenta o tempo na página. Em site institucional com dez páginas, o mesmo bloco não muda quase nada: o leitor já viu todo o menu.
Por isso, antes de escolher o plugin, defina o que você espera medir. Se a resposta for “quero que o leitor continue navegando”, o bloco faz sentido. Se for “quero preencher o rodapé do post”, você está adicionando consulta ao banco sem contrapartida.
Como o plugin de posts relacionados monta a lista
Quase todo plugin de posts relacionados WordPress usa uma destas estratégias para decidir o que mostrar:
| Estratégia | Como funciona | Custo no banco |
|---|---|---|
| Categorias e tags | Busca posts que compartilham termos da taxonomia | Baixo a médio, depende dos índices |
| Palavras do título | Compara palavras do título atual com outros títulos | Alto em bases grandes, porque a busca é textual |
| Conteúdo completo | Analisa o corpo do post para achar similaridade | Alto, e costuma exigir tabela própria |
| Histórico de acessos | Usa o que outros leitores clicaram | Médio, mas exige gravar e ler dados de sessão |
Na prática, a estratégia de palavras do título é a que mais pesa. Ela faz uma consulta com LIKE em cima da tabela de posts, e esse tipo de consulta não usa índice direito. Em site com milhares de posts, cada visita a um artigo dispara uma varredura que o MySQL precisa resolver antes de entregar a página.
Quando o plugin de posts relacionados WordPress ajuda
O plugin de posts relacionados compensa quando pelo menos duas destas condições são verdadeiras:
- O site tem volume real de artigos publicados, e o leitor costuma chegar por busca orgânica.
- Você tem como medir páginas por sessão antes e depois da ativação.
- O servidor tem cache de página ativo, de preferência cache em disco ou na borda.
- O bloco aparece em posts, não em páginas institucionais nem em produtos.
Quando o cache de página está funcionando, o bloco é gerado uma vez e servido pronto para os próximos visitantes. Nesse cenário, o custo da consulta some do caminho crítico e o plugin passa a ser só ganho de navegação.
Quando o plugin de posts relacionados WordPress só pesa
Existe um cenário em que a receita comum falha: site com milhares de posts, cache de página ativo, e mesmo assim o tempo de resposta sobe. Isso acontece porque o cache não cobre tudo. Visitante logado, carrinho ativo, comentário recém-enviado, página de busca interna e o próprio editor do WordPress costumam ficar fora do cache. Em cada uma dessas visitas, o plugin roda a consulta de novo.
Além disso, alguns plugins de related posts gravam a lista em post meta. Isso ajuda na leitura, mas cria trabalho na publicação: cada novo post precisa recalcular relações com o acervo inteiro. Em site que publica várias vezes por dia, esse recálculo pode travar a tela de edição.
Por fim, tem o caso do plugin abandonado. Se ele não recebe atualização há tempo, pode ter consulta antiga, sem índice, e ainda virar porta de entrada. Vale conferir o histórico do plugin antes de instalar, como explicamos em plugin abandonado no WordPress: trocar ou manter.
Ordem de teste: medir antes e depois
Não ative o plugin e confie na sensação. Meça. A ordem abaixo serve para qualquer site, com ou sem SSH.
- Meça a linha de base. Com o plugin desativado, registre o tempo de resposta da home e de um post representativo. Use uma ferramenta externa de teste de velocidade ou o próprio
curlno terminal:curl -o /dev/null -s -w "%{time_total}\n" https://seusite.com/um-post/. Rode três vezes e guarde o maior valor. - Ative o plugin e repita a medição. Faça o mesmo teste nos mesmos endereços, de preferência no mesmo horário do dia.
- Compare com o cache ligado e desligado. Se o tempo só sobe quando o cache está desligado, o problema é do visitante não cacheado. Se sobe nos dois casos, a consulta está pesando no caminho crítico.
- Olhe o número de consultas. Plugins de diagnóstico mostram quantas consultas ao banco a página executa. Um bloco de relacionados bem feito adiciona uma ou duas consultas. Se adicionar dezenas, o plugin está fazendo laço em cima de post meta.
- Teste em um post antigo e em um recente. Post antigo costuma ter mais conteúdo e mais termos, e a consulta fica mais cara.
Se você administra vários sites, esse teste precisa ser repetido em cada um. Um plugin que se comporta bem em site com duzentos posts pode derrubar a performance em site com vinte mil. Para achar o que pesa sem chutar, vale a leitura de profiler de plugins WordPress: achar o que pesa no site.
Alternativa: fazer o bloco por código
Quando o plugin pesa, a saída mais comum é montar o bloco por código, usando a consulta que você controla. A ideia é simples: buscar posts da mesma categoria, limitar a três, e cachear o resultado.
Um exemplo de consulta enxuta, dentro do loop do tema:
$relacionados = new WP_Query( array(
'category__in' => wp_get_post_categories( get_the_ID() ),
'post__not_in' => array( get_the_ID() ),
'posts_per_page' => 3,
'no_found_rows' => true,
'ignore_sticky_posts' => true,
) );O parâmetro no_found_rows evita que o WordPress conte o total de resultados, o que economiza uma consulta. O post__not_in impede que o próprio post apareça na lista. Com isso, você tem um bloco de conteúdo relacionado que faz uma consulta só, sem depender de plugin.
O preço é manutenção: esse código vive no tema ou em um plugin próprio, e você precisa lembrar dele na próxima troca de tema. Se o site usa tema premium com suporte, verifique se ele já traz o bloco nativo antes de instalar qualquer coisa. Tem tema que resolve isso bem, e a decisão de pagar por ele segue a mesma lógica de tema corporativo premium: quando vale e o que exigir.
Quando NÃO usar plugin de posts relacionados
Existem casos em que a resposta honesta é não instalar nada:
- Site com poucos posts publicados. O bloco vai repetir sempre os mesmos títulos e o leitor percebe.
- Site cujo objetivo é levar o visitante para uma página de conversão, não para outro artigo. Nesse caso, o bloco compete com o botão que importa.
- Site em que o tema já entrega o bloco. Instalar plugin por cima é duplicar consulta.
- Site com banco já sobrecarregado por outro motivo. Resolva o gargalo antes de adicionar mais uma consulta.
Além disso, se o problema atual é o site fora do ar, não é hora de testar plugin de posts relacionados WordPress. Primeiro descubra o que travou, como em plugin quebrado no WordPress: como descobrir qual travou o site.
Erros comuns ao configurar o bloco
Os tropeços que mais aparecem em sites de clientes:
- Deixar o bloco em todas as páginas. Página institucional e produto não precisam de related posts. Limite a posts.
- Mostrar posts sem relação real. Quando a taxonomia é bagunçada, o plugin cai no fallback e mostra qualquer coisa. Revise as categorias antes.
- Ignorar o cache. Plugin de relacionados sem cache de página é consulta a cada visita.
- Não testar com usuário logado. É aí que o cache não cobre e o peso aparece.
- Esquecer o mobile. O bloco pode empurrar o conteúdo para baixo e piorar a experiência no celular.
Prevenção para quem cuida de vários sites
Se você administra uma carteira de sites, trate o bloco de relacionados como qualquer outro recurso que consome banco: entre na lista de itens a medir depois de cada atualização. Uma atualização de plugin pode mudar a consulta e o tempo de resposta sem aviso. Por isso, vale ter uma checagem automática de performance rodando em todos os sites, como em checagem automática de performance: monitore vários sites.
Quando o mesmo plugin de posts relacionados WordPress está em dez sites, o teste que você faz em um não vale para os outros: volume de posts, tema e cache mudam o resultado. É aí que faz diferença ter um painel único para acompanhar tempo de resposta, atualizações e backups de todos os sites de uma vez, em vez de abrir site por site. O 100% WP existe para esse cenário de carteira, e o ganho aparece justamente quando o problema se repete em vários clientes.
Quando chamar alguém
Você consegue resolver sozinho se o teste mostrar que o plugin adiciona uma ou duas consultas e o cache cobre o visitante anônimo. Chame ajuda quando o tempo de resposta subir mesmo com cache ativo, quando a tela de edição travar ao publicar, ou quando o site tiver milhares de posts e você não puder mexer no tema. Nesses casos, o caminho costuma ser reescrever o bloco por código ou trocar a estratégia de relacionamento, e isso exige acesso ao servidor e conhecimento de WP_Query. Se o plugin estiver quebrado e derrubando o site, o serviço de plugins quebrados cobre esse tipo de intervenção.
Em resumo: posts relacionados WordPress vale a pena quando aumenta páginas por sessão e o cache absorve a consulta. Pesa quando a base é grande, a consulta é textual e o visitante logado escapa do cache. Meça antes e depois, e decida com número, não com impressão.
