JavaScript hérité

Silktide vérifie si votre page embarque du code supplémentaire dont le seul but est de prendre en charge des navigateurs très anciens. Les navigateurs modernes n’en ont pas besoin ; pour la quasi-totalité des visiteurs, ce sont donc des téléchargements et du temps de traitement gaspillés.

Lors de la préparation de la publication de , les outils de build ajoutent souvent des polyfills (substituts aux fonctionnalités manquantes dans les anciens navigateurs) et des transformations (réécritures d’une syntaxe moderne en équivalents plus anciens). S’ils sont configurés pour des navigateurs qui ont pratiquement disparu, ils peuvent ajouter un poids mort considérable à chaque chargement de page.

Pourquoi c’est important

La grande majorité des visiteurs utilisent des navigateurs qui se mettent à jour automatiquement et prennent en charge nativement le JavaScript moderne. Le code de compatibilité hérité les fait tous payer — en temps de téléchargement, en données mobiles et en temps de traitement — pour une compatibilité avec des navigateurs qui ne représentent peut-être aucune part de votre trafic réel.

Ce coût passe facilement inaperçu, car rien n’a l’air cassé : le site fonctionne partout. Il est simplement plus lent qu’il ne devrait l’être, sur chaque page, pour tout le monde.

Comment y remédier

Il s’agit d’un réglage de configuration de build pour vos développeurs :

Définissez les cibles de prise en charge des navigateurs de la build sur les navigateurs que vos visiteurs utilisent réellement, plutôt qu’un paramètre hérité par défaut devenu obsolète. La plupart des outils de build lisent ces informations à partir d’une déclaration de prise en charge des navigateurs dans le projet.
Supprimez les imports de polyfills globaux qui ajoutent une prise en charge pour tout, et laissez la build n’inclure que ce dont vos cibles ont réellement besoin.
Si vous devez encore prendre en charge un navigateur ancien, servez deux builds — une moderne pour les navigateurs actuels et une héritée uniquement pour les navigateurs qui en ont besoin — au lieu d’envoyer la build héritée à tout le monde.

Comment Silktide teste cela

Chargez la page dans un véritable navigateur, en utilisant le type d’appareil, la vitesse de connexion et l’emplacement de test configurés pour vos tests de vitesse.
Examinez le JavaScript que la page télécharge pour y repérer des polyfills connus et des transformations de syntaxe dont les navigateurs modernes n’ont pas besoin.
Signalez chaque fichier contenant du code hérité, avec la taille de téléchargement qui pourrait être économisée.
Attribuez une note à la page selon la taille totale gaspillée : environ 30 Ko de code hérité entraîne une pénalisation, et 100 Ko ou plus est noté comme médiocre.

Dépannage

Nous devons encore prendre en charge des navigateurs anciens

Demandez-vous si vos visiteurs les utilisent réellement — vos outils d’analytics vous le diront. Si certains les utilisent vraiment, le modèle module/nomodule vous permet de ne servir le code hérité qu’aux navigateurs qui en ont besoin, de sorte que les navigateurs modernes cessent d’en payer le coût.

Le code hérité se trouve dans un script tiers

Les scripts provenant d’autres fournisseurs peuvent embarquer leur propre surcharge héritée, que vous ne pouvez pas reconstruire. Vérifiez si le fournisseur propose une build moderne et évaluez la valeur du script par rapport à son coût.