Un temps de réponse perçu par le visiteur et un temps d’exécution réel du script PHP ne sont pas forcément la même chose. WordPress dispose d’un mécanisme simple, souvent sous-exploité, pour distinguer les deux : le hook shutdown, couplé à la fonction fastcgi_finish_request() quand l’environnement PHP-FPM le permet.
Voici comment déplacer un traitement secondaire — journalisation détaillée, appel de webhook non critique, mise à jour de statistiques internes — après l’envoi de la réponse HTML au navigateur, sans toucher à la logique métier existante.
Étape 1 : identifier ce qui peut être différé
Un traitement est éligible au report s’il ne modifie rien de ce que le visiteur voit à l’écran et si son échec éventuel ne doit pas empêcher l’affichage de la page. Concrètement : l’enregistrement d’une entrée de log applicatif, l’envoi d’un événement à un outil de suivi interne, la mise à jour d’un compteur de vues, ou la purge d’un cache secondaire déclenchée par la visite elle-même.
À l’inverse, tout ce qui doit apparaître dans la réponse HTML — le contenu de la page, les en-têtes HTTP, une redirection — reste hors du périmètre de cette technique, puisque le hook shutdown s’exécute justement après que cette réponse a été construite.
Étape 2 : accrocher le traitement au hook shutdown
add_action( 'shutdown', function () {
// Traitement qui n'a pas besoin d'être visible immédiatement
error_log( sprintf(
'[stats-internes] Page %s vue à %s',
esc_url_raw( $_SERVER['REQUEST_URI'] ?? '' ),
current_time( 'mysql' )
) );
} );Le hook shutdown se déclenche à la toute fin de l’exécution du script PHP, qu’il se termine normalement, par un appel à exit, ou même après une erreur fatale. C’est l’un des rares points d’accroche garantis de s’exécuter presque systématiquement, ce qui en fait un bon candidat pour du nettoyage ou de la journalisation de dernier recours.
Étape 3 : envoyer la réponse avant de continuer
Sur une configuration PHP-FPM classique, la fonction fastcgi_finish_request() permet de clore explicitement la connexion avec le serveur web et d’envoyer la réponse au visiteur, tout en laissant le script PHP continuer à s’exécuter en arrière-plan côté serveur :
add_action( 'shutdown', function () {
if ( function_exists( 'fastcgi_finish_request' ) ) {
fastcgi_finish_request();
}
// À partir d'ici, le visiteur a déjà reçu sa page.
envoyer_notification_interne_non_critique();
mettre_a_jour_compteur_vues_secondaire();
} );Le visiteur voit sa page s’afficher dès la fin de fastcgi_finish_request(), sans attendre l’exécution des instructions suivantes. Le processus PHP-FPM, lui, reste occupé quelques dizaines ou centaines de millisecondes supplémentaires pour terminer le travail différé, ce qui reste transparent pour l’expérience de navigation.
Étape 4 : mesurer l’effet réel
La bonne façon de vérifier le gain consiste à comparer, via l’en-tête Server-Timing ou un outil de mesure côté navigateur, le moment où le premier octet de contenu arrive (TTFB) avant et après la mise en place du report. Le temps total du script PHP côté serveur ne diminue pas : c’est la partie perçue par le visiteur qui se raccourcit, puisque la connexion HTTP se termine plus tôt.
- Vérifiez que votre environnement d’hébergement tourne bien en PHP-FPM ; sur certaines configurations mod_php ou CGI classique,
fastcgi_finish_request()n’existe pas et l’appel est ignoré silencieusement. - Évitez d’y placer un traitement qui dépend d’une session utilisateur encore active : selon la configuration, les données de session peuvent déjà être verrouillées ou libérées.
- Gardez le traitement différé court : un serveur qui accumule des scripts PHP encore actifs en arrière-plan peut saturer le pool PHP-FPM sous forte charge.
Étape 5 : prévoir l’échec silencieux
Puisque ce code s’exécute après l’envoi de la réponse, aucune erreur qui s’y produit ne remonte au visiteur ni à un éventuel affichage de débogage classique. Il est donc indispensable d’entourer ce traitement d’une capture d’exception explicite et de le journaliser correctement, sous peine de perdre silencieusement des événements sans jamais s’en rendre compte.
En résumé
Le hook shutdown associé à fastcgi_finish_request() offre un moyen simple d’améliorer le temps de réponse perçu sans toucher à la logique métier principale. Il ne remplace pas une vraie file de tâches asynchrones pour des traitements longs ou critiques, mais convient parfaitement à des opérations secondaires, courtes, et dont l’échec éventuel n’a aucune conséquence visible pour le visiteur.
