Pendant des années, la règle a été gravée dans le marbre : concaténer tous les fichiers CSS en un seul, tous les fichiers JavaScript en un seul, pour limiter le nombre de requêtes HTTP. Puis HTTP/2 s’est généralisé, et la rumeur a circulé aussi vite que la règle précédente : « avec HTTP/2, il ne faut plus concaténer, ça ralentit même le site ». La réalité est plus nuancée que ces deux extrêmes, et elle mérite d’être comprise avant de changer la configuration d’un thème de production.
Ce que HTTP/1.1 imposait vraiment
Sous HTTP/1.1, un navigateur ouvre un nombre limité de connexions TCP simultanées par domaine, généralement six. Chaque requête supplémentaire attend qu’une connexion se libère. Avec une trentaine de fichiers CSS et JS sur une page WordPress chargée d’extensions, l’essentiel du temps de chargement partait dans cette file d’attente, pas dans le téléchargement lui-même. La concaténation réduisait mécaniquement ce goulot en divisant le nombre de requêtes par dix ou vingt.
Ce que change réellement le multiplexage de HTTP/2
HTTP/2 introduit le multiplexage : plusieurs requêtes et réponses circulent en parallèle sur une seule connexion TCP, sans attendre de libération de créneau. La file d’attente qui justifiait la concaténation disparaît largement. À cela s’ajoute la compression d’en-têtes HPACK, qui réduit le poids de chaque requête individuelle, un gain proportionnellement plus important quand les fichiers sont nombreux et petits.
Sur le papier, ces deux mécanismes suggèrent qu’il vaut mieux servir des fichiers séparés : chacun profite du cache HTTP indépendamment (modifier un seul fichier n’invalide pas tout le paquet), et le multiplexage absorbe le coût du nombre de requêtes.
Où la concaténation reste utile malgré tout
Le multiplexage supprime le coût d’ouverture de connexion, mais pas les autres coûts : chaque requête garde un minimum de traitement côté serveur, de compression, et surtout de priorisation. Sur une connexion mobile avec une latence élevée, un grand nombre de petites requêtes reste pénalisant, même en HTTP/2, car la latence aller-retour s’additionne pour les ressources qui dépendent les unes des autres (une feuille CSS qui importe une police, par exemple).
La concaténation garde donc un intérêt dans deux cas précis :
- Un très grand nombre de petits fichiers (plus d’une trentaine), où le coût de traitement individuel dépasse le gain du cache partiel.
- Un public majoritairement sur réseau mobile à latence élevée, où chaque aller-retour supplémentaire coûte cher.
Comment trancher pour votre propre site
Aucune règle générale ne remplace une mesure sur votre propre configuration. Vérifiez d’abord que HTTP/2 est bien actif :
curl -I --http2 https://exemple-client.test/ | head -n 1Une réponse commençant par HTTP/2 200 confirme le protocole. Ensuite, comparez deux configurations dans WebPageTest ou Lighthouse : assets concaténés contre assets séparés, sur une connexion 4G simulée. Regardez le Largest Contentful Paint plutôt que le nombre brut de requêtes, qui n’est plus un indicateur pertinent à lui seul depuis HTTP/2.
Le cas particulier des serveurs qui ne supportent pas encore le push HTTP/2
Le Server Push, qui permettait au serveur d’envoyer des ressources avant même que le navigateur ne les demande, a été retiré des principaux navigateurs faute d’adoption efficace. Ne construisez pas de stratégie autour de cette fonctionnalité : elle n’apporte plus de bénéfice fiable en 2020, quel que soit votre hébergeur.
Le protocole a changé les règles, mais il n’a pas rendu la mesure inutile : ce qui marchait sur un projet peut ralentir le suivant.
Pour aller plus loin
Retenez surtout ceci : HTTP/2 réduit fortement, mais n’élimine pas, l’intérêt de limiter le nombre de requêtes. La bonne approche pour un site WordPress moderne consiste à regrouper les assets par contexte d’usage plutôt qu’en un seul fichier global : un bundle pour les pages de blog, un autre pour les pages produit, plutôt qu’un unique fichier CSS chargé partout. Cette granularité intermédiaire tire parti du multiplexage tout en évitant l’explosion du nombre de petites requêtes.
