Réduire le coût de démarrage du JavaScript

À mesure que les sites s’appuient davantage sur JavaScript, on en paie le prix de manières peu visibles. Transmettre moins de code, c’est réduire à la fois le temps de transfert réseau, le temps de décompression et le temps d’analyse et de compilation. Or chacune de ces étapes retarde le moment où la page devient réellement interactive.

Un peu de discipline change tout, surtout sur mobile. Pour le SEO, l’enjeu est clair : une page qui devient interactive rapidement offre une meilleure expérience, allège le thread principal et soutient des métriques comme l’INP, suivies par Google. Réduire le coût de démarrage du JavaScript est donc un levier de performance autant que de visibilité.

On résume souvent le coût du JavaScript à son téléchargement et à son exécution. C’est incomplet. Une fois récupéré, le script doit être décompressé, puis analysé et compilé par le moteur, avant même d’être exécuté. Sur un mobile d’entrée de gamme, le temps d’analyse et de compilation peut être 2 à 5 fois plus long que sur un appareil haut de gamme.

Le contexte compte : un utilisateur peut disposer d’une bonne connexion mais d’un processeur lent, ou l’inverse. Octet pour octet, le traitement du JavaScript est plus coûteux pour le navigateur que celui d’une image de taille équivalente, car une image bloque rarement le thread principal pendant son décodage ; lorsqu’un script monopolise ce thread, il faut alors optimiser les longues tâches pour préserver la réactivité.

Le premier levier consiste à n’envoyer que le code utile. Le fractionnement du code sépare l’essentiel du superflu, et le reste est chargé de façon différée. La minification supprime espaces et caractères inutiles, la compression (gzip au minimum, idéalement Brotli) réduit encore le poids des fichiers texte.

Supprimez aussi le code mort : l’outil de couverture des outils pour développeurs Chrome révèle ce qui n’est jamais utilisé, tandis que le tree-shaking et des préréglages comme babel-preset-env évitent de transpiler des fonctionnalités déjà gérées par les navigateurs modernes. Enfin, une mise en cache HTTP bien réglée évite de retélécharger des ressources inchangées.

Tester uniquement sur un appareil haut de gamme donne une vision faussée. Sur un site réel, le code JavaScript peut être analysé en quelques secondes sur un téléphone récent, mais prendre nettement plus de temps sur un mobile moyen. Développez et mesurez donc sur du matériel représentatif de votre audience, sans oublier de maîtriser les scripts externes en suivant nos conseils pour optimiser le JavaScript tiers.

Côté architecture, deux modèles aident à limiter les coûts. PRPL (Push, Render, Pre-cache, Lazy-load) optimise l’interactivité par un fractionnement et une mise en cache agressifs. Le démarrage progressif consiste à envoyer une page minimale fonctionnelle, puis à débloquer les fonctionnalités au fur et à mesure que les ressources arrivent, plutôt que de tout charger d’un coup.