Approche compilateur de la performance web : le point de vue de Rich Harris

Pourquoi certaines applications web semblent lentes même sur de bons appareils

Les utilisateurs décrivent rarement la performance avec des termes techniques. Ils disent que l'app paraît lourde. Les pages mettent une fraction de seconde trop longtemps avant d'afficher quelque chose, les boutons répondent en retard, et des actions simples comme ouvrir un menu, taper dans une barre de recherche ou changer d'onglet saccadent.

Les symptômes sont familiers : un premier chargement lent (UI vide ou partiellement construite), des interactions lentes (clics qui n'arrivent qu'après une pause, défilement haché), et de longues animations ou spinners après des actions qui devraient être instantanées, comme enregistrer un formulaire ou filtrer une liste.

Beaucoup de cela vient du coût d'exécution. En termes simples, c'est le travail que le navigateur doit faire après le chargement de la page pour rendre l'app utilisable : télécharger plus de JavaScript, l'analyser, l'exécuter, construire l'UI, attacher des handlers, puis continuer à faire du travail supplémentaire à chaque mise à jour. Même sur des appareils rapides, il y a une limite à la quantité de JavaScript que l'on peut pousser dans le navigateur avant que l'expérience ne commence à ralentir.

Les problèmes de performance apparaissent aussi tard. Au début, l'app est petite : quelques écrans, données légères, UI simple. Puis le produit grossit. Le marketing ajoute des trackers, le design enrichit les composants, les équipes ajoutent de l'état, des fonctionnalités, des dépendances et de la personnalisation. Chaque changement semble inoffensif pris isolément, mais le travail total s'accumule.

C'est pourquoi les équipes commencent à regarder les idées de performance centrées sur le compilateur. L'objectif n'est généralement pas d'obtenir des scores parfaits. C'est de continuer à livrer sans que l'app ne ralentisse chaque mois.

Runtime-heavy vs compilation : l'idée de base

La plupart des frameworks frontend vous aident à faire deux choses : construire une app et maintenir l'UI synchronisée avec les données. La différence clé est le moment où la seconde partie a lieu.

Avec un framework axé sur le runtime, une grande partie du travail se produit dans le navigateur après le chargement de la page. Vous envoyez un runtime généraliste capable de gérer de nombreux cas : suivre les changements, décider ce qu'il faut mettre à jour et appliquer ces mises à jour. Cette flexibilité est pratique pour le développement, mais cela signifie souvent plus de JavaScript à télécharger, analyser et exécuter avant que l'UI soit prête.

Avec l'optimisation à la compilation, une partie de ce travail est déplacée vers l'étape de build. Au lieu d'envoyer au navigateur un ensemble de règles génériques, l'outil de build analyse vos composants et génère du code plus direct et spécifique à l'app.

Un modèle mental utile :

• Runtime-heavy, c'est comme expédier des instructions et une boîte à outils, puis assembler chez le client.
• Compilation, c'est comme expédier des pièces déjà coupées et étiquetées, pour que l'assemblage soit plus rapide.

