Vitesse d'un site local : plan d'action pragmatique

Un plan d'action réaliste pour la vitesse d'un site local tient en trois gestes : mesurer une page réelle sur mobile, repérer la ressource la plus lourde (le plus souvent une image ou une police), puis corriger une seule cause à la fois. Les trois repères officiels de Google, LCP, INP et CLS, donnent des seuils concrets pour savoir où on en est, sans jargon technique. Pour un premier relevé, utilisez le diagnostic gratuit vitesse, mobile et clarté de votre site.

Les 3 repères officiels à connaître : LCP, INP, CLS

Google mesure la vitesse perçue d'un site avec trois indicateurs, les Core Web Vitals. Le LCP (Largest Contentful Paint) mesure le temps d'affichage du plus gros élément visible, en général une image ou un titre : une page réactive l'affiche généralement en dessous de 2,5 secondes. L'INP (Interaction to Next Paint) mesure la réactivité quand un visiteur clique ou touche l'écran : un site fluide répond en dessous de 200 millisecondes dans la plupart des cas. Le CLS (Cumulative Layout Shift) mesure les décalages visuels pendant le chargement, par exemple un bouton qui saute au moment où une image se charge : un score sous 0,1 est considéré comme correct.

Ces trois repères viennent directement de Google et servent de base à la plupart des outils de mesure gratuits. Ils ne remplacent pas un avis de spécialiste, mais ils donnent un langage commun et des seuils vérifiables plutôt qu'une impression de lenteur. Pour un dirigeant pressé, l'essentiel est de retenir l'ordre de grandeur de chaque seuil, pas la mécanique exacte de calcul : voir web.dev, comprendre les Core Web Vitals pour la définition officielle et complète.

Pourquoi un site local charge souvent trop d'images

Les sites d'artisans et de commerces locaux ont un point commun : une galerie de réalisations ou de photos de chantier, souvent ajoutée telle quelle depuis l'appareil photo ou le smartphone, sans compression. Une photo de plusieurs mégaoctets n'est pas un problème pour la regarder sur un ordinateur, mais elle l'est pour un site qui doit en charger dix, vingt ou quarante d'un coup sur une page d'accueil ou une page portfolio.

Sur mobile, ce poids se paie généralement deux fois : une connexion mobile est souvent plus lente qu'une box fibre, et un écran plus petit n'a pas besoin d'une image aussi large pour paraître nette. Résultat, le LCP peut se dégrader nettement sur mobile alors qu'il semblait correct sur ordinateur. Ce sujet du poids des images touche aussi la manière de les choisir et de les légender pour qu'elles servent le référencement local, un enjeu traité à part, pour en faire des preuves locales utiles.

Le plan d'action en 3 étapes réalistes

Première étape, mesurer une page réelle du site en conditions mobiles, pas seulement la page d'accueil optimisée pour la démo. Des outils de mesure gratuits simulent une connexion mobile et donnent un score LCP, INP et CLS pour cette page précise. Deuxième étape, identifier dans le rapport la ressource la plus coûteuse, c'est-à-dire l'élément qui bloque le plus le chargement. Dans la plupart des sites de TPE, il s'agit d'une image en haute résolution ou d'une police web chargée en plusieurs variantes inutiles.

Troisième étape, corriger cette seule cause avant de passer à la suivante, plutôt que de tout changer en même temps. Compresser les images d'une galerie, limiter le nombre de polices, ou différer le chargement d'un script tiers sont des corrections ciblées qui peuvent améliorer le score sans toucher au design ni au contenu. Une refonte complète n'est généralement pas nécessaire pour un problème de vitesse localisé sur une ou deux ressources.

Un exemple illustratif : une galerie de 40 photos qui ralentit tout

Exemple illustratif : une TPE du bâtiment publie une galerie de 40 photos de chantier en pleine résolution sur sa page d'accueil, pour montrer la diversité de ses réalisations. La page met plusieurs secondes à afficher son image principale sur mobile, et le score LCP dépasse nettement le seuil indicatif. Le réflexe naturel serait de penser à une refonte complète du site, alors que la cause est concentrée sur un seul point : le poids cumulé des photos.

Dans ce cas de figure, un tri des photos les plus représentatives et une compression systématique, souvent proposée directement par l'outil de gestion du site, suffisent généralement à corriger la cause principale, sans toucher au design ni à la structure des pages. C'est le type d'intervention ciblée que peut couvrir l'accompagnement site de Leka Digital, sans passer par un chantier de refonte.

Ce qui n'est pas un problème de vitesse, malgré les apparences

Un site qui semble lent n'a pas toujours un problème de vitesse au sens des Core Web Vitals. Un formulaire de contact qui ne génère pas de demandes, une page qui ne convainc pas malgré un bon score technique, ou une navigation confuse sont des sujets différents, liés au contenu et au parcours plutôt qu'au temps de chargement. De même, un contraste de couleur insuffisant ou un bouton trop petit pour être touché facilement n'est pas une question de vitesse, même si l'expérience globale en pâtit.

Avant de conclure à un problème de vitesse, il peut être utile de vérifier d'abord les contrôles de conversion d'un site vitrine si le sujet est le manque de demandes, ou les priorités d'accessibilité d'un site de TPE si le sujet est la facilité d'usage. La vitesse reste un repère technique précis, pas une réponse à tout.

Exemple illustratif chiffré : le poids d'une galerie avant et après tri

Exemple illustratif, à refaire avec vos propres chiffres : une page réalisations affiche 40 photos sorties du smartphone, d'environ 4 Mo chacune. Les hypothèses sont volontairement simples : une connexion mobile de 20 Mbit/s, sans tenir compte de la latence, du cache ni du chargement différé.

Élément	Avant	Après
Nombre de photos	40	12 retenues
Poids par photo	4 Mo	250 Ko après compression
Poids total	40 × 4 = 160 Mo	12 × 250 Ko = 3 Mo
Temps de transfert théorique à 20 Mbit/s	160 × 8 = 1 280 Mbit, soit 64 secondes	3 × 8 = 24 Mbit, soit 1,2 seconde

Le calcul reste théorique : un navigateur ne charge pas forcément toutes les images d'un coup, surtout si le chargement différé est activé. Il montre pourtant l'ordre de grandeur, un poids divisé par plus de cinquante, qui explique pourquoi trier et compresser passe avant toute autre optimisation. Pour votre site, relevez le nombre de photos d'une page et le poids moyen d'un fichier, visible dans les propriétés du fichier ou l'onglet réseau du navigateur, puis refaites la multiplication. Si le total d'une page dépasse quelques mégaoctets, commencez par là.

Sources

• web.dev, Web Vitals : définitions officielles et seuils du LCP (2,5 s), de l'INP (200 ms) et du CLS (0,1).
• Google Search Central, Core Web Vitals et résultats de recherche : Google recommande de bons Core Web Vitals, alignés sur ce que ses systèmes de classement récompensent, sans en faire une garantie de position.