Lo que cuesta realmente en almacenamiento una analítica de comportamiento completa — medido en un sitio WordPress en producción que usa Opti-Behavior.
La base de datos de Opti-Behavior creció unos 6,3 MB al día con 1.725 sesiones diarias, es decir, aproximadamente 1,45 KB por página vista, con mapas de calor, grabaciones de sesión, embudos, tests A/B, recorridos de usuario, analítica de formularios y seguimiento de errores todos activados.
Todos los plugins de analítica para WordPress prometen ser «ligeros». Casi ninguno publica cifras. Este artículo publica cifras y luego explica la arquitectura que las hace posibles, para que puedas comprobar la afirmación en tu propio sitio en lugar de fiarte de una página de marketing.
Explora un panel real antes de instalar nada
Un sitio WordPress en producción con tráfico real, mapas de calor reales y grabaciones reales. Sin registro, sin tarjeta de crédito, sin correo.
Ver la demo en vivo →La versión corta
Opti-Behavior es un plugin de analítica para WordPress autoalojado que guarda metadatos pequeños e indexados en MySQL y envía las cargas pesadas — grabaciones de sesión y flujos de eventos de mapa de calor en bruto — a archivos JSON comprimidos con gzip en disco. En un sitio en producción con todos los módulos activos durante 90 días, Opti-Behavior usó 565 MB de base de datos y 1,52 GB de almacenamiento en archivos para registrar 400.163 páginas vistas:
| Métrica | Valor |
|---|---|
| Periodo medido | 1 de junio – 29 de agosto de 2026 (90 días) |
| Visitantes | 125.889 |
| Sesiones | 155.263 (≈1.725/día) |
| Páginas vistas | 400.163 (≈4.450/día) |
| Huella en MySQL | 565 MB en 34 tablas (852.404 filas) |
| Huella de almacenamiento en archivos | 1,52 GB |
| Huella total | ≈2,07 GB |
| Crecimiento de la base de datos por día | ≈6,3 MB |
| Coste en base de datos por página vista | ≈1,45 KB |
| Coste total por sesión (todo incluido) | ≈14 KB |
| Coste est. por sesión (BD / archivos) | ≈3,7 KB BD / ≈10,3 KB archivos |
| Tamaño medio de grabación de sesión almacenada | ≈69 KB comprimido |
La grabación de sesión es el módulo costoso: 16.627 repeticiones almacenadas representan aproximadamente 1,1 GB de los 1,52 GB en disco. Todo lo demás — cada clic, desplazamiento, muestra de atención, paso de embudo, impresión de test A/B, interacción de formulario, error de JS y muestra de rendimiento — cabe en los ~500 MB de archivos y los 565 MB de base de datos restantes.
Esa es toda la afirmación. El resto de este artículo explica cómo se logra.
El problema: por qué los plugins de analítica arruinan las bases de datos de WordPress
El diseño por defecto de un plugin de seguimiento para WordPress es una fila de MySQL por evento. Funciona de maravilla en una demo y se derrumba en producción, por tres razones predecibles.
Las filas escalan con la interacción, no con el tráfico. Una sola sesión de 90 segundos con un ratón, un desplazamiento y un formulario genera cientos de muestras de coordenadas. Con 1.700 sesiones al día, un esquema ingenuo de una fila por evento escribe decenas de millones de filas al mes en la misma instancia de MySQL que sirve tus páginas.
Las filas grandes envenenan el buffer pool. Las cargas de repetición de sesión son cientos de kilobytes de JSON. Almacenadas como LONGTEXT junto a tus artículos y opciones, desplazan de la caché las páginas que MySQL realmente necesita. Tu sitio no se ralentiza porque el plugin esté consultando la base de datos: se ralentiza porque todo lo demás dejó de caber en memoria.
Leer-modificar-escribir mata las sesiones largas. Una sesión que aún se está grabando debe actualizarse repetidamente. Si cada actualización lee toda la carga acumulada, la fusiona, la reordena y la recomprime antes de reescribirla, el coste de almacenar una sesión crece con el cuadrado de su duración. Las sesiones más largas y valiosas se vuelven las más costosas.
Cada decisión de diseño de abajo existe para vencer uno de esos tres modos de fallo.
Diseño 1: almacenamiento híbrido — MySQL para consultas, archivos para cargas
La regla es simple: si lo consultas, vive en MySQL. Si solo lo reproduces, vive en disco, comprimido.
| Dato | Dónde vive | Por qué |
|---|---|---|
| Sesiones, visitantes, páginas vistas, páginas de sesión | MySQL (indexado) | Filtrado, agrupado y unido en cada carga del panel |
| Pasos de embudo, impresiones y conversiones de tests A/B, interacciones de formulario | MySQL | Agregado en tiempo real |
| Errores de JS, muestras de rendimiento, fuentes de tráfico | MySQL | Consultado por página, fecha y tipo |
| Metadatos de grabación (id de sesión, duración, número de eventos, página) | MySQL (fila pequeña) | Alimenta la lista y búsqueda de grabaciones |
| Flujos de eventos de grabación (mutaciones DOM de rrweb) | archivo JSON gzip | Solo se lee una vez, entero, al reproducir |
| Lotes de eventos de mapa de calor en bruto (clics, movimientos, atención) | archivo JSON gzip | Solo se lee para renderizar el mapa de calor de una página |
Agregados diarios (daily_stats, daily_dimension_stats, heatmap_daily, ab_daily_stats) | MySQL (diminuto) | Sirve todos los gráficos históricos |
Los archivos se escriben bajo wp-content/uploads/opti-behavior-data, repartidos en carpetas por fecha y hora para que ningún directorio acumule un número patológico de entradas, y se comprimen con zlib a nivel 9. La tasa de compresión sobre la salida de rrweb es severa — los flujos de mutaciones DOM son extremadamente repetitivos —, por eso una repetición de sesión completa ocupa de media 69 KB en disco en lugar de los 1-3 MB que ocupa sin comprimir.
La consecuencia para MySQL es la cifra que importa: la base de datos crece unos 6,3 MB al día con 1.700 sesiones diarias, y crece en filas pequeñas, indexadas y amigables con la caché.
Diseño 2: escrituras solo-anexar, para que las sesiones largas sigan siendo baratas
La forma ingenua de actualizar una grabación en crecimiento es: leer el archivo completo, descomprimirlo, fusionar los nuevos eventos, reordenarlo todo, recomprimir a nivel 9 y reescribir el archivo. En cada guardado. Eso es un trabajo O(N²) a lo largo de la vida de una sesión, y es la razón número uno por la que los plugins de grabación de sesión se describen como «pesados».
Opti-Behavior escribe el archivo base de la grabación exactamente una vez. Cada lote posterior de eventos se anexa como una línea NDJSON a un archivo auxiliar (.oblog), mientras un segundo archivo auxiliar diminuto (.obidx) lleva contadores en marcha — número de eventos y duración — de modo que los límites de tamaño y de eventos se puedan aplicar en tiempo constante sin volver a leer nunca la carga.
La fusión y el ordenamiento ocurren una sola vez, en el momento de la lectura, cuando alguien realmente abre la repetición. Las escrituras son anexados. Una sesión de cuatro minutos y una de cuarenta minutos cuestan lo mismo por evento.
Diseño 3: un rastreador que nunca pelea con el hilo principal
El coste del lado del cliente es donde las promesas de «ligereza» suelen morir en silencio. El rastreador se construye alrededor de cuatro restricciones:
Escuchadores pasivos en todas partes. Cada escuchador de mousemove, scroll y click se registra como pasivo, de modo que el navegador nunca se ve forzado a esperar al código de seguimiento antes de poder desplazarse o pintar.
Lotes, no charla constante. Los eventos se acumulan en memoria y se envían por intervalo o por umbral de tamaño, no evento por evento. Los lotes tienen un tope deliberado, porque cargas sin límite de 8-10 MB son exactamente lo que empuja a un hosting compartido de 128 MB hacia un error HTTP 500.
Compresión en el navegador, en flujo. Las cargas se comprimen con gzip antes de salir de la página usando la API nativa CompressionStream — el compresor en flujo propio del navegador, no una implementación de zlib en JavaScript que bloquee el hilo principal. Menos ancho de banda para el visitante, menos CPU en el servidor, sin bloqueos. Cuando CompressionStream no está disponible, el rastreador recurre a una subida multipart simple con un tope de tamaño menor en lugar de intentar comprimir en JS.
Entrega que sobrevive a la navegación. Los envíos usan navigator.sendBeacon, con respaldo en fetch con keepalive. El rastreador nunca retiene el unload, y nunca necesita hacerlo, porque no le está pidiendo a la página que espere.
Los scripts también declaran data-cfasync="false" y llevan una capa de compatibilidad dedicada para WP Rocket, LiteSpeed Cache, SG Optimizer y otros grandes optimizadores — porque el rastreador más rápido del mundo sigue siendo lento si tu plugin de caché lo concatena y lo difiere en el orden de ejecución equivocado.
Diseño 4: un panel que pone en cola sus propias consultas
El rendimiento de escritura es la mitad de la historia. La otra mitad es lo que ocurre cuando abres un panel de analítica con 850.000 filas y 167.000 archivos.
La implementación obvia — disparar la petición AJAX de cada widget a la vez con Promise.all — es la equivocada. Seis escaneos pesados de GROUP BY lanzados simultáneamente contra un buffer pool de InnoDB frío en hosting compartido saturan el disco, y cada una de esas consultas termina más lenta que si se hubieran ido soltando poco a poco. El paralelismo más allá de cierto punto no es velocidad; es congestión.
Así que el panel programa en su lugar:
- Concurrencia acotada. Un pequeño grupo limita cuántas consultas de widgets están en vuelo a la vez. Mismos widgets, mismos datos, base de datos estable.
- Paralelo dentro de una sección, secuencial entre secciones. La primera sección carga sus widgets juntos, y luego arma la siguiente sección, ascendiendo, una lista a la vez.
- Cero AJAX para lo que no has abierto. Las secciones colapsadas no piden nada hasta que haces clic en la flecha; ese primer clic arma la cascada del resto.
- Bloqueo por dependencia para afinidad de caché. Los widgets que comparten una serie calculada esperan al que ceba el transient compartido, para que la consulta cara se ejecute una vez en lugar de seis.
El renderizado de mapas de calor usa la misma filosofía, pero contra archivos en vez de filas. El mapa de calor de una página puede referenciar miles de archivos JSON comprimidos, así que se cargan progresivamente en lotes pequeños con pausas asíncronas entre ellos, manteniendo la interfaz receptiva mientras la superposición se rellena. El renderizado reproyecta en fragmentos y se pausa al desplazarse, el cargador se detiene por completo cuando la pestaña del navegador está oculta y retoma donde se quedó, y el usuario puede detener una carga larga en cualquier momento.
El resultado es un panel que permanece interactivo en hardware donde una descarga de Promise.all produciría un spinner y un 504.
Diseño 5: retención por niveles — historial sin acumular basura
Los datos en bruto son la parte que crece sin límite. Los agregados no. Opti-Behavior los separa con un modelo de retención de cuatro niveles:
- Sesiones de spam y de bots — purgadas automáticamente cada día.
- Archivos pesados — las grabaciones y los archivos de eventos de mapa de calor en bruto caducan primero (90 días por defecto).
- Datos detallados — sesiones, eventos, filas por visitante caducan después (365 días por defecto).
- Agregados del panel — las tablas de estadísticas diarias se conservan para siempre.
La ventana de archivos está limitada para que nunca pueda superar a la ventana de datos detallados, y los archivos nunca quedan huérfanos: se eliminan en la misma cascada que sus filas de base de datos.
Por eso la base de datos del sitio medido guarda apenas 25.000 filas de sesión detalladas mientras el panel reporta con confianza 155.263 sesiones en los mismos 90 días. Las sesiones de spam y de bots se eliminan como filas en bruto — con sus eventos, grabaciones y archivos, en una sola cascada —, pero los recuentos diarios sobreviven en los agregados diarios, incluidos los recuentos de sesiones de spam y automatizadas que producen tus porcentajes de tráfico de bots.
Ese es el trato en una frase: conservas la cifra, descartas el cadáver. Puedes seguir respondiendo «cuántas sesiones de bots visitaron este sitio en junio» un año después, por el coste de una fila al día, sin almacenar ni una sola de esas sesiones.
Ese desacoplamiento es la respuesta real a «¿seguirá siendo rápido este plugin dentro de dos años?». Los datos detallados tienen un horizonte. Los agregados son permanentes y cuestan kilobytes.
La válvula de seguridad: una limpieza que se niega a ejecutarse
La eliminación automática es peligrosa, y Opti-Behavior la trata como tal. Cada pasada de limpieza automatizada — el nivel diario de spam y cualquier regla condicional programada — mide primero qué proporción de la tabla de sesiones está a punto de borrar. Si esa proporción supera el 50%, la ejecución se aborta y registra una advertencia en lugar de borrar nada, bajo el supuesto de que una regla que coincide con la mayoría de tus datos es una regla mal configurada o descontrolada, no una purga legítima. Las limpiezas manuales desde la Zona de Peligro no están bloqueadas deliberadamente: una confirmación humana explícita puede hacer lo que un cron desatendido no puede.
Como un disyuntor permanentemente disparado dejaría acumularse filas marcadas para siempre, una segunda regla actúa por debajo: mientras el disyuntor está disparado, las sesiones de spam de más de 30 días se siguen eliminando por antigüedad dentro del tope nocturno. Los incidentes de clasificación errónea etiquetan mal sesiones recientes con interacción real, así que las filas marcadas antiguas se pueden eliminar con seguridad mientras las recientes esperan revisión. La base de datos nunca puede crecer sin límite, y una regla defectuosa nunca puede borrar tu conjunto de datos en silencio de la noche a la mañana.
Cada ejecución se registra en un log de limpieza con sus recuentos, sus advertencias y su desglose de filas por tabla, para que nada sobre lo que se borró — o por qué no se borró nada — sea un misterio.
Diseño 6: filtrar antes de almacenar, no después
La fila más barata es la que nunca se escribe. Una puerta de entrada dedicada y un clasificador de bots se ejecutan antes de la persistencia, de modo que el tráfico de rastreadores y automatizado se clasifica al llegar en lugar de descubrirse durante una dolorosa limpieza seis meses después. En el sitio medido, se registran 74.051 visitas de bots como filas de clasificación compactas — no como sesiones con grabaciones, archivos de mapa de calor y flujos de eventos adjuntos.
Qué significa esto para tu hosting
Traduce las cifras por unidad a tu propio tráfico:
| Tu tráfico | Crecimiento est. de BD / mes | Huella total est. / mes (con grabaciones activas) |
|---|---|---|
| 500 páginas vistas/día | ~22 MB | ~80 MB |
| 2.000 páginas vistas/día | ~87 MB | ~325 MB |
| 5.000 páginas vistas/día | ~215 MB | ~815 MB |
| 15.000 páginas vistas/día | ~650 MB | ~2,4 GB |
Dos notas prácticas. Primero, las grabaciones dominan el total de archivos; muestrearlas o acortar la ventana de archivos pesados es la palanca más eficaz si el disco anda justo, y no te cuesta nada en el historial del panel porque los agregados no se ven afectados. Segundo, la columna de base de datos es la que a tu hosting realmente le importa en planes compartidos — y es la pequeña.
Metodología
Las cifras proceden de las propias pantallas de Resumen de Almacenamiento y Estadísticas de Base de Datos de Opti-Behavior en un sitio WordPress en producción, medidas el 29 de agosto de 2026 sobre el rango 1 de junio – 29 de agosto de 2026, con todos los módulos activados: analítica en tiempo real, mapas de calor de clic/movimiento/atención, grabación de sesión, embudos, tests A/B, recorridos de usuario, analítica de formularios, seguimiento de errores y rendimiento. La retención estaba en sus valores por defecto: purga diaria de spam activada, archivos pesados 90 días, datos detallados 365 días, agregados para siempre. Los totales son las propias mediciones del plugin sobre sus tablas y su directorio de datos, no estimaciones.
Explora un panel real antes de instalar nada
Un sitio WordPress en producción con tráfico real, mapas de calor reales y grabaciones reales. Sin registro, sin tarjeta de crédito, sin correo.
Ver la demo en vivo →Preguntas frecuentes
¿Opti-Behavior ralentiza mi base de datos de WordPress?
Está diseñado para que la base de datos crezca despacio y en filas pequeñas e indexadas: unos 6,3 MB al día con 1.700 sesiones diarias, aproximadamente 1,45 KB por página vista. Las cargas pesadas nunca entran en MySQL: las grabaciones y los eventos de mapa de calor en bruto se guardan como archivos JSON comprimidos fuera de la base de datos.
¿Cuánto espacio en disco usa Opti-Behavior?
En un sitio con 400.163 páginas vistas en 90 días y todos los módulos activados: 565 MB de base de datos y 1,52 GB de archivos, ≈2,07 GB en total, o unos 14 KB por sesión incluyendo la repetición completa de la sesión.
¿Dónde se guardan las grabaciones de sesión?
En archivos JSON comprimidos con gzip bajo wp-content/uploads/opti-behavior-data, repartidos por fecha y hora, con solo una pequeña fila de metadatos en MySQL. Una grabación almacenada pesa de media unos 69 KB.
¿El script de seguimiento perjudica los Core Web Vitals?
El rastreador usa escuchadores de eventos pasivos, agrupa eventos en lugar de enviar una petición por evento, comprime las cargas con la API nativa en flujo CompressionStream del navegador y las entrega con sendBeacon o fetch con keepalive. Nunca bloquea el desplazamiento, el renderizado ni la navegación.
¿Qué pasa con mis datos antiguos?
Las sesiones de spam y de bots se purgan a diario. Las grabaciones y los archivos de mapa de calor en bruto caducan a los 90 días por defecto, los datos detallados de sesión a los 365 días, y los agregados diarios del panel se conservan para siempre, así que los gráficos y totales siguen funcionando para fechas mucho más antiguas que las ventanas de datos en bruto. Todas las ventanas son configurables.
¿El panel se vuelve lento cuando hay muchos datos?
El panel ejecuta sus consultas de widgets a través de una cola de concurrencia acotada en lugar de dispararlas todas a la vez, carga las secciones de forma perezosa a medida que las expandes y comparte cachés de consulta cebadas entre widgets relacionados. Las páginas de mapa de calor cargan sus archivos de eventos comprimidos en lotes progresivos pequeños que ceden el control al navegador, se pausan cuando la pestaña está oculta y se pueden detener a mitad de carga.
¿La limpieza automática puede borrar datos que quería conservar?
Las pasadas de limpieza automatizadas se abortan si una regla borraría más del 50% de la tabla de sesiones, registrando una advertencia en su lugar. Mientras ese disyuntor está disparado, solo se eliminan por antigüedad las sesiones de spam de más de 30 días, así que la base de datos sigue sin poder crecer sin límite. Las limpiezas manuales desde la Zona de Peligro no están bloqueadas, porque llevan una confirmación explícita.
¿Opti-Behavior es compatible con plugins de caché y optimización?
Sí. Incluye una capa de compatibilidad dedicada para WP Rocket, LiteSpeed Cache, SG Optimizer y otros, y marca sus scripts con data-cfasync="false" para que los optimizadores no rompan el orden de ejecución del rastreador.
¿Mis datos salen de mi servidor?
No. Opti-Behavior es completamente autoalojado. Las sesiones, grabaciones, mapas de calor y agregados se quedan en tu propia base de datos y tu propio directorio de subidas, lo que hace viable el cumplimiento del RGPD desde el principio.
¿En qué se diferencia de un plugin que lo guarda todo en MySQL?
Un diseño de una fila por evento escribe decenas de millones de filas al mes con este nivel de tráfico y guarda las cargas de repetición como columnas de texto grandes junto a tus artículos, lo que desplaza páginas útiles del buffer pool de InnoDB. El modelo híbrido mantiene MySQL pequeño y consultable, y pone las cargas voluminosas donde deben estar: en disco, comprimidas.
Pruébalo en tu propio sitio
Instala Opti-Behavior desde el directorio de plugins de WordPress, déjalo funcionar una semana y abre Resumen de Almacenamiento. El plugin mide su propia huella hasta el nivel de tabla. Compara la cifra con lo que estés usando hoy.
Más sobre los módulos Pro — grabación de sesión, embudos, tests A/B, analítica de formularios — en optiuser.com.
