vendredi 25 septembre 2026

À propos

Contact

Performance

L’en-tête Server-Timing : exposer les temps de génération de WordPress

Combien de temps passe WordPress dans la base, dans les hooks, dans le rendu ? L'en-tête Server-Timing répond directement dans l'onglet Réseau de DevTools.

Par Clément Hadrot • 17 avril 2023 • 4 min de lecture • Aucun commentaire
L'en-tête Server-Timing : exposer les temps de génération de WordPress

Un client se plaignait d’un site « globalement lent » sans qu’on sache où chercher. Les outils habituels — Query Monitor, WebPageTest — donnaient des indices, mais pas de vision synthétique directement visible pour l’équipe côté client, moins technique. La solution la plus simple a été d’ajouter un en-tête HTTP standard, Server-Timing, qui affiche des durées directement dans l’onglet Réseau de n’importe quel navigateur.

L’avantage de cette approche est sa légèreté : pas besoin d’installer un profileur lourd ni de configurer Xdebug pour obtenir une première photographie. Voici comment mettre en place ces mesures, avec le module Performance Lab de WordPress ou avec quelques lignes de code maison.

Ce qu’est Server-Timing et comment le lire

Server-Timing est un en-tête HTTP standardisé par le W3C qui permet à un serveur de communiquer des durées de traitement au navigateur. Concrètement, la réponse contient une ligne du type :

Server-Timing: db;dur=142.3, hooks;dur=38.7, render;dur=61.2

Dans Chrome ou Firefox, l’onglet Réseau affiche ces métriques dans le panneau « Timing » de chaque requête, avec le nom de la métrique et sa durée en millisecondes. Aucune extension n’est nécessaire côté navigateur : c’est un standard supporté nativement.

Activer les mesures avec Performance Lab

L'essentiel à retenir : Server-Timing s'affiche nativement dans l'onglet Réseau sans extension ; Le module Performance Lab l'active en quelques clics sur un site de test ; Un mini plugin maison permet de mesurer des blocs de code précis

Performance Lab est le plugin officiel de test des futures fonctionnalités du cœur de WordPress, maintenu par l’équipe Core Performance. Il embarque un module server-timing qui instrumente automatiquement plusieurs points clés du chargement : le bootstrap de WordPress, les requêtes à la base de données via $wpdb, et le temps passé dans les hooks les plus coûteux.

Une fois le plugin installé et le module activé dans les réglages, chaque page générée expose un en-tête Server-Timing détaillé. C’est particulièrement utile pour comparer rapidement l’effet d’un changement (désactivation d’une extension, changement de thème) sans avoir à relancer un audit complet.

Il est recommandé de réserver ce module aux environnements de recadrage ou de préproduction, ou de le limiter aux utilisateurs administrateurs en production, car exposer des détails d’implémentation à tous les visiteurs n’est pas souhaitable pour la sécurité.

Ajouter ses propres mesures avec du code maison

Pour des mesures ciblées sur une fonctionnalité spécifique — par exemple le temps passé à générer un widget de recommandations personnalisées — un petit plugin suffit. L’idée est de chronométrer un bloc précis et d’ajouter la mesure à l’en-tête via le hook wp_headers ou directement avant l’envoi des en-têtes.

<?php
add_action( 'init', function() {
    $GLOBALS['wpm_timing_start'] = microtime( true );
} );

add_action( 'wp_head', function() {
    $duration = ( microtime( true ) - $GLOBALS['wpm_timing_start'] ) * 1000;
    header( sprintf( 'Server-Timing: front-render;dur=%.1f', $duration ), false );
} );

Ce type de mesure isolée est utile pour vérifier l’effet d’une optimisation ciblée, par exemple après avoir remplacé une boucle WP_Query imbriquée par une requête unique avec tax_query.

Interpréter les résultats sans se tromper

Une erreur fréquente est de comparer des mesures prises à des moments différents, sur des pages différentes, ou après une purge de cache d’un côté et pas de l’autre. Pour une comparaison fiable, il faut :

  • Toujours désactiver le cache de page pendant la mesure, sous peine de comparer une génération complète à une réponse déjà en cache.
  • Répéter chaque mesure trois à cinq fois et regarder la médiane plutôt qu’une seule valeur, car la première requête après un redémarrage PHP-FPM est souvent plus lente.
  • Isoler la base de données du reste : une durée « db » élevée oriente vers une requête ou un index à revoir, une durée « hooks » élevée oriente vers une extension à auditer.

Pour aller plus loin

Server-Timing ne remplace pas un profileur complet comme Blackfire ou Tideways lorsqu’il faut descendre jusqu’à la fonction PHP précise responsable d’un ralentissement. Mais pour une première triangulation rapide, directement visible par toute personne sachant ouvrir l’onglet Réseau d’un navigateur, c’est un outil remarquablement peu coûteux à mettre en place. Sur nos projets, il sert désormais de premier réflexe avant de sortir l’artillerie lourde du profilage.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi