Fix #4269 - Removes empty/special characters (#4270)

* Remove ufeff

* Remove u2064

* Remove u2062

* Replace u202f followed by : with  :

* Replace u202f next to « or » with   and « or »

* Replace u202f followed by ; with  ;

* Replace u202f followed by ! with  

* Replace u202f followed by ? with  ?

* Replace remaining u202f with classical space

* Replace u200b surrounded by space  with classical space

* Replace u200b surrounded by space  with classical space - again (repeated)

* Remove remaining u200b

* Remove u200a

* Replace u2009 with  

* Remove u00ad

* Replace u00a0 followed by : ! or ? with   and punctuation

* Replace u00a0 surrounded « or » with   and punctuation

* Replace u00a0 followed by whitespaces

* Replace u00a0 preceded by whitespaces

* Replace u00a0 followed by a newline with a newline

* Replace u00a0 followed by a newline with a newline - Take2

* Replace u00a0 followed by a ;   and punctuation

* Remove u00a0 followed by ,

* Remove u00a0 in indentation spaces with \n([ ]*)([\u00a0])([ ]*)

* Manual replacement of ([\u00a0])([ ]+)

* Replace remaining ([\u00a0]+) by a space

* cleaning empty elements

* remove ufe0f

* Remove u00a0 and u202f after merging against updated main

* remove double whitespace using (\w)(  )(\w)

5 files changed, 24 insertions, 24 deletions

diff --git a/files/fr/web/performance/how_browsers_work/index.md b/files/fr/web/performance/how_browsers_work/index.md
index e8e78939fc..db2ab9f11c 100644
--- a/files/fr/web/performance/how_browsers_work/index.md
+++ b/files/fr/web/performance/how_browsers_work/index.md
@@ -16,7 +16,7 @@ Pour comprendre comment améliorer les performances et les performances perçues
 
 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é.
 
-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.
+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.
 
 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.
 
@@ -114,7 +114,7 @@ Même si le code HTML de la page de demande est plus volumineux que le paquet in
 
 Nous décrivons cinq étapes dans le chemin de rendu critique, ou "[critical rendering path](/fr/docs/Web/Performance/Critical_rendering_path)".
 
-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.
+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.
 
 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.
 
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 3011ce92e6..9ce23d8285 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
@@ -3,26 +3,26 @@ 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
 ---
-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).
+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).
 
 ## Objectifs de chargement
 
-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.
+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.
 
 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.
 
-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.
+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 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.
 
 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.
 
 ### Objectifs concernant les étapes de chargement de la page (en anglais <i lang="en">idling</i>)
 
-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.
+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.
 
 ### Objectifs concernant les animations
 
-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.
+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.
 
 ### Objectifs concernant la réactivité
 
-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.
+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 78fa39206d..1a4021e71f 100644
--- a/files/fr/web/performance/index.md
+++ b/files/fr/web/performance/index.md
@@ -22,7 +22,7 @@ The MDN [Web Performance Learning Area](/fr/docs/Learn/Performance) contains mod
 - [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.
+  - : 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)
@@ -49,8 +49,8 @@ The MDN [Web Performance Learning Area](/fr/docs/Learn/Performance) contains mod
 
 ## 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).
+- [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.
 
@@ -113,7 +113,7 @@ The MDN [Web Performance Learning Area](/fr/docs/Learn/Performance) contains mod
 - [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.
+  - : 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
@@ -123,22 +123,22 @@ The MDN [Web Performance Learning Area](/fr/docs/Learn/Performance) contains mod
 - 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.
+  - : 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.
+  - : 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.
+  - : 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.
+  - : 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)
+- [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
diff --git a/files/fr/web/performance/lazy_loading/index.md b/files/fr/web/performance/lazy_loading/index.md
index 4e659bda89..5a70ef59cf 100644
--- a/files/fr/web/performance/lazy_loading/index.md
+++ b/files/fr/web/performance/lazy_loading/index.md
@@ -21,10 +21,10 @@ Le chargement différé peut être appliqué sur de multiples ressources et avec
 
 #### Division du code
 
-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 :
+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;:
 
-- 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.
+- division par points d'entrée&nbsp;: séparation du code en différents points d'entrée au sein de l'application&nbsp;;
+- division dynamique&nbsp;: séparation du code où des déclarations [`import()`](/fr/docs/Web/JavaScript/Reference/Statements/import) dynamiques sont utilisées.
 
 ### JavaScript
 
@@ -34,7 +34,7 @@ Toute balise `<script>` utilisant `type="module"` sera traitée comme un [module
 
 ### CSS
 
-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 :
+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&nbsp;:
 
 ```html
 <link href="style.css"    rel="stylesheet" media="all">
@@ -71,7 +71,7 @@ Vous pouvez déterminer si une image donnée a terminé son chargement en examin
 
 #### Polyfill
 
-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)
+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&nbsp;: [loading-attribute-polyfill](https://github.com/mfranzke/loading-attribute-polyfill)
 
 #### API Intersection Observer
 
@@ -79,7 +79,7 @@ Pour ajouter la prise en charge de l'attribut `loading` sur les vieux navigateur
 
 #### Gestionnaires d'évènements
 
-Lorsque la compatibilité navigateur est cruciale, vous pouvez utiliser ces quelques options :
+Lorsque la compatibilité navigateur est cruciale, vous pouvez utiliser ces quelques options&nbsp;:
 
 - [polyfill pour l'API <i lang="en">Intersection observer</i>](https://github.com/w3c/IntersectionObserver)
 
diff --git a/files/fr/web/performance/performance_budgets/index.md b/files/fr/web/performance/performance_budgets/index.md
index 4626639e8c..7c5b83f4ea 100644
--- a/files/fr/web/performance/performance_budgets/index.md
+++ b/files/fr/web/performance/performance_budgets/index.md
@@ -46,7 +46,7 @@ Pour un site contenant beaucoup de texte, tel qu'un blog ou un site d'actualité
 
 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.
 
-## Comment mettre en œuvre un budget de performance?
+## Comment mettre en œuvre un budget de performance?
 
 Pendant le développement, il existe quelques outils pour effectuer des vérifications sur les actifs nouveaux ou modifiés: