Comment un paysagiste a divisé son temps de chargement par 13
En mai 2026, j’ai repris le site d’ACAE Paysagiste, un artisan installé à Buzet-sur-Tarn, au nord de Toulouse. Le diagnostic tenait en une ligne : score de performance mobile de 37 sur 100, et un plus gros élément de page qui mettait 18 secondes à s’afficher sur un téléphone.
Le détail qui compte, c’est que ce site n’avait aucun problème d’indexation. Robots.txt correct, sitemap en place, balises d’indexation conformes, 16 adresses déclarées et exploitables. Techniquement, Google pouvait le lire sans difficulté. Simplement, aucun visiteur n’attendait 18 secondes pour voir apparaître une photo de jardin.
C’est le point aveugle de la plupart des dirigeants de TPE. On cherche une raison invisible à un problème visible. On soupçonne l’algorithme, le budget publicitaire, la concurrence du voisin. Dans ce dossier, le vrai coupable se mesurait en trente secondes avec un chronomètre.
| Paramètre | Situation initiale (audit du 31/05/2026) | Intervention Oplia | Résultat mesuré (13/09/2026) |
|---|---|---|---|
| Score de performance mobile | 37 / 100 | Conversion WebP, report des scripts tiers, mise en cache | Mesures directes du 13/09 ci-dessous |
| Affichage du plus gros élément (LCP) | 18 050 ms sur mobile | Image d’en-tête ramenée de 948 Ko à moins de 100 Ko | 1,38 s mesuré, soit 13 fois plus rapide |
| Fluidité visuelle (CLS) | 0,085 sur ordinateur | Redimensionnement des visuels, réservation des espaces | 0,163 au dernier relevé : encore hors seuil, chantier ouvert |
| Poids total transféré | 4 090 Ko sur 90 requêtes | Lazy-load, WebP, nettoyage des dépendances | 1 602 Ko sur 59 requêtes |
Pourquoi un site correctement indexé peut-il rester invisible ?
Un site peut être parfaitement lisible par Google et parfaitement inutilisable par un client. Ce sont deux choses distinctes, et confondre les deux fait perdre des mois. C’est précisément ce que je corrige dans un accompagnement à la refonte de votre site : la vitesse n’est jamais un problème technique isolé, elle se traite avec l’ensemble du parcours.
Google mesure la vitesse avec trois seuils publics : l’affichage du plus gros élément sous 2,5 secondes, la stabilité visuelle sous 0,1, et la réactivité aux clics sous 200 millisecondes (documentation officielle Google). Sur ce dossier, le plus gros élément mettait 18 secondes à apparaître sur mobile, soit sept fois la limite. Le fil principal du navigateur était bloqué pendant 1,9 seconde avant même que le visiteur puisse toucher la page.
D’où venait ce poids ? De quatre choses très banales :
- Une image d’en-tête en PNG de 948 Ko. Un format non compressé, servi dans sa résolution d’origine, pour un écran de téléphone de 390 pixels de large.
- 29 scripts et 43 feuilles de style chargés sur une seule page, dont l’outil de mesure d’audience en mode synchrone.
- Une balise de suivi qui bloquait le fil principal pendant 1,7 seconde. Un outil invisible pour le visiteur, qui retardait tout le reste.
- Aucun chargement différé des images situées sous la ligne de flottaison, soit environ 310 Ko chargés pour rien au premier affichage.
Aucun de ces quatre problèmes ne se voit à l’œil nu. Un site lourd ressemble à un site normal quand on le consulte depuis la fibre d’un bureau. C’est seulement sur le téléphone d’un prospect, en 4G, dans une cour ou sur un chantier, que l’écart se creuse.
Dans quel ordre faut-il corriger un site trop lent ?
L’ordre d’intervention n’est pas neutre. Chaque étape a été choisie pour son rapport entre le gain et le risque de casser quelque chose.
1. Les images en premier. Toutes les images ont été converties en WebP et redimensionnées aux résolutions réellement affichées. L’image d’en-tête est passée de 948 Ko en PNG à moins de 100 Ko, sans que le rendu change à l’écran. C’est l’action qui rapporte le plus, immédiatement, sur un site vitrine ou un site de prestataire.
2. Les scripts tiers ensuite. L’outil de mesure d’audience et les balises de suivi ont été différés : ils ne se chargent plus au chargement de la page, mais au premier signe d’activité du visiteur, avec un repli automatique après quatre secondes pour ne pas perdre de données. Le fil principal du navigateur a été libéré 1,7 seconde.
3. Le chargement différé pour finir. Les visuels situés sous la ligne de flottaison ne se chargent désormais qu’à l’approche de l’écran, ce qui retire environ 310 Ko du premier affichage.

