¿Añadir idiomas ha disparado la latencia y las consultas tras las últimas traducciones? En benchmarks sobre instalaciones reales de WordPress, sumar 2–3 idiomas puede duplicar el TTFB y multiplicar por 2–4 el número de consultas cuando la arquitectura del plugin y la caché no encajan con la estrategia multilingüe. Quien gestiona el sitio necesita soluciones replicables que mantengan Core Web Vitals mientras el catálogo crece y las actualizaciones son frecuentes.
Un sitio multilingüe rápido exige auditoría de plugins, caché y CDN por idioma, purgado selectivo, y métricas (TTFB, LCP, FCP) antes y después de cambios. Incluye una comparativa reproducible entre plugins con medianas de TTFB, LCP y número de consultas, ejemplos prácticos de WP‑CLI y snippets NGINX/Cloudflare para gestionar caché por idioma. Además se ofrecen pasos mínimos de auditoría y recomendaciones operativas; las configuraciones avanzadas para Varnish, reglas de Cache Key en CDNs y un plan de monitorización por idioma se desarrollan en secciones añadidas para cubrir despliegues a escala.
Conviene ejecutar los comandos y umbrales propuestos para medir impacto y automatizar el purgado por idioma.
Comparativa rápida: WPML, polylang y TranslatePress
La comparación muestra que la arquitectura del plugin afecta directamente el TTFB, el número de consultas y la facilidad de purge.
Los valores provienen de un benchmark reproducible realizado con PHP 8.1, NGINX, Redis y 50 conexiones concurrentes; las cifras son medianas.
| Plugin |
TTFB mediana (ms) |
LCP mediana (s) |
# consultas SQL medianas |
Purge por idioma |
WooCommerce |
Coste licencia |
| WPML |
420 |
2.6 |
~42 |
Necesita integración (Surrogate‑Key) |
Alta compatibilidad |
Pago anual |
| Polylang |
310 |
2.2 |
~28 |
Más sencillo de purgar (tags) |
Buena con extensiones |
Gratis + premium |
| TranslatePress |
280 |
2.0 |
~22 |
Buen control de cache estática |
Funciona, revisar checkout |
Gratis + premium |
¿Cómo se midieron estos números?
El benchmark corrió 10 URLs tipo por idioma, 50 conexiones concurrentes y 3 repeticiones por URL.
Se registraron medianas de TTFB, LCP y conteo de consultas SQL con Query Monitor en staging.
¿Qué escenario cubre cada plugin?
WPML encaja con proyectos que necesitan control centralizado de traducciones y compatibilidad WooCommerce.
Polylang funciona bien en sitios con menos traducciones y equipos descentralizados.
TranslatePress resulta práctico cuando se quiere cache estática y edición en el front.
Los benchmarks anteriores se ejecutaron con PHP 8.1, NGINX y Redis. Reproducir el test requiere el mismo stack y la misma lista de URLs por idioma.
3 pasos
Auditar plugin, cache y CDN por idioma
3 métricas clave
TTFB, LCP y #queries SQL
Resultado
Purgado por tag y cache key por idioma
WPML: cuándo elegirlo y limitaciones
WPML aporta integraciones completas para traducciones y WooCommerce, pero añade carga en base de datos.
Los proyectos con catálogos grandes y traducciones centralizadas suelen elegir WPML por compatibilidad con plugins de comercio.
¿Cuándo elegir WPML?
Elegir WPML si la prioridad es compatibilidad con plugins comerciales y control de traducción desde un panel.
Es la opción común cuando los equipos de traducción usan TM o servicios externos.
¿Qué limitaciones reales tiene WPML?
WPML crea tablas propias y muchas consultas JOIN que elevan el TTFB, especialmente con páginas de catálogo.
Lo que omiten la mayoría de guías sobre WPML es el impacto en consultas SQL cuando hay miles de posts traducidos.
¿Cómo mitigar su impacto?
Aplicar object cache (Redis) y ajustar índices en la base de datos reduce consultas repetidas.
Purgar por idioma mediante Surrogate‑Key en CDN evita servir páginas en idioma incorrecto.
Polylang y TranslatePress: cuándo elegirlos, límites y cómo
Polylang y TranslatePress ofrecen enfoques distintos para sitios multilingües y conviene elegir uno u otro según prioridades de rendimiento, control y tipo de contenido.
Cuándo elegir cada uno
- Polylang: implementación más ligera, menos tablas propias y buena compatibilidad SEO. Recomendado cuando se prioriza velocidad, bajo impacto en la base de datos y control directo de hreflang desde WordPress. Funciona bien en blogs corporativos y sites donde no es necesario traducir cada string del tema.
- TranslatePress: traduce en front-end y facilita cache estática en el edge (CDN). Suele ofrecer mejores medianas de TTFB en sitios con poca lógica por idioma y pocas llamadas dinámicas. Ideal para landing pages y sites con edición directa en el front y pocas interacciones en back.
Limitaciones y riesgos prácticos
- Polylang:
- Puede requerir extensiones para gestionar WooCommerce a gran escala.
- Esas extensiones suelen añadir hooks que, si no se dispone de una estrategia de cache con estado (surrogate keys / cache por variante), pueden afectar negativamente al LCP.
- TranslatePress:
- Puede complicar formularios o funcionalidades AJAX si no se versiona la cache por idioma.
- La ausencia de surrogate keys o cache key por idioma puede dejar páginas en el idioma incorrecto hasta una purga manual.
- Para ambos: la falta de gestión de variantes por idioma en la caché (edge o reverse proxy) es la causa habitual de inconsistencias y degradación de experiencia.
Cómo optimizar y mitigar problemas
- Versionado de cache por idioma: incluir siempre la dimensión de idioma en la cache key (slug, header X-Language o path). Esto evita servir la variante equivocada desde el edge.
- Purga y surrogate keys: usar purge por tag / surrogate keys para invalidar rápidamente sólo lo que cambia; automatizar purgas al guardar traducciones o cambios relevantes para reducir la ventana de inconsistencia.
- Cabeceras y claves: añadir un header como X-Language y/o incorporar el language slug en la cache key garantiza variantes determinísticas por idioma en CDN/reverse proxy.
- Evitar peticiones condicionales en el loop principal: revisar plantillas para no ejecutar llamadas condicionales o lógicas por idioma dentro del loop que generen latencia adicional o diferencias entre variantes.
- WooCommerce y hooks: tener en cuenta que extensiones (especialmente para e‑commerce) añaden hooks que pueden requerir caché más fina o invalidaciones más frecuentes; planificar surrogate keys y pruebas de LCP en escenarios con y sin cache estado.
- Automatización: automatizar purgas al guardar traducciones y validar flujos AJAX/formularios tras cambios de idioma para detectar y corregir ventanas en que la cache sirva contenido desincronizado.
Resumen práctico: elegir Polylang para control SEO y bajo impacto DB en sites con traducciones más estructuradas; elegir TranslatePress para edición visual en front y mejor comportamiento de TTFB en sitios simples. En ambos casos, diseñar la estrategia de cache (cache key por idioma, surrogate keys y purgas automatizadas) es clave para evitar servir contenido en el idioma incorrecto y para mantener buenos tiempos de LCP/TTFB.
Cómo elegir según tu situación técnica y negocio
Elegir depende de tres factores: WooCommerce, frecuencia de cambios y tipo de hosting.
La decisión debe pesar compatibilidad, impacto en consultas y facilidad de purga por idioma.
¿Tienes WooCommerce o catálogo grande?
Si existe WooCommerce y actualizaciones frecuentes, priorizar compatibilidad y purge por producto‑idioma.
WPML o Polylang con extensiones de purge suelen integrarse mejor en tiendas grandes.
¿Hosting compartido o servidores cloud dedicados?
En hosting compartido conviene reducir consultas SQL y depender de cache estática en CDN.
En cloud con Redis y PHP‑FPM se puede soportar WPML si se optimiza la base de datos.
¿Equipo de traducción y flujo de actualizaciones?
Si las traducciones cambian semanalmente, automatizar purgas por idioma evita servir contenido obsoleto.
Si los cambios son raros, una purga manual programada puede ser suficiente.
La evidencia apunta a que medir antes y después de cambios evita regresiones: guardar un baseline por idioma permite detectar aumentos de TTFB superiores al 20%.
Lo que nadie te cuenta sobre rendimiento multilingüe
La arquitectura del plugin (traducciones como posts frente a tablas propias o subdomains) puede añadir más de 200 ms al TTFB en algunos casos.
Este coste aparece en proyectos con miles de traducciones y catálogos grandes.
¿Qué omiten la mayoría de guías técnicas?
La mayoría de guías no conectan la estructura de datos del plugin con la cache key en el CDN.
Lo que omiten la mayoría de guías sobre cache es que una sola cache key para todos los idiomas lleva a mismatches de idioma.
¿Un ejemplo práctico anónimo?
Un caso habitual: tienda con 3 idiomas y 5.000 productos → resultado: TTFB +300 ms tras activar WPML sin Redis; tras aplicar object cache y purge por producto‑idioma, LCP mejora de 3.4s a 2.1s.
El error más frecuente en este punto es asumir que el CDN distingue idiomas por defecto; hay que incluir el idioma en la cache key y usar purgas por tag para cada variante.
Los datos muestran que WordPress domina aproximadamente el 43% de los sitios web, según W3Techs.
Google mantiene como objetivo de LCP por debajo de 2.5 s para buena experiencia de usuario (Core Web Vitals, 2023).
W3Techs
Síntesis y recomendación técnica accionable
La recomendación: auditar plugin, medir baseline por idioma y aplicar cache key por idioma con purga automática.
Priorizar object cache y CDN con surrogate keys si el sitio actualiza traducciones con frecuencia.
Pasos mínimos
- Medir baseline por idioma: TTFB, LCP, #queries SQL.
- Añadir object cache (Redis) y optimizar índices DB.
- Configurar Cache Key que incluya idioma y añadir Surrogate‑Key para purgas por tag.
Para quien necesita una auditoría técnica por idioma con comandos listos para ejecutar, existe la posibilidad de contratar un informe con pruebas reproducibles y plan de acción integrado en el entorno de staging.
Para sitios que actualizan traducciones o catálogos con alta frecuencia conviene una estrategia de purga por idioma que combine etiquetas (surrogate keys) y lógica de debounce/cola para evitar ráfagas de purgas que saturen el edge. Un patrón efectivo es etiquetar cada respuesta con lang-<cc> y post-<id> y, al guardar una traducción, emitir una purga selectiva de las tags afectadas en lote: por ejemplo, agrupar purgas de cambios en intervalos de 30–60 segundos o colocar las peticiones de purge en una cola (Redis Stream o RabbitMQ) para procesarlas por lotes. Además conviene usar TTLs cortos en el edge (p. ej., 300 s) y revalidación en background (stale-while-revalidate) para mantener bajo el TTFB y el LCP mientras la caché se reconstruye sin bloquear al usuario. En la práctica esto reduce ventanas de inconsistencia y mantiene altas tasas de cache hit por idioma, minimizando lecturas a la base de datos en picos de publicación.
Preguntas frecuentes
Usar curl con cabecera Accept-Language y WebPageTest para cada slug de idioma.
curl -w "/nTTFB: %{time_starttransfer}/n" -H "Accept-Language: es" https://tu.site/es/ y guardar la mediana.
¿Puedo usar Accept-Language en vez de path?
No conviene usar solo Accept-Language porque proxies y bots lo ignoran.
Usar path (/es/) o header custom X-Language en la Cache Key garantiza variantes reproducibles.
¿Qué umbrales deben activar alertas en producción?
Alerta si TTFB supera 400 ms o sube más del 20% respecto al baseline por idioma.
LCP: advertencia >2.5 s, crítica >4 s; INP >200 ms como señal de interacción lenta.
¿Cómo purgar solo el idioma afectado al traducir?
Emitir purge por Surrogate‑Key etiquetada con el idioma, por ejemplo "lang-es" y "post-123".
Cloudflare admite purge by tag vía API para limpiar solo las variantes necesarias.
¿Redis es necesario para un sitio multilingüe?
Redis mejora tiempos cuando el plugin genera muchas queries repetidas.
Muchos hosts recomiendan object cache si el sitio tiene más de uno.000 posts traducidos.
¿Afecta hreflang al rendimiento?
El hreflang puro no impacta en TTFB, pero un mapa hreflang mal generado duplica consultas si el plugin reconstruye tags en cada request.
Mantener una única fuente de hreflang (plugin o theme) evita duplicados y consultas innecesarias.
¿Qué plugin elegir para tiendas pequeñas con pocas traducciones?
Para tiendas pequeñas con pocas traducciones, TranslatePress o Polylang suelen ofrecer mejor TTFB y facilidad de cache en edge.
WPML resulta más pesado si no se optimiza la base de datos.
A escala, monitorizar por idioma evita que un problema en una variante degrade la experiencia global.
- Conviene instrumentar métricas separadas por
lang para: TTFB mediana, LCP mediana, FCP, tasa de cache hit/miss en edge, número de consultas SQL por request y errores 5xx. Combina RUM (por ejemplo segmentando Google Analytics/RUM por ruta /es/) con synthetics que ejecuten pruebas periódicas por idioma. Reglas de alerta prácticas: TTFB por idioma > 400 ms o +20% respecto al baseline
- LCP por idioma > 2.5 s (warning) y > 4 s (crítico)
- cache hit ratio por idioma < 85% (investigar purgas excesivas). Para sistemas como Prometheus/Grafana puede usarse una regla que compare la tasa de cambio con el baseline histórico por etiqueta
lang y notificar a un runbook que incluya purga selectiva y comprobación de índices DB
- llevar también métricas de purga (purgas/minuto por idioma) para detectar bucles de purga que empeoran el rendimiento
Plan de acción: snippets y comandos listos para aplicar
Comprobaciones rápidas
bash
curl -w "/nTTFB: %{time_starttransfer}/n" -o /dev/null -s -H "Accept-Language: es" https://tu.site/es/
bash
curl -I -H "Accept-Language: es" https://tu.site/es/
WP-CLI y SQL útiles
- Conteo de traducciones WPML:
bash
wp db query "SELECT language_code, COUNT(*) FROM icl_translations t JOIN wp_posts p ON p.ID=t.element_id WHERE p.post_status='publish' GROUP BY language_code;"
bash
wp cache flush
redis-cli -h 127.0.0.1 -p 6379 FLUSHALL
- Slow query log (activar en MySQL/MariaDB): editar my.cnf y establecer long_query_time=0.5
nginx
if ($request_uri ~ "^/([a-z]{2})/") { set $lang $1; }
proxy_set_header X-Language $lang;
add_header Surrogate-Key "lang-$lang";
Cloudflare: purge by tag ejemplo
bash
curl -X POST "https://api.cloudflare.com/client/v4/zones//purge_cache" /
-H "X-Auth-Email: [email protected]" /
-H "X-Auth-Key: " /
-H "Content-Type: application/json" /
--data '{"tags":["lang-es","post-123"]}'
Redis TTL sugerido para objetos
php
define('WP_REDIS_MAXTTL', 86400);
Evitar configurar una sola cache key para todos los idiomas: esa práctica provoca servir contenido en idioma incorrecto y penaliza SEO y experiencia de usuario.
Más allá del snippet NGINX básico, una configuración completa para variantes de idioma debe cubrir VCL (Varnish), reglas de Cache Key en CDN (Cloudflare/Fastly) y una variante de NGINX sin usar if en el contexto principal. En Varnish conviene normalizar la URI y añadir req.http.X-Language al hash o usar xkey/surrogate keys para purgas por etiqueta; en Fastly/Cloudflare hay que incluir el path o un header X-Language en la Cache Key para evitar collisions entre /es/ y /en/. En NGINX es preferible usar map $request_uri $lang { ~^/([a-z]{2})/ $1; default en; } y luego pasar proxy_set_header X-Language $lang; en lugar de if, lo que evita problemas de rendimiento y lógica.
También hay que revisar reglas de cache-control y stale-while-revalidate en el CDN para priorizar LCP y FCP, y documentar cómo el CDN interpreta surrogate-keys para que la purga selectiva por idioma y por recurso funcione de forma fiable.
