Votre site est lent et GTMetrix affiche plus de 130 requêtes HTTP par page?

Ce n’est pas un chiffre abstrait sorti d’un rapport. Chaque requête correspond à un appel du navigateur au serveur pour un fichier: un script, une feuille de style, une image ou une police. Plus il y a de requêtes, plus vos visiteurs restent longtemps devant un écran blanc. Selon Portent, un délai de chargement qui passe de 0 à 3 secondes réduit la conversion de 2,5%. Et chaque seconde supplémentaire au-delà coûte encore 4,4%.

Le problème des requêtes HTTP, ce n’est pas leur existence. C’est que la plupart des sites WordPress en génèrent bien plus que nécessaire. Voici cinq actions concrètes pour réduire le nombre de requêtes sans refondre intégralement votre site.

💡 Aperçu rapide:

• Supprimez les plugins et thèmes inutilisés qui créent des requêtes superflues sur chaque page
• Optimisez les images: compressez les fichiers, supprimez les visuels inutiles, regroupez les icônes en sprites
• Fusionnez le CSS et le JavaScript en 1 ou 2 fichiers et activez la minification
• Mettez en place le chargement différé pour les scripts qui bloquent l’affichage de la page
• Activez la mise en cache et un CDN pour que les visiteurs récurrents ne rechargent pas l’intégralité du site

Étape 1. Faites le ménage

Chaque plugin installé apporte son lot de fichiers. PHP, CSS, JavaScript: chacun d’eux génère une requête HTTP au chargement de la page. Vingt plugins, cela peut représenter près d’une centaine de requêtes rien qu’au démarrage, avant même l’affichage du moindre contenu.

La première chose à faire est un audit. Ouvrez Extensions → Extensions installées et posez-vous honnêtement la question: lesquelles sont indispensables au fonctionnement du site, et lesquelles sont simplement là «au cas où»? Cet analyseur SEO installé il y a un an et ouvert deux fois est un bon candidat à la suppression. Le plugin d’icônes sociales aussi, si vous avez déjà intégré les liens dans le pied de page.

Une catégorie à part concerne les plugins qui se connectent à des serveurs tiers. Chat en direct, radio en streaming, notifications push. Chacun de ces plugins crée des requêtes HTTP externes supplémentaires vers des serveurs distants. Supprimez tout ce dont le site peut se passer. Vous en avez besoin une fois par mois? Installez-le pour une journée, puis désinstallez-le.

La même règle s’applique aux thèmes. Dans Apparence → Thèmes, conservez uniquement votre thème actif et un thème de secours (par exemple, le thème par défaut Twenty Twenty-Five). Supprimez le reste.

Si un plugin est nécessaire mais seulement sur une page spécifique, chargez-le de manière sélective. Asset CleanUp: Page Speed Booster fait exactement cela. C’est une extension gratuite qui compte plus de 100 000 installations actives et une note de 4,7 sur WordPress.org.

L’extension analyse la page, affiche la liste des fichiers CSS et JS chargés et vous permet de désactiver des fichiers précis sur des pages, des types de publication ou sur l’ensemble du site. Vous utilisez Contact Form 7 uniquement sur la page de contact? Décochez-le partout ailleurs, et ses scripts ne se chargeront pas là où le formulaire est absent.

🔗 Asset CleanUp sur WordPress.org

Profitez-en pour optimiser votre base de données. Après avoir nettoyé les plugins, leurs réglages et leurs enregistrements restent dans les tables et doivent également être supprimés. Vérifiez aussi les liens cassés: chaque redirection est une requête HTTP supplémentaire.

Pour visualiser clairement l’ampleur du problème avant et après, testez votre site avec GTMetrix:

Le premier test montre la situation de référence: nombre de requêtes, poids total de la page, temps de chargement. Après chaque étape de cet article, relancez le test. Vous verrez ainsi quelles modifications ont eu le plus d’impact.

Étape 2. Optimisez les images

Les images représentent le plus gros «poids» d’une page WordPress moyenne. Selon HTTP Archive, elles comptent pour environ 44% du poids total d’une page sur ordinateur. Et chaque image est une requête HTTP.

Commencez par supprimer les fichiers inutilisés. Dans Médias → Bibliothèque, filtrez par «Non attaché». Il s’agit des images qui ne sont liées à aucun article. Si elles ne sont pas utilisées dans le thème ou le pied de page, supprimez-les.

