Une page web moderne charge rarement une seule ressource : feuilles de style, scripts, polices, images, widgets tiers (réseaux sociaux, chat en ligne, outils d'analyse) s'accumulent, chacun déclenchant sa propre requête HTTP. Même si les protocoles récents ont beaucoup atténué le problème, réduire ce nombre de requêtes reste une optimisation qui compte.
Le coût fixe de chaque requête
Chaque requête HTTP comporte un coût de latence qui lui est propre, indépendant de la taille du fichier demandé : résolution DNS si le domaine n'a pas déjà été résolu, établissement de la connexion, puis attente de la réponse du serveur. Pour un petit fichier (une icône de quelques kilooctets par exemple), ce coût fixe peut représenter une part disproportionnée du temps total par rapport au poids réel transféré.
Ce que HTTP/2 a changé, et ce qu'il n'a pas changé
Avec HTTP/2, plusieurs requêtes vers un même domaine peuvent circuler simultanément sur une seule connexion (le multiplexage), ce qui a nettement réduit l'intérêt de certaines pratiques historiques comme la concaténation systématique de tous les fichiers CSS ou JavaScript en un seul gros fichier. Mais ce multiplexage ne s'applique qu'au sein d'une même connexion vers un même domaine : chaque domaine distinct sollicité par la page (polices externes, widget de réseau social, script d'un outil d'analyse tiers, publicité) nécessite sa propre connexion séparée, avec son propre coût de résolution DNS et de poignée de main. C'est là que le nombre de domaines tiers sollicités reste un facteur de ralentissement bien réel, même avec les protocoles les plus récents.
Où se cachent les requêtes superflues
- Les scripts tiers accumulés sans revue régulière : outils d'analyse multiples, widgets de chat, boutons de partage social, pixels publicitaires — chacun ajoute non seulement son propre poids, mais souvent ses propres requêtes additionnelles en cascade.
- Les icônes individuelles : remplacer une série de petites images séparées par une seule police d'icônes ou un fichier SVG en sprite réduit le nombre de requêtes correspondantes à une seule.
- Les ressources non utilisées réellement sur la page : un thème ou un constructeur de page qui charge systématiquement l'ensemble de ses scripts et styles, même pour des fonctionnalités absentes de la page consultée.
Comment auditer concrètement sa page
L'onglet réseau des outils de développement du navigateur affiche la liste complète des requêtes déclenchées par une page, avec leur domaine d'origine et leur temps de réponse individuel. Un nombre élevé de domaines tiers distincts, visible dans cette liste, est un signal clair d'optimisation possible, souvent plus impactant que la simple réduction du nombre de fichiers internes au site lui-même.
Préconnecter plutôt que subir le coût d'un domaine externe
Quand un domaine tiers reste nécessaire (police auto-hébergée ailleurs, service d'analyse, CDN), deux indices HTML atténuent une partie du coût de latence sans supprimer la requête elle-même :
- La directive dns-prefetch, ajoutée dans l'en-tête de la page pour un domaine donné, indique au navigateur de résoudre ce nom de domaine en avance, avant même qu'une ressource de ce domaine ne soit explicitement demandée.
- La directive preconnect va plus loin en établissant à l'avance la connexion complète (DNS, TCP, TLS) vers ce domaine, prête à être utilisée dès que la première ressource qui en dépend sera réellement sollicitée par la page.
Utilisées avec parcimonie, pour les deux ou trois domaines tiers réellement critiques d'une page, ces indices réduisent le temps perdu sur l'établissement de connexion, sans pour autant remplacer le travail de fond consistant à réduire le nombre de domaines externes sollicités. Un excès de ces directives, appliqué à des dizaines de domaines à la fois, peut même devenir contre-productif en saturant la bande passante disponible avec des connexions ouvertes pour rien.
Faut-il encore concaténer ses fichiers CSS et JavaScript avec HTTP/2 ?
Moins systématiquement qu'à l'époque de HTTP/1.1, puisque le multiplexage réduit le coût de requêtes multiples vers un même domaine. Regrouper reste toutefois pertinent pour réduire le poids global des en-têtes répétés et simplifier la gestion du cache.
Les widgets tiers sont-ils le problème principal aujourd'hui ?
Dans beaucoup de cas, oui : chaque widget externe (chat, réseaux sociaux, publicité) ajoute une connexion vers un domaine distinct, souvent accompagnée de ses propres scripts et requêtes en cascade, ce qui en fait fréquemment la première source de requêtes superflues sur un site par ailleurs bien optimisé.
Un audit régulier des scripts tiers réellement utiles à votre activité, combiné à une configuration serveur moderne, reste la meilleure façon de garder un site léger. Nos offres d'hébergement mutualisé et VPS Linux s'appuient sur des serveurs configurés pour HTTP/2, et notre constructeur de site limite nativement les ressources superflues chargées par page.
