diff --git a/src/content/fr/2019/javascript.md b/src/content/fr/2019/javascript.md index a771623a30e..f10d89f5263 100644 --- a/src/content/fr/2019/javascript.md +++ b/src/content/fr/2019/javascript.md @@ -23,7 +23,7 @@ La spécification du langage elle-même, ainsi que les nombreuses bibliothèques ## Combien de JavaScript utilisons-nous ? -JavaScript est la ressource la plus consommatrice que nous envoyons aux navigateurs ; il doit être téléchargé, analysé, compilé et enfin exécuté. Bien que les navigateurs aient considérablement réduit le temps nécessaire pour analyser et compiler les scripts, [le téléchargement et l’exécution sont devenus les étapes les plus coûteuses](https://v8.dev/blog/cost-of-javascript-2019) lorsque JavaScript est traité par une page web. +JavaScript est la ressource la plus consommatrice que nous envoyons aux navigateurs : il doit être téléchargé, analysé, compilé et enfin exécuté. Bien que les navigateurs aient considérablement réduit le temps nécessaire pour analyser et compiler les scripts, [le téléchargement et l’exécution sont devenus les étapes les plus coûteuses](https://v8.dev/blog/cost-of-javascript-2019) lorsque JavaScript est traité par une page web. Envoyer de plus petits paquets de JavaScript au navigateur est le meilleur moyen de réduire les temps de téléchargement et d’améliorer ainsi les performances des pages. Mais quelle quantité de JavaScript utilisons-nous réellement ? @@ -37,7 +37,7 @@ Envoyer de plus petits paquets de JavaScript au navigateur est le meilleur moyen La Figure 1 ci-dessus montre que nous utilisons 373 Ko de JavaScript au 50ᵉ percentile (aussi appelé médiane). En d’autres termes, 50 % des sites envoient plus que cette quantité de JavaScript à leurs utilisateurs. -En regardant ces chiffres, il est naturel de se demander si ce n’est pas trop de JavaScript. Cependant, en termes de performances des pages, l’impact dépend entièrement des connexions réseau et des appareils utilisés. Ce qui nous amène à notre prochaine question : quelle quantité de JavaScript envoyons-nous lorsque nous comparons les tests mobiles et sur ordinateurs de bureau ? +En regardant ces chiffres, il est naturel de se demander si ce n’est pas trop de JavaScript. Cependant, en termes de performances des pages, l’impact dépend entièrement des connexions réseau et des appareils utilisés. Ce qui nous amène à notre prochaine question : quelle quantité de JavaScript envoyons-nous lorsque nous comparons les tests sur mobiles et sur ordinateurs de bureau ?
@@ -129,18 +129,18 @@ Tant sur les mobiles que sur les ordinateurs de bureau, les requêtes vers des t
Figure 9. Répartition de l’ensemble du JavaScript téléchargé sur mobile.
-À la médiane, on utilise 89 % plus de code tiers que de code du domaine principal rédigé par l’équipe de développement, tant sur mobiles que sur ordinateurs de bureau. Cela montre clairement que le code tiers peut être un des principaux facteurs de lourdeur d’une page web. Pour plus d’informations sur l’impact des tiers, consultez le chapitre ["Tierces Parties"](./third-parties). +À la médiane, on utilise 89 % plus de code tiers que de code du domaine principal rédigé par l’équipe de développement, tant sur mobiles que sur ordinateurs de bureau. Cela montre clairement que le code tiers peut être un des principaux facteurs de lourdeur d’une page web. Pour plus d’informations sur l’impact des tiers, consultez le chapitre [« Tierces Parties »](./third-parties). ## Compression des ressources -Dans le contexte des interactions entre navigateur et serveur, la compression des ressources fait référence au code qui a été transformé à l’aide d’un algorithme de compression des données. Les ressources peuvent être compressées statiquement à l’avance ou à la volée, quand le navigateur les requêtes. Dans les deux cas, la taille de la ressource transférée est considérablement réduite, ce qui améliore les performances de la page. +Dans le contexte des interactions entre navigateur et serveur, la compression des ressources fait référence au code qui a été transformé à l’aide d’un algorithme de compression des données. Les ressources peuvent être compressées statiquement à l’avance ou à la volée, au moment où le navigateur en fait la demande. Dans les deux cas, la taille de la ressource transférée est considérablement réduite, ce qui améliore les performances de la page. Il existe de nombreux algorithmes de compression de texte, mais seuls deux sont principalement utilisés pour la compression (et la décompression) des requêtes sur le réseau HTTP : -- [Gzip](https://www.gzip.org/) (gzip): le format de compression le plus utilisé pour les interactions entre serveurs et clients ; -- [Brotli](https://github.com/google/brotli) (br): un algorithme de compression plus récent visant à améliorer encore les taux de compression. [90 % des navigateurs](https://caniuse.com/#feat=brotli) supportent la compression Brotli. +- [Gzip](https://www.gzip.org/) (gzip) : le format de compression le plus utilisé pour les interactions entre serveurs et clients ; +- [Brotli](https://github.com/google/brotli) (br) : un algorithme de compression plus récent visant à améliorer encore les taux de compression. [90 % des navigateurs](https://caniuse.com/#feat=brotli) supportent la compression Brotli. -Les scripts compressés devront toujours être décompressés par le navigateur une fois transférés. Cela signifie que son contenu reste le même et que les temps d’exécution ne sont pas du tout optimisés. Cependant, la compression des ressources améliorera toujours les temps de téléchargement, qui est également l’une des étapes les plus coûteuses du traitement JavaScript. S’assurer que les fichiers JavaScript sont correctement compressés peut constituer un des principaux facteurs d’amélioration des performances pour un site web. +Les scripts compressés devront toujours être décompressés par le navigateur une fois transférés. Cela signifie que son contenu reste le même et que les temps d’exécution ne sont pas du tout optimisés. Cependant, la compression des ressources améliorera toujours leur temps de téléchargement, qui est également l’une des étapes les plus coûteuses du traitement JavaScript. S’assurer que les fichiers JavaScript sont correctement compressés peut constituer un des principaux facteurs d’amélioration des performances pour un site web. Combien de sites compressent leurs ressources JavaScript ? @@ -154,19 +154,19 @@ Combien de sites compressent leurs ressources JavaScript ? La majorité des sites compressent leurs ressources JavaScript. L’encodage Gzip est utilisé sur ~64-67 % des sites et Brotli sur ~14 %. Les taux de compression sont similaires sur ordinateurs de bureau et mobiles. -Pour une analyse plus approfondie sur la compression, reportez-vous au chapitre ["Compression"](./compression). +Pour une analyse plus approfondie sur la compression, reportez-vous au chapitre [« Compression »](./compression). ## Bibliothèques et frameworks ouverts -Parlons ici du code source ouvert (open source), ou du code sous licence permissive, qui peut être consulté, visualisé et modifié par n’importe qui. Des minuscules bibliothèques aux navigateurs complets, tels que [Chromium](https://www.chromium.org/Home) et [Firefox](https://www.openhub.net/p/firefox), le code source open source joue un rôle crucial dans le monde du développement web. Dans le contexte de JavaScript, les équipe de développement s’appuient sur des outils open source pour inclure tous types de fonctionnalités dans leur page web. Qu’un développeur ou une développeuse décide d’utiliser une petite bibliothèque d’utilitaires ou un énorme framework qui dicte l’architecture de toute son application, le fait de s’appuyer sur du code open source peut rendre le développement de fonctionnalités plus facile et plus rapide. Quelles sont donc les bibliothèques JavaScript open source les plus utilisées ? +Parlons ici du code source ouvert (open source), ou du code sous licence permissive, qui peut être consulté, visualisé et modifié par n’importe qui. Des minuscules bibliothèques aux navigateurs complets, tels que [Chromium](https://www.chromium.org/Home) et [Firefox](https://www.openhub.net/p/firefox), le code source open source joue un rôle crucial dans le monde du développement web. Dans le contexte de JavaScript, les équipes de développement s’appuient sur des outils open source pour inclure tous types de fonctionnalités dans leur page web. Qu’un développeur ou une développeuse décide d’utiliser une petite bibliothèque d’utilitaires ou un énorme framework qui dicte l’architecture de toute son application, le fait de s’appuyer sur du code open source peut rendre le développement de fonctionnalités plus facile et plus rapide. Quelles sont donc les bibliothèques JavaScript open source les plus utilisées ?
- - - + + + @@ -289,26 +289,26 @@ Il y a plusieurs raisons possibles : Les autres bibliothèques JavaScript les plus utilisées comprennent les variantes de jQuery (jQuery migrate, jQuery UI), [Modernizr](https://modernizr.com/), [Moment.js](https://momentjs.com/), [Underscore.js](https://underscorejs.org/) et ainsi de suite. -### Frameworks and librairies UI +### Frameworks et bibliothèques d'interface -

Comme mentionné dans notre méthodologie, la bibliothèque de détection tierce utilisée dans HTTP Archive (Wappalyzer) a un certain nombre de limitations en ce qui concerne la manière dont elle détecte certains outils. Un ticket est ouvert concernant l’amélioration de la détection des librairies et frameworks JavaScript, ce qui aura eu un impact sur les résultats présentés ici.

+

Comme mentionné dans notre méthodologie, la bibliothèque de détection tierce utilisée dans HTTP Archive (Wappalyzer) a un certain nombre de limitations en ce qui concerne la manière dont elle détecte certains outils. Un ticket est ouvert concernant l’amélioration de la détection des bibliothèques et frameworks JavaScript, ce qui aura eu un impact sur les résultats présentés ici.

-Au cours des dernières années, l’écosystème JavaScript a connu une augmentation du nombre de librairies et frameworks open-source pour faciliter la création d’applications monopages (SPA). Une application monopage se caractérise par une page web qui charge une seule page HTML et utilise JavaScript pour modifier la page lors de l’interaction avec l’utilisateur au lieu de télécharger de nouvelles pages depuis le serveur. Bien que cela reste la principale prémisse des applications monopages, différentes approches de rendu du serveur peuvent encore être utilisées pour améliorer l’expérience de ces sites. Combien de sites utilisent ces types de frameworks ? +Au cours des dernières années, l’écosystème JavaScript a connu une augmentation du nombre de bibliothèques et frameworks open-source pour faciliter la création d’applications monopages (SPA). Une application monopage se caractérise par une page web qui charge une seule page HTML et utilise JavaScript pour modifier la page lors de l’interaction avec l’utilisateur au lieu de télécharger de nouvelles pages depuis le serveur. Bien que cela reste la principale prémisse des applications monopages, différentes approches de rendu du serveur peuvent encore être utilisées pour améliorer l’expérience de ces sites. Combien de sites utilisent ces types de frameworks ?
Figure 12. Frameworks les plus fréquemment utilisés sur ordinateurs de bureau. -
Figure 12. Frameworks les plus fréquemment utilisés sur ordinateurs de bureau.
+
Figure 12. Frameworks les plus fréquemment utilisés sur ordinateurs de bureau.
Seul un sous-ensemble de frameworks populaires est analysé ici, mais il est important de noter que tous suivent l’une ou l’autre de ces deux approches : - Une architecture [modèle-vue-contrôleur](https://developer.chrome.com/apps/app_frameworks) (ou modèle-vue-vue/modèle) -- Une architecture orientée composant +- Une architecture orientée composants -Bien qu’il y ait eu une évolution vers un modèle basé sur les composants, de nombreux frameworks plus anciens suivent le paradigme MVC. ([AngularJS](https://angularjs.org/), [Backbone.js](https://backbonejs.org/), [Ember](https://emberjs.com/)) sont toujours utilisées dans des milliers de pages. Cependant, [React](https://reactjs.org/), [Vue](https://vuejs.org/) et [Angular](https://angular.io/) sont les frameworks à base de composants les plus populaires ([Zone.js](https://github.com/angular/zone.js) est un module qui fait maintenant partie du noyau Angular). +Bien qu’il y ait eu une évolution vers un modèle basé sur les composants, de nombreux frameworks plus anciens suivent le paradigme MVC. ([AngularJS](https://angularjs.org/), [Backbone.js](https://backbonejs.org/), [Ember](https://emberjs.com/)) sont toujours utilisées dans des milliers de pages. Cependant, [React](https://reactjs.org/), [Vue](https://vuejs.org/) et [Angular](https://angular.io/) sont les frameworks à base de composants les plus populaires. ([Zone.js](https://github.com/angular/zone.js) est un module qui fait maintenant partie du noyau Angular). ## Chargement différentiel @@ -326,11 +326,11 @@ Combien de site utilisent `type="module"` sur des scripts dans leurs pages  Figure 13. Pourcentage de sites utilisant type=module. - -
Figure 13. Pourcentage de sites utilisant type=module.
+ +
Figure 13. Pourcentage de sites utilisant type=module.
-La prise en charge des modules au niveau du navigateur est encore relativement récente, et les chiffres montrent que très peu de sites utilisent actuellement le `type="module"` pour leurs scripts. De nombreux sites s’appuient encore sur des chargeurs de modules (2,37 % de tous les sites sur ordinateurs de bureau utilisent [RequireJS](https://github.com/requirejs/requirejs) par exemple) et des bundlers ([webpack](https://webpack.js.org/) par exemple) pour définir des modules au sein de leur base de code. +La prise en charge des modules au niveau du navigateur est encore relativement récente, et les chiffres montrent que très peu de sites utilisent actuellement le `type="module"` pour leurs scripts. De nombreux sites s’appuient encore sur des chargeurs de modules (2,37 % de tous les sites sur ordinateurs de bureau utilisent [RequireJS](https://github.com/requirejs/requirejs) par exemple) et des bundlers ([webpack](https://webpack.js.org/) par exemple) pour définir des modules au sein de leur base de code. Si des modules natifs sont utilisés, il est important de s’assurer qu’un script de recours approprié est utilisé pour les navigateurs qui ne supportent pas encore les modules. Cela peut être fait en incluant un script supplémentaire avec un attribut `nomodule`. @@ -363,20 +363,20 @@ Alors, combien de sites utilisent les directives `preload` et `prefetch` ? Figure 15. Pourcentage de sites utilisant rel=preload pour les scripts. - -
Figure 15. Pourcentage de sites utilisant rel=preload pour les scripts.
+ +
Figure 15. Pourcentage de sites utilisant rel=preload pour les scripts.
Sur tous les sites mesurés par HTTP Archive, 14,33 % des sites sur ordinateurs de bureau et 14,84 % des sites sur mobiles utilisent `` pour des scripts de leur page. -Pour `prefetch`, les chiffres sont les suivant : +Pour `prefetch`, les chiffres sont les suivants :
Figure 16. Pourcentage de sites utilisant rel=prefetch pour les scripts. - -
Figure 16. Pourcentage de sites utilisant rel=prefetch pour les scripts.
+ +
Figure 16. Pourcentage de sites utilisant rel=prefetch pour les scripts.
Sur mobiles comme sur ordinateurs de bureau, 0,08 % des pages utilisent la directive `prefetch` pour au moins un de leurs scripts. @@ -385,7 +385,7 @@ Sur mobiles comme sur ordinateurs de bureau, 0,08 % des pages utilisent la JavaScript continue d’évoluer en tant que langage. Une nouvelle version de la norme de langage elle-même, connue sous le nom d’ECMAScript, est publiée chaque année avec de nouvelles API et comprend des fonctionnalités qui franchissent les étapes de proposition pour devenir une partie du langage lui-même. -Grâce à HTTP Archive, nous pouvons examiner toute nouvelle API prise en charge (ou sur le point de l’être) et voir à quel point son utilisation est répandue. Ces API peuvent déjà être utilisées dans les navigateurs qui les prennent en charge _ou_ avec un polyfill d’accompagnement pour s’assurer qu’elles fonctionnent quel que soit le navigateur. +Grâce à HTTP Archive, nous pouvons examiner toute nouvelle API prise en charge (ou sur le point de l’être) et voir à quel point son utilisation est répandue. Ces API peuvent déjà être utilisées dans les navigateurs qui les prennent en charge _ou_ avec un polyfill d’accompagnement pour s’assurer qu’elles fonctionnent quel que soit le navigateur. Combien de sites utilisent les API suivantes ? @@ -412,22 +412,22 @@ Il est important de noter que les chiffres indiqués ici sont des approximations Dans de nombreux moteurs de compilation, les fichiers JavaScript subissent une minification afin de minimiser leur taille et une transpilation pour les nouvelles fonctionnalités du langage qui ne sont pas encore prises en charge par de nombreux navigateurs. Par ailleurs, les surensembles de langage comme [TypeScript](https://www.typescriptlang.org/) se compilent en un résultat qui peut être sensiblement différent du code source original. Pour toutes ces raisons, le code final servi au navigateur peut être illisible et difficile à déchiffrer. -Une cartographie de code source, ou **sourcemap** est un fichier supplémentaire accompagnant un fichier JavaScript qui permet à un navigateur de faire correspondre la version finale à sa source d’origine. Cela peut rendre le débogage et l’analyse des bundles de production beaucoup plus simples. +Une cartographie de code source, ou **sourcemap** est un fichier supplémentaire accompagnant un fichier JavaScript qui permet à un navigateur de faire correspondre la version finale à sa source d’origine. Cela peut rendre le débogage et l’analyse des bundles de production beaucoup plus simples. Bien qu’utile, il existe un certain nombre de raisons pour lesquelles de nombreux sites peuvent ne pas vouloir inclure de cartographie des sources dans leur site de production final, par exemple en choisissant de ne pas exposer le code source complet au public. Combien de sites incluent donc réellement des sourcemaps ?
- Figure 18. Pourcentage de sites utilisant des sourcemaps. + Figure 18. Pourcentage de sites utilisant des source maps. - -
Figure 18. Percentage of sites using source maps.
+ +
Figure 18. Pourcentage de sites utilisant des source maps.
Les résultats sont à peu près les mêmes pour les pages sur ordinateurs de bureau et les pages sur mobiles. 17-18 % incluent un sourcemap pour au moins un script sur la page (détecté comme un script du domaine principal avec `sourceMappingURL`). ## Conclusion -L’écosystème JavaScript continue de changer et d’évoluer chaque année. Nous verront toujours apparaitre des API plus récentes, des moteurs de navigation améliorés, de nouvelles librairies ou frameworks. HTTP Archive nous fournit des informations précieuses sur la façon dont les sites utilisent le langage sur le terrain. +L’écosystème JavaScript continue de changer et d’évoluer chaque année. Nous verront toujours apparaitre des API plus récentes, des moteurs de navigation améliorés, de nouvelles bibliothèques ou frameworks. HTTP Archive nous fournit des informations précieuses sur la façon dont les sites utilisent le langage sur le terrain. Sans JavaScript, le web ne serait pas là où il est aujourd’hui, et toutes les données recueillies pour cet article ne font que le prouver.
LibrairieOrdinateur de bureauMobileLibrairieOrdinateur de bureauMobile