[Sergio Iglesias](https://sergioiglesias.net) · Blog sobre Joomla

# Optimización de base de datos y TTFB en Joomla: más allá de los plugins de caché

[ Añadir a fuentes preferidas ](https://www.google.com/preferences/source?q=sergioiglesias.net)   21 Octubre 2026    [Marketing Online](https://sergioiglesias.net/blog/marketing-online)   7 - 13 minutos    Visitas: 26  -
- [ SEO Joomla ](https://sergioiglesias.net/etiquetas/seo-joomla)
- [ Autónomos y PYMES ](https://sergioiglesias.net/etiquetas/autonomos-y-pymes)

  ![](https://sergioiglesias.net/images/blog/marketing/optimizacion-base-datos-ttfb-joomla.webp) Cuando una web en Joomla empieza a ir lenta, la reacción habitual suele ser bastante previsible: instalar otro plugin de caché.

Y otro.

Y quizá uno más, por si acaso.

El problema es que la velocidad de una web no depende únicamente de lo que ocurre en el navegador. Antes de que Joomla pueda enviar el primer byte al visitante, el servidor tiene que procesar la petición, ejecutar PHP, consultar la base de datos y construir la respuesta.

Ahí aparece un protagonista que muchas veces pasa desapercibido: **el TTFB (Time To First Byte)**.

Si el servidor tarda demasiado en responder, puedes tener imágenes perfectamente comprimidas, CSS minificado y una caché bien configurada. El visitante seguirá esperando.

Por eso, en Joomla 5 (y 6), mejorar el rendimiento implica mirar un poco más abajo.

La base de datos, PHP, OPcache, Redis y la configuración del servidor pueden marcar una diferencia enorme.

## Qué es el TTFB y por qué importa en Joomla

El TTFB mide el tiempo que transcurre desde que el navegador solicita una página hasta que recibe el primer byte de respuesta del servidor.

Dicho de forma sencilla: **mide cuánto tarda tu servidor en empezar a contestar**.

No es exactamente lo mismo que el tiempo total de carga de una página. Una web puede comenzar a responder rápidamente y después tardar varios segundos en cargar todos sus recursos.

Pero cuando el TTFB es elevado, suele existir un problema antes de que el navegador pueda hacer gran cosa.

En Joomla, una petición puede implicar varias operaciones:

- Ejecución de PHP.
- Carga del framework y extensiones.
- Consultas a la base de datos.
- Comprobaciones de sesión.
- Procesamiento de módulos.
- Generación del HTML.
- Lectura de archivos o datos almacenados.
- Comunicación con servicios externos.

Cuanto más trabajo tenga que hacer el servidor antes de entregar la respuesta, mayor puede ser el TTFB.

Y aquí está una de las claves: **añadir más caché no siempre soluciona el problema de fondo**.

## La base de datos puede ser el cuello de botella

Joomla depende de la base de datos para almacenar buena parte de la información necesaria para construir una página.

Artículos, categorías, usuarios, sesiones, configuraciones, menús, extensiones y muchos otros datos terminan pasando por ella.

Cuando una instalación lleva años funcionando, es fácil que la base de datos acumule información que ya no aporta ningún valor a las peticiones actuales.

Esto no significa que una base de datos grande sea necesariamente lenta.

Una base de datos de varios cientos de megabytes puede funcionar perfectamente si está bien estructurada, indexada y consultada.

El problema aparece cuando tenemos **datos innecesarios, consultas poco eficientes, tablas mal configuradas o índices que no responden a las consultas reales**.

Por eso conviene empezar por el mantenimiento.

## Limpieza de tablas críticas en Joomla 5

Antes de tocar índices o cambiar configuraciones del servidor, merece la pena revisar qué información está acumulando Joomla.

Uno de los casos más habituales son los registros que tienen una vida útil limitada.

### Sesiones antiguas

Las sesiones pueden acumular registros que ya no son necesarios.

Dependiendo de cómo esté configurada la gestión de sesiones y del tráfico de la web, esta tabla puede crecer considerablemente.

Una instalación con poco tráfico probablemente no tendrá un problema importante.

Una web con miles de visitas, múltiples usuarios conectados o procesos automatizados puede tener una historia muy diferente.

La limpieza periódica de sesiones antiguas ayuda a evitar que una tabla de mantenimiento se convierta en un pequeño almacén arqueológico.

### Registros de redirecciones

La gestión de redirecciones de Joomla resulta muy útil para controlar cambios de URLs y evitar errores 404.

Pero hay que vigilar su crecimiento.

En webs que llevan años publicando contenido, migrando URLs o realizando cambios de estructura, los registros pueden acumularse hasta alcanzar un tamaño considerable.

No se trata de borrar redirecciones sin criterio.

Primero hay que identificar cuáles siguen siendo necesarias y cuáles corresponden a URLs que ya no tienen sentido.

Una redirección que todavía recibe tráfico puede ser importante para SEO.

Una entrada histórica que nadie consulta puede ser otra historia.

### Datos temporales y registros de extensiones

Las extensiones de terceros son otro punto que conviene revisar.

Algunas almacenan logs, estadísticas, información temporal o registros de actividad directamente en la base de datos.

El comportamiento depende de cada extensión.

Por eso, antes de borrar tablas o registros, hay que saber exactamente qué función cumplen.

**Nunca conviene limpiar una base de datos a golpe de escoba.**

Primero copia de seguridad.

Después, análisis.

Y finalmente, limpieza.

## Haz una copia de seguridad antes de tocar la base de datos

Parece una recomendación obvia, pero merece estar escrita en letras grandes.

Antes de realizar operaciones de limpieza, modificar índices o ejecutar instrucciones SQL, crea una copia de seguridad completa.

Idealmente, hazlo fuera del mismo servidor donde está alojada la web.

Una buena práctica consiste en comprobar también que esa copia puede restaurarse.

Porque tener un backup que nunca has probado es un poco como tener un extintor sin saber si funciona.

## Comprueba el motor de almacenamiento de las tablas

En instalaciones modernas de Joomla y MySQL/MariaDB, **InnoDB** es el motor de almacenamiento que normalmente debería encontrarse en las tablas.

InnoDB ofrece características importantes para aplicaciones web modernas, como transacciones, bloqueo a nivel de fila y recuperación ante determinados fallos.

Si encuentras tablas utilizando otro motor, no significa automáticamente que debas convertirlas.

Primero hay que comprobar qué extensión las creó y por qué.

Las tablas pertenecientes a Joomla y a extensiones de terceros deben analizarse con conocimiento de su estructura y requisitos.

## Los índices pueden cambiar completamente el rendimiento

Uno de los errores más frecuentes es pensar que una consulta lenta significa que la base de datos necesita simplemente más potencia.

No siempre.

Imagina una tabla con cientos de miles de registros.

Si una consulta necesita buscar información en una columna que no tiene un índice adecuado, el servidor puede verse obligado a revisar una gran cantidad de filas antes de encontrar lo que necesita.

Con un índice correctamente planteado, esa búsqueda puede ser mucho más eficiente.

Aquí aparece una regla importante:

**No añadas índices porque sí.**

Cada índice ocupa espacio y también tiene un coste cuando se insertan o modifican datos.

La solución correcta depende de las consultas que realmente ejecuta Joomla y sus extensiones.

## Cómo detectar consultas problemáticas

Cuando sospechas que la base de datos está detrás de un TTFB elevado, necesitas datos.

No basta con decir:

"La web está lenta."

Hay que averiguar **qué operación está tardando**.

Algunas herramientas habituales permiten analizar consultas SQL, tiempos de ejecución y consumo de recursos.

También puedes revisar el comportamiento del servidor mediante herramientas de monitorización y registros.

El objetivo es encontrar patrones.

Por ejemplo:

- Una determinada consulta se ejecuta cientos de veces durante una petición.
- Una consulta tarda mucho más cuando aumenta el número de registros.
- Una extensión genera consultas innecesarias.
- Una tabla ha crecido enormemente.
- Una consulta no está aprovechando correctamente un índice.

Cuando encuentras el origen, deja de ser necesario disparar contra todo lo que se mueve.

## OPcache: acelera PHP antes de que Joomla haga su trabajo

La base de datos es una pieza importante, pero PHP también puede convertirse en un cuello de botella.

Joomla 5 ejecuta código PHP para procesar las peticiones.

Sin OPcache, PHP puede tener que analizar y compilar scripts repetidamente.

**OPcache mantiene el código PHP compilado en memoria**, reduciendo ese trabajo repetitivo.

El resultado puede ser una reducción significativa del tiempo necesario para procesar las peticiones.

En un servidor Joomla de producción, comprobar que OPcache está activo y correctamente configurado debería formar parte de cualquier auditoría básica de rendimiento.

Pero cuidado con una idea habitual:

"Activo OPcache y listo."

No.

También hay que comprobar que dispone de suficiente memoria, que los límites son adecuados para el número de scripts de la instalación y que la configuración se adapta al entorno real.

## Redis y la caché en memoria

Redis juega en otra liga.

En lugar de almacenar determinados datos exclusivamente en el almacenamiento tradicional, Redis permite trabajar con información directamente en memoria.

Esto puede ser especialmente interesante para determinados escenarios de caché y gestión de sesiones.

En Joomla, la caché debe plantearse como parte de una arquitectura.

No se trata de instalar Redis porque alguien dijo que "es rápido".

La pregunta correcta es:

**¿Qué queremos almacenar en caché, durante cuánto tiempo y dónde tiene sentido hacerlo?**

Una arquitectura bien planteada puede reducir consultas repetitivas y disminuir el trabajo que Joomla tiene que realizar en cada petición.

Eso puede repercutir positivamente en el TTFB.

## Joomla, caché y Redis: cada pieza tiene su función

Aquí conviene evitar un error bastante común.

La caché de Joomla y Redis no son necesariamente alternativas excluyentes.

Pueden formar parte de una misma estrategia.

Joomla gestiona la lógica de caché de la aplicación.

Redis puede actuar como almacenamiento en memoria para determinados mecanismos.

OPcache trabaja sobre el código PHP.

Y el servidor web puede incorporar sus propias capas de caché.

Son piezas diferentes.

El objetivo es que trabajen juntas, no que todas intenten resolver exactamente el mismo problema.

Porque cuando instalamos cinco sistemas de caché que hacen prácticamente lo mismo, la web puede terminar siendo más difícil de mantener que rápida.

## No confundas caché con solución mágica

La caché funciona especialmente bien cuando evita repetir trabajo.

Pero si cada petición necesita ejecutar una consulta lenta antes de poder generar la respuesta, el problema sigue existiendo cuando la caché no puede intervenir.

Por ejemplo, una página dinámica puede necesitar consultar información que cambia constantemente.

Si esa información no puede almacenarse durante mucho tiempo, la aplicación seguirá necesitando procesarla.

Por eso, **la caché debe complementar una base de datos saludable, no esconder una base de datos problemática**.

## Cómo mejorar el TTFB de Joomla 5 paso a paso

Una estrategia lógica sería trabajar desde la raíz hacia arriba.

### 1. Mide antes de modificar

Primero establece una referencia.

Comprueba el TTFB de varias páginas:

- Portada.
- Artículos.
- Categorías.
- Páginas con muchos módulos.
- Áreas dinámicas.

No midas únicamente una URL.

Una página puede ser rápida mientras otra tarda varios segundos por culpa de una consulta concreta.

### 2. Revisa el servidor

Comprueba recursos disponibles:

CPU, memoria, almacenamiento y carga del servidor.

También conviene revisar la versión de PHP y la configuración de PHP-FPM cuando corresponda.

Un servidor saturado no se arregla con un plugin de caché.

### 3. Comprueba OPcache

Asegúrate de que está activo y funcionando correctamente.

Revisa su consumo y evita configuraciones excesivamente conservadoras que provoquen que la caché se quede pequeña para el tamaño real de la instalación.

### 4. Analiza la base de datos

Busca tablas que hayan crecido demasiado.

Revisa sesiones, redirecciones, logs y datos temporales.

Después analiza las consultas que realmente están afectando al rendimiento.

### 5. Comprueba los índices

No añadas índices de manera indiscriminada.

Identifica primero las consultas lentas y comprueba cómo está ejecutándolas el motor de base de datos.

Herramientas como EXPLAIN pueden ayudarte a entender cómo se está ejecutando una consulta.

### 6. Revisa las extensiones

Una extensión mal diseñada puede generar más problemas que cien imágenes sin comprimir.

Comprueba cuáles realizan consultas frecuentes o procesos pesados.

Si el problema desaparece al desactivar temporalmente una extensión en un entorno de pruebas, ya tienes una pista bastante interesante.

### 7. Configura la caché

Una vez que la base está limpia y las consultas están razonablemente optimizadas, configura la caché de Joomla y, cuando tenga sentido, Redis.

Aquí es donde la caché empieza a multiplicar el trabajo bien hecho.

## ¿Cuándo merece la pena Redis?

Redis puede tener mucho sentido en sitios Joomla con bastante tráfico, aplicaciones con necesidades importantes de caché o entornos donde la reducción de operaciones de lectura repetitivas aporte una mejora real.

En una web pequeña, con poco tráfico y un servidor rápido, instalar Redis puede aportar una mejora mínima.

Y eso también es rendimiento.

No instalar cosas que no necesitas.

Cada servicio adicional aumenta la complejidad de la infraestructura y requiere mantenimiento.

## ¿Y si el TTFB sigue siendo alto?

Si después de limpiar la base de datos, revisar las consultas, configurar OPcache y ajustar la caché el TTFB continúa siendo elevado, toca mirar más abajo.

Puede haber problemas relacionados con:

- PHP-FPM.
- El servidor web.
- DNS.
- TLS.
- La infraestructura de hosting.
- Recursos insuficientes.
- Consultas a APIs externas.
- Servicios de terceros.
- Procesos bloqueantes.

También es posible que el problema no esté en Joomla.

Un servicio externo que tarda 800 milisegundos en responder puede terminar formando parte del tiempo de generación de la página.

Por eso es importante medir cada componente.

## La optimización empieza antes del plugin de caché

El mensaje importante es sencillo.

**La velocidad de Joomla no se arregla instalando caché a ciegas.**

Primero hay que saber dónde está el problema.

Una base de datos llena de registros innecesarios, consultas deficientes, índices incorrectos, PHP mal configurado o un servidor saturado pueden disparar el TTFB.

OPcache puede reducir el trabajo de PHP.

Redis puede acelerar determinados accesos a datos en memoria.

La caché de Joomla puede evitar procesos repetitivos.

Pero ninguna de estas herramientas sustituye un buen diagnóstico.

La mejor optimización suele ser la que elimina trabajo innecesario antes de que el usuario tenga que esperar.

Y eso, en una web Joomla 5, empieza bastante antes de que el navegador reciba el primer byte.

## Checklist rápido de rendimiento para Joomla

Antes de dar por terminado un trabajo de optimización, revisa:

- ☐ ¿Has medido el **TTFB** antes de hacer cambios?
- ☐ ¿Has comprobado la carga real del servidor?
- ☐ ¿**OPcache** está activo?
- ☐ ¿Las tablas utilizan **InnoDB** cuando corresponde?
- ☐ ¿Hay tablas que han crecido de forma desproporcionada?
- ☐ ¿Se están acumulando sesiones antiguas?
- ☐ ¿La tabla de redirecciones necesita mantenimiento?
- ☐ ¿Las extensiones están generando consultas innecesarias?
- ☐ ¿Has identificado las consultas **SQL** más lentas?
- ☐ ¿Los índices responden a las consultas reales?
- ☐ ¿Tiene sentido introducir **Redis** en tu instalación?
- ☐ ¿La caché de **Joomla** está correctamente configurada?
- ☐ ¿Has vuelto a medir después de los cambios?

**Porque si no mides después, puedes pasar horas "optimizando" para descubrir que has conseguido exactamente lo mismo.**

[ Añadir a fuentes preferidas ](https://www.google.com/preferences/source?q=sergioiglesias.net)Gratuito · Primer paso recomendado

### ¿No sabes bien en qué estado

está tu web Joomla?

Antes de decidir si hay que arreglar, migrar o mantener, conviene saber qué está pasando. Reviso el estado de tu web — versión de Joomla, extensiones y lo que se pueda ver — y te digo qué conviene hacer y en qué orden.

Versión de Joomla y ruta de actualización Estado de extensiones Plan de acción con recomendaciones Informe por email + HTML

[ Solicitar revisión gratuita sin compromiso ](https://sergioiglesias.net/revision-joomla-gratis)Respuesta en 24–48 h laborables

[![Sergio Iglesias](https://sergioiglesias.net/images/sergiois-joomla-web.png)](https://sergioiglesias.net/sobre-mi)##### Consultor Web Joomla Senior

Soy [Sergio Iglesias](https://sergioiglesias.net/sobre-mi). Ayudo a empresas, instituciones y profesionales a convertir su web en una herramienta real de negocio: segura, escalable y fácil de gestionar. Soy especialista en migraciones complejas de Joomla sin pérdida de datos, desarrollo de extensiones y plantillas a medida y ofrezco mantenimiento y evolución de tu CMS.

[](https://x.com/sergiois "Sergio Iglesias en X") [](https://www.linkedin.com/in/sergiois "Sergio Iglesias en Linkedin") [](https://github.com/sergiois "Sergio Iglesias en Github") [](https://sergiois.github.io/ "Extensiones Joomla de Sergio Iglesias")

### Suscríbete a mi newsletter

¿Te ha gustado el artículo? Suscríbete a mi newsletter y recibe contenido exclusivo.
Podrás hacer gratis un **Curso de desarrollo de plantillas Joomla**.

[Quiero apuntarme!](https://sergioiglesias.net/newsletter)

###  No hay comentarios

###  Deja tu comentario

 En respuesta a Some User

 Nombre \*

 Dirección de email \*

 Texto del comentario \*

 Doy mi consentimiento para que mi información personal sea recopilada y procesada por este sitio para aceptar y mostrar mi comentario, así como para notificarme sobre las respuestas a él según la [Declaración de privacidad](https://sergioiglesias.net/politica-privacidad) del sitio. \*
