Comment améliorer le temps de chargement de son site web en 7 étapes

Un client m'appelle un mardi matin, paniqué : son taux de rebond a bondi de 18 points en trois semaines. Il a changé une bannière, ajouté trois scripts de tracking, refait sa page d'accueil. Rien de « grave » selon lui. Résultat : le LCP de sa page d'accueil est passé de 2,1 s à 4,7 s. Il a perdu un quart de son trafic organique. Il n'avait rien mesuré.

C'est toujours la même histoire. On me demande comment améliorer le temps de chargement de son site web, et dans 9 cas sur 10, la personne n'a jamais ouvert PageSpeed Insights. Elle veut des astuces. Elle va avoir un diagnostic d'abord. Parce que l'optimisation à l'aveugle, c'est comme changer les pneus d'une voiture qui a un problème de boîte de vitesses.

Mesurer avant d'optimiser : le réflexe qu'on saute tout le temps

Quand j'ai commencé à travailler sur la performance, je faisais exactement l'erreur inverse : j'attaquais directement. Je passais la minification, je compressais les images, je supprimais des plugins « inutiles ». Et je n'obtenais rien. Pire, une fois, j'ai cassé un carrousel parce que j'avais viré un script sans comprendre à quoi il servait.

Depuis, je commence toujours par le même rituel. Cinq minutes, pas plus.

Les trois mesures qui comptent vraiment

Le LCP (Largest Contentful Paint) mesure le temps d'affichage de l'élément le plus gros de votre viewport au chargement. C'est l'indicateur qui traduit le mieux la perception utilisateur. En dessous de 2,5 secondes, vous êtes bon. Au-dessus de 4, vous perdez des visiteurs. Entre les deux, on optimise si on veut, mais ce n'est plus critique.

Le CLS (Cumulative Layout Shift) mesure les décalages visuels. Une bannière qui apparaît, un bouton qui descend de 40 pixels au moment où l'utilisateur veut cliquer dessus. Ce n'est pas un problème de vitesse, mais ça énerve autant.

L'INP (Interaction to Next Paint) a remplacé le FID en 2024 dans les Core Web Vitals. Il mesure la réactivité aux clics et aux frappes clavier. Un site qui réagit en 200 ms paraît fluide. À 500 ms, on sent un lag.

Quelle vitesse cible pour quel type de site ?

Une boutique en ligne doit viser 2 s maximum sur mobile. Amazon l'a compris avant tout le monde et a passé des années à gratter la moitié d'une seconde. Une page e-commerce qui met 4 secondes à afficher son produit phare, c'est un panier abandonné sur deux.

Un blog ou un site vitrine peut se contenter de 2,5 à 3 s. Le visiteur lit, il n'achète pas dans la seconde.

Une application web (SaaS, dashboard) doit être réactive en interaction, mais son premier chargement peut être plus lent (3 à 4 s) si l'utilisateur reste ensuite longtemps dessus. Je préfère un tableau de bord qui met 3,5 s à s'ouvrir et qui répond à chaque action en 100 ms plutôt que l'inverse.

Les leviers qui changent vraiment quelque chose

Sur les sites que j'ai repris, le gain se concentre toujours sur les mêmes trois postes. Le reste représente des miettes.

Les images : le gisement principal, et de loin

Une photo prise à l'iPhone et posée telle quelle sur une page pèse 3 à 5 Mo. C'est absurde pour un affichage de 800 pixels de large. Si je convertis en WebP et que je redimensionne à la bonne dimension, je descends à 80-120 Ko. Un rapport de 40 pour un.

Les outils que j'utilise systématiquement :

• WebP ou AVIF pour le format. AVIF compresse mieux, mais le support a mis du temps à se généraliser. En 2026, AVIF est safe sur tous les navigateurs grand public.
• srcset et sizes pour servir une version adaptée à chaque écran. Un mobile de 390 px n'a aucune raison de télécharger une image de 2000 px.
• loading="lazy" sur tout sauf l'image du viewport initial. Attention à ne pas le mettre sur l'image LCP, ça la retarde.
• fetchpriority="high" sur l'image justement LCP. Une ligne qui grignote 200 à 400 ms.

JavaScript : le poids mort qu'on ne voit pas

Un plugin de stats installé par le service marketing, un widget de chat greffé par le support, un carrousel ajouté par le designer. Chacun pèse 100-300 Ko. Empilés, on atteint 1,5 Mo de JavaScript qui bloquent le rendu. J'ai vu des sites vitrines charger plus de code que des applications web.

La technique qui marche : ouvrir l'onglet Couverture dans DevTools. On voit immédiatement quel pourcentage de chaque fichier JS est réellement exécuté au chargement. Sur la plupart des sites WordPress, le chiffre tourne autour de 30 %. Le reste est du code chargé pour rien.

Après, on applique :

