Por qué tu caching rompe la performance multilingüe

¿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.

¿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.

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.

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

1. Medir baseline por idioma: TTFB, LCP, #queries SQL.
2. Añadir object cache (Redis) y optimizar índices DB.
3. 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

¿Cómo medir TTFB por idioma de forma rápida?

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

• Medir TTFB con curl:

bash curl -w "/nTTFB: %{time_starttransfer}/n" -o /dev/null -s -H "Accept-Language: es" https://tu.site/es/

• Ver cabeceras de cache:

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;"

• Flush cache WP y Redis:

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: añadir header de idioma

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);

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.

• Transforma la carga y rendimiento de sites multilingües
• Reduce carga y errores con caché del navegador y headers

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.