Comment nous avons réduit le temps de chargement d’un site à moins d’une seconde
La vitesse n’est pas une métrique de vanité — elle influence le positionnement et les revenus. Voici le travail précis de performance que nous effectuons sur chaque build, dans l’ordre qui importe le plus.
La plupart des sites web lents ne le sont pas pour des raisons mystérieuses. Ils sont lents à cause d’une poignée de problèmes prévisibles qui s’accumulent — et ils se résolvent dans un ordre prévisible. Lorsqu’un client s’adresse à nous avec un temps de chargement de trois secondes, nous avons rarement besoin d’astuces exotiques. Nous avons besoin de discipline.
C’est la même liste de contrôle que nous appliquons pour chaque projet de performance, à peu près par ordre de priorité. Chaque étape est peu coûteuse par rapport à son impact, et la plupart des sites semblent considérablement plus rapides après les trois premières.
Mesurer avant de toucher à quoi que ce soit
Vous ne pouvez pas améliorer ce que vous ne mesurez pas, et vous ne pouvez certainement pas prouver d’amélioration sans point de référence. Nous commençons chaque projet avec des données de terrain, et pas seulement des scores de laboratoire.
- Laboratoire — Lighthouse et WebPageTest pour un aperçu contrôlé et reproductible.
- Terrain — mesures des utilisateurs réels (CrUX / RUM) pour ce que les gens vivent réellement.
- Budget — un plafond strict par route, afin que les régressions soient détectées dans la CI, pas en production.
Un score de laboratoire de 100 ne signifie rien si vos utilisateurs réels utilisent des téléphones de milieu de gamme et des réseaux instables. Optimisez pour le terrain.
Éliminer les ressources qui bloquent le rendu
Le gain le plus important sur la plupart des sites consiste à sortir le CSS et le JavaScript du chemin critique. Le navigateur ne peut pas effectuer le rendu tant qu’il n’a pas fini d’analyser les ressources qui bloquent le rendu — donc moins il y en a, plus tôt quelque chose s’affiche.
// différer tout ce qui n'est pas critique
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Intégrez en ligne la petite quantité de CSS nécessaire pour le premier viewport, puis chargez le reste de manière asynchrone. Différez les scripts non critiques. L’objectif est d’obtenir un premier rendu qui n’attend rien dont il n’a pas absolument besoin.
Traiter les images comme un budget
Les images sont généralement l’élément le plus lourd d’une page, et le plus facile à rater. Trois règles couvrent quatre-vingt-dix pour cent des cas :
- Servez des formats modernes — AVIF ou WebP — avec une solution de repli.
- Redimensionnez les images à leurs dimensions d’affichage ; ne livrez jamais un hero de 3000px dans un emplacement de 600px.
- Chargez en différé tout ce qui se trouve sous la ligne de flottaison, et réservez de l’espace pour éviter les décalages de mise en page.
Mettre en cache à la périphérie
Une fois la page allégée, la question suivante est de savoir à quelle vitesse les octets atteignent l’utilisateur. Un CDN avec des en-têtes de cache judicieux transforme un trajet de 600 ms vers l’origine en un accès à l’edge de 30 ms. Pour le contenu dynamique, stale-while-revalidate vous offre des réponses instantanées tout en actualisant en arrière-plan.
La performance est une fonctionnalité. Nous la budgétisons de la même manière que n’importe quelle autre partie du build.
Le résultat
Sur le projet qui a inspiré cet article, la page d’accueil est passée d’un largest contentful paint de 3,1s à 0,9s, et les conversions organiques ont augmenté de manière mesurable au cours du mois. Rien de tout cela n’était magique — juste la liste de contrôle ci-dessus, appliquée dans l’ordre.
Si votre site semble lent et que vous ne savez pas par où commencer, contactez-nous — un court audit permet généralement de cibler les deux ou trois changements qui importent le plus.