Vient ensuite la compression. Des extensions comme WP Compress gèrent cela automatiquement: lorsque vous téléversez une image, elle passe par un optimiseur cloud, est compressée sans perte de qualité visible et convertie en WebP ou AVIF. Ces formats sont nettement plus légers que le JPEG à qualité visuelle équivalente. Selon Google, le WebP réduit la taille des fichiers de 25 à 35% en moyenne par rapport au JPEG.

WP Compress compte plus de 10 000 installations actives, une note de 4,5 sur 5 et plus de 1,1 million de téléchargements sur WordPress.org. Les 100 premières images sont gratuites, de quoi constater la différence.

🔗 WP Compress sur WordPress.org

La compression seule ne réduit pas le nombre de requêtes HTTP. Mais elle diminue la taille de chaque fichier, ce qui réduit le temps de transfert. Combinée aux autres étapes, elle apporte un gain de vitesse notable.

Sprites CSS: un fichier au lieu de dix

Si vous avez une dizaine de petites icônes sur une page (réseaux sociaux, flèches, étoiles de notation), chacune se charge via une requête distincte. Un sprite CSS résout ce problème: toutes les icônes sont regroupées dans un seul fichier, et le CSS affiche la portion nécessaire.

Voici le principe: cinq images, c’est cinq requêtes serveur. Ces cinq mêmes images combinées en un seul sprite, c’est une requête. Des outils en ligne comme CSS Sprite Generator peuvent créer des sprites pour vous. Une connaissance de base du CSS est nécessaire pour définir la propriété background-position de chaque icône.

Remarque: si votre serveur prend en charge HTTP/2, les fichiers se chargent de manière asynchrone au sein d’une même connexion. Dans ce cas, le gain apporté par les sprites est moins sensible. Mais en pratique, une dizaine d’icônes dans un seul fichier se chargent toujours plus vite que dix fichiers séparés.

Étape 3. Fusionnez et minifiez le CSS et le JavaScript

Un site WordPress typique compte plus de 40 fichiers JS et plus de 20 fichiers CSS. Chacun représente une requête HTTP distincte. Cela fait plus de 60 appels serveur rien que pour les scripts et les styles, qui se chargent avant l’apparition du moindre contenu.

La minification supprime tout ce qui est superflu dans les fichiers: espaces, sauts de ligne, commentaires. Le fichier devient plus léger, mais le nombre de requêtes HTTP reste inchangé.

La fusion regroupe plusieurs fichiers en un seul. Cinq fichiers CSS deviennent deux (un pour la partie visible sans défilement, un pour le reste). Cinq fichiers JS, même principe. Et au lieu de dix requêtes, vous passez à deux ou trois.

L’outil gratuit le plus répandu pour cela est Autoptimize. Une extension qui compte un million d’installations actives et une note de 4,7. Dans les réglages, trois cases à cocher: optimiser le HTML, le CSS et le JS. Cochez les trois et observez les résultats immédiats.

Pour un contrôle plus fin, il existe WP Rocket, une solution premium qui combine la fusion, la minification et la mise en cache dans une seule interface.

Après avoir combiné les fichiers, vérifiez toujours votre site en navigation privée: il arrive que la fusion casse la mise en page. Si quelque chose ne s’affiche pas correctement, désactivez la combinaison pour le fichier problématique et conservez uniquement la minification.

🔗 Site officiel de WP Rocket

Un dernier point: la combinaison de fichiers n’est pas une solution miracle. Si un plugin charge des scripts externes depuis un CDN (Google Fonts, reCAPTCHA, lecteur YouTube), vous ne pouvez pas les combiner. Vous pouvez uniquement les différer ou les charger de manière asynchrone, ce qui nous amène à l’étape suivante.

Étape 4. Gérer les scripts bloquant le rendu

Le navigateur lit une page de haut en bas. Lorsqu’il rencontre <script src="..."> dans le <head>, il interrompt le rendu, télécharge entièrement le script, puis reprend seulement ensuite. Pendant ce temps, les visiteurs voient une page blanche.

La solution consiste à déplacer les scripts qui ne sont pas nécessaires à l’affichage du premier écran en bas de page, ou à ajouter l’attribut async/defer. La différence:

