Server-Timing: db-query;dur=780.4, tpl-render;dur=42.1 : cette ligne, visible dans l’onglet réseau des outils de développement, a suffi à localiser le goulet d’étranglement d’un moteur de recherche d’offres d’emploi géré par une agence de recrutement, sans avoir besoin d’installer le moindre profileur externe.
La page de résultats, censée filtrer plusieurs centaines d’offres selon la localisation, le secteur d’activité et le type de contrat, mettait parfois plus d’une seconde à répondre lors des recherches combinant plusieurs critères. Un délai suffisant pour dissuader un visiteur pressé de creuser davantage.
Exposer le temps de génération sans outil tiers
Plutôt que d’installer immédiatement un profileur complet, l’équipe a choisi d’exposer directement les temps de traitement clés via l’en-tête HTTP Server-Timing, standard reconnu et directement lisible dans l’onglet réseau de n’importe quel navigateur moderne, sans extension supplémentaire :
add_action( 'template_redirect', function () {
$debut = microtime( true );
add_action( 'wp_footer', function () use ( $debut ) {
$duree = ( microtime( true ) - $debut ) * 1000;
header( sprintf( 'Server-Timing: page-totale;dur=%.1f', $duree ) );
}, 0 );
} );Cette instrumentation minimale a rapidement montré que l’essentiel du temps de réponse se concentrait dans une seule requête, la recherche d’offres elle-même, et non dans le rendu du gabarit ni dans les scripts tiers.
Le diagnostic derrière la requête fautive
En isolant précisément cette requête avec une mesure supplémentaire autour de l’appel à WP_Query, la cause est apparue : la recherche combinait un tax_query sur deux taxonomies (secteur et type de contrat) avec un meta_query sur un champ de localisation stocké en postmeta, sans index dédié pour cette combinaison.
MySQL devait donc croiser des jointures de taxonomie avec un filtrage sur une table de métadonnées non indexée pour ce cas d’usage précis, ce qui explique le temps de réponse dégradé dès que plusieurs filtres étaient combinés simultanément.
Le correctif appliqué
La solution a consisté à sortir la localisation du système générique de métadonnées pour la stocker dans une taxonomie dédiée, bien plus adaptée à ce type de filtrage combiné que le postmeta :
- Création d’une taxonomie
localisation_offreavec un terme par zone géographique - Migration ponctuelle des valeurs existantes via un script WP-CLI personnalisé
- Remplacement du
meta_querypar untax_querysupplémentaire, cohérent avec les deux premiers
Après ce changement, la mesure exposée par Server-Timing est passée de 780 millisecondes à 95 millisecondes pour la même recherche combinée, sans qu’aucun outil de profilage tiers n’ait été nécessaire pour identifier ni valider le correctif.
Pourquoi cette approche plutôt qu’un profileur classique
Un profileur complet reste indispensable pour des diagnostics larges et exploratoires. Mais pour une hypothèse précise et localisée — une seule page, un seul comportement suspect — exposer directement les temps de traitement via Server-Timing évite d’installer un outil supplémentaire sur un environnement de production sensible, tout en restant lisible par n’importe quel développeur ouvrant simplement l’onglet réseau.
Le meilleur outil de diagnostic reste souvent celui qu’on n’a pas besoin d’installer.
En résumé
Un moteur de recherche d’offres perçu comme lent cachait une combinaison de filtres mal indexée, révélée en quelques minutes grâce à l’en-tête Server-Timing plutôt qu’à un outil de profilage lourd. Ce billet ne traite pas du référencement des pages d’offres d’emploi, sujet à part entière qui dépasse la seule question de la vitesse de réponse.
