Un site rapide commence par moins de code

Distinguer une page et une application

Une page d’offre, un article, une étude de cas sont des documents : ils affichent du contenu et des liens. Un tunnel de commande, un tableau de bord, un configurateur sont des applications : ils maintiennent un état et réagissent.

Les traiter de la même façon conduit à embarquer un moteur d’interface complet pour afficher trois paragraphes. Le visiteur télécharge, analyse et exécute du code dont il ne verra jamais l’usage.

Ce que coûte un composant interactif inutile

La colonne de gauche n’est pas un retour en arrière : les éléments natifs sont accessibles au clavier, fonctionnent sans JavaScript et se comportent correctement sur les lecteurs d’écran, ce qui demande un travail considérable à reproduire.

Rendre au serveur ce qui lui appartient

Un contenu qui ne change pas d’un visiteur à l’autre n’a aucune raison d’être assemblé dans le navigateur. Le produire au moment de la construction ou sur le serveur supprime d’un coup le temps d’analyse, le temps d’exécution et la dépendance au réseau.

Limiter le nombre de décisions au chargement

Chaque test conditionnel au chargement — thème, langue, consentement, test A/B, personnalisation — ajoute une étape avant le premier affichage utile. Trois de ces mécanismes suffisent à transformer une page légère en page lente.

• Décider la langue par l’URL plutôt que par un script de détection.
• Servir le thème par défaut immédiatement, ajuster ensuite.
• Réserver l’espace du bandeau de consentement au lieu de pousser le contenu.
• Charger les tiers après le premier affichage, jamais avant.

Mesurer ce qu’on retire

Chaque suppression doit être vérifiée comme un ajout : parcours testés, comportement clavier, rendu sur mobile ancien. Retirer du code est une modification comme une autre, et les régressions y sont aussi possibles.

Le code le plus rapide est celui qu’on n’envoie pas. Le deuxième plus rapide est celui que le navigateur sait déjà exécuter sans qu’on le lui apprenne.