Inicio›Soporte›Soporte en español›[A la espera de la opinión de los usuarios] Severe performance issues caused by WPML String Translation
[A la espera de la opinión de los usuarios] Severe performance issues caused by WPML String Translation
Este es el foro de soporte técnico de WPML, el plugin multilingüe de WordPress.
Todas las personas pueden leerlo pero solo los clientes de WPML pueden ingresar comentarios. El equipo de WPML responde en los foros 6 días a la semana, 22 horas por día.
Sun
Mon
Tue
Wed
Thu
Fri
Sat
-
-
9:00 – 18:00
9:00 – 18:00
9:00 – 18:00
9:00 – 18:00
9:00 – 18:00
-
-
-
-
-
-
-
Zona horaria del soporte: America/Lima (GMT-05:00)
We have been working extensively on our website’s performance over the past weeks, and both our hosting provider and performance analysis tools indicate that there are significant delays in page load times caused by WPML components, specifically WPML String Translation.
Our server provider has confirmed that the processes related to strings are generating excessive load and have a direct impact on TTFB and overall response time. Additionally, we have consulted multiple technical analysis platforms (including AI-based tools), and all of them point to the same conclusion: the main performance bottleneck is the String Translation plugin.
The consistent feedback we receive is that WPML — and especially the String Translation module — has serious performance issues, to the point where some recommendations are to stop using WPML altogether. This is obviously not the solution we are looking for.
Our intention is not to invest time in building custom plugins or alternative solutions, but rather to receive an official solution from your side, as everything clearly indicates that the delay is caused by WPML String Translation.
It is also important to note that we contacted your support some time ago, followed all the recommendations provided at that time, and unfortunately the situation remains exactly the same. We have not seen any real improvement in performance.
For this reason, we kindly ask you to review this case in depth and provide a satisfactory and definitive solution, as the performance impact is critical for our project.
Zona horaria: America/Argentina/Buenos_Aires (GMT-03:00)
Hola Xavi,
¿Dónde observas el problema de performance? ¿Front end, back end, en alguna/s página/s en particular?
En muchos casos, si bien las herramientas y los logs apuntan a WPML, el problema de performance surge de un problema de compatibilidad.
Para verificarlo, si es posible para ti, haz la siguiente prueba:
**Antes de continuar, haz un backup completo y confiable.**
1. Desactiva todos los plugins excepto WooCommerce, WPML y sus complementos.
2. Cambia a un tema por defecto de WordPress (por ejemplo, Twenty Twenty-Five).
3. Si el problema desaparece, reactiva los plugins uno por uno hasta identificar cuál causa el conflicto.
Si aún con un setup mínimo el problema persiste, para investigar mejor el problema, ¿puedes proporcionarme acceso temporal a tu sitio?
**Importante:**
- **Haz un backup** de tu sitio antes de compartir los datos.
- Si no ves un formulario privado para ingresar las credenciales, **no las publiques** en el foro.
¿Si fuera necesario, podría replicar tu sitio localmente instalando un plugin (Duplicator o WP All in One Migration)? Una vez resuelto el problema, borraré la copia.
Zona horaria: America/Argentina/Buenos_Aires (GMT-03:00)
Hola,
Gracias.
Antes de continuar, ¿podrías actualizar el tema y los plugins con un update disponible y chequear si el problema persiste? ❌ Por favor, antes que nada: haz un backup de tu sitio ❌
Por otro lado, he navegado el sitio y no he notado un problema severo de performance. Podrías indicarme una o dos páginas de ejemplo para que podamos tomar de referencia y comparar el rendimiento con y sin WPML y una vez que encontremos la causa y la solución: antes y después.
Everything is up to date and backed up. The slowest section is this one: enlace oculto
As you can also see in this screenshot, the issue is the time until the page starts rendering. We’ve checked it from the server side, and what happens during this delay—before the page loads—is related to WPML strings. Please review this urgently.
Zona horaria: America/Argentina/Buenos_Aires (GMT-03:00)
Hola,
Gracias.
He intentado hacer una copia del sitio para investigar el problema en mi entorno local. Pero tanto All In One Wp Migration (banned) como Duplicator fallan en el sitio.
Por favor, prueba la siguiente:
Ve a WPML -> Support -> Troubleshooting y haz click en "Cleanup and optimize string tables"
Si el problema persiste, ¿podrías proveerme una copia de la DB y de la carpeta wp-content (excluyendo Uploads para que no pese tanto)?
We’ve been looking into this in depth and we’ve noticed that resource usage is drastically reduced when the Translate Slugs option in WPML is disabled. The issue is that we can’t do this right now because all the URLs would change. We’ll think about how to handle that, but this could be a large part of the problem.
In any case, if you can think of anything else, we’re happy to take a look at that as well.
Thanks for sharing the debug information. I can confirm that slug translation is currently enabled for several custom post types, including long-content, long-content_42, long-content_71, and others. These post types are not part of WordPress, WooCommerce, or WPML, so they must be registered by your theme or another plugin.
Translating slugs for custom post types adds extra lookups to the String Translation tables on every request, which can significantly increase TTFB on larger sites. This matches the performance issues you’re seeing.
To help narrow this down, could you temporarily disable slug translation only for these custom post types and check whether the performance improves?
You can do this in:
WPML → Settings → Post Types Translation → “Translate custom post slugs”
If disabling slug translation for these custom types resolves the slowdown, we can then decide together which post types actually need translated URLs and which can safely remain un-translated.
Hi Andreas,
We did it and the performance improved immediately.
The issue is that we already have the URLs indexed with the translated slugs.
Would it be possible to translate the slugs manually, or something similar, so they don’t have to be recalculated all the time?
Does this mean you can narrow down that this issue is related only to queries coming from those custom post types?
Please name me an example where I can see the issue.
Examples: enlace oculto
Page Load Time averages 3.50 seconds.
enlace oculto
Page Load time averages 3.80 seconds.
Note that a load time increase due to WPML is currently expected to be between 0.3 to 0.7 seconds.
To analyze this further, I can offer to take a local copy of the site and compare how long the original content takes to load without running WPML.
If you have a better example with a significantly higher load time, then please let me know.
Further, make sure to update our plugins. The new versions do come with some performance fixes. Also, make sure that all additional plugins are updated.
Also, take note that WPML String Translation uses .mo files instead of database calls. WPML needs to generate these .mo files in order for translations to appear on the front-end. I have now used WPML's troubleshooting options to generate those files, which should enhance the performance.
The issue is not related to custom post types. The main problem is the shop, which is very slow, and when we run a test directly from the server, it shows that what is causing the slowdown is the loading of strings, specifically those related to rewrites.
When we disable the option to translate strings, the entire website’s performance improves significantly, but we cannot afford to lose the URLs. Is there an option to translate the slugs manually so they don’t have to be recalculated all the time?
So I understand that you have already generated the .mo files on our website. Could you please let us know exactly what you did and how we can do the same on our side?
It is sadly not possible for me to create a local copy, as your hosting seems to allow the usage of the plugins "All In One WP Migration" or "Duplicator PRO".
Could you please set up a staging site for testing?
If you are unsure about how to set up a staging environment, please consult your hosting support team.
