155 000 sessions en 90 jours pour 6 Mo de croissance de base de données par jour
Ce que coûte réellement en stockage une analyse comportementale complète — mesuré sur un site WordPress en production utilisant Opti-Behavior.
La base de données d’Opti-Behavior a grossi d’environ 6,3 Mo par jour pour 1 725 sessions par jour, soit environ 1,45 Ko par page vue, avec les heatmaps, les enregistrements de session, les entonnoirs de conversion, les tests A/B, les parcours utilisateurs, l’analyse des formulaires et le suivi des erreurs, tous activés.
Tous les plugins d’analytics WordPress promettent d’être « légers ». Presque aucun ne publie de chiffres. Cet article publie des chiffres, puis explique l’architecture qui les rend possibles, afin que vous puissiez vérifier l’affirmation sur votre propre site plutôt que de faire confiance à une page marketing.
Explorez un vrai tableau de bord avant d’installer quoi que ce soit
Un site WordPress en production avec du vrai trafic, de vraies heatmaps et de vrais enregistrements. Sans inscription, sans carte bancaire, sans email.
Voir la démo en direct →En résumé
Opti-Behavior est un plugin d’analytics WordPress auto-hébergé qui stocke de petites métadonnées indexées dans MySQL et envoie les charges lourdes — enregistrements de session et flux d’événements de heatmap bruts — dans des fichiers JSON compressés en gzip sur le disque. Sur un site en production avec tous les modules activés pendant 90 jours, Opti-Behavior a utilisé 565 Mo de base de données et 1,52 Go de stockage fichiers pour suivre 400 163 pages vues :
| Indicateur | Valeur |
|---|---|
| Période mesurée | 1er juin – 29 août 2026 (90 jours) |
| Visiteurs | 125 889 |
| Sessions | 155 263 (≈1 725/jour) |
| Pages vues | 400 163 (≈4 450/jour) |
| Empreinte MySQL | 565 Mo sur 34 tables (852 404 lignes) |
| Empreinte du stockage fichiers | 1,52 Go |
| Empreinte totale | ≈2,07 Go |
| Croissance de la base de données par jour | ≈6,3 Mo |
| Coût base de données par page vue | ≈1,45 Ko |
| Coût total par session (tout compris) | ≈14 Ko |
| Coût est. par session (BDD / fichiers) | ≈3,7 Ko BDD / ≈10,3 Ko fichiers |
| Taille moyenne d’un enregistrement de session stocké | ≈69 Ko compressé |
L’enregistrement de session est le module coûteux : 16 627 replays stockés représentent environ 1,1 Go des 1,52 Go sur disque. Tout le reste — chaque clic, défilement, échantillon d’attention, étape d’entonnoir, impression A/B, interaction de formulaire, erreur JS et échantillon de performance — tient dans les ~500 Mo de fichiers et les 565 Mo de base de données restants.
C’est là toute l’affirmation. Le reste de cet article explique comment.
Le problème : pourquoi les plugins d’analytics ruinent les bases de données WordPress
La conception par défaut d’un plugin de suivi WordPress est une ligne MySQL par événement. Cela fonctionne magnifiquement en démo et s’effondre en production, pour trois raisons prévisibles.
Le nombre de lignes suit l’engagement, pas le trafic. Une seule session de 90 secondes avec une souris, un défilement et un formulaire génère des centaines d’échantillons de coordonnées. À 1 700 sessions par jour, un schéma naïf d’une ligne par événement écrit des dizaines de millions de lignes par mois dans la même instance MySQL qui sert vos pages.
Les grosses lignes empoisonnent le buffer pool. Les charges de replay de session pèsent des centaines de kilo-octets de JSON. Stockées en LONGTEXT à côté de vos articles et options, elles évincent les pages dont MySQL a réellement besoin en cache. Votre site ne ralentit pas parce que le plugin interroge la base — il ralentit parce que tout le reste ne tient plus en mémoire.
Le lire-modifier-écrire tue les sessions longues. Une session encore en cours d’enregistrement doit être mise à jour à répétition. Si chaque mise à jour relit l’intégralité de la charge accumulée, la fusionne, la retrie et la recompresse avant de la réécrire, le coût de stockage d’une session croît avec le carré de sa durée. Les sessions les plus longues et les plus précieuses deviennent les plus coûteuses.
Chaque décision de conception ci-dessous existe pour déjouer l’un de ces trois modes de défaillance.
Conception 1 : stockage hybride — MySQL pour les questions, fichiers pour les charges
La règle est simple : si vous l’interrogez, ça vit dans MySQL. Si vous ne faites que le rejouer, ça vit sur disque, compressé.
| Donnée | Où elle vit | Pourquoi |
|---|---|---|
| Sessions, visiteurs, pages vues, pages de session | MySQL (indexé) | Filtré, groupé et joint à chaque chargement du dashboard |
| Étapes d’entonnoir, impressions et conversions A/B, interactions de formulaire | MySQL | Agrégé en temps réel |
| Erreurs JS, échantillons de performance, sources de trafic | MySQL | Interrogé par page, date et type |
| Métadonnées d’enregistrement (id de session, durée, nombre d’événements, page) | MySQL (petite ligne) | Alimente la liste des enregistrements et la recherche |
| Flux d’événements d’enregistrement (mutations DOM rrweb) | fichier JSON gzip | Lu une seule fois, en entier, à la lecture |
| Lots d’événements heatmap bruts (clics, mouvements, attention) | fichier JSON gzip | Lu uniquement pour restituer la heatmap d’une page |
Agrégats journaliers (daily_stats, daily_dimension_stats, heatmap_daily, ab_daily_stats) | MySQL (minuscule) | Alimente tous les graphiques historiques |
Les fichiers sont écrits sous wp-content/uploads/opti-behavior-data, répartis en dossiers par date et par heure pour qu’aucun répertoire unique ne contienne jamais un nombre pathologique d’entrées, et compressés avec zlib au niveau 9. Le taux de compression sur les flux rrweb est sévère — les flux de mutations DOM sont extrêmement répétitifs — ce qui explique qu’un replay de session complet pèse en moyenne 69 Ko sur disque au lieu des 1 à 3 Mo qu’il occupe non compressé.
La conséquence pour MySQL est le chiffre qui compte : la base de données grossit d’environ 6,3 Mo par jour pour 1 700 sessions par jour, et elle grossit en petites lignes indexées, adaptées au cache.
Conception 2 : écritures en ajout seul, pour que les sessions longues restent bon marché
La façon naïve de mettre à jour un enregistrement qui grandit est : lire tout le fichier, le décompresser, fusionner les nouveaux événements, tout retrier, recompresser au niveau 9, réécrire le fichier. À chaque sauvegarde. C’est un travail en O(N²) sur la durée de vie d’une session, et c’est la raison la plus fréquente pour laquelle les plugins d’enregistrement de session sont qualifiés de « lourds ».
Opti-Behavior écrit le fichier d’enregistrement de base exactement une fois. Chaque lot d’événements suivant est ajouté comme une ligne NDJSON à un fichier annexe (.oblog), tandis qu’un second fichier annexe minuscule (.obidx) porte des compteurs courants — nombre d’événements et durée — pour que les plafonds de taille et d’événements restent applicables en temps constant, sans jamais relire la charge.
La fusion et le tri n’ont lieu qu’une seule fois, à la lecture, quand quelqu’un ouvre réellement le replay. Les écritures sont des ajouts. Une session de quatre minutes et une session de quarante minutes coûtent la même chose par événement.
Conception 3 : un tracker qui ne se bat jamais avec le thread principal
Le coût côté client est là où les promesses de « légèreté » meurent discrètement. Le tracker est construit autour de quatre contraintes :
Des écouteurs passifs partout. Chaque écouteur mousemove, scroll et click est enregistré en mode passif, pour que le navigateur ne soit jamais forcé d’attendre le code de suivi avant de pouvoir défiler ou peindre.
Du regroupement, pas du bavardage. Les événements s’accumulent en mémoire et sont envoyés sur un intervalle ou un seuil de taille, pas événement par événement. Les lots sont plafonnés délibérément, car des charges non plafonnées de 8 à 10 Mo sont exactement ce qui pousse un hébergement partagé à 128 Mo vers une erreur HTTP 500.
Compression dans le navigateur, en streaming. Les charges sont compressées en gzip avant de quitter la page grâce à l’API native CompressionStream — le compresseur en streaming natif du navigateur, pas une implémentation zlib en JavaScript bloquant le thread principal. Moins de bande passante pour le visiteur, moins de CPU côté serveur, aucun à-coup. Quand CompressionStream n’est pas disponible, le tracker bascule sur un envoi multipart simple avec un plafond de taille plus bas plutôt que de tenter de compresser en JS.
Une livraison qui survit à la navigation. Les envois utilisent navigator.sendBeacon, avec repli sur fetch et keepalive. Le tracker ne retient jamais l’événement unload, et il n’en a d’ailleurs jamais besoin, puisqu’il ne demande pas à la page d’attendre.
Les scripts déclarent aussi data-cfasync="false" et embarquent une couche de compatibilité dédiée pour WP Rocket, LiteSpeed Cache, SG Optimizer et les autres grands optimiseurs — parce que le tracker le plus rapide du monde reste lent si votre plugin de cache le concatène et le diffère dans le mauvais ordre d’exécution.
Conception 4 : un dashboard qui met ses propres requêtes en file d’attente
La performance à l’écriture n’est que la moitié de l’histoire. L’autre moitié, c’est ce qui se passe quand vous ouvrez un dashboard d’analytics contenant 850 000 lignes et 167 000 fichiers.
L’implémentation évidente — tirer la requête AJAX de chaque widget d’un coup avec Promise.all — est la mauvaise. Six scans GROUP BY lourds lancés simultanément contre un buffer pool InnoDB froid sur un hébergement partagé saturent le disque, et chacun d’eux finit plus lentement que s’ils avaient été distillés un par un. La parallélisation, passé un certain seuil, n’est pas de la vitesse ; c’est de la congestion.
Le dashboard planifie donc plutôt :
- Concurrence bornée. Un petit pool plafonne le nombre de requêtes de widgets en vol à la fois. Mêmes widgets, mêmes données, base de données stable.
- Parallèle au sein d’une section, séquentiel entre les sections. La première section charge ses widgets ensemble, puis arme la section suivante, en montant, une liste à la fois.
- Zéro AJAX pour ce que vous n’avez pas ouvert. Les sections repliées ne récupèrent rien tant que vous ne cliquez pas sur le chevron ; ce premier clic arme la cascade pour le reste.
- Blocage de dépendance pour l’affinité de cache. Les widgets qui partagent une série calculée attendent celui qui amorce le transient partagé, pour que la requête coûteuse s’exécute une fois au lieu de six.
Le rendu des heatmaps applique la même philosophie aux fichiers plutôt qu’aux lignes. La heatmap d’une page peut référencer des milliers de fichiers d’événements JSON compressés ; ils sont donc chargés progressivement, par petits lots, avec des pauses asynchrones entre eux, pour que l’interface reste réactive pendant que la superposition se remplit. Le rendu se reprojette par blocs et se met en pause sur le défilement, le chargeur se met entièrement en pause quand l’onglet du navigateur est masqué et reprend où il s’était arrêté, et l’utilisateur peut interrompre un chargement long à tout moment.
Le résultat est un dashboard qui reste interactif sur un matériel où une rafale Promise.all produirait un spinner et une erreur 504.
Conception 5 : rétention par paliers — de l’historique sans accumulation
Les données brutes sont la partie qui grandit sans limite. Les agrégats, non. Opti-Behavior les sépare avec un modèle de rétention à quatre paliers :
- Sessions de spam et de bots — purgées automatiquement chaque jour.
- Fichiers lourds — les enregistrements et les fichiers d’événements heatmap bruts expirent en premier (90 jours par défaut).
- Données détaillées — sessions, événements, lignes par visiteur expirent plus tard (365 jours par défaut).
- Agrégats du dashboard — les tables de statistiques journalières sont conservées indéfiniment.
La fenêtre des fichiers est plafonnée pour ne jamais dépasser la fenêtre des données détaillées, et les fichiers ne sont jamais orphelins : ils sont supprimés dans la même cascade que leurs lignes de base de données.
C’est pourquoi la base de données du site mesuré ne contient qu’environ 25 000 lignes de sessions détaillées alors que le dashboard rapporte avec assurance 155 263 sessions sur la même période de 90 jours. Les sessions de spam et de bots sont supprimées en tant que lignes brutes — avec leurs événements, enregistrements et fichiers, en une seule cascade — mais les comptages journaliers survivent dans les agrégats journaliers, y compris les comptages de sessions spam et automatisées qui produisent vos pourcentages de trafic de bots.
C’est l’échange en une phrase : vous gardez le chiffre, vous jetez la carcasse. Vous pouvez toujours répondre « combien de sessions de bots ont touché ce site en juin » un an plus tard, pour le coût d’une ligne par jour, sans stocker une seule de ces sessions.
Ce découplage est la véritable réponse à « ce plugin sera-t-il encore rapide dans deux ans ». Les données détaillées ont un horizon. Les agrégats sont permanents et coûtent des kilo-octets.
La soupape de sécurité : un nettoyage qui refuse de s’exécuter
La suppression automatique est dangereuse, et Opti-Behavior la traite comme telle. Chaque passe de nettoyage automatisée — le palier spam quotidien et toute règle conditionnelle planifiée — mesure d’abord quelle part de la table des sessions elle s’apprête à supprimer. Si cette part dépasse 50 %, l’exécution s’interrompt et consigne un avertissement au lieu de supprimer quoi que ce soit, sur l’hypothèse qu’une règle qui correspond à la majorité de vos données est une règle mal configurée ou défaillante, pas une purge légitime. Les nettoyages manuels depuis la Zone de danger ne sont volontairement pas bloqués : une confirmation humaine explicite est autorisée à faire ce qu’une tâche cron non surveillée ne peut pas faire.
Parce qu’un disjoncteur déclenché en permanence laisserait les lignes signalées s’accumuler indéfiniment, une seconde règle s’exécute en dessous : tant que le disjoncteur est déclenché, les sessions spam de plus de 30 jours continuent d’être purgées, des plus anciennes aux plus récentes, dans la limite du plafond nocturne. Les incidents de mauvaise classification touchent des sessions engagées récentes, donc les anciennes lignes signalées peuvent être supprimées sans risque pendant que les récentes attendent une revue. La base de données ne peut jamais croître sans limite, et une mauvaise règle ne peut jamais effacer silencieusement votre jeu de données du jour au lendemain.
Chaque exécution est consignée dans un journal de nettoyage avec ses comptages, ses avertissements et sa répartition des lignes par table, pour que rien de ce qui a été supprimé — ou de ce qui ne l’a pas été — ne reste un mystère.
Conception 6 : filtrer avant de stocker, pas après
La ligne la moins chère est celle qui n’est jamais écrite. Une porte d’entrée dédiée et un classificateur de bots s’exécutent avant la persistance, pour que le trafic de crawlers et automatisé soit classifié dès son arrivée plutôt que découvert pendant un nettoyage pénible six mois plus tard. Sur le site mesuré, 74 051 visites de bots sont enregistrées comme des lignes de classification compactes — pas comme des sessions avec enregistrements, fichiers heatmap et flux d’événements attachés.
Ce que cela signifie pour votre hébergement
Transposez les chiffres unitaires à votre propre trafic :
| Votre trafic | Croissance BDD est. / mois | Empreinte totale est. / mois (enregistrements activés) |
|---|---|---|
| 500 pages vues/jour | ~22 Mo | ~80 Mo |
| 2 000 pages vues/jour | ~87 Mo | ~325 Mo |
| 5 000 pages vues/jour | ~215 Mo | ~815 Mo |
| 15 000 pages vues/jour | ~650 Mo | ~2,4 Go |
Deux remarques pratiques. D’abord, les enregistrements dominent le total fichiers ; les échantillonner ou raccourcir la fenêtre des fichiers lourds est le levier le plus puissant si l’espace disque est serré, et cela ne coûte rien à l’historique du dashboard puisque les agrégats ne sont pas affectés. Ensuite, la colonne base de données est celle à laquelle votre hébergeur s’intéresse réellement sur les offres mutualisées — et c’est la petite.
Méthodologie
Les chiffres proviennent des écrans Aperçu du stockage et Statistiques de base de données d’Opti-Behavior lui-même, sur un site WordPress en production, mesurés le 29 août 2026 sur la période du 1er juin au 29 août 2026, avec tous les modules activés : analytics en temps réel, heatmaps de clics/mouvements/attention, enregistrement de session, entonnoirs de conversion, tests A/B, parcours utilisateurs, analyse des formulaires, suivi des erreurs et des performances. La rétention était aux réglages par défaut : purge spam quotidienne activée, fichiers lourds 90 jours, données détaillées 365 jours, agrégats indéfiniment. Les totaux sont les mesures propres du plugin sur ses tables et son répertoire de données, pas des estimations.
Explorez un vrai tableau de bord avant d’installer quoi que ce soit
Un site WordPress en production avec du vrai trafic, de vraies heatmaps et de vrais enregistrements. Sans inscription, sans carte bancaire, sans email.
Voir la démo en direct →FAQ
Opti-Behavior ralentit-il ma base de données WordPress ?
Il est conçu pour que la base de données grossisse lentement et en petites lignes indexées : environ 6,3 Mo par jour pour 1 700 sessions par jour, soit environ 1,45 Ko par page vue. Les charges lourdes n’entrent jamais dans MySQL — les enregistrements et les événements heatmap bruts sont stockés sous forme de fichiers JSON compressés en dehors de la base de données.
Quel espace disque Opti-Behavior utilise-t-il ?
Sur un site avec 400 163 pages vues sur 90 jours et tous les modules activés : 565 Mo de base de données et 1,52 Go de fichiers, ≈2,07 Go au total, soit environ 14 Ko par session en incluant le replay complet.
Où sont stockés les enregistrements de session ?
Dans des fichiers JSON compressés en gzip sous wp-content/uploads/opti-behavior-data, répartis par date et par heure, avec seulement une petite ligne de métadonnées dans MySQL. Un enregistrement stocké pèse en moyenne environ 69 Ko.
Le script de suivi nuit-il aux Core Web Vitals ?
Le tracker utilise des écouteurs d’événements passifs, regroupe les événements au lieu d’envoyer une requête par événement, compresse les charges avec l’API native de streaming CompressionStream du navigateur, et les livre via sendBeacon ou fetch avec keepalive. Il ne bloque jamais le défilement, le rendu ou la navigation.
Qu’advient-il de mes anciennes données ?
Les sessions de spam et de bots sont purgées quotidiennement. Les enregistrements et les fichiers heatmap bruts expirent après 90 jours par défaut, les données de session détaillées après 365 jours, et les agrégats journaliers du dashboard sont conservés indéfiniment — les graphiques et les totaux continuent donc de fonctionner pour des dates bien plus anciennes que les fenêtres de données brutes. Toutes les fenêtres sont configurables.
Le dashboard est-il lent une fois qu’il y a beaucoup de données ?
Le dashboard fait passer ses requêtes de widgets par une file à concurrence bornée plutôt que de toutes les lancer d’un coup, charge les sections paresseusement à mesure que vous les développez, et partage les caches de requêtes amorcées entre widgets liés. Les pages heatmap chargent leurs fichiers d’événements compressés par petits lots progressifs qui cèdent la main au navigateur, se mettent en pause quand l’onglet est masqué et peuvent être interrompues en cours de chargement.
Le nettoyage automatique peut-il supprimer des données que je voulais garder ?
Les passes de nettoyage automatisées s’interrompent si une règle supprimerait plus de 50 % de la table des sessions, en consignant un avertissement à la place. Tant que ce disjoncteur est déclenché, seules les sessions spam de plus de 30 jours sont purgées, donc la base de données ne peut toujours pas croître sans limite. Les nettoyages manuels depuis la Zone de danger ne sont pas bloqués, car ils portent une confirmation explicite.
Est-ce qu’Opti-Behavior est compatible avec les plugins de cache et d’optimisation ?
Oui. Il embarque une couche de compatibilité dédiée pour WP Rocket, LiteSpeed Cache, SG Optimizer et d’autres, et marque ses scripts data-cfasync="false" pour que les optimiseurs ne cassent pas l’ordre d’exécution du tracker.
Mes données quittent-elles mon serveur ?
Non. Opti-Behavior est entièrement auto-hébergé. Sessions, enregistrements, heatmaps et agrégats restent dans votre propre base de données et votre propre répertoire uploads, ce qui rend la conformité RGPD réalisable dès le départ.
En quoi est-ce différent d’un plugin qui stocke tout dans MySQL ?
Une conception une-ligne-par-événement écrit des dizaines de millions de lignes par mois à ce niveau de trafic et stocke les charges de replay comme de grandes colonnes texte à côté de vos articles, ce qui évince les pages utiles du buffer pool InnoDB. Le modèle hybride garde MySQL petit et interrogeable et place les charges volumineuses là où elles doivent être — sur disque, compressées.
Essayez-le sur votre propre site
Installez Opti-Behavior depuis l’annuaire des plugins WordPress, depuis l’annuaire des plugins WordPress, laissez-le tourner une semaine, et ouvrez Aperçu du stockage. Le plugin mesure sa propre empreinte jusqu’à la table. Comparez le chiffre à ce que vous utilisez aujourd’hui.
Plus d’informations sur les modules Pro — enregistrement de session, entonnoirs de conversion, tests A/B, analyse des formulaires — sur optiuser.com.
{« @context »: »https://schema.org », »@type »: »FAQPage », »mainEntity »:[{« @type »: »Question », »name »: »Opti-Behavior ralentit-il ma base de données WordPress ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Opti-Behavior ne stocke que de petites métadonnées indexées dans MySQL et écrit les charges lourdes comme les enregistrements de session et les événements heatmap bruts dans des fichiers JSON compressés en gzip sur disque. Sur un site avec environ 1 725 sessions par jour, la base de données a grossi d’environ 6,3 Mo par jour, soit environ 1,45 Ko par page vue. »}},{« @type »: »Question », »name »: »Quel espace disque Opti-Behavior utilise-t-il ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Sur un site en production avec 400 163 pages vues sur 90 jours et tous les modules activés, Opti-Behavior a utilisé 565 Mo de base de données et 1,52 Go de stockage fichiers, soit environ 2,07 Go au total, ou environ 14 Ko par session en incluant le replay complet. »}},{« @type »: »Question », »name »: »Où sont stockés les enregistrements de session Opti-Behavior ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Les enregistrements sont stockés sous forme de fichiers JSON compressés en gzip sous wp-content/uploads/opti-behavior-data, répartis par date et par heure, avec seulement une petite ligne de métadonnées conservée dans MySQL. Un enregistrement stocké pèse en moyenne environ 69 Ko. »}},{« @type »: »Question », »name »: »Qu’advient-il des anciennes données d’Opti-Behavior ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Les sessions de spam et de bots sont purgées quotidiennement. Les enregistrements et les fichiers heatmap bruts expirent après 90 jours par défaut et les données de session détaillées après 365 jours, tandis que les agrégats journaliers du dashboard sont conservés indéfiniment afin que les graphiques historiques continuent de fonctionner. »}},{« @type »: »Question », »name »: »Le nettoyage automatique d’Opti-Behavior peut-il supprimer des données que je voulais garder ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Non. Les passes de nettoyage automatisées s’interrompent et consignent un avertissement si une règle supprimerait plus de 50 pour cent de la table des sessions. Tant que ce disjoncteur est déclenché, seules les sessions spam de plus de 30 jours sont purgées dans la limite d’un plafond nocturne, donc la base de données ne peut toujours pas croître sans limite. Les nettoyages manuels depuis la Zone de danger ne sont pas bloqués car ils nécessitent une confirmation explicite. »}},{« @type »: »Question », »name »: »Le dashboard Opti-Behavior est-il lent avec de gros volumes de données ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Le dashboard fait passer les requêtes de widgets par une file à concurrence bornée plutôt que de les lancer simultanément, charge les sections repliées paresseusement, et partage les caches de requêtes amorcées entre widgets liés. Les pages heatmap chargent les fichiers d’événements compressés par petits lots progressifs qui cèdent la main au navigateur et se mettent en pause quand l’onglet est masqué. »}}]}
