Triagem de desempenho do WPML – painel de administração lento, esgotamento de tempo limite 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 é a configuração de cache de página inteira ou um plugin pesado no front-end.
• Painel de administração lento, front-end normal → provavelmente é inchaço de carregamento automático em wp_options, um plugin pesado apenas para o painel de administração ou um servidor com pouca potência.
• 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 WPMLSuporte (veja em Logs qual log responde a qual sintoma).

Verifique os recursos do servidor

Abra WPMLSuporte. O painel de avisos na parte superior sinaliza a memória PHP 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; é raro precisar de 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 costumam ter 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 a partir do banco de dados em cada requisição. Adicione Redis ou 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 ativam isso).

A melhoria costuma ser grande. As configurações que antes exigiam acessos 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á tiver um, mas as páginas ainda parecerem lentas, verifique se o seu cache está lidando corretamente com os URLs por idioma. A estrutura de URL do WPML (seja idioma como diretório, idioma como subdomínio ou idioma como domínio) precisa que o cache varie de acordo com o 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 a aba Consultas por componente. 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 parecerem lentos, mas o próprio site estiver normal, o gargalo está entre o seu site e a infraestrutura de tradução do WPML.

Verifique em WPMLSuporteLog de comunicação. O log mostra a latência de cada chamada de API. Se 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 culpado for o próprio cache do WPML, 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 análise do Suporte, empacote o que você encontrou por meio do compartilhamento de informações de depuração com o suporte.