La plupart des produits réels se situent quelque part entre les deux. Les approches compilateur-first envoient encore du code runtime (routage, fetch de données, animations, gestion d'erreurs). Les frameworks runtime-heavy reposent aussi sur des techniques au build (minification, code-splitting, rendu serveur) pour réduire le travail client. La question pratique n'est pas quel camp a raison, mais quel mix convient à votre produit.

Rich Harris et pourquoi « le framework est un compilateur » compte

Rich Harris est l'une des voix les plus claires derrière la pensée compilateur-first côté frontend. Son argument est simple : faites plus de travail à l'avance pour que les utilisateurs téléchargent moins de code et que le navigateur fasse moins de travail.

La motivation est pratique. Beaucoup de frameworks runtime-heavy envoient un moteur généraliste : logique de composants, réactivité, diffing, ordonnancement et helpers qui doivent fonctionner pour toutes les apps possibles. Cette flexibilité coûte en octets et en CPU. Même quand votre UI est petite, vous pouvez payer pour un gros runtime.

L'approche compilateur inverse le modèle. Pendant la compilation, le compilateur regarde vos composants réels et génère le code d'update DOM spécifique dont ils ont besoin. Si un libellé ne change jamais, il devient du HTML statique. Si une seule valeur change, seul le chemin de mise à jour pour cette valeur est émis. Au lieu d'envoyer une machine UI générique, vous envoyez la sortie adaptée à votre produit.

Le résultat est souvent simple : moins de code de framework envoyé aux utilisateurs et moins de travail à chaque interaction. Ça se voit particulièrement sur les appareils bas de gamme, où la surcharge runtime devient rapidement perceptible.

Les compromis existent toujours :

• Certains patterns dynamiques sont plus difficiles quand le compilateur ne peut pas les comprendre à l'avance.
• La qualité du tooling prend plus d'importance (vitesse de build, debug, source maps).
• Les conventions d'écosystème peuvent différer, ce qui affecte le recrutement et la réutilisation.
• Vous aurez peut-être toujours besoin d'helpers runtime, mais plus petits et ciblés.

Règle pratique : si votre UI est majoritairement connaissable à la compilation, un compilateur peut générer une sortie compacte. Si votre UI est très dynamique ou pilotée par des plugins, un runtime plus lourd peut être plus simple.

Ce que l'optimisation à la compilation peut améliorer en pratique

L'optimisation à la compilation change l'endroit où le travail se fait. Plus de décisions sont prises pendant le build, et moins il en reste pour le navigateur.

Un résultat visible est la réduction de JavaScript envoyé. Des bundles plus petits réduisent le temps réseau, le temps d'analyse et le délai avant que la page réponde à un tap ou un clic. Sur des téléphones milieu de gamme, cela compte plus que ce que beaucoup d'équipes imaginent.

Les compilateurs peuvent aussi générer des mises à jour DOM plus directes. Quand l'étape de build voit la structure d'un composant, elle peut produire du code qui ne touche que les nœuds DOM qui changent réellement, sans autant de couches d'abstraction à chaque interaction. Ça rend les mises à jour fréquentes plus réactives, en particulier dans les listes, tableaux et formulaires.

L'analyse à la compilation renforce aussi le tree-shaking et la suppression de code mort. Le bénéfice n'est pas seulement des fichiers plus petits : ce sont moins de chemins de code que le navigateur doit charger et exécuter.

L'hydratation est un autre domaine où les choix au build peuvent aider. L'hydratation consiste à transformer une page rendue côté serveur en page interactive en attachant des handlers et en reconstruisant assez d'état dans le navigateur. Si le build peut marquer ce qui demande de l'interactivité et ce qui n'en demande pas, vous réduisez le travail au premier chargement.

En prime, la compilation améliore souvent le scope du CSS. Le build peut réécrire les noms de classes, supprimer les styles inutilisés et réduire les fuites de styles entre composants. Cela diminue les coûts surprises au fur et à mesure que l'UI grandit.

Imaginez un tableau de bord avec des filtres et un grand tableau de données. Une approche compilateur-first peut garder le chargement initial léger, ne mettre à jour que les cellules modifiées après un clic de filtre et éviter d'hydrater des parties de la page qui ne deviennent jamais interactives.

Où les frameworks runtime-heavy ont encore du sens

Un runtime plus grand n'est pas automatiquement mauvais. Il apporte souvent de la flexibilité : des patterns décidés à l'exécution, beaucoup de composants tiers et des workflows éprouvés.

Les frameworks runtime-heavy brillent quand les règles d'UI changent souvent. Si vous avez besoin d'un routage complexe, de layouts imbriqués, de formulaires riches et d'un modèle d'état profond, un runtime mature peut faire office de filet de sécurité.

Le runtime paie la commodité

Un runtime aide lorsque vous voulez que le framework gère beaucoup pendant l'exécution de l'app, pas seulement pendant la construction. Cela peut accélérer les équipes au quotidien, même si ça ajoute une surcharge.

Les gains courants incluent un écosystème large, des patterns familiers pour l'état et le fetch de données, d'excellents outils de dev, une extension par plugins plus simple et un onboarding plus fluide quand vous recrutez dans un vivier commun.

La familiarité de l'équipe est un coût réel et un vrai avantage. Un framework légèrement plus lent que votre équipe maîtrise peut battre une approche plus rapide qui nécessite une rééducation, une discipline stricte ou des outils personnalisés pour éviter les pièges.

Quand la surcharge runtime n'est pas le goulot d'étranglement

Beaucoup de plaintes sur la lenteur ne sont pas causées par le runtime du framework. Si votre page attend une API lente, des images lourdes, trop de polices ou des scripts tiers, changer de framework ne résoudra pas le problème central.

Un tableau de bord interne derrière une authentification fonctionne souvent bien même avec un runtime plus lourd, parce que les utilisateurs sont sur des appareils puissants et que le travail est dominé par des tableaux, permissions et requêtes backend.

« Assez rapide » peut être l'objectif adapté au début. Si vous prouvez encore la valeur du produit, gardez une vitesse d'itération élevée, fixez des budgets basiques et n'introduisez la complexité compilateur-first que quand vous avez des preuves que cela importe.

Performance vs vitesse d'itération : le vrai compromis pour les équipes

La vitesse d'itération est le temps jusqu'au feedback : à quelle vitesse quelqu'un peut changer un écran, le lancer, voir ce qui casse et corriger. Les équipes qui gardent cette boucle courte livrent plus souvent et apprennent plus vite. C'est pourquoi les frameworks runtime-heavy peuvent sembler productifs au départ : patterns familiers, résultats rapides, beaucoup de comportements intégrés.

Le travail de performance ralentit cette boucle s'il est fait trop tôt ou trop largement. Si chaque PR tourne en débat de micro-optimisation, l'équipe cesse de prendre des risques. Si vous construisez une pipeline complexe avant de savoir ce que sera le produit, les gens passent du temps à lutter contre le tooling au lieu de parler aux utilisateurs.

L'astuce est de s'accorder sur ce que « suffisant » signifie et d'itérer dans cette boîte. Un budget de performance vous donne cette boîte. Il ne s'agit pas de courir après des scores parfaits, mais de limites qui protègent l'expérience tout en permettant le mouvement.

Un budget pratique peut inclure :

• la page devient utilisable en quelques secondes sur des téléphones milieu de gamme ;
• le JavaScript par route reste sous un plafond convenu par l'équipe ;
• les interactions clés (recherche, ajout au panier, sauvegarde) répondent rapidement ;
• aucune fonctionnalité ne peut ajouter plus qu'une petite quantité fixe de JS ou CSS.

Si vous ignorez la performance, vous payez souvent plus tard. Quand un produit grandit, la lenteur se lie aux décisions d'architecture, pas seulement à des réglages mineurs. Une réécriture tardive peut signifier geler des fonctionnalités, rééduquer l'équipe et casser des flux qui marchaient.

Les outils compilateur-first peuvent déplacer ce compromis : vous acceptez des builds un peu plus lents, mais réduisez le travail effectué sur chaque appareil, à chaque visite.

Revenez sur les budgets au fur et à mesure que le produit se confirme. Au début, protégez les bases. Quand le trafic et les revenus augmentent, serrez les budgets et investissez là où les changements déplacent de vrais indicateurs, pas l'ego.

Comment mesurer la performance sans se perdre

Les débats sur la performance deviennent confus quand personne n'est d'accord sur ce que « rapide » signifie. Choisissez un petit ensemble de métriques, écrivez-les et traitez-les comme un tableau de score partagé.

Un ensemble de départ simple :

• Temps de chargement initial (temps jusqu'au premier écran utilisable)
• Délai d'interaction (combien de temps un tap/clic semble bloqué)
• Taille du bundle (ce que le navigateur doit télécharger et analyser)
• Latence API (temps de réponse du backend)

Mesurez sur des appareils représentatifs, pas seulement sur un portable de développement. Un CPU rapide, un cache chaud et un serveur local peuvent cacher des délais qui apparaissent sur un téléphone milieu de gamme en réseau mobile moyen.

Restez concret : choisissez deux ou trois appareils qui correspondent aux vrais utilisateurs et exécutez à chaque fois le même flux (écran d'accueil, login, une tâche courante). Faites cela de façon cohérente.

Avant de changer de framework, capturez une baseline. Prenez le build actuel, enregistrez les chiffres pour les mêmes flux et gardez-les visibles. Cette baseline est votre photo « avant ».

Ne jugez pas la performance sur un seul score de laboratoire. Les outils de lab aident, mais ils peuvent récompenser la mauvaise chose (excellent premier chargement) tout en manquant ce que les utilisateurs reprochent (menus saccadés, saisie lente, délais après le premier écran).

Quand les chiffres empirent, n'improvisez pas. Vérifiez ce qui a été livré, ce qui bloquait le rendu et où le temps a été passé : réseau, JavaScript ou API.

Un cadre décisionnel étape par étape que vous pouvez réellement utiliser

Pour faire un choix calme et répétable, traitez le choix de framework et de rendu comme une décision produit. L'objectif n'est pas la meilleure techno, mais le bon équilibre entre performance et rythme dont votre équipe a besoin.

1. Définissez vos surfaces produit. Séparez pages marketing, dashboard authentifié, mobile et outils internes. Chaque surface a des utilisateurs, appareils et attentes différents.
2. Fixez un budget de performance. Choisissez 2 ou 3 nombres à protéger, comme le premier chargement sur un téléphone milieu de gamme et le temps pour une interaction clé (recherche, filtre, sauvegarde).
3. Classez vos contraintes. Soyez honnête sur ce qui importe maintenant : compétences de l'équipe, délais, SEO, règles de confidentialité des données, et où l'app doit fonctionner.
4. Choisissez une approche. Compiler-first convient quand le premier chargement et la réactivité sont non négociables. Runtime-first convient quand vous avez besoin de flexibilité maximale et d'une itération rapide. L'hybride gagne souvent : gardez les surfaces sensibles à la performance légères, et utilisez du runtime plus lourd là où il apporte clairement de la vitesse d'expérimentation.
5. Validez avec une thin slice, puis verrouillez. Construisez un flux utilisateur réel de bout en bout, mesurez-le par rapport au budget et écrivez ce que vous avez choisi et pourquoi.

Une thin slice doit inclure les parties compliquées : données réelles, auth et votre écran le plus lent.

Si vous voulez prototyper rapidement cette thin slice, Koder.ai (koder.ai) vous permet de construire des flux web, backend et mobile via le chat, puis d'exporter le code source. Cela aide à tester une route réelle tôt et à garder les expériences réversibles grâce aux snapshots et rollbacks.

Documentez la décision en langage clair, en précisant ce qui vous ferait la revoir (croissance du trafic, part mobile, objectifs SEO). Cela rend le choix durable quand l'équipe évolue.

Erreurs courantes des équipes en matière de choix de performance

Les décisions de performance foirent souvent quand les équipes optimisent ce qu'elles voient aujourd'hui, pas ce que les utilisateurs ressentiront dans trois mois.

Une erreur est de sur-optimiser dès la première semaine. Une équipe passe des jours à gagner des millisecondes sur une page qui change encore tous les jours, alors que le vrai problème est que les utilisateurs n'ont pas encore les bonnes fonctionnalités. Au début, accélérez l'apprentissage d'abord. Verrouillez les travaux de performance profonds une fois les routes et composants stabilisés.

Une autre erreur est d'ignorer la croissance du bundle jusqu'à ce que ça fasse mal. Les choses vont bien à 200 KB, puis quelques ajouts « petits » plus tard vous expédiez des mégaoctets. Une habitude simple aide : suivez la taille du bundle dans le temps et traitez les sauts brutaux comme des bugs.

Les équipes ont aussi tendance à tout rendre côté client, même quand certaines routes sont majoritairement statiques (pages pricing, docs, onboarding). Ces pages peuvent souvent être livrées avec bien moins de travail côté appareil.

Un tueur plus discret est d'ajouter une grosse bibliothèque UI pour la commodité sans mesurer son coût dans le build de production. La commodité est valide. Soyez juste clair sur ce que vous payez en JS supplémentaire, CSS supplémentaire et interactions plus lentes sur les téléphones milieu de gamme.

Enfin, mélanger les approches sans frontières claires crée des apps difficiles à déboguer. Si la moitié de l'app suppose des updates générés par compilateur pendant que l'autre moitié repose sur de la magie runtime, vous vous retrouvez avec des règles floues et des échecs confus.

Quelques garde-fous qui tiennent dans de vraies équipes :

• Fixez un budget de taille de bundle par route majeure, pas seulement pour l'app entière.
• Décidez quelles routes doivent être rapides au premier chargement et concevez le rendu autour de ça.
• Ajoutez des bibliothèques seulement après avoir vérifié leur poids en production.
• Rédigez des frontières (quelles parties sont optimisées par le compilateur, quelles parties sont runtime).
• Revenez sur les décisions après des données utilisateurs réelles, pas avant.

Un exemple réaliste : livrer un SaaS sans se mettre dans une impasse

Imaginez une équipe de 3 personnes construisant un SaaS de planification et facturation. Il a deux visages : un site marketing public (landing, pricing, docs) et un dashboard authentifié (calendrier, factures, rapports, réglages).

Sur la voie runtime-first, ils choisissent une configuration runtime-heavy parce qu'elle rend les changements UI rapides. Le dashboard devient une grosse app client avec composants réutilisables, une librairie d'état et des interactions riches. L'itération est rapide. Avec le temps, le premier chargement commence à peser sur les téléphones milieu de gamme.

Sur la voie compilateur-first, ils optent pour un framework qui pousse plus de travail à la compilation pour réduire le JavaScript client. Les flux communs comme ouvrir le dashboard, changer d'onglet et rechercher sont plus réactifs. Le compromis est que l'équipe doit être plus délibérée sur les patterns et le tooling, et que certains trucs runtime faciles ne sont pas aussi plug-and-play.

Ce qui déclenche le changement n'est presque jamais du goût. C'est la pression de la réalité : des pages plus lentes nuisent aux inscriptions, plus d'utilisateurs arrivent sur des appareils bas de gamme, des clients enterprise demandent des budgets prévisibles, le dashboard reste ouvert tout le temps et la mémoire compte, ou le support signale des lenteurs sur des réseaux réels.

Une option hybride gagne souvent. Gardez les pages marketing légères (rendu serveur ou essentiellement statique, code client minimal) et acceptez plus de runtime dans le dashboard là où l'interactivité le justifie.

En utilisant les étapes de décision : ils nomment les parcours critiques (inscription, première facture, reporting hebdo), les mesurent sur un téléphone milieu de gamme, fixent un budget et choisissent l'hybride. Par défaut compilateur-first pour les pages publiques et les composants partagés, runtime-heavy uniquement là où cela améliore clairement la vitesse d'expérimentation.

Checklist rapide et étapes suivantes pour votre produit

La façon la plus simple de concrétiser ces idées est une boucle hebdomadaire courte.

Commencez par un scan de 15 minutes : la taille du bundle augmente-t-elle, quelles routes paraissent lentes, quels sont les plus gros morceaux UI sur ces routes (tables, charts, éditeurs, cartes), et quelles dépendances pèsent le plus. Puis choisissez un goulot que vous pouvez corriger sans réécrire votre stack.

Pour cette semaine, gardez ça petit :

• Mesurez une baseline : un cold load de votre route la plus lente et une action courante.
• Fixez un budget qui correspond à votre produit.
• Corrigez un goulot (supprimez une dépendance, splittez une route, lazy-load un composant lourd, réduisez des rendus inutiles).
• Re-mesurez et notez ce qui a changé.

Pour garder les choix réversibles, tracez des frontières claires entre routes et fonctionnalités. Préférez des modules interchangeables (charts, éditeurs riche, SDKs analytics) que vous pouvez remplacer plus tard sans toucher toute l'app.