Pourquoi une page qui affiche le même menu toute la journée met-elle autant de temps à répondre à chaque rafraîchissement ? C’est la question qu’un restaurateur s’est posée en repérant, dans les outils de mesure de son navigateur, un temps de première octet dépassant régulièrement la seconde sur sa page « La carte du jour », pourtant l’une des plus visitées de son site de commande en ligne.
La réponse tenait en une ligne de code mal placée : la fonction qui construisait le menu du jour à partir de la base de données tournait à chaque chargement de page, y compris pour deux visiteurs consécutifs regardant strictement la même carte à trois secondes d’intervalle.
Le constat : une régénération systématique
Le thème du site interrogeait, à chaque affichage, une table de plats reliée à des relations de type post_meta pour construire la carte du jour : entrées, plats, desserts, allergènes, prix. Rien d’anormal en soi, sauf que cette requête composite s’exécutait pour chaque visiteur, chaque robot d’indexation et chaque rechargement, alors que le contenu ne changeait qu’une fois par jour, en général en fin de matinée quand le chef validait le menu.
Le reste de la page — panier, formulaire de commande, statut de livraison — devait rester entièrement dynamique. Impossible donc de mettre en cache la page entière sans casser ces fonctionnalités.
La solution : un cache de fragment ciblé
La bonne échelle n’était pas la page, mais le fragment. La fonction de construction de la carte a été enveloppée dans un test de get_transient(), avec une clé incluant la date du jour :
function restaurant_get_carte_du_jour() {
$cle = 'carte_du_jour_' . date( 'Y-m-d' );
$carte = get_transient( $cle );
if ( false === $carte ) {
$carte = restaurant_construire_carte(); // requêtes lourdes ici
set_transient( $cle, $carte, 12 * HOUR_IN_SECONDS );
}
return $carte;
}
Le transient expire naturellement au bout de douze heures, et la clé change automatiquement chaque jour : pas besoin de purge manuelle dans le cas courant. Pour les jours où le chef modifie la carte après publication, un bouton dans l’administration appelle simplement delete_transient( 'carte_du_jour_' . date( 'Y-m-d' ) ), régénérant le fragment au prochain visiteur.
Ce que le cache ne devait surtout pas figer
Le panier, le calcul des frais de livraison selon le code postal et le statut de la commande en cours restaient hors de ce cache : ils dépendent du visiteur et doivent rester recalculés à chaque requête. Seule la partie « lecture du menu » bénéficiait du fragment mis en cache, ce qui évitait tout risque d’afficher un panier ou une commande obsolète à quelqu’un d’autre.
- Fragment mis en cache : liste des plats, prix, descriptions, allergènes.
- Resté dynamique : panier, sélection de créneau de retrait, statut de commande.
- Purge automatique : changement de date, ou action manuelle du chef en cas de rupture de stock d’un plat.
Résultats mesurés
Sur trois semaines de suivi, le temps de première octet de la page carte est passé d’une fourchette de 850 à 1 400 millisecondes à une fourchette de 180 à 300 millisecondes pour les visites bénéficiant du fragment déjà en cache. Le gain moyen mesuré s’établit autour de 610 millisecondes, un chiffre cohérent avec le fait que la requête évitée représentait, à elle seule, la majeure partie du temps de génération de la page.
Un cache de fragment gagne à être découpé selon la fréquence réelle de changement du contenu, pas selon des habitudes copiées d’un autre projet.
Ce que cet article ne couvre pas
Le paiement en ligne, la gestion des créneaux de livraison saturés ou la synchronisation avec un système de caisse restent hors sujet ici : ce sont des chantiers à part entière, avec leurs propres contraintes de cohérence des données, qui ne se règlent pas avec un simple transient.
Notre verdict
Quand une partie d’une page change rarement mais qu’elle cohabite avec des éléments strictement dynamiques, le cache de page entier n’est pas la bonne échelle. Un fragment mis en cache avec get_transient() et une clé datée règle le problème proprement, sans complexifier l’infrastructure ni prendre le risque de servir un contenu périmé à qui que ce soit.
