“Não coloco o site em vários idiomas porque o plugin vai deixar ele lento.” É uma das objeções mais repetidas e uma das mais mal fundamentadas: na maioria das auditorias, o plugin de linguagem é o quarto fator, muito atrás das imagens e da acomodação.
Isso não significa que não pese. Isso significa que é aconselhável medi-lo em seu site antes de culpar o suspeito errado.
Direto ao ponto: Um plugin multilíngue adiciona consultas ao banco de dados em cada página e em sites com vários idiomas que ele mostra. Mas se o seu site demorar três segundos para carregar, o plugin de idioma não é a causa: quase sempre são as imagens não otimizadas. Meça antes de decidir.
O que exatamente cada arquitetura faz?
Nem todos têm o mesmo peso e a diferença está na forma como salvam as traduções.
Taxonomia nativa (Polylang)
Declare o idioma como outra taxonomia do WordPress. Cada entrada traduzida é uma entrada normal com um termo atribuído. O WordPress faz o que já sabe fazer, com suas próprias consultas e cache otimizados. É a arquitetura mais leve, e não é uma opinião: acrescenta menos maquinaria do que qualquer outra.
Tabelas próprias (WPML)
Crie suas tabelas para relacionar traduções e armazenar strings. Mais poderoso – permite o gerenciador, status, trabalhos em lote – mas cada página precisa de consultas adicionais para decidir qual versão servir e quais links pintar. Em sites grandes com seis ou sete idiomas é onde isso é mais perceptível.
Tabla de Cadenas (TranslatePress, WP-Translate)
Eles mantêm uma tabela de strings traduzidas e consultam-na ao pintar a página. O custo depende quase inteiramente de haver cache na memória: com o mapa de tradução armazenado em cache, é uma leitura; sem ele, é uma consulta para cada visita.
Atendimento externo (Weglot, GTranslate)
Praticamente não tocam no seu servidor: o trabalho é feito pela sua infraestrutura. Em troca, você depende do tempo de resposta deles e suas traduções não são suas, como vemos em Weglot vs WPML.
Como realmente medir isso em seu site
A única maneira honesta é comparar a mesma página com o plugin ativo e desativado. Dez minutos:
- Escolher uma página representativa: não a capa (geralmente atípica), mas uma entrada normal ou ficha de produto.
- Com o plugin ativo, meça três vezes seguidas com PageSpeed Insights ou WebPageTest e observe o TTFB (tempo até o primeiro byte) e o PCL.
- Desative o plugin de idioma e limpe todo o cache.
- Meça o mesmo URL mais três vezes.
- Compare o médio, não é a melhor nem a pior marca.
- Reative o plugin.
Ojo: faça isso em uma cópia de prova, não em produção. Desativar o plug-in multilíngue em um site ativo deixa temporariamente os URLs traduzidos inutilizáveis e, se o Google passar nesse momento, você encontrará erros 404 nas páginas indexadas. Nunca vale a pena o tempo que você economiza.
Interprete o resultado:
- Menos de 50 ms de diferença no TTFB: o plugin não é problema seu. Procure em outro lugar.
- Entre 50 e 200ms: É pesado, mas há espaço para otimização antes de trocar de ferramenta.
- Mais de 300ms: merece investigação. Geralmente é um cache mal configurado, não o plugin em si.
O que realmente torna um site lento
| Causa | Freqüência | Pendência |
|---|---|---|
| Imagens não otimizadas | Muito alto | WebP, tamanhos corretos, loading="lazy" |
| Hospedagem compartilhada saturada | Alta | Assista ao TTFB; alterar planos ou provedores |
| Layout com CSS e JS de sobra | Alta | Exclua recursos não utilizados |
| Muitos plug-ins ativos | Mídia | Audite e remova o que não é usado |
| Sem cache de página | Mídia | Ative o cache e verifique se funciona |
| Plug-in de idioma | Baixa | Cache de objetos; verifique o número de idiomas |
A ordem é importante. Otimizar o plugin de idioma quando você tem imagens descompactadas de 3 MB está funcionando no lugar errado.
Como reduzir o custo do multilíngue
Se você já mediu e o plugin pesa no seu caso:
1. Cache de páginas, bem configurado por idioma. É o que tem maior impacto, de longe. Um plugin de cache mal configurado em um site multilíngue pode servir a versão em cache do idioma errado; Verifique se o seu plugin de cache entende os idiomas e salve uma cópia para cada um.
2. Caché de objetos (Redis o Memcached). É aqui que isso é mais perceptível nas arquiteturas de tabelas de strings: o mapa de tradução é carregado uma vez e reutilizado. Muitos hosts decentes oferecem ativação com um clique.
3. Menos idiomas. O custo aumenta com o número de idiomas ativos, não com o número de visitas. Cinco idiomas mantidos pela metade pesam o mesmo que cinco idiomas bem mantidos e têm desempenho muito menor. Como decidir com dados, em quantos idiomas seu site deve ter.
4. Otimize primeiro o acima. As imagens, a hospedagem e o designer do layout vêm em primeiro lugar. E as imagens em um site multilíngue têm seu próprio truque: a mesma imagem funciona para todos os idiomas, portanto, otimizá-la já ajuda muito. Nós cobrimos isso otimização multilíngue de imagens e metadados.
Conselho: verifique se você plugin de cache entende idiomas antes de mais nada. É o erro que mais se confunde com “o plugin de idioma está lento”: o cache salva uma única versão e serve para todos, então alguns visitantes veem o idioma errado e o plugin acaba funcionando duas vezes mais. Quase todos os plugins de cache possuem uma configuração específica para isso.
O custo de não traduzir
Vale a pena contextualizar a figura. Supondo um pior caso razoável – 200 ms a mais de TTFB – esse é o tempo necessário para carregar duas imagens mal otimizadas. Em troca, o seu site existe em um mercado onde não existia antes.
Se o desempenho é sua principal preocupação, a ordem correta é: otimizar primeiro o topo da tabela, medir depois e decidir com números. Quase sempre há muito espaço.
WP-Translate armazena em cache o mapa de traduções na memória e nos transientes, para que a maioria das visitas não consulte o banco de dados em busca de traduções. Você mesmo pode medi-lo com o versão gratuita seguindo o método acima, que é a única coisa que realmente responde a essa pergunta para o seu site.
Perguntas frequentes
Qual é o plugin multilíngue mais rápido?
Polylang, para arquitetura. Se sua única prioridade é o desempenho e você tem alguém para escrever cada idioma, é difícil superá-lo. As alternativas estão em Alternativas Polylang.
Isso afeta Core Web Vitals?
Pode afetar o TTFB, o que influencia o LCP. Não afeta CLS ou INP, que dependem do tema e do JavaScript.
Mais idiomas são mais lentos?
Sim, mas não linearmente. O que cresce a cada linguagem é o trabalho de resolução de links e pintura do seletor. Conteúdo em idiomas que ninguém visita não custa nada.
E se eu usar um CDN?
Ajuda muito, desde que esteja configurado para cache por idioma. Se você não for sensível ao idioma, a versão errada poderá servir — o mesmo problema do cache de página, mas mais difícil de detectar.
Continuar lendo
Esta peça faz parte do guia WordPress multilíngue, onde está o tour completo: estrutura de URL, escolha de plugin, tradução automática, SEO e orçamento.
- hreflang com Yoast SEO - o que realmente cobre e o que você precisa concluir
- conteúdo duplicado em sites multilíngues - quando o Google não penaliza você e quando o faz
- Erros de SEO multilíngue — 9 erros de SEO multilíngues que afundam um site (e como detectá-los hoje)