• defer: le script se charge en arrière-plan mais s’exécute strictement après la fin de l’analyse du HTML et dans l’ordre où ils sont inclus;
• async: le script se charge et s’exécute dès que possible, sans ordre garanti.

Pour WordPress, il existe une extension gratuite appelée Async JavaScript. Elle ajoute async ou defer aux scripts sélectionnés via une interface claire. Elle fonctionne immédiatement, mais demande de la prudence: si un script auquel on a ajouté async doit s’exécuter avant un autre, la page peut casser.

Une approche prudente consiste à tester sur un seul script, vérifier le site en navigation privée, puis passer au suivant.

WP Rocket peut également différer les scripts: allez dans Optimisation des fichiers → Charger le JavaScript différé. Sélectionnez «Différé» et ajoutez jQuery aux exclusions, car la plupart des thèmes et extensions WordPress en dépendent.

Résultat: la page commence à s’afficher plus tôt, même si le nombre total de requêtes HTTP n’a pas changé. Les visiteurs voient le contenu pendant que les scripts restants se chargent en arrière-plan.

Étape 5. Activer la mise en cache et le CDN

La mise en cache réduit directement les requêtes HTTP lors des visites répétées. Le mécanisme est simple: le navigateur enregistre les fichiers statiques (CSS, JS, images, polices) en local. Au prochain chargement de la page, au lieu de les demander au serveur, il les récupère depuis le cache. Zéro requête HTTP pour ce fichier.

La mise en cache côté serveur est le niveau supérieur: le serveur délivre une page HTML déjà assemblée au lieu d’exécuter des dizaines de requêtes PHP vers la base de données. Les extensions de cache (WP Rocket, Flying Press, W3 Total Cache) le font automatiquement.

Un CDN (Content Delivery Network) est un réseau de serveurs répartis dans le monde. Au lieu d’aller chercher les fichiers sur votre hébergement aux Pays-Bas pour un visiteur au Brésil, le CDN les délivre depuis le nœud le plus proche. De plus, les fournisseurs de CDN incluent souvent la compression, la minification et l’optimisation des images de série.

Cloudflare est une option gratuite qui couvre les besoins de base: CDN, protection DDoS, SSL gratuit.

Installez l’extension Cloudflare pour WordPress. Elle connecte votre site au CDN et fournit les réglages de base directement depuis l’administration. Pour un contrôle plus fin, allez dans le tableau de bord Cloudflare: activez la minification automatique pour CSS/JS/HTML, la compression Brotli et Rocket Loader pour le chargement asynchrone des scripts.

🔗 Cloudflare sur WordPress.org

Avec la mise en cache et le CDN, le nombre de requêtes HTTP pour les visiteurs récurrents chute considérablement. Première visite: chargement complet. Deuxième visite: la plupart des fichiers proviennent du cache du navigateur et du nœud CDN le plus proche, sans aucun appel à votre serveur.

Bonus: vérifier si votre serveur prend en charge HTTP/2

HTTP/2 est un protocole qui transfère plusieurs fichiers via une seule connexion TCP. Le navigateur n’attend pas que le fichier n°1 ait fini de se télécharger pour demander le fichier n°2; ils se chargent en parallèle. Cela réduit l’impact d’un nombre élevé de requêtes HTTP: 60 fichiers en HTTP/2 se chargent plus vite que les mêmes 60 en HTTP/1.1.

Vérifiez votre serveur avec l’outil de test HTTP/2 de KeyCDN. Saisissez votre domaine et cliquez sur «Test». Un résultat «HTTP/2 is supported» signifie que le multiplexage fonctionne.

Si le test indique HTTP/1.1, contactez votre hébergeur. La plupart des hébergeurs modernes (SiteGround, Cloudways, Kinsta) activent HTTP/2 par défaut. Sur un hébergement mutualisé des années 2010, ce n’est pas toujours le cas. Vérifiez aussi votre version de PHP: passer à une version récente de PHP apporte un gain de performance notable, tandis que les versions obsolètes traitent les requêtes nettement plus lentement. Si votre hébergeur ne met à jour ni le protocole ni la version de PHP, il est peut-être temps d’envisager de changer d’hébergeur.

Si vous préférez le format vidéo, voici un guide visuel pour réduire les requêtes HTTP dans WordPress (12 minutes).

⁉️🤔 Foire aux questions

