L’optimisation des performances a ceci de particulier qu’elle attire immédiatement vers les détails techniques les plus fins, alors que 80 % du gain se joue sur trois ou quatre décisions très simples. Beaucoup de développeurs passent une journée sur la minification et laissent en place des images de 3 Mo. Voici l’ordre dans lequel s’y prendre.
Mesurer avant de toucher à quoi que ce soit
Première règle : ne modifiez rien tant que vous n’avez pas de point de départ chiffré.
Les outils de mesure gratuits vous donnent trois indicateurs qui comptent réellement le délai d’affichage du contenu principal, la réactivité aux premières interactions, et la stabilité visuelle pendant le chargement. Ce sont ces trois-là que Google évalue, et ils se mesurent sur mobile.
Attention à un piège dans lequel tombent beaucoup d’équipes : les scores de laboratoire, obtenus en conditions simulées, ne reflètent pas toujours l’expérience réelle. Les données de terrain, collectées auprès de vrais visiteurs, sont plus lentes à s’accumuler mais nettement plus fiables. Le site www.julienjimenez.eu insiste sur cette distinction, et elle évite de gaspiller des semaines à optimiser un score de test qui ne correspond à rien de vécu.
Les images : la moitié du problème, la moitié du gain
C’est presque toujours le premier poste, et de très loin.
- Le format. WebP ou AVIF réduisent le poids de 30 à 60 % à qualité équivalente. La compatibilité navigateur n’est plus un obstacle.
- Les dimensions. Servir une image de 3000 px de large dans un emplacement de 600 px gaspille 90 % des octets transférés. Générez des variantes et laissez l’attribut
srcsetfaire le tri. - Le chargement différé. Les images situées hors de l’écran initial ne doivent pas être chargées immédiatement. L’attribut
loading="lazy"suffit dans la plupart des cas sauf pour l’image principale visible d’emblée, qu’il faut au contraire charger en priorité. - Les dimensions déclarées. Précisez toujours largeur et hauteur : c’est ce qui empêche la page de sauter pendant le chargement.
Le serveur et le cache
Un temps de réponse serveur supérieur à 600 ms plombe tout le reste, quelles que soient vos optimisations en aval.
Activez un cache de pages, mettez en place une mise en cache navigateur avec des durées longues sur les ressources statiques, et activez la compression Brotli ou Gzip. Un réseau de diffusion de contenu apporte un gain net dès que votre audience est géographiquement dispersée.
Vérifiez également votre base de données : sur un site un peu ancien, les requêtes non indexées et les tables gonflées expliquent souvent une lenteur qu’on attribue à tort au front-end.
Le code : CSS, JavaScript, polices
Une fois les deux postes précédents traités, on peut descendre à ce niveau.
Supprimez le CSS et le JavaScript inutilisés sur un site bâti avec un thème générique, la proportion dépasse souvent 50 %. Différez le chargement des scripts non critiques avec defer ou async. Limitez les scripts tiers : chaque outil de suivi, chaque widget, chaque bouton de partage ajoute des requêtes et du temps d’exécution.
Les polices méritent une mention à part. Limitez-vous à deux familles et aux graisses réellement utilisées, hébergez-les localement, et employez font-display: swap pour éviter le texte invisible pendant le chargement.
Savoir s’arrêter
Passer de 8 à 3 secondes change tout, pour les visiteurs comme pour le classement. Passer de 1,2 à 1,0 seconde ne change plus rien de perceptible, et coûte souvent des journées entières.
Fixez-vous un seuil raisonnable un affichage du contenu principal sous 2,5 secondes sur mobile en conditions réelles atteignez-le, puis passez à autre chose. La performance est un moyen, pas une fin.
