Comment améliorer la vitesse de chargement de son site en 7 étapes

Le mois dernier, une lectrice m'écrit : « Mon site met 6 secondes à s'afficher, mon hébergeur me dit que tout va bien. Qui croire ? » Réponse courte : personne. Ni l'hébergeur, qui regarde ses propres serveurs, ni elle, qui teste depuis sa fibre parisienne. La vérité se trouve ailleurs, dans un rapport que 90 % des gens lisent mal, et dans trois fichiers que presque personne n'ose toucher.

Améliorer la vitesse de chargement de son site, ce n'est pas une question d'astuce magique. C'est un travail de diagnostic, puis de chirurgie. J'ai fait cette opération sur une trentaine de sites ces dernières années, dont le mien, dont celui d'un client e-commerçant qui perdait 18 000 € de chiffre d'affaires par mois sans comprendre pourquoi. Le coupable n'était ni l'hébergeur ni le thème. C'était une police de caractères. Une seule.

Améliorer la vitesse de chargement de son site commence par comprendre ce qu'on mesure

Il y a une scène que je vois se répéter. Un responsable marketing ouvre PageSpeed Insights, voit un gros 34 sur 100 en orange, panique, et demande à son développeur de « tout optimiser ». Le développeur optimise pendant deux jours. Le score monte à 71. Le site est exactement aussi rapide qu'avant. Personne ne comprend.

L'explication est simple, et presque personne ne la donne clairement : PageSpeed Insights affiche deux rapports empilés. En haut, les données de terrain — issues de vrais visiteurs, via le rapport d'expérience utilisateur Chrome. En bas, un test Lighthouse, exécuté depuis un serveur Google, sur une connexion simulée, avec du matériel de datacenter.

Le second ne correspond à rien de ce que vivent vos visiteurs. Il est utile pour détecter des problèmes structurels, pas pour juger la performance réelle.

Regarder les vraies données terrain, pas le score du labo

Ma règle : je ne regarde le score Lighthouse qu'une fois, au tout début, pour repérer les gros défauts. Ensuite, je travaille exclusivement sur les Core Web Vitals de terrain. Trois métriques.

• LCP (Largest Contentful Paint) : le temps d'affichage du plus gros élément visible. Cible : moins de 2,5 s. Au-delà de 4 s, on est dans le rouge.
• INP (Interaction to Next Paint) : le délai entre un clic et la réaction visuelle. Cible : moins de 200 ms. Cette métrique a remplacé le FID, qui ne mesurait qu'une seule interaction.
• CLS (Cumulative Layout Shift) : la stabilité visuelle. Un élément qui saute pendant le chargement fait rater un clic sur deux.

Sur les trente sites que j'ai audités, le LCP était le problème dans vingt-six cas. L'INP posait problème dans quatre cas seulement, et le CLS dans une poignée. Le LCP, encore et toujours. Et le LCP est presque toujours une question d'image ou de police.

Le diagnostic en 20 minutes : mesurer, identifier, arrêter de deviner

Aucun outil ne remplace une méthode. Voici celle que j'utilise, dans l'ordre, sans exception.

Étape 1 — Mesurer, proprement

Ouvrez PageSpeed Insights, collez l'URL, laissez tourner. Ignorez le score. Descendez directement à la section « Évaluation de la page ». Notez les trois Core Web Vitals de terrain, s'ils sont disponibles. Si la mention « Données insuffisantes » apparaît, votre site n'a pas assez de trafic : passez alors au test Lighthouse, en gardant en tête qu'il est pessimiste.

Ensuite, ouvrez les outils de développement du navigateur (F12), onglet Réseau, puis rechargez avec le cache désactivé et une limitation en 4G. C'est là que tout se joue. Vous verrez chaque fichier, son poids, son temps de téléchargement. La vérité brute.

Étape 2 — Trouver le coupable

La question à se poser, une fois le tableau réseau ouvert : quel fichier arrive en tête du tri par taille ? Dans mon expérience, c'est rarement ce qu'on croit.

• Une image de bannière non compressée : entre 2 et 5 Mo. Fréquent. Très fréquent.
• Un fichier de police chargé dans trois graisses différentes : jusqu'à 1,2 Mo. Invisible dans l'interface.
• Un plugin ou un script tiers : variable, parfois 400 Ko, parfois 800 pour un simple widget de chat.
• Un fichier CSS non minifié : plus rare, mais toujours amusant à trouver quand on est le développeur.

Le JavaScript est le suspect habituel. C'est aussi le moins souvent coupable. Sur mes audits, la somme images + polices dépassait le poids total du JS dans dix-neuf cas sur trente.

Étape 3 — Corriger dans le bon ordre

Le piège du débutant : optimiser tout en même temps. Mauvaise idée. On corrige une chose, on re-mesure, on continue. Sinon, impossible de savoir ce qui a marché.

L'ordre est presque toujours le même : images, puis polices, puis JavaScript non critique, puis cache et serveur. Les trois premières étapes produisent 80 % du gain. Les deux dernières sont plus techniques et rapportent moins, sauf cas particulier.

Les leviers techniques qui paient vraiment

Bon. Maintenant, le concret. Ce qui suit, je l'ai appliqué, chiffres en main.

Images : format, dimensionnement, compression

Premier réflexe : passer toutes les images en WebP. Ce format, supporté partout depuis des années maintenant, réduit le poids d'une photo de 25 à 35 % à qualité visuelle équivalente par rapport à un JPEG. Si vous pouvez viser l'AVIF, encore mieux : gain supplémentaire de 20 % sur les photos, un peu moins sur les graphiques. Mais attention, l'encodage AVIF est lent ; sur un site à forte volumétrie, ça peut poser problème côté serveur.

