¿La tienda o la web corporativa ha perdido velocidad tras añadir idiomas? Añadir cada idioma suele aumentar TTFB, consultas y consumo de memoria PHP; el responsable técnico necesita identificar el origen con datos reproducibles, scripts y métricas objetivo que permitan revertir la degradación sin riesgo. Se recomiendan cinco pasos reproducibles, probados en staging, con validación de métricas antes del deploy.
Si tu WordPress multilingüe va lento, la prioridad es medir impacto por idioma, optimizar la capa de caché/CDN y corregir consultas del plugin de traducción. Rendimiento en sites multilingües requiere tests reproducibles, comandos Nginx/Redis/PHP‑FPM, ajustes para WPML/Polylang, reglas CDN por idioma y checklist de deployment para recuperar Core Web Vitals y reducir TTFB.
Paso 1: Medición del impacto por idioma y configuración de benchmarking
El proceso sigue cinco pasos claros y reproducibles que se prueban en staging antes de deploy. Cada paso incluye comandos, configuraciones y métricas objetivo para validar los cambios. Al final queda una checklist de despliegue y monitorización continua.
Pasos rápidos
- Medir impacto por idioma en 1, 3 y 6+ idiomas y capturar TTFB, LCP y número de consultas.
- Ajustar Nginx/PHP‑FPM y activar object cache con Redis.
- Configurar page cache en Varnish o CDN edge con cache key por idioma.
- Optimizar WPML/Polylang/Weglot y reindexar tablas críticas.
- Automatizar pruebas en CI y vigilar con RUM y APM.
Checkpoints para deploy
Confirmar que las URLs por idioma devuelven cache hit en edge. Comprueba que no hay contenido en idioma equivocado. Verificar que TTFB mejora o se mantiene dentro del umbral admisible.
Paso 1: Medición por idioma: por qué y qué medir
Realizar mediciones por idioma identifica el coste real de cada idioma. Sin datos es imposible priorizar medidas. La medición debe incluir tanto el tiempo de servidor como la experiencia real de usuario (RUM y laboratorio): TTFB, LCP, FCP, INP/FID y número de queries SQL por URL. Usar Lighthouse, WebPageTest y curl para capturas repetibles.
URLs y métricas representativas
Seleccionar URLs representativas: home, producto/ficha, artículo largo y una página con widgets. Medir en cada URL: TTFB, LCP, FCP, INP/FID y número de queries SQL. Repetir mediciones para cada idioma (p. ej. /es/, /en/, /fr/, /de/, /it/, /pt).
Scripts de test (ejemplos)
Ejemplo para medir TTFB con curl:
curl -o /dev/null -s -w "%{time_starttransfer}/n" https://example.com/es/
Script para iterar idiomas:
langs=(es en fr de it pt)
for l in "${langs[@]}"; do
curl -o /dev/null -s -w "$l %{time_starttransfer}/n" https://example.com/$l/
done
Métricas de referencia y protocolo de benchmarking
Usar como baseline los resultados de staging y comparar tras cada cambio. Google Web Vitals define objetivos claros para LCP, FCP e INP; seguir esas referencias ayuda a priorizar trabajo: https://web.dev/vitals/
Para que las decisiones sean reproducibles, publicar una matriz de benchmarks que detalle entorno, herramienta y resultados por idioma y por plugin. Un protocolo válido incluye, como ejemplo:
- Entorno de staging con snapshot de BD y caché desactivada entre runs.
- 3 URLs representativas (home, ficha producto, artículo largo) y una página con widgets.
- 50 requests cold y 200 warm por URL.
- Mediciones con Lighthouse (JSON), WebPageTest y curl para TTFB.
- Registrar versión del build, configuración de plugins multilenguaje y si se usaron A/B o feature flags.
Paso 3: Cache y CDN por idioma: principios generales
La cache key debe distinguir idiomas para evitar servir contenido equivocado. Las rutas por idioma (/es/, /en/) son la opción más simple y robusta. Si no hay rutas por idioma, usar un header o cookie que forme parte de la cache key. Evitar usar Vary: Accept-Language (multiplica cachés y es poco fiable).
Reglas CDN y lógica en el edge
- En Cloudflare: crear un Worker o Page Rule que normalice un header (por ejemplo X-Lang) y añadirlo a la cache key.
- En CloudFront: crear behaviors por path pattern (/es/, /en/) y configurar TTLs y encabezados según necesidad.
- Evitar variar por Accept-Language; preferir paths, header explícito (X-Lang) o cookie bien definida.
- Preferir ruta por idioma para la cache key.
- Si se usa cookie del plugin (por ejemplo icl_lang o pll_language), incluir esa cookie en la clave de la caché.
- Normalizar valores (minúsculas, códigos ISO 2 letras) en el edge para evitar claves duplicadas.
- Documentar la estrategia de cache keys por idioma en la matriz de benchmarks y en la configuración CDN.
Hreflang, sitemaps y SEO
- Mantener sitemaps separados por idioma y añadir rel="alternate" en cada página hacia sus equivalentes. El CDN no debe alterar estas etiquetas.
- Una sitemap por idioma reduce errores en indexación y facilita el trabajo de rastreo de motores.
Evitar duplicar assets por idioma
- Compartir rutas de recursos cuando el contenido visual es idéntico y generar variantes solo cuando el texto dentro del asset cambia.
- Servir fuentes comunes desde un path único en CDN con cabeceras de cache largas; aplicar subsetting por familias que lo requieran (p. ej. una fuente latina compartida y otra con glifos para alfabetos distintos).
- Para imágenes con texto, generar la imagen base y aplicar un overlay de texto en el cliente con un pequeño JS cuando sea posible, en lugar de crear múltiples versiones estáticas.
- Documentar qué assets varían por idioma y automatizar la generación de variantes solo cuando sea necesario.
Integrar ambas áreas: medir el impacto por idioma y usar esos datos para validar la estrategia de cache/CDN (p. ej. comparar TTFB y LCP por idioma antes y después de incluir la lengua en la cache key, y comprobar indexación y enlaces alternates tras cambios en CDN).
Paso 2: ajustes de servidor y caché
Ajustar la capa servidor reduce TTFB y evita que muchas peticiones lleguen a PHP. Cambios en Nginx, PHP‑FPM, Redis y Varnish producen mejoras medibles en segundos de respuesta. La clave es incluir la variable de idioma en la cache key.
Nginx y PHP‑FPM
Mapear el idioma desde la URI y pasarla a FastCGI para usarla en la cache key. Configuración recomendada de opcache: opcache.memory_consumption=256. Si se opta por opcache.validate_timestamps=0 en producción, documentar y automatizar la invalidación de Opcache en cada deploy (por ejemplo via php-fpm reload o opcache_reset() en un hook de despliegue); alternativamente mantener opcache.validate_timestamps=1 y ajustar opcache.revalidate_freq para entornos donde no exista un deploy hook seguro. Ejemplo Nginx:
nginx
map $request_uri $lang {
~^/es/ es;
~^/en/ en;
default en;
}
fastcgi_param HTTP_X_LANG $lang;
fastcgi_cache_key "$scheme$request_method$host$uri-$lang";
Varnish, redis y page cache
Varnish debe incluir idioma en el hash; Redis sirve para object cache y transients. Ejemplo VCL:
vcl
sub vcl_recv {
if (req.url ~ "^/([a-z]{2})/") {
set req.http.X-Lang = regsub(req.url, "^/([a-z]{2})/.*", "/1");
}
}
sub vcl_hash {
hash_data(req.http.X-Lang);
}
Asegurar que Redis tiene memoria suficiente y política LRU para evitar evictions inesperadas.
Flujo de caching por idioma
Cliente
→
CDN Edge (Key incluye idioma)
→
Origin (Nginx + PHP‑FPM + Redis)
La CDN sirve HTML cacheado por idioma. Si hay miss, Varnish/Origin responde y Redis reduce carga PHP.
En entornos multilingües, los comandos y fragmentos reproducibles ayudan a validar cambios en servidor. Ejemplos prácticos: comprobar versión y reinicio de servicios: systemctl status php7.4-fpm && systemctl restart php7.4-fpm, validar Redis y memory usage: redis-cli INFO memory | grep used_memory_human, tests rápidos de cache en Nginx con una petición que incluye header de idioma: curl -I -H "X-Lang: es" https://staging.example.com/es/. Un pool mínimo de PHP‑FPM para sitios con alto tráfico y muchas traducciones puede usar en el pool: pm = dynamic, pm.max_children = 50, pm.start_servers = 10, pm.min_spare_servers = 5, pm.max_spare_servers = 15.
Para Varnish, además del VCL de ejemplo del artículo, verificar estado con varnishlog y ejecutar purgas/ban con varnishadm (usar comandos como vcl.list y vcl.load para gestionar VCLs); para Redis ajustar maxmemory y policy LRU: CONFIG SET maxmemory 2gb y CONFIG SET maxmemory-policy allkeys-lru. Estos fragmentos permiten repetir la misma secuencia en staging y medir impacto real en TTFB y Core Web Vitals.
Paso 4: optimizar plugins y base de datos
Los plugins multilingües generan consultas adicionales que afectan TTFB. Identificar esas queries y aplicar índices o limpiar transients reduce carga. Lo que la mayoría de guías omite es el impacto de meta queries repetidas en wp_postmeta.
WPML, polylang y weglot
WPML guarda traducciones en tablas propias y suele generar más SELECTs por idioma. Polylang trabaja más con taxonomías y suele ser más ligero. Weglot actúa por API y añade latencia externa si no se cachea.
| Plugin |
Modelo |
Overhead DB |
Mejor caso uso |
| WPML |
DB tables + meta |
Alto |
Site corporativo con traducciones profesionales |
| Polylang |
Taxonomías + meta |
Medio |
Proyectos con control de rutas y menores costes |
| Weglot |
API externa |
Bajo (pero dependencia externa) |
Landing pages o despliegue rápido |
Índices, EXPLAIN y transients
Activar slow_query_log y analizar las consultas con EXPLAIN. Indexar meta_key en wp_postmeta y las tablas de traducción reduce full table scans. Ejemplo de índice:
sql
ALTER TABLE wp_postmeta ADD INDEX idx_meta_key (meta_key(191));
Eliminar transients huérfanos con WP‑CLI reduce I/O:
bash
wp transient delete --all
wp cache flush
Un caso habitual: una tienda WooCommerce con 3 idiomas vio cómo el número de queries por página subía un 250% tras activar WPML. Tras indexar wp_postmeta y ajustar cache key, el TTFB bajó de 800 ms a 320 ms.
La evidencia apunta a que muchas ralentizaciones vienen de meta queries en bucles no optimizados. Revisar templates y evitar get_post_meta en bucles críticos disipa gran parte del problema.
La recomendación es clara: usar Polylang si se busca menor coste DB, elegir WPML si se necesita funcionalidad avanzada y Weglot para despliegues rápidos que toleren dependencia externa.
Paso 5: CI/CD y monitorización
Automatizar pruebas por idioma evita regresiones tras traducciones o actualizaciones. Integrar Lighthouse CI y scripts curl en el pipeline obliga a medir antes de lanzar cambios. Monitorizar en producción detecta degradaciones reales.
Tests automáticos
Añadir un job en CI que ejecute Lighthouse para /es/, /en/ y /fr/. Fallar el build si LCP o TTFB empeoran más del 15% respecto al baseline. Ejemplo de comando Lighthouse en CI:
bash
lighthouse https://staging.example.com/es/ --output=json --quiet
Monitorización y alertas
Usar RUM para Core Web Vitals y APM para servidor. New Relic y Prometheus ofrecen alertas en spikes de TTFB o aumento de consultas SQL. Crear alertas para cache hit ratio en CDN.
Errores que arruinan el resultado
Algunos errores son comunes y fáciles de detectar. Evitarlos ahorra tiempo y mantiene rendimiento al añadir idiomas.
Caché mal configurada
No incluir el idioma en la cache key provoca servir contenido en idioma equivocado o invalidaciones masivas. Revisar reglas CDN y Varnish antes de activar un nuevo idioma.
Duplicar recursos estáticos
Servir imágenes o fuentes por cada idioma sin usar el mismo asset pipeline aumenta peso y peticiones. Usar srcset y compartir assets reduce carga. Revisar con DevTools para contar recursos duplicados.
Medir solo en un idioma
Medir rendimiento solo en el idioma principal lleva a decisiones equivocadas. Siempre medir las rutas por idioma y comparar resultados.
Síntesis y recomendación accionable
La prioridad es medir, cachear por idioma y corregir consultas del plugin de traducción. Aplicando ajustes en Nginx, Redis y Varnish se logran mejoras de TTFB que son medibles en 24-48 horas. La inversión en una configuración de CDN y object cache suele amortizarse con menor carga de servidor.
Plan de 48 horas
- Ejecutar script de TTFB y Lighthouse para 3 URLs por idioma.
- Implementar cache key con X-Lang en staging y comprobar cache hit ratio.
- Revisar slowlog y aplicar índices rápidos en tablas críticas.
Aspectos de coste
Para sitios 1-3 idiomas, una configuración con Redis y Cloudflare es suficiente y de coste moderado. Para 6+ idiomas suele compensar usar Varnish en origen y un CDN empresarial. Incluir coste de licencia de plugin en el cálculo.
No aplicar estas recomendaciones en sitios que sirven traducciones como HTML estático pre-renderizado. Tampoco compensa en proyectos con menos de 10 páginas y tráfico mínimo, donde la complejidad operacional supera el beneficio.
En caso de necesitar una revisión técnica concreta y un plan de acciones, se puede solicitar asistencia profesional para ejecutar el laboratorio de pruebas en staging y documentar un plan de despliegue seguro.
Preguntas frecuentes
¿Me conviene WPML o polylang para rendimiento?
Depende del caso: WPML ofrece funciones avanzadas y añade más consultas, Polylang es más ligero y suele generar menos overhead. Elegir según la necesidad de features o la prioridad de rendimiento.
¿CDN y cache valen la pena en sites multilingües?
Sí, siempre que la cache key distinga idiomas. Un CDN reduce latencia y descarga el origen, pero requiere reglas por idioma para ser efectivo.
¿Mejor multisite o instalación única para un site multilingüe?
Instalación única con rutas por idioma suele ser más sencilla y cache-friendly. Multisite puede ser útil si cada idioma requiere estructura completamente distinta o equipos separados.
¿Qué errores de plugins de idioma ralentizan el rendimiento?
Los errores típicos son: queries en bucles, syncs automáticos de postmeta y uso de cookies o headers que no se incluyen en la cache key. Revisar templates y Query Monitor ayuda a detectarlos.
¿Qué pasa si cargo imágenes por cada idioma?
Duplicar imágenes por idioma aumenta peso y peticiones. Mejor compartir assets y usar parámetros de texto en overlays cuando sea posible.
¿Cuáles son los costes ocultos de traducción
Costes de API, latencia externa y mayor complejidad en sincronización de precios y variaciones. Estos costes crecen con el tráfico y pueden penalizar TTFB si no se cachean respuestas.
¿Cómo saber si mi base de datos necesita índices
Activa slow_query_log y usa EXPLAIN en las consultas que salgan repetidas. Si hay full table scans en meta consultas, añadir índices suele reducir tiempos notablemente.
Checklist y recursos
Checklist final antes de publicar nuevos idiomas: pruebas en staging, backup completo, cache key por idioma, Redis activo, índices aplicados y CI con Lighthouse. Documentar el plan de rollback y mantener monitorización RUM en producción.
Recursos y lecturas: WordPress.org ofrece estadísticas de uso y guías; consultar Web Vitals para métricas objetivo. WordPress.org
La evidencia visual de las mejoras aparece en las capturas de Lighthouse y en los logs slow_query tras aplicar índices, mostrando reducción clara del TTFB y del número de queries.
