Prix ​​JavaScript 2019

Au cours des dernières années, ce qu'on appelle le « prix JavaScript » a connu des changements positifs majeurs en raison de la vitesse d'analyse accrue et de la compilation de scripts par le navigateur. Maintenant, en 2019, les principaux composants de la charge sur les systèmes créés par JavaScript sont le temps de chargement des scripts et leur temps d'exécution.



L'interaction de l'utilisateur avec le site peut être temporairement interrompue si le navigateur est occupé à exécuter du code JavaScript. En conséquence, nous pouvons dire que l'optimisation des goulots d'étranglement associés au chargement et à l'exécution de scripts peut avoir un fort impact positif sur les performances du site Web.

Directives pratiques générales pour l'optimisation de sites Web

Que signifie ce qui précède pour les développeurs Web? Le point ici est que le coût des ressources pour l'analyse (analyse, analyse) et la compilation de scripts ne sont pas aussi graves qu'auparavant. Par conséquent, lors de l'analyse et de l'optimisation des bundles JavaScript, les développeurs doivent prendre en compte les trois recommandations suivantes:

1. Essayez de réduire le temps requis pour télécharger les scripts.
   
   
   • Essayez de garder vos bundles JS petits. Ceci est particulièrement important pour les sites conçus pour les appareils mobiles. L'utilisation de petits ensembles améliore le temps de chargement du code, réduit le niveau d'utilisation de la mémoire et réduit la charge du processeur.
   • Essayez d'empêcher que tout le code du projet soit présenté comme un seul gros paquet. Si la taille du paquet dépasse environ 50 à 100 Ko - divisez-le en fragments séparés de petite taille. Grâce au multiplexage HTTP / 2, plusieurs demandes de serveur et plusieurs réponses peuvent être traitées simultanément. Cela réduit la charge sur le système associée à la nécessité de répondre à des demandes supplémentaires de chargement de données.
   • Si vous travaillez sur un projet mobile, essayez de garder le code aussi petit que possible. Cette recommandation est associée à de faibles débits de données sur les réseaux mobiles. De plus, efforcez-vous d'utiliser économiquement la mémoire.
2. Essayez de réduire le temps nécessaire à l'exécution des scripts.
   
   
   • Évitez d'utiliser des tâches longues qui peuvent charger le thread principal pendant une longue période et augmenter le temps nécessaire pour que les pages soient dans un état dans lequel les utilisateurs peuvent interagir avec eux. Dans l'environnement actuel, les scripts qui s'exécutent après leur chargement apportent une contribution majeure au «prix de JavaScript».
3. N'intégrez pas d'extraits de code volumineux dans les pages.
   
   
   • La règle suivante doit être respectée ici: si la taille du script dépasse 1 Ko, essayez de ne pas l'intégrer dans le code de la page. L'une des raisons de cette recommandation est le fait que 1 Ko est la limite après laquelle la mise en cache du code de script externe commence à fonctionner dans Chrome. Gardez également à l'esprit que l'analyse et la compilation de scripts intégrés sont toujours en cours d'exécution dans le thread principal.

Pourquoi est-il si important de charger et d'exécuter des scripts?

Pourquoi est-il important d'optimiser le temps de chargement et d'exécution des scripts dans des conditions modernes? Les temps de chargement des scripts sont extrêmement importants dans les situations où les sites sont accessibles via des réseaux lents. Malgré le fait que les réseaux 4G (et même 5G) se répandent de plus en plus, la propriété NetworkInformation.effectiveType dans de nombreux cas d'utilisation de connexions Internet mobiles affiche des indicateurs qui se situent au niveau des réseaux 3G ou même à des niveaux inférieurs.

Le temps requis pour exécuter le code JS est important pour les appareils mobiles avec des processeurs lents. En raison du fait que les appareils mobiles utilisent des CPU et GPU différents, du fait que lorsque les appareils surchauffent, afin de les protéger, les performances de leurs composants diminuent, vous pouvez observer un écart important entre les performances des téléphones et tablettes chers et bon marché. Cela affecte considérablement les performances du code JavaScript, car la capacité à exécuter ce code par un périphérique est limitée par les capacités du processeur de ce périphérique.

