Trop de requêtes HTTP sur une page : comment les réduire

Trop de requêtes HTTP, ce n’est pas une erreur 429. C’est une page qui, pour afficher un écran, télécharge des dizaines de fichiers : CSS, JavaScript, images, polices, pixels publicitaires, chat, A/B test. Chaque fichier ajoute une attente. Sur mobile, cette attente se voit dans le LCP, le temps avant que le contenu principal apparaisse.

Compter les requêtes

1. Ouvrez la page dans Chrome.
2. Ouvrez les outils de développement, onglet Réseau.
3. Cochez Désactiver le cache, rechargez.
4. Lisez le nombre de requêtes en bas du panneau, et le poids transféré.

Triez par nom de domaine. Si une grande partie des lignes ne vient pas de votre site (googletagmanager.com, un chat, une régie, une police hébergée ailleurs), le levier n’est pas le serveur : ce sont les outils collés à la page.

Repérez aussi les lignes en rouge et celles qui restent longues avant le premier affichage. Une requête bloquante dans le <head> retarde tout le reste, même si le total « n’est que » de 40 fichiers.

D’où viennent les requêtes en trop

• Images : une image pleine taille alors que le navigateur affiche une vignette, plus une version pour chaque icône de réseau social.
• Polices : quatre graisses et deux familles alors que la page n’en utilise qu’une.
• Constructeur de page ou thème : un CSS et un JS chargés sur toutes les pages, y compris celles qui n’utilisent pas le module.
• Tags : Google Tag Manager qui charge Analytics, Ads, un pixel et un outil de heatmaps, chacun avec ses propres fichiers.
• Extensions : un slider, un bandeau cookies et un chat, chacun avec deux ou trois requêtes.

HTTP/2 et HTTP/3 envoient plusieurs fichiers dans la même connexion. Ils ne rendent pas un script de 400 Ko gratuit, et ils ne rendent pas un fichier tiers rapide si ce domaine met 600 ms à répondre.

Réduire dans cet ordre

1. Supprimez ce qui n’est plus utilisé. Un pixel « qu’on verra plus tard » coûte déjà.
2. Remplacez les images trop lourdes. Une image au format affiché, en WebP ou AVIF, enlève souvent plus de poids que la fusion de trois CSS.
3. Limitez les polices à une famille et aux graisses visibles. Ajoutez font-display: swap pour ne pas bloquer le texte.
4. Chargez les scripts secondaires après le contenu. Le chat et les avis clients n’ont pas à partir avant le titre de la page.
5. Ne concaténez pas tout à l’aveugle. Un seul fichier de 2 Mo est pire que dix petits fichiers bien mis en cache. Fusionnez seulement les fichiers qui changent ensemble et qui bloquent l’affichage.

Après chaque retrait, rechargez l’onglet Réseau et notez le nouveau total. Si vous changez cinq choses d’un coup, vous ne saurez pas laquelle a rendu la page plus rapide.

Lien avec les Core Web Vitals

Le nombre de requêtes n’est pas une métrique Google. Il agit sur le LCP (le gros élément arrive tard parce que d’autres fichiers passent avant) et parfois sur l’INP (trop de JavaScript à exécuter au premier clic). Le détail des seuils est dans le guide Core Web Vitals.

Une page allégée peut régresser au prochain plugin. Contrôler le temps de réponse des URL importantes fait partie du monitoring de site web : une page qui passe de 400 ms à 3 s est souvent une page qui a gagné des scripts, pas seulement un serveur lent.

Erreurs qui empirent le diagnostic

• Mesurer avec le cache activé, puis comparer à un visiteur qui arrive pour la première fois.
• Tester seulement sur le Wi-Fi du bureau.
• Ajouter une extension « d’optimisation » qui charge elle-même deux scripts.
• Croire qu’un CDN annule le coût des ressources tiers : le CDN accélère vos fichiers, pas ceux des autres domaines.

Visez une page compréhensible avec le minimum de fichiers avant l’affichage du titre et de l’image principale. Le reste peut attendre le scroll ou un clic.

Articles connexes : Core Web Vitals | Scripts tiers et performance | Lazy-loading des images