unslug fr: move

3 files changed, 0 insertions, 393 deletions

diff --git a/files/fr/outils/performance/scenarios/animating_css_properties/index.html b/files/fr/outils/performance/scenarios/animating_css_properties/index.html
deleted file mode 100644
index b2767f6b32..0000000000
--- a/files/fr/outils/performance/scenarios/animating_css_properties/index.html
+++ /dev/null
@@ -1,154 +0,0 @@
----
-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/outils/performance/scenarios/index.html b/files/fr/outils/performance/scenarios/index.html
deleted file mode 100644
index 1b5969c1ff..0000000000
--- a/files/fr/outils/performance/scenarios/index.html
+++ /dev/null
@@ -1,8 +0,0 @@
----
-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/outils/performance/scenarios/intensive_javascript/index.html b/files/fr/outils/performance/scenarios/intensive_javascript/index.html
deleted file mode 100644
index 9d9a2291de..0000000000
--- a/files/fr/outils/performance/scenarios/intensive_javascript/index.html
+++ /dev/null
@@ -1,231 +0,0 @@
----
-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>