Un site lent ne perd pas seulement des visiteurs : il perd des demandes de devis, des ventes et des places sur Google.
La bonne nouvelle, c’est que les causes sont presque toujours les mêmes, et que les correctifs les plus efficaces sont aussi les moins chers.
L’essentiel en 30 secondes
Un site est jugé rapide quand son contenu principal s’affiche en 2,5 secondes ou moins sur mobile, pour au moins 75 % des visites. Pour y arriver : on mesure, on allège les images, on trie les scripts, on simplifie le haut de page et on vérifie l’hébergement.
des visites mobiles abandonnées au-delà de 3 secondes de chargement.
de probabilité de rebond quand le chargement passe de 1 à 3 secondes.
Les cinq leviers, dans l’ordre où les traiter :
- 1Mesurer sur mobile, avec les indicateurs de Google
- 2Alléger les images
- 3Faire le tri dans les scripts tiers
- 4Simplifier le haut de page
- 5Vérifier l’hébergement et le cache
Mesurer sur mobile, avec les indicateurs de Google
Sur mobile, l’internaute est pressé, souvent en déplacement et sur un réseau moins stable. S’il attend, il revient aux résultats de recherche et clique sur le concurrent suivant. Et chaque seconde de plus fait partir une part de plus en plus grande des visiteurs.
Hausse du risque de rebond par rapport à une page qui charge en 1 seconde
Les trois indicateurs de Google
Google ne regarde pas un « temps de chargement » unique. Il suit trois indicateurs, les Core Web Vitals, mesurés chez de vrais visiteurs. Depuis mars 2024, l’INP a remplacé l’ancien indicateur FID.
| Indicateur | Ce qu’il mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Le temps d’affichage du plus grand élément visible | ≤ 2,5 s | 2,5 à 4 s | > 4 s |
| INP | Le délai de réaction après un clic ou une saisie | ≤ 200 ms | 200 à 500 ms | > 500 ms |
| CLS | Les décalages de mise en page au chargement | ≤ 0,1 | 0,1 à 0,25 | > 0,25 |
Testez votre page d’accueil et vos deux pages les plus visitées sur
PageSpeed Insights, en version mobile.- Notez le LCP, l’INP et le CLS des données réelles, en haut du rapport : ce sont vos repères.
Un test ponctuel simule un téléphone moyen. Les données de terrain viennent de vos vrais visiteurs, sur les 28 derniers jours : c’est sur elles que Google se fonde.
Alléger les images
C’est la cause numéro un. Exemple classique : une photo de 4 000 pixels de large et 5 Mo, affichée dans une zone de 800 pixels. Le visiteur télécharge bien plus de pixels que son écran n’en montre, et la page attend cette photo pour s’afficher.
Le format compte aussi. Selon 
Google, le WebP est 25 à 34 % plus léger que le JPEG à qualité égale ; l’AVIF l’est en général encore davantage. Le SVG reste le bon choix pour les logos et les icônes.
- Redimensionnez chaque image à sa taille d’affichage (le double pour les écrans haute densité).
- Convertissez les photos en WebP.
- Chargez en différé (
loading="lazy") les images sous le premier écran, jamais l’image principale du haut de page.
Faire le tri dans les scripts tiers
Chat en ligne, pixels publicitaires, widgets d’avis, vidéos intégrées, outils d’analyse : chacun charge son propre code, souvent depuis un autre serveur. Ensemble, ils retardent l’affichage et rendent la page plus lente à réagir au doigt.
Un site est rarement lent à cause d’un seul gros problème, mais d’une dizaine de petits ajouts que personne n’a remis en question.
- Listez les outils installés et retirez ceux que plus personne ne consulte.
- Chargez les autres après l’affichage (attribut
defer), ou au premier clic pour un chat.
Simplifier le haut de page
Le premier écran est celui que le visiteur attend. Un carrousel de cinq grandes images charge cinq images pour une seule vue, et une vidéo d’arrière-plan peut peser plus que tout le reste du site. Côté polices, trois familles en quatre graisses font douze fichiers à télécharger.
- Une image fixe bien compressée plutôt qu’un carrousel ou une vidéo.
- Une ou deux familles de polices, avec
font-display: swap. - Une place réservée pour chaque image, pour éviter les décalages de mise en page.
Vérifier l’hébergement et le cache
Le temps de réponse du serveur (TTFB) est jugé bon sous 0,8 seconde. Au-delà, rien ne peut s’afficher tant que le serveur n’a pas répondu, même sur une page parfaitement optimisée. Un hébergement avec cache et réseau de diffusion (CDN) sert les pages depuis un serveur proche du visiteur.
- Relevez le TTFB dans les données réelles de PageSpeed Insights.
- S’il dépasse 0,8 seconde alors que vos pages sont légères, activez le cache, puis envisagez un hébergement avec CDN. Sinon, ne changez rien.
Exemple concret : une page d’accueil passée au crible
Exemple illustratif. Une entreprise de rénovation reçoit la majorité de ses visites sur mobile.
Le point de départ
Sa page d’accueil pèse 6,8 Mo, lance 142 requêtes et affiche son contenu principal en 5,2 secondes. En cause : un carrousel de cinq photos en haut de page, une vidéo intégrée et deux outils de suivi que plus personne ne consulte.
Ce qui a été fait
- 1La mesure des trois pages les plus visitées, en version mobile.
- 2Les images : 38 photos redimensionnées et converties en WebP, soit 4,1 Mo de moins.
- 3Les scripts : les deux outils inutilisés retirés, le chat chargé au premier clic.
- 4Le haut de page : le carrousel remplacé par une seule photo, la vidéo lancée au clic.
Le résultat
Le design n’a pas changé. Et l’enjeu est concret : avec 2 000 visites mobiles par mois et 1 % de demandes de devis, passer à 1,2 % représente 4 demandes de plus par mois, sans un euro de publicité.
Comparer les trois façons d’accélérer son site
| Critère | Le faire soi-même | Une extension | Recommandé Sur mesure |
|---|---|---|---|
| Coût | Gratuit, hors votre temps | Gratuit ou abonnement annuel | Sur devis, une seule fois |
| Temps à y passer | Plusieurs soirées | Une heure d’installation | Un échange pour cadrer |
| Ce qui est corrigé | Ce que vous savez repérer | Compression, cache | Images, scripts, polices, haut de page, hébergement |
| Risque | Casser une fonction | Conflits avec le thème | Faible : chaque changement est mesuré |
| Idéal pour | Un petit site | Un site WordPress | Un site qui doit générer des demandes |
Questions fréquentes
Quel est un bon temps de chargement ?
Google considère qu’une page est rapide quand son contenu principal s’affiche en 2,5 secondes ou moins (LCP) pour au moins 75 % des visites.
La vitesse influence-t-elle le référencement ?
Oui, les Core Web Vitals font partie des signaux de classement de Google, mais leur poids reste plus faible que celui de la pertinence du contenu.
Mon site est rapide sur ordinateur mais lent sur mobile, pourquoi ?
Un téléphone a un processeur moins puissant et une connexion moins stable. Or Google évalue d’abord la version mobile : c’est elle qu’il faut optimiser en priorité.
Faut-il viser 100 sur 100 ?
Non. Ce qui compte pour Google, ce sont des Core Web Vitals de terrain dans le vert. Au-delà de 90, les gains se voient rarement chez vos visiteurs.
Combien de temps pour voir l’effet sur Google ?
Les données de terrain portent sur les 28 derniers jours : comptez environ un mois pour que la Search Console reflète vos progrès.
Ce qu’il faut retenir
- Sur mobile, au-delà de 3 secondes, plus de la moitié des visites sont abandonnées.
- Google juge la vitesse sur trois indicateurs : LCP, INP et CLS.
- Images, scripts tiers et haut de page expliquent la plupart des lenteurs.
- Mesurez avant et après chaque changement, toujours sur mobile.
Si vous voulez savoir où en est votre site, parlons-en.
Pour aller plus loin
- Google (DoubleClick), 2016 : part des visites mobiles abandonnées au-delà de 3 secondes.
- Google / SOASTA Research, 2017 : hausse du risque de rebond selon le temps de chargement.
Deloitte, 2020 : « Milliseconds Make Millions », effet de 0,1 seconde sur les conversions.- web.dev (Google) : seuils des Core Web Vitals.
- Google for Developers : gain de poids du format WebP.
Fondateur d’Elix Marketing. Je conçois à Dijon des sites rapides, bien référencés et pensés pour transformer les visiteurs en clients.
