# Combien de temps une page WordPress passe-t-elle réellement en attente de la base

> Un temps de génération se décompose en trois parts distinctes : attente réseau, exécution des requêtes, traitement PHP pur. Voici comment les séparer.

- Auteur : Clément Hadrot
- Publié le : 2025-12-29
- Mis à jour le : 2025-12-29
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/temps-generation-page-attente-base-de-donnees/

## L’essentiel

- Le temps de génération n'est pas un seul bloc homogène
- La latence réseau vers MySQL se mesure séparément de l'exécution
- Isoler chaque part change les priorités de correction

Un temps de génération de 320 millisecondes s'affiche dans un en-tête `Server-Timing`, ou dans l'onglet réseau du navigateur. Cette valeur unique cache pourtant trois réalités bien distinctes, chacune répondant à une cause différente et appelant une correction différente. Confondre ces trois parts conduit souvent à optimiser la mauvaise chose.

Ce billet propose de décomposer ce temps total en trois composantes mesurables séparément : le temps passé à attendre que le serveur de base de données réponde sur le réseau, le temps d'exécution proprement dit des requêtes SQL une fois reçues, et le temps de traitement PHP pur, celui qui ne dépend d'aucune base de données.

## Première part : la latence réseau vers MySQL

Lorsque WordPress et sa base de données ne partagent pas le même serveur physique, chaque requête effectuée via `$wpdb` traverse le réseau interne de l'hébergeur avant d'atteindre le moteur MySQL. Cette latence, souvent de l'ordre d'une à quelques millisecondes sur une infrastructure bien conçue, peut grimper significativement si le serveur de base de données est distant géographiquement ou surchargé. Elle se mesure en isolant une requête minimale, du type `SELECT 1`, chronométrée avec `hrtime()` juste avant et juste après son exécution :

```
$debut = hrtime( true );
$wpdb->get_var( 'SELECT 1' );
$latence_reseau = ( hrtime( true ) - $debut ) / 1e6; // en millisecondes
```

## Deuxième part : le temps d'exécution des requêtes

> L'essentiel à retenir : Le temps de génération n'est pas un seul bloc homogène ; La latence réseau vers MySQL se mesure séparément de l'exécution ; Isoler chaque part change les priorités de correction

Une fois la latence réseau connue, la différence entre le temps total rapporté par `$wpdb->queries` (lorsque `SAVEQUERIES` est activé) et cette latence de base donne une estimation du temps réellement passé par MySQL à exécuter la requête : recherche d'index, tri, jointures. C'est cette part qui bénéficie le plus d'un index bien choisi ou d'une requête réécrite. Un test comparatif mené sur une page d'archive de trois cents articles a donné les résultats suivants :

| Composante | Temps mesuré | Part du total |
| --- | --- | --- |
| Latence réseau cumulée (18 requêtes) | 36 ms | 11 % |
| Exécution SQL cumulée | 142 ms | 44 % |
| Traitement PHP pur | 142 ms | 45 % |

## Troisième part : le traitement PHP pur

Ce qui reste, une fois soustraites les deux premières parts du temps de génération total, correspond au traitement effectué par PHP sans aucun échange avec la base de données : rendu des blocs, application des filtres et des actions, formatage des dates, échappement des sorties, exécution du thème lui-même. Sur l'exemple ci-dessus, cette part représentait presque la moitié du temps total, une proportion souvent sous-estimée par des équipes qui concentrent leurs efforts d'optimisation sur les seules requêtes SQL.

## Pourquoi cette décomposition change les priorités

Sur ce site précis, l'équipe technique avait initialement prévu d'ajouter un cache d'objets persistant pour réduire le temps SQL, en supposant que la base de données était le principal responsable de la lenteur. La décomposition a montré que le traitement PHP pur pesait autant que les requêtes elles-mêmes : une partie de cet effort venait de plusieurs filtres `the_content` appliqués séquentiellement par différentes extensions, chacune ajoutant son propre traitement du texte affiché.

## Comment reproduire cette mesure sur un site

- Activer temporairement la constante `SAVEQUERIES` dans `wp-config.php`, uniquement sur un environnement de test, jamais en production où elle ajoute elle-même un coût.
- Mesurer une requête minimale de type `SELECT 1` pour établir la latence réseau de référence.
- Comparer le temps de génération total, rapporté par un en-tête `Server-Timing` personnalisé, avec la somme des deux premières parts pour en déduire le temps PHP pur par soustraction.

> Un temps de génération n'est jamais un bloc unique : le décomposer révèle souvent que la moitié du problème ne se trouve pas là où on la cherchait en premier.

## En résumé

Séparer la latence réseau, le temps d'exécution SQL et le traitement PHP pur transforme un chiffre global, difficile à interpréter, en trois pistes de correction distinctes. Sur ce site associatif, cette décomposition a réorienté l'effort d'optimisation vers les filtres de contenu plutôt que vers un cache d'objets qui n'aurait résolu qu'une partie du problème.