convert content to md

5 files changed, 452 insertions, 503 deletions

diff --git a/files/fr/web/performance/how_browsers_work/index.md b/files/fr/web/performance/how_browsers_work/index.md
index 516c2d42fb..e8e78939fc 100644
--- a/files/fr/web/performance/how_browsers_work/index.md
+++ b/files/fr/web/performance/how_browsers_work/index.md
@@ -8,214 +8,215 @@ tags:
   - Performance Web
 translation_of: Web/Performance/How_browsers_work
 ---
-<p>Les utilisateurs veulent des expériences Web avec un contenu rapide à charger et une interaction fluide. Par conséquent, un développeur doit s'efforcer d'atteindre ces deux objectifs.</p>
+Les utilisateurs veulent des expériences Web avec un contenu rapide à charger et une interaction fluide. Par conséquent, un développeur doit s'efforcer d'atteindre ces deux objectifs.
 
-<p>Pour comprendre comment améliorer les performances et les performances perçues, il est utile de comprendre le fonctionnement du navigateur.</p>
+Pour comprendre comment améliorer les performances et les performances perçues, il est utile de comprendre le fonctionnement du navigateur.
 
-<h2 id="Vue_générale">Vue générale</h2>
+## Vue générale
 
-<p>Les sites rapides offrent une meilleure expérience utilisateur. Les utilisateurs veulent et s'attendent à des expériences Web avec un contenu rapide à charger et à interagir avec fluidité.</p>
+Les sites rapides offrent une meilleure expérience utilisateur. Les utilisateurs veulent et s'attendent à des expériences Web avec un contenu rapide à charger et à interagir avec fluidité.
 
-<p>La compréhension des problèmes liés 1) à la latence et 2) les problèmes liés au fait que, dans la plupart des cas, les navigateurs fonctionné  à un seul thread. Cela sont deux problèmes majeurs dans les performances Web.</p>
+La compréhension des problèmes liés 1) à la latence et 2) les problèmes liés au fait que, dans la plupart des cas, les navigateurs fonctionné  à un seul thread. Cela sont deux problèmes majeurs dans les performances Web.
 
-<p>La latence est notre principale menace à surmonter pour assurer une charge rapide. Pour être rapides à charger, les objectifs des développeurs incluent l’envoi des informations demandées aussi rapidement que possible, ou du moins, cela semble super rapide. La latence du réseau est le temps nécessaire pour transmettre des octets par liaison radio aux ordinateurs. La performance Web est ce que nous devons faire pour que le chargement de la page se fasse le plus rapidement possible.</p>
+La latence est notre principale menace à surmonter pour assurer une charge rapide. Pour être rapides à charger, les objectifs des développeurs incluent l’envoi des informations demandées aussi rapidement que possible, ou du moins, cela semble super rapide. La latence du réseau est le temps nécessaire pour transmettre des octets par liaison radio aux ordinateurs. La performance Web est ce que nous devons faire pour que le chargement de la page se fasse le plus rapidement possible.
 
-<p>Pour la plupart, les navigateurs sont considérés comme un seul thread. Pour que les interactions se déroulent sans heurt, l’objectif du développeur est d’assurer des interactions de site performantes, du défilement en douceur à la réactivité au touchers Le temps de rendu est essentiel, car il permet de s’assurer que le fil principal peut effectuer tout le travail que nous lui faisons, tout en restant disponible pour gérer les interactions de l’utilisateur.</p>
+Pour la plupart, les navigateurs sont considérés comme un seul thread. Pour que les interactions se déroulent sans heurt, l’objectif du développeur est d’assurer des interactions de site performantes, du défilement en douceur à la réactivité au touchers Le temps de rendu est essentiel, car il permet de s’assurer que le fil principal peut effectuer tout le travail que nous lui faisons, tout en restant disponible pour gérer les interactions de l’utilisateur.
 
-<p>Les performances Web peuvent être améliorées en comprenant le caractère mono-thread du navigateur et en minimisant les responsabilités du thread principal, lorsque cela est possible et approprié, pour assurer un rendu fluide et des réponses aux interactions immédiates.</p>
+Les performances Web peuvent être améliorées en comprenant le caractère mono-thread du navigateur et en minimisant les responsabilités du thread principal, lorsque cela est possible et approprié, pour assurer un rendu fluide et des réponses aux interactions immédiates.
 
-<h2 id="Navigation">Navigation</h2>
+## Navigation
 
-<p>La navigation est la première étape du chargement d’une page Web. Cela se produit chaque fois qu'un utilisateur demande une page en saisissant une URL dans la barre d'adresse, en cliquant sur un lien, en soumettant un formulaire, ainsi que d'autres actions.</p>
+La navigation est la première étape du chargement d’une page Web. Cela se produit chaque fois qu'un utilisateur demande une page en saisissant une URL dans la barre d'adresse, en cliquant sur un lien, en soumettant un formulaire, ainsi que d'autres actions.
 
-<p>L'un des objectifs de la performance Web est de minimiser le temps de navigation. Dans des conditions idéales, cela ne prend généralement pas trop de temps, mais la latence et la bande passante sont des ennemis qui peuvent causer des retards.</p>
+L'un des objectifs de la performance Web est de minimiser le temps de navigation. Dans des conditions idéales, cela ne prend généralement pas trop de temps, mais la latence et la bande passante sont des ennemis qui peuvent causer des retards.
 
-<h3 id="Recherche_DNS">Recherche DNS</h3>
+### Recherche DNS
 
-<p>La première étape de la navigation vers une page Web consiste à rechercher l'emplacement des actifs de cette page. Si vous accédez à <code>https://example.com</code>, la page HTML se trouve sur le serveur avec l'adresse IP de <code>93.184.216.34</code>. Si vous n’avez jamais visité ce site, une recherche DNS doit être effectuée.</p>
+La première étape de la navigation vers une page Web consiste à rechercher l'emplacement des actifs de cette page. Si vous accédez à `https://example.com`, la page HTML se trouve sur le serveur avec l'adresse IP de `93.184.216.34`. Si vous n’avez jamais visité ce site, une recherche DNS doit être effectuée.
 
-<p>Votre navigateur demande une recherche DNS, qui est éventuellement effectuée par un serveur de noms, qui lui-même répond avec une adresse IP. Après cette demande initiale, l'adresse IP sera probablement mise en cache pendant un certain temps, ce qui accélérera les demandes suivantes en récupérant l'adresse IP du cache au lieu de contacter à nouveau un serveur de noms.&lt;</p>
+Votre navigateur demande une recherche DNS, qui est éventuellement effectuée par un serveur de noms, qui lui-même répond avec une adresse IP. Après cette demande initiale, l'adresse IP sera probablement mise en cache pendant un certain temps, ce qui accélérera les demandes suivantes en récupérant l'adresse IP du cache au lieu de contacter à nouveau un serveur de noms.<
 
-<p>Les recherches DNS ne doivent généralement être effectuées qu'une fois par nom d'hôte pour le chargement d'une page. Cependant, des recherches DNS doivent être effectuées pour chaque nom d'hôte unique référencé par la page demandée.</p>
+Les recherches DNS ne doivent généralement être effectuées qu'une fois par nom d'hôte pour le chargement d'une page. Cependant, des recherches DNS doivent être effectuées pour chaque nom d'hôte unique référencé par la page demandée.
 
-<p>Si vos fichier de police, images, scripts, publicites/annonces et métriques ont tous un nom d'hôte différent, une recherche DNS devra être effectuée pour chacun d'eux.</p>
+Si vos fichier de police, images, scripts, publicites/annonces et métriques ont tous un nom d'hôte différent, une recherche DNS devra être effectuée pour chacun d'eux.
 
-<p><img src="latency.jpg"></p>
+![](latency.jpg)
 
-<p>Cela peut être problématique pour les performances, en particulier sur les réseaux mobiles. Lorsqu'un utilisateur est sur un réseau mobile, chaque recherche DNS doit aller du téléphone à la tour cellulaire pour atteindre un serveur DNS faisant autorité. La distance entre un téléphone, une tour de téléphonie cellulaire et le serveur de noms peut ajouter une latence significative.</p>
+Cela peut être problématique pour les performances, en particulier sur les réseaux mobiles. Lorsqu'un utilisateur est sur un réseau mobile, chaque recherche DNS doit aller du téléphone à la tour cellulaire pour atteindre un serveur DNS faisant autorité. La distance entre un téléphone, une tour de téléphonie cellulaire et le serveur de noms peut ajouter une latence significative.
 
-<h3 id="TCP_Handshake">TCP Handshake</h3>
+### TCP Handshake
 
-<p>Une fois que l'adresse IP est connue, le navigateur établit une connexion avec le serveur via un {{glossary('TCP handshake','négociation de liaison TCP à trois voies')}}. TCe mécanisme est conçu pour que deux entités essayant de communiquer, dans ce cas le navigateur et le serveur Web, puissent négocier les paramètres de la connexion de socket TCP sur le réseau avant de transmettre des données, souvent sur {{glossary('HTTPS')}}.</p>
+Une fois que l'adresse IP est connue, le navigateur établit une connexion avec le serveur via un {{glossary('TCP handshake','négociation de liaison TCP à trois voies')}}. TCe mécanisme est conçu pour que deux entités essayant de communiquer, dans ce cas le navigateur et le serveur Web, puissent négocier les paramètres de la connexion de socket TCP sur le réseau avant de transmettre des données, souvent sur {{glossary('HTTPS')}}.
 
-<p>La technique de négociation à trois voies de TCP est souvent appelée "SYN-SYN-ACK", ou plus précisément SYN, SYN-ACK, ACK, car trois messages sont transmis par TCP pour négocier et démarrer une session TCP entre deux ordinateurs. Oui, cela signifie trois messages supplémentaires entre chaque serveur et la demande doit encore être faite.</p>
+La technique de négociation à trois voies de TCP est souvent appelée "SYN-SYN-ACK", ou plus précisément SYN, SYN-ACK, ACK, car trois messages sont transmis par TCP pour négocier et démarrer une session TCP entre deux ordinateurs. Oui, cela signifie trois messages supplémentaires entre chaque serveur et la demande doit encore être faite.
 
-<h3 id="Negotiation_TLS">Negotiation TLS</h3>
+### Negotiation TLS
 
-<p>Pour les connexions sécurisées établies via HTTPS, une autre "liaison" est requise. Cette négociation, ou plutôt la négociation {{glossary('TLS')}}, détermine quel chiffrement sera utilisé pour chiffrer la communication, vérifie le serveur et établit qu'une connexion sécurisée est en place avant de commencer le transfert effectif des données. Cela nécessite encore trois allers-retours vers le serveur avant que la demande de contenu ne soit réellement envoyée.</p>
+Pour les connexions sécurisées établies via HTTPS, une autre "liaison" est requise. Cette négociation, ou plutôt la négociation {{glossary('TLS')}}, détermine quel chiffrement sera utilisé pour chiffrer la communication, vérifie le serveur et établit qu'une connexion sécurisée est en place avant de commencer le transfert effectif des données. Cela nécessite encore trois allers-retours vers le serveur avant que la demande de contenu ne soit réellement envoyée.
 
-<p><img src="ssl.jpg"></p>
+![](ssl.jpg)
 
-<p>Bien que sécuriser la connexion ajoute du temps au chargement de la page, une connexion sécurisée vaut la dépense en latence, car les données transmises entre le navigateur et le serveur Web ne peuvent pas être déchiffrées par un tiers.</p>
+Bien que sécuriser la connexion ajoute du temps au chargement de la page, une connexion sécurisée vaut la dépense en latence, car les données transmises entre le navigateur et le serveur Web ne peuvent pas être déchiffrées par un tiers.
 
-<p>Après les 8 allers-retours, le navigateur est enfin en mesure de faire la demande.</p>
+Après les 8 allers-retours, le navigateur est enfin en mesure de faire la demande.
 
-<h2 id="Response">Response</h2>
+## Response
 
-<p>Une fois la connexion établie avec un serveur Web établie, le navigateur envoie une <a href="/fr/docs/Web/HTTP/M%C3%A9thode">demande HTTP <code>GET</code></a> initiale au nom de l'utilisateur, qui pour les sites Web est le plus souvent un fichier HTML. Dès que le serveur reçoit la demande, il répond avec les en-têtes de réponse pertinents et le contenu du code HTML.</p>
+Une fois la connexion établie avec un serveur Web établie, le navigateur envoie une [demande HTTP `GET`](/fr/docs/Web/HTTP/M%C3%A9thode) initiale au nom de l'utilisateur, qui pour les sites Web est le plus souvent un fichier HTML. Dès que le serveur reçoit la demande, il répond avec les en-têtes de réponse pertinents et le contenu du code HTML.
 
-<pre class="brush: html">&lt;!doctype HTML&gt;
-&lt;html lang="fr"&gt;
- &lt;head&gt;
-  &lt;meta charset="UTF-8"/&gt;
-  &lt;title&gt;Une page simple&lt;/title&gt;
-  &lt;link rel="stylesheet" src="styles.css"/&gt;
-  &lt;script src="monscript.js"&gt;&lt;/script&gt;
-&lt;/head&gt;
-&lt;body&gt;
-  &lt;h1 class="heading"&gt;Ma Page&lt;/h1&gt;
-  &lt;p&gt;Un paragraph avec in &lt;a href="https://example.com/about"&gt;lien&lt;/a&gt;&lt;/p&gt;
-  &lt;div&gt;
-    &lt;img src="monImage.jpg" alt="description de l'image"/&gt;
-  &lt;/div&gt;
-  &lt;script src="unautrescript.js"&gt;&lt;/script&gt;
-&lt;/body&gt;
-&lt;/html&gt;</pre>
+```html
+<!doctype HTML>
+<html lang="fr">
+ <head>
+  <meta charset="UTF-8"/>
+  <title>Une page simple</title>
+  <link rel="stylesheet" src="styles.css"/>
+  <script src="monscript.js"></script>
+</head>
+<body>
+  <h1 class="heading">Ma Page</h1>
+  <p>Un paragraph avec in <a href="https://example.com/about">lien</a></p>
+  <div>
+    <img src="monImage.jpg" alt="description de l'image"/>
+  </div>
+  <script src="unautrescript.js"></script>
+</body>
+</html>
+```
 
-<p>La réponse pour cette demande initiale contient le premier octet de données reçu. {{glossary('Time to First Byte')}} (TTFB) est le temps écoulé entre le moment où l'utilisateur a fait la demande (disons en cliquant sur un lien) et la réception du premier paquet HTML. Le premier bloc de contenu est généralement constitué de 14 Kb de données.</p>
+La réponse pour cette demande initiale contient le premier octet de données reçu. {{glossary('Time to First Byte')}} (TTFB) est le temps écoulé entre le moment où l'utilisateur a fait la demande (disons en cliquant sur un lien) et la réception du premier paquet HTML. Le premier bloc de contenu est généralement constitué de 14 Kb de données.
 
-<p>Dans notre exemple ci-dessus, la demande est nettement inférieure à 14 Kb, mais les ressources liées ne sont pas demandées tant que le navigateur n'a pas rencontré les liens lors de l'analyse, décrit ci-dessous.</p>
+Dans notre exemple ci-dessus, la demande est nettement inférieure à 14 Kb, mais les ressources liées ne sont pas demandées tant que le navigateur n'a pas rencontré les liens lors de l'analyse, décrit ci-dessous.
 
-<h3 id="TCP_Slow_Start_14kb_rule">TCP Slow Start / 14kb rule</h3>
+### TCP Slow Start / 14kb rule
 
-<p>Le premier paquet de réponse sera de 14 Kb. Cela fait partie de {{glossary('TCP slow start')}}, un algorithme qui équilibre la vitesse d'une connexion réseau. Le démarrage lent augmente progressivement la quantité de données transmises jusqu'à ce que la bande passante maximale du réseau puisse être déterminée.</p>
+Le premier paquet de réponse sera de 14 Kb. Cela fait partie de {{glossary('TCP slow start')}}, un algorithme qui équilibre la vitesse d'une connexion réseau. Le démarrage lent augmente progressivement la quantité de données transmises jusqu'à ce que la bande passante maximale du réseau puisse être déterminée.
 
