WPML y los problemas de rendimiento: qué pesa de verdad y cómo optimizarlo

WPML es uno de los plugins multilingües más usados en WordPress y también uno de los que más se señalan cuando una web va lenta. En este artículo vemos qué partes de WPML tienen coste real (String Translation, carga de archivos de traducción, filtrado por idioma, caché y tablas que crecen), qué ajustes recomienda la propia documentación de WPML, cómo medir el impacto en tu sitio y qué alternativas hay hoy si WPML no encaja.

Qué hace WPML en cada petición

WPML guarda el idioma de cada contenido en su propia tabla, icl_translations. Según su documentación de tablas, cada fila registra el tipo de elemento (element_type), su ID (element_id), el idioma (language_code), el idioma de origen y un identificador de grupo de traducción (trid): las filas que comparten trid son traducciones entre sí.

Eso significa que, además de lo que haría WordPress solo, en cada petición WPML tiene que averiguar el idioma actual, limitar las consultas de contenido a ese idioma, resolver qué traducción corresponde a cada entrada, término o menú y traducir las cadenas de temas y plugins. Nada de esto es gratis, pero tampoco es un coste fijo: depende de cuántos idiomas, contenidos y cadenas tengas, y de cómo esté configurado. Por eso lo primero es medir.

Cómo medir el impacto de WPML en tu sitio

Antes de tocar nada conviene tener una línea base. Nosotros usamos Query Monitor en un entorno de pruebas con la misma base de datos que producción:

1. Carga las mismas URL (portada, un listado, una ficha) en el idioma principal y en un idioma secundario.
2. Anota el número de consultas, el tiempo de base de datos, el tiempo total de generación y la memoria pico.
3. Filtra las consultas por componente para ver cuáles vienen de WPML y cuáles del tema u otros plugins.
4. Repite las mediciones después de cada cambio de configuración, de uno en uno.

Con esto sabrás si el problema está realmente en WPML o en otra parte. Muchas veces la lentitud de una web multilingüe viene del tema, del constructor de páginas o de no tener caché de página, y WPML solo lo amplifica porque multiplica las URL.

String Translation: la pieza que más conviene revisar

String Translation traduce los textos que no son entradas ni páginas: cadenas de temas y plugins, widgets, opciones del panel. Es históricamente la parte de WPML con más coste, y también la que más ha cambiado.

Las traducciones se sirven desde archivos .mo

Desde String Translation 3.0.0 (publicado con WPML 4.3), las cadenas traducidas ya no se leen de la base de datos en cada petición. Según el changelog oficial, WPML genera archivos .mo parciales con las traducciones y los usa para mostrar las cadenas en otros idiomas, en lugar de consultar la base de datos. WPML los regenera cuando traduces cadenas.

Esto tiene una consecuencia práctica si tu web corre en varios servidores (balanceador, contenedores): por defecto WPML solo guarda esos .mo en un servidor, y las peticiones que atienden los demás no traducen las cadenas. La documentación de WPML para varios servidores indica que hay que añadir esta constante en wp-config.php:

define( 'WPML_ST_SYNC_TRANSLATION_FILES', true );

Autorregistro de cadenas y detección en JavaScript

WPML puede registrar automáticamente las cadenas que aparecen en pantalla mientras se navega por el sitio. En la versión actual la opción se llama Auto-register unmanaged strings y está en la utilidad de la pestaña Strings (WPML → Translations → Strings) o en «Detect unmanaged strings», al final del panel de traducciones; ambas controlan el mismo ajuste, según la documentación de cadenas. Que el registro dependa de las visitas implica trabajo extra en el servidor: las notas de String Translation 5.0.0 (13 de septiembre de 2026) corrigen, por ejemplo, los tiempos de espera agotados en sitios con muchas cadenas autorregistradas en el front-end.

Más claro es el caso de Detect strings in JavaScript files (WPML → Settings → String Translation). La documentación de WPML dice que puede afectar al rendimiento y recomienda desactivarla después de traducir las cadenas. Nuestra pauta es la misma para cualquier detección de cadenas: activarla mientras se traduce y desactivarla cuando no hace falta.

Mantén WPML y String Translation al día

Las mejoras de rendimiento de WPML llegan con las versiones. String Translation 5.0.0, por ejemplo, hace que la pantalla de cadenas cargue más rápido con una búsqueda indexada, carga solo las traducciones necesarias al añadir un idioma y limita la memoria de la caché de archivos de idioma traducidos. Actualizar no es un consejo genérico aquí: es una de las palancas reales.

La carga de traducciones en WordPress 6.5 y posteriores

En un sitio multilingüe, cargar archivos de traducción de núcleo, tema y plugins pesa más. WordPress 6.5 cambió esto en el núcleo con la biblioteca que nació del plugin Performant Translations. Según la nota oficial en make.wordpress.org:

• Los archivos .mo se cargan más rápido y con menos memoria, y se pueden tener varios locales cargados a la vez, lo que acelera el cambio de idioma.
• WordPress puede leer traducciones desde archivos PHP (.l10n.php), que aprovechan OPcache. Si existe un .l10n.php junto al .mo, carga el PHP.
• Los paquetes de idioma de WordPress.org incluyen ya los .l10n.php; no hay que hacer nada para el núcleo ni para los plugins y temas del directorio.
• El filtro translation_file_format permite volver a mo si hace falta.

Para un tema o plugin propio, puedes generar los archivos PHP a partir de los .po con wp i18n make-php (WP-CLI 2.10.0 o superior). Si no usas WP-CLI todavía, tenemos una introducción a WP-CLI.

# Genera los .l10n.php de todos los .po del directorio languages
wp i18n make-php languages

Asegúrate también de que OPcache está activo en el servidor; sin él, los archivos PHP de traducción pierden buena parte de la ventaja.

Caché de página por idioma

La forma más eficaz de quitar el coste de WPML en las visitas anónimas es no ejecutarlo: servir HTML desde caché. La única condición es que la caché distinga idiomas, y eso es sencillo si cada idioma tiene su propia URL (directorio /en/, subdominio o dominio), porque la caché indexa por URL.

La guía de rendimiento de WPML, Boosting the performance of your multilingual WordPress site, recomienda justo eso: plugin de caché de página, CDN, optimización de imágenes y de CSS y JavaScript, y un alojamiento adecuado al tráfico. Para WP Rocket, WPML tiene una página de compatibilidad que indica que no necesita configuración especial, que cachea cada idioma por separado y que se puede purgar la caché de un idioma concreto. Si tu servidor usa LiteSpeed, en el blog explicamos cómo configurar LSCache.

Un punto a vigilar es la redirección según el idioma del navegador. La documentación de WPML explica que se hace con JavaScript en el navegador y recuerda las visitas con cookies, por lo que funciona con plugins de caché, pero puede fallar si otro plugin también redirige con JavaScript. Si ves redirecciones raras con la caché activa, desactiva temporalmente esa opción para descartar.

Tablas de WPML que crecen

En sitios con mucho historial de traducciones, las tablas de trabajos de traducción pueden crecer mucho. WPML incluye una herramienta para limpiarlas, documentada en Optimizing WPML database tables:

1. Haz una copia de seguridad completa de la base de datos. WPML advierte de que estas herramientas escriben directamente en sus tablas y pueden perder traducciones.
2. Instala el plugin Troubleshooting desde WPML → Activate & Update (desde WPML 5.0 la herramienta está en ese plugin).
3. Ve a WPML → Support → Database & strings maintenance, sección Database Tables Optimization.
4. Marca la confirmación y pulsa «Optimize translation tables». Actúa sobre wp_icl_translate y wp_icl_translation_status.

La optimización reduce los datos, pero no el tamaño del archivo en disco: para recuperar espacio hay que reconstruir las tablas a mano. Para el resto de la base de datos, tenemos una guía sobre cómo optimizar la base de datos de WordPress.

Traducción automática en WPML hoy

La traducción automática no afecta a la velocidad de carga (las traducciones se guardan en tu sitio), pero ha cambiado bastante y merece una aclaración. WPML presenta ahora como motor principal PTC (Private Translation Cloud), su propio motor de traducción con IA, según la documentación de traducción automática. DeepL, Google Translate y Microsoft Translator siguen disponibles, pero WPML los califica de motores legacy: con soporte completo y recomendados solo para sitios que ya los usan (DeepL, Google Translate, Microsoft Translator). El motor se cambia en WPML → Settings → AI Translation.

Sea cual sea el motor, una persona tiene que revisar las traducciones antes de publicarlas, sobre todo en textos legales, fichas de producto y titulares.

Alternativas a WPML

Si después de medir y optimizar WPML no encaja, estas son las opciones que se mantienen activas hoy. No las ordenamos: cada una parte de un modelo distinto y la elección depende del proyecto.

• Polylang: gratuito en WordPress.org, con una versión Pro de pago que comparte el mismo núcleo. Se apoya en funciones nativas de WordPress como las taxonomías. La traducción automática con DeepL es una función de Polylang Pro.
• TranslatePress: se traduce desde el front-end con un editor visual, y las traducciones se guardan en la base de datos de tu servidor. Admite Google Translate con tu propia clave, DeepL mediante un complemento de pago y su propio servicio de IA.
• Weglot: servicio en la nube con suscripción. Las traducciones se guardan en los servidores de Weglot, no en tu base de datos, y ofrece URL por idioma en subdirectorios o subdominios. A cambio, dependes de un servicio externo.

qTranslate, que aparecía en la versión anterior de este artículo, ya no es una opción recomendable: su autor lo abandonó, y el fork comunitario qTranslate-XT no está en WordPress.org (hay que instalarlo a mano) y se describe a sí mismo como un proyecto puente con nombre y futuro por decidir.

Ten en cuenta que migrar de plugin multilingüe implica mover traducciones, URL y redirecciones. Rara vez compensa solo por rendimiento si antes no has aplicado la caché y los ajustes anteriores.

Resumen: lista de comprobación

• Mide con Query Monitor en el idioma principal y en uno secundario antes de cambiar nada.
• Mantén WPML y String Translation actualizados.
• Desactiva la detección de cadenas en JavaScript y el autorregistro cuando no estés traduciendo.
• En varios servidores, define WPML_ST_SYNC_TRANSLATION_FILES.
• Usa WordPress 6.5 o superior con OPcache, y genera .l10n.php para tus temas y plugins propios.
• Activa caché de página con URL distintas por idioma.
• Si las tablas de WPML han crecido, haz copia de seguridad y usa la herramienta de optimización oficial.

Si quieres seguir con la parte de front-end, en nuestra guía técnica de Core Web Vitals en WordPress vemos cómo medir y mejorar LCP, INP y CLS.