Quel nombre de requêtes HTTP est considéré comme normal pour WordPress?

Une fourchette cible se situe entre 30 et 60 par page. Au-delà de 80-90, une optimisation s’impose. GTMetrix et Pingdom affichent des chiffres précis dans leurs rapports. Après avoir appliqué les cinq étapes de cet article, il est réaliste de passer de 130 à 35-45 requêtes.

«J’ai un site sous Elementor, et il totalise déjà plus de 100 requêtes. Est-ce normal?»

Les constructeurs de pages génèrent par nature beaucoup de CSS et de JS. Elementor et Divi ajoutent à eux seuls 30 à 50 requêtes. Cela ne signifie pas qu’il faut «l’accepter»; cela signifie que le reste de votre site doit être aussi propre que possible. Supprimez tout ce qui n’est pas lié au constructeur: extensions inutiles, polices externes, images non optimisées. Ne gardez que ce qui sert réellement vos visiteurs.

Qu’est-ce qui importe le plus: le nombre de requêtes ou le poids total de la page?

Les deux. 20 requêtes de 1 Mo chacune signifient un temps de chargement de 20 secondes. 100 requêtes de 5 Ko chacune peuvent se charger plus vite, mais chaque requête engendre un surcoût lié à la résolution DNS, à la connexion TCP et à la poignée de main TLS. En HTTP/2, cette différence est atténuée. En HTTP/1.1, elle est critique. Optimisez les deux: réduisez le nombre de requêtes en combinant les fichiers et en utilisant des sprites, réduisez le poids par la compression et la minification.

Puis-je m’en sortir sans extensions?

En partie, oui. La minification CSS/JS peut être configurée via Gulp ou Webpack pendant le développement du thème. HTTP/2 s’active au niveau du serveur (configuration Nginx/Apache). La mise en cache peut être réalisée via des règles serveur. Mais pour la plupart des propriétaires de sites WordPress, les extensions restent la voie la plus pratique: la mise en place prend quelques minutes, les résultats sont immédiats et le risque de casser le site est plus faible.

À quelle fréquence dois-je revérifier le nombre de requêtes HTTP?

Après chaque installation ou mise à jour majeure d’extension. Une nouvelle extension peut ajouter ses CSS/JS sur toutes les pages, et vous ne le remarquerez pas avant que le site ne commence à ralentir. Une fois par mois suffit pour un contrôle de routine. GTMetrix vous permet de configurer une surveillance automatique avec des alertes en cas de baisse de performance.

Ai-je vraiment besoin de ce guide si j’ai déjà un hébergement rapide?

L’hébergement règle une partie du problème au niveau du serveur, mais pas au niveau du code. Si un plugin insère 15 scripts dans le <head> de la page, même les serveurs les plus performants ne les feront pas charger instantanément. Le navigateur attendra quand même. Un hébergement rapide vous donne une longueur d’avance, mais le vrai gagnant est celui qui nettoie aussi le côté client.

Qu’est-ce qui réduit réellement les requêtes HTTP, et qu’est-ce qui ne le fait pas?

Passons en revue toutes les étapes sans illusions:

• Le nettoyage des plugins et des thèmes apporte l’amélioration la plus visible. Chaque plugin supprimé élimine ses CSS, JS et appels externes. En pratique, 10 à 30 requêtes disparaissent après un audit.
• La compression d’images réduit le poids des fichiers, mais le nombre de requêtes reste identique. En revanche, le temps de chargement total baisse de façon notable.
• La combinaison des CSS et JS diminue significativement le nombre de requêtes. Inconvénient: cela peut casser la mise en page, donc vérifiez après chaque modification.
• Le chargement différé des scripts: même nombre de requêtes, mais la page devient visible plus tôt.
• Cache et CDN: pour les nouveaux visiteurs, la différence est minime. Pour les visiteurs récurrents, les chargements de page suivants se font sans la moindre requête au serveur.

S’il fallait retenir exactement trois actions ayant le plus fort impact sur un site WordPress classique: (1) supprimer les plugins inutiles, (2) activer la combinaison CSS/JS via Autoptimize, (3) mettre en place Cloudflare. Ce sont trois étapes qui prennent une soirée plutôt qu’une semaine, et vous en verrez les résultats dans les chiffres GTMetrix dès le lendemain.