Douze appels à current_user_can() répartis dans un seul template d’archive : c’est ce qu’un audit a relevé sur un site associatif affichant des boutons d’action conditionnels (modifier, supprimer, épingler) selon le rôle du visiteur connecté. La question posée était simple : cette répétition d’appels a-t-elle un coût mesurable sur le temps de génération de la page ?
Plutôt que de répondre par intuition, une mesure directe avec un outil de profilage a permis de trancher, et le résultat surprend par sa modestie, tout en révélant un vrai point de vigilance ailleurs dans le code concerné.
Comment fonctionne réellement current_user_can
La fonction current_user_can() ne déclenche aucune requête à la base de données à chaque appel. Les capacités et rôles de l’utilisateur actuellement connecté sont chargés une seule fois en mémoire, lors de l’initialisation de l’objet WP_User correspondant, via la propriété allcaps qui agrège l’ensemble des capacités effectives de l’utilisateur. Chaque appel ultérieur à current_user_can() ne fait que consulter ce tableau déjà en mémoire, une opération de recherche extrêmement rapide en PHP.
// Ce que fait current_user_can en interne, simplifié
$user = wp_get_current_user();
$peut_modifier = isset( $user->allcaps['edit_posts'] ) && $user->allcaps['edit_posts'];
// Aucune requête SQL supplémentaire à ce stadeLa mesure effectuée
Sur le site audité, dix appels consécutifs à current_user_can( 'edit_posts' ) placés dans une boucle de test ont représenté un temps d’exécution cumulé de 0,3 milliseconde, une valeur négligeable au regard du temps de génération total de la page, qui dépassait 180 millisecondes. Ce résultat confirme que le coût direct de la vérification de capacités, même répétée plusieurs fois par page, ne constitue pas un facteur de ralentissement significatif pour un site WordPress typique.
Le vrai point de vigilance identifié dans l’audit
Le ralentissement réel provenait d’un tout autre endroit : chaque bouton conditionnel, avant même de vérifier la capacité de l’utilisateur, chargeait les métadonnées complètes de l’article concerné via get_post_meta( $post_id ) sans troisième paramètre, récupérant l’ensemble des métadonnées plutôt qu’une seule valeur ciblée. Ce chargement, répété pour chaque article affiché dans la boucle d’archive, représentait un coût bien plus significatif que la vérification de capacité elle-même, à laquelle il était associé dans le code sans lien de causalité réel.
La leçon à retenir : ce qui entoure une vérification de capacité coûte souvent bien plus cher que la vérification elle-même. Corriger le mauvais suspect ne change rien au temps de génération observé.
Quand la vérification de capacité peut réellement peser
- Sur un site multisite avec un grand nombre de rôles personnalisés et de capacités additionnelles, la construction initiale du tableau
allcapspeut devenir plus coûteuse, bien que ce coût reste ponctuel, au chargement de l’utilisateur, pas à chaque appel. - Un appel à
current_user_can()avec un identifiant de ressource spécifique (commecurrent_user_can( 'edit_post', $post_id )) déclenche en interne un chargement de l’objet article concerné si celui-ci n’est pas déjà en mémoire, ce qui peut ajouter un coût si l’article n’a pas encore été chargé par ailleurs. - Un plugin qui définit ses propres capacités via des filtres personnalisés sur
user_has_cappeut introduire une logique plus lourde à chaque vérification, selon la complexité de ce filtre.
Comment mesurer sur son propre site
Un profilage ciblé avec Query Monitor, en filtrant spécifiquement les appels à current_user_can() et leur temps cumulé, permet de vérifier objectivement si ce mécanisme représente un facteur de ralentissement réel sur un site donné, plutôt que de se fier à une intuition générale sur le coût supposé du système de capacités et rôles de WordPress.
En résumé
Le système de capacités et rôles de WordPress, conçu pour être consulté en mémoire plutôt que requêté à chaque appel, n’ajoute pas de coût mesurable significatif à la génération d’une page, même en cas d’appels répétés. Les vrais points de ralentissement se cachent presque toujours dans le code qui entoure ces vérifications, pas dans les vérifications elles-mêmes.
