unslug fr: move

13 files changed, 1604 insertions, 0 deletions

diff --git a/files/fr/tools/performance/allocations/index.html b/files/fr/tools/performance/allocations/index.html
new file mode 100644
index 0000000000..21cdf3b008
--- /dev/null
+++ b/files/fr/tools/performance/allocations/index.html
@@ -0,0 +1,86 @@
+---
+title: Allocations
+slug: Outils/Performance/Allocations
+translation_of: Tools/Performance/Allocations
+---
+<div>{{ToolsSidebar}}</div><div class="summary">
+<p>La vue Allocations de l'outil Performance affiche quelles fonctions dans une page web allouent le plus de mémoire durant le profil.</p>
+
+<p>C'est important pour la performance, car allouer beaucoup de mémoire ou faire beaucoup d'allocations peut activer le <a href="/fr/docs/Tools/Performance/Allocations#Allocations_and_garbage_collection">ramasse-miette</a> (garabage collector). Celui-ci peut affecter la réactivité de la page.</p>
+</div>
+
+<div class="geckoVersionNote">
+<p>La vue Allocations est une des nouveautés de Firefox 46.</p>
+</div>
+
+<p>Pour activer la vue Allocations, il faut activer l'option "Enregistrer les Allocations" dans les options de l'outil Performance, <em>avant</em> d'enregister un profil. Il faut ensuite <a href="/fr/docs/Tools/Performance/How_to#Record_a_profile">enregistrer un profil</a>, un nouvel onglet nommé "Allocations" apparaitra alors dans la barre d'outils :</p>
+
+<p>{{EmbedYouTube("Le9tTo7bqts")}}</p>
+
+<h2 id="Anatomie_de_la_vue_allocations">Anatomie de la vue allocations</h2>
+
+<p>La vue allocations ressemble à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12393/allocations-view-1.png" style="display: block; height: 156px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Cette vue fait périodiquement des échantillons des allocations qui sont faites durant l'enregistrement. Chaque ligne représente une fonction pour laquelle au moins un échantillon d'allocation a été pris durant l'enregistrement.</p>
+
+<p>La vue inclut les colonnes suivantes :</p>
+
+<ul>
+ <li>Self Count: Le nombre d'échantillons d'allocations qui ont été prises dans cette fonction (affiché également en pourcentage du total)</li>
+ <li>Self Bytes: Le nombre total d'octets qui ont été alloués dans les échantillons d'allocations dans cette fonction (affiché également en pourcentage du total)</li>
+</ul>
+
+<p>Les lignes sont triées par la colonne "Self Bytes".</p>
+
+<p>Anisi dans l'exemple ci-dessus :</p>
+
+<ul>
+ <li>8904 échantillons ont été pris dans la fonction <code>signalLater()</code>, ce qui représente 28.57% du nombre total d'échantillons pris.</li>
+ <li>Ces échantillons ont alloué 1102888 octets, ce qui représente 30.01% de la taille totale de mémoire alloué par tous les échantillons.</li>
+</ul>
+
+<p>À côté de chaque nom de fonction, se trouve une flèche de développement. Cliquer sur celle-ci affichera l'endroit d'où la fonction a été appelée :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12397/allocations-view-2.png" style="display: block; height: 155px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Ici, il est possible de voir que <code>signalLater()</code> a été appelée depuis deux endroits :<code> removeInner()</code> et <code>setSelectionInner()</code>. Il est ainsi possible de remonter l'arbre d'appel et de mieux comprendre le contexte de ces allocations.</p>
+
+<h3 id="Self_Cost_et_Total_Cost">Self Cost et Total Cost</h3>
+
+<ul>
+</ul>
+
+<p>Les colonnes de coût sont séparées en "Self" et en "Total". La colonne "Self" correspond aux échantillons pris seulement dans cette fonction. La colonne "Total" correspond aux échantillons pris dans cette fonction ou dans les fonctions appelées par cette fonction. Au premier niveau, ces deux colones sont les mêmes, vu que la vue représente les dernières fonctions (il s'agit d'une vue inversée de l'arbre d'appel). Mais, si l'on remonte l'arbre en développant les lignes, alors la différence devient visible.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12397/allocations-view-2.png" style="display: block; height: 155px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Ici, 8904 échantillons ont été pris dans <code>signalLater()</code>. Mais <code>signalLater()</code> a été appelé depuis deux endroits : <code>removeInner()</code> et <code>setSelectionInner()</code>. Mais ces deux fonctions ont 0 en Self Count, ce qui veut dire qu'aucune allocation n'a été faite depuis ces fonctions. Cependant<code> removeInner()</code> a 8901 en Total Count, tandis que <code>setSelectionInner()</code> a seulement 3 en Total Count. Cela révèle que sur les 8904 allocations faites dans <code>signalLater()</code>, toutes sauf trois proviennent de la branche <code>removeInner()</code>.</p>
+
+<h2 id="Allocations_et_garbage_collection">Allocations et garbage collection</h2>
+
+<p>Bien sûr, en savoir plus sur l'utilisation mémoire d'un site est très utile. Cependant la connexion principale entre la réactivité d'un site et le profil d'allocation réside dans le coût de la garbage collection (GC) (ramasse-miette).</p>
+
+<p>Dans un langage à ramasse miette comme JavaScript, le runtime a périodiquement besoin de parcourir la heap à la recherche d'objets qui ne sont plus <a href="/fr/docs/Tools/Memory/Dominators#Reachability">accessibles</a>, pour libérer l'espace mémoire qu'ils occupent. Lors du passage du ramasse-miette, le moteur JavaScript doit être mis en pause, le programme est donc suspendu et ne répondra pas.</p>
+
+<p>Pour réduire l'impact de ce phénomène sur la réactivité des sites, <a href="/fr/docs/Mozilla/Projects/SpiderMonkey">SpiderMonkey</a> (le moteur JavaScript de Firefox) possède un ramasse-miette incrémental. Celui-ci procède par petites étapes, lassant le programme tourner entre chaque incrémentation. Quelques fois cependant le moteur a besoin de réaliser un passage complet non incrémental et le programme doit alors attendre la fin du nettoyage.</p>
+
+<p>Les passages du ramasse-miette sont affichés en rouge dans la vue <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a>, et sont des véritables points noirs pour la réactivité, ils peuvent en effet prendre jusqu'a des centaines de millisecondes :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12399/allocations-view-long-gc.png" style="display: block; height: 160px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Que faire en cas de passage intempestif du ramasse-miette ? SpiderMonkey utilise un <a href="https://dxr.mozilla.org/mozilla-central/rev/584870f1cbc5d060a57e147ce249f736956e2b62/js/src/gc/GCRuntime.h#192">ensemble complexe d'heuristiques</a> pour déterminer quand et quel type de passage de ramasse-miette est nécessaire.</p>
+
+<p>En général, cependant :<em> "l'allocation pressure" - allouer beaucoup de mémoire ou allouer de la mémoire a haute fréquence - tend a augmenter la probabilité de SpiderMonkey à ordonner le passage du ramasse-miette, et tend également a faire plus de passages non incrémentaux.</em></p>
+
+<p>Si un passage du ramasse-miette a été causé par de "l'allocation pressure", alors le panneau droit du marqueur dans la vue Chronologie contient un lien nommé "Show allocation triggers". Cliquer sur celui-ci passe la vue en vue allocations et sélectionne la période de temps entre la fin du dernier passage du ramasse-miette et le début de celui qui a été cliqué. Cela révèle toute les allocations qui ont amené à déclencher ce passage du ramasse-miette :</p>
+
+<p>{{EmbedYouTube("tO5ovD9Jw4k")}}</p>
+
+<p>Si vous rencontrez ces problèmes, il est conseillé d'essayer de réduire la taille de vos allocations. Par exemple :</p>
+
+<ul>
+ <li>Est-il possible d'allouer de la mémoire en "<a href="https://en.wikipedia.org/wiki/Lazy_loading">lazy load</a>", lorsqu'elle est nécessaire plutôt que de l'allouer en avance ?</li>
+ <li>Si vous allouez de la mémoire dans une boucle, pouvez-vous réutiliser une seule allocation dans chaque itération ?</li>
+</ul>
diff --git a/files/fr/tools/performance/call_tree/index.html b/files/fr/tools/performance/call_tree/index.html
new file mode 100644
index 0000000000..e8a3447894
--- /dev/null
+++ b/files/fr/tools/performance/call_tree/index.html
@@ -0,0 +1,122 @@
+---
+title: Arbre d'appels
+slug: Outils/Performance/Call_Tree
+translation_of: Tools/Performance/Call_Tree
+---
+<div>{{ToolsSidebar}}</div>
+
+<div class="summary">
+<p>L'arbre d'appel permet de savoir dans quelles fonctions JavaScript le navigateur passe le plus de temps. En analysant ces résultats, il est possible de trouver les points noirs du code (les endroits ou le navigateur passe beaucoup trop de temps).</p>
+
+<p>Ces points noirs sont les endroits où les optimisations auront le plus grand impact.</p>
+</div>
+
+<p>L'arbre d'appel est un profileur par échantillons. Il prend périodiquement des échantillons de l'état du moteur JavaScript, et enregistre la pile pour le code s'exécutant dans ce moment. Statistiquement, le nombre d'échantillons dans lequel on exécute une fonction en particulier correspond au temps que le navigateur passe à l'exécuter. Il est alors possible de trouver les points noirs de votre code.</p>
+
+<div class="note">
+<p>Cet article utilisera le résultat d'un programme simple comme exemple. Si vous voulez récupérer ce programme pour expérimenter l'outil vous-même, il est disponible <a href="https://github.com/mdn/performance-scenarios/blob/gh-pages/js-call-tree-1/">ici</a>. Vous pouvez trouver le profil discuté dans cet article <a href="https://github.com/mdn/performance-scenarios/blob/gh-pages/js-call-tree-1/profile/call-tree.json">ici</a> - importez juste le profil dans l'outil Performance pour pouvoir voir le profil utilisé dans cet article.</p>
+
+<p>Il y a une courte page décrivant la structure du programme disponible <a href="https://developer.mozilla.org/fr/docs/Tools/Performance/Examples/Sorting_algorithms_comparison">ici</a>.</p>
+
+<p>Il est à noter que le même programme et le même profil est utilisé pour la page de documentation sur le <a href="/fr/docs/Tools/Performance/Flame_Chart">Flame Chart</a>.</p>
+</div>
+
+<p>La capture d'écran ci-dessous montre les résultats d'un programme qui compare trois différents algorithmes de tri (tri à bulle, tri par sélection et tri rapide). Pour faire cela, il génère un nombre de tableaux remplis avec des int aléatoires et les tris avec chaque algorithme.</p>
+
+<p>Nous avons <a href="/fr/docs/Tools/Performance/UI_Tour#Zooming_in">zoomé</a> dans une partie de l'enregistrement qui montre un long marker JavaScript :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10981/perf-call-tree.png" style="display: block; height: 574px; margin-left: auto; margin-right: auto; width: 1052px;"></p>
+
+<p>L'arbre d'appel présente les résultats dans un tableau. Chaque ligne représente une fonction dans laquelle au moins un échantillon a été pris, et les lignes sont classées par nombre d'échantillons pris dans la fonction.</p>
+
+<p><em>Échantillons</em> correspond au nombre d'échantillons pris lors de de l'exécution de la fonction. Cela inclu ses enfants (les autres fonctions appelées par cette fonction).</p>
+
+<p><em>Durée Totale </em>correspond est ce nombre, traduit en millisecondes, basées sur le temps total couvert par la portion sélectionnée de l'enregistrement. Ces deux nombres devraient être approximativement les même.</p>
+
+<p><em>Cout Total </em>correspond à ce nombre traduit en pourcentage du nombre total d'échantillons dans la portion sélectionnée de l'enregistrement.</p>
+
+<p><em>Coût individuel</em> correspond au temps passé dans cette fonction en particulier, sans inclure ses enfants. Cela vient de la pille capturé lorsque cette fonction est la plus basse.</p>
+
+<p><em>Durée individuelle</em> est calculé depuis <em>Coût individuel </em>comme un pourcentage du nombre total d'échantillons dans la portion sélectionnée de l'enregistrement.</p>
+
+<p>Dans la version actuelle de l'arbre d'appel, ce sont les colones les plus importantes. Les fonctions avec un <em>Cout individuel</em> important sont de bons candidats pour de l'optimisation, soit parce qu’elles prennent beaucoup de temps à s'exécuter, soit parce qu'elles sont appelées très souvent.</p>
+
+<p>Cette capture d'écran révèle ce que l'on savait déjà : <code>bubbleSort()</code> est un algorithme très inefficace. Il y a à peu près 6 fois plus d'échantillons dans <code>bubbleSort()</code> que de dans <code>selectionSort()</code>, et 13 fois plus dans que dans <code>quickSort()</code>.</p>
+
+<h2 id="Se_déplacer_dans_l'arbre_d'appel">Se déplacer dans l'arbre d'appel</h2>
+
+<p>A coté de chaque nom de fonction, se trouve une flèche d'expansion : cliquer sur celle-ci révèle le chemin allant de l'appel de la fonction jusqu'a la racine. Par exemple, il est possible d'étendre l'entrée pour <code>bubbleSort()</code> :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10983/perf-call-tree-expanded-bubblesort.png" style="display: block; height: 512px; margin-left: auto; margin-right: auto; width: 1054px;"></p>
+
+<p>On peut donc voir que le graphique d'appel est comme ceci :</p>
+
+<pre>sortAll()
+
+    -&gt; sort()
+
+        -&gt; bubbleSort()</pre>
+
+<p>Notez également que le <em>Cout individuel </em>pour <code>sort()</code> est ici de 1.45%, et notez également que ce chiffre est le même pour une autre ligne de <code>sort()</code> plus tard dans la liste. Cela révèle que quelques échantillons ont été pris dans <code>sort()</code> elle-même plutôt que dans la fonction qu'elle appelle.</p>
+
+<p>Quelques fois, il y a plus d'un chemin menant à la même fonction. Essayons par exemple d'étendre la ligne de <code>swap()</code>:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10985/perf-call-tree-expanded-sawp.png" style="display: block; height: 636px; margin-left: auto; margin-right: auto; width: 1052px;"></p>
+
+<p>Il y a 253 échantillons qui ont été pris à l'intérieur de<code> swap()</code>. Mais <code>swap()</code> a été accédé par deux chemins différents car <code>bubbleSort()</code> <code>et selectionSort()</code> l'utilisent tous deux. Il est également possible de voir que 252 des 253 échantillons ont été pris dans la branche <code>bubbleSort()</code>, et uniquement un dans la branche <code>selectionSort()</code>.</p>
+
+<p>Cela signifie que le tri à bulle est encore moins efficient que ce que l'on pensait ! La fonction coute 252 échantillons de plus, soit 10% de cout supplémentaire.</p>
+
+<p>Avec ce genre de recherche, il est possible de déduire le graphique d'appel complet, avec le nombre d'échantillons associés :</p>
+
+<pre>sortAll()                         //    8
+
+    -&gt; sort()                     //   37
+
+        -&gt; bubbleSort()           // 1345
+
+            -&gt; swap()             //  252
+
+        -&gt; selectionSort()        //  190
+
+            -&gt; swap()             //    1
+
+        -&gt; quickSort()            //  103
+
+            -&gt; partition()        //   12</pre>
+
+<h2 id="Données_de_la_plateforme">Données de la plateforme</h2>
+
+<p>Vous pouvez également remarquer des lignes nommées <em>Gecko</em>, <em>Input &amp; Events</em>, et ainsi de suite. Cela représente les appels internes au navigateur.</p>
+
+<p>Cela peut être utile comme informations. Par exemple si votre site donne beaucoup de travail au navigateur. Ces échantillons ne sont peut-être pas pris dans votre code, mais c'est quand même votre problème.</p>
+
+<p>Dans notre exemple, il y a 679 échantillons assignés à <em>Gecko </em>- le deuxième plus gros groupe après <code>bubbleSort()</code>. étendons donc cela :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10987/perf-call-tree-expanded-gecko.png" style="display: block; height: 478px; margin-left: auto; margin-right: auto; width: 1050px;"></p>
+
+<p>Cela révèle que 614 de ces échantillons, soit environ 20% du cout total, viennent de l'appel de <code>sort()</code>. Si nous regardons au code de la fonction, il devient évident que le cout élevé des données de plateforme viennent des appels répétés à <code>console.log()</code>:</p>
+
+<pre class="brush: js">function sort(unsorted) {
+  console.log(bubbleSort(unsorted));
+  console.log(selectionSort(unsorted));
+  console.log(quickSort(unsorted));
+}</pre>
+
+<p>Il serait certainement intéressant de considérer des façons plus efficientes d'implémenter cela.</p>
+
+<p>Une chose à garder en tête est que les périodes d'inactivité sont classifiées en tant que <em>Gecko</em>, donc les parties de votre profil où votre JavaScript ne tourne pas contribueront aux échantillons <em>Gecko</em>. Ces échantillons n'impactent pas la performance de votre site.</p>
+
+<div class="note">
+<p>Par défaut, l'arbre d'appel ne sépare par les données de plateforme dans des fonctions séparées, car elles ajoutent beaucoup de nuisance et ces détails ont peu de chances d'être utiles à des personnes ne travaillant sur le développement de Firefox. Si vous voulez cependant voir ces détails, il faut cocher l'option "Afficher les données de la plateforme Gecko" dans les <a href="/fr/docs/Tools/Performance/UI_Tour#Toolbar">options</a>.</p>
+</div>
+
+<p> </p>
+
+<h2 id="Utiliser_un_arbre_inversé_(_Bottom-Up)">Utiliser un arbre inversé ( Bottom-Up)</h2>
+
+<p>Un arbre d'appel inversé, inverse l'ordre de toutes les piles, en mettant la fonction la plus loin dans l'arbre au début. La conséquence directe est que cette vue se focalise plus sur l'information <em>Durée Individuelle</em>. Cette vue est pratique pour trouver les points "chauds" du code.</p>
+
+<p>Pour afficher cette vue, cliquer sur l'icône en forme d'engrenage dans la partie droite et de cliquer sur <strong>L'arbre d'appel</strong>.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/16093/performance_menu_invert_call_tree.png" style="border-style: solid; border-width: 1px; display: block; height: 201px; margin: 0 auto; width: 492px;"></p>
diff --git a/files/fr/tools/performance/examples/index.html b/files/fr/tools/performance/examples/index.html
new file mode 100644
index 0000000000..e3ca28d9bd
--- /dev/null
+++ b/files/fr/tools/performance/examples/index.html
@@ -0,0 +1,8 @@
+---
+title: Exemples
+slug: Outils/Performance/Examples
+translation_of: Tools/Performance/Examples
+---
+<div>{{ToolsSidebar}}</div><p>Liste des pages de démos pour les scénarios de performances et walkthroughs.</p>
+
+<p>{{ ListSubpages ("/en-US/docs/Tools/Performance/Examples", 5) }}</p>
diff --git a/files/fr/tools/performance/examples/sorting_algorithms_comparison/index.html b/files/fr/tools/performance/examples/sorting_algorithms_comparison/index.html
new file mode 100644
index 0000000000..608691a9d5
--- /dev/null
+++ b/files/fr/tools/performance/examples/sorting_algorithms_comparison/index.html
@@ -0,0 +1,71 @@
+---
+title: Comparaison des algorithmes de tri
+slug: Outils/Performance/Examples/Sorting_algorithms_comparison
+translation_of: Tools/Performance/Examples/Sorting_algorithms_comparison
+---
+<div>{{ToolsSidebar}}</div><p>Ce articlé décrit un programe simple qui est utilisé dans deux des guides de l'outil Performance : le guide pour <a href="/fr/docs/Tools/Performance/Call_Tree">l'arbre d'appel</a> et le guide pour le <a href="/fr/docs/Tools/Performance/Flame_Chart">diagramme de flamme</a>.</p>
+
+<p>Ce programme compare les performances de trois algorithmes de tri différents :</p>
+
+<ul>
+ <li>le tri à bulles</li>
+ <li>le tri par sélection</li>
+ <li>le Ttri rapide</li>
+</ul>
+
+<p>Ce programme est composé des fonctions suivantes :</p>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <td><strong><code>sortAll()</code></strong></td>
+   <td>Fonction principale. génère itérativement (200 itérations) des tableaux aléatoires et appelle<code>sort()</code>.</td>
+  </tr>
+  <tr>
+   <td><strong><code>sort()</code></strong></td>
+   <td>Appelle les fonctions <code>bubbleSort()</code>, <code>selectionSort()</code>, et <code>quickSort()</code> tour à tour et affiche le résultat.</td>
+  </tr>
+  <tr>
+   <td><strong><code>bubbleSort()</code></strong></td>
+   <td>Implémente un tri à bulles, retourne le tableau trié</td>
+  </tr>
+  <tr>
+   <td><strong><code>selectionSort()</code></strong></td>
+   <td>Implémente un par sélection retourne le tableau trié</td>
+  </tr>
+  <tr>
+   <td><strong><code>quickSort()</code></strong></td>
+   <td>Implémente un tri rapide, retourne le tableau trié</td>
+  </tr>
+  <tr>
+   <td><code><strong>swap()</strong></code></td>
+   <td>fonction d'aide pour <code>bubbleSort()</code> et <code>selectionSort()</code>.</td>
+  </tr>
+  <tr>
+   <td><code><strong>partition()</strong></code></td>
+   <td>fonction d'aide pour <code>quickSort()</code>.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>le graphique d'appel ressemble à ceci :</p>
+
+<pre>sortAll()                     // (génère un tableau aléatoire puis appelle sort) x 200
+
+    -&gt; sort()                 // tri le tableau avec chaque tri et affiche le résultat
+
+        -&gt; bubbleSort()
+
+            -&gt; swap()
+
+        -&gt; selectionSort()
+
+            -&gt; swap()
+
+        -&gt; quickSort()
+
+            -&gt; partition()</pre>
+
+<p>Les implémentations des algorithmes de tri dans ce programme ont été tirées du dépôt <a href="https://github.com/nzakas/computer-science-in-javascript/">https://github.com/nzakas/computer-science-in-javascript/</a> et sont utilisées sous la licence MIT.</p>
+
+<p>Vous pouvez tester ce programme d'exemple <a href="https://mdn.github.io/performance-scenarios/js-call-tree-1/index.html">ici</a> et cloner le code <a href="https://github.com/mdn/performance-scenarios">ici</a> (soyez sûr de bien check out la branche gh-pages).</p>
diff --git a/files/fr/tools/performance/flame_chart/index.html b/files/fr/tools/performance/flame_chart/index.html
new file mode 100644
index 0000000000..0bcb285b4d
--- /dev/null
+++ b/files/fr/tools/performance/flame_chart/index.html
@@ -0,0 +1,103 @@
+---
+title: Flame Chart
+slug: Outils/Performance/Flame_Chart
+translation_of: Tools/Performance/Flame_Chart
+---
+<div>{{ToolsSidebar}}</div><div class="summary">
+<p>Le Flame Chart affiche l'état de la pile JavaScript de votre code à chaque milliseconde durant le profil de performance.</p>
+
+<p>Cela permet de savoir exactement quelle fonction s'est exécutée à un moment donné dans l’enregistrement, combien de temps elle a mis, et d'où elle a été appelée.</p>
+</div>
+
+<p>L'Arbre d'appel et le Flame Chart sont tous deux utilisés pour analyser les performances du code JavaScript de pages web. Et ils utilisent tous deux les mêmes données : des échantillons de la pile du moteur JavaScript, pris périodiquement durant l'enregistrement.</p>
+
+<p>Cependant, tandis que le Call Tree organise ces données pour mettre en évidence les endroits où le code passe le plus de temps, de manière cohérente à travers tout l'enregistrement, le Flame Chart lui utilise ces données pour afficher où exactement dans l'enregistrement les fonctions s'exécutent. Essentiellement, il affiche l'état de la pile d'appel à n’importe quel point donné de l'enregistrement.</p>
+
+<p>Voici une capture d'écran montrant le Flame Chart pour une section d'un profil :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10989/perf-flame-chart-overview.png" style="display: block; height: 622px; margin-left: auto; margin-right: auto; width: 1676px;"></p>
+
+<p>Tout d'abord, vous pouvez remarquer que dans le <a href="/fr/docs/Tools/Performance/UI_Tour#Recording_overview">panneau de vue globale de l'enregistrement</a>. Ici, une petite partie de l'enregistrement est sélectionné et affiché dans le Flame Chart. Le Flame Chart affiche beaucoup de données, donc pour obtenir des résultats pertinents, il est souvent nécessaire de zoomer.</p>
+
+<p>Dans la vue du Flame Chart, l'axe X représente le temps. La capture d'écran couvre la période de 1435ms à un peu plus de 1465ms. Sur l'axe Y, on trouve les fonctions de la pile d'appel à ce point dans le temps, avec le haut niveau en haut, et les fonctions filles en bas. Les fonctions ont un code couleur pour pouvoir les distinguer facilement.</p>
+
+<p>Cela fournit une façon de savoir à tout moment de l'enregistrement quelles fonctions sont exécutées, quand et pendant combien de temps, et également d'où elles ont été appelées.</p>
+
+<h2 id="Zoomer_et_faire_un_panoramique">Zoomer et faire un panoramique</h2>
+
+<p>Pour travailler efficacement avec le Flame Chart, il est nécessaire de pouvoir naviguer dedans. Il existe deux contrôles principaux pour naviguer dans le Flame Chart :</p>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <td><strong>Zoom </strong>: Augmente/diminue la portion du profil sélectionné qui est affiché dans le Flame Chart</td>
+   <td>
+    <p>1) Souris : mollette vers le haut ou vers le bas dans le Flame Chart.</p>
+
+    <p>2) Pavé tactile : deux doigts vers le haut ou vers le bas dans le Flame Chart.</p>
+   </td>
+  </tr>
+  <tr>
+   <td><strong>Déplacement </strong>: Déplace la portion du profil sélectionné qui est affiché dans le Flame Chart</td>
+   <td>
+    <p>1) Clic puis glissement de la partie sélectionnée dans le <a href="/fr/docs/Tools/Performance/UI_Tour#Recording_overview">panneau de la vue d'ensemble de l'enregistrement</a>.</p>
+
+    <p>2) Clic puis glissement n'importe où dans le Flame Chart (attention, cliquer dans le panneau de vue d'ensemble à l’extérieur de la partie sélectionnée entraînera une nouvelle sélection)</p>
+   </td>
+  </tr>
+ </tbody>
+</table>
+
+<p>{{EmbedYouTube("BzfkBRFucp8")}}</p>
+
+<h2 id="Exemple">Exemple</h2>
+
+<p>Afin de voir comment le Flame Chart peut révéler le comportement d'un programme, nous utiliserons cet exemple simple. Nous utilisons le même programme dans la page de <a href="/fr/docs/Tools/Performance/Call_Tree">L'Arbre d'appel</a>. Il s'agit d'un programme qui compare trois algorithmes de tri différents. Il existe une <a href="/fr/docs/Tools/Performance/Examples/Sorting_algorithms_comparison">page séparée</a> qui fournit une vue d'ensemble de la structure du programme.</p>
+
+<p>Nous utiliserons le même profil que celui utilisé sur la page de l'Arbre d'appel. Le graphique d'appel et le nombre d'échantillons associé ressemblent à ceci :</p>
+
+<pre>sortAll()                         //    8
+
+    -&gt; sort()                     //   37
+
+        -&gt; bubbleSort()           // 1345
+
+            -&gt; swap()             //  252
+
+        -&gt; selectionSort()        //  190
+
+            -&gt; swap()             //    1
+
+        -&gt; quickSort()            //  103
+
+            -&gt; partition()        //   12</pre>
+
+<p>Tout d'abord, sélectionnons toute la partie durant laquelle le programme était actif :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10991/perf-flame-chart-zoomed-out.png" style="display: block; height: 350px; margin-left: auto; margin-right: auto; width: 1212px;"></p>
+
+<p>L'appel<code>sortAll()</code>, tout en haut et coloré en mauve court du début du programme à la fin. En dessous, on trouve en couleur olive les appels que cette fonction fait à <code>sort()</code>. Encore en dessous, comme les dents d'une scie, on trouve les appels à chacun des algorithmes de tri.</p>
+
+<p>Zoomons un peu :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10993/perf-flame-chart-zoom-1.png" style="display: block; height: 350px; margin-left: auto; margin-right: auto; width: 1212px;"></p>
+
+<p>Cette partie dure à peu près 140ms, et montre plus de détails sur les fonctions appelées par <code>sort()</code>. Le code de <code>sort()</code> est celui-ci :</p>
+
+<pre class="brush: js">function sort(unsorted) {
+  console.log(bubbleSort(unsorted));
+  console.log(selectionSort(unsorted));
+  console.log(quickSort(unsorted));
+}</pre>
+
+<p>Les boites intitulées "bubb..." et colorées en vert olive sont vraisemblablement des <code>bubbleSort()</code>. Les boites colorées en vert sont vraisemblablement les autres fonctions de tri. Même au premier regard, il parait évident que les boites du tri à bulle sont bien plus grosses (et donc durent plus longtemps) que les autres.</p>
+
+<p>Nous pouvons également voir quelques fonctions appelées par <code>bubbleSort()</code>, en violet.</p>
+
+<p>Zoomons une deuxième fois :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10995/perf-flame-chart-zoom-2.png" style="display: block; height: 348px; margin-left: auto; margin-right: auto; width: 1212px;"></p>
+
+<p>Cette partie dure environ 20ms. Nous pouvons voir que les boites violettes en dessous de <code>bubbleSort()</code> sont les appels à <code>swap()</code>. Si voulions tous les compter, l'Arbre d'appel nous dirait facilement qu'il en existe 253 (le nombre d'échantillons pris dans cette fonction) . Tous les échantillons dans cette portion sont en dessous de <code>bubbleSort()</code>, mais l'on peut voir dans l'arbre d'appel que le profil contient un appel dans <code>selectionSort()</code>.</p>
+
+<p>Nous pouvons également voir que deux des boites vertes correspondent à <code>selectionSort()</code> et <code>quickSort()</code>, mais que les autres boites vertes correspondent à des appels à la plate-forme Gecko. Il est très probable qu'il s’agisse des <code>console.log()</code> dans <code>sort()</code>.</p>
diff --git a/files/fr/tools/performance/frame_rate/index.html b/files/fr/tools/performance/frame_rate/index.html
new file mode 100644
index 0000000000..3f4c5016f0
--- /dev/null
+++ b/files/fr/tools/performance/frame_rate/index.html
@@ -0,0 +1,58 @@
+---
+title: Frame rate
+slug: Outils/Performance/Frame_rate
+translation_of: Tools/Performance/Frame_rate
+---
+<div>{{ToolsSidebar}}</div><div class="summary">
+<p>Le Frame rate est une unité de mesure de la réactivité des sites web en frames par seconde (fps). Un frame rate faible ou extrêmement variable peut donner l'impression qu'un site ne répond pas ou est de mauvaise qualité. Cela donne une mauvaise expérience utilisateur.</p>
+
+<p><strong>Un frame rate de 60fps est la cible idéale pour des performances fluides, cela donne un budget temps de 16.7ms pour effectuer tous les changements en réponse à un évènement.</strong></p>
+
+<p>Le graphique du frame rate dans l'outil Performance affiche le frame rate au cours de l'enregistrement. Cela donne une indication rapide d'où se situent les problèmes dans le site analysé, et permet d'utiliser d'autres outils pour une analyse plus approfondie.</p>
+</div>
+
+<h2 id="Frame_rate_et_réactivité">Frame rate et réactivité</h2>
+
+<p>Le Frame rate est la vitesse à laquelle un appareil vidéo peut produire des images (frames). Cette unité est très utilisée dans les films ou les jeux vidéos, mais est maintenant utilisée couramment comme indicateur de performance pour les sites web et les applications web.</p>
+
+<p>Dans le domaine de la performance web, une frame englobe tout le travail que doit faire le navigateur afin de mettre à jour et de repeindre l'écran. Le frame rate est évidemment applicable aux animations : si le frame rate est trop bas, une animation aura l'air saccadée, alors qu'avec un frame rate élevée, elle sera fluide. Mais le frame rate est également utile en temps qu'indicateur de performance générale de la réactivité d'un site web lorsqu’un utilisateur interagit avec.</p>
+
+<p>Par exemple, si déplacer la souris au-dessus d'un élément de la page active du code JavaScript qui change l'apparence de l'élément et déclenche ainsi un reflow et un repaint, alors tout le travail doit être complété dans la même frame. Si l'opération prend trop de temps au navigateur, alors celui-ci apparaitra momentanément non réactif.</p>
+
+<p>Similairement, si faire défiler une page implique un grand nombre de mises à jour complexes et que le navigateur ne peut alors pas garder un frame rate décent, alors le navigateur sera saccadé et sera occasionnellement bloqué (freeze).</p>
+
+<p>En général, un frame rate constant et élevé rendra les interactions de l'utilisateur plus agréables.</p>
+
+<div class="note">
+<p>Un frame rate de 60fps est reconnu comme le saint Graal de la performance. Cela donne un budget temps de 16.7ms pour toutes les opérations à effectuer dans une frame.</p>
+
+<p>Cependant, la constance est très importante, surtout si le frame rate ne peut pas être de 60fps. Il est recommandé d'avoir un frame rate moins élevé, mais plus constant afin d’éviter des différences de réactivité brusques.</p>
+</div>
+
+<h2 id="Graphique_du_Frame_rate">Graphique du Frame rate</h2>
+
+<p>Le graphique du frame rate se trouve dans la <a href="/fr/docs/Tools/Performance/UI_Tour#Recording_overview">vue d'ensemble de l'enregistrement</a> de l'outil Performance. Il prend un simple timestamp lorsque le navigateur finit une frame, et l'utilise pour connaitre le frame rate tout au long de l'enregistrement.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11025/perf-frame-rate.png" style="display: block; height: 66px; margin-left: auto; margin-right: auto; width: 900px;">L'axe X est le temps dans le profil. Il y a trois annotations : le frame rate maximum, le frame rate minimum, et le frame rate moyen.</p>
+
+<h2 id="Utiliser_le_graphique_du_frame_rate">Utiliser le graphique du frame rate</h2>
+
+<p>Le principal intérêt de ce graphique est que tout comme la <a href="/fr/docs/Tools/Web_Console">Console web</a>, il donne une indication rapide d'ou le site peut avoir des problèmes et permet une analyse plus approfondie par d'autres outils. Voici par exemple une capture d'écran d'un profil de performance :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11023/perf-fr-waterfall.png" style="display: block; height: 413px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Il est possible de voir que le frame rate moyen est raisonnable, mais qu'il existe cependant trois endroits où le frame rate s'effondre pendant 10 millisecondes. Cela causera certainement un freeze considérable dans les animations de la page.</p>
+
+<p>Le graphique du frame rate est en relation avec la <a href="/fr/docs/Tools/Performance/UI_Tour#Waterfall_overview">vue d'ensemble de la Chronologie</a> et celle-ci est affichée directement au-dessus. Il est donc possible de voir que les chutes correspondent aux barres orange qui dénotent le temps passé à exécuter du JavaScript.</p>
+
+<p>Sélectioner une partie de l'enregistrement contenant une chute permet de zoomer sur cette partie. La vue principale de la <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a> en dessous affiche alors les informations de cette portion uniquement. Il est alors possible de trouver le coupable :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11027/perf-zoom.png" style="display: block; height: 504px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Il y a ici une fonction JavaScript exécutée à la suite d'un évènement de clic qui bloque le processus principal pendant 170 millisecondes.</p>
+
+<p>Pour savoir de quelle fonction il s'agit exactement, il faut passer au <a href="/fr/docs/Tools/Performance/Flame_Chart">Flame Chart (Graphique JS)</a> pour voir la pile d'appels à ce moment donné :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11021/perf-fr-flame-chart.png" style="display: block; height: 413px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>La fonction coupable est <code>doPointlessComputations()</code>, et est définie dans "main.js". Pour régler ce problème, il est possible de séparer cette fonction en plusieurs parties et d'exécuter ces parties dans <code><a href="/fr/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame</a></code>, ou bien même d'exécuter la fonction dans un <a href="/fr/docs/Web/API/Web_Workers_API/Using_web_workers">worker</a>. L'article <a href="/fr/docs/Tools/Performance/Scenarios/Intensive_JavaScript">JavaScript intensif</a> expose des stratégies pour résoudre ce genre de problèmes.</p>
diff --git a/files/fr/tools/performance/how_to/index.html b/files/fr/tools/performance/how_to/index.html
new file mode 100644
index 0000000000..f7cd86402f
--- /dev/null
+++ b/files/fr/tools/performance/how_to/index.html
@@ -0,0 +1,63 @@
+---
+title: Comment faire ?
+slug: Outils/Performance/How_to
+translation_of: Tools/Performance/How_to
+---
+<div>{{ToolsSidebar}}</div><h2 id="Ouvrir_l'outil_Performance">Ouvrir l'outil Performance</h2>
+
+<p>Pour ouvrir l'outil Performance, il existe plusieurs possibilités :</p>
+
+<ul>
+ <li>Utiliser le raccourci clavier Maj + F5.</li>
+ <li>Selectioner "Performances" depuis le menu "Développement" présent dans le menu de Firefox (ou du menu outils sous OS X).</li>
+ <li>Ouvrir la <a href="/fr/docs/Outils/Outils_boite_%C3%A0_outils">boite à outils</a> (F12).</li>
+ <li>Sélectionner l’icône de l'outil depuis la barre d'outils si vous en avez une :<img alt="" src="https://m311pxdn.mozillademos.org/files/10997/devtools-button.png" style="height: 76px; width: 728px;"></li>
+</ul>
+
+<h2 id="Enregistrer_un_profil">Enregistrer un profil</h2>
+
+<p>Pour commencer un nouvel enregistrement, il faut presser sur le bouton en forme de chronomètre dans le panneau des enregistrements. Pour arrêter l'enregistrement, il suffit d'appuyer à nouveau sur le bouton :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13230/perf-record.png" style="display: block; height: 346px; margin-left: auto; margin-right: auto; width: 744px;"></p>
+
+<p>Il est également possible de démarrer et d'arrêter un enregistrement depuis la Console Web, en utilisant <code><a href="/fr/docs/Web/API/Console/profile">console.profile()</a></code> et <code><a href="/fr/docs/Web/API/Console/profileEnd">console.profileEnd()</a></code>.</p>
+
+<h2 id="Sauvegarder_un_profil">Sauvegarder un profil</h2>
+
+<p>Pour sauvegarder un profil, il faut cliquer sur le lien "Enregistrer" dans le tableau des enregistrements :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13232/perf-save.png" style="display: block; height: 311px; margin-left: auto; margin-right: auto; width: 733px;"></p>
+
+<h2 id="Charger_un_profil">Charger un profil</h2>
+
+<p>Pour charger un profil, il suffit de cliquer sur "Importer..." et sélectionner le fichier :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13226/perf-load.png" style="display: block; height: 622px; margin-left: auto; margin-right: auto; width: 733px;"></p>
+
+<h2 id="Effacer_tous_les_profils_chargés">Effacer tous les profils chargés</h2>
+
+<p>Pour effacer tous les profils chargés, il faut cliquer sur "Effacer".</p>
+
+<div class="note">
+<p>Attention, cette action entrainera la perte de tout profil non sauvegardé</p>
+</div>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13224/perf-clear.png" style="display: block; height: 311px; margin-left: auto; margin-right: auto; width: 733px;"></p>
+
+<h2 id="Sélectioner_un_outil">Sélectioner un outil</h2>
+
+<p>Les outils <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a>, <a href="/fr/docs/Tools/Performance/Call_Tree">Arbre d'appel</a>, et <a href="/fr/docs/Tools/Performance/Flame_Chart">Flame Chart (Graphique JS)</a> proposent chacun une méthode de visualisation différente. Pour passer de l'une à l'autre, il faut utiliser leurs boutons associés :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13234/perf-select.png" style="display: block; height: 311px; margin-left: auto; margin-right: auto; width: 733px;"></p>
+
+<h2 id="Configurer_les_données_affichées">Configurer les données affichées</h2>
+
+<p>Pour contrôler quels types de données sont affichées dans la chronologie, il faut utiliser ce bouton :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13228/perf-markers.png" style="display: block; height: 311px; margin-left: auto; margin-right: auto; width: 733px;"></p>
+
+<h2 id="Zoomer">Zoomer</h2>
+
+<p>Pour zoomer sur une partie de l'enregistrement, il faut sélectionner cette partie dans la vue d'ensemble :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13236/perf-zoom.png" style="display: block; height: 311px; margin-left: auto; margin-right: auto; width: 733px;"></p>
diff --git a/files/fr/tools/performance/index.html b/files/fr/tools/performance/index.html
new file mode 100644
index 0000000000..503820e30f
--- /dev/null
+++ b/files/fr/tools/performance/index.html
@@ -0,0 +1,94 @@
+---
+title: Performance
+slug: Outils/Performance
+translation_of: Tools/Performance
+---
+<div>{{ToolsSidebar}}</div>
+
+<p>L'outil Performance donne un aperçu de : la réactivité générale du site, la performance de son code JavaScript et de la performance du layout (disposition). Cet outil permet de réaliser un enregistrement (appelé profil) d'un site sur une période donnée. L'outil montre alors une <a href="/fr/docs/Tools/Performance/UI_Tour#Waterfall_overview">vue d'ensemble</a> des opérations que le navigateur a effectuées pour afficher le site durant le profil. Un graphique du <a href="/fr/docs/Tools/Performance/Frame_rate">frame rate</a> lors du profil est également affiché.</p>
+
+<p>Il existe quatre sous-outils pour examiner les différents aspects du profil en détail :</p>
+
+<ul>
+ <li>La <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a> révèle les différentes opérations que le navigateur fait, par exemple l'exécution de JavaScript ou de layout, les repaints ou bien même la garbage collection</li>
+ <li><a href="/fr/docs/Tools/Performance/Call_Tree">L'Arbre d'appels</a> met en évidence les fonctions JavaScripts dans lesquels le navigateur passe le plus de temps.</li>
+ <li>Le <a href="/fr/docs/Tools/Performance/Flame_Chart">Graphique JS (Flame Chart)</a> montre la pile d'appels JavaScript durant l'enregistrement.</li>
+ <li>La vue <a href="/fr/docs/Tools/Performance/Allocations">Allocations</a> affiche les allocations faites par le code tout au long de l'enregistrement. Cette vue n'apparait que si vous avez coché l'option « Enregistrer les allocations » dans les outils de développement.</li>
+</ul>
+
+<p>{{EmbedYouTube("WBmttwfA_k8")}}</p>
+
+<hr>
+<h2 id="Débuter">Débuter</h2>
+
+<div class="column-container">
+<div class="column-half">
+<dl>
+ <dt><a href="/fr/docs/Tools/Performance/UI_Tour">UI Tour</a></dt>
+ <dd>
+ <p>Une visite guidée rapide pour s'y retrouver dans l'interface.</p>
+ </dd>
+</dl>
+</div>
+
+<div class="column-half">
+<dl>
+ <dt><a href="/fr/docs/Tools/Performance/How_to">Comment faire ?</a></dt>
+ <dd>Tutoriels pour les tâches de base : ouverture de l'outil, création, sauvegarde, chargement et configuration des enregistrements.</dd>
+</dl>
+</div>
+</div>
+
+<hr>
+<h2 id="Composants_de_l'outil_Performance">Composants de l'outil Performance</h2>
+
+<div class="column-container">
+<div class="column-half">
+<dl>
+ <dt><a href="/fr/docs/Tools/Performance/Frame_rate">Frame rate</a></dt>
+ <dd>Comprendre la réactivité générale des sites.</dd>
+ <dt><a href="/fr/docs/Tools/Performance/Call_Tree">Arbre d'appel</a></dt>
+ <dd>Trouver les points noirs dans le code JavaScript d'un site.</dd>
+ <dt><a href="/fr/docs/Tools/Performance/Allocations">Allocations</a></dt>
+ <dd>Afficher les allocations faites par le code tout au long de l'enregistrement.</dd>
+</dl>
+</div>
+
+<div class="column-half">
+<dl>
+ <dt><a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a></dt>
+ <dd>Comprendre les opérations que fait le navigateur pendant que l'utilisateur interagit avec un site.</dd>
+ <dt><a href="/fr/docs/Tools/Performance/Flame_Chart">Graphique JS</a></dt>
+ <dd>Voir quelles fonctions JavaScript s'exécutent et quand elles s'exécutent pendant toute la durée de l'enregistrement.</dd>
+ <dd></dd>
+</dl>
+</div>
+</div>
+
+<hr>
+<h2 id="Scenarios">Scenarios</h2>
+
+<div class="column-container">
+<div class="column-half">
+<dl>
+ <dt><a href="/fr/docs/Tools/Performance/Scenarios/Animating_CSS_properties">Animer des propriétés CSS</a></dt>
+ <dd>Utiliser l'arbre d'appel pour comprendre comme le navigateur met à jour une page, et comment différentes animations de propriétés CSS peuvent impacter la performance.</dd>
+ <dd></dd>
+</dl>
+</div>
+
+<div class="column-half">
+<dl>
+ <dt><a href="/fr/docs/Tools/Performance/Scenarios/Intensive_JavaScript">JavaScript intensif</a></dt>
+ <dd>Utiliser le frame rate et l'arbre d'appel pour mettre en évidence les problèmes causés par du JavaScript à longue exécution et comment l'utilisation des workers peut aider à résoudre cette situation..</dd>
+</dl>
+</div>
+</div>
+
+
+
+<div class="column-half">
+<dl>
+ <dd></dd>
+</dl>
+</div>
diff --git a/files/fr/tools/performance/scenarios/animating_css_properties/index.html b/files/fr/tools/performance/scenarios/animating_css_properties/index.html
new file mode 100644
index 0000000000..b2767f6b32
--- /dev/null
+++ b/files/fr/tools/performance/scenarios/animating_css_properties/index.html
@@ -0,0 +1,154 @@
+---
+title: Animer des propriétés CSS
+slug: Outils/Performance/Scenarios/Animating_CSS_properties
+translation_of: Tools/Performance/Scenarios/Animating_CSS_properties
+---
+<div>{{ToolsSidebar}}</div>
+
+<div class="summary">
+<p>Le cout en performance des animations CSS peuvent varier d'une propriété à une autre, et animer des propriétés couteuses peut résulter en un ralentissement/blocage du navigateur (<a href="/fr/docs/Glossary/Jank">jank</a>) tandis que le navigateur se débat pour obtenir un frame rate fluide.</p>
+
+<p>Le <a href="/fr/docs/Tools/Performance/Frame_rate">Frame rate</a> et la <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a> peuvent fournir des renseignements sur les opérations que fait le navigateur lors d'une animation CSS, dans le but d'aider à diagnostiquer les problèmes de performances.</p>
+</div>
+
+<p>Avec les <a href="/fr/docs/Web/Guide/CSS/Using_CSS_animations">animations CSS</a>, il est possible de spécifier un nombre <a href="/fr/docs/Web/CSS/@keyframes">keyframes</a>, chacune de celle-ci utilisent du CSS pour définir l'apparence d'un élément à un moment donné de l'animation. Le navigateur crée l'animation comme étant une transition d'une keyframe à une autre.</p>
+
+<p>Comparées à l'animation via JavaScript, les animations CSS peuvent être plus faciles à créer. Elles peuvent également donner de meilleures performances, car elles donnent plus de contrôle au navigateur pour afficher les frames au bon moment et les supprimer si nécessaire.</p>
+
+<p>Cependant, le cout en performances de la modification des propriétés CSS varient d'une propriété à une autre. Animer des propriétés couteuses peut résulter en un ralentissement/blocage du navigateur (<a href="/fr/docs/Glossary/Jank">jank</a>) tandis que le navigateur se débat pour obtenir un frame rate fluide.</p>
+
+<h2 id="La_chronologie_du_rendu_CSS">La chronologie du rendu CSS</h2>
+
+<p>Le processus que le navigateur utilise pour mettre à jour la page lorsqu'une propriété CSS a changé peut être décrit comme une chronologie consistant des étapes suivantes :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10821/css-rendering-waterfall.png" style="display: block; height: 203px; margin-left: auto; margin-right: auto; width: 546px;"></p>
+
+<ol>
+ <li><strong>Recalculate Style (recalculer le style) </strong>: à chaque fois qu'une propriété CSS d'un élément change, le navigateur doit recalculer les styles calculés.</li>
+ <li><strong>Layout (disposition) </strong>: ensuite, le navigateur utilise les styles calculés pour trouver la position et la géométrie des éléments. Cette opération est appelée "layout" mais peut être également appelée "reflow".</li>
+ <li><strong>Paint</strong> (affichage) : enfin, le navigateur doit repeindre les éléments à l'écran. Une dernière étape qui n'est pas montrée dans cette séquence : la page peut être séparée en calques qui sont affichés indépendamment, puis combinés dans un processus appelé "Composition".</li>
+</ol>
+
+<p>Cette séquence doit tenir dans une seule frame, vu que l'écran n'est pas mis à jour avant sa complétion. Il est généralement accepté que 60 frames par secondes est le frame rate auquel les animations apparaitront fluides. Un frame rate de 60 frames par secondes (fps) donne au navigateur 16.7 millisecondes pour exécuter entièrement cette séquence.</p>
+
+<h2 id="Cout_des_propriétés_CSS">Cout des propriétés CSS</h2>
+
+<p>Lors de l'exécution de la chronologie du rendu CSS, certaines propriétés sont plus couteuses que d'autres :</p>
+
+<table class="fullwidth-table standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Nom de la propriété</th>
+   <th scope="col">Cout</th>
+   <th scope="col">Exemples</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>Les propriétés qui impactent la forme d'un élément ou sa position déclenchent une recalculation du style, une disposition, et un repaint.</td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10827/recalculate-style.png" style="height: 26px; width: 123px;"> <img alt="" src="https://mdn.mozillademos.org/files/10825/layout.png" style="height: 26px; width: 123px;"> <img alt="" src="https://mdn.mozillademos.org/files/10823/paint.png" style="height: 26px; width: 123px;"></td>
+   <td>
+    <p><code><a href="/fr/docs/Web/CSS/left">left</a></code><br>
+     <code><a href="/fr/docs/Web/CSS/max-width">max-width</a></code><br>
+     <code><a href="/fr/docs/Web/CSS/border-width">border-width</a></code><br>
+     <code><a href="/fr/docs/Web/CSS/margin-left">margin-left</a></code><br>
+     <code><a href="/fr/docs/Web/CSS/font-size">font-size</a></code></p>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p>Les propriétés qui n'impactent pas la forme d'un élément ou sa position, mais qui ne sont pas dans leur propre calque, ne déclenchent pas de disposition (layout)</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10827/recalculate-style.png" style="height: 26px; width: 123px;"> <img alt="" src="https://mdn.mozillademos.org/files/10835/layout-faint.png" style="height: 52px; width: 123px;"> <img alt="" src="https://mdn.mozillademos.org/files/10823/paint.png" style="height: 26px; width: 123px;"></td>
+   <td>
+    <p><code><a href="/fr/docs/Web/CSS/color">color</a></code></p>
+   </td>
+  </tr>
+  <tr>
+   <td>Les propriétés dans leur propre calque ne déclenchent même pas un repaint, car la mise à jour est gérée dans la composition.</td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10827/recalculate-style.png" style="height: 26px; width: 123px;"> <img alt="" src="https://mdn.mozillademos.org/files/10835/layout-faint.png" style="height: 52px; width: 123px;"> <img alt="" src="https://mdn.mozillademos.org/files/10839/paint-faint.png" style="height: 26px; width: 123px;"></td>
+   <td><code><a href="/fr/docs/Web/CSS/transform">transform</a></code><br>
+    <code><a href="/en-US/docs/Web/CSS/opacity">opacity</a></code></td>
+  </tr>
+ </tbody>
+</table>
+
+<div class="note">
+<p>Le site web <a href="http://csstriggers.com/">CSS Triggers</a> affiche le cout pour chacune des propriétés CSS. Cela n'est valable que pour les navigateurs WebKit, mais la plupart des couts seront les mêmes dans tous les navigateurs récents.</p>
+</div>
+
+<h2 id="Example_margin_contre_transform">Example : <code>margin </code>contre <code>transform</code></h2>
+
+<p>Dans cette section, la façon dont la <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a> peut mettre en évidence la différence entre une animation utilisant <code><a href="/fr/docs/Web/CSS/margin">margin</a></code> et une utilisant <code><a href="/fr/docs/Web/CSS/transform">transform </a></code>serra démontrée.</p>
+
+<p>L'intention de ce scénario n'est pas de convaincre que l'animation en utilisant <code>margin</code> est forcement une mauvaise idée. Mais plutôt de démontrer comment les outils de développement peuvent donner une idée du travail qu'effectue le navigateur pour afficher un site web, et comment utiliser ces renseignements pour régler les problèmes de performance..</p>
+
+<p>Si vous voulez expérimenter en même temps, le site de la démo est disponible <a href="http://mdn.github.io/performance-scenarios/animation-transform-margin/index.html">ici</a>. Il ressemble à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11029/css-animations-demo.png" style="display: block; height: 677px; margin-left: auto; margin-right: auto; width: 1000px;">Le site comporte deux boutons : un pour démarrer/arrêter l'animation, et un groupe pour sélectionner le type d'animation.</p>
+
+<p>Il y a quelques éléments, et ceux-ci ont les propriétés CSS <code><a href="/fr/docs/Web/CSS/linear-gradient">linear-gradient</a></code> et <code><a href="/fr/docs/Web/CSS/box-shadow">box-shadow</a></code>, car elles sont relativement couteuses.</p>
+
+<p>Il existe également une version vidéo de cette démo.</p>
+
+<p>{{EmbedYouTube("Tvu6_j8Qzfk")}}</p>
+
+<h3 id="Animer_en_utilisant_margin">Animer en utilisant margin</h3>
+
+<p>Il faut laisser l'option "Use margin" sélectionnée, puis lancer l'animation. Il faut ensuite ouvrir l'outil Performances (maj+F5) et faire un enregistrement, seulement quelques secondes sont nécessaires.</p>
+
+<p>En ouvrant l'enregistrement, ce que vous verrez dépend grandement de votre machine et de la charge du système, mais cela devrait ressembler à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10853/margin-recording.png" style="display: block; height: 237px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Cette capture d'écran montre trois vues distinctes : une vue d'ensemble de la chronologie, le frame rate, et les détails de la frise chronologique.</p>
+
+<h4 id="Vue_densemble_de_la_chronologie">Vue d'ensemble de la chronologie</h4>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10857/margin-timeline-overview.png" style="display: block; height: 58px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Il s'agit d'une représentation compressée de la <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a>. La prédominance du vert révèle que <a href="/fr/docs/Tools/Performance/Timeline#timeline-color-coding">la page passe beaucoup de temps à peindre.</a>.</p>
+
+<h4 id="Frame_rate">Frame rate</h4>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10859/margin-frame-rate.png" style="display: block; height: 64px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Cette partie montre le <a href="/fr/docs/Tools/Performance/Frame_rate">frame rate</a>. Le frame rate moyen est de 46.67fps, bien en dessous de la cible de 60fps. Pire, le frame rate n'est pas du tout constant, avec un nombre conséquent de décentes dans les 20fps. Il est donc peu probable que l'animation soit fluide, surtout si une interaction utilisateur est ajoutée.</p>
+
+<h4 id="Chronologie">Chronologie</h4>
+
+<p>Le reste de l'enregistrement montre la vue de la chronologie. En faisant défiler un peu, on trouve le pattern suivant :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10861/margin-timeline.png" style="display: block; height: 532px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Cela représente la <a href="/fr/docs/Tools/Performance/Scenarios/Animating_CSS_properties#The_CSS_rendering_waterfall">chronologie du rendu</a>. À chaque frame de l'animation, les styles de chaque élément sont recalculés, puis composés en une seule disposition, et enfin le repaint a lieu.</p>
+
+<p>Il est facile de voir que le paint prend beaucoup de performance ici. Dans la capture d'écran ci-dessus, une opération paint est mise en surbrillance. La partie sur la droite révèle que cette opération prend 13.11ms. Avec seulement 16.7ms de budget temps par frame, il n'est pas surprenant d'avoir un frame rate si bas.</p>
+
+<p>Vous pouvez expérimenter avec l'exemple : essayez d'enlever la propriété <code>box-shadow</code> en utilisant <a href="/fr/docs/Tools/Page_Inspector/How_to/Examine_and_edit_CSS">l'Inspecteur</a>, et regardez comment cela affecte le temps que prend paint. Par la suite, nous verrons comment utiliser <code><a href="/fr/docs/Web/CSS/transform">transform</a></code> au lieu de <code><a href="/fr/docs/Web/CSS/margin">margin</a></code> élimine complètement ces paint couteux.</p>
+
+<h3 id="Animer_en_utilisant_transform">Animer en utilisant transform</h3>
+
+<p>En cliquant sélectionnant l'option "Use transform", et en effectuant un nouvel enregistrement, on obtient quelque chose ressemblant à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10863/transform-recording.png" style="display: block; height: 234px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<h4 id="Vue_densemble_de_la_chronologie_2">Vue d'ensemble de la chronologie</h4>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10869/transform-timeline-overview.png" style="display: block; height: 57px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>En comparaison avec la <a href="/fr/docs/Tools/Performance/Scenarios/Animating_CSS_properties#Waterfall_overview"> version utilisant margin</a>, on remarque beaucoup moins de vert et beaucoup plus de rose, ce qui peut être <a href="/fr/docs/Tools/Performance/Waterfall#timeline-color-coding">soit du positionnement soit de la recalculation de style.</a></p>
+
+<h4 id="Frame_rate_2">Frame rate</h4>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10865/transform-frame-rate.png" style="display: block; height: 62px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>En comparaison avec la <a href="/fr/docs/Tools/Performance/Scenarios/Animating_CSS_properties#Waterfall_overview"> version utilisant margin</a>, cela semble bien mieux. Le frame rate moyen est quasiment à 60fps et le frame rate est quasiment constant.</p>
+
+<h4 id="Chronologie_2">Chronologie</h4>
+
+<p>La frise chronologique montre la raison pour laquelle le frame rate s'est amélioré. The timeline view shows the reason for the improved frame rate. Contrairement à la <a href="/fr/docs/Tools/Performance/Scenarios/Animating_CSS_properties#Waterfall_overview"> version utilisant margin</a> aucun temps n'est dépensé dans la disposition ou dans paint :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10867/transform-timeline.png" style="display: block; height: 384px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Dans ce cas-là, utiliser <code>transform</code> a considérablement amélioré la performance du site, et l'outil de performance permet de voir comment et pourquoi.</p>
diff --git a/files/fr/tools/performance/scenarios/index.html b/files/fr/tools/performance/scenarios/index.html
new file mode 100644
index 0000000000..1b5969c1ff
--- /dev/null
+++ b/files/fr/tools/performance/scenarios/index.html
@@ -0,0 +1,8 @@
+---
+title: Scénarios
+slug: Outils/Performance/Scenarios
+tags:
+  - NeedsContent
+translation_of: Tools/Performance/Scenarios
+---
+<div>{{ToolsSidebar}}</div><p>Scénarios de performances</p>
diff --git a/files/fr/tools/performance/scenarios/intensive_javascript/index.html b/files/fr/tools/performance/scenarios/intensive_javascript/index.html
new file mode 100644
index 0000000000..9d9a2291de
--- /dev/null
+++ b/files/fr/tools/performance/scenarios/intensive_javascript/index.html
@@ -0,0 +1,231 @@
+---
+title: Intensive JavaScript
+slug: Outils/Performance/Scenarios/Intensive_JavaScript
+translation_of: Tools/Performance/Scenarios/Intensive_JavaScript
+---
+<div>{{ToolsSidebar}}</div><div class="summary">
+<p>Par défaut, le navigateur n'utilise qu'un seul thread pour exécuter tout le JavaScript d'une page et pour effectuer les layout, reflows et garbage collections. Cela signifie que les fonctions JavaScript qui mettent trop de temps à s'exécuter peuvent bloquer le thread, empêchant ainsi à la page de répondre et donnant alors une mauvaise expérience utilisateur.</p>
+
+<p>Il est possible d'utiliser les outils <a href="/fr/docs/Tools/Performance/Frame_rate">Frame rate</a> et <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a> pour repérer le code JavaScript qui cause des problèmes de performances, et pour mettre en évidence les fonctions qui demandent une attention particulière.</p>
+
+<p>Dans cet article, nous prendrons un exemple d'un site où le JavaScript cause des problèmes de réactivité, et nous utiliserons deux approches différentes pour résoudre ce problème. La première approche est de fractionner les fonctions trop gourmandes en plusieurs morceaux et d'utiliser <code><a href="/fr/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame</a></code> pour planifier l'exécution de chaque morceau. La seconde approche est d'exécuter la fonction en entier dans un thread séparé en utilisant un <a href="/fr/docs/Web/API/Web_Workers_API/Using_web_workers">web worker</a>.</p>
+</div>
+
+<p>Si vous souhaitez expérimenter par vous même tout en lisant, le site web de démonstration est disponible <a class="external external-icon" href="http://mdn.github.io/performance-scenarios/js-worker/index.html">ici</a>.</p>
+
+<p>Il existe également une version vidéo de cet article :</p>
+
+<p>{{EmbedYouTube("Pcc6jQX6JDI")}}</p>
+
+<p>Le site de démonstration ressemble à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11031/js-worker-demo.png" style="display: block; height: 677px; margin-left: auto; margin-right: auto; width: 1000px;">Il y trois contrôles :</p>
+
+<ul>
+ <li>un bouton de sélection qui permet de contrôler comment exécuter le JavaScript : soit d'un seul bloc dans le thread principal, soit en plusieurs parties avec <code>requestAnimationFrame()</code>, soit en utilisant un thread séparé grâce à un worker.</li>
+ <li>Un bouton nommé "Do pointless computations!" (faire des calculs inutiles) pour exécuter le JavaScript.</li>
+ <li>Un bouton pour démarrer et arrêter des animations CSS. Cela donne au navigateur des tâches de fond à exécuter.</li>
+</ul>
+
+<p>Afin de voir le problème de cette page, il faut laisser le bouton de sélection sur "Use blocking call in main thread" (appel de fonction bloquant dans le thread principal), puis faire un enregistrement. Pour ce faire, il faut réaliser les étapes suivantes :</p>
+
+<ul>
+ <li>Presser le bouton "Start animations"</li>
+ <li>Démarrer l'enregistrement d'un profil</li>
+ <li>Presser le bouton "Do pointless computations!" deux ou trois fois</li>
+ <li>Arreter l'enregistrement du profil</li>
+</ul>
+
+<p>Le résultat sera différent d'une machine à l'autre, mais globalement il devrait ressembler à ceci :</p>
+
+<p><a id="js-blocking-overview" name="js-blocking-overview"><img alt="" src="https://mdn.mozillademos.org/files/10891/perf-js-blocking-overview.png" style="display: block; height: 113px; margin-left: auto; margin-right: auto; width: 800px;"></a></p>
+
+<p>La partie haute est la <a href="/fr/docs/Tools/Performance/UI_Tour#Waterfall_overview">vue d'ensemble de la chronologie</a>. Cela donne une vue compressée de la <a href="/fr/docs/Tools/Performance/Waterfall">Chronologie</a>, qui affiche quels types d'opérations le navigateur effectue durant l'enregistrement. La partie rose indique que le navigateur effectue principalement des <a href="/fr/docs/Tools/Performance/Waterfall#Markers">calculs CSS et potentiellement des reflows</a>: il s'agit des animations CSS qui s'exécutent tout au long du profil. Il y a également des gros blocs orange, représentant l'exécution de JavaScript, il y a un bloc par appui de bouton "Do pointless computations!".</p>
+
+<p>La partie basse qui est relation avec le résumé de la frise chronologique, montre le <a href="/fr/docs/Tools/Performance/Frame_rate">frame rate</a>. Celui-ci est bon pendant la plus grande partie de l'enregistrement, mais s'effondre complètement à chaque appui de bouton.</p>
+
+<p>Il est possible de sélectionner une de ces périodes afin d'obtenir des informations plus précises dans la vue principale de la chronologie :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10895/perf-js-blocking-waterfall.png" style="display: block; height: 306px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Ici, lorsque le bouton est pressé, le navigateur a exécuté une fonction JavaScript, ou une série de fonctions qui ont bloqué le thread principal pendant 71.73ms, soit plus de trois fois le budget de temps pour une frame (1000ms/60frames = 16.67ms par frame).</p>
+
+<p>Mais quelle est cette fonction qui prend tant de temps ? En passant à la vue du <a href="/fr/docs/Tools/Performance/Flame_Chart">Flame Chart</a> (Graphique JS), il est possible de le découvrir :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10893/perf-js-blocking-flame-chart.png" style="display: block; height: 230px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Cela révèle la pile d'appels JavaScript à cet instant de l'exécution. Sur le haut de la pile, on trouve une fonction nommée <code>calculatePrimes()</code>, le nom du fichier dans laquelle elle est contenue ainsi que le numéro de ligne à laquelle elle se trouve est également affiché. Le code incriminé est le suivant :</p>
+
+<pre class="brush: js">const iterations = 50;
+const multiplier = 1000000000;
+
+function calculatePrimes(iterations, multiplier) {
+  var primes = [];
+  for (var i = 0; i &lt; iterations; i++) {
+    var candidate = i * (multiplier * Math.random());
+    var isPrime = true;
+    for (var c = 2; c &lt;= Math.sqrt(candidate); ++c) {
+      if (candidate % c === 0) {
+          // not prime
+          isPrime = false;
+          break;
+       }
+    }
+    if (isPrime) {
+      primes.push(candidate);
+    }
+  }
+  return primes;
+}
+
+function doPointlessComputationsWithBlocking() {
+  var primes = calculatePrimes(iterations, multiplier);
+  pointlessComputationsButton.disabled = false;
+  console.log(primes);
+}
+</pre>
+
+<p>Il s'agit tout simplement d'un test (mal optimisé) de nombre primaire réalisé 50 fois, pour des nombres assez grands.</p>
+
+<h2 id="Utilisation_de_requestAnimationFrame">Utilisation de requestAnimationFrame</h2>
+
+<p>La première manière de régler ce problème de performance consiste à fractionner la fonction en plusieurs parties plus restreintes, et de planifier l'exécution de chacune avec <code><a href="/fr/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame()</a></code>.</p>
+
+<p><code>requestAnimationFrame()</code> ordonne au navigateur d'effectuer une fonction à chaque frame, juste avant qu'il effectue un repaint. Tant que les chaque fonction est raisonnablement courte, le navigateur devrait être capable de de ne pas dépasser le budget temps idéal.</p>
+
+<p>Il est assez facile de fractionner <code>calculatePrimes()</code>: Il suffit de calculer la primarité de chaque nombre dans une fonction séparée :</p>
+
+<pre class="brush: js">function doPointlessComputationsWithRequestAnimationFrame() {
+
+  function testCandidate(index) {
+    // finishing condition
+    if (index == iterations) {
+      console.log(primes);
+      pointlessComputationsButton.disabled = false;
+      return;
+    }
+    // test this number
+    var candidate = index * (multiplier * Math.random());
+    var isPrime = true;
+    for (var c = 2; c &lt;= Math.sqrt(candidate); ++c) {
+      if (candidate % c === 0) {
+          // not prime
+          isPrime = false;
+          break;
+       }
+    }
+    if (isPrime) {
+      primes.push(candidate);
+    }
+    // schedule the next
+    var testFunction = testCandidate.bind(this, index + 1);
+    window.requestAnimationFrame(testFunction);
+  }
+
+  var primes = [];
+  var testFunction = testCandidate.bind(this, 0);
+  window.requestAnimationFrame(testFunction);
+}</pre>
+
+<p>Il est maintenant temps de tester cette version. Pour cela on répète les étapes précédentes. Cette fois par contre, l'enregistrement devrait ressembler à ceci :</p>
+
+<p><a id="js-raf-overview" name="js-raf-overview"><img alt="" src="https://mdn.mozillademos.org/files/10897/perf-js-raf-overview.png" style="display: block; height: 112px; margin-left: auto; margin-right: auto; width: 800px;"></a></p>
+
+<p>Au lieu <a href="#js-blocking-overview">d'un seul bloc organe continu</a>, chaque pression de bouton révèle une longue séquence de courts blocs orange. Ces blocs sont tous espacés d'une frame, et chacun représente une des fonctions appelées par <code>requestAnimationFrame()</code>. Il est à noter qu'il n'y a eu que deux pressions de bouton dans ce profil.</p>
+
+<p>Ces appels de fonction sont en parallèle aux blocs roses des animations CSS, et chaque fonction est assez courte pour que le navigateur puisse l'exécuter sans faire baisser le frame rate.</p>
+
+<p>Utiliser <code>requestAnimationFrame</code> pour résoudre le problème de réactivité a fonctionné ici. Cependant, il existe quelques problèmes potentiels à cette solution :</p>
+
+<ul>
+ <li>Il peut être difficile de fractionner des longues fonctions. Même cet exemple simple a rendu nécessaire l'écriture de code plus complexe.</li>
+ <li>La version fractionnée prend beaucoup plus de temps à s'exécuter. En fait il est possible d'être assez précis sur le temps utilisé : il y a 50 itérations, et le navigateur tourne à 60 frames par secondes. Cela prendra donc presque une seconde d'exécuter tous les calculs, et cela à des répercussions sur l'expérience utilisateur et sur le profil.</li>
+</ul>
+
+<h2 id="Utilisation_des_web_workers">Utilisation des web workers</h2>
+
+<p>Cette solution tente de régler le problème en utilisant un web worker. Les web workers permettent d'exécuter du JavaScript dans un thread séparé. Le thread principal et le thread du worker ne peuvent pas s'appeler directement, mais peuvent cependant communiquer via une API de messagerie asynchrone.</p>
+
+<p>Le code du thread principal doit ressembler à ceci :</p>
+
+<pre class="brush: js">const iterations = 50;
+const multiplier = 1000000000;
+
+var worker = new Worker("js/calculate.js");
+
+function doPointlessComputationsInWorker() {
+
+  function handleWorkerCompletion(message) {
+    if (message.data.command == "done") {
+      pointlessComputationsButton.disabled = false;
+      console.log(message.data.primes);
+      worker.removeEventListener("message", handleWorkerCompletion);
+    }
+  }
+
+  worker.addEventListener("message", handleWorkerCompletion, false);
+
+  worker.postMessage({
+    "multiplier": multiplier,
+    "iterations": iterations
+  });
+}</pre>
+
+<p>La différence avec le code original est que l'on a besoin de :</p>
+
+<ul>
+ <li>Créer un worker.</li>
+ <li>Lui envoyer un message lorsque l'on est pretr à calculer.</li>
+ <li>Être à l'écoute d'un message nommé "done", qui indique quand le worker est finni.</li>
+</ul>
+
+<p>Un fichier "calculate.js", est également nécessaire, son code est le suivant :</p>
+
+<pre class="brush: js">self.addEventListener("message", go);
+
+function go(message) {
+  var iterations = message.data.iterations;
+  var multiplier = message.data.multiplier;
+  primes = calculatePrimes(iterations, multiplier);
+
+  self.postMessage({
+    "command":"done",
+    "primes": primes
+  });
+}
+
+function calculatePrimes(iterations, multiplier) {
+  var primes = [];
+  for (var i = 0; i &lt; iterations; i++) {
+    var candidate = i * (multiplier * Math.random());
+    var isPrime = true;
+    for (var c = 2; c &lt;= Math.sqrt(candidate); ++c) {
+      if (candidate % c === 0) {
+          // not prime
+          isPrime = false;
+          break;
+       }
+    }
+    if (isPrime) {
+      primes.push(candidate);
+    }
+  }
+  return primes;
+}</pre>
+
+<p>Dans le worker, il est nécessaire d'être à l'écoute d'un message donnant l'ordre de démarrer. Il est également nécessaire d'envoyer un message "done" lorsque les calculs sont finis. La partie du code qui réalise les calculs elle n'a pas changé.</p>
+
+<p>Comment s'en tire cette version ? Pour le savoir, il suffit de sélectionner "Use a worker", et de capturer un nouveau profil. Il devrait ressembler à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10899/perf-js-worker-overview.png" style="display: block; height: 112px; margin-left: auto; margin-right: auto; width: 800px;"></p>
+
+<p>Dans ce profil, le bouton a été pressé trois fois. <a href="#js-blocking-overview">Comparé à l'original</a>, chaque pression de bouton est visible dans le résumé sous la forme de deux blocs orange très courts :</p>
+
+<ul>
+ <li>La fonction <code>doPointlessComputationsInWorker()</code> qui gère l'évènement de clic et lance le worker</li>
+ <li>La fonction <code>handleWorkerCompletion()</code> qui s'exécute lorsque le worker appelle "donne".</li>
+</ul>
+
+<p>Entre ces deux blocs, le worker effectue ses opérations, et n'a aucun effet visible sur le frame rate et donc sur la réactivité du thread principal. Cela peut sembler étrange, mais puisque le worker s'exécute dans thread séparé, l'ordinateur peut profiter de l'architecture multi coeurs, ce qu'un site web à thread unique ne peut pas faire.</p>
+
+<p>La limitation principale des webs workers est que le code qui s'exécute dans un worker n'a pas accès à l'API DOM.</p>
diff --git a/files/fr/tools/performance/ui_tour/index.html b/files/fr/tools/performance/ui_tour/index.html
new file mode 100644
index 0000000000..b364f3029b
--- /dev/null
+++ b/files/fr/tools/performance/ui_tour/index.html
@@ -0,0 +1,125 @@
+---
+title: UI Tour
+slug: Outils/Performance/UI_Tour
+translation_of: Tools/Performance/UI_Tour
+---
+<div>{{ToolsSidebar}}</div>
+
+<p>La plateforme d'outils se découpe en 4 parties principales :<img alt="" src="https://mdn.mozillademos.org/files/13220/perf-tool-pieces.png" style="display: block; height: 351px; margin-left: auto; margin-right: auto; width: 808px;"></p>
+
+<ul>
+ <li><a href="/en-US/docs/">La barre d'outils</a></li>
+ <li>La zone d'enregistrement</li>
+ <li><a href="/en-US/docs/Tools/Performance/UI_Tour#Recording_overview">Recording overview</a></li>
+ <li><a href="/en-US/docs/Tools/Performance/UI_Tour#Details_pane">Details pane</a>, which may contain any one of:
+  <ul>
+   <li><a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a></li>
+   <li><a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a></li>
+   <li><a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Chart</a></li>
+  </ul>
+ </li>
+</ul>
+
+<h2 id="Outil">Outil</h2>
+
+<p>La boite à outils contient les boutons pour :</p>
+
+<ul>
+ <li>commencer et arrêter l'enregistrement</li>
+ <li>importer les enregistrements de vos sauvegardes précédentes</li>
+ <li>nettoyer le volet d'enregistrements. <em>à noter que si vous faîtes cela, vous perdrez tout ce que vous n'avez pas sauvegardé.L.</em></li>
+ <li>filtrer les <a href="/en-US/docs/Tools/Performance/Waterfall#Markers">markers</a> qui sont affichés dans la vue Cascade</li>
+ <li>switch the active tool in the <a href="/en-US/docs/Tools/Performance/UI_Tour#Details_pane">Details pane</a>.</li>
+ <li>accéder au menu des paramètres</li>
+</ul>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10915/perf-toolbar-annotated.png" style="display: block; height: 191px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<h2 id="Recordings_pane">Recordings pane</h2>
+
+<p>The recordings pane lists all the recordings you have loaded, including any you have made in this session and any you have imported.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10917/perf-recordings-pane.png" style="display: block; height: 337px; margin-left: auto; margin-right: auto; width: 300px;"></p>
+
+<p>Pour un temps donné, un enregistrement est sélectionné, et cet enregistrement est affiché dans le reste de l'outil. Pour sélectionner un enregistrement différent, cliquer sur son entrée dans le panneau. Pour sauvegarder l'enregistrement en tant que fichier d'extension JSON, appuyer sur "Save".</p>
+
+<h2 id="Vue_d'ensemble_de_l'enregistrement">Vue d'ensemble de l'enregistrement</h2>
+
+<p>Ceci affiche une vue d'ensemble de la totalité de l'enregistrement.This displays an overview of the entire recording, with the x-axis representing time.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10919/perf-overview.png" style="display: block; height: 164px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>It contains two elements: an overview of the Waterfall and a frame rate graph.</p>
+
+<h3 id="Waterfall_overview">Waterfall overview</h3>
+
+<p>This presents a compressed view of the <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a>:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10923/perf-waterfall-overview.png" style="display: block; height: 76px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>Recorded operations are color-coded using <a href="/en-US/docs/Tools/Performance/Waterfall#Markers">the same scheme as in the main Waterfall view</a>.</p>
+
+<h3 id="Frame_rate_graph">Frame rate graph</h3>
+
+<p>The frame rate gives you an overview of the browser's responsiveness during the recording:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10921/perf-frame-rate.png" style="display: block; height: 88px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>See the separate article on <a href="/en-US/docs/Tools/Performance/Frame_rate">frame rate</a>.</p>
+
+<h3 id="Correlating_events">Correlating events</h3>
+
+<p>Because these elements are synchronized, you can correlate events in one element with events in another.</p>
+
+<p>For example, in the screenshot below a long-running paint operation (<a href="/en-US/docs/Tools/Performance/Waterfall#Markers">shown as a green bar</a> in the waterfall overview) corresponds to a drop in the frame rate:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10925/perf-overview-correlation.png" style="display: block; height: 494px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<h3 id="Zooming_in">Zooming in</h3>
+
+<p>You can use the overview to select a slice of the recording to examine in more detail. Select a slice, and the main view will be updated to contain just the part selected. In the screenshot below we've selected that drop in the frame rate, and can see the long-running paint operation in more detail:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10927/perf-zoomed.png" style="display: block; height: 416px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<h2 id="Details_pane">Details pane</h2>
+
+<p>The Details pane shows whichever tool is currently selected. To switch to a different tool, use the buttons in the <a href="/en-US/docs/Tools/Performance/UI_Tour#Toolbar">Toolbar</a>.</p>
+
+<h3 id="Waterfall">Waterfall</h3>
+
+<p>The Waterfall presents a view of the work the browser is doing during the recording: executing JavaScript, updating the CSS, updating the page layout, and performing repaints. The x-axis represents time, and the recorded operations are laid out as a waterfall, reflecting the serial nature of the browser's execution.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10929/perf-waterfall.png" style="display: block; height: 568px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>To learn much more about the Waterfall, see the separate <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a> page.</p>
+
+<h3 id="Call_Tree">Call Tree</h3>
+
+<p>The Call Tree is a sampling profiler for JavaScript running in the page. It periodically samples the state of the JavaScript engine, and records the stack for the code executing at the time the sample was taken. Statistically, the number of samples taken in which we were executing a particular function corresponds to the amount of time the browser is spending executing it, so you can identify bottlenecks in your code.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10949/perf-call-tree.png" style="display: block; height: 384px; margin-left: auto; margin-right: auto; width: 972px;"><br>
+ To learn much more about the Call Tree, see the separate <a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a> page.</p>
+
+<h3 id="Flame_Chart">Flame Chart</h3>
+
+<p>If the Call Tree tells you, statistically, which functions your site is spending most time executing across the whole recording, the Flame Chart tells you the call stack at any given point during the recording:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10933/perf-flame-chart.png" style="display: block; height: 504px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>To learn much more about the Flame Chart, see the separate <a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Chart</a> page.</p>
+
+<h3 id="Allocations">Allocations</h3>
+
+<div class="geckoVersionNote">
+<p>La vue Allocations est une des nouvautés de Firefox 46.</p>
+</div>
+
+<p>La vue Allocations ressemble à la vue Call tree view is like the Call Tree view, but for allocations: it shows you which functions in your page are allocating the most memory over the course of the profile.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12413/allocations-view-1.png" style="display: block; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>The Allocations view only appears if you checked "Record Allocations" in the Performance tool settings, before recording a profile:</p>
+
+<p>{{EmbedYouTube("Le9tTo7bqts")}}</p>
+
+<p>To learn much more about the Allocations view, see the separate <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Allocations">Allocations</a> page.</p>
diff --git a/files/fr/tools/performance/waterfall/index.html b/files/fr/tools/performance/waterfall/index.html
new file mode 100644
index 0000000000..cf30f9a81d
--- /dev/null
+++ b/files/fr/tools/performance/waterfall/index.html
@@ -0,0 +1,481 @@
+---
+title: Chronologie
+slug: Outils/Performance/Waterfall
+translation_of: Tools/Performance/Waterfall
+---
+<div>{{ToolsSidebar}}</div>
+
+<div class="summary">
+<p>La chronologie vous donne des indications sur les opérations qu'effectue le navigateur lorsqu'il fait tourner une page web ou une application. Cet outil se base sur l'idée que les opérations qu'effectue un navigateur peuvent être divisées en plusieurs types : exécution du JavaScript, mise à jour du layout, et ainsi de suite... Ainsi que l'idée qu'à n'importe quel point donné dans le temps, le navigateur effectue l'une ou l'autre de ces actions.</p>
+
+<p>Donc, si vous voyez un problème de performance - une chute du frame rate par exemple - vous pouvez utiliser la chronologie pour voir ce que le navigateur faisait à ce moment de l'enregistrement.</p>
+</div>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10951/perf-waterfall.png" style="display: block; height: 568px; margin-left: auto; margin-right: auto; width: 972px;"></p>
+
+<p>L'axe X représente le temps. Les opérations enregistrées, appelées marqueurs sont affichées sous la forme de barres de couleur horizontales. Ces marqueurs sont disposés en cascade pour refléter le caractère séquentiel de l'exécution du navigateur.</p>
+
+<p>Lorsqu'un marqueur est sélectionné, des informations supplémentaires sur celui-ci s'affichent dans le panneau de droite. Ces informations intègrent la durée du marqueur et quelques informations spécifiques de son <a href="/fr/docs/Tools/Performance/Waterfall#Marqueurs">type</a>.</p>
+
+<h2 id="Marqueurs"><a id="timeline-color-coding" name="timeline-color-coding"></a>Marqueurs</h2>
+
+<p>Les marqueurs possèdent un code couleur et un libellé. Les opérations suivantes sont enregistrées :</p>
+
+<table class="fullwidth-table standard-table">
+ <thead>
+  <tr>
+   <th scope="col" style="width: 20%;">Nom et description</th>
+   <th scope="col">Couleur</th>
+   <th scope="col">Informations détaillées</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td style="width: 40%;">
+    <p><a id="DOM_Event_Marker" name="DOM_Event_Marker"><strong>Évènements DOM</strong></a></p>
+
+    <p>Le code JavaScript qui est exécuté en réponse à un évènement DOM.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10703/orange.png" style="height: 21px; width: 60px;"></td>
+   <td style="width: 45%;">
+    <dl>
+     <dt>Type de l'évènement</dt>
+     <dd>Par exemple, "click" ou "message".</dd>
+    </dl>
+
+    <dl>
+     <dt>Phase de l'évènement</dt>
+     <dd>Par exemple "Target" ou "Capture".</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p>Les fonctions JavaScript exécutées dans la page ont le libellé de la raison pour laquelle la fonction a été appelée :</p>
+
+    <p><strong>Script Tag<br>
+     setInterval<br>
+     setTimeout<br>
+     requestAnimationFrame<br>
+     Promise Callback<br>
+     Promise Init<br>
+     Worker<br>
+     JavaScript URI<br>
+     Event Handler</strong></p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10703/orange.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Pile</dt>
+     <dd>La pile d'appels avec des liens vers les fonctions.</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Parse HTML</strong></p>
+
+    <p>Le temps passé à parser le HTML de la page.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10703/orange.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Pile</dt>
+     <dd>La pile d'appels avec des liens vers les fonctions.</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Parse XML</strong></p>
+
+    <p>Le temps passé à parser le XML de la page.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10703/orange.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Pile</dt>
+     <dd>La pile d'appels avec des liens vers les fonctions.</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Recalcul des styles</strong></p>
+
+    <p>Le calcul des styles qui s'appliquent aux éléments de la page.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10707/purple.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Causes du recalcul</dt>
+     <dd>Une chaine de caractères indiquant quel type de recalcul est nécessaire. Elle peut prendre les valeurs suivantes :<br>
+     Self<br>
+     Subtree<br>
+     LaterSiblings<br>
+     CSSTransitions<br>
+     CSSAnimations<br>
+     SVGAttrAnimations<br>
+     StyleAttribute<br>
+     StyleAttribute_Animations<br>
+     Force<br>
+     ForceDescendants</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Layout</strong></p>
+
+    <p>Le calcul des positions et de la taille des éléments de la page. Cette opération est parfois appelée "reflow".</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10707/purple.png" style="height: 21px; width: 60px;"></td>
+   <td> </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Paint</strong></p>
+
+    <p>Affichage des pixels à l'écran</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10705/green.png" style="height: 21px; width: 60px;"></td>
+   <td> </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Ramasse-miettes</strong></p>
+
+    <p><a href="/fr/docs/Tools/Performance/Waterfall#Garbage_collection">évènement de garbage collection</a>. Les évènements GC non incrémentaux sont nommés "non incrémentiel".</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10709/red.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Raison</dt>
+     <dd>Une chaine de caractères indiquant la raison pour laquelle le ramasse-miettes a été effectué.</dd>
+     <dt>Raison du cycle non incrémentiel</dt>
+     <dd>Si l'évènement n'était pas incrémentiel, une chaine expliquant pourquoi la GC a été effectuée.</dd>
+     <dt> </dt>
+     <dd>
+     <div class="geckoVersionNote">
+     <p>Nouveau dans Firefox 46: Si l’évènement GC a été causé par une d'allocation, un nouveau lien "Show Allocation Triggers". Cliquer dessus affiche le profil d'allocation menant à cet évènement.</p>
+
+     <p>Voir <a href="/fr/docs/Tools/Performance/Allocations#Allocations_and_garbage_collection">Allocations et Ramasse-miettes</a> pour plus d'informations.</p>
+     </div>
+     </dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Cycle Collection</strong></p>
+
+    <p>Récupération des structures de données C++ qui sont en <a href="https://en.wikipedia.org/wiki/Reference_counting">"reference-count"</a></p>
+
+    <p>Semblable au ramasse-miette, mais pour les objets C++. Voir <a href="http://blog.kylehuey.com/post/27564411715/cycle-collection">l'article de blog de Kyle Huey sur le cycle collection</a>.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10709/red.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt><strong>Type</strong></dt>
+     <dd>Toujours "Collect"</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Réduction d'arbre de ramasse-miettes</strong></p>
+
+    <p>Préparation/préoptimisation pour le Cycle Collection.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10709/red.png" style="height: 21px; width: 60px;"></td>
+   <td><span style="display: none;"> </span>
+    <p><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><strong>Type</strong></p>
+    <span style="display: none;"> </span>
+
+    <dl>
+     <dd>Toujours "ForgetSkippable".</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Console</strong></p>
+
+    <p>La période entre les appels à <code>console.time()</code> et <code>console.timeEnd()</code>.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10955/gray.png" style="height: 54px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Nom du timer</dt>
+     <dd>L'argument passé aux fonctions <code>console</code>.</dd>
+     <dt>Pile au début</dt>
+     <dd>La pile d'appels <code>à console.time()</code>, avec des liens vers les fonctions.</dd>
+     <dt>Pile de fin</dt>
+     <dd>(Nouveau dans Firefox 41). La pile d'appels <code>console.timeEnd()</code>. S'il s'agit d'un appel dans un callback de <code><a href="/fr/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</a></code>, cela montrera également la <a href="/fr/docs/Tools/Performance/Waterfall#Async_stack">"Async stack"</a>.</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Timestamp</strong></p>
+
+    <p>Un appel unique à <code><a href="/fr/docs/Web/API/Console/timeStamp">console.timeStamp()</a></code>.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/10953/blue.png" style="height: 54px; width: 60px;"></td>
+   <td>
+    <dl>
+     <dt>Label</dt>
+     <dd>L'argument passé à <code>timeStamp()</code>.</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>DOMContentLoaded</strong></p>
+
+    <p>L'évènement <code><a href="/en-US/docs/Web/Events/DOMContentLoaded">DOMContentLoaded</a></code> du document</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/12191/red.png" style="height: 21px; width: 60px;"></td>
+   <td> </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Load</strong></p>
+
+    <p>L'évènement <code><a href="/en-US/docs/Web/Events/load">load</a></code> du document.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/12193/blue.png" style="height: 21px; width: 60px;"></td>
+   <td> </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Évènement dans le thread principal du worker</strong></p>
+
+    <p>Affiché lorsque le thread principal envoie un message à un worker, ou reçoit un message d'un worker.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/12195/orange2.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <p>Un parmi :</p>
+
+    <dl>
+     <dt>Sérialisation des données sur le thread principal</dt>
+     <dd>Le thread principal sérialise un message pour l'envoyer au worker</dd>
+     <dt>Déserialisation des données sur le thread principal</dt>
+     <dd>Le thread principal désérialise un message pour l'envoyer au worker</dd>
+    </dl>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p><strong>Worker event in worker thread</strong></p>
+
+    <p>Affiché lorsque le worker  envoie un message à un worker, ou reçoit un message du thread principal.</p>
+   </td>
+   <td><img alt="" src="https://mdn.mozillademos.org/files/12197/orange2-hollow.png" style="height: 21px; width: 60px;"></td>
+   <td>
+    <p>Un parmi :</p>
+
+    <dl>
+     <dt>Serialisation des données dans le Worker</dt>
+     <dd>Le worker sérialise un message pour l'envoyer au thread principal</dd>
+     <dt>Déserialisation des données dans le Worker</dt>
+     <dd>Le worker désérialise un message pour l'envoyer au thread principal</dd>
+    </dl>
+   </td>
+  </tr>
+ </tbody>
+</table>
+
+<p>Les marqueurs et leurs couleurs sont les mêmes dans la chronologie que dans la <a href="/fr/docs/Tools/Performance/UI_Tour#Waterfall_overview">vue d'ensemble de la chronologie</a>.</p>
+
+<h3 id="Filtrer_les_marqueurs">Filtrer les marqueurs</h3>
+
+<p>Il est possible de contrôler quels marqueurs sont affichés en utilisant le bouton dans la <a href="/fr/docs/Tools/Performance/UI_Tour#Toolbar">barre d'outils </a>:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13238/perf-markers.png" style="display: block; height: 694px; margin-left: auto; margin-right: auto; width: 799px;"></p>
+
+<h2 id="Motifs_de_la_chronologie">Motifs de la chronologie</h2>
+
+<p>Le contenu de l´enregistrement dépend énormément des opérations réalisées par le site : Les sites utilisant beaucoup de JavaScript auront un profil à dominance orange, alors que les sites à contenu visuel dynamique auront beaucoup de violet et de vert. Cependant certains motifs communs peuvent vous indiquer de possibles problèmes de performance.</p>
+
+<h3 id="Chronologie_de_rendu">Chronologie de rendu</h3>
+
+<p>Le motif suivant est très courant dans la vue de la chronologie :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10711/perf-timeline-waterfall.png" style="display: block; height: 286px; margin-left: auto; margin-right: auto; width: 727px;"></p>
+
+<p>C'est une visualisation de l´algorithme de base qu'utilise le navigateur pour mettre à jour la page en réponse à un évènement :</p>
+
+<ol>
+ <li><strong>JavaScript Function Call</strong>: Un évènement quelconque - par exemple un évènement DOM - a pour effet de lancer du JavaScript. Le code change du DOM ou du CSSOM.</li>
+ <li><strong>Recalculate Style</strong>: Si le navigateur pense que des styles calculés de la page ont changé, il les recalcule.</li>
+ <li><strong>Layout</strong>: Puis, le navigateur utilise les styles calculés pour déterminer la position et la géométrie des éléments. Cette opération est étiquetée "layout", mais on l'appelle aussi « reflow ».</li>
+ <li><strong>Paint</strong>: Enfin, le navigateur a besoin de réafficher les éléments à l'écran. Une dernière étape n'est pas représentée dans cette séquence: La page peut être divisée en couches, qui sont affichées indépendamment puis assemblées lors d'un processus appelé "Composition".</li>
+</ol>
+
+<p>Cette séquence doit se terminer en une seule image, puisque l'écran n'est pas mis à jour avant qu'elle soit terminée. Il est communément admis que 60 images/secondes est la vitesse à laquelle les animations apparaîtront fluides. Pour un taux de 60 images/secondes, cela laisse au navigateur 16,7 millisecondes pour exécuter le flow complet.</p>
+
+<p>Il est important pour la réactivité à ce que le navigateur n´ait pas à passer par toutes ces étapes à chaque fois :</p>
+
+<ul>
+ <li><a href="/fr/docs/Web/Guide/CSS/Using_CSS_animations">Les animations CSS</a> mettent à jour la page sans avoir besoin d'exécuter du JavaScript.</li>
+ <li>Toutes les propriétés CSS modifiées ne causent pas de « reflow ». Modifier des propriétés qui changent la position ou la géométrie d'un objet, telles que <code><a href="/fr/docs/Web/CSS/width">width</a></code>, <code><a href="/fr/docs/Web/CSS/display">display</a></code>, <code><a href="/fr/docs/Web/CSS/font-size">font-size</a></code>, ou <code><a href="/fr/docs/Web/CSS/top">top</a></code>, provoqueront un « reflow ». Par contre, modifier des propriétés qui ne changent par la géométrie ou le positionnement, telles que <code><a href="/fr/docs/Web/CSS/color">color</a></code> ou <code><a href="/fr/docs/Web/CSS/opacity">opacity</a></code>, n'en feront rien.</li>
+ <li>Toutes les propriétés CSS modifiées n'amènent pas à un repaint. En particulier, si vous animez un élément en utilisant la propriété <code><a href="/fr/docs/Web/CSS/transform">transform</a></code>, le navigateur utilisera une couche séparée pour l'élément transformé, et n'aura peut-être même pas à faire un repaint si l'élément est déplacé : Sa nouvelle position est traitée dans la composition.</li>
+</ul>
+
+<p>L'article <a href="/fr/docs/Tools/Performance/Scenarios/Animating_CSS_properties">Animer des propriétés CSS </a>montre qu'animer différentes propriétés CSS peut donner des résultats de performance différents, et comment la chronologie peut aider à le voir.</p>
+
+<h3 id="JavaScript_bloquant">JavaScript bloquant</h3>
+
+<p>Par défaut, le JavaScript des pages web est exécuté sur le même thread que celui que le navigateur utilise pour les mises à jour de layout, les repaints, les évènements DOM et ainsi de suite. Cela signifie que des fonctions JavaScript qui mettent longtemps à s´exécuter peuvent causer des ralentissements (jank). Les animations ne seront pas fluides et le site pourra même freezer.</p>
+
+<p>En utilisant l'outil frame rate et la « chronologie », il est facile de voir lorsque des fonctions JavaScript posent problème. Dans la capture d´écran ci-dessous, un zoom a été fait sur une fonction JS qui cause une chute du frame rate :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10973/perf-js-blocking-waterfall.png" style="display: block; height: 432px; margin-left: auto; margin-right: auto; width: 1128px;"></p>
+
+<p>L'article <a href="/fr/docs/Tools/Performance/Scenarios/Intensive_JavaScript">JavaScript Intensif</a> montre comment la « chronologie » peut mettre en évidence les problèmes de réactivité causés par des fonctions JavaScript trop gourmandes, et comment utiliser des méthodes asynchrones pour garder le thread principal réactif.</p>
+
+<h3 id="«_Décorations_»_coûteuses">« Décorations » coûteuses</h3>
+
+<p>Certains effets tels que <code><a href="/fr/docs/Web/CSS/box-shadow">box-shadow</a></code>, peuvent être coûteux ; surtout lors de transitions où le navigateur doit recalculer cet effet à chaque image. Si vous remarquez des chutes de frame rate surtout lors d'opérations et transitions graphiques couteuses, recherchez les longs marqueurs verts (repaint) dans la chronologie.</p>
+
+<h3 id="Ramasse-miettes_(Garbage_Collection)">Ramasse-miettes (Garbage Collection)</h3>
+
+<p>Les marqueurs rouges dans la chronologie représentent le passage du ramasse-miettes (GC), pour lequel <a href="/fr/docs/Mozilla/Projects/SpiderMonkey">SpiderMonkey</a> (le moteur JavaScript de Firefox) parcourt la pile à la recherche d´éléments en mémoire qui ne sont plus accessible pour les libérer. La GC est un indice de performance, car lorsqu’elle « tourne », le moteur JavaScript doit être en pause et donc le programme est mis en pause et ne répondra pas.</p>
+
+<p>Pour aider à réduire la durée de ces pauses, SpiderMonkey implémente une <em>GC</em> morcelée. Cela signifie qu´il peut faire de la garbage collection par petites « passes », permettant au programme de tourner entre celles-ci. Parfois, le moteur à besoin de réaliser une garbage collection complète et non par morceaux et alors, le programme a besoin d'attendre la fin de cette opération.</p>
+
+<p>Pour essayer d’éviter les évènements GC et surtout les passages complets, il est sage de ne pas essayer d'optimiser pour l'implémentation spécifique du moteur JavaScript. SpiderMonkey utilise un ensemble complexe <span class="tag_lemma"><span class="dictTerm">d'heuristiques pour déterminer quand la GC est nécessaire, et quand une GC non incrémentale en particulier est nécessaire. En général cependant :</span></span></p>
+
+<ul>
+ <li>La GC est nécessaire lorsque beaucoup de mémoire est allouée.</li>
+ <li>La GC complète est généralement nécessaire lorsque le taux d'allocation mémoire est assez haut pour que SpiderMonkey puisse être à court de mémoire durant une GC morcelée.</li>
+</ul>
+
+<p>Lorsque la Chronologie enregistre un marqueur GC, cela indique :</p>
+
+<ul>
+ <li>Si le ramasse-miettes passait de manière morcelée ou pas.</li>
+ <li>La raison de l'événement GC qui a eu lieu.</li>
+ <li>Si la passe du ramasse-miettes était complète, et la raison pour laquelle elle l'était.</li>
+ <li>Depuis de Firefox 46, si l’évènement GC a été causé par une d'allocation, un nouveau lien "Show Allocation Triggers". Cliquer dessus affiche le profil d'allocation menant à cet évènement. Voir <a href="/fr/docs/Tools/Performance/Allocations#Allocations_and_garbage_collection">Allocations et Ramasse-miettes</a> pour plus d'informations.</li>
+</ul>
+
+<h2 id="Ajouter_des_marqueurs_avec_la_console_API">Ajouter des marqueurs avec la console API</h2>
+
+<p>Deux marqueurs peuvent être contrôlés par des appels à la <a href="/fr/docs/Web/API/Console">console API</a> : "Console" et "Timestamp".</p>
+
+<h3 id="Marqueurs_de_console">Marqueurs de console</h3>
+
+<p>Ces marqueurs permettent de marquer une section spécifique de l'enregistrement.</p>
+
+<p>Pour faire un marqueur console, il faut appeler<code> console.time()</code> au début d'une section, et <code>console.timeEnd()</code> à la fin. Ces fonctions prennent un argument qui est le nom de la section.</p>
+
+<p>Par exemple si nous avons un code comme ceci :</p>
+
+<pre class="brush: js">var iterations = 70;
+var multiplier = 1000000000;
+
+function calculatePrimes() {
+
+  console.time("calculating...");
+
+  var primes = [];
+  for (var i = 0; i &lt; iterations; i++) {
+    var candidate = i * (multiplier * Math.random());
+    var isPrime = true;
+    for (var c = 2; c &lt;= Math.sqrt(candidate); ++c) {
+      if (candidate % c === 0) {
+          // not prime
+          isPrime = false;
+          break;
+       }
+    }
+    if (isPrime) {
+      primes.push(candidate);
+    }
+  }
+
+  console.timeEnd("calculating...");
+
+  return primes;
+}</pre>
+
+<p>La sortie de la Chronologie ressemblera à ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10967/perf-console-time.png" style="display: block; height: 430px; margin-left: auto; margin-right: auto; width: 1192px;"></p>
+
+<p>Le marqueur est nommé par l'argument passé à <code>console.time()</code>, et lorsque le marqueur est sélectionné, il est possible de voir la pile du programme dans l'encadré sur le coté droit.</p>
+
+<h4 id="Tache_Async">Tache Async</h4>
+
+<p class="geckoVersionNote">Nouveau dans Firefox 41.</p>
+
+<p>À partir de Firefox 41, l'encadré de droite affichera également la stack à la fin de la période. C´est à dire au moment où <code>console.timeEnd()</code> a été appelé. Si <code>console.timeEnd()</code> a été appelé par la résolution d'une <code><a href="/fr/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</a></code>, l'encadré affichera également le label "(Async: Promise)", sous lequel sera affiché la "async stack" : Il s'agit de la pile d'appels au moment où la promise a été faite.</p>
+
+<p>Par exemple, avec ce code :</p>
+
+<pre class="brush: js">var timerButton = document.getElementById("timer");
+timerButton.addEventListener("click", handleClick, false);
+
+function handleClick() {
+  console.time("timer");
+  runTimer(1000).then(timerFinished);
+}
+
+function timerFinished() {
+  console.timeEnd("timer");
+  console.log("ready!");
+}
+
+function runTimer(t) {
+  return new Promise(function(resolve) {
+    setTimeout(resolve, t);
+  });
+}</pre>
+
+<p>La Chronologie affichera un marqueur pour la période entre <code>time()</code> et <code>timeEnd()</code>, et s’il est sélectionné, la pile async apparaitra dans l'encadré :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11179/async-stack.png" style="display: block; height: 378px; margin-left: auto; margin-right: auto; width: 352px;"></p>
+
+<h3 id="Marqueurs_de_temps">Marqueurs de temps</h3>
+
+<p>Les Timestamps permettent de marquer un instant dans l'enregistrement.</p>
+
+<p>Pour faire un timestamp, il faut appeler <code><a href="/fr/docs/Web/API/Console/timeStamp">console.timeStamp()</a></code>. Il est possible de passer un argument pour nommer le timestamp.</p>
+
+<p>Par exemple, supposons que nous adaptions le code au-dessus pour faire un timestamp toutes les 10 itérations de la boucle ayant pour nom le nombre de l'itération :</p>
+
+<pre class="brush: js">var iterations = 70;
+var multiplier = 1000000000;
+
+function calculatePrimes() {
+  console.time("calculating...");
+
+  var primes = [];
+  for (var i = 0; i &lt; iterations; i++) {
+
+    if (i % 10 == 0) {
+      console.timeStamp(i.toString());
+    }
+
+    var candidate = i * (multiplier * Math.random());
+    var isPrime = true;
+    for (var c = 2; c &lt;= Math.sqrt(candidate); ++c) {
+      if (candidate % c === 0) {
+          // not prime
+          isPrime = false;
+          break;
+       }
+    }
+    if (isPrime) {
+      primes.push(candidate);
+    }
+  }
+  console.timeEnd("calculating...");
+  return primes;
+}</pre>
+
+<p>Dans la Chronologie, vous verrez quelque chose comme ceci :</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/10971/perf-timestamp.png" style="display: block; height: 530px; margin-left: auto; margin-right: auto; width: 1192px;"></p>