On a multiplié par 5 la vitesse de son module de réservation

Dans un parc indoor, le planning n’est pas un écran secondaire.
C’est l’outil central des agents d’accueil : afficher les créneaux, créer une réservation, modifier une activité, ajuster un nombre de participants, vérifier un statut. Toute la journée. Sans interruption.  Ce module s’utilise en ligne et sert autant à l’opérateur qu’au client final qui obtient l’information utile au bon moment. 

Pour notre client, FullInPark, cet outil fonctionnait correctement… jusqu’à ce que l’activité monte. Plus la journée avançait, plus l’affichage du planning devenait lent. Progressivement et de manière prévisible. Et surtout, pénalisante pour les équipes sur le terrain.

La mission des experts TYTAE a été simple : identifier l’origine réelle de ces lenteurs, vérifier qu’elles ne venaient pas de l’infrastructure, puis optimiser le module sans remettre en cause sa logique métier.
Un travail qui relève davantage du développement WordPress sur-mesure que d’un simple réglage de performance. L’objectif : apporter une solution adaptée au besoin opérationnel, sans ajouter de plugin superflu. 

Une lenteur du module directement ressentie par les équipes d’accueil

Le problème n’était pas théorique.
Il était vécu.

Les agents d’accueil se retrouvaient face à :

• un planning long à s’afficher,
• des clics qui répondaient avec un délai perceptible,
• des fenêtres de détail (popups) qui tardaient à s’ouvrir alors qu’elles servent à créer ou modifier les réservations.

Et plus le planning se remplissait, plus ces délais augmentaient. Ce point est important : la lenteur n’était pas constante, elle était corrélée au volume de réservations de la journée. Cela compliquait la gestion quotidienne et l’accès à l’information en temps réel. 

Dans un contexte opérationnel, ce type de dégradation a un impact direct : perte de fluidité à l’accueil, tension dans les périodes de rush, risque d’erreurs humaines.
À terme, c’est exactement le genre de situation qui finit par nécessiter une maintenance de site WordPress corrective, parfois en urgence. Un service réactif et disponible devient alors décisif. 

Notre stratégie pour un module de réservation plus rapide

Première étape : écarter un problème d’infrastructure

Avant d’ouvrir le code, nous avons vérifié l’évidence : serveur, base de données, charge globale, latence réseau.

Résultat : rien d’anormal.
Pas de saturation CPU persistante.
Pas de goulet d’étranglement côté hébergement.

La lenteur apparaissait uniquement sur cette page de planning, et uniquement lorsque le volume de données augmentait. Autrement dit : ce n’était pas un problème de performance globale, mais un problème de complexité interne au module.

Ce point est essentiel : beaucoup de projets assimilent encore ce type de lenteur à un site “en panne” ou “inaccessible”, alors que le problème se situe ailleurs, contrairement à des cas de site piraté ou inaccessible, par exemple. Ici, la fonctionnalité de planning devait être rendue plus efficace sans changer de version majeure. 

L’origine réelle : des calculs répétés à chaque créneau

En analysant le fonctionnement du planning, un schéma classique est apparu.

La journée est découpée en créneaux de 30 minutes.
Pour chacun de ces créneaux, le module recalculait :

• les totaux de participants,
• les données “réelles” issues de l’historique,
• les warnings (retards, non-arrivés),
• les comptages par activité,
• et relançait des lectures de métadonnées WordPress.

Ces calculs étaient effectués dans des boucles, avec des requêtes SQL répétées et des appels successifs à get_post_meta().

Sur le principe, tout était cohérent.
Sur le plan algorithmique, beaucoup moins.

Chaque créneau relisait l’ensemble des réservations de la journée.
Ce qui revenait à multiplier silencieusement le coût à mesure que le planning se remplissait.

C’est ce type de logique qui fonctionne très bien avec peu de données… puis se dégrade mécaniquement avec la charge. Pour un tel parc indoor avec location d’espaces et multiples activités, l’efficacité d’affichage doit rester disponible en continu. 

