Triagem de desempenho do WPML – painel de administração lento, tempos limite esgotados no Painel de tradução, lentidão no front-end

Confirme onde está a lentidão

• Front-end lento, painel de administração normal → provavelmente é uma configuração de cache de página inteira ou um plugin pesado no front-end.
• Painel de administração lento, front-end normal → provavelmente é um inchaço no autoload de wp_options, um plugin pesado apenas para o painel de administração ou um servidor com pouca capacidade.
• O Painel de tradução especificamente lento → provavelmente há um grande número de posts na consulta do painel e não há memória PHP ou tempo de execução suficientes.
• Operações de tradução lentas → provavelmente é a conectividade com os serviços de tradução; verifique o Log de comunicação em WPML > Suporte (veja em Logs qual log responde a qual sintoma).

Verifique os recursos do servidor

Abra WPML > Suporte. O painel de avisos na parte superior sinaliza se a memória PHP estiver abaixo dos 256 MB recomendados pelo WPML. Sites com catálogos maiores precisam de 512 MB ou mais.

Outros sintomas de recursos do servidor:

• Consultas lentas ao banco de dados. Sites grandes com muitas traduções se beneficiam de um servidor de banco de dados com SSD, innodb_buffer_pool_size suficiente e índices na tabela wp_icl_translations (estes são adicionados pelo WPML; raramente é necessária intervenção manual).
• Tempo de execução do PHP. Se max_execution_time estiver abaixo de 60 segundos e o tempo limite do Painel se esgotar, aumente-o.
• CPU. Planos de hospedagem compartilhada geralmente têm limites agressivos de CPU; verifique com sua hospedagem se você está sofrendo limitação.

Cache de objeto

O WordPress sem um cache de objeto carrega muitas das configurações do WPML do banco de dados a cada requisição. Adicione o Redis ou o Memcached como um cache de objeto (a maioria das hospedagens gerenciadas de WordPress oferece isso; caso contrário, os plugins Redis Object Cache ou WP Redis o ativam).

A melhoria geralmente é grande. As configurações que antes exigiam consultas ao banco de dados passam a ser servidas a partir da memória.

Cache de página inteira

Um cache de página inteira (WP Rocket, W3 Total Cache, cache de borda do provedor de hospedagem) é o maior ganho de desempenho isolado para a velocidade do front-end.

Se você já tem um, mas as páginas ainda parecem lentas, verifique se o seu cache está lidando corretamente com as URLs por idioma. A estrutura de URLs do WPML (seja idioma como diretório, idioma como subdomínio ou idioma como domínio) precisa que o cache varie de acordo com a URL. A maioria dos caches faz isso automaticamente, mas vale a pena verificar se a versão em francês não está sendo servida a partir do cache em inglês ou vice-versa.

Plugins conflitantes ou lentos

Os sites acumulam plugins; alguns são bem construídos e outros não. Para encontrar um plugin lento:

1. Instale o Query Monitor (um plugin de depuração).
2. Recarregue uma página lenta.
3. Observe as Queries by Component. O plugin com as consultas mais pesadas é o suspeito.

Se um plugin for a causa, substitua-o ou desative o recurso nele que está causando a lentidão.

Serviços de tradução lentos, não o site

Se os trabalhos de tradução parecem lentos, mas o site em si está normal, o gargalo está entre o seu site e a infraestrutura de tradução do WPML.

Verifique WPML > Suporte > Log de comunicação. O log mostra a latência de cada chamada de API. Se as chamadas individuais estiverem levando muitos segundos, o problema é a conectividade (caminho de rede, DNS ou limitação de saída do seu provedor de hospedagem), não o site. Se, em vez disso, o próprio cache do WPML for o culpado, as Ferramentas de solução de problemas de nível seguro incluem Limpar o cache no WPML. Quando a investigação de desempenho precisar da atenção do Suporte, empacote o que você encontrou por meio de Compartilhar informações de depuração com o suporte.