En fait, si nous analysons le temps total consacré au chargement et à la préparation de la page pour le travail dans un navigateur comme Chrome, environ 30% de ce temps peut être consacré à l'exécution du code JS. Vous trouverez ci-dessous une analyse du chargement d'une page Web très typique (reddit.com) sur un ordinateur de bureau hautes performances.


Dans le processus de chargement de la page, environ 10 à 30% du temps est consacré à l'exécution de code à l'aide de V8

Si nous parlons d'appareils mobiles, alors sur un téléphone moyen (Moto G4), il faut 3 à 4 fois plus de temps pour exécuter reddit.com sur un code JS que sur un appareil de haut niveau (Pixel 3). Sur un appareil faible (Alcatel 1X coûtant moins de 100 $), résoudre le même problème nécessite au moins 6 fois plus de temps que quelque chose comme Pixel 3.


Le temps requis pour traiter le code JS sur des appareils mobiles de différentes classes

Veuillez noter que les versions mobile et bureau de reddit.com sont différentes. Par conséquent, vous ne pouvez pas comparer les résultats des appareils mobiles et, par exemple, du MacBook Pro.

Lorsque vous essayez d'optimiser le temps d'exécution du code JavaScript, faites attention aux tâches longues qui peuvent capturer le flux d'interface utilisateur pendant une longue période. Ces tâches peuvent entraver l'exécution d'autres tâches extrêmement importantes, même lorsque l'apparence de la page semble complètement prête pour le travail. Les tâches à long terme doivent être décomposées en tâches plus petites. En divisant le code en parties et en contrôlant l'ordre de chargement de ces parties, vous pouvez obtenir le fait que les pages atteindront un état interactif plus rapidement. Espérons que cela conduira les utilisateurs à moins d'inconvénients à interagir avec les pages.


Les tâches de longue durée capturent le thread principal. Ils doivent être brisés en morceaux

Comment les améliorations V8 accélèrent-elles l'analyse et la compilation des scripts?

La vitesse d'analyse du code JS source dans la V8, depuis l'époque de Chrome 60, a été multipliée par 2. Dans le même temps, l'analyse et la compilation contribuent désormais moins au «prix JavaScript». Cela est dû à d'autres efforts d'optimisation de Chrome menant à la parallélisation de ces tâches.

Dans la V8, la quantité de travail sur l'analyse et la compilation de code produite dans le thread principal est réduite en moyenne de 40%. Par exemple, pour Facebook, l'amélioration de cet indicateur était de 46%, pour Pinterest - 62%. Le résultat le plus élevé, 81%, a été obtenu pour YouTube. Ces résultats sont possibles du fait que l'analyse et la compilation sont déplacées vers un flux distinct. Et cela s'ajoute aux améliorations existantes concernant la solution de streaming des mêmes tâches en dehors du flux principal.


Temps d'analyse JS dans différentes versions de Chrome

Vous pouvez également visualiser comment les optimisations V8 produites dans différentes versions de Chrome affectent le temps processeur requis pour traiter le code. En même temps que Chrome 61 devait analyser le code Facebook JS, Chrome 75 peut désormais analyser le code Facebook JS et, en outre, analyser le code Twitter 6 fois.


Pendant que Chrome 61 avait besoin de traiter le code Facebook JS, Chrome 75 peut traiter à la fois le code Facebook et six fois la quantité de code Twitter.

Parlons de la façon dont ces améliorations ont été réalisées. En résumé, les ressources de script peuvent être analysées et compilées en mode streaming dans le workflow. Cela signifie ce qui suit:

• V8 peut analyser et compiler du code JS sans bloquer le thread principal.
• Le traitement de flux du script démarre lorsque l'analyseur HTML universel rencontre la <script> . Un analyseur HTML gère les scripts qui bloquent l'analyse des pages. Rencontre avec des scripts asynchrones, il continue de travailler.
• Dans la plupart des scénarios du monde réel, caractérisés par certaines vitesses de connexion réseau, le V8 analyse le code plus rapidement qu'il ne peut le charger. En conséquence, V8 termine les tâches d'analyse et de compilation du code quelques millisecondes après le chargement des derniers octets du script.

