Optimiser la vitesse d'un site : un ordre de travail pratique
Le travail sur la vitesse a une forme de Pareto marquée : une poignée de correctifs explique l'essentiel de l'amélioration sur la plupart des sites, et ce sont presque toujours les images, la réponse serveur et les scripts tiers.
Ce guide couvre dans quel ordre travailler, comment mesurer si un changement a aidé, et les optimisations qui ne valent généralement pas l'effort.
Mesurez avant de changer quoi que ce soit#
Optimiser sans mesurer revient à corriger ce qui est le plus facile plutôt que ce qui est lent. Deux mesures, puis au travail.
- Récupérez des données de terrain de vrais visiteurs : le rapport Core Web Vitals dans la Search Console, ou votre propre supervision.
- Lancez un test de laboratoire sur les trois gabarits les plus importants, bridé à un mobile de milieu de gamme en 4G.
- Notez les chiffres avant de commencer. Sans référence vous ne pouvez pas dire si un changement a aidé.
- Repérez la plus grosse ressource unique et la plus grosse requête bloquante de chaque gabarit.
- Notez le Time to First Byte à part : s'il dépasse 800 ms, aucun travail front-end ne vous sauvera.
L'ordre qui paie#
À peu près par amélioration obtenue par heure d'effort, pour un site éditorial ou vitrine typique.
| Travail | Gain typique | Effort |
|---|---|---|
| Optimiser et dimensionner correctement les images | Important | Faible |
| Retirer les scripts tiers inutilisés | Important | Faible : c'est surtout une tâche politique |
| Activer le cache et un CDN | Important | Faible |
| Corriger le CSS et le JS bloquant le rendu | Moyen à important | Moyen |
| Réduire le paquet JavaScript | Moyen à important | Moyen à élevé |
| Corriger les requêtes de base de données lentes | Important là où cela s'applique | Moyen |
| Optimiser le chargement des polices | Moyen | Faible |
| Minifier et compresser les ressources texte | Faible | Faible : généralement déjà actif |
| Micro-optimiser les sélecteurs CSS | Négligeable | Ne vaut pas la peine |
Les images : généralement le plus grand gain#
Sur la plupart des sites, les images représentent l'essentiel du poids de page, et la plupart sont servies plusieurs fois plus grandes que ce qui est affiché. C'est la plus grande amélioration bon marché disponible.
- Servez du WebP ou de l'AVIF ; les deux sont largement pris en charge et généralement 25 à 50 % plus légers que le JPEG à qualité équivalente.
- Générez plusieurs tailles et utilisez srcset avec sizes pour que les mobiles téléchargent des fichiers de taille mobile.
- Ne servez jamais une image de 2000 px dans un emplacement de 400 px : cette seule erreur est extrêmement courante.
- Chargez en différé tout ce qui est sous la ligne de flottaison, et rien au-dessus.
- Automatisez-le dans le build ou dans le CMS. Les images optimisées à la main cessent de l'être dès que quelqu'un d'autre en téléverse une.
- Retirez les métadonnées ; l'EXIF d'appareil photo peut peser des dizaines de kilooctets par fichier.
L'automatisation est le point clé. Une passe d'optimisation ponctuelle se dégrade en quelques mois à mesure que du contenu est ajouté, et personne ne le remarque avant que le poids de page ait doublé.
Scripts tiers et serveur#
Ce sont les deux domaines où le problème est généralement organisationnel plutôt que technique : personne n'est responsable du gestionnaire de balises, et personne n'est responsable de la décision d'hébergement.
| Problème | Que faire |
|---|---|
| Gestionnaire de balises avec des balises inconnues | Auditer chaque balise ; supprimer tout ce que personne ne peut justifier |
| Widget de chat chargé sur chaque page | Charger à l'interaction, ou seulement là où le support est utile |
| Plusieurs outils de statistiques | N'en garder qu'un ; chacun est un script complet et une connexion |
| Script de test A/B bloquant le rendu | Le passer côté serveur, ou accepter un clignotement et le charger en async |
| TTFB lent en hébergement mutualisé | Ajouter un cache de page complète ; monter d'offre si cela persiste |
| Requêtes de base de données non mises en cache | Mettre en cache les coûteuses ; ajouter des index pour les fréquentes |
| Pas de CDN | En ajouter un : c'est le correctif de latence globale le moins cher qui existe |
Les scripts tiers sont la source la plus fiable de ralentissements inexpliqués, car ils changent sans vous prévenir et échappent à votre processus de déploiement.
Questions fréquentes
Quel est un bon temps de chargement ?
Les cibles utiles sont les seuils des Core Web Vitals plutôt qu'un chiffre unique de chargement : LCP sous 2,5 secondes et Time to First Byte sous 800 ms. Le temps de chargement total est une mauvaise mesure car une page peut être utilisable bien avant que chaque ressource soit terminée, et inutilisable bien avant cela sur un appareil lent.
Un site plus rapide augmente-t-il les conversions ?
En général oui, et l'effet est le plus fort là où les pages sont actuellement lentes et où les visiteurs sont sur des réseaux mobiles. Le gain de trois secondes à deux est bien plus grand que d'une seconde et demie à une. Si votre site est déjà rapide, investissez l'effort dans le contenu et la clarté : le retour est meilleur.
Les extensions de cache règlent-elles tout ?
Elles règlent bien une chose réelle — le travail serveur répété pour la même page — et elles peuvent créer de nouveaux problèmes, en particulier avec les utilisateurs connectés, les paniers et les formulaires. Elles ne font rien contre les images surdimensionnées et les scripts tiers, qui sont généralement les problèmes plus importants. Utiles, pas suffisantes.
Le rendu côté serveur vaut-il la peine pour la vitesse ?
Si vos pages ne sont aujourd'hui rendues que dans le navigateur, oui : le rendu côté serveur ou la génération statique supprime un aller-retour complet avant l'apparition du contenu, et cela aide l'indexation par la même occasion. Si vos pages sont déjà du HTML rendu côté serveur, la question ne se pose pas : vous avez déjà le bénéfice.
optimisation vitesse sitevitesse de pageperformance site weboptimisation des imagesmise en cachecdn
