Camille-C Chardon, gestion de projet web
Accélérer le site d'un commerce spécialisé : ce qui a été fait et ce que ça change vraiment
En un après-midi, la page d’accueil du site d’un commerce spécialisé a perdu environ 850 Ko de JavaScript inutile, sans refonte et sans plugin payant. Deux changements ciblés ont suffi :
- remplacer la vidéo YouTube par une image cliquable,
- et remplacer le reCAPTCHA de Google par Cloudflare Turnstile.
Le point de départ
Tout est parti d’une recommandation de botrank.ai, un outil qui évalue la lisibilité d’un site pour les moteurs de recherche et les assistants IA. Son verdict : auditer les scripts, styles et images non essentiels de la page d’accueil, différer ce qui n’est pas visible au premier écran, charger les médias « paresseusement » (en lazy load), puis mesurer à nouveau. Le tout en préservant ce qui fonctionnait déjà bien : l’URL canonique, le sitemap, le robots.txt et le fichier llms.txt.
Le site tourne sous WordPress.
Sa page d’accueil est riche : bannière, vidéo de présentation, une soixantaine de logos de marques, douze actualités et un fil Instagram. C’est précisément ce contenu sous la ligne de flottaison qui pesait le plus lourd.
Deux diagnostics très différents
PageSpeed Insights, l’outil de mesure de Google, donne deux lectures distinctes. Et le 5 octobre à 12h04, elles racontaient deux histoires opposées.
Les vrais visiteurs : tout va bien. Les données récoltaient l’expérience des utilisateurs de Chrome sur 28 jours. Le site passait les Core Web Vitals, les critères que Google utilise pour son classement. Le contenu principal s’affichait en 2,1 secondes, les clics répondaient en 96 millisecondes et rien ne bougeait à l’écran. Seul point faible : le serveur mettait 1,4 seconde à envoyer le premier octet de la page, alors que Google recommande moins de 0,8 seconde.
Le test de laboratoire : 30 sur 100. Ce test simule un téléphone de milieu de gamme sur une 4G lente. Il révélait une page lourde : le processeur restait bloqué près de 2 secondes par du JavaScript, et la page mettait 11,5 secondes à se remplir visuellement.
L’outil chiffrait à 1 342 Ko le JavaScript téléchargé sans être utilisé. Presque tout venait de services externes, pas du site lui-même :
Source | Poids téléchargé | Inutilisé |
|---|---|---|
Lecteur vidéo YouTube | 853 Ko | 518 Ko |
Google reCAPTCHA (chargé deux fois) | 694 Ko | 337 Ko |
Google Tag Manager et ses balises | 677 Ko | 288 Ko |
Facebook (widget et pixel) | 336 Ko | 129 Ko |
Hotjar | 56 Ko | 27 Ko |
Code propre au site | 37 Ko | 23 Ko |
Le code du site ne représentait que 37 Ko. Les deux plus gros postes, la vidéo et l’anti-spam, étaient aussi les plus faciles à traiter.
Ce qui a été fait
1. La vidéo YouTube remplacée par une image cliquable.
La vidéo de présentation chargeait le lecteur YouTube complet à chaque visite, soit 853 Ko de scripts, même si personne ne la regardait. Elle a été remplacée par un petit bloc HTML personnalisé : une image de couverture et un bouton de lecture. Le vrai lecteur ne se charge qu’au clic. La vidéo passe aussi par youtube-nocookie.com, qui ne dépose pas de cookies de suivi avant la lecture. Aucun plugin n’a été installé.
2. Google reCAPTCHA remplacé par Cloudflare Turnstile.
Le formulaire de contact présent dans le pied de page de chaque page était protégé par reCAPTCHA. Celui-ci était chargé deux fois, sur toutes les pages, pour 694 Ko. Il a été remplacé par Cloudflare Turnstile, un service anti-spam gratuit et bien plus léger, qui ne suit pas les visiteurs. La mise en place a pris un compte Cloudflare gratuit, une extension WordPress gratuite et la suppression des clés reCAPTCHA dans Contact Form 7.
Dans les deux cas, l’apparence et le fonctionnement pour le visiteur restent les mêmes : la vidéo se lance toujours d’un clic, le formulaire fonctionne toujours.
Avant / après
Le JavaScript inutile a fondu de 1 342 Ko à 492 Ko, et la page se remplit presque deux fois plus vite.
Mesures PageSpeed Insights, mobile, le 5 octobre 2026 à 12h04 puis vers 14h30.
Indicateur | Avant | Après | Évolution |
|---|---|---|---|
JavaScript inutilisé | 1 342 Ko | 492 Ko | −63 % |
Speed Index (remplissage visuel) | 11,5 s | 6,9 s | −4,6 s |
Stabilité de la mise en page (CLS) | 0,089 | 0,065 | Meilleure |
Score Bonnes pratiques | 73 | 96 | +23 points |
Total Blocking Time | 1 920 ms | 1 840 ms | Stable |
Premier affichage (FCP) | 4,1 s | 4,1 s | Inchangé |
Plus grand élément affiché (LCP) | 6,6 s | 6,6 s | Inchangé |
Score Performance | 30 | 34 | +4 points |
Le score Performance n’a gagné que 4 points, et c’est normal. Il dépend surtout du temps de blocage et du premier affichage, deux indicateurs que ces changements ne visaient pas. Les tests de laboratoire varient aussi de quelques points d’une mesure à l’autre. Les données des vrais visiteurs, calculées sur 28 jours, n’intégreront ces changements que progressivement.
Ce que ça améliore vraiment
Le gain principal n’est pas dans le score : il est dans ce que le téléphone du visiteur n’a plus à télécharger ni à exécuter.
- Moins de données mobiles. Environ 850 Ko de scripts en moins à chaque visite de la page d’accueil. Cela compte pour un client qui consulte le site avec une connexion faible ou un forfait limité.
- Une page qui se remplit plus vite. Le Speed Index passe de 11,5 à 6,9 secondes : le visiteur voit le contenu apparaître nettement plus tôt en faisant défiler la page.
- Moins de suivi par des tiers. Ni YouTube ni Google reCAPTCHA ne se chargent plus d’office. Les cookies tiers ont disparu, d’où le bond du score Bonnes pratiques de 73 à 96. C’est aussi un plus pour la protection des données des visiteurs.
- Une page plus stable. La mise en page bouge moins pendant le chargement, ce qui évite les clics ratés.
- Rien n’est cassé. URL canonique, sitemap, robots.txt et llms.txt sont intacts, et le score SEO reste à 100.
Ce qui ne change pas encore. Le premier affichage reste à 4,1 secondes et le blocage du processeur reste élevé. Ces deux points dépendent d’autres causes : des fichiers CSS et JavaScript qui bloquent l’affichage (estimés à 3 secondes), les balises de Google Tag Manager, Facebook et Hotjar, et la lenteur du serveur.
La suite
Les prochaines étapes visent le premier affichage et le blocage du processeur, avec des outils gratuits et une nouvelle mesure après chaque changement :
- Différer les fichiers CSS et JavaScript qui bloquent l’affichage, par exemple avec l’extension Autoptimize.
- Retarder Google Tag Manager, le pixel Facebook et Hotjar jusqu’à la première interaction du visiteur, et vérifier qu’ils attendent son consentement.
- Remplacer le widget Facebook du pied de page par un simple lien.
- Convertir les images en WebP et alléger la page, qui pèse encore près de 6 Mo.
- Mettre en place un cache de pages pour réduire le temps de réponse du serveur.
La leçon de cette première étape : avant d’installer une extension de plus, il vaut la peine de regarder ce que la page charge vraiment. Ici, deux services externes représentaient plus de la moitié du JavaScript inutile.