Mesurer précisément avant d’optimiser

Avant toute modification, nous avons instrumenté le code.

Des timers basés sur microtime(true) ont été ajoutés autour des sections clés, avec un affichage sous forme de commentaires HTML. L’objectif était clair : identifier précisément où le temps était consommé.

Cela a permis de confirmer plusieurs points :

• les accès SQL dans les boucles étaient coûteux,
• la lecture des métadonnées en cascade représentait une part significative du temps,
• la génération des popups faisait exploser le temps de rendu.

Avec ces mesures, l’optimisation pouvait être ciblée, et non empirique. 

Changer la logique : pré-calculer, puis afficher

L’amélioration des performances ne s’est pas faite par micro-optimisation, mais par changement de structure.

1. Charger les données une seule fois

Les métadonnées des réservations étaient lues individuellement.
Nous avons basculé sur un préchargement en masse via le cache natif WordPress (update_meta_cache()), supprimant des dizaines d’accès SQL indirects.

Même logique pour les blocages (anniversaires, kids) : ils sont désormais chargés en début de traitement, en deux requêtes globales, puis utilisés en mémoire.

2. Isoler les calculs lourds

Les calculs suivants ont été extraits dans des fonctions de pré-calcul :

• totaux “réel” (historique),
• totaux par créneau,
• warnings,
• comptages par activité.

Chaque réservation n’est parcourue qu’une seule fois, et les résultats sont stockés dans des tableaux indexés par créneau.
Les templates d’affichage ne font plus aucun calcul lourd : ils lisent simplement des données déjà préparées.

La complexité est ainsi passée de O(n × m) à O(n + m).

3. Clarifier le rôle des popups

Les popups ne sont pas décoratives.
Ce sont les interfaces utilisées par les opérateurs pour créer et modifier les réservations.

Initialement, elles étaient générées dynamiquement à chaque affichage, ce qui impliquait :

• de nouveaux filtrages,
• des lectures de métadonnées,
• parfois des requêtes SQL supplémentaires.

Nous avons donc choisi de les pré-générer :

• regroupement par créneau, section et activité,
• cache des métadonnées,
• transmission des blocages préchargés,
• génération HTML unique, stockée et réutilisée.

Résultat : l’ouverture d’une popup ne déclenche plus de calcul lourd. La fonctionnalité reste disponible instantanément pour l’agent et le client au comptoir. 

Les résultats observés

Les gains sont mesurables et cohérents :

• Requêtes SQL : ~100–200 → ~5
• Temps de traitement global : divisé par 5
• Temps observé sur une journée chargée : environ 300–350 ms
• Performances stables, quel que soit le remplissage de la journée

Mais surtout, le comportement ne se dégrade plus avec le volume. Le planning reste fluide du matin à la fermeture. Le module est désormais un produit robuste et complet.

L’impact côté usage du module de réservation

Pour les équipes d’accueil :

• un planning réactif,
• des actions immédiates,
• moins de friction dans les périodes de forte affluence.

Pour la plateforme :

• une charge serveur maîtrisée,
• un code plus lisible,
• une base saine pour les évolutions futures, facilitant l’accompagnement à la création de site internet et les évolutions fonctionnelles.

Ce cas n’illustre pas une astuce magique, mais un principe simple :
quand un module métier devient lent, ce n’est pas toujours l’infrastructure qui est en cause, mais la façon dont les données sont parcourues et recalculées.

Mesurer, comprendre, pré-calculer et séparer les responsabilités reste l’approche la plus fiable pour faire évoluer un outil WordPress à usage intensif.

Si votre module commence à ralentir à mesure que l’activité augmente, une optimisation ciblée peut suffire à lui redonner de la marge, sans tout réécrire, et souvent bien avant d’envisager un changement de stack ou une hausse des prix de maintenance de site internet.

TYTAE peut vous accompagner, du diagnostic au plan d’action, jusqu’à la mise en production complete lors d’un rendez-vous dédié pour qualifier votre besoin et choisir la meilleure solution.