Si vous en parlez un peu plus en détail, le point ici est le suivant. Dans les versions beaucoup plus anciennes de Chrome, le script devait être téléchargé dans son intégralité avant de l'analyser. Cette approche est simple et compréhensible, mais lorsqu'elle est utilisée, les ressources du processeur sont utilisées de manière irrationnelle. Chrome, entre les versions 41 et 68, commence l'analyse en mode asynchrone, immédiatement après le chargement du script, effectuant cette tâche dans un thread distinct.


Les scripts sont envoyés au navigateur en fragments. La V8 démarre le traitement des données en continu après avoir au moins 30 Ko de code.

Dans Chrome 71, nous sommes passés à un système basé sur les tâches. Ici, le planificateur peut démarrer simultanément plusieurs sessions de traitement de script asynchrones / retardées. En raison de ce changement, la charge créée par l'analyse du thread principal a diminué d'environ 20%. Cela a conduit à une amélioration d'environ 2% des scores TTI / FID obtenus sur des sites réels.


Chrome 71 utilise un système de traitement de code basé sur les tâches. Avec cette approche, le planificateur peut traiter plusieurs scripts asynchrones / en attente en même temps.

Dans Chrome 72, nous avons fait du traitement en streaming le principal moyen d'analyser les scripts. Désormais, même les scripts synchrones réguliers sont gérés de cette façon (bien que cela ne s'applique pas aux scripts intégrés). De plus, nous avons cessé d'annuler les opérations d'analyse basée sur les tâches si le thread principal avait besoin de code analysé. Cela est dû au fait que cela conduit à la nécessité de réexécuter une partie du travail déjà effectué.

La version précédente de Chrome était compatible avec l'analyse en continu et la compilation en continu de code. Ensuite, le script téléchargé à partir du réseau doit d'abord entrer dans le flux principal, puis il sera redirigé vers le système de traitement de script de streaming.

