Accept-Encoding: br, gzip : cet en-tête, envoyé par défaut par la plupart des navigateurs récents et par de nombreux clients HTTP côté serveur, signale que le format de compression Brotli est accepté en plus de gzip. Sur un front headless qui interroge en continu l’API REST de WordPress pour récupérer des articles au format JSON, ignorer ce support revient à laisser filer une bande passante compressible plus efficacement.
Brotli, normalisé par l’IETF et documenté par le Mozilla Developer Network, compresse généralement mieux les contenus textuels que gzip à niveau de compression comparable, un avantage particulièrement net sur du JSON répétitif comme celui que renvoie l’API REST de WordPress. Encore faut-il pouvoir l’activer précisément sur ces réponses, sans dépendre d’un accès root complet au serveur mutualisé.
Vérifier le support Brotli réellement disponible sur l’hébergement
Sur un mutualisé, la configuration Nginx ou Apache n’est en général pas modifiable directement : c’est le panneau d’hébergement ou un fichier .htaccess qui reste l’unique levier. La première étape consiste donc à vérifier si le module Brotli est déjà chargé côté serveur, via une requête simple :
curl -s -H "Accept-Encoding: br" -I https://exemple.fr/wp-json/wp/v2/postsSi l’en-tête de réponse Content-Encoding: br apparaît, le module est actif au niveau du serveur web et il ne reste qu’à s’assurer qu’il couvre bien le type MIME application/json. S’il est absent, l’activation dépendra des options exposées par l’hébergeur, ou d’une compression applicative directement dans PHP.
Restreindre la compression aux routes de l’API, pas à tout le site
Compresser systématiquement toutes les réponses en Brotli côté mutualisé peut consommer un temps CPU non négligeable, ressource justement la plus contrainte sur ce type d’offre. L’objectif ici n’est pas de tout compresser en Brotli, mais de cibler précisément les réponses JSON de l’API REST, déjà identifiées comme volumineuses et fréquemment interrogées par le front headless.
Quand le panneau d’hébergement expose un fichier de configuration Apache personnalisable, la restriction se fait par type de contenu et par chemin :
<IfModule mod_brotli.c>
<LocationMatch "^/wp-json/">
AddOutputFilterByType BROTLI_COMPRESS application/json
</LocationMatch>
</IfModule>Cette restriction évite de solliciter le processeur pour compresser des ressources qui bénéficient déjà d’un cache long, comme les images, tout en concentrant l’effort sur des réponses générées dynamiquement à chaque requête.
Compresser côté PHP quand le serveur ne le fait pas
Sur un mutualisé qui ne propose aucun module Brotli côté serveur, une compression applicative reste possible via l’extension PHP brotli, lorsqu’elle est disponible dans l’environnement d’exécution. Un filtre accroché au traitement de la réponse REST permet de compresser directement le corps JSON avant son envoi :
add_filter( 'rest_pre_serve_request', function( $served, $result, $request ) {
if ( ! function_exists( 'brotli_compress' ) ) {
return $served;
}
$accept = $request->get_header( 'accept_encoding' );
if ( strpos( (string) $accept, 'br' ) === false ) {
return $served;
}
$body = wp_json_encode( $result->get_data() );
header( 'Content-Encoding: br' );
echo brotli_compress( $body, 5 );
return true;
}, 10, 3 );Le niveau de compression 5, dans cet exemple, représente un compromis raisonnable entre le temps CPU consommé et le gain de taille obtenu, à ajuster selon la charge réelle observée sur le mutualisé.
Ce que révèlent les mesures sur nos réponses JSON
| Compression | Taille d’une réponse de 50 articles | Temps de traitement serveur |
|---|---|---|
| Aucune | 184 Ko | Référence |
| Gzip niveau 6 | 31 Ko | + 8 ms |
| Brotli niveau 5 | 25 Ko | + 11 ms |
Sur nos réponses JSON, ce test a montré un gain d’environ vingt pour cent en taille par rapport à gzip, pour un surcoût de traitement limité à quelques millisecondes supplémentaires, largement compensé par la réduction du temps de transfert sur les connexions mobiles du front headless.
Vérifier que le fallback vers gzip reste fonctionnel
Un client qui n’annonce pas le support Brotli dans son en-tête Accept-Encoding doit continuer à recevoir une réponse compressée en gzip, sans erreur ni réponse non compressée par défaut. Tester ce repli avec un client qui n’envoie que Accept-Encoding: gzip fait partie des vérifications à ne pas négliger avant mise en production, la compression des assets statiques du thème restant, elle, un sujet distinct déjà traité par ailleurs.
Compresser plus fort ne sert à rien si le client ne sait pas décompresser : vérifier l’en-tête envoyé compte autant que choisir l’algorithme.
Notre verdict
Sur un hébergement mutualisé, activer Brotli spécifiquement pour les réponses JSON de l’API REST apporte un gain mesurable sans bouleverser la configuration existante, à condition de cibler précisément les bonnes routes et de vérifier la présence réelle du module ou de l’extension PHP correspondante. Le gain de vingt pour cent constaté ici justifie largement les quelques lignes de configuration nécessaires.