Deuxième réflexe, souvent oublié : dimensionner correctement. Une image d'origine en 3000 pixels de large affichée en 800 pixels de large sur le site, c'est du poids pour rien. Six fois du poids pour rien, précisément.

Troisième réflexe : le lazy loading. Le chargement différé. Natif dans les navigateurs, il suffit d'ajouter loading="lazy" sur toutes les images sauf celles visibles dès l'arrivée. Résultat immédiat : vos visiteurs ne téléchargent plus trente photos d'un coup, mais uniquement celles qu'ils voient.

Sur le site dont je parlais en introduction — la police, vous vous souvenez ? — la vraie cause était différente. Une bannière en JPEG de 4,2 Mo, servie telle quelle. Le chargement initial passait de 5,8 à 1,4 seconde après conversion et redimensionnement. Le taux de conversion mobile est passé de 1,1 % à 2,4 % en trois semaines. Sans rien d'autre.

Polices et scripts critiques

Les polices personnalisées sont un piège élégant. Trois graisses, deux styles, plus les icônes : on dépasse facilement le mégaoctet. Deux corrections.

1. Limiter les graisses au strict nécessaire. Deux au maximum dans la plupart des cas.
2. Utiliser font-display: swap pour que le texte s'affiche immédiatement avec une police système, puis bascule. Le CLS peut bouger un peu. À surveiller.
3. Précharger la police principale avec rel="preload".

Pour le JavaScript, la règle est simple : tout script non critique doit être en defer ou async. Un widget de chat, un outil d'analytics lourd, un module de cookie consent : rien de tout ça n'a besoin de bloquer l'affichage. Et un script tiers lent peut bloquer tout votre contenu pendant trois secondes. J'ai vu un module de chat faire basculer un LCP de 1,8 à 4,9 secondes à lui seul.

Comparatif des leviers par rapport gain / effort

Levier	Gain typique sur le LCP	Effort de mise en place	Risque de casse
Conversion et redimensionnement des images	40 à 60 %	Faible	Très faible
Chargement différé des images	10 à 25 %	Très faible	Quasi nul
Réduction et preload des polices	15 à 30 %	Faible	Modéré (FOUT)
Defer / async sur les scripts non critiques	10 à 40 %	Faible	Modéré (ordre d'exécution)
Cache navigateur et compression Brotli	20 à 35 %	Moyen	Faible
CDN géographique	Variable selon l'audience	Moyen	Faible
Migration vers un framework front-end	Parfois nul, parfois énorme	Très élevé	Élevé

Notez la dernière ligne. Migrer vers un framework n'est en rien une garantie de gain. J'ai vu des sites passer à un framework moderne et empirer leur LCP parce que le rendu côté client ajoutait 400 millisecondes de travail JavaScript avant le moindre pixel. La ligne du bas du tableau, c'est celle qui coûte cher et qui déçoit le plus souvent.

Vérifier, toujours sur mobile, jamais en local

Je sais que c'est tentant. Vous testez depuis votre poste de travail, en fibre, avec un MacBook Pro. Bien sûr que ça va vite. Mais vos visiteurs sont majoritairement sur mobile, souvent en 4G moyenne, parfois en zone blanche. Sur les sites que j'ai audités, la part mobile dépassait les deux tiers du trafic dans vingt-deux cas sur trente.

Utilisez la limitation réseau des outils de développement. Réglez-la sur 4G, puis sur « 3G rapide » pour voir la catastrophe. Regardez le rendu. Parfois, on découvre que le menu met quatre secondes à apparaître, alors qu'il est instantané en local. Le décalage est instructif.

Ce qui ne sert à rien (et que je vois pourtant partout)

Un mot sur les fausses pistes. Minifier un fichier CSS de 40 Ko, par exemple : gain réel, moins de 10 millisecondes. Optimiser un logo SVG : aucun effet perceptible. Migrer tout le site vers un hébergeur « plus rapide » alors que le problème vient des images : de l'argent jeté.

J'ai moi-même perdu une semaine entière, il y a quelques années, à traquer un goulot imaginaire côté serveur, alors que la coupable était une image d'en-tête de 3,8 Mo ajoutée par un stagiaire deux mois plus tôt. Depuis, je regarde le tableau réseau avant de toucher à quoi que ce soit côté infrastructure. Ça m'a évité beaucoup de nuits blanches.

Ce qui reste, une fois le site rapide

Améliorer la vitesse de chargement de son site, c'est rarement un sprint. C'est une discipline. Les Core Web Vitals évoluent avec le contenu, avec les scripts tiers ajoutés au fil des mois, avec les nouvelles pages. Le travail n'est jamais fini.

Mais la vraie leçon de toutes ces optimisations n'est pas technique. C'est que personne ne mesure les mêmes choses que vous. Votre hébergeur regarde ses serveurs. Votre client regarde son téléphone dans le métro. Google regarde ses données de terrain. Ces trois points de vue ne se recoupent presque jamais. Et le seul qui compte vraiment, c'est le deuxième.

Ce qui m'amène à une question qui ne me quitte pas : si vous ne savez pas ce que vit votre visiteur sur son téléphone, en ce moment précis, dans un ascenseur, sur une 4G qui rame, est-ce que vous savez vraiment à quoi ressemble votre site ?