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, donc pour la quasi-totalité des visiteurs, ce sont 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 des 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 cellulaires et en temps de traitement — pour la compatibilité avec des navigateurs qui ne représentent peut‑être aucune part de votre trafic réel.

Ce coût est facile à rater parce que rien ne paraît anormal : le site fonctionne partout. Il est simplement plus lent qu’il ne devrait l’être, sur chaque page, pour tout le monde.

Comment corriger le problème

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

Définissez les cibles de prise en charge des navigateurs du build en fonction des 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 cela à partir d’une déclaration de prise en charge des navigateurs dans le projet.
Retirez les importations de polyfills globales qui ajoutent une prise en charge pour tout, et laissez le build n’inclure que ce dont vos cibles ont réellement besoin.
Si un navigateur ancien doit encore être pris en charge, proposez deux builds — un moderne pour les navigateurs actuels et un hérité uniquement pour ceux qui en ont besoin — au lieu d’envoyer le build hérité à tout le monde.

Comment Silktide teste ceci

Charge 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.
Examine le JavaScript téléchargé par la page à la recherche de polyfills connus et de transformations de syntaxe dont les navigateurs modernes n’ont pas besoin.
Signale chaque fichier contenant du code hérité, avec la taille de téléchargement qui pourrait être économisée.
Note la page selon la taille totale gaspillée : environ 30 Ko de code hérité entraîne une baisse de note, et 100 Ko ou plus sont notés comme médiocres.

Dépannage

Nous devons encore prendre en charge d’anciens navigateurs

Demandez‑vous si vos visiteurs les utilisent vraiment — vos données d’analytique vous le diront. Si certains les utilisent effectivement, le modèle module/nomodule vous permet de servir du code hérité uniquement 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 recompiler. Vérifiez si le fournisseur propose un build moderne, et mettez en balance la valeur du script avec son coût.