1. Différer les scripts non critiques avec defer ou async.
2. Découper les bundles pour ne charger que ce que la page utilise.
3. Virer les librairies qu'on peut écrire en 20 lignes de vanilla JS. jQuery pour un accordéon, franchement, en 2026, on arrête.

Cache et CDN : la partie qu'on oublie côté serveur

Le cache navigateur (headers Cache-Control) évite de retélécharger les ressources à chaque visite. Un visiteur qui revient sur votre site devrait recharger 10 fois moins de données que la première fois.

Le cache serveur (page cache, object cache) évite de régénérer le HTML à chaque requête. Sur WordPress, c'est la différence entre 800 ms et 80 ms de TTFB.

Le CDN, enfin, sert vos fichiers depuis un serveur proche géographiquement du visiteur. Un site hébergé à Paris répond en 40 ms à un Parisien et en 250 ms à un Tokyoïte. Avec un CDN, on tombe à 60-80 ms pour tout le monde.

Les fausses bonnes pratiques qui font perdre du temps

Il y a des conseils qu'on lit partout et qui ne servent à rien dans la vraie vie. Je les ai tous testés au moins une fois.

Minifier tout à la folie

Minifier, c'est bien. Mais les gains sur les fichiers texte sont marginaux (10-20 % sur du CSS, un peu plus sur du JS). Comparé au gain sur les images (90 %), c'est du bruit. Passez votre temps sur les images d'abord.

Activer quinze plugins de cache en même temps

J'ai déjà vu un site avec trois plugins de cache concurrents. Résultat : le serveur régénérait les pages en boucle. Le admin-ajax.php était appelé toutes les deux secondes par chacun. Tempête de CPU. Le site était plus lent avec que sans.

Tout lazy-loader (y compris ce qui doit s'afficher tout de suite)

Le lazy loading sur l'image du hero est une aberration. Le navigateur doit attendre d'avoir calculé le layout pour lancer le téléchargement de la première image visible. Une perte de 300 à 800 ms sur le LCP. Le navigateur sait déjà qu'il doit la charger, il suffit de ne pas lui mettre de bâtons dans les roues.

Un cas concret : de 4,7 s à 1,9 s en deux jours

Retour au client paniqué du début. Voilà ce qu'on a fait, dans l'ordre.

Jour 1, matin. On installe un plugin de cache serveur correctement configuré (pas trois, un seul). TTFB passe de 780 ms à 110 ms. Le LCP descend mécaniquement de 4,7 s à 3,6 s. Aucune image touchée, aucun script supprimé.

Jour 1, après-midi. Conversion des 12 images de la page d'accueil en WebP, redimensionnées aux dimensions réelles d'affichage. La plus lourde passe de 2,8 Mo à 180 Ko. LCP à 2,4 s.

Jour 2. Suppression de deux scripts de tracking que le service marketing n'utilisait plus depuis huit mois (personne ne s'en était rendu compte). Découpage d'un bundle JS bloquant. Ajout de fetchpriority="high" sur le hero. LCP final : 1,9 s.

Le taux de rebond est redescendu en dessous de son niveau initial en dix jours. On n'a pas touché au design, pas refait la structure du site, pas migré d'hébergeur. Deux jours de travail, cinq heures cumulées.

Et pour les sites avec beaucoup de JavaScript ?

Si votre site est une SPA (React, Vue, Angular côté client), la logique change. Le HTML initial est vide, tout se construit dans le navigateur. Le premier rendu peut dépasser 4 s, même sur un bon réseau.

Les pistes qui font vraiment bouger les choses :

• SSR ou SSG. Servir du HTML pré-rendu au lieu d'un <div id="root"></div> vide.
• Code splitting par route. Ne charger que le JavaScript de la page visitée, pas tout le bundle.
• Hydration partielle. React Server Components, Astro islands, ou équivalents. On n'hydrate que les composants interactifs.

Le cas typique que je vois : une SPA avec un bundle de 2,3 Mo, dont 60 % jamais exécuté sur la page d'accueil. Le découpage par route fait tomber le bundle initial à 400-500 Ko. LCP divisé par deux.

Ce qu'il faut retenir

Améliorer le temps de chargement d'un site, ce n'est pas appliquer 30 astuces dans l'ordre alphabétique. C'est identifier les deux ou trois postes qui pèsent le plus sur votre site précis, et les traiter à fond. Sur 90 % des sites que j'ai repris, ce sont les images et le cache serveur. Le reste, c'est du vernis.

Et une dernière chose : mesurez après chaque changement. Un déploiement peut améliorer une page et dégrader une autre. J'ai déjà vu une optimisation de JavaScript faire gagner 600 ms sur la page d'accueil et en perdre 400 sur une page catégorie à cause d'un script partagé. La performance, c'est un travail de jardinier, pas de plombier.

Vous avez un site qui met plus de 3 secondes à s'afficher sur mobile ? Ouvrez PageSpeed Insights maintenant. Regardez le LCP. Puis regardez votre hébergeur. Neuf fois sur dix, la réponse est dans l'une de ces deux fenêtres.