Qu’est-ce que les mesures donnent réellement aujourd’hui ?
J’ai refait la mesure directement sur le site le 13 septembre 2026, dans Chrome, sans bridage de processeur et sans simulation de réseau lent. Voilà ce qui a bougé et ce qui n’a pas bougé.
| Indicateur | Audit du 31/05/2026 | Mesure du 13/09/2026 | Lecture |
|---|---|---|---|
| Temps de réponse du serveur (TTFB) | 320 ms sur mobile | 228 ms | Correct |
| Affichage du plus gros élément | 18 050 ms mobile | 1 380 ms | Dans les seuils Google |
| Poids transféré | 4 090 Ko | 1 602 Ko | Divisé par 2,5 |
| Requêtes | 90 | 59 | Allégé d’un tiers |
| Stabilité visuelle (CLS) | 0,085 desktop | 0,163 | Hors seuil, à corriger |

Je préfère écrire noir sur blanc ce qui reste en travers : la stabilité visuelle est encore dégradée. Au dernier relevé, la page bouge encore pendant son affichage, ce qui provoque des clics à côté sur mobile. C’est mesurable, identifié, et ce n’est pas résolu.
Reste également une police d’icônes de 391 Ko, à elle seule plus lourde que l’image d’en-tête du site. C’est le genre de dépendance qu’on installe pour trois icônes et qu’on n’ose plus retirer. Elle est au programme de la prochaine passe.
Que pouvez-vous transposer sur votre activité ?
Trois choses, applicables cette semaine, sans intervention extérieure. C’est le même travail que celui mené sur ce dossier, et que vous retrouverez détaillé dans notre prestation de création et de refonte de site.
- Mesurez votre site sur mobile avant de chercher autre chose. Ouvrez PageSpeed Insights et lancez le test sur l’adresse de votre page d’accueil. Tant que l’affichage du plus gros élément dépasse 2,5 secondes, vous perdez des prospects avant même qu’ils aient lu votre offre. Aucun travail de référencement ne compense un site qu’on ne peut pas ouvrir.
- Regardez le poids de vos images en priorité. C’est presque toujours le premier poste de dépense. Une photo de chantier prise au téléphone pèse 4 à 8 Mo. Redimensionnée et convertie en WebP, elle descend sous les 200 Ko, sans différence visible à l’écran. Si votre site tourne sous WordPress, un plugin de compression correct fait le travail en une heure.
- Chronométrez la page vous-même, depuis un vrai téléphone, en 4G. Vous découvrirez l’écart entre ce que vous voyez sur votre bureau et ce que vos clients subissent. Ce test ne coûte rien et il est plus convaincant que n’importe quel tableau de bord.

Un site que personne ne peut ouvrir n’a pas un problème de référencement. Il a un problème de porte d’entrée.
Pour aller plus loin
- Pourquoi mon site lent me fait perdre des clients ? : ce que la vitesse change concrètement sur vos demandes de devis
- Mon site n’apparaît pas sur Google : par où commencer ? : le protocole de diagnostic, du plus simple au plus technique
- Comment faire de mon site une machine à trouver des clients ? : la suite logique une fois le site rapide et lisible
Questions fréquentes
Combien de temps faut-il pour voir une amélioration réelle de la vitesse d'un site WordPress ?
Faut-il tout refaire sur son site pour gagner en vitesse ?
Pourquoi mon site est-il beaucoup plus lent sur mobile que sur ordinateur ?
Besoin d'un accompagnement de proximité ? Découvrez nos zones d'intervention dans toute la France.