Vous avez investi dans un site web, peut-être même payé une agence pour le créer. Mais quand un client potentiel tape « plombier Marseille » sur son téléphone et que votre page met 4 secondes à s'afficher, il ne vous attend pas. Il appuie sur retour et appelle le concurrent dont le site s'est affiché instantanément.
La vitesse de chargement n'est pas un détail technique réservé aux développeurs. C'est un facteur direct de perte ou de gain de chiffre d'affaires. Ce guide explique pourquoi, et comment y remédier concrètement.
1. La vitesse, un enjeu business (pas juste technique)
Quand un visiteur arrive sur votre site, vous avez moins de 3 secondes pour capter son attention. Au-delà, la majorité des visiteurs quittent la page sans même lire votre premier paragraphe. C'est ce qu'on appelle le taux de rebond.
Pour un artisan, chaque visiteur perdu est un devis en moins. Imaginons que votre site reçoive 200 visites par mois. Si 40 % des visiteurs partent à cause d'un chargement trop lent, ce sont 80 personnes qui ne verront jamais vos services, vos réalisations ou votre numéro de téléphone.
À retenir : un site rapide ne vous apporte pas plus de visiteurs — il vous évite d'en perdre. C'est la différence entre un magasin dont la porte s'ouvre facilement et un magasin dont la porte coince.
Google tient aussi compte de la vitesse dans son classement, mais de façon plus étroite qu'on ne le lit partout. Il la mesure chez de vrais visiteurs, et la plupart des sites d'artisans n'en ont pas assez pour être mesurés. On y revient plus bas : ça change la façon de regarder la vitesse. Pour ce qui décide vraiment du classement local, voir notre guide SEO local.
2. Core Web Vitals : ce que Google mesure vraiment
Google ne se contente pas de mesurer « le temps de chargement » de façon globale. Il utilise trois métriques précises, appelées Core Web Vitals, pour évaluer l'expérience utilisateur sur votre site.
LCP — Largest Contentful Paint
C'est le temps que met l'élément principal de votre page (souvent le titre ou l'image héro) à s'afficher. Objectif : moins de 2,5 secondes. Au-delà, Google considère l'expérience comme dégradée.
INP — Interaction to Next Paint
C'est le délai entre le moment où le visiteur clique (sur un bouton, un lien, un menu) et le moment où la page réagit visuellement. Objectif : moins de 200 millisecondes. Un site qui « rame » quand on clique donne une impression de qualité médiocre.
CLS — Cumulative Layout Shift
C'est la stabilité visuelle de la page. Vous avez déjà vécu ça : vous êtes sur le point de cliquer sur un bouton et le contenu se décale parce qu'une image ou une pub vient de se charger. Objectif : score inférieur à 0,1.
Concret : vous pouvez vérifier les Core Web Vitals de n'importe quel site gratuitement sur PageSpeed Insights, l'outil officiel de Google.
Faites le test sur dix sites artisans concurrents dans votre ville : de nombreux sites présentent des délais d'affichage initiaux (LCP mobile) supérieurs à 4 secondes. Cette situation s'explique souvent par l'utilisation de CMS dynamiques configurés avec de multiples extensions tierces (constructeurs de pages visuels, extensions de formulaires, de cookies ou de sécurité) non optimisées. L'accumulation de ressources JavaScript et CSS alourdit la page, ce qui nuit au rendu rapide sur mobile. C'est un avantage concurrentiel pour les sites en HTML statique déployés sur CDN : le code léger s'affiche instantanément par conception.
Le détail que les guides oublient : Google mesure chez de vrais visiteurs
Les Core Web Vitals qui comptent pour le classement ne sortent pas d'un test PageSpeed. Ils viennent du Chrome UX Report (CrUX) : les temps relevés chez les vrais visiteurs qui naviguent avec Chrome, sur les 28 derniers jours.
Un site n'entre dans ce relevé qu'à partir d'un nombre minimum de visiteurs, que Google ne publie pas. Un site d'artisan l'atteint rarement : il sert quelques clients par semaine, pas des milliers de visiteurs. PageSpeed Insights l'écrit alors en haut de son rapport, à la place des mesures réelles : pas de données. Le rapport Core Web Vitals de la Search Console dit la même chose.
La conséquence est simple. Tant que votre site n'est pas mesuré, ce signal n'a rien à comparer : un site lent n'y perd rien, un site rapide n'y gagne rien. Le classement local se joue ailleurs : une page qui répond à la recherche (votre métier, votre commune), une fiche Google tenue à jour, des avis, l'ancienneté du site. Google le dit lui-même : il montre d'abord le contenu le plus pertinent, même quand l'expérience de la page est moyenne.
Nous le voyons chez nos propres clients. Prenez un laveur auto d'Île-de-France et une entreprise de services installée dans un arrondissement d'une grande ville. En octobre 2026, PageSpeed Insights n'a aucune donnée de vrais visiteurs pour leurs deux sites : ils sont trop récents pour ça. Les deux ressortent pourtant en première page de Google quand on cherche leur métier et leur commune, ou leur arrondissement. Ce n'est donc pas le signal Core Web Vitals qui les y a mis, puisque Google n'a rien mesuré. C'est une page qui dit clairement le métier, le lieu, l'adresse et les horaires. La vitesse, elle, fait que le visiteur arrivé là reste.
Alors pourquoi viser 100 ? Parce que la vitesse sert d'abord celui qui arrive sur votre site, pas l'algorithme. Avec peu de visiteurs, chacun compte double : celui qui ouvre votre page depuis sa voiture, en 4G, doit voir votre numéro tout de suite. Le jour où votre site a assez de visites pour être mesuré, il est déjà au vert, sans rien refaire. Un score PageSpeed se vérifie par n'importe qui en trente secondes : c'est une preuve de travail soigné, pas une promesse de classement. Et une page qui fait 100 se lit aussi sans peine par les robots des IA (on y vient).
3. Vos clients vous cherchent depuis leur téléphone
La grande majorité des recherches locales se font depuis un smartphone. Un propriétaire qui constate une fuite le dimanche soir ne va pas allumer son ordinateur — il sort son téléphone et cherche « plombier urgence » depuis son canapé.
Sur mobile, les contraintes sont plus fortes : la connexion peut être en 4G, l'écran est petit, et la patience est encore plus limitée. Un site qui charge en 1,5 seconde sur fibre peut mettre 5 secondes sur un réseau mobile moyen.
C'est pourquoi Google utilise la version mobile de votre site comme référence pour le classement (c'est le « mobile-first indexing »). Votre site doit être rapide et lisible d'abord sur téléphone, ensuite sur desktop.
4. Site lent vs site rapide : la différence concrète
Voici ce qui se passe, en pratique, quand un client potentiel arrive sur votre site.
Le visiteur voit un écran blanc pendant plusieurs secondes
Il appuie sur retour avant d'avoir vu quoi que ce soit
S'il a assez de visiteurs pour être mesuré, il peut perdre des places dans Google
Le formulaire de contact ne se charge pas correctement
Sur mobile, la page « saute » pendant le chargement
Le contenu apparaît instantanément
Le visiteur voit immédiatement vos services et votre numéro
Le jour où Google le mesure, il est déjà au vert
Le bouton « Appeler » est accessible en une seconde
L'expérience est fluide et professionnelle
La vitesse envoie un signal inconscient au visiteur : un site rapide inspire confiance, un site lent donne l'impression d'un service peu professionnel. C'est injuste, mais c'est mesurable.
Un site artisan rapide par défaut
Les sites générés par Sitigo sont en HTML statique pur — pas de CMS, pas de base de données. Score PageSpeed cible : 100/100 par défaut.
Créer mon site — 69 € HTPrix hors taxes. Service réservé aux professionnels enregistrés : Sitigo ne facture aucune TVA, le client assujetti l'autoliquide. Détail
5. WhatsApp et nouveaux modes de contact
La vitesse ne concerne pas seulement le chargement de la page. Elle concerne aussi la rapidité avec laquelle un visiteur peut vous contacter.
Beaucoup de clients hésitent à appeler un artisan à froid, surtout le soir ou le week-end. Ils sont pourtant prêts à envoyer un message WhatsApp avec la photo de leur problème.
Chez les jeunes adultes, cette réticence a été mesurée. Au Royaume-Uni, 61 % des 18-34 ans disent préférer recevoir un message plutôt qu'un appel, et près d'un quart disent ne jamais décrocher (enquête Opinium pour Uswitch, 2 000 adultes, avril 2024). Six sur dix : la majorité d'une génération qui arrive à l'âge de ses premiers travaux. L'enquête parle des appels reçus, pas des appels passés, mais le sens est le même : l'écrit passe d'abord.
Google en a même fait un produit. Aux États-Unis, depuis juillet 2025, son moteur propose d'appeler une entreprise locale à la place de l'internaute, pour demander un prix ou une disponibilité (TechCrunch). L'objectif, résume le site : obtenir l'information sans avoir à décrocher soi-même. Rien n'est annoncé en France. Mais quand Google construit un robot pour éviter un coup de fil, c'est que le coup de fil freine.
Pourquoi WhatsApp fonctionne pour les artisans
Zéro friction. Le client clique, envoie une photo de la fuite ou du mur à rénover, et attend votre réponse. Pas de formulaire à remplir, pas d'attente téléphonique, pas de boîte vocale.
Le lead de 21h. Vos clients consultent votre site le soir après le travail. Ils ne vont pas appeler à cette heure, mais ils sont prêts à laisser un message écrit. Un bouton WhatsApp visible capte ces demandes que vous perdriez autrement.
La photo vaut mille mots. Un client qui envoie une photo de sa panne par WhatsApp vous donne plus d'informations utiles qu'un formulaire de contact classique. Vous pouvez évaluer le travail, préparer votre intervention et répondre avec un devis estimé.
En pratique : un bouton WhatsApp sur votre site n'exclut pas le téléphone. Il ajoute un canal supplémentaire qui capte les clients qui n'auraient pas appelé.
Et si vous ne voulez pas de WhatsApp ? Vous décidez
Chez Sitigo, l'artisan est roi. WhatsApp est un atout pour beaucoup, mais ce n'est pas une obligation : c'est votre site, et vous gardez la main sur chaque bouton. Si vous préférez ne proposer que l'appel téléphonique, ouvrez votre espace client Mon site, section « Bouton flottant », et choisissez « Téléphone seul » : deux clics et le bouton WhatsApp disparaît — tout aussi vite remis si vous changez d'avis. Vous pouvez aussi opter pour « WhatsApp seul » ou « Les deux », selon ce qui vous ressemble. Aucune manipulation technique, aucun délai.
6. CMS dynamique vs Site statique
La majorité des sites d'artisans sont construits avec un CMS (système de gestion de contenu) dynamique comme WordPress. C'est une architecture puissante, mais elle présente des contraintes différentes de celles du statique.
Comment fonctionne un CMS dynamique
À chaque visite, le serveur doit interroger une base de données, assembler la page, charger les extensions d'affichage, puis envoyer le résultat au navigateur. D'après les relevés publics de HTTP Archive, qui analyse chaque année des millions de pages réelles, la page médiane d'un site WordPress pèse 2 894 Ko sur mobile, contre 2 164 Ko toutes technologies confondues. L'essentiel de ce poids ne vient pas du texte : il vient des extensions, qui apportent chacune leurs styles et leurs scripts sur toutes les pages du site, y compris celles qui ne s'en servent pas.
Comment fonctionne un site statique
Un site statique en HTML pur est un ensemble de fichiers prêts à l'emploi. Quand un visiteur le demande, le serveur l'envoie directement, sans calcul de page ni base de données à charger en temps réel, garantissant des temps de réponse minimaux.
Ce que ça pèse vraiment, mesuré
Nous avons relevé au navigateur, sur un mobile simulé, ce que télécharge la page d'accueil de trente-six sites d'artisans sous WordPress. Le code de la page — le document, ses feuilles de style, ses scripts — y pèse 473 Ko en valeur médiane, répartis sur une quarantaine de requêtes, dont 301 Ko de JavaScript et 95 Ko de feuilles de style réclamées en quatorze fichiers distincts. Sur un site Sitigo, le même code pèse une cinquantaine de kilo-octets, en une douzaine de requêtes, sans aucune feuille de style externe : elle est écrite dans la page.
Le détail le plus parlant tient dans une seule mesure : sur ces sites, neuf dixièmes des styles téléchargés ne servent jamais à la page qui les demande. Ce n'est pas un défaut de réglage, c'est le fonctionnement normal d'un système d'extensions : un site de cinq pages télécharge la mise en forme d'un carrousel, d'une boutique et d'un formulaire en plusieurs étapes qu'il n'affichera jamais.
Le JavaScript inutile coûte deux fois
Tous les kilo-octets ne se valent pas. Une image se télécharge puis s'affiche ; un script, lui, doit être exécuté, et le téléphone ne fait rien d'autre pendant ce temps. C'est pour cette raison que le JavaScript est la charge la plus chère d'une page : il se paie une première fois sur le réseau, une seconde fois sur le processeur.
Mesuré sur un mobile d'entrée de gamme, ces mêmes sites consacrent plusieurs secondes de calcul à exécuter leurs scripts — jusqu'à vingt secondes pour le plus lourd du lot — là où un site Sitigo y passe deux dixièmes de seconde. Ce sont des secondes pendant lesquelles la page ne répond pas au doigt qui appuie sur un bouton : c'est exactement ce que mesure l'INP, l'un des trois signaux Core Web Vitals de Google, et c'est aussi de la batterie.
La question à se poser n'est donc pas « mon site a-t-il du JavaScript ? » mais « à quoi sert celui qu'il charge ? ». Un compteur de visites, un widget d'avis, une animation d'apparition et trois bibliothèques dont une seule est utilisée : chacun paraît anodin, et ensemble ils font la différence entre une page qui répond tout de suite et une page qui hésite.
Vérifiez-le vous-même. Ouvrez votre site, appuyez sur F12, onglet Réseau, puis rechargez la page : le nombre de requêtes et le total transféré s'affichent en bas. Aucune connaissance technique n'est nécessaire, et la comparaison marche sur n'importe quelle adresse.
Photos de chantier : le piège du smartphone et la compression automatique
Après les scripts, le deuxième écueil classique sur les sites d'artisans vient des photos de réalisations. Vous photographiez votre chantier terminé — une salle de bains posée, une toiture refaite, une terrasse — directement avec votre smartphone. Une photo prise avec un téléphone récent pèse couramment entre 4 et 10 Mo, avec une définition native de plus de 4 000 pixels de large.
Sur un CMS classique, quand vous déposez ces clichés dans votre galerie ou sur votre page d'accueil, ils sont souvent stockés et servis tels quels. Résultat : un client potentiel qui ouvre votre site depuis son téléphone en 4G doit télécharger 20 à 30 Mo rien que pour regarder trois réalisations. Le temps d'affichage de l'image principale (LCP) s'effondre à 6 ou 8 secondes, la navigation se fige, et le visiteur repart. Pour contourner ce problème sur WordPress, il faut soit redimensionner chaque photo à la main sur un ordinateur avant l'envoi, soit installer une extension d'optimisation (souvent payante avec un abonnement mensuel au quota d'images).
Chez Sitigo, le traitement est automatique. Quand vous déposez une photo depuis votre espace client Mon site, votre navigateur la prépare avant même l'envoi : deux tailles (1 200 pixels sur le plus grand côté pour l'ordinateur, 600 pour le téléphone), chacune en JPEG et en WebP, plus une version AVIF gardée seulement quand elle pèse moins que le WebP. Le fichier brut ne part pas : une photo de 8 Mo devient une image à la taille de l'écran qui l'affiche, une petite fraction du fichier d'origine. Si votre navigateur n'y arrive pas, le serveur prend le relais et compresse lui-même. Au-delà de 8 millions de pixels, il refuse la photo avec un message qui dit quoi faire, plutôt que de servir un fichier brut. Vos réalisations restent nettes, la page reste légère sur smartphone, sans manipulation technique et sans abonnement d'optimisation.
C'est aussi un avantage sur la sécurité. Pas de base de données active sur le serveur web signifie moins de risques d'injections ou de failles SQL de sécurité à surveiller, simplifiant l'exploitation au quotidien.
Enfin, c'est plus écologique. Moins de calcul serveur = moins d'énergie consommée = moins de CO₂ émis par chaque visite.
Le fonctionnement de ce modèle, et la raison pour laquelle il restait hors de portée d'un artisan jusqu'à récemment, sont détaillés dans notre guide sur le site HTML pur avec espace client.
7. Tester votre site en 30 secondes
Google met à disposition un outil gratuit pour mesurer la performance de n'importe quel site : PageSpeed Insights.
Comment lire les résultats
Le score va de 0 à 100. Voici l'interprétation :
90–100 (vert) : excellent. Votre site offre une expérience rapide et fluide. Ce score de laboratoire n'est pas un critère de classement en soi : Google s'appuie sur les mesures de vrais visiteurs (qu'un petit site n'a souvent pas en nombre suffisant), et un bon résultat ne garantit pas la première place.
50–89 (orange) : améliorable. Votre site fonctionne mais perd des visiteurs par rapport à un concurrent mieux optimisé.
0–49 (rouge) : problématique. Votre site offre une expérience frustrante sur mobile, et à pertinence égale un concurrent plus rapide peut passer devant vous.
Testez aussi vos concurrents. Allez sur PageSpeed Insights, entrez l'URL du site d'un concurrent dans votre ville. Si son score est nettement meilleur que le vôtre, ses visiteurs attendent moins que les vôtres, et c'est un argument de moins pour vous.
Les 4 scores à surveiller
PageSpeed Insights affiche quatre scores : Performance (la vitesse), Accessibilité (utilisabilité pour tous), Bonnes pratiques (sécurité et standards web), et SEO (les bases du référencement). L'idéal est d'avoir les quatre au vert.
Attention au piège Ordinateur vs Mobile : beaucoup d'agences ou d'éditeurs affichent un score PageSpeed de 100/100 mesuré sur la version Desktop (Ordinateur). Sur un grand écran avec la fibre et un processeur puissant, atteindre 100 en HTML pur est relativement aisé. Mais Google ne classe désormais les sites que selon leurs critères Mobile (Mobile-First Indexing). Décrocher un 100/100 sur mobile — avec le processeur bridé et la connexion 4G simulés par Google — exige une optimisation chirurgicale (CSS critique inliné, polices WOFF2 préchargées, WebP optimisés, zéro script bloquant), même en HTML pur et même assisté par l'IA.
8. Vitesse et référencement par l'IA
Les moteurs de recherche évoluent. En 2026, les IA intégrées à Google, Bing et d'autres moteurs génèrent des réponses directes aux questions des internautes. Quand quelqu'un demande à l'IA « quel électricien recommander à Lyon ? », elle sélectionne les sources les plus fiables pour construire sa réponse.
Les robots qui nourrissent ces IA ne lisent pas votre site comme un visiteur. Une étude de Vercel portant sur des centaines de millions de passages de robots l'a mesuré : ceux de ChatGPT et de Claude téléchargent bien les scripts, mais ne les exécutent pas. Ils ne lisent que le HTML livré au départ. Un texte, une liste de services ou un numéro qu'un script affiche après coup leur reste invisible.
Ces IA ne lisent pas votre score PageSpeed. Mais un 100 dit quelque chose de la page. Il s'obtient rarement avec une page que des scripts fabriquent sur place : le texte est là dès la première lecture. Les scores Accessibilité et SEO vérifient le reste : des titres dans l'ordre, des images décrites, une langue déclarée, des liens lisibles. PageSpeed contrôle même désormais le fichier destiné aux IA (voir notre guide être cité par ChatGPT). Une page propre pour le visiteur l'est aussi pour le robot : il lit tout du premier coup, et comprend ce que vous faites et où.
C'est une condition, pas une garantie : une page bien lisible retire une raison d'être mal compris ou écarté, elle ne promet pas d'être cité. Ce qui fait citer un artisan reste le fond : des informations précises sur son métier, sa zone et ses prestations (voir notre guide SEO local).
PageSpeed cible 100/100, sans effort
HTML statique, hébergé sur CDN mondial, pas de CMS à maintenir. Sitigo génère un site artisan optimisé pour la vitesse, le SEO local et les Core Web Vitals.
Créer mon site — 69 € HTQuestions fréquentes
Comment savoir si mon site est trop lent ?
Testez-le gratuitement avec Google PageSpeed Insights ou Lighthouse : entrez votre adresse et vous obtenez une note, ainsi que le temps d'affichage du contenu principal. Google considère qu'au-delà de 2,5 secondes sur mobile (l'indicateur LCP), l'expérience se dégrade. Testez toujours en version mobile et sur une connexion moyenne, pas seulement depuis votre ordinateur en fibre.
Pourquoi la vitesse compte-t-elle pour le référencement local ?
Pour deux raisons, d'inégale force. Google intègre les Core Web Vitals à son classement, mais il les mesure chez de vrais visiteurs, et un site d'artisan en a rarement assez pour entrer dans cette mesure : chez la plupart, ce signal reste muet. La raison qui pèse vraiment, c'est le visiteur. Il cherche depuis son téléphone, souvent en déplacement, et un site lent le fait repartir avant qu'il voie vos services. Tant que votre site n'est pas mesuré, la vitesse ne vous fait pas monter dans Google : elle transforme mieux les visites qu'il vous envoie.
Un site avec de belles images et des animations est-il forcément lent ?
Pas forcément. Le poids vient surtout d'images non optimisées, de scripts externes (widgets, trackers, polices lourdes) et d'un CMS surchargé d'extensions. On peut avoir un site visuellement soigné et rapide si les images sont compressées au bon format et si le code reste léger. C'est pourquoi Sitigo convertit et compresse automatiquement chaque photo uploadée par l'artisan (WebP, et AVIF quand il est plus léger, en deux tailles : ordinateur et téléphone) : vos réalisations restent nettes sans alourdir le chargement sur mobile. C'est un travail d'optimisation, pas un renoncement à l'esthétique.
Faut-il un site statique pour être rapide ?
Ce n'est pas la seule voie, mais c'est la plus simple à garder rapide. Un site statique (HTML pur, sans base de données) s'affiche directement, sans calcul serveur à chaque visite, et atteint de bonnes performances par défaut. Un site WordPress peut être rapide lui aussi, mais demande une optimisation continue (cache, extensions, hébergement) pour le rester.