-<p>Avec un {{glossary('TCP slow start')}}, après la réception du paquet initial, le serveur double la taille du paquet suivant, pour atteindre environ 28 Kb. La taille des paquets suivants augmente jusqu'à atteindre un seuil prédéterminé ou jusqu'à ce qu'un encombrement se produise.</p>
+Avec un {{glossary('TCP slow start')}}, après la réception du paquet initial, le serveur double la taille du paquet suivant, pour atteindre environ 28 Kb. La taille des paquets suivants augmente jusqu'à atteindre un seuil prédéterminé ou jusqu'à ce qu'un encombrement se produise.
 
-<p><img src="congestioncontrol.jpg"></p>
+![](congestioncontrol.jpg)
 
-<p>Si vous avez déjà entendu parler de la règle de 14 Kb pour le chargement de page initial, c'est le démarrage lent de TCP qui explique pourquoi la réponse initiale est de 14 Ko et pourquoi l'optimisation des performances Web appelle à l'optimisation de la focalisation avec cette réponse initiale à l'esprit. Le démarrage lent TCP augmente progressivement les vitesses de transmission en fonction des capacités du réseau afin d'éviter les encombrements.</p>
+Si vous avez déjà entendu parler de la règle de 14 Kb pour le chargement de page initial, c'est le démarrage lent de TCP qui explique pourquoi la réponse initiale est de 14 Ko et pourquoi l'optimisation des performances Web appelle à l'optimisation de la focalisation avec cette réponse initiale à l'esprit. Le démarrage lent TCP augmente progressivement les vitesses de transmission en fonction des capacités du réseau afin d'éviter les encombrements.
 
-<h3 id="Contrôle_congestion">Contrôle congestion</h3>
+### Contrôle congestion
 
-<p>Lorsque le serveur envoie des données sous forme de paquets TCP, le client de l'utilisateur confirme la livraison en renvoyant des accusés de réception, ou ACK. La connexion a une capacité limitée en fonction des conditions matérielles et du réseau. Si le serveur envoie trop de paquets trop rapidement, ils seront supprimés. Sens, il n'y aura pas de reconnaissance. Le serveur l'enregistre comme ACK manquant. Les algorithmes de contrôle d'encombrement utilisent ce flux de paquets envoyés et d'accusés de réception pour déterminer un débit d'envoi.</p>
+Lorsque le serveur envoie des données sous forme de paquets TCP, le client de l'utilisateur confirme la livraison en renvoyant des accusés de réception, ou ACK. La connexion a une capacité limitée en fonction des conditions matérielles et du réseau. Si le serveur envoie trop de paquets trop rapidement, ils seront supprimés. Sens, il n'y aura pas de reconnaissance. Le serveur l'enregistre comme ACK manquant. Les algorithmes de contrôle d'encombrement utilisent ce flux de paquets envoyés et d'accusés de réception pour déterminer un débit d'envoi.
 
-<h2 id="Parsing">Parsing</h2>
+## Parsing
 
-<p>Une fois que le navigateur a reçu le premier bloc de données, il peut commencer à analyser les informations reçues. L'analyse, our {{glossary('speculative parsing', 'parsing')}}, est l'étape par laquelle le navigateur prend pour transformer les données qu'il reçoit sur le réseau en {{glossary('DOM')}} et {{glossary('CSSOM' )}}, qui est utilisé par le moteur de rendu pour peindre une page à l'écran.</p>
+Une fois que le navigateur a reçu le premier bloc de données, il peut commencer à analyser les informations reçues. L'analyse, our {{glossary('speculative parsing', 'parsing')}}, est l'étape par laquelle le navigateur prend pour transformer les données qu'il reçoit sur le réseau en {{glossary('DOM')}} et {{glossary('CSSOM' )}}, qui est utilisé par le moteur de rendu pour peindre une page à l'écran.
 
-<p>Le DOM est la représentation interne du balisage pour le navigateur. Le DOM est également exposé et peut être manipulé via diverses API en JavaScript.</p>
+Le DOM est la représentation interne du balisage pour le navigateur. Le DOM est également exposé et peut être manipulé via diverses API en JavaScript.
 
-<p>Même si le code HTML de la page de demande est plus volumineux que le paquet initial de 14 Kb, le navigateur commencera à analyser et à tenter de restituer une expérience en fonction des données dont il dispose. C'est pourquoi il est important pour l'optimisation des performances Web d'inclure tout ce dont le navigateur a besoin pour commencer le rendu d'une page, ou du moins d'un modèle de page - les CSS et HTML nécessaires au premier rendu - dans les 14 premiers kilo-octets. Mais avant que tout ne soit rendu à l'écran, le HTML, CSS et JavaScript doivent être analysés.</p>
+Même si le code HTML de la page de demande est plus volumineux que le paquet initial de 14 Kb, le navigateur commencera à analyser et à tenter de restituer une expérience en fonction des données dont il dispose. C'est pourquoi il est important pour l'optimisation des performances Web d'inclure tout ce dont le navigateur a besoin pour commencer le rendu d'une page, ou du moins d'un modèle de page - les CSS et HTML nécessaires au premier rendu - dans les 14 premiers kilo-octets. Mais avant que tout ne soit rendu à l'écran, le HTML, CSS et JavaScript doivent être analysés.
 
-<h3 id="Building_the_DOM_tree">Building the DOM tree</h3>
+### Building the DOM tree
 
-<p>Nous décrivons cinq étapes dans le chemin de rendu critique, ou "<a href="/fr/docs/Web/Performance/Critical_rendering_path">critical rendering path</a>".</p>
+Nous décrivons cinq étapes dans le chemin de rendu critique, ou "[critical rendering path](/fr/docs/Web/Performance/Critical_rendering_path)".
 
-<p>La première étape consiste à traiter le balisage HTML et à créer l'arborescence DOM. L'analyse HTML implique la création de jetons, <a href="/fr/docs/Web/API/DOMTokenList">tokenization,</a> et la construction du DOM tree. Les jetons HTML incluent les balises de début et de fin, ainsi que les noms et les valeurs des attributs. Si le document est bien formé, son analyse est simple et rapide. L'analyseur analyse les entrées sous forme de jetons dans le document, créant ainsi le document tree.</p>
+La première étape consiste à traiter le balisage HTML et à créer l'arborescence DOM. L'analyse HTML implique la création de jetons, [tokenization,](/fr/docs/Web/API/DOMTokenList) et la construction du DOM tree. Les jetons HTML incluent les balises de début et de fin, ainsi que les noms et les valeurs des attributs. Si le document est bien formé, son analyse est simple et rapide. L'analyseur analyse les entrées sous forme de jetons dans le document, créant ainsi le document tree.
 
-<p>Le DOM tree décrit le contenu du document. L'élément <code><a href="/fr/docs/Web/HTML/Element/html">&lt;html&gt;</a></code> est la première balise et le premier nœud racine de du document tree. L'arbre reflète les relations et les hiérarchies entre différentes balises. Les balises imbriquées dans d'autres balises sont des nœuds enfants. Plus le nombre de nœuds DOM est élevé, le plus de temps ca prends pour construire le DOM tree.</p>
+Le DOM tree décrit le contenu du document. L'élément [`<html>`](/fr/docs/Web/HTML/Element/html) est la première balise et le premier nœud racine de du document tree. L'arbre reflète les relations et les hiérarchies entre différentes balises. Les balises imbriquées dans d'autres balises sont des nœuds enfants. Plus le nombre de nœuds DOM est élevé, le plus de temps ca prends pour construire le DOM tree.
 
-<p><img src="dom.gif"></p>
+![](dom.gif)
 
-<p>Lorsque l'analyseur trouve des ressources non bloquantes, telles qu'une image, le navigateur demande ces ressources et poursuit l'analyse. L'analyse peut continuer lorsqu'un fichier CSS est rencontré, mais les balises <code>&lt;script&gt;</code>, en particulier celles sans attribut <code><a href="/fr/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> ou <code>defer</code>, bloquent le rendu et mettent en pause l'analyse du code HTML. Bien que le scanner de précharge du navigateur accélère ce processus, le nombre excessif de scripts peut toujours constituer un goulot d'étranglement important.</p>
+Lorsque l'analyseur trouve des ressources non bloquantes, telles qu'une image, le navigateur demande ces ressources et poursuit l'analyse. L'analyse peut continuer lorsqu'un fichier CSS est rencontré, mais les balises `<script>`, en particulier celles sans attribut [`async`](/fr/docs/Web/JavaScript/Reference/Statements/async_function) ou `defer`, bloquent le rendu et mettent en pause l'analyse du code HTML. Bien que le scanner de précharge du navigateur accélère ce processus, le nombre excessif de scripts peut toujours constituer un goulot d'étranglement important.
 
-<h3 id="Preload_scanner">Preload scanner</h3>
+### Preload scanner
 
-<p>Pendant que le navigateur construit le DOM tree, ce processus occupe le thread principal. Dans ce cas, le scanner de préchargement analysera le contenu disponible et demandera des ressources hautement prioritaires telles que CSS, JavaScript et les polices. Grâce à l'analyseur de précharge, il n'est pas nécessaire d'attendre que l'analyseur trouve une référence à une ressource externe pour la demander. Il récupérera les ressources en arrière-plan, de sorte qu'au moment où l'analyseur HTML principal atteindra les actifs demandés, il se peut qu'ils soient déjà en vol ou aient été téléchargés. Les optimisations fournies par le scanner de précharge permettent de réduire les blocages.</p>
+Pendant que le navigateur construit le DOM tree, ce processus occupe le thread principal. Dans ce cas, le scanner de préchargement analysera le contenu disponible et demandera des ressources hautement prioritaires telles que CSS, JavaScript et les polices. Grâce à l'analyseur de précharge, il n'est pas nécessaire d'attendre que l'analyseur trouve une référence à une ressource externe pour la demander. Il récupérera les ressources en arrière-plan, de sorte qu'au moment où l'analyseur HTML principal atteindra les actifs demandés, il se peut qu'ils soient déjà en vol ou aient été téléchargés. Les optimisations fournies par le scanner de précharge permettent de réduire les blocages.
 
-<pre class="brush:html">&lt;link rel="stylesheet" src="styles.css"/&gt;
-&lt;script src="myscript.js" <strong>async</strong>&gt;&lt;/script&gt;
-&lt;img src="monImage.jpg" alt="description de l'image"/&gt;
-&lt;script src="unautrescript.js" <strong>async</strong>&gt;&lt;/script&gt;
-</pre>
+```html
+<link rel="stylesheet" src="styles.css"/>
+<script src="myscript.js" async></script>
+<img src="monImage.jpg" alt="description de l'image"/>
+<script src="unautrescript.js" async></script>
+```
 
-<p>Dans cet exemple, alors que le fil principal analyse HTML et CSS, le scanner de préchargement trouvera les scripts et l'image, et commencera également à les télécharger. Pour vous assurer que le script ne bloque pas le processus, ajoutez l'attribut <code>async</code> ou <code>defer</code> si l'analyse et l'exécution de JavaScript ne sont pas importantes.</p>
+Dans cet exemple, alors que le fil principal analyse HTML et CSS, le scanner de préchargement trouvera les scripts et l'image, et commencera également à les télécharger. Pour vous assurer que le script ne bloque pas le processus, ajoutez l'attribut `async` ou `defer` si l'analyse et l'exécution de JavaScript ne sont pas importantes.
 
-<p>L’attente pour obtenir CSS ne bloque pas l’analyse ou le téléchargement HTML, mais bloque JavaScript, car JavaScript est souvent utilisé pour rechercher l’impact des propriétés CSS sur les éléments.</p>
+L’attente pour obtenir CSS ne bloque pas l’analyse ou le téléchargement HTML, mais bloque JavaScript, car JavaScript est souvent utilisé pour rechercher l’impact des propriétés CSS sur les éléments.
 
-<h3 id="Construction_du_CSSOM">Construction du CSSOM</h3>
+### Construction du CSSOM
 
-<p>La deuxième étape du chemin de rendu critique est le traitement de CSS et la construction du CSSOM. Le modèle d'objet CSS est similaire au DOM. Les DOM et CSSOM sont deux arbres. Ce sont des structures de données indépendantes. Le navigateur convertit les règles CSS en une carte de styles qu'il peut comprendre et utiliser. Le navigateur passe en revue chaque ensemble de règles de la feuille de style CSS, créant ainsi une arbre de noeuds avec des relations parent, enfant et sœurs basées sur les sélecteurs CSS.</p>
+La deuxième étape du chemin de rendu critique est le traitement de CSS et la construction du CSSOM. Le modèle d'objet CSS est similaire au DOM. Les DOM et CSSOM sont deux arbres. Ce sont des structures de données indépendantes. Le navigateur convertit les règles CSS en une carte de styles qu'il peut comprendre et utiliser. Le navigateur passe en revue chaque ensemble de règles de la feuille de style CSS, créant ainsi une arbre de noeuds avec des relations parent, enfant et sœurs basées sur les sélecteurs CSS.
 
-<p>Comme avec HTML, le navigateur doit convertir les règles CSS reçues en quelque chose avec lequel il peut travailler. Par conséquent, il répète le processus HTML-à-object, mais pour le CSS.</p>
+Comme avec HTML, le navigateur doit convertir les règles CSS reçues en quelque chose avec lequel il peut travailler. Par conséquent, il répète le processus HTML-à-object, mais pour le CSS.
 
-<p>L'arbre CSSOM comprend les styles du stylesheet de l'agent utilisateur. Le navigateur commence par la règle la plus générale applicable à un nœud et affine de manière récursive les styles calculés en appliquant des règles plus spécifiques. En d'autres termes, il cascade les valeurs de propriété.</p>
+L'arbre CSSOM comprend les styles du stylesheet de l'agent utilisateur. Le navigateur commence par la règle la plus générale applicable à un nœud et affine de manière récursive les styles calculés en appliquant des règles plus spécifiques. En d'autres termes, il cascade les valeurs de propriété.
 
-<p>La construction du CSSOM est très, très rapide et n’est pas affiché dans une couleur unique dans les outils de développement actuels. Le "Style recalculé" dans les outils de développement indique le temps total nécessaire à l'analyse CSS, à la construction du CSSOM et au calcul récursif des styles calculés. En ce qui concerne l’optimisation des performances Web, l’effet de l’effort d’optimisation de la construction CSSOM crée sont minimes, car le temps total nécessaire pour créer le CSSOM est généralement inférieur au temps requis pour une recherche DNS.</p>
+La construction du CSSOM est très, très rapide et n’est pas affiché dans une couleur unique dans les outils de développement actuels. Le "Style recalculé" dans les outils de développement indique le temps total nécessaire à l'analyse CSS, à la construction du CSSOM et au calcul récursif des styles calculés. En ce qui concerne l’optimisation des performances Web, l’effet de l’effort d’optimisation de la construction CSSOM crée sont minimes, car le temps total nécessaire pour créer le CSSOM est généralement inférieur au temps requis pour une recherche DNS.
 
-<h3 id="Autres_Processus">Autres Processus</h3>
+### Autres Processus
 
-<h4 id="Compilation_JavaScript">Compilation JavaScript</h4>
+#### Compilation JavaScript
 
-<p>Lors de l’analyse du CSS et de la création du CSSOM, d’autres ressources, notamment des fichiers JavaScript, sont en cours de téléchargement (grâce au scanner de préchargement). JavaScript est interprété, compilé, analysé et exécuté. Les scripts sont analysés dans des arbres à syntaxe abstraite. Certains moteurs de navigateur utilisent le {{glossary('Abstract Syntax Tree','Arbre de syntaxe abstraite')}} et le transmettent à un interpréteur, générant le code binaire exécuté sur le thread principal. Ceci est connu sous le nom de compilation JavaScript.</p>
+Lors de l’analyse du CSS et de la création du CSSOM, d’autres ressources, notamment des fichiers JavaScript, sont en cours de téléchargement (grâce au scanner de préchargement). JavaScript est interprété, compilé, analysé et exécuté. Les scripts sont analysés dans des arbres à syntaxe abstraite. Certains moteurs de navigateur utilisent le {{glossary('Abstract Syntax Tree','Arbre de syntaxe abstraite')}} et le transmettent à un interpréteur, générant le code binaire exécuté sur le thread principal. Ceci est connu sous le nom de compilation JavaScript.
 
-<h4 id="Construire_l'arbre_d'accessibilité">Construire l'arbre d'accessibilité</h4>
+#### Construire l'arbre d'accessibilité
 
-<p>Le navigateur crée également une arbre d'<a href="/fr/docs/Apprendre/a11y">accessibilité</a> que les périphériques d'assistance utilisent pour analyser et interpréter le contenu. Le modèle d'objet d'accessibilité (AOM) est comme une version sémantique du DOM. Le navigateur met à jour l'arbre d'accessibilité lorsque le DOM est mis à jour. L'arbre d'accessibilité n'est pas modifiable par les technologies d'assistance elles-mêmes.</p>
+Le navigateur crée également une arbre d'[accessibilité](/fr/docs/Apprendre/a11y) que les périphériques d'assistance utilisent pour analyser et interpréter le contenu. Le modèle d'objet d'accessibilité (AOM) est comme une version sémantique du DOM. Le navigateur met à jour l'arbre d'accessibilité lorsque le DOM est mis à jour. L'arbre d'accessibilité n'est pas modifiable par les technologies d'assistance elles-mêmes.
 
-<p>Jusqu'à la construction de l'AOM, le contenu n'est pas accessible aux <a href="/fr/docs/Accessibilit%C3%A9/ARIA/FAQ_Applications_Web_et_ARIA">lecteurs d'écran</a>.</p>
+Jusqu'à la construction de l'AOM, le contenu n'est pas accessible aux [lecteurs d'écran](/fr/docs/Accessibilit%C3%A9/ARIA/FAQ_Applications_Web_et_ARIA).
 
-<h2 id="Rendre">Rendre</h2>
+## Rendre
 
-<p>Les étapes de rendu incluent le style, la mise en page, la peinture et, dans certains cas, la composition. Les arbres CSSOM et DOM créés à l'étape d'analyse sont combinés en un arbre de rendu qui est ensuite utilisé pour calculer la mise en page de chaque élément visible, qui est ensuite peint à l'écran. Dans certains cas, le contenu peut être promu dans ses propres couches et composé, ce qui améliore les performances en peignant des parties de l'écran sur le GPU au lieu du CPU, libérant ainsi le thread principal.</p>
+Les étapes de rendu incluent le style, la mise en page, la peinture et, dans certains cas, la composition. Les arbres CSSOM et DOM créés à l'étape d'analyse sont combinés en un arbre de rendu qui est ensuite utilisé pour calculer la mise en page de chaque élément visible, qui est ensuite peint à l'écran. Dans certains cas, le contenu peut être promu dans ses propres couches et composé, ce qui améliore les performances en peignant des parties de l'écran sur le GPU au lieu du CPU, libérant ainsi le thread principal.
 
-<h3 id="Style">Style</h3>
+### Style
 
-<p>La troisième étape du chemin de rendu critique consiste à combiner le DOM et CSSOM dans une arborescence de rendu. La construction de l'arbre de style calculé ou de l'arbre de rendu commence à la racine de l'arborescence DOM, en traversant chaque nœud visible.</p>
+La troisième étape du chemin de rendu critique consiste à combiner le DOM et CSSOM dans une arborescence de rendu. La construction de l'arbre de style calculé ou de l'arbre de rendu commence à la racine de l'arborescence DOM, en traversant chaque nœud visible.
 
-<p>Les balises qui ne vont pas être affichées, telles que <code><a href="/fr/docs/Web/HTML/Element/head">&lt;head&gt;</a></code> et ses enfants, ainsi que tous les nœuds avec <code>display: none</code>, tel que le <code>script { display: none;</code><code>}</code> vous trouverez dans les feuilles de style de l'agent utilisateur, ne sont pas inclus dans l'arborescence de rendu car ils n'apparaîtront pas dans la sortie rendue. Les nœuds avec <code>visibility: hidden</code> appliqué sont inclus dans l'arborescence de rendu, car ils occupent de l'espace. Comme nous n'avons donné aucune directive pour remplacer la valeur par défaut de l'agent utilisateur, le noeud de <code>script</code> de notre exemple de code ci-dessus ne sera pas inclus dans l'arbre de rendu.</p>
+Les balises qui ne vont pas être affichées, telles que [`<head>`](/fr/docs/Web/HTML/Element/head) et ses enfants, ainsi que tous les nœuds avec `display: none`, tel que le ` script { display: none;``} ` vous trouverez dans les feuilles de style de l'agent utilisateur, ne sont pas inclus dans l'arborescence de rendu car ils n'apparaîtront pas dans la sortie rendue. Les nœuds avec `visibility: hidden` appliqué sont inclus dans l'arborescence de rendu, car ils occupent de l'espace. Comme nous n'avons donné aucune directive pour remplacer la valeur par défaut de l'agent utilisateur, le noeud de `script` de notre exemple de code ci-dessus ne sera pas inclus dans l'arbre de rendu.
 
-<p>Les règles CSSOM sont appliquées à chaque nœud visible. L'arborescence de rendu contient tous les nœuds visibles avec le contenu et les styles calculés - en faisant correspondre tous les styles pertinents à chaque nœud visible du DOM tree et en déterminant, en fonction de la cascade CSS, les styles calculés pour chaque nœud.</p>
+Les règles CSSOM sont appliquées à chaque nœud visible. L'arborescence de rendu contient tous les nœuds visibles avec le contenu et les styles calculés - en faisant correspondre tous les styles pertinents à chaque nœud visible du DOM tree et en déterminant, en fonction de la cascade CSS, les styles calculés pour chaque nœud.
 
-<h3 id="Disposition">Disposition</h3>
+### Disposition
 
-<p>La quatrième étape du chemin de rendu critique consiste à exécuter la disposition sur l’arbre de rendu pour calculer la géométrie de chaque noeud.</p>
+La quatrième étape du chemin de rendu critique consiste à exécuter la disposition sur l’arbre de rendu pour calculer la géométrie de chaque noeud.
 
-<p>La disposition est le processus par lequel la largeur, la hauteur et l'emplacement de tous les noeuds de l'arbre de rendu sont déterminés, ainsi que la détermination de la taille et de la position de chaque objet sur la page. La redistribution correspond à toute détermination ultérieure de la taille et de la position d'une partie de la page ou du document dans son ensemble.</p>
+La disposition est le processus par lequel la largeur, la hauteur et l'emplacement de tous les noeuds de l'arbre de rendu sont déterminés, ainsi que la détermination de la taille et de la position de chaque objet sur la page. La redistribution correspond à toute détermination ultérieure de la taille et de la position d'une partie de la page ou du document dans son ensemble.
 
