Add as a preferred source on Google
Vamos imaginar o cenário. Seu novo chatbot do WooCommerce passa em todos os testes. Ele responde a perguntas sobre produtos, ajuda os compradores a comparar opções e responde com rapidez suficiente para que ninguém pense duas vezes no desempenho.
O problema só aparece quando a loja tem uma tarde movimentada. A finalização de compra começa a demorar um pouco mais, e os tempos de resposta aumentam gradualmente à medida que as threads PHP atingem sua capacidade. No início, a lentidão parece ser resultado de um pico de tráfego, mas o número de visitantes é praticamente o mesmo da semana anterior. O que mudou foi a quantidade de trabalho que o servidor realiza durante cada visita.
Cada interação com o chatbot pode acionar uma chamada de API em tempo real que passa pelo WordPress, ignora o cache de página e ocupa uma thread PHP enquanto o provedor do modelo gera a resposta. Ela também pode consultar o banco de dados em busca de detalhes dos produtos, histórico da conversa ou outro contexto. O comprador vê uma resposta chegar em dois segundos. O servidor vê uma thread que não pode usar para nenhuma outra tarefa durante esse período.
Essa questão de infraestrutura está se tornando cada vez mais difícil de ignorar. O WordPress 7.0 incorporou a IA ao núcleo por meio de um AI Client independente de provedor, juntamente com a Abilities API e uma central de Connectors.
A mesma pressão pode vir de funcionalidades que parecem muito diferentes à primeira vista. Pesquisa com IA, recomendações de produtos, conteúdo personalizado, ferramentas editoriais e integrações com agentes interagem com o WordPress de maneiras distintas. Saber se elas são executadas no painel de controle, no frontend ou por meio de uma API (e se as solicitações podem ser armazenadas em cache) ajuda a planejar os recursos de servidor necessários.
Como a IA no WordPress realmente funciona em um site em produção
A IA no WordPress não representa uma única carga de trabalho. O local e o momento em que a funcionalidade é executada, bem como se ela é acionada por um visitante, afetam o perfil da infraestrutura.
Chatbots de IA e assistentes de suporte
Esta é a categoria mais visível. Plugins como AI Engine (com mais de 100 mil instalações ativas), MxChat e Tidio adicionam interfaces de conversação ao frontend.
Cada mensagem pode iniciar uma solicitação dinâmica, recuperar o contexto, chamar um modelo externo e armazenar os dados da conversa. Diferentemente do envio de um formulário de contato, uma única conversa pode gerar várias dessas solicitações em rápida sequência.
Personalização, recomendações e pesquisa com IA
A personalização, as recomendações e a pesquisa com IA geralmente são executadas no frontend. Em uma loja WooCommerce, isso pode significar ajustar as sugestões de produtos com base no que um comprador já visualizou ou interpretar uma consulta de pesquisa em vez de procurar uma correspondência exata com as palavras usadas. Muitas vezes, o restante da página pode vir do cache, mas esses resultados ainda precisam ser gerados para cada solicitação individual.
Geração de conteúdo com IA e ferramentas editoriais
Pense em ferramentas como Jetpack AI, Rank Math Content AI, Divi AI e GetGenie. Elas são executadas principalmente no painel de controle do WordPress.
Como essas ferramentas são executadas principalmente no painel de controle do WordPress, geralmente não tornam o carregamento das páginas no frontend mais lento. Ainda assim, elas podem exercer uma pressão considerável sobre o servidor quando vários editores as utilizam ao mesmo tempo.
Agentes de IA e integrações com MCP
As integrações com MCP não esperam que alguém visite o site. O suporte a MCP do AI Engine e o WordPress MCP Adapter oficial permitem que uma ferramenta externa se conecte ao WordPress e execute tarefas aprovadas, como ler dados do site ou atualizar um artigo. Cada tarefa chega como uma solicitação de API autenticada, adicionando outra fonte de atividade do servidor a ser considerada.
Dois sites podem usar IA e precisar de níveis muito diferentes de recursos de hospedagem. Um deles pode usá-la ocasionalmente no editor para sugerir títulos, enquanto outro gera recomendações de produtos para cada comprador. Para estimar o impacto, observe onde a funcionalidade é executada e com que frequência ela aciona uma solicitação ao WordPress.
O que as funcionalidades de IA realmente fazem com seu servidor
O custo de uma funcionalidade de IA vem do trabalho envolvido na geração da resposta do modelo. O WordPress ainda precisa receber a solicitação, executar o código do plugin, recuperar todos os dados necessários, entrar em contato com o provedor externo e retornar o resultado. Quatro partes desse processo têm maior impacto sobre o desempenho.
As threads PHP permanecem ocupadas por mais tempo
O conteúdo armazenado em cache pode ser servido sem usar uma thread PHP. Uma solicitação dinâmica de IA precisa ser processada por uma thread, e cada thread processa apenas uma solicitação por vez. Se um chatbot aguardar dois segundos por um provedor externo, a thread PHP que processa essa interação poderá permanecer ocupada durante esses dois segundos. Quando conversas simultâneas usam todas as threads disponíveis, outras solicitações não armazenadas em cache entram em uma fila.
Isso é estruturalmente semelhante aos padrões de tráfego de bots documentados no Relatório de Tráfego de IA e Bots da Kinsta. Os bots que acessam endpoints de pesquisa, carrinho e outros endpoints dinâmicos ocupam threads PHP e forçam o processamento no servidor de origem. As funcionalidades de IA fazem a mesma coisa intencionalmente e, de preferência, de forma produtiva. O custo de infraestrutura de cada solicitação permanece semelhante.
Mais solicitações ignoram o cache
Muitas respostas de IA são específicas para a pessoa que faz a solicitação, portanto, não podem simplesmente ser reutilizadas para o visitante seguinte. A página principal do produto ainda pode ser carregada do cache, mas um painel de recomendações ou resultado de pesquisa com IA precisa ser gerado separadamente. Quanto mais vezes isso ocorre durante uma visita, mais solicitações o servidor de origem precisa processar.
A atividade do banco de dados se torna mais complexa
Antes de enviar um prompt, um plugin pode precisar obter do WordPress detalhes dos produtos, mensagens anteriores ou informações sobre o usuário. Como os dados mudam de uma solicitação para outra, é mais difícil armazená-los em cache do que uma consulta de página comum. Se muitas dessas solicitações chegarem ao mesmo tempo, elas aumentarão a atividade do banco de dados enquanto as páginas de finalização de compra e da conta tentam executar suas próprias tarefas.
A latência de APIs externas passa a fazer parte do desempenho do site
Os plugins de IA frequentemente precisam aguardar um serviço de terceiros antes de concluir uma solicitação. Se a OpenAI levar três segundos para responder, o WordPress também ficará aguardando e, em uma chamada síncrona, o mesmo ocorrerá com a thread PHP que a processa. O plugin deve ter um tempo limite para que uma chamada paralisada não permaneça aberta indefinidamente. Algumas cargas de trabalho também podem ser colocadas em uma fila ou armazenadas em cache, embora um chatbot em tempo real geralmente precise aguardar o provedor.
O próprio WordPress 7.0 oferece um exemplo útil. A equipe do núcleo removeu a colaboração em tempo real da versão após os testes levantarem preocupações relacionadas à carga do servidor, ao uso de memória e às condições de corrida. A funcionalidade ainda tinha valor, mas não estava pronta para ser incluída na versão dentro dos limites de desempenho que o núcleo do WordPress precisava atender.
As três características de hospedagem mais importantes para o WordPress com IA
As cargas de trabalho de IA são dinâmicas, apresentam picos repentinos e frequentemente dependem de serviços externos ao ambiente de hospedagem. Três características da hospedagem determinam se essas solicitações permanecem isoladas e podem ser diagnosticadas ou se começam a afetar o restante do site.
1. Arquitetura de contêineres isolados
Isso pode ser um problema na hospedagem compartilhada, em que seu site não é o único a utilizar o servidor. Se a atividade de IA aumentar repentinamente, ela poderá consumir parte dos recursos de CPU, memória e banco de dados disponíveis para outros sites na mesma máquina.
A Kinsta executa cada site WordPress em seu próprio contêiner Linux isolado, com uma stack de software dedicada que inclui Nginx, PHP e MySQL. Cada site também recebe sua própria alocação de threads PHP e memória. Se um chatbot de IA processar repentinamente dezenas de conversas simultâneas, sua carga de trabalho permanecerá dentro do contêiner desse site, em vez de usar recursos atribuídos a outro site.
Esse isolamento é especialmente valioso para agências. Um plugin de IA mal configurado no site de um cliente ainda pode prejudicar esse site, mas o problema não se propaga para o restante do portfólio.
2. Uma versão atual do PHP e uma configuração adequada
O PHP 7.4 executará o WordPress 7.0, mas não é a versão que você escolheria visando ao desempenho. O PHP 8.x processa o código do WordPress com mais rapidez, portanto, o trabalho relacionado a uma solicitação de IA leva menos tempo, e a thread PHP fica disponível mais rapidamente.
Uma versão mais recente do PHP não pode fazer a OpenAI ou a Anthropic responderem mais rapidamente, mas pode reduzir o trabalho que o WordPress realiza antes e depois dessa chamada externa. A Kinsta oferece suporte a versões do PHP até a 8.5 e permite alterar as versões de ambientes de produção ou de teste individualmente no MyKinsta. Testar primeiro a alteração no ambiente de teste ajuda a identificar conflitos de compatibilidade no plugin de IA, no tema ou no código personalizado.
3. Visibilidade de toda a solicitação
Os problemas de desempenho da IA podem ter origem em vários pontos: no código PHP do plugin, em uma consulta ao banco de dados, no provedor externo do modelo ou na capacidade insuficiente de threads. Sem dados no nível da solicitação, todos os quatro podem parecer uma lentidão geral da hospedagem.
A ferramenta APM da Kinsta separa esses componentes.
Uma investigação prática pode seguir estas etapas:
- Verifique Análises > Desempenho para confirmar quando os tempos de resposta aumentaram.
- Abra APM > Transações para identificar os endpoints e as solicitações mais lentos.
- Analise APM > Externo para medir as chamadas à OpenAI, à Anthropic ou a outro provedor.
- Verifique APM > Banco de dados para identificar consultas de personalização lentas ou repetidas.
- Analise Principais solicitações que ignoraram o cache do servidor para ver quais caminhos acionados por IA estão chegando ao servidor de origem.
Depois de identificar onde o tempo foi gasto, você terá um ponto de partida útil. Uma transação lenta do WordPress exige uma correção diferente daquela necessária para um banco de dados sobrecarregado ou uma API de modelo que leva vários segundos para responder.
As funcionalidades de IA também alteram o perfil de tráfego do seu site
A IA pode aumentar a demanda de infraestrutura em ambas as direções. Seu site WordPress envia mais solicitações aos provedores de modelos, enquanto sistemas automatizados enviam mais solicitações ao seu site.
A publicação assistida por IA pode ampliar rapidamente a área de rastreamento de um site. Se uma equipe de mídia aumentar sua produção de cinco para vinte artigos por semana, o site adicionará mais URLs, links internos, arquivos e paginação para os crawlers explorarem. Os crawlers não necessariamente sabem ou se importam que a IA ajudou a produzir o conteúdo. Eles simplesmente encontram uma biblioteca maior e atualizada com mais frequência e retornam para rastreá-la.
Um milhão de solicitações de páginas armazenadas em cache impõe uma carga muito diferente ao servidor em comparação com um milhão de solicitações a URLs dinâmicas. Na análise da Kinsta de mais de 10 bilhões de solicitações, os crawlers acessaram repetidamente resultados de pesquisa, páginas de produtos filtradas, links de adicionar ao carrinho e endpoints semelhantes. Cada solicitação pode ignorar o cache e enviar trabalho ao PHP e ao banco de dados.
Isso coloca o tráfego automatizado em concorrência com as próprias funcionalidades de IA do site. Uma solicitação de chatbot e um crawler acessando um filtro de produtos dinâmico podem ter finalidades completamente diferentes, mas ambos podem ocupar threads PHP. Se os crawlers consumirem uma parcela considerável da capacidade disponível do site, as solicitações legítimas de chatbot, pesquisa e recomendação terão menos capacidade para serem executadas.
Um site com IA precisa ter margem de capacidade suficiente para as solicitações que seus visitantes realmente fazem. Os controles de bots ajudam a preservar essa margem. O Googlebot ainda precisa acessar as páginas que você deseja indexar, e você pode decidir que vale a pena permitir alguns Crawlers de IA. O tráfego que deve ser eliminado é a atividade repetida em endpoints dinâmicos que não gera valor, mas ainda ocupa threads PHP.
A Proteção contra Bots da Kinsta oferece controles no nível do ambiente para permitir, desafiar ou bloquear o tráfego automatizado, incluindo uma opção separada para Crawlers de IA. Suas análises mostram como as solicitações são classificadas e processadas.
As análises de bots são apenas uma parte do cenário. Compare-as com os rastreamentos do APM, os relatórios de solicitações que ignoram o cache e os principais IPs de clientes no MyKinsta. Isso facilita identificar se a carga vem das suas próprias funcionalidades de IA ou de crawlers externos e se as solicitações desses crawlers justificam os recursos que consomem.
O que verificar antes de adicionar uma funcionalidade de IA a um site WordPress
Antes de colocar uma funcionalidade de IA em produção, teste como ela se comporta em sua infraestrutura atual. Comece com estas cinco perguntas.
1. Em que ponto do ciclo da solicitação esse plugin é executado?
O caminho da solicitação é importante nesse caso. As ferramentas de escrita e edição geralmente mantêm suas operações no wp-admin. As ferramentas voltadas aos clientes compartilham a capacidade do PHP com o restante do frontend, incluindo as páginas de finalização de compra e da conta. Um agente pode ignorar ambos os caminhos e acessar o site por meio da API. Verifique o fluxo de solicitações do plugin antes de estimar a capacidade necessária.
2. O que o plugin pode armazenar em cache?
Descubra exatamente o que o plugin exclui do cache. Talvez a própria resposta precise permanecer dinâmica, pois muda conforme o prompt ou o usuário, mas dados relacionados, como o estado da conversa, os resultados da pesquisa ou as recomendações, podem ser reutilizados por um curto período. Um endpoint de API dedicado e não armazenado em cache consome muito menos recursos do que um plugin que torna dinâmica toda a página do produto.
3. O que acontece quando a API externa está lenta?
Teste também uma chamada que falha, não apenas uma chamada lenta. Interrompa temporariamente a conexão no ambiente de teste e observe quando a solicitação é encerrada. Alguns plugins tentam novamente de imediato; outros permanecem abertos até que o PHP os encerre. Se várias solicitações do chatbot fizerem isso ao mesmo tempo, as solicitações de finalização de compra e da conta talvez precisem aguardar uma thread PHP.
4. Teste primeiro no ambiente de teste com a ferramenta APM em execução
Instale o plugin em um ambiente de teste e ative a ferramenta APM da Kinsta durante os testes. Reproduza conversas, pesquisas ou fluxos de trabalho de geração de conteúdo comuns, incluindo atividades simultâneas quando apropriado. Analise as abas Transações, Externo e Banco de dados para determinar quanto tempo as solicitações levam e onde esse tempo é gasto.
5. O PHP está preparado para o trabalho adicional?
Registre como o site no ambiente de teste se comporta antes de alterar o PHP. O MyKinsta mostra se ele já está atingindo o limite de threads PHP, além de fornecer dados sobre o tempo de resposta e o uso de memória. Altere o ambiente de teste para uma versão atual do PHP 8.x, repita os mesmos fluxos de trabalho e confirme se o plugin continua funcionando antes de fazer a alteração em produção.
O ambiente de teste não reproduzirá perfeitamente o ambiente de produção. Ainda assim, ele pode mostrar se o plugin faz com que solicitações demais ignorem o cache, aguarda por muito tempo uma API externa, executa consultas que consomem muitos recursos ou deixa pouca capacidade do PHP disponível para o restante do site.
Trate cada lançamento de IA como uma alteração na infraestrutura
O WordPress 7.0 oferece aos desenvolvedores uma maneira padronizada de integração com provedores de IA e de chamada de modelos pelo WordPress. O servidor ainda precisa processar essas solicitações quando a funcionalidade entra em produção.
Antes de alterar a configuração de hospedagem, abra alguns rastreamentos do APM. A lista de plugins não mostrará quanto trabalho o site está realizando, e a quantidade de threads PHP não explicará por que uma solicitação está lenta. Um rastreamento mostra se a solicitação ignorou o cache, quanto tempo o PHP levou para processá-la e se o atraso veio do banco de dados ou da API do modelo. A partir dessas informações, você pode decidir se o plugin precisa de ajustes ou se o site precisa de mais capacidade.
Um plugin de IA pode funcionar perfeitamente e, ainda assim, não ser adequado à capacidade atual do site. Antes de instalá-lo no site de um cliente, execute o APM no ambiente de teste e verifique quanto tempo levam as chamadas para APIs externas, quais solicitações não são atendidas pelo cache e qual versão do PHP o ambiente utiliza. Verifique esses números novamente após o lançamento, quando o tráfego real também estiver presente.
Essas poucas verificações podem identificar a pressão sobre as threads, dependências lentas e comportamentos de consultas que consomem muitos recursos antes que resultem em um site lento — ou em uma conversa difícil com o cliente.
Carlo é um apaixonado por webdesign e desenvolvimento frontend. Ele tem mais de 10 anos de experiência com WordPress e colaborou com diversas universidades e instituições educacionais na Itália e na Europa. Carlo já publicou inúmeros artigos e guias sobre WordPress, tanto em sites italianos quanto internacionais, além de revistas impressas. Você pode seguir ele no LinkedIn e no X.
