Cabinet d’avocats : Server-Timing révèle une signature électronique lente

Server-Timing: db;dur=42, sig-check;dur=340, tpl;dur=18 — cet en-tête, ajouté manuellement pour le diagnostic, a immédiatement pointé vers un coupable inattendu sur le site d’un cabinet d’avocats spécialisé en droit des affaires.

Le site affichait un temps de génération global honorable en apparence, mais une sensation de lenteur persistante remontait des retours utilisateurs, sans qu’aucun outil de mesure globale ne parvienne à isoler précisément l’origine du ralentissement. C’est cette absence de piste claire qui a motivé l’ajout d’un découpage plus fin du temps serveur.

Mettre en place le découpage Server-Timing

L’en-tête HTTP Server-Timing permet d’exposer, depuis le serveur, des métriques nommées et chronométrées, directement visibles dans l’onglet réseau des outils de développement du navigateur. WordPress ne l’expose pas nativement de façon détaillée, mais il suffit de quelques points de mesure ajoutés au code pour obtenir un découpage exploitable.

<?php
$debut_sig = microtime( true );
// bloc de code du plugin de signature électronique
$duree_sig = ( microtime( true ) - $debut_sig ) * 1000;
header( sprintf( 'Server-Timing: sig-check;dur=%.1f', $duree_sig ), false );

Ce type d’instrumentation, posé temporairement autour des blocs suspects, a permis de chronométrer précisément chaque étape du rendu d’une page, sans dépendre d’un profileur complet installé en production.

La découverte : un plugin actif sur toutes les pages

Le point de mesure posé autour du plugin de signature électronique a révélé un temps d’exécution de 340 millisecondes en moyenne, un chiffre déjà élevé pour une opération censée n’intervenir que sur la page de signature d’un mandat. Le plus surprenant restait ailleurs : ce même temps de 340 millisecondes apparaissait sur toutes les pages du site, y compris la page d’accueil et les articles du blog du cabinet, sans lien avec la fonctionnalité de signature.

Le diagnostic du comportement

L’inspection du code du plugin a montré qu’il s’accrochait au hook init, exécuté sur chaque chargement de page côté front comme côté back-office, pour vérifier l’état de synchronisation avec le service de signature électronique. Cette vérification interrogeait une API distante à chaque requête, sans mise en cache d’aucune sorte, alors qu’elle n’était réellement utile que sur les pages contenant un document en attente de signature.

Ce genre de comportement n’est pas rare chez des extensions conçues pour un usage ponctuel mais intégrées sans discernement sur l’ensemble d’un site. Le développeur du plugin avait probablement raisonné en pensant à son propre cas d’usage, sans anticiper qu’il serait actif sur un site généraliste comprenant des dizaines de pages sans rapport avec la signature de documents.

Le correctif appliqué

Plutôt que de désactiver le plugin, ce qui aurait supprimé une fonctionnalité utilisée par les clients du cabinet, un filtre conditionnel a été ajouté pour ne déclencher la vérification que sur les templates concernés, identifiés par un champ personnalisé posé sur les pages de mandat.

• Vérification de synchronisation limitée aux pages marquées comme contenant un document à signer
• Résultat de la vérification mis en cache via un transient de cinq minutes sur ces pages précises
• Suppression complète de l’appel sur toutes les autres pages du site

Résultat après correctif

Le temps de génération moyen des pages sans lien avec la signature est retombé de 340 millisecondes à une valeur négligeable, confirmée par un nouveau relevé Server-Timing sur les mêmes pages. Le cabinet a conservé l’intégralité de la fonctionnalité de signature sur les pages qui en avaient réellement besoin.

Un plugin qui s’accroche à init sans condition mérite toujours une inspection, quelle que soit sa réputation. C’est le hook le plus large qui existe dans WordPress, et le moins souvent audité pour son coût réel page par page.

En résumé

L’en-tête Server-Timing offre un moyen simple et peu invasif d’isoler le coût réel d’un bloc de code précis, sans installer d’outil de profilage lourd en production. Dans ce cas, il a permis de découvrir qu’une fonctionnalité censée rester ponctuelle s’exécutait en réalité sur chaque page du site. Le correctif, une condition d’exécution basée sur le contexte réel de la page, a suffi à faire disparaître un ralentissement invisible aux outils de mesure globale du site.