-<p>Une fois que l'arborescence de rendu est construite, la mise en page commence. L'arbre de rendu identifiait les nœuds affichés (même s'ils étaient invisibles) avec leurs styles calculés, mais pas les dimensions ou l'emplacement de chaque nœud. Pour déterminer la taille et l'emplacement exact de chaque objet, le navigateur commence à la racine de l'arbre de rendu et le traverse.</p>
+Une fois que l'arborescence de rendu est construite, la mise en page commence. L'arbre de rendu identifiait les nœuds affichés (même s'ils étaient invisibles) avec leurs styles calculés, mais pas les dimensions ou l'emplacement de chaque nœud. Pour déterminer la taille et l'emplacement exact de chaque objet, le navigateur commence à la racine de l'arbre de rendu et le traverse.
 
-<p>Sur la page Web, presque tout est une boîte. Différents périphériques et différentes préférences de bureau signifient un nombre illimité de tailles de fenêtres d'affichage différentes. Au cours de cette phase, prenant en compte la taille de la fenêtre d'affichage, le navigateur détermine les dimensions de toutes les différentes boîtes à l'écran. En prenant la taille de la fenêtre comme base, la présentation commence généralement par le corps, elle présente les dimensions de tous les descendants du corps, ainsi que les propriétés du modèle de boîte de chaque élément, offrant ainsi un espace réservé aux éléments remplacés dont il ne connaît pas les dimensions: comme notre image.</p>
+Sur la page Web, presque tout est une boîte. Différents périphériques et différentes préférences de bureau signifient un nombre illimité de tailles de fenêtres d'affichage différentes. Au cours de cette phase, prenant en compte la taille de la fenêtre d'affichage, le navigateur détermine les dimensions de toutes les différentes boîtes à l'écran. En prenant la taille de la fenêtre comme base, la présentation commence généralement par le corps, elle présente les dimensions de tous les descendants du corps, ainsi que les propriétés du modèle de boîte de chaque élément, offrant ainsi un espace réservé aux éléments remplacés dont il ne connaît pas les dimensions: comme notre image.
 
-<p>La première fois que la taille et la position des nœuds sont déterminées est appelée "mise en page", ou <i lang="en">layout</i>. Les recalculs ultérieurs de la taille et des emplacements des noeuds sont appelés redistributions, ou <i lang="en">reflows</i>. Dans notre exemple, supposons que la mise en page initiale se produise avant que l'image ne soit renvoyée. Comme nous n’avons pas déclaré la taille de notre image, il y aura un reflow une fois que la taille de l’image est connue.</p>
+La première fois que la taille et la position des nœuds sont déterminées est appelée "mise en page", ou <i lang="en">layout</i>. Les recalculs ultérieurs de la taille et des emplacements des noeuds sont appelés redistributions, ou <i lang="en">reflows</i>. Dans notre exemple, supposons que la mise en page initiale se produise avant que l'image ne soit renvoyée. Comme nous n’avons pas déclaré la taille de notre image, il y aura un reflow une fois que la taille de l’image est connue.
 
-<h3 id="Peindre">Peindre</h3>
+### Peindre
 
-<p>La dernière étape du chemin de rendu critique consiste à peindre les nœuds individuels à l'écran, la première occurrence étant appelée la première peinture significative, ou <i lang="en">first meaningful paint</i>.</p>
+La dernière étape du chemin de rendu critique consiste à peindre les nœuds individuels à l'écran, la première occurrence étant appelée la première peinture significative, ou <i lang="en">first meaningful paint</i>.
 
-<p>Lors de la phase de peinture ou de rastérisation, le navigateur convertit chaque case calculée lors de la phase de mise en page en pixels réels à l'écran. La peinture implique de dessiner chaque partie visuelle d'un élément sur l'écran, y compris le texte, les couleurs, les bordures, les ombres et les éléments remplacés, comme les boutons et les images. Le navigateur doit faire cela très rapidement.</p>
+Lors de la phase de peinture ou de rastérisation, le navigateur convertit chaque case calculée lors de la phase de mise en page en pixels réels à l'écran. La peinture implique de dessiner chaque partie visuelle d'un élément sur l'écran, y compris le texte, les couleurs, les bordures, les ombres et les éléments remplacés, comme les boutons et les images. Le navigateur doit faire cela très rapidement.
 
-<p>Pour assurer un défilement et une animation fluides, tout ce qui occupe le fil principal, y compris le calcul des styles, ainsi que le redistribution et la peinture, doit nécessiter moins de 16,67ms de navigateur.</p>
+Pour assurer un défilement et une animation fluides, tout ce qui occupe le fil principal, y compris le calcul des styles, ainsi que le redistribution et la peinture, doit nécessiter moins de 16,67ms de navigateur.
 
-<p>À 2048 X 1536, l’iPad a plus de 3 145 000 pixels à peindre à l’écran. C'est beaucoup de pixels qui doivent être peints très rapidement. Afin de pouvoir repeindre même plus rapidement que la peinture initiale, le dessin à l'écran est généralement divisé en plusieurs couches, ou <i lang="en">layers</i>. Si cela se produit, la composition est nécessaire.</p>
+À 2048 X 1536, l’iPad a plus de 3 145 000 pixels à peindre à l’écran. C'est beaucoup de pixels qui doivent être peints très rapidement. Afin de pouvoir repeindre même plus rapidement que la peinture initiale, le dessin à l'écran est généralement divisé en plusieurs couches, ou <i lang="en">layers</i>. Si cela se produit, la composition est nécessaire.
 
-<p>La peinture peut diviser les éléments de l’arborescence en couches. La promotion du contenu en couches sur le GPU (au lieu du thread principal sur le CPU) améliore la performances de la peinture originale et chaque la performances de repeinte supplémentaire.</p>
+La peinture peut diviser les éléments de l’arborescence en couches. La promotion du contenu en couches sur le GPU (au lieu du thread principal sur le CPU) améliore la performances de la peinture originale et chaque la performances de repeinte supplémentaire.
 
-<p>Il existe des propriétés et des éléments spécifiques qui instancient un calque, notamment <code>&lt;video&gt;</code> et <code>&lt;canvas&gt;</code>, ainsi que tout élément possédant les propriétés CSS d'<a href="/fr/docs/Web/CSS/opacity">opacité</a>, de <a href="/fr/docs/Web/CSS/CSS_Transforms">transformation 3D</a>, de et de plusieurs valeur de <code><a href="/fr/docs/Web/CSS/will-change">will-change</a></code>, <code><a href="/fr/docs/Web/CSS/isolation">isolation</a></code> et <code><a href="/fr/docs/Web/CSS/contain">contain</a></code>. Ces nœuds seront peints sur leur propre calque, avec leurs descendants, à moins qu'un descendant ne nécessite son propre calque pour une (ou plusieurs) des raisons ci-dessus.</p>
+Il existe des propriétés et des éléments spécifiques qui instancient un calque, notamment `<video>` et `<canvas>`, ainsi que tout élément possédant les propriétés CSS d'[opacité](/fr/docs/Web/CSS/opacity), de [transformation 3D](/fr/docs/Web/CSS/CSS_Transforms), de et de plusieurs valeur de [`will-change`](/fr/docs/Web/CSS/will-change), [`isolation`](/fr/docs/Web/CSS/isolation) et [`contain`](/fr/docs/Web/CSS/contain). Ces nœuds seront peints sur leur propre calque, avec leurs descendants, à moins qu'un descendant ne nécessite son propre calque pour une (ou plusieurs) des raisons ci-dessus.
 
-<p>Les couches améliorent les performances, mais sont coûteuses en termes de gestion de la mémoire et ne doivent donc pas être utilisées de manière excessive dans les stratégies d'optimisation des performances Web.</p>
+Les couches améliorent les performances, mais sont coûteuses en termes de gestion de la mémoire et ne doivent donc pas être utilisées de manière excessive dans les stratégies d'optimisation des performances Web.
 
-<h3 id="Composition">Composition</h3>
+### Composition
 
-<p>Lorsque des sections du document sont dessinées dans différentes couches se chevauchant, la composition est nécessaire pour garantir qu'elles sont dessinées à l'écran dans le bon ordre et que le contenu est restitué correctement.</p>
+Lorsque des sections du document sont dessinées dans différentes couches se chevauchant, la composition est nécessaire pour garantir qu'elles sont dessinées à l'écran dans le bon ordre et que le contenu est restitué correctement.
 
-<p>Si la page continue de charger des ressources, des retraits peuvent se produire (rappelez-vous notre exemple d'image arrivé en retard). Un reflux déclenche un repeinte et un recomposition. Si nous avions défini la taille de notre image, aucune refusion n'aurait été nécessaire, et seule la couche à repeindre serait repeinte et composée si nécessaire. Mais nous n'avons pas inclus la taille de l'image! Lorsque l'image est obtenue à partir du serveur, le processus de rendu reprend les étapes de la mise en page et redémarre à partir de là.</p>
+Si la page continue de charger des ressources, des retraits peuvent se produire (rappelez-vous notre exemple d'image arrivé en retard). Un reflux déclenche un repeinte et un recomposition. Si nous avions défini la taille de notre image, aucune refusion n'aurait été nécessaire, et seule la couche à repeindre serait repeinte et composée si nécessaire. Mais nous n'avons pas inclus la taille de l'image! Lorsque l'image est obtenue à partir du serveur, le processus de rendu reprend les étapes de la mise en page et redémarre à partir de là.
 
-<h2 id="L'interactivité">L'interactivité</h2>
+## L'interactivité
 
-<p>Une fois que le fil principal est terminé, on pourrait penser que nous serions "tout prêt". Ce n'est pas nécessairement le cas. Si le chargement inclut JavaScript, correctement différé et exécuté uniquement après le déclenchement de l'événement <a href="/fr/docs/Web/API/GlobalEventHandlers/onload">onload</a>, le thread principal est peut-être occupé et indisponible pour les interactions de défilement, tactiles et autres.</p>
+Une fois que le fil principal est terminé, on pourrait penser que nous serions "tout prêt". Ce n'est pas nécessairement le cas. Si le chargement inclut JavaScript, correctement différé et exécuté uniquement après le déclenchement de l'événement [onload](/fr/docs/Web/API/GlobalEventHandlers/onload), le thread principal est peut-être occupé et indisponible pour les interactions de défilement, tactiles et autres.
 
-<p>{{glossary('Time to Interactive')}} (TTI) est la mesure du temps qu'il a fallu à cette première demande pour aboutir à la recherche DNS et à la connexion SSL lorsque la page est interactive - interactif étant le point dans le temps après le {{glossary('First Contentful Paint')}} lorsque la page répond aux interactions de l'utilisateur dans un délai de 50 ms. Si le thread principal est occupé à analyser, compiler et exécuter JavaScript, il n'est pas disponible et ne peut donc pas répondre aux interactions de l'utilisateur dans les meilleurs délais (moins de 50 ms).</p>
+{{glossary('Time to Interactive')}} (TTI) est la mesure du temps qu'il a fallu à cette première demande pour aboutir à la recherche DNS et à la connexion SSL lorsque la page est interactive - interactif étant le point dans le temps après le {{glossary('First Contentful Paint')}} lorsque la page répond aux interactions de l'utilisateur dans un délai de 50 ms. Si le thread principal est occupé à analyser, compiler et exécuter JavaScript, il n'est pas disponible et ne peut donc pas répondre aux interactions de l'utilisateur dans les meilleurs délais (moins de 50 ms).
 
-<p>Dans notre exemple, l'image a peut-être été chargée rapidement, mais le fichier <code>unautrescript.js</code> faisait 2 MB et la connexion réseau de notre utilisateur était lente. Dans ce cas, l'utilisateur verrait la page très rapidement, mais ne pourrait pas faire défiler sans jank jusqu'à ce que le script soit téléchargé, analysé et exécuté. Ce n'est pas une bonne expérience utilisateur. Évitez d’occuper le fil principal, comme illustré dans cet exemple <a href="https://webpagetest.org">WebPageTest</a>:</p>
+Dans notre exemple, l'image a peut-être été chargée rapidement, mais le fichier `unautrescript.js` faisait 2 MB et la connexion réseau de notre utilisateur était lente. Dans ce cas, l'utilisateur verrait la page très rapidement, mais ne pourrait pas faire défiler sans jank jusqu'à ce que le script soit téléchargé, analysé et exécuté. Ce n'est pas une bonne expérience utilisateur. Évitez d’occuper le fil principal, comme illustré dans cet exemple [WebPageTest](https://webpagetest.org):
 
-<p><img src="visa_network.png"></p>
+![](visa_network.png)
 
-<p>Dans cet exemple, le processus de chargement du contenu du DOM a duré plus de 1,5 seconde et le thread principal a été entièrement occupé pendant tout ce temps, ne répondant pas pour cliquer sur des événements ou sur des taps à l'écran.</p>
+Dans cet exemple, le processus de chargement du contenu du DOM a duré plus de 1,5 seconde et le thread principal a été entièrement occupé pendant tout ce temps, ne répondant pas pour cliquer sur des événements ou sur des taps à l'écran.
 
-<h2 id="Voir_aussi">Voir aussi</h2>
+## Voir aussi
 
-<ul>
- <li><a href="/fr/docs/Web/Guide/Performance">Web Performance</a></li>
-</ul>
+- [Web Performance](/fr/docs/Web/Guide/Performance)
diff --git a/files/fr/web/performance/how_long_is_too_long/index.md b/files/fr/web/performance/how_long_is_too_long/index.md
index 872d7c77e4..3011ce92e6 100644
--- a/files/fr/web/performance/how_long_is_too_long/index.md
+++ b/files/fr/web/performance/how_long_is_too_long/index.md
@@ -1,28 +1,28 @@
 ---
-title: 'Temps de chargement : à partir de quel moment un site est-il « lent » ?'
+title: "Temps de chargement\_: à partir de quel moment un site est-il «\_lent\_»\_?"
 slug: Web/Performance/How_long_is_too_long
-translation_of: 'Web/Performance/How_long_is_too_long'
+translation_of: Web/Performance/How_long_is_too_long
 ---
-<p>Il n'y a pas de règle stricte définissant ce qui constitue un site trop long à charger, mais il y a des bonnes pratiques spécifiques pour définir un bon temps de chargement du contenu (1&nbsp;seconde), de fonctionnement au ralenti (50&nbsp;millisecondes), d'animation (16,7&nbsp;secondes) ou encore de réponse à la saisie d'un visiteur (50 à 200&nbsp;millisecondes).</p>
+Il n'y a pas de règle stricte définissant ce qui constitue un site trop long à charger, mais il y a des bonnes pratiques spécifiques pour définir un bon temps de chargement du contenu (1 seconde), de fonctionnement au ralenti (50 millisecondes), d'animation (16,7 secondes) ou encore de réponse à la saisie d'un visiteur (50 à 200 millisecondes).
 
-<h2 id="load_goal">Objectifs de chargement</h2>
+## Objectifs de chargement
 
-<p>La durée optimale de temps de chargement est souvent définie comme étant «&nbsp;inférieure à une seconde&nbsp;», mais qu'est-ce que cela signifie&nbsp;? Ce temps d'une seconde devrait être considéré comme le temps maximal pour indiquer à une personne visitant le site que la demande à été traitée et que le nouveau contenu a été chargé, ce qui signifie par exemple que le navigateur affiche le titre de la page et sa couleur de fond.</p>
+La durée optimale de temps de chargement est souvent définie comme étant « inférieure à une seconde », mais qu'est-ce que cela signifie ? Ce temps d'une seconde devrait être considéré comme le temps maximal pour indiquer à une personne visitant le site que la demande à été traitée et que le nouveau contenu a été chargé, ce qui signifie par exemple que le navigateur affiche le titre de la page et sa couleur de fond.
 
-<p>La première ressource récupérée après une demande est généralement un document HTML, qui appelle lui-même par la suite des ressources additionnelles. Comme noté dans la description du <a href="/fr/docs/Web/Performance/Critical_rendering_path">chemin critique de rendu (en anglais <i lang="en">critical rendering path</i>)</a>, lorsque la ressource est reçue alors les navigateurs commencent à traiter le HTML et affichent son rendu au fur et à mesure qu'il est reçu plutôt que d'attendre le chargement des ressources additionnelles.</p>
+La première ressource récupérée après une demande est généralement un document HTML, qui appelle lui-même par la suite des ressources additionnelles. Comme noté dans la description du [chemin critique de rendu (en anglais <i lang="en">critical rendering path</i>)](/fr/docs/Web/Performance/Critical_rendering_path), lorsque la ressource est reçue alors les navigateurs commencent à traiter le HTML et affichent son rendu au fur et à mesure qu'il est reçu plutôt que d'attendre le chargement des ressources additionnelles.
 
-<p>Oui, un temps de chargement d'une seconde est un bon objectif, mais c'est un objectif qui ne sera rempli que par quelques sites seulement. Les attentes diffèrent en réalité en fonction du contexte. L'affichage du texte «&nbsp;Bonjour tout le monde&nbsp;» devrait pouvoir s'afficher en quelques millisecondes sur un réseau d'entreprise, mais le téléchargement de la vidéo d'un chat rigolo sur un appareil de plus de 5 ans avec un réseau <i lang="en">Edge</i> dans le Nord de la Sibérie pourrait prendre plus de 20&nbsp;secondes sans choquer personne. D'une manière plus générale, si vous attendez trois ou quatre secondes avant de fournir le moindre contenu à la personne visitant votre site, vous perdrez des visiteurs potentiels qui ne reviendront peut-être jamais consulter votre site.</p>
+Oui, un temps de chargement d'une seconde est un bon objectif, mais c'est un objectif qui ne sera rempli que par quelques sites seulement. Les attentes diffèrent en réalité en fonction du contexte. L'affichage du texte « Bonjour tout le monde » devrait pouvoir s'afficher en quelques millisecondes sur un réseau d'entreprise, mais le téléchargement de la vidéo d'un chat rigolo sur un appareil de plus de 5 ans avec un réseau <i lang="en">Edge</i> dans le Nord de la Sibérie pourrait prendre plus de 20 secondes sans choquer personne. D'une manière plus générale, si vous attendez trois ou quatre secondes avant de fournir le moindre contenu à la personne visitant votre site, vous perdrez des visiteurs potentiels qui ne reviendront peut-être jamais consulter votre site.
 
-	<p>En optimisant les performances de votre site, visez un temps de premier chargement du contenu ambitieux, comme 5 secondes sur un réseau mobile 3G, et 1,5 seconde sur un réseau Wifi, avec peut-être des objectifs de chargement de page encore plus ambitieux pour les chargements de page ultérieurs, en tirant parti des <i lang="en">service workers</i> et de la mise en cache. Il y a plusieurs étapes où vous devrez travailler, suivant qu'il s'agisse d'initialiser le chargement de la page, du chargement des ressources additionnelles, de la réponse à l'interaction de l'utilisateur ou de l'utilisatrice ou encore pour proposer des animations fluides. C'est ce que nous détaillerons dans les sections suivantes.</p>
+En optimisant les performances de votre site, visez un temps de premier chargement du contenu ambitieux, comme 5 secondes sur un réseau mobile 3G, et 1,5 seconde sur un réseau Wifi, avec peut-être des objectifs de chargement de page encore plus ambitieux pour les chargements de page ultérieurs, en tirant parti des <i lang="en">service workers</i> et de la mise en cache. Il y a plusieurs étapes où vous devrez travailler, suivant qu'il s'agisse d'initialiser le chargement de la page, du chargement des ressources additionnelles, de la réponse à l'interaction de l'utilisateur ou de l'utilisatrice ou encore pour proposer des animations fluides. C'est ce que nous détaillerons dans les sections suivantes.
 
-<h3 id="idling_goal">Objectifs concernant les étapes de chargement de la page (en anglais <i lang="en">idling</i>)</h3>
+### Objectifs concernant les étapes de chargement de la page (en anglais <i lang="en">idling</i>)
 
-<p>Les navigateurs s'occupent des tâches les unes après les autres (même si des tâches de fond peuvent être prises en charge par les <i lang="en">web workers</i>). Cela signifie que l'interaction avec le visiteur, la peinture de la page et l'exécution des scripts ont lieu lors d'un processus unique. Si le processus est occupé à exécuter du code JavaScript complexe, le processus principal ne sera pas disponible pour réagir à la saisie du visiteur (par exemple le fait d'appuyer sur un bouton). Pour cette raison, le périmètre de l'exécution des scripts devrait être limité et divisé en plusieurs bouts de code pouvant chacun être exécuté en 50 millisecondes ou moins. Cela rend le processus disponible pour l'interaction avec la personne visitant le site.</p>
+Les navigateurs s'occupent des tâches les unes après les autres (même si des tâches de fond peuvent être prises en charge par les <i lang="en">web workers</i>). Cela signifie que l'interaction avec le visiteur, la peinture de la page et l'exécution des scripts ont lieu lors d'un processus unique. Si le processus est occupé à exécuter du code JavaScript complexe, le processus principal ne sera pas disponible pour réagir à la saisie du visiteur (par exemple le fait d'appuyer sur un bouton). Pour cette raison, le périmètre de l'exécution des scripts devrait être limité et divisé en plusieurs bouts de code pouvant chacun être exécuté en 50 millisecondes ou moins. Cela rend le processus disponible pour l'interaction avec la personne visitant le site.
 
-<h3 id="animation_goal">Objectifs concernant les animations</h3>
+### Objectifs concernant les animations
 
-<p>Pour les animations de défilement et autres animations qui doivent être fluides et réactives, le contenu est repeint à 60 images par seconde (60 fps), ce qui fait une fois toutes les 16,7&nbsp;millisecondes. Ces 16.7&nbsp;millisecondes incluent la gestion des scripts, le <i lang="en">reflow</i> et le <i lang="en">repaint</i>. Un document met environ 6&nbsp;millisecondes pour rendre une image, ce qui laisse environ 10&nbsp;millisecondes au reste. Tout ce qui prend moins de 60 images par secondes risque d'apparaître cassé, surtout s'il s'agit de changements d'images.</p>
+Pour les animations de défilement et autres animations qui doivent être fluides et réactives, le contenu est repeint à 60 images par seconde (60 fps), ce qui fait une fois toutes les 16,7 millisecondes. Ces 16.7 millisecondes incluent la gestion des scripts, le <i lang="en">reflow</i> et le <i lang="en">repaint</i>. Un document met environ 6 millisecondes pour rendre une image, ce qui laisse environ 10 millisecondes au reste. Tout ce qui prend moins de 60 images par secondes risque d'apparaître cassé, surtout s'il s'agit de changements d'images.
 
-<h3 id="responsiveness_goal">Objectifs concernant la réactivité</h3>
+### Objectifs concernant la réactivité
 
-<p>Lorsque la personne visitant le site interagit avec le contenu, il est important de fournir une réponse et de faire connaître cette réponse au visiteur sous 100&nbsp;millisecondes au maximum, et de préférence en moins de 50&nbsp;millisecondes. Une réponse de 50&nbsp;millisecondes sera ressentie comme étant immédiate. La mise à disposition de l'interaction devrait le plus souvent possible être ressentie comme étant immédiate, par exemple lorsqu'il s'agit du survol ou de l'appui sur un bouton, mais cela ne veut pas dire que la réponse complète devrait être instantanée. Si une réponse plus lente que 100&nbsp;millisecondes peut créer une déconnexion entre l'action du visiteur et la réponse, une transition de 100 ou 200&nbsp;millisecondes peut aider le visiteur à remarquer la réponse à l'interaction initiée, telle que l'ouverture d'un menu. Si une réponse prend plus de 100&nbsp;millisecondes à être terminée, il est important de fournir une forme de retour utilisateur pour informer que l'interaction a bien eu lieu.</p>
+Lorsque la personne visitant le site interagit avec le contenu, il est important de fournir une réponse et de faire connaître cette réponse au visiteur sous 100 millisecondes au maximum, et de préférence en moins de 50 millisecondes. Une réponse de 50 millisecondes sera ressentie comme étant immédiate. La mise à disposition de l'interaction devrait le plus souvent possible être ressentie comme étant immédiate, par exemple lorsqu'il s'agit du survol ou de l'appui sur un bouton, mais cela ne veut pas dire que la réponse complète devrait être instantanée. Si une réponse plus lente que 100 millisecondes peut créer une déconnexion entre l'action du visiteur et la réponse, une transition de 100 ou 200 millisecondes peut aider le visiteur à remarquer la réponse à l'interaction initiée, telle que l'ouverture d'un menu. Si une réponse prend plus de 100 millisecondes à être terminée, il est important de fournir une forme de retour utilisateur pour informer que l'interaction a bien eu lieu.
diff --git a/files/fr/web/performance/index.md b/files/fr/web/performance/index.md
index 074f7b7010..b76ba4f995 100644
--- a/files/fr/web/performance/index.md
+++ b/files/fr/web/performance/index.md
@@ -3,263 +3,230 @@ title: Web Performance
 slug: Web/Performance
 translation_of: Web/Performance
 ---
-<p>Translation in progress</p>
-
-<p>Web performance is the objective measurements and the perceived user experience of load time and runtime. Web performance is how long a site takes to load, become interactive and responsive, and how smooth the content is during user interactions - is the scrolling smooth? are buttons clickable? Are pop-ups quick to load and display, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to become interactive, and subjective experiences of how long it felt like it took the content to load.</p>
-
-<p>The longer it takes for a site to respond, the more users will abandon the site. It is important to minimize the loading and response times and add additional features to conceal latency by making the experience as available and interactive as possible, as soon as possible, while asynchronously loading in the longer tail parts of the experience.</p>
-
-<p>There are tools, APIs, and best practices that help us measure and improve web performance. We cover them in this section:</p>
-
-<h2 id="In_this_section">In this section</h2>
-
-<p>{{LandingPageListSubpages}}</p>
-
-<h2 id="Selected_tutorials">Selected tutorials</h2>
-
-<p>The MDN <a href="/fr/docs/Learn/Performance">Web Performance Learning Area</a> contains modern, up-to-date tutorials covering Performance essentials:</p>
-
-<dl>
- <dt><a href="/fr/docs/Learn/Performance/What_is_web_performance">What is web performance</a></dt>
- <dd>This article starts the module off with a good look at what Performance actually is — this includes the tools, metrics, APIs, networks, and groups of people we need to consider when thinking about performance, and how we can make Performance part of our web development workflow.</dd>
- <dt><a href="/fr/docs/Learn/Performance/web_performance_basics">Web Performance Basics</a></dt>
- <dd>In addition to the front-end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, Developer Tools, best practices and bad practices relating to web performance. Here we'll introduce many of these features at the basic level and provide links to deeper dives to improve performance for each topic.</dd>
- <dt><a href="/fr/docs/Learn/Performance/perceived_performance">How do users perceive performance?</a></dt>
- <dd>
- <p>More important than how fast your website is in milliseconds, is how fast do your users perceive your site to be. Page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations impact these perceptions. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings themselves.</p>
- </dd>
- <dt><a href="/fr/docs/Learn/Performance/Multimedia">Multimedia: Images and Video</a></dt>
- <dd>Frequently, media optimization is the lowest hanging fruit of web performance. Serving different media files based on each user agent's capability, size and pixel density is possible. Additional tips, like removing audio tracks from background images, can improve performance even further. In this article, we discuss the impact video, audio, and image content has on performance, and the methods to ensure that impact is as minimal as possible.</dd>
- <dt><a href="/fr/docs/Learn/Performance/CSS_performance">CSS performance features</a></dt>
- <dd>CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article, we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted.</dd>
-</dl>
-
-<h2>Using Performance APIs</h2>
-
-<dl>
- <dt><a href="/fr/docs/Web/API/Performance_API/Using_the_Performance_API">Performance API</a></dt>
- <dd>This guide describes how to use the <a href="/fr/docs/Web/API/Performance" title="The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API."><code>Performance</code></a> interfaces that are defined in the <a class="external external-icon" href="https://w3c.github.io/hr-time/" rel="noopener">High-Resolution Time</a> standard.</dd>
- <dt><a href="/fr/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></dt>
- <dd><a href="/fr/docs/Web/API/Resource_Timing_API">Resource loading and timing</a> the loading of those resources, including managing the resource buffer and coping with CORS</dd>
- <dt><a href="/fr/docs/Web/API/Performance_Timeline/Using_Performance_Timeline">The performance timeline</a></dt>
- <dd>The <a href="/fr/docs/Web/API/Performance_Timeline">Performance Timeline</a> standard defines extensions to the <a href="/fr/docs/Web/API/Performance" title="The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API."><code>Performance</code></a> interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks.</dd>
- <dt><a href="/fr/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">User Timing API</a></dt>
- <dd>Create application specific timestamps using the <a href="/fr/docs/Web/API/User_Timing_API">user timing API</a>'s "mark" and "measure" entry types - that are part of the browser's performance timeline.</dd>
- <dt><a href="/fr/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API">Frame Timing API</a></dt>
- <dd>The <code><a href="/fr/docs/Web/API/PerformanceFrameTiming">PerformanceFrameTiming</a></code> interface provides <em>frame</em> timing data about the browser's event loop.</dd>
- <dt><a href="/fr/docs/Web/API/Beacon_API/Using_the_Beacon_API">Beacon API</a></dt>
- <dd><small>The <a href="/fr/docs/Web/API/Beacon_API">Beacon</a> interface schedules an asynchronous and non-blocking request to a web server.</small></dd>
- <dt><a href="/fr/docs/Web/API/Intersection_Observer_API/Timing_element_visibility">Intersection Observer API</a></dt>
- <dd>Learn to time element visibility with the <a href="/fr/docs/Web/API/Intersection_Observer_API">Intersection Observer API</a> and be asynchronously notified when elements of interest becomes visible.</dd>
-</dl>
-
-<h2>Other documentation</h2>
-
-<dl>
- <dt><a href="/fr/docs/Tools/Performance">Developer Tools Performance Features</a></dt>
- <dd>This section provides information on how to use and understand the performance features in your developer tools, including <a href="/fr/docs/Tools/Performance/Waterfall">Waterfall</a>, <a href="/fr/docs/Tools/Performance/Call_Tree">Call Tree</a>, and <a href="/fr/docs/Tools/Performance/Flame_Chart">Flame Charts</a>.</dd>
- <dt><a href="/fr/docs/Learn/Performance/Understanding_latency">Understanding Latency</a></dt>
- <dd>Latency is the amount of time it takes between the browser making a request for a resource, and the browser receiving back the first byte of the resource requested. This article explains what latency is, how it impacts performance, how to measure latency, and how to reduce it.</dd>
-</dl>
-
-<h2 id="Glossary_Terms">Glossary Terms</h2>
-
-<ul>
- <li>{{glossary('Beacon')}}</li>
- <li>{{glossary('Brotli compression')}}</li>
- <li>{{glossary('Client hints')}}</li>
- <li>{{glossary('Code splitting')}}</li>
- <li>{{glossary('CSSOM')}}</li>
- <li>{{glossary('Domain sharding')}}</li>
- <li>{{glossary('Effective connection type')}}</li>
- <li>{{glossary('First contentful paint')}}</li>
- <li>{{glossary('First CPU idle')}}</li>
- <li>{{glossary('First input delay')}}</li>
- <li>{{glossary('First interactive')}}</li>
- <li>{{glossary('First meaningful paint')}}</li>
- <li>{{glossary('First paint')}}</li>
- <li>{{glossary('HTTP')}}</li>
- <li>{{glossary('HTTP_2', 'HTTP/2')}}</li>
- <li>{{glossary('Jank')}}</li>
- <li>{{glossary('Latency')}}</li>
- <li>{{glossary('Lazy load')}}</li>
- <li>{{glossary('Long task')}}</li>
- <li>{{glossary('Lossless compression')}}</li>
- <li>{{glossary('Lossy compression')}}</li>
- <li>{{glossary('Main thread')}}</li>
- <li>{{glossary('Minification')}}</li>
- <li>{{glossary('Network throttling')}}</li>
- <li>{{glossary('Packet')}}</li>
- <li>{{glossary('Page load time')}}</li>
- <li>{{glossary('Page prediction')}}</li>
- <li>{{glossary('Parse')}}</li>
- <li>{{glossary('Perceived performance')}}</li>
- <li>{{glossary('Prefetch')}}</li>
- <li>{{glossary('Prerender')}}</li>
- <li>{{glossary('QUIC')}}</li>
- <li>{{glossary('RAIL')}}</li>
- <li>{{glossary('Real User Monitoring')}}</li>
- <li>{{glossary('Resource Timing')}}</li>
- <li>{{glossary('Round Trip Time (RTT)')}}</li>
- <li>{{glossary('Server Timing')}}</li>
- <li>{{glossary('Speculative parsing')}}</li>
- <li>{{glossary('Speed index')}}</li>
- <li>{{glossary('SSL')}}</li>
- <li>{{glossary('Synthetic monitoring')}}</li>
- <li>{{glossary('TCP handshake')}}</li>
- <li>{{glossary('TCP slow start')}}</li>
- <li>{{glossary('Time to first byte')}}</li>
- <li>{{glossary('Time to interactive')}}</li>
- <li>{{glossary('TLS')}}</li>
- <li>{{glossary('TCP', 'Transmission Control Protocol (TCP)')}}</li>
- <li>{{glossary('Tree shaking')}}</li>
- <li>{{glossary('Web performance')}}</li>
-</ul>
-
-
-<h2 id="Documents_yet_to_be_written">Documents yet to be written</h2>
-
-<dl>
- <dt><a href="/fr/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt>
- <dd>JavaScript, when used properly, can allow for interactive and immersive web experiences ... or it can significantly harm download time, render time, in app performance, battery life, and user experience. This article outlines some JavaScript best practices that can ensure even complex content's performance is the highest possible.</dd>
- <dt><a href="/fr/docs/Learn/Performance/Mobile">Mobile performance</a></dt>
- <dd>With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU, and battery life, it is important to consider the performance of your web content on these platforms. This article also looks at mobile-specific performance considerations.</dd>
- <dt>Web font performance</dt>
- <dd>An often overlooked aspect of performance landscape are web fonts. Web fonts are more prominent in web design than ever, yet many developers simply embed them from a third party service and think nothing of it. In this article, we'll covers methods for getting your font files as small as possible with efficient file formats and sub setting. From there, we'll go on to talk about how browsers text, and how you can use CSS and JavaScript features to ensure your fonts render quickly, and with minimal disruption to the user experience.</dd>
- <dt>Performance bottlenecks</dt>
- <dt>Understanding bandwidth</dt>
- <dd>Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. This article explains the role of bandwidth in media-rich internet applications, how you can measure it, and how you can optimize applications to make the best use of available bandwidth.</dd>
- <dt>The role of TLS in performance</dt>
- <dd>
- <p>TLS—or HTTPS as we tend to call it—is crucial in creating secure and safe user experiences. While hardware has reduced the negative impacts TLS has had on server performance, it still represents a substantial slice of the time we spend waiting for browsers to connect to servers. This article explains the TLS handshake process, and offers some tips for reducing this time, such as OCSP stapling, HSTS preload headers, and the potential role of resource hints in masking TLS latency for third parties.</p>
- </dd>
- <dt>Reading performance charts</dt>
- <dd>Developer tools provide information on performance, memory, and network requests. Knowing how to read <a href="/fr/docs/Tools/Performance/Waterfall">waterfall</a> charts, <a href="/fr/docs/Tools/Performance/Call_Tree">call trees</a>, traces, <a href="/fr/docs/Tools/Performance/Flame_Chart">flame charts</a> , and <a href="/fr/docs/Tools/Performance/Allocations">allocations</a> in your browser developer tools will help you understand waterfall and flame charts in other performance tools.</dd>
- <dt>Alternative media formats</dt>
- <dd>When it comes to images and videos, there are more formats than you're likely aware of. Some of these formats can take your highly optimized media-rich pages even further by offering additional reductions in file size. In this guide we'll discuss some alternative media formats, how to use them responsibly so that non-supporting browsers don't get left out in the cold, and some advanced guidance on transcoding your existing assets to them.</dd>
- <dt>Analyzing JavaScript bundles</dt>
- <dd>No doubt, JavaScript is a big part of modern web development. While you should always strive to reduce the amount of JavaScript you use in your applications, it can be difficult to know where to start. In this guide, we'll show you how to analyze your application's script bundles, so you know <em>what</em> you're using, as well how to detect if your app contains duplicated scripts between bundles.</dd>
- <dt><a href="/fr/docs/Web/Performance/Lazy_loading">Lazy loading</a></dt>
- <dd>It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is deferring the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time i.e when those assets are actually needed.</dd>
- <dt>Lazy-loading JavaScript with dynamic imports</dt>
- <dd>When developers hear the term "lazy loading", they immediately think of below-the-fold imagery that loads when it scrolls into the viewport. But did you know you can lazy load JavaScript as well? In this guide we'll talk about the dynamic import() statement, which is a feature in modern browsers that loads a JavaScript module on demand. Of course, since this feature isn't available everywhere, we'll also show you how you can configure your tooling to use this feature in a widely compatible fashion.</dd>
- <dt><a href="/fr/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints">Controlling resource delivery with resource hints</a></dt>
- <dd>Browsers often know better than we do when it comes to resource prioritization and delivery however they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage.</dd>
- <dt><a href="/fr/docs/Web/Performance/Performance_budgets">Performance Budgets</a></dt>
- <dd>Marketing, design, and sales needs, and developer experience, often ad bloat, third-party scripts, and other features that can slow down web performance. To help set priorities, it is helpful to set a performance budget: a set of restrictions to not exceed during the development phase. In this article, we'll discuss creating and sticking to a performance budget. </dd>
- <dt><a href="/fr/docs/Web/Performance/Checklist">Web performance checklist</a></dt>
- <dd>A performance checklist of features to consider when developing applications with links to tutorials on how to implement each feature, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.</dd>
- <dt><a href="/fr/docs/Web/Performance/Mobile_performance_checklist">Mobile performance checklist</a></dt>
- <dd>A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.</dd>
-</dl>
-
-<h3 id="App_Performance">App Performance</h3>
-
-<dl>
- <dt><a href="/fr/Apps/Developing/Performance/Performance_fundamentals">Performance fundamentals</a></dt>
- <dd>A wide overview of Web application performance, what it is, how the browser helps to improve it, and what tools and processes you can use to test and further improve it.</dd>
- <dt><a href="/fr/Apps/Developing/Performance/Optimizing_startup_performance">Optimizing startup performance</a></dt>
- <dd>Tips and suggestions to help you improve start-up performance, both when writing a new app and when porting an app from another platform to the Web.</dd>
- <dt><a href="/fr/docs/Performance/Profiling_with_the_Built-in_Profiler">Profiling with the built-in profiler</a></dt>
- <dd>Learn how to profile app performance with Firefox's built-in profiler.</dd>
- <dt><a href="/fr/Apps/Build/Performance/CSS_JavaScript_animation_performance">CSS and JavaScript animation performance</a></dt>
- <dd>Animations are critical for a pleasurable user experience. This article discusses the performance differences between CSS- and JavaScript-based animations. </dd>
-</dl>
-
-<h2 id="See_also">See also</h2>
-
-<p>HTML</p>
-
-<ul>
- <li><a href="/fr/docs/Web/HTML/Element/picture">The <code>&lt;picture&gt;</code> Element</a></li>
- <li><a href="/fr/docs/Web/HTML/Element/video">The <code>&lt;video&gt;</code> Element</a></li>
- <li><a href="/fr/docs/Web/HTML/Element/source">The <code>&lt;source&gt;</code> Element</a></li>
- <li><a href="/fr/docs/Web/HTML/Element/img#Attributes">The <code>&lt;img&gt; srcset</code> attribute</a>
-  <ul>
-   <li><a href="/fr/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Responsive images</a></li>
-  </ul>
- </li>
- <li><a href="/fr/docs/Web/HTML/Preloading_content">Preloading content with <code>rel="preload"</code></a> - <a href="https://w3c.github.io/preload/">(https://w3c.github.io/preload/ </a>)</li>
-</ul>
-
-<p>CSS</p>
-
-<ul>
- <li><a href="/fr/docs/Web/CSS/will-change">will-change</a></li>
- <li>GPU v CPU</li>
- <li>Measuring layout</li>
- <li>Font-loading best practices</li>
-</ul>
-
-<p>JavaScript</p>
-
-<ul>
- <li><a href="/fr/docs/Web/Events/DOMContentLoaded">DOMContentLoaded</a></li>
- <li><a href="/fr/docs/Glossary/Garbage_collection">Garbage collection</a></li>
- <li><a href="/fr/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame</a></li>
-</ul>
-
-<p>APIs</p>
-
-<ul>
- <li><a href="/fr/docs/Web/API/Performance_API">Performance API</a></li>
- <li><a href="/fr/docs/Web/API/Navigation_timing_API">Navigation Timing API</a></li>
- <li><a href="/fr/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API">Media Capabilities API</a></li>
- <li><a href="/fr/docs/Web/API/Network_Information_API">Network Information API</a></li>
- <li><a href="/fr/docs/Web/API/PerformanceNavigationTiming">PerformanceNavigationTiming</a></li>
- <li><a href="/fr/docs/Web/API/Battery_Status_API">Battery Status API</a></li>
- <li><a href="/fr/docs/Web/API/Navigator/deviceMemory">Navigator.deviceMemory</a></li>
- <li><a href="/fr/docs/Web/API/Intersection_Observer_API">Intersection Observer</a></li>
- <li><a href="/fr/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">Using the User Timing AP</a>I</li>
- <li><a href="/fr/docs/Web/API/Long_Tasks_API">Long Tasks API</a></li>
- <li><a href="/fr/docs/Web/API/DOMHighResTimeStamp">High Resolution Timing API</a> (<a href="https://w3c.github.io/hr-time/">https://w3c.github.io/hr-time/)</a></li>
- <li><a href="/fr/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></li>
- <li><a href="/fr/docs/Web/API/Page_Visibility_API">Page Visibility</a></li>
- <li><p><a href="/fr/docs/Web/API/Background_Tasks_API">Cooperative Scheduling of Background Tasks API</a></p>
-  <ul>
-   <li><a href="/fr/docs/Web/API/Window/requestIdleCallback">requestIdleCallback() </a></li>
-  </ul>
- </li>
- <li><a href="/fr/docs/Web/API/Beacon_API/Using_the_Beacon_API">Beacon API</a></li>
- <li>Resource Hints - <a href="/fr/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control">dns-prefetch</a>, preconnect, <a href="/fr/docs/Web/HTTP/Link_prefetching_FAQ">prefetch</a>, and prerender</li>
- <li><a href="/fr/docs/Web/API/FetchEvent/navigationPreload">Fetchevent.navigationPreload</a></li>
- <li><a href="/fr/docs/Web/API/PerformanceServerTiming">Performance Server Timing API</a></li>
-</ul>
-
-<p>Headers</p>
-
-<ul>
- <li><a href="/fr/docs/Web/HTTP/Headers/Content-Encoding">Content-encoding</a></li>
- <li>HTTP/2</li>
- <li><a href="/fr/docs/Glossary/GZip_compression">gZip</a></li>
- <li>Client Hints</li>
-</ul>
-
-<p>Tools</p>
-
-<ul>
- <li><a href="/fr/docs/Tools/Performance">Performance in Firefox Developer Tools</a></li>
- <li>Flame charts</li>
- <li>The Network panel</li>
- <li>Waterfall charts</li>
-</ul>
-
-<p>Additional Metrics</p>
-
-<ul>
- <li>Speed Index and Perceptual Speed Index</li>
-</ul>
-
-<p>Best Practices</p>
-
-<ul>
- <li><a href="/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers">Using Service Workers</a></li>
- <li><a href="/fr/docs/Web/API/Web_Workers_API/Using_web_workers">Using Web Workers</a>
-  <ul>
-   <li><a href="/fr/docs/Web/API/Web_Workers_API">Web Workers API</a></li>
-  </ul>
- </li>
- <li><a href="/fr/docs/Web/Apps/Progressive/Offline_Service_workers">PWA</a></li>
- <li><a href="/fr/docs/Web/HTTP/Caching">Caching</a></li>
- <li>Content Delivery Networks (CDN)</li>
-</ul>
+Translation in progress
+
+Web performance is the objective measurements and the perceived user experience of load time and runtime. Web performance is how long a site takes to load, become interactive and responsive, and how smooth the content is during user interactions - is the scrolling smooth? are buttons clickable? Are pop-ups quick to load and display, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to become interactive, and subjective experiences of how long it felt like it took the content to load.
+
+The longer it takes for a site to respond, the more users will abandon the site. It is important to minimize the loading and response times and add additional features to conceal latency by making the experience as available and interactive as possible, as soon as possible, while asynchronously loading in the longer tail parts of the experience.
+
+There are tools, APIs, and best practices that help us measure and improve web performance. We cover them in this section:
+
+## In this section
+
+{{LandingPageListSubpages}}
+
+## Selected tutorials
+
+The MDN [Web Performance Learning Area](/fr/docs/Learn/Performance) contains modern, up-to-date tutorials covering Performance essentials:
+
+- [What is web performance](/fr/docs/Learn/Performance/What_is_web_performance)
+  - : This article starts the module off with a good look at what Performance actually is — this includes the tools, metrics, APIs, networks, and groups of people we need to consider when thinking about performance, and how we can make Performance part of our web development workflow.
+- [Web Performance Basics](/fr/docs/Learn/Performance/web_performance_basics)
+  - : In addition to the front-end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, Developer Tools, best practices and bad practices relating to web performance. Here we'll introduce many of these features at the basic level and provide links to deeper dives to improve performance for each topic.
+- [How do users perceive performance?](/fr/docs/Learn/Performance/perceived_performance)
+  - : More important than how fast your website is in milliseconds, is how fast do your users perceive your site to be. Page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations impact these perceptions. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings themselves.
+- [Multimedia: Images and Video](/fr/docs/Learn/Performance/Multimedia)
+  - : Frequently, media optimization is the lowest hanging fruit of web performance. Serving different media files based on each user agent's capability, size and pixel density is possible. Additional tips, like removing audio tracks from background images, can improve performance even further. In this article, we discuss the impact video, audio, and image content has on performance, and the methods to ensure that impact is as minimal as possible.
+- [CSS performance features](/fr/docs/Learn/Performance/CSS_performance)
+  - : CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article, we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted.
+
+## Using Performance APIs
+
+- [Performance API](/fr/docs/Web/API/Performance_API/Using_the_Performance_API)
+  - : This guide describes how to use the [`Performance`](/fr/docs/Web/API/Performance "The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API.") interfaces that are defined in the [High-Resolution Time](https://w3c.github.io/hr-time/) standard.
+- [Resource Timing API](/fr/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API)
+  - : [Resource loading and timing](/fr/docs/Web/API/Resource_Timing_API) the loading of those resources, including managing the resource buffer and coping with CORS
+- [The performance timeline](/fr/docs/Web/API/Performance_Timeline/Using_Performance_Timeline)
+  - : The [Performance Timeline](/fr/docs/Web/API/Performance_Timeline) standard defines extensions to the [`Performance`](/fr/docs/Web/API/Performance "The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API.") interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks.
+- [User Timing API](/fr/docs/Web/API/User_Timing_API/Using_the_User_Timing_API)
+  - : Create application specific timestamps using the [user timing API](/fr/docs/Web/API/User_Timing_API)'s "mark" and "measure" entry types - that are part of the browser's performance timeline.
+- [Frame Timing API](/fr/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API)
+  - : The [`PerformanceFrameTiming`](/fr/docs/Web/API/PerformanceFrameTiming) interface provides _frame_ timing data about the browser's event loop.
+- [Beacon API](/fr/docs/Web/API/Beacon_API/Using_the_Beacon_API)
+  - : The [Beacon](/fr/docs/Web/API/Beacon_API) interface schedules an asynchronous and non-blocking request to a web server.
+- [Intersection Observer API](/fr/docs/Web/API/Intersection_Observer_API/Timing_element_visibility)
+  - : Learn to time element visibility with the [Intersection Observer API](/fr/docs/Web/API/Intersection_Observer_API) and be asynchronously notified when elements of interest becomes visible.
+
+## Other documentation
+
+- [Developer Tools Performance Features](/fr/docs/Tools/Performance)
+  - : This section provides information on how to use and understand the performance features in your developer tools, including [Waterfall](/fr/docs/Tools/Performance/Waterfall), [Call Tree](/fr/docs/Tools/Performance/Call_Tree), and [Flame Charts](/fr/docs/Tools/Performance/Flame_Chart).
+- [Understanding Latency](/fr/docs/Learn/Performance/Understanding_latency)
+  - : Latency is the amount of time it takes between the browser making a request for a resource, and the browser receiving back the first byte of the resource requested. This article explains what latency is, how it impacts performance, how to measure latency, and how to reduce it.
+
+## Glossary Terms
+
+- {{glossary('Beacon')}}
+- {{glossary('Brotli compression')}}
+- {{glossary('Client hints')}}
+- {{glossary('Code splitting')}}
+- {{glossary('CSSOM')}}
+- {{glossary('Domain sharding')}}
+- {{glossary('Effective connection type')}}
+- {{glossary('First contentful paint')}}
+- {{glossary('First CPU idle')}}
+- {{glossary('First input delay')}}
+- {{glossary('First interactive')}}
+- {{glossary('First meaningful paint')}}
+- {{glossary('First paint')}}
+- {{glossary('HTTP')}}
+- {{glossary('HTTP_2', 'HTTP/2')}}
+- {{glossary('Jank')}}
+- {{glossary('Latency')}}
+- {{glossary('Lazy load')}}
+- {{glossary('Long task')}}
+- {{glossary('Lossless compression')}}
+- {{glossary('Lossy compression')}}
+- {{glossary('Main thread')}}
+- {{glossary('Minification')}}
+- {{glossary('Network throttling')}}
+- {{glossary('Packet')}}
+- {{glossary('Page load time')}}
+- {{glossary('Page prediction')}}
+- {{glossary('Parse')}}
+- {{glossary('Perceived performance')}}
+- {{glossary('Prefetch')}}
+- {{glossary('Prerender')}}
+- {{glossary('QUIC')}}
+- {{glossary('RAIL')}}
+- {{glossary('Real User Monitoring')}}
+- {{glossary('Resource Timing')}}
+- {{glossary('Round Trip Time (RTT)')}}
+- {{glossary('Server Timing')}}
+- {{glossary('Speculative parsing')}}
+- {{glossary('Speed index')}}
+- {{glossary('SSL')}}
+- {{glossary('Synthetic monitoring')}}
+- {{glossary('TCP handshake')}}
+- {{glossary('TCP slow start')}}
+- {{glossary('Time to first byte')}}
+- {{glossary('Time to interactive')}}
+- {{glossary('TLS')}}
+- {{glossary('TCP', 'Transmission Control Protocol (TCP)')}}
+- {{glossary('Tree shaking')}}
+- {{glossary('Web performance')}}
+
+## Documents yet to be written
+
+- [JavaScript performance best practices](/fr/docs/Learn/Performance/JavaScript)
+  - : JavaScript, when used properly, can allow for interactive and immersive web experiences ... or it can significantly harm download time, render time, in app performance, battery life, and user experience. This article outlines some JavaScript best practices that can ensure even complex content's performance is the highest possible.
+- [Mobile performance](/fr/docs/Learn/Performance/Mobile)
+  - : With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU, and battery life, it is important to consider the performance of your web content on these platforms. This article also looks at mobile-specific performance considerations.
+- Web font performance
+  - : An often overlooked aspect of performance landscape are web fonts. Web fonts are more prominent in web design than ever, yet many developers simply embed them from a third party service and think nothing of it. In this article, we'll covers methods for getting your font files as small as possible with efficient file formats and sub setting. From there, we'll go on to talk about how browsers text, and how you can use CSS and JavaScript features to ensure your fonts render quickly, and with minimal disruption to the user experience.
+- Performance bottlenecks
+
+  Understanding bandwidth
+
+  - : Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. This article explains the role of bandwidth in media-rich internet applications, how you can measure it, and how you can optimize applications to make the best use of available bandwidth.
+
+- The role of TLS in performance
+  - : TLS—or HTTPS as we tend to call it—is crucial in creating secure and safe user experiences. While hardware has reduced the negative impacts TLS has had on server performance, it still represents a substantial slice of the time we spend waiting for browsers to connect to servers. This article explains the TLS handshake process, and offers some tips for reducing this time, such as OCSP stapling, HSTS preload headers, and the potential role of resource hints in masking TLS latency for third parties.
+- Reading performance charts
+  - : Developer tools provide information on performance, memory, and network requests. Knowing how to read [waterfall](/fr/docs/Tools/Performance/Waterfall) charts, [call trees](/fr/docs/Tools/Performance/Call_Tree), traces, [flame charts](/fr/docs/Tools/Performance/Flame_Chart) , and [allocations](/fr/docs/Tools/Performance/Allocations) in your browser developer tools will help you understand waterfall and flame charts in other performance tools.
+- Alternative media formats
+  - : When it comes to images and videos, there are more formats than you're likely aware of. Some of these formats can take your highly optimized media-rich pages even further by offering additional reductions in file size. In this guide we'll discuss some alternative media formats, how to use them responsibly so that non-supporting browsers don't get left out in the cold, and some advanced guidance on transcoding your existing assets to them.
+- Analyzing JavaScript bundles
+  - : No doubt, JavaScript is a big part of modern web development. While you should always strive to reduce the amount of JavaScript you use in your applications, it can be difficult to know where to start. In this guide, we'll show you how to analyze your application's script bundles, so you know _what_ you're using, as well how to detect if your app contains duplicated scripts between bundles.
+- [Lazy loading](/fr/docs/Web/Performance/Lazy_loading)
+  - : It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is deferring the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time i.e when those assets are actually needed.
+- Lazy-loading JavaScript with dynamic imports
+  - : When developers hear the term "lazy loading", they immediately think of below-the-fold imagery that loads when it scrolls into the viewport. But did you know you can lazy load JavaScript as well? In this guide we'll talk about the dynamic import() statement, which is a feature in modern browsers that loads a JavaScript module on demand. Of course, since this feature isn't available everywhere, we'll also show you how you can configure your tooling to use this feature in a widely compatible fashion.
+- [Controlling resource delivery with resource hints](/fr/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints)
+  - : Browsers often know better than we do when it comes to resource prioritization and delivery however they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage.
+- [Performance Budgets](/fr/docs/Web/Performance/Performance_budgets)
+  - : Marketing, design, and sales needs, and developer experience, often ad bloat, third-party scripts, and other features that can slow down web performance. To help set priorities, it is helpful to set a performance budget: a set of restrictions to not exceed during the development phase. In this article, we'll discuss creating and sticking to a performance budget.
+- [Web performance checklist](/fr/docs/Web/Performance/Checklist)
+  - : A performance checklist of features to consider when developing applications with links to tutorials on how to implement each feature, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.
+- [Mobile performance checklist](/fr/docs/Web/Performance/Mobile_performance_checklist)
+  - : A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.
+
+### App Performance
+
+- [Performance fundamentals](/fr/Apps/Developing/Performance/Performance_fundamentals)
+  - : A wide overview of Web application performance, what it is, how the browser helps to improve it, and what tools and processes you can use to test and further improve it.
+- [Optimizing startup performance](/fr/Apps/Developing/Performance/Optimizing_startup_performance)
+  - : Tips and suggestions to help you improve start-up performance, both when writing a new app and when porting an app from another platform to the Web.
+- [Profiling with the built-in profiler](/fr/docs/Performance/Profiling_with_the_Built-in_Profiler)
+  - : Learn how to profile app performance with Firefox's built-in profiler.
+- [CSS and JavaScript animation performance](/fr/Apps/Build/Performance/CSS_JavaScript_animation_performance)
+  - : Animations are critical for a pleasurable user experience. This article discusses the performance differences between CSS- and JavaScript-based animations.
+
+## See also
+
+HTML
+
+- [The `<picture>` Element](/fr/docs/Web/HTML/Element/picture)
+- [The `<video>` Element](/fr/docs/Web/HTML/Element/video)
+- [The `<source>` Element](/fr/docs/Web/HTML/Element/source)
+- [The `<img> srcset` attribute](/fr/docs/Web/HTML/Element/img#Attributes)
+
+  - [Responsive images](/fr/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images)
+
+- [Preloading content with `rel="preload"`](/fr/docs/Web/HTML/Preloading_content) - [(https://w3c.github.io/preload/ ](https://w3c.github.io/preload/))
+
+CSS
+
+- [will-change](/fr/docs/Web/CSS/will-change)
+- GPU v CPU
+- Measuring layout
+- Font-loading best practices
+
+JavaScript
+
+- [DOMContentLoaded](/fr/docs/Web/Events/DOMContentLoaded)
+- [Garbage collection](/fr/docs/Glossary/Garbage_collection)
+- [requestAnimationFrame](/fr/docs/Web/API/window/requestAnimationFrame)
+
+APIs
+
+- [Performance API](/fr/docs/Web/API/Performance_API)
+- [Navigation Timing API](/fr/docs/Web/API/Navigation_timing_API)
+- [Media Capabilities API](/fr/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API)
+- [Network Information API](/fr/docs/Web/API/Network_Information_API)
+- [PerformanceNavigationTiming](/fr/docs/Web/API/PerformanceNavigationTiming)
+- [Battery Status API](/fr/docs/Web/API/Battery_Status_API)
+- [Navigator.deviceMemory](/fr/docs/Web/API/Navigator/deviceMemory)
+- [Intersection Observer](/fr/docs/Web/API/Intersection_Observer_API)
+- [Using the User Timing AP](/fr/docs/Web/API/User_Timing_API/Using_the_User_Timing_API)I
+- [Long Tasks API](/fr/docs/Web/API/Long_Tasks_API)
+- [High Resolution Timing API](/fr/docs/Web/API/DOMHighResTimeStamp) ([https://w3c.github.io/hr-time/)](https://w3c.github.io/hr-time/)
+- [Resource Timing API](/fr/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API)
+- [Page Visibility](/fr/docs/Web/API/Page_Visibility_API)
+- [Cooperative Scheduling of Background Tasks API](/fr/docs/Web/API/Background_Tasks_API)
+
+  - [requestIdleCallback()](/fr/docs/Web/API/Window/requestIdleCallback)
+
+- [Beacon API](/fr/docs/Web/API/Beacon_API/Using_the_Beacon_API)
+- Resource Hints - [dns-prefetch](/fr/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control), preconnect, [prefetch](/fr/docs/Web/HTTP/Link_prefetching_FAQ), and prerender
+- [Fetchevent.navigationPreload](/fr/docs/Web/API/FetchEvent/navigationPreload)
+- [Performance Server Timing API](/fr/docs/Web/API/PerformanceServerTiming)
+
+Headers
+
+- [Content-encoding](/fr/docs/Web/HTTP/Headers/Content-Encoding)
+- HTTP/2
+- [gZip](/fr/docs/Glossary/GZip_compression)
+- Client Hints
+
+Tools
+
+- [Performance in Firefox Developer Tools](/fr/docs/Tools/Performance)
+- Flame charts
+- The Network panel
+- Waterfall charts
+
+Additional Metrics
+
+- Speed Index and Perceptual Speed Index
+
+Best Practices
+
+- [Using Service Workers](/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers)
+- [Using Web Workers](/fr/docs/Web/API/Web_Workers_API/Using_web_workers)
+
+  - [Web Workers API](/fr/docs/Web/API/Web_Workers_API)
+
+- [PWA](/fr/docs/Web/Apps/Progressive/Offline_Service_workers)
+- [Caching](/fr/docs/Web/HTTP/Caching)
+- Content Delivery Networks (CDN)
diff --git a/files/fr/web/performance/lazy_loading/index.md b/files/fr/web/performance/lazy_loading/index.md
index 2512a94b13..4e659bda89 100644
--- a/files/fr/web/performance/lazy_loading/index.md
+++ b/files/fr/web/performance/lazy_loading/index.md
@@ -3,109 +3,98 @@ title: Le chargement différé
 slug: Web/Performance/Lazy_loading
 translation_of: Web/Performance/Lazy_loading
 ---
-<p>Le <strong>chargement différé</strong> (<i lang="en">lazy loading</i> en anglais) est une stratégie d'identification des ressources non bloquantes (non critiques) afin de ne les charger qu'au moment où elles sont utiles. C'est une façon de raccourcir le <a href="/fr/docs/Web/Performance/Critical_rendering_path">chemin critique de rendu</a>, ce qui se traduit par une réduction du temps de chargement de la page.</p>
+Le **chargement différé** (<i lang="en">lazy loading</i> en anglais) est une stratégie d'identification des ressources non bloquantes (non critiques) afin de ne les charger qu'au moment où elles sont utiles. C'est une façon de raccourcir le [chemin critique de rendu](/fr/docs/Web/Performance/Critical_rendering_path), ce qui se traduit par une réduction du temps de chargement de la page.
 
-<p>Le chargement différé peut se dérouler à plusieurs moments du chargement d'une application, mais il se déroule typiquement lorsque l'internaute interagit avec la page, notamment lors du défilement de la page ou de la navigation.</p>
+Le chargement différé peut se dérouler à plusieurs moments du chargement d'une application, mais il se déroule typiquement lorsque l'internaute interagit avec la page, notamment lors du défilement de la page ou de la navigation.
 
-<h2 id="general_overview">Vue d'ensemble</h2>
+## Vue d'ensemble
 
-<p>Au fur et à mesure de l'évolution du web, nous avons vu une grande augmentation du nombre et de la taille des ressources servie aux internautes. Entre 2011 et 2019, le poids médian des ressources est passé de <strong>~10 Ko</strong> à <strong>~40 Ko</strong> sur ordinateur et de <strong>~5 Ko</strong> à <strong>~35 Ko</strong> sur mobile. Tandis que la taille médiane des images est passée de <strong>~25 Ko</strong> à <strong>~90 Ko</strong> sur ordinateur et de <strong>~10 Ko</strong> à <strong>~85 Ko</strong> sur mobile.</p>
+Au fur et à mesure de l'évolution du web, nous avons vu une grande augmentation du nombre et de la taille des ressources servie aux internautes. Entre 2011 et 2019, le poids médian des ressources est passé de **\~10 Ko** à **\~40 Ko** sur ordinateur et de **\~5 Ko** à **\~35 Ko** sur mobile. Tandis que la taille médiane des images est passée de **\~25 Ko** à **\~90 Ko** sur ordinateur et de **\~10 Ko** à **\~85 Ko** sur mobile.
 
-<p>L'une des méthodes utilisables pour s'occuper de ce problème consiste à réduire la longueur du <a href="/fr/docs/Web/Performance/Critical_rendering_path">chemin critique de rendu</a> en chargeant les ressources de façon différée lors du premier rendu de la page. Exemple concret : lorsque vous arrivez sur la page d'accueil d'une boutique en ligne disposant d'un lien vers la section « panier », il est plus optimal de ne charger ses ressources que lorsque vous naviguerez vers cette section.</p>
+L'une des méthodes utilisables pour s'occuper de ce problème consiste à réduire la longueur du [chemin critique de rendu](/fr/docs/Web/Performance/Critical_rendering_path) en chargeant les ressources de façon différée lors du premier rendu de la page. Exemple concret : lorsque vous arrivez sur la page d'accueil d'une boutique en ligne disposant d'un lien vers la section « panier », il est plus optimal de ne charger ses ressources que lorsque vous naviguerez vers cette section.
 
-<h2 id="strategies">Stratégies</h2>
+## Stratégies
 
-<p>Le chargement différé peut être appliqué sur de multiples ressources et avec de multiples stratégies.</p>
+Le chargement différé peut être appliqué sur de multiples ressources et avec de multiples stratégies.
 
-<h3 id="general">En général</h3>
+### En général
 
-<h4 id="code_splitting">Division du code</h4>
+#### Division du code
 
-<p>Le code JavaScript, CSS et HTML peuvent être divisés en petits morceaux. Cela permet de n'envoyer que la portion de code nécessaire à l'affichage sur l'écran de l'internaute, et donc d'améliorer les temps de chargement. Le reste sera chargé sur demande. Deux systèmes sont possibles&nbsp;:</p>
+Le code JavaScript, CSS et HTML peuvent être divisés en petits morceaux. Cela permet de n'envoyer que la portion de code nécessaire à l'affichage sur l'écran de l'internaute, et donc d'améliorer les temps de chargement. Le reste sera chargé sur demande. Deux systèmes sont possibles :
 
-<ul>
-  <li>division par points d'entrée&nbsp;: séparation du code en différents points d'entrée au sein de l'application&nbsp;;</li>
-  <li>division dynamique&nbsp;: séparation du code où des déclarations <a href="/fr/docs/Web/JavaScript/Reference/Statements/import"><code>import()</code></a> dynamiques sont utilisées.</li>
-</ul>
+- division par points d'entrée : séparation du code en différents points d'entrée au sein de l'application ;
+- division dynamique : séparation du code où des déclarations [`import()`](/fr/docs/Web/JavaScript/Reference/Statements/import) dynamiques sont utilisées.
 
-<h3 id="javascript">JavaScript</h3>
+### JavaScript
 
-<h4 id="script_de_type_module">Script de type module</h4>
+#### Script de type module
 
-<p>Toute balise <code>&lt;script&gt;</code> utilisant <code>type="module"</code> sera traitée comme un <a href="/fr/docs/Web/JavaScript/Guide/Modules">module JavaScript</a> et son chargement sera différé par défaut.</p>
+Toute balise `<script>` utilisant `type="module"` sera traitée comme un [module JavaScript](/fr/docs/Web/JavaScript/Guide/Modules) et son chargement sera différé par défaut.
 
-<h3 id="css">CSS</h3>
+### CSS
 
-<p>Par défaut, les fichiers CSS sont traités comme des ressources <a href="/fr/docs/Web/Performance/Critical_rendering_path">bloquant le rendu</a>, donc le navigateur n'affichera aucun contenu traité tant que le <a href="/fr/docs/Web/API/CSS_Object_Model">CSSOM (pour <i lang="en">CSS Object Model</i>)</a> est construit. Les fichiers CSS doivent être légers, délivrés aussi rapidement que possible, et l'utilisation des types de médias et des requêtes média est conseillé pour ne pas bloquer le rendu&nbsp;:</p>
+Par défaut, les fichiers CSS sont traités comme des ressources [bloquant le rendu](/fr/docs/Web/Performance/Critical_rendering_path), donc le navigateur n'affichera aucun contenu traité tant que le [CSSOM (pour <i lang="en">CSS Object Model</i>)](/fr/docs/Web/API/CSS_Object_Model) est construit. Les fichiers CSS doivent être légers, délivrés aussi rapidement que possible, et l'utilisation des types de médias et des requêtes média est conseillé pour ne pas bloquer le rendu :
 
-<pre class="brush: html">&lt;link href="style.css"    rel="stylesheet" media="all"&gt;
-&lt;link href="portrait.css" rel="stylesheet" media="orientation:portrait"&gt;
-&lt;link href="print.css"    rel="stylesheet" media="print"&gt;
-</pre>
+```html
+<link href="style.css"    rel="stylesheet" media="all">
+<link href="portrait.css" rel="stylesheet" media="orientation:portrait">
+<link href="print.css"    rel="stylesheet" media="print">
+```
 
-<p>Pour cela, il est possible de réaliser certaines <a href="/fr/docs/Learn/Performance/CSS">optimisations CSS</a>.</p>
+Pour cela, il est possible de réaliser certaines [optimisations CSS](/fr/docs/Learn/Performance/CSS).
 
-<h3 id="fonts">Polices</h3>
+### Polices
 
-<p>Par défaut, les requêtes d'affichage des polices sont différées jusqu'à ce que l'arbre de rendu soit construit, ce qui peut conduire à un délai d'affichage du texte.</p>
+Par défaut, les requêtes d'affichage des polices sont différées jusqu'à ce que l'arbre de rendu soit construit, ce qui peut conduire à un délai d'affichage du texte.
 
-<p>Il est possible de surcharger le comportement par défaut et de précharger les polices web en utilisant <code>&lt;link rel="preload"&gt;</code>, la <a href="/fr/docs/Web/CSS/@font-face/font-display">propriété CSS <code>font-display</code></a> et the <a href="/fr/docs/Web/API/CSS_Font_Loading_API">l'API de chargement des polices</a>.<br><br>Voir aussi <a href="/fr/docs/Web/HTML/Element/link">la documentation de l'élément <code>Link</code></a></p>
+Il est possible de surcharger le comportement par défaut et de précharger les polices web en utilisant `<link rel="preload">`, la [propriété CSS `font-display`](/fr/docs/Web/CSS/@font-face/font-display) et the [l'API de chargement des polices](/fr/docs/Web/API/CSS_Font_Loading_API).
 
-<h3 id="images_and_iframes">Images et iframes</h3>
+Voir aussi [la documentation de l'élément `Link`](/fr/docs/Web/HTML/Element/link)
 
-<p>Très souvent, les pages web contiennent beaucoup d'images et cela contribue à la quantité de données chargées et donc à la vitesse de chargement de la page. La plupart de ces images sont généralement en dehors de l'écran (ces ressources sont alors considérées comme étant <a href="/fr/docs/Web/Performance/Critical_rendering_path">non critiques</a>), car elles nécessitent une interaction de l'internaute (par exemple le faire de défiler dans la page) avant de les voir.</p>
+### Images et iframes
 
-<h4 id="attribut_loading">Attribut loading</h4>
+Très souvent, les pages web contiennent beaucoup d'images et cela contribue à la quantité de données chargées et donc à la vitesse de chargement de la page. La plupart de ces images sont généralement en dehors de l'écran (ces ressources sont alors considérées comme étant [non critiques](/fr/docs/Web/Performance/Critical_rendering_path)), car elles nécessitent une interaction de l'internaute (par exemple le faire de défiler dans la page) avant de les voir.
 
-<p>L'attribut <a href="/fr/docs/Web/HTML/Element/Img#attr-loading"><code>loading</code></a> utilisé sur un élément <a href="/fr/docs/Web/HTML/Element/Img"><code>&lt;img&gt;</code></a> (ou sur un élément <a href="/fr/docs/Web/HTML/Element/iframe"><code>&lt;iframe&gt;</code></a>) peut être utilisé pour demander au navigateur de différer le chargement des images et des iframes qui se situent en dehors de la zone affichée à l'écran, jusqu'à ce que la personne visitant le site ne les affiche en faisant défiler la page.</p>
+#### Attribut loading
 
-<pre class="brush: html">&lt;img src="image.jpg" alt="..." loading="lazy"&gt;
-&lt;iframe src="video-player.html" title="..." loading="lazy"&gt;&lt;/iframe&gt;</pre>
+L'attribut [`loading`](/fr/docs/Web/HTML/Element/Img#attr-loading) utilisé sur un élément [`<img>`](/fr/docs/Web/HTML/Element/Img) (ou sur un élément [`<iframe>`](/fr/docs/Web/HTML/Element/iframe)) peut être utilisé pour demander au navigateur de différer le chargement des images et des iframes qui se situent en dehors de la zone affichée à l'écran, jusqu'à ce que la personne visitant le site ne les affiche en faisant défiler la page.
 
-<p>L'événement <code>load</code> se déclenche lorsque que le contenu le plus rapide a entièrement été chargé. À ce moment-là, il est complètement possible (et même probable) que des images utilisant le chargement différé, situées dans la <a href="/fr/docs/Glossary/Visual_Viewport">zone visible de l'écran</a> n'aient pas encore été chargées.</p>
+```html
+<img src="image.jpg" alt="..." loading="lazy">
+<iframe src="video-player.html" title="..." loading="lazy"></iframe>
+```
 
-<p>Vous pouvez déterminer si une image donnée a terminé son chargement en examinant la valeur de la valeur booléenne de sa propriété <a href="/fr/docs/Web/API/HTMLImageElement/complete"><code>complete</code></a>.</p>
+L'événement `load` se déclenche lorsque que le contenu le plus rapide a entièrement été chargé. À ce moment-là, il est complètement possible (et même probable) que des images utilisant le chargement différé, situées dans la [zone visible de l'écran](/fr/docs/Glossary/Visual_Viewport) n'aient pas encore été chargées.
 
-<h4 id="polyfill">Polyfill</h4>
+Vous pouvez déterminer si une image donnée a terminé son chargement en examinant la valeur de la valeur booléenne de sa propriété [`complete`](/fr/docs/Web/API/HTMLImageElement/complete).
 
-<p>Pour ajouter la prise en charge de l'attribut <code>loading</code> sur les vieux navigateurs qui ne sont pas compatibles, vous pouvez utiliser le polyfill suivant&nbsp;: <a href="https://github.com/mfranzke/loading-attribute-polyfill">loading-attribute-polyfill</a></p>
+#### Polyfill
 
-<h4 id="api_intersection_observer">API Intersection Observer</h4>
+Pour ajouter la prise en charge de l'attribut `loading` sur les vieux navigateurs qui ne sont pas compatibles, vous pouvez utiliser le polyfill suivant : [loading-attribute-polyfill](https://github.com/mfranzke/loading-attribute-polyfill)
 
-<p><a href="/fr/docs/Web/API/IntersectionObserver">L'API Intersection Observers</a> permet à l'internaute de savoir si un élément suivi est entré ou est déjà dans la zone d'affichage.</p>
+#### API Intersection Observer
 
-<h4 id="gestionnaire_d_évènements">Gestionnaires d'évènements</h4>
+[L'API Intersection Observers](/fr/docs/Web/API/IntersectionObserver) permet à l'internaute de savoir si un élément suivi est entré ou est déjà dans la zone d'affichage.
 
-<p>Lorsque la compatibilité navigateur est cruciale, vous pouvez utiliser ces quelques options&nbsp;:</p>
+#### Gestionnaires d'évènements
 
-<ul>
-  <li><a href="https://github.com/w3c/IntersectionObserver">polyfill pour l'API <i lang="en">Intersection observer</i></a></li>
-  <li>Utilisés en tant que solution de contournement pour le défilement, les gestionnaires de redimensionnement ou de changement d'orientation peuvent déterminer si un élément spécifique se trouve dans la zone d'affichage ou non.</li>
-</ul>
+Lorsque la compatibilité navigateur est cruciale, vous pouvez utiliser ces quelques options :
 
-<h2 id="specifications">Spécifications</h2>
+- [polyfill pour l'API <i lang="en">Intersection observer</i>](https://github.com/w3c/IntersectionObserver)
 
-<table class="standard-table">
-  <thead>
-    <tr>
-      <th><strong>Spécification</strong></th>
-      <th><strong>Statut</strong></th>
-      <th><strong>Commentaires</strong></th>
-    </tr>
-  </thead>
-  <tbody>
-    <tr>
-      <td>{{SpecName('HTML WHATWG', "#lazy-loading-attributes")}}</td>
-      <td>{{Spec2('HTML WHATWG')}}</td>
-      <td></td>
-    </tr>
-  </tbody>
-</table>
+  <i lang="en">Intersection observer</i>
 
-<h2 id="see_also">Voir aussi</h2>
+- Utilisés en tant que solution de contournement pour le défilement, les gestionnaires de redimensionnement ou de changement d'orientation peuvent déterminer si un élément spécifique se trouve dans la zone d'affichage ou non.
 
-<ul>
-  <li><a href="https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css">CSS bloquant le rendu (en anglais)</a></li>
-  <li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#optimizing_loading_and_rendering">Optimiser le chargement et le rendu (en anglais)</a></li>
-  <li><a href="https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video">Chargement différé des images et des vidéos (en anglais)</a></li>
-</ul>
+## Spécifications
+
+| **Spécification**                                                        | **Statut**                       | **Commentaires** |
+| ------------------------------------------------------------------------ | -------------------------------- | ---------------- |
+| {{SpecName('HTML WHATWG', "#lazy-loading-attributes")}} | {{Spec2('HTML WHATWG')}} |                  |
+
+## Voir aussi
+
+- [CSS bloquant le rendu (en anglais)](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css)
+- [Optimiser le chargement et le rendu (en anglais)](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#optimizing_loading_and_rendering)
+- [Chargement différé des images et des vidéos (en anglais)](https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video)
diff --git a/files/fr/web/performance/performance_budgets/index.md b/files/fr/web/performance/performance_budgets/index.md
index 273c5a19a4..4626639e8c 100644
--- a/files/fr/web/performance/performance_budgets/index.md
+++ b/files/fr/web/performance/performance_budgets/index.md
@@ -9,74 +9,66 @@ tags:
 translation_of: Web/Performance/Performance_budgets
 original_slug: Web/Performance/Budgets_de_performance
 ---
-<p>{{draft}}</p>
+{{draft}}
 
-<p>Un budget de performance est une limite pour éviter les régressions. Il peut s'appliquer à un fichier, un type de fichier, tous les fichiers chargés sur une page, une métrique spécifique (par exemple, <a href="/fr/docs/Glossaire/Time_to_interactive">Time to Interactive</a>), une métrique personnalisée (par exemple, Time to Hero Element), ou un seuil sur une période de temps.</p>
+Un budget de performance est une limite pour éviter les régressions. Il peut s'appliquer à un fichier, un type de fichier, tous les fichiers chargés sur une page, une métrique spécifique (par exemple, [Time to Interactive](/fr/docs/Glossaire/Time_to_interactive)), une métrique personnalisée (par exemple, Time to Hero Element), ou un seuil sur une période de temps.
 
-<h2 id="Pourquoi_ai-je_besoin_dun_budget_de_performance">Pourquoi ai-je besoin d'un budget de performance?</h2>
+## Pourquoi ai-je besoin d'un budget de performance?
 
-<p>Un budget existe pour refléter vos objectifs atteignables. C'est un compromis entre l'expérience utilisateur et d'autres indicateurs de performance (par exemple, le taux de conversion).<br>
- <br>
- Ces objectifs peuvent être:</p>
+Un budget existe pour refléter vos objectifs atteignables. C'est un compromis entre l'expérience utilisateur et d'autres indicateurs de performance (par exemple, le taux de conversion).
 
-<ul>
- <li>Basé sur le timing (par exemple, <a href="/fr/docs/Glossaire/Time_to_interactive">Time to Interactive</a>, <a href="/fr/docs/Glossaire/First_contentful_paint">First Contentful Paint</a>).</li>
- <li>Basé sur la quantité (par exemple, quantité de fichiers JS / taille totale de l'image).</li>
- <li>Basé sur des règles (par exemple, Pagespeed index, Lighthouse score).</li>
-</ul>
+Ces objectifs peuvent être:
 
-<p>Leur objectif principal est d'éviter les régressions, mais ils peuvent fournir des informations sur les tendances prévisionnelles (c'est-à-dire qu'en septembre, 50% du budget a été dépensé en une semaine).</p>
+- Basé sur le timing (par exemple, [Time to Interactive](/fr/docs/Glossaire/Time_to_interactive), [First Contentful Paint](/fr/docs/Glossaire/First_contentful_paint)).
+- Basé sur la quantité (par exemple, quantité de fichiers JS / taille totale de l'image).
+- Basé sur des règles (par exemple, Pagespeed index, Lighthouse score).
 
-<p>De plus, il peut découvrir les besoins de développement (c'est-à-dire qu'une grande bibliothèque avec des alternatives plus petites est souvant choisie pour résoudre un problème courant).</p>
+Leur objectif principal est d'éviter les régressions, mais ils peuvent fournir des informations sur les tendances prévisionnelles (c'est-à-dire qu'en septembre, 50% du budget a été dépensé en une semaine).
 
-<h2 id="Comment_définir_un_budget_de_performance">Comment définir un budget de performance ?</h2>
+De plus, il peut découvrir les besoins de développement (c'est-à-dire qu'une grande bibliothèque avec des alternatives plus petites est souvant choisie pour résoudre un problème courant).
 
-<p>Un budget doit comprendre 2 niveaux:</p>
+## Comment définir un budget de performance ?
 
-<ul>
- <li>Attention.</li>
- <li>Erreur.</li>
-</ul>
+Un budget doit comprendre 2 niveaux:
 
-<p>Le niveau d'avertissement vous permet d'être proactif et de planifier toute dette technologique, sans bloquer le développement ou les déploiements.</p>
+- Attention.
+- Erreur.
 
-<p>Le niveau d'erreur est une limite supérieure, où les changements auront un impact négatif et notable.</p>
+Le niveau d'avertissement vous permet d'être proactif et de planifier toute dette technologique, sans bloquer le développement ou les déploiements.
 
-<p>Pour commencer, vous devez d'abord mesurer les appareils et les vitesses de connexion d'où viennent vos utilisateurs (par exemple, un appareil Android à ~200$ via une connexion 3G), à l'aide de plusieurs <a href="/fr/docs/Learn/Performance/Web_Performance_Basics">outils</a>. Ces mesures basées sur le temps se traduiront par des budgets de taille de fichier.</p>
+Le niveau d'erreur est une limite supérieure, où les changements auront un impact négatif et notable.
 
-<p>Une base de référence par défaut pour réduire le taux de rebond est d'atteindre un <a href="https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/">Time to Interactive inférieur à 5 secondes en 3G/4G, et inférieur à 2 secondes pour les charges suivantes</a>. Cependant, en fonction des objectifs et du contenu spécifiques de votre site, vous pouvez choisir de vous concentrer sur d'autres mesures.</p>
+Pour commencer, vous devez d'abord mesurer les appareils et les vitesses de connexion d'où viennent vos utilisateurs (par exemple, un appareil Android à \~200$ via une connexion 3G), à l'aide de plusieurs [outils](/fr/docs/Learn/Performance/Web_Performance_Basics). Ces mesures basées sur le temps se traduiront par des budgets de taille de fichier.
 
-<p>Pour un site contenant beaucoup de texte, tel qu'un blog ou un site d'actualités, la métrique <a href="/fr/docs/Glossaire/First_contentful_paint">First Contentful Paint</a> pourrait refléter plus étroitement le comportement de l'utilisateur. (c'est-à-dire à quelle vitesse les utilisateurs peuvent-ils commencer à lire), ce qui informera les budgets spécifiques aux fichiers (par exemple, la taille de la police), et leurs optimisations. (par exemple, utiliser l'<a href="/fr/docs/Web/CSS/@font-face/font-display">affichage des polices</a> pour améliorer les <a href="/fr/docs/Learn/Performance/perceived_performance">performances perçues</a>).</p>
+Une base de référence par défaut pour réduire le taux de rebond est d'atteindre un [Time to Interactive inférieur à 5 secondes en 3G/4G, et inférieur à 2 secondes pour les charges suivantes](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/). Cependant, en fonction des objectifs et du contenu spécifiques de votre site, vous pouvez choisir de vous concentrer sur d'autres mesures.
 
-<p>La valeur ultime d'un budget de performance est de corréler l'impact de la performance sur les objectifs commerciaux ou produits. Lors de la définition des mesures, vous devez vous concentrer sur l'<a href="https://extensionworkshop.com/documentation/develop/user-experience-best-practices/">expérience utilisateur</a>, qui dictera non seulement le taux de rebond ou de conversion, mais aussi la probabilité de retour de l'utilisateur.</p>
+Pour un site contenant beaucoup de texte, tel qu'un blog ou un site d'actualités, la métrique [First Contentful Paint](/fr/docs/Glossaire/First_contentful_paint) pourrait refléter plus étroitement le comportement de l'utilisateur. (c'est-à-dire à quelle vitesse les utilisateurs peuvent-ils commencer à lire), ce qui informera les budgets spécifiques aux fichiers (par exemple, la taille de la police), et leurs optimisations. (par exemple, utiliser l'[affichage des polices](/fr/docs/Web/CSS/@font-face/font-display) pour améliorer les [performances perçues](/fr/docs/Learn/Performance/perceived_performance)).
 
-<h2 id="Comment_mettre_en_œuvre_un_budget_de_performance">Comment mettre en œuvre un budget de performance?</h2>
+La valeur ultime d'un budget de performance est de corréler l'impact de la performance sur les objectifs commerciaux ou produits. Lors de la définition des mesures, vous devez vous concentrer sur l'[expérience utilisateur](https://extensionworkshop.com/documentation/develop/user-experience-best-practices/), qui dictera non seulement le taux de rebond ou de conversion, mais aussi la probabilité de retour de l'utilisateur.
 
-<p>Pendant le développement, il existe quelques outils pour effectuer des vérifications sur les actifs nouveaux ou modifiés:</p>
+## Comment mettre en œuvre un budget de performance?
 
-<ul>
- <li>Un bundler de modules (par exemple, <a href="https://webpack.js.org/">webpack</a>), possède des <a href="https://webpack.js.org/configuration/performance/">fonctionnalités de performance</a> qui vous avertiront lorsque les actifs dépassent les limites spécifiées.</li>
- <li><a href="https://github.com/siddharthkp/bundlesize">Bundlesize</a>, vous permet de définir et d'exécuter des contrôles de taille de fichier dans votre pipeline <a href="/fr/docs/Mozilla/Continuous_integration">CI</a>.</li>
-</ul>
+Pendant le développement, il existe quelques outils pour effectuer des vérifications sur les actifs nouveaux ou modifiés:
 
-<p>Les vérifications de la taille des fichiers sont la première ligne de défense contre les régressions, mais la conversion de la taille en mesures temporelles peut être difficile car les environnements de développement peuvent manquer de scripts tiers et d'optimisations généralement fournies par un <a href="/fr/docs/Glossaire/CDN">CDN</a>.</p>
+- Un bundler de modules (par exemple, [webpack](https://webpack.js.org/)), possède des [fonctionnalités de performance](https://webpack.js.org/configuration/performance/) qui vous avertiront lorsque les actifs dépassent les limites spécifiées.
+- [Bundlesize](https://github.com/siddharthkp/bundlesize), vous permet de définir et d'exécuter des contrôles de taille de fichier dans votre pipeline [CI](/fr/docs/Mozilla/Continuous_integration).
 
-<p>La première étape consiste à définir une base de développement pour chaque branche à comparer et la précision de la différence entre le développement et la production peut être utilisée comme objectif pour mieux correspondre à l'environnement réel.</p>
+Les vérifications de la taille des fichiers sont la première ligne de défense contre les régressions, mais la conversion de la taille en mesures temporelles peut être difficile car les environnements de développement peuvent manquer de scripts tiers et d'optimisations généralement fournies par un [CDN](/fr/docs/Glossaire/CDN).
 
-<p>Le <a href="https://github.com/GoogleChromeLabs/lighthousebot">bot Lighthouse</a> s'intègre à <a href="https://travis-ci.org/">Travis CI</a> et peut être utilisé pour collecter des métriques de <a href="https://developers.google.com/web/tools/lighthouse/">Lighthouse</a> et de <a href="https://webpagetest.org">Webpage Test</a> à partir d'une URL de dévloppement. Le bot réussira ou échouera en fonction des scores minimums fournis.</p>
+La première étape consiste à définir une base de développement pour chaque branche à comparer et la précision de la différence entre le développement et la production peut être utilisée comme objectif pour mieux correspondre à l'environnement réel.
 
-<h2 id="Comment_appliquer_un_budget_de_performance">Comment appliquer un budget de performance?</h2>
+Le [bot Lighthouse](https://github.com/GoogleChromeLabs/lighthousebot) s'intègre à [Travis CI](https://travis-ci.org/) et peut être utilisé pour collecter des métriques de [Lighthouse](https://developers.google.com/web/tools/lighthouse/) et de [Webpage Test](https://webpagetest.org) à partir d'une URL de dévloppement. Le bot réussira ou échouera en fonction des scores minimums fournis.
 
-<p>Plus tôt vous pourrez identifier un ajout potentiel poussant le budget, mieux vous pourrez analyser l'état actuel de votre site et identifier les optimisations ou le code inutile.</p>
+## Comment appliquer un budget de performance?
 
-<p>Cependant, vous devez avoir plusieurs budgets et être dynamique. Ils sont destinés à refléter vos objectifs en cours, mais permettent des risques et des expériences. Par exemple, vous pouvez introduire une fonctionnalité qui augmente le temps de chargement global mais tente d'augmenter l'engagement des utilisateurs. (c'est-à-dire combien de temps un utilisateur reste sur une page ou un site).</p>
+Plus tôt vous pourrez identifier un ajout potentiel poussant le budget, mieux vous pourrez analyser l'état actuel de votre site et identifier les optimisations ou le code inutile.
 
-<p>Un budget de performance vous aide à protéger le comportement optimal de vos utilisateurs actuels tout en vous permettant d'accéder à de nouveaux marchés et de proposer des expériences personnalisées.</p>
+Cependant, vous devez avoir plusieurs budgets et être dynamique. Ils sont destinés à refléter vos objectifs en cours, mais permettent des risques et des expériences. Par exemple, vous pouvez introduire une fonctionnalité qui augmente le temps de chargement global mais tente d'augmenter l'engagement des utilisateurs. (c'est-à-dire combien de temps un utilisateur reste sur une page ou un site).
 
-<h2 id="Voir_aussi">Voir aussi</h2>
+Un budget de performance vous aide à protéger le comportement optimal de vos utilisateurs actuels tout en vous permettant d'accéder à de nouveaux marchés et de proposer des expériences personnalisées.
 
-<ul>
- <li><a href="https://addyosmani.com/blog/performance-budgets/">Start Performance Budgeting</a> par Addy Osmani</li>
- <li><a href="https://web.dev/fast/performance-budgets-101">Performance Budgets 101</a> par Milica Mihajlija</li>
- <li><a href="https://timkadlec.com/remembers/2019-03-07-performance-budgets-that-stick/">Performance Budgets That Stick</a> par Tim Kadlec</li>
-</ul>
+## Voir aussi
+
+- [Start Performance Budgeting](https://addyosmani.com/blog/performance-budgets/) par Addy Osmani
+- [Performance Budgets 101](https://web.dev/fast/performance-budgets-101) par Milica Mihajlija
+- [Performance Budgets That Stick](https://timkadlec.com/remembers/2019-03-07-performance-budgets-that-stick/) par Tim Kadlec