Comment un paysagiste a divisé son temps de chargement par 13

Auteur : Thomas — Oplia
Publié le : 3 juillet 2026
Mis à jour le : 29 août 2026
Temps de lecture : 7 min
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ètreSituation initiale (audit du 31/05/2026)Intervention OpliaRésultat mesuré (13/09/2026)
Score de performance mobile37 / 100Conversion WebP, report des scripts tiers, mise en cacheMesures directes du 13/09 ci-dessous
Affichage du plus gros élément (LCP)18 050 ms sur mobileImage d’en-tête ramenée de 948 Ko à moins de 100 Ko1,38 s mesuré, soit 13 fois plus rapide
Fluidité visuelle (CLS)0,085 sur ordinateurRedimensionnement des visuels, réservation des espaces0,163 au dernier relevé : encore hors seuil, chantier ouvert
Poids total transféré4 090 Ko sur 90 requêtesLazy-load, WebP, nettoyage des dépendances1 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.

Infographie : les 3 corrections et leur gain mesuré sur le temps d'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é.

IndicateurAudit du 31/05/2026Mesure du 13/09/2026Lecture
Temps de réponse du serveur (TTFB)320 ms sur mobile228 msCorrect
Affichage du plus gros élément18 050 ms mobile1 380 msDans les seuils Google
Poids transféré4 090 Ko1 602 KoDivisé par 2,5
Requêtes9059Allégé d’un tiers
Stabilité visuelle (CLS)0,085 desktop0,163Hors seuil, à corriger

Infographie : comparatif avant/après des 5 indicateurs de performance mesurés sur le site, poids divisé par 2,5 et affichage passé de 18 050 ms à 1 380 ms

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.

Capture réelle de la page d'accueil du site après correction

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

Questions fréquentes

Combien de temps faut-il pour voir une amélioration réelle de la vitesse d'un site WordPress ?
Les gains les plus importants se mesurent dès la première semaine. Sur ce dossier, la conversion des images et le report des scripts tiers ont été déployés en 4 jours, et le plus gros élément de la page est passé de 18 secondes à 1,4 seconde. Le score Lighthouse, lui, bouge plus lentement : il dépend aussi du temps de réponse du serveur et de la mise en cache, qui demandent une à deux semaines de réglages supplémentaires.
Faut-il tout refaire sur son site pour gagner en vitesse ?
Rarement. Dans neuf cas sur dix, le blocage vient de trois choses : des images non compressées, des scripts tiers chargés trop tôt, et l'absence de chargement différé des visuels sous la ligne de flottaison. Ces trois corrections se font sur un site existant, sans toucher à la structure ni au contenu. Une refonte complète ne se justifie que si votre hébergement lui-même est saturé.
Pourquoi mon site est-il beaucoup plus lent sur mobile que sur ordinateur ?
Un téléphone en 4G dispose de dix à vingt fois moins de puissance de calcul et de débit qu'un ordinateur de bureau. Un site qui s'affiche en 2 secondes sur votre PC peut dépasser les 15 secondes sur un smartphone d'entrée de gamme. C'est pour cette raison que Google évalue la vitesse en priorité sur mobile : votre client, lui, consulte votre site depuis son téléphone, souvent en extérieur.
Thomas DE ALMEIDA — Fondateur d'Oplia
Qui écrit ?

Je combine SEO technique, performance web et IA pour aider les TPE/PME à gagner en visibilité en ligne. Que de la valeur concrète pour votre business.

Besoin d'un accompagnement de proximité ? Découvrez nos zones d'intervention dans toute la France.