Cela a souvent conduit l'analyseur de flux à attendre des données déjà téléchargées depuis le réseau mais pas encore redirigées par le flux principal vers le traitement de flux. Cela est dû au fait que le thread principal peut être occupé par d'autres tâches (telles que l'analyse HTML, la création d'une mise en page ou l'exécution de code JS).

Maintenant, nous essayons de commencer à analyser le code lors du préchargement des pages. Auparavant, la mise en œuvre d'un tel mécanisme était entravée par la nécessité d'utiliser les ressources du thread principal pour transférer des tâches vers l'analyseur de streaming. Des détails sur l'analyse du code JS qui s'exécute «instantanément» peuvent être trouvés ici .

Comment les améliorations ont-elles affecté ce qui peut être vu dans les outils du développeur?

En plus de ce qui précède, on peut noter qu'il y avait un problème dans les outils de développement auparavant. Cela consistait dans le fait que les informations sur la tâche d'analyse étaient affichées comme si elles bloquaient complètement le thread principal. Cependant, l'analyseur a effectué des opérations bloquant le thread principal uniquement lorsqu'il avait besoin de nouvelles données. Depuis que nous sommes passés du schéma d'utilisation d'un flux unique pour le traitement en continu des données au schéma dans lequel les tâches de traitement en streaming sont appliquées, cela est devenu assez évident. Voici ce que vous pouvez voir dans Chrome 69.


Le problème réside dans les outils de développement, en raison desquels les informations sur l'analyse des scripts ont été affichées comme si elles bloquaient complètement le thread principal

Ici, vous pouvez voir que la tâche d'analyse du script prend 1,08 seconde. Mais l'analyse de JavaScript n'est en fait pas si lente! La plupart du temps, rien d'utile n'est effectué, à part attendre les données du thread principal.
Dans Chrome 76, vous pouvez déjà voir une image complètement différente.


Dans Chrome 76, l'analyse est divisée en de nombreuses petites tâches

En général, on peut noter que l'onglet Performances des outils de développement est idéal pour voir l'image globale de ce qui se passe sur la page. Afin d'obtenir des informations plus détaillées qui reflètent les fonctionnalités de la V8, telles que le temps d'analyse et le temps de compilation, vous pouvez utiliser le suivi de Chrome avec la prise en charge RCS (Runtime Call Stats). Dans les données RCS reçues, vous pouvez trouver les indicateurs Parse-Background et Compile-Background. Ils peuvent signaler le temps qu'il a fallu pour analyser et compiler le code JS en dehors du thread principal. Les mesures Parse et Compile indiquent combien de temps a été consacré à des activités connexes dans le thread principal.


Analyse des données RCS à l'aide de Google Tracing

Comment les changements ont-ils affecté le travail avec des sites réels?

Examinons quelques exemples de la façon dont le traitement de script en continu a influencé la navigation sur des sites réels.

▍Reddit

Affichez reddit.com sur un MacBook Pro. Temps d'analyse et de compilation du code JS passé dans les threads principal et de travail

Il existe plusieurs bundles JS sur le site reddit.com, dont chacun dépasse 100 Ko. Ils sont enveloppés dans des fonctions externes, ce qui conduit à l'exécution de gros volumes de compilation "paresseux" dans le thread principal. Le temps nécessaire pour traiter les scripts dans le thread principal est crucial dans le diagramme ci-dessus. Cela est dû au fait qu'une charge importante sur le thread principal peut augmenter le temps nécessaire pour que la page passe en mode interactif. Lors du traitement du code du site reddit.com, la plupart du temps est consacré au thread principal et les ressources du thread de travail / arrière-plan sont utilisées au minimum.

Vous pouvez optimiser ce site en divisant certains gros paquets en parties (environ 50 Ko chacun) et sans encapsuler le code dans une fonction. Cela maximiserait le traitement parallèle des scripts. En conséquence, les bundles pouvaient être analysés et compilés en même temps en mode streaming. Cela réduirait la charge sur le thread principal lors de la préparation de la page pour le travail.

▍Facebook

Affichez facebook.com sur votre MacBook Pro. Temps d'analyse et de compilation du code JS passé dans les threads principal et de travail

Nous pouvons également envisager un site comme facebook.com, qui utilise environ 6 Mo de code JS compressé. Ce code est chargé à l'aide d'environ 292 requêtes. Certains d'entre eux sont asynchrones, certains visent à précharger des données, certains ont une faible priorité. La plupart des scripts Facebook sont de petite taille et à focalisation étroite. Cela peut avoir un bon effet sur le traitement parallèle des données au moyen de flux d'arrière-plan / de travail. Le fait est que de nombreux petits scripts peuvent être analysés et compilés en même temps au moyen d'un traitement de script en continu.

Veuillez noter que votre site est probablement différent du site Facebook. Vous n'avez probablement pas d'applications qui restent ouvertes pendant longtemps (comme ce qu'est un site Facebook ou l'interface Gmail), et lorsque vous travaillez avec elles, le téléchargement de volumes de scripts aussi sérieux avec un navigateur de bureau peut être justifié. Mais, malgré cela, nous pouvons donner une recommandation générale qui soit juste pour tous les projets. Cela réside dans le fait qu'il vaut la peine de diviser le code d'application en paquets modestes et que vous ne devez télécharger ces paquets qu'en cas de besoin.

Bien que la plupart du travail d'analyse et de compilation du code JS puisse être effectué à l'aide d'outils de streaming dans un thread d'arrière-plan, certaines opérations nécessitent toujours un thread principal. Lorsque le thread principal est occupé par quelque chose, la page ne peut pas répondre à l'interaction de l'utilisateur. Par conséquent, il est recommandé de prêter attention à l'impact sur les sites UX du chargement et de l'exécution du code JS.

Gardez à l'esprit que tous les moteurs et navigateurs JavaScript ne diffusent plus de scripts et optimisent leur chargement. Mais malgré cela, nous espérons que les principes généraux d'optimisation décrits ci-dessus peuvent améliorer l'expérience utilisateur de travailler avec des sites consultés dans l'un des navigateurs existants.

Prix ​​d'analyse JSON

L'analyse du code JSON peut être beaucoup plus efficace que l'analyse du code JavaScript. Le fait est que la grammaire JSON est beaucoup plus simple que la grammaire JavaScript. Ces connaissances peuvent être appliquées afin d'améliorer la vitesse de préparation pour le travail des applications Web qui utilisent de gros objets de configuration (tels que les référentiels Redux), dont la structure ressemble au code JSON. Par conséquent, il s'avère qu'au lieu de présenter les données comme des littéraux d'objet incorporés dans le code, vous pouvez les représenter comme des chaînes d'objets JSON et analyser ces objets lors de l'exécution.

La première approche, utilisant des objets JS, ressemble à ceci:

 const data = { foo: 42, bar: 1337 }; //  

La deuxième approche, utilisant des chaînes JSON, implique l'utilisation de telles constructions:

 const data = JSON.parse('{"foo":42,"bar":1337}'); //  

Comme vous n'avez besoin d'exécuter le traitement de chaîne JSON qu'une seule fois, l'approche qui utilise JSON.parse est beaucoup plus rapide que l'utilisation de littéraux d'objet JavaScript. Surtout - lors du chargement de page "à froid". Il est recommandé d'utiliser des chaînes JSON pour représenter les objets commençant à 10 Ko. Cependant, comme pour tout conseil de performance, ce conseil ne doit pas être suivi sans réfléchir. Avant d'appliquer cette technique de présentation des données en production, il est nécessaire de faire des mesures et d'évaluer son impact réel sur le projet.

L'utilisation de littéraux d'objets comme stockage pour de grandes quantités de données constitue une autre menace. Le fait est qu'il existe un risque que ces littéraux puissent être traités deux fois:

1. La première passe de traitement est effectuée avec une analyse préliminaire du littéral.
2. La deuxième approche est effectuée lors de l'analyse "paresseuse" du littéral.

Vous ne pouvez pas vous débarrasser de la première passe de traitement des littéraux d'objet. Mais, heureusement, la deuxième passe peut être évitée en plaçant les littéraux d'objet au niveau supérieur ou à l'intérieur de PIFE .

Qu'en est-il de l'analyse et de la compilation de code lors de visites répétées sur des sites?

Il est possible d'optimiser les performances du site dans les cas où les utilisateurs les visitent plusieurs fois, grâce aux capacités V8 de mise en cache du code et du bytecode. Lorsqu'un script est demandé au serveur pour la première fois, Chrome le télécharge et passe la V8 pour la compilation. Le navigateur enregistre en outre le fichier de ce script dans son cache disque. Lorsque la deuxième demande de téléchargement du même fichier JS est exécutée, Chrome le prend dans le cache du navigateur et passe à nouveau V8 pour la compilation. Cette fois, cependant, le code compilé est sérialisé et attaché au fichier de script mis en cache en tant que métadonnées.


Système de mise en cache de code dans V8

Lorsque le script est demandé pour la troisième fois, Chrome prend le fichier et ses métadonnées du cache, puis transfère le V8 à la fois. La V8 désérialise les métadonnées et, par conséquent, peut ignorer l'étape de compilation. La mise en cache du code est déclenchée si les visites sur le site sont effectuées dans les 72 heures. Chrome utilise également la stratégie de mise en cache de code gourmande lorsqu'un employé de service est utilisé pour mettre en cache des scripts. Des détails sur la mise en cache du code peuvent être trouvés ici .

Résumé

En 2019, les principaux goulots d'étranglement des performances des pages Web sont le chargement et l'exécution de scripts. Afin d'améliorer la situation, efforcez-vous d'utiliser des scripts synchrones (intégrés) de petites tailles, qui sont nécessaires pour organiser l'interaction de l'utilisateur avec la partie de la page qui lui est visible immédiatement après le chargement. Il est recommandé de charger les scripts utilisés pour traiter d'autres parties des pages en mode différé. Brisez les gros paquets en petits morceaux. Cela facilitera la mise en œuvre d'une stratégie pour travailler avec du code, dans l'application duquel le code n'est chargé que lorsqu'il est nécessaire, et uniquement là où il est nécessaire. Cela maximisera les capacités de V8, visant à un traitement parallèle du code.

Si vous développez des projets mobiles, vous devez vous assurer qu'ils utilisent le moins de code JS possible. Cette recommandation découle du fait que les appareils mobiles fonctionnent généralement dans des réseaux assez lents. De tels périphériques, en outre, peuvent être limités en termes de RAM disponible et de ressources processeur disponibles. Essayez de trouver un équilibre entre le temps requis pour préparer les scripts téléchargés depuis le réseau et l'utilisation du cache. Cela maximisera la quantité d'analyse et de compilation de code effectuée en dehors du thread principal.

Chers lecteurs! Optimisez-vous vos projets web en tenant compte des particularités du traitement de code JS par les navigateurs modernes?