«No pongo la web en varios idiomas porque el plugin me la va a ralentizar.» Es una de las objeciones más repetidas y una de las peor fundamentadas: en la mayoría de auditorías, el plugin de idiomas es el cuarto factor, muy por detrás de las imágenes y del alojamiento.
Eso no significa que no pese. Significa que conviene medirlo en tu web antes de culpar al sospechoso equivocado.
Al grano: un plugin multiidioma añade consultas a la base de datos en cada página, y en sitios con muchos idiomas se nota. Pero si tu web tarda tres segundos en cargar, el plugin de idiomas no es la causa: casi siempre son las imágenes sin optimizar. Mide antes de decidir.
Qué hace exactamente cada arquitectura
No todos pesan igual, y la diferencia está en cómo guardan las traducciones.
Taxonomía nativa (Polylang)
Declara el idioma como una taxonomía más de WordPress. Cada entrada traducida es una entrada normal con un término asignado. WordPress hace lo que ya sabe hacer, con sus propias consultas optimizadas y su caché. Es la arquitectura más ligera, y no es opinión: añade menos maquinaria que cualquier otra.
Tablas propias (WPML)
Crea sus tablas para relacionar traducciones y guardar cadenas. Más potente —permite el gestor, los estados, los trabajos por lotes— pero cada página necesita consultas adicionales para resolver qué versión servir y qué enlaces pintar. En sitios grandes con seis o siete idiomas es donde más se nota.
Tabla de cadenas (TranslatePress, WP-Translate)
Guardan una tabla de cadenas traducidas y la consultan al pintar la página. El coste depende casi por completo de si hay caché en memoria: con el mapa de traducciones cacheado, es una lectura; sin él, es una consulta por cada visita.
Servicio externo (Weglot, GTranslate)
Prácticamente no tocan tu servidor: el trabajo lo hace su infraestructura. A cambio, dependes de su tiempo de respuesta y tus traducciones no son tuyas, como vemos en Weglot vs WPML.
Cómo medirlo de verdad en tu web
La única forma honesta es comparar la misma página con el plugin activo y desactivado. Diez minutos:
- Elige una página representativa: no la portada (suele ser atípica), sino una entrada o una ficha de producto normal.
- Con el plugin activo, mide tres veces seguidas con PageSpeed Insights o WebPageTest y anota el TTFB (tiempo hasta el primer byte) y el LCP.
- Desactiva el plugin de idiomas y vacía toda la caché.
- Mide otras tres veces la misma URL.
- Compara las medianas, no la mejor ni la peor marca.
- Vuelve a activar el plugin.
Ojo: hazlo en una copia de pruebas, no en producción. Desactivar el plugin multiidioma en una web viva deja temporalmente sin servir las URL traducidas, y si Google pasa en ese momento se encuentra 404s en páginas indexadas. Nunca compensa el rato que ahorras.
Interpretar el resultado:
- Menos de 50 ms de diferencia en TTFB: el plugin no es tu problema. Busca en otro sitio.
- Entre 50 y 200 ms: pesa, pero hay margen de optimización antes de cambiar de herramienta.
- Más de 300 ms: merece investigación. Suele ser caché mal configurada, no el plugin en sí.
Lo que de verdad hace lenta una web
| Causa | Frecuencia | Qué hacer |
|---|---|---|
| Imágenes sin optimizar | Altísima | WebP, tamaños correctos, loading="lazy" |
| Alojamiento compartido saturado | Alta | Mirar el TTFB; cambiar de plan o proveedor |
| Maquetador con CSS y JS de sobra | Alta | Eliminar recursos no usados |
| Demasiados plugins activos | Media | Auditar y quitar lo que no se usa |
| Sin caché de página | Media | Activar caché y comprobar que funciona |
| Plugin de idiomas | Baja | Caché de objetos; revisar número de idiomas |
El orden importa. Optimizar el plugin de idiomas cuando tienes imágenes de 3 MB sin comprimir es trabajar en el sitio equivocado.
Cómo reducir el coste del multiidioma
Si ya has medido y el plugin sí pesa en tu caso:
1. Caché de página, bien configurada por idioma. Es la que más impacto tiene, con diferencia. Un plugin de caché mal configurado en un sitio multiidioma puede servir la versión cacheada del idioma equivocado; comprueba que tu plugin de caché entiende los idiomas y guarda una copia por cada uno.
2. Caché de objetos (Redis o Memcached). Aquí es donde más se nota en las arquitecturas de tabla de cadenas: el mapa de traducciones se carga una vez y se reutiliza. Muchos alojamientos decentes la ofrecen activable con un clic.
3. Menos idiomas. El coste crece con el número de idiomas activos, no con el de visitas. Cinco idiomas a medio mantener pesan lo mismo que cinco bien mantenidos y rinden mucho menos. Cómo decidirlo con datos, en cuántos idiomas debería tener tu web.
4. Optimiza primero lo de arriba. Las imágenes, el alojamiento y el maquetador van antes. Y las imágenes en una web multiidioma tienen su propio truco: la misma imagen sirve para todos los idiomas, así que optimizarla una vez rinde por cinco. Lo cubrimos en optimización de imágenes y metadatos multilingües.
Consejo: comprueba que tu plugin de caché entiende los idiomas antes que ninguna otra cosa. Es el fallo que más veces se confunde con «el plugin de idiomas va lento»: la caché guarda una sola versión y la sirve a todo el mundo, así que unos visitantes ven el idioma equivocado y el plugin acaba trabajando el doble. Casi todos los plugins de caché tienen un ajuste específico para esto.
El coste de no traducir
Merece la pena poner la cifra en contexto. Suponiendo el peor caso razonable —200 ms más de TTFB—, eso es lo que tardan en cargar dos imágenes mal optimizadas. A cambio, tu web existe en un mercado donde antes no existía.
Si el rendimiento es tu preocupación principal, el orden correcto es: optimiza primero lo de arriba de la tabla, mide después, y decide con números. Casi siempre queda margen de sobra.
WP-Translate cachea el mapa de traducciones en memoria y transitorios, de forma que la mayoría de visitas no llegan a consultar la base de datos por las traducciones. Puedes medirlo tú mismo con la versión gratuita siguiendo el método de arriba, que es lo único que de verdad responde a esta pregunta para tu web.
Preguntas frecuentes
¿Cuál es el plugin multiidioma más rápido?
Polylang, por arquitectura. Si tu única prioridad es el rendimiento y tienes quien escriba cada idioma, es difícil de superar. Las alternativas están en alternativas a Polylang.
¿Afecta al Core Web Vitals?
Puede afectar al TTFB, que influye en el LCP. No afecta al CLS ni al INP, que dependen del tema y del JavaScript.
¿Más idiomas es más lento?
Sí, pero no linealmente. Lo que crece con cada idioma es el trabajo de resolver enlaces y pintar el selector. El contenido de los idiomas que nadie está visitando no cuesta nada.
¿Y si uso un CDN?
Ayuda mucho, siempre que esté configurado para cachear por idioma. Si no distingue idiomas, puede servir la versión equivocada — el mismo problema que con la caché de página, pero más difícil de detectar.
Seguir leyendo
Esta pieza forma parte de la guía de WordPress multiidioma, donde está el recorrido completo: estructura de URL, elección de plugin, traducción automática, SEO y presupuesto.
- hreflang con Yoast SEO — qué cubre de verdad y qué te toca completar
- contenido duplicado en webs multiidioma — cuándo Google no te penaliza y cuándo sí
- errores de SEO multiidioma — 9 errores de SEO multiidioma que hunden una web (y cómo detectarlos hoy)