Comparons deux façons de résoudre le même problème : servir une image plus légère à un mobile qu’à un grand écran. La première, largement répandue, s’appuie sur l’attribut srcset et laisse le navigateur choisir parmi plusieurs variantes déjà générées. La seconde, moins connue, laisse le serveur décider directement, avant même de générer la réponse, grâce à une information que le navigateur lui transmet volontairement dans ses en-têtes de requête : les Client Hints.
Ce que déclare Accept-CH et comment l’activer
Par défaut, un navigateur n’envoie aucune information sur la largeur de son viewport ou la densité de ses pixels dans une requête HTTP classique, pour des raisons de préservation de la vie privée : moins d’information transmise par défaut réduit les possibilités de suivi passif. Pour qu’un navigateur commence à transmettre ces informations, le serveur doit explicitement les demander via l’en-tête de réponse Accept-CH, qui liste les hints souhaités :
add_action( 'send_headers', function () {
header( 'Accept-CH: Width, DPR' );
} );
Une fois cette déclaration reçue, le navigateur commence à inclure les en-têtes correspondants (Width, DPR) dans ses requêtes suivantes vers ce même serveur. Le point souvent mal compris : cette déclaration doit être renvoyée régulièrement, à chaque réponse pertinente, pour rester active ; elle ne s’enregistre pas de façon permanente comme le ferait un cookie. Si le serveur cesse de la renvoyer, le navigateur cesse progressivement de transmettre les hints correspondants.
Le hint Width indique la largeur en pixels CSS à laquelle une ressource va être affichée, ce qui suppose que le navigateur la connaît à l’avance, typiquement via l’attribut sizes d’une balise image. Le hint DPR (Device Pixel Ratio) indique le rapport entre pixels physiques et pixels CSS de l’appareil, utile pour distinguer un écran standard d’un écran à haute densité.
Adapter une réponse WordPress à partir de ces hints
Une fois les hints reçus dans la requête, un point d’entrée qui sert des images (une route personnalisée, ou un gestionnaire attaché à une extension existante) peut lire ces en-têtes pour choisir la variante appropriée, sans qu’aucun script JavaScript n’ait eu besoin d’intervenir côté client pour transmettre cette information :
$largeur_demandee = isset( $_SERVER['HTTP_WIDTH'] ) ? (int) $_SERVER['HTTP_WIDTH'] : null;
$densite = isset( $_SERVER['HTTP_DPR'] ) ? (float) $_SERVER['HTTP_DPR'] : 1.0;
if ( $largeur_demandee ) {
$largeur_cible = (int) round( $largeur_demandee * $densite );
// sélection de la taille d'image WordPress la plus proche de $largeur_cible
}
Cette approche a un intérêt particulier pour un site qui sert des images depuis un point d’entrée dynamique plutôt que des fichiers statiques déjà redimensionnés à la publication, par exemple un service de redimensionnement à la volée. Elle permet de générer directement la taille pertinente plutôt que de compter sur le navigateur pour choisir parmi une liste de variantes déjà toutes générées et potentiellement déjà toutes transférées côté serveur d’origine vers le CDN.
Le piège du cache partagé mal déclaré
Cette adaptation côté serveur introduit un risque spécifique : si une réponse varie selon les hints reçus, mais qu’un cache partagé en amont (un CDN, un cache de page) ne le sait pas, il risque de mettre en cache la première réponse générée et de la resservir ensuite à des visiteurs dont les caractéristiques d’écran diffèrent totalement. Un visiteur sur grand écran pourrait ainsi recevoir l’image pensée pour un mobile, simplement parce qu’un mobile a visité la page en premier et que sa réponse a été mise en cache sans distinction.
La correction consiste à déclarer un en-tête Vary qui inclut les hints utilisés dans la décision :
header( 'Vary: Width, DPR' );
Ce réglage a toutefois un coût réel : chaque combinaison distincte de largeur et de densité observée génère potentiellement sa propre entrée de cache, ce qui peut fragmenter fortement l’efficacité d’un cache partagé si les valeurs de Width varient trop finement d’un visiteur à l’autre. Une pratique courante consiste à arrondir la largeur reçue à un nombre limité de paliers avant de l’utiliser pour la sélection, plutôt que de traiter chaque valeur exacte comme une variante distincte.
- Renvoyer Accept-CH à chaque réponse pertinente, la déclaration ne persiste pas indéfiniment côté navigateur
- Toujours associer un en-tête Vary aux hints effectivement utilisés dans la logique de sélection
- Arrondir les largeurs reçues à quelques paliers pour limiter la fragmentation d’un cache partagé
- Prévoir un comportement par défaut cohérent quand les hints sont absents, ce qui reste le cas de nombreux navigateurs
Un Client Hint mal accompagné d’un Vary ne casse rien visiblement pour le premier visiteur, il casse l’expérience du second, servi depuis un cache qui n’a pas su faire la différence.
Une alternative complémentaire, pas un remplacement
Les Client Hints ne remplacent pas srcset et sizes, ils offrent une voie alternative pour les cas où l’adaptation doit se décider avant même la génération de la réponse, côté serveur, plutôt qu’après coup côté client par sélection parmi des variantes déjà toutes disponibles. Le support de ces hints reste par ailleurs inégal selon les navigateurs, ce qui impose de conserver un comportement de repli raisonnable pour les requêtes qui n’en transmettent aucun.
