# Une agence de recrutement : Server-Timing dévoile un moteur d’offres lent

> Un moteur de recherche d'offres d'emploi soupçonné de lenteur a été diagnostiqué grâce à l'en-tête Server-Timing, sans recourir à un outil de profilage externe.

- Auteur : Clément Hadrot
- Publié le : 2025-07-04
- Mis à jour le : 2025-07-04
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/agence-recrutement-server-timing-moteur-offres-lent/

## L’essentiel

- L'en-tête Server-Timing expose des mesures de temps directement dans les outils du navigateur
- Un tag_query combiné à un meta_query multiplie le coût d'une recherche d'offres
- Isoler chaque étape du rendu évite d'installer un profileur complet pour un diagnostic ponctuel

`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.

> L'essentiel à retenir : L'en-tête Server-Timing expose des mesures de temps directement dans les outils du navigateur ; Un tag_query combiné à un meta_query multiplie le coût d'une recherche d'offres ; Isoler chaque étape du rendu évite d'installer un profileur complet pour un diagnostic ponctuel

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_offre` avec un terme par zone géographique
- Migration ponctuelle des valeurs existantes via un script WP-CLI personnalisé
- Remplacement du `meta_query` par